Postfix in Docker container not forwarding virtual aliases

Question

I am trying to configure Postfix for the first time. I do not need mailboxes, I want only virtual aliases, forwarding [email protected] --> [email protected]

My Postfix is running in a Docker container on a Digital Ocean droplet.

I have got as far as:

$ postalias -q [email protected] [email protected] 

...from inside the container, i.e. my /etc/postfix/virtual file is working.

Also, from outside the container on the droplet:

telnet example.com 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 example.com ESMTP Postfix (Ubuntu) 

But from my own computer:

$ telnet example.com 25 Trying <droplet IP>... telnet: connect to address <droplet IP>: Operation timed out telnet: Unable to connect to remote host 

I think this is expected and correct as a result of the mynetworks config setting (see below) which is as recommended by Digital Ocean - I don't want to host an 'open' SMTP relay.

I have an MX record for example.com. set up and I can ping example.com just fine and access websites on it. Also (from my computer):

$ host -t mx example.com example.com mail is handled by 1 example.com. 

So that looks right.

But if I send a test message to [email protected] nothing comes through and I don't see anything in Postfix logs either... I can't tell at what point it failed.

I am uncertain if the problem is in my Postfix configuration or in the routing into the container.

The container exposes port 25 (only) and is run via Fig with

ports: - "25:25" 

From shell in the droplet:

$ netstat -tulpn | grep 25 tcp6 0 0 :::25 :::* LISTEN 10680/docker-proxy 

My /etc/postfix/main.cf has this in it:

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = example.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = /etc/mailname, <container id>, localhost.localdomain, localhost, example.com relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all virtual_alias_domains = example.com virtual_alias_maps = hash:/etc/postfix/virtual inet_protocols = ipv4 

I'm not really clear of the distinction between myhostname (which was originally set to <container id>) mydestination and virtual_alias_domains

Updated

with output from http://mxtoolbox.com/SuperTool.aspx

Connecting to <server IP> 220 example.com ESMTP Postfix (Ubuntu) [733 ms] EHLO MXTB-PWS3.mxtoolbox.com 250-example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN [714 ms] MAIL FROM: <[email protected]> 250 2.1.0 Ok [722 ms] RCPT TO: <[email protected]> 454 4.7.1 <[email protected]>: Relay access denied [715 ms] MXTB-PWS3v2 4006ms 

Update
As @masegaloeh helped me discover, my postfix server was basically working. I had two problems that confused things though:

1. Due to mistake in my Dockerfile I had /var/log/mail.log owned by root user... this is why it stayed empty. I didn't see any errors about it but basically rsyslog couldn't write to it. A chown syslog:adm /var/log/mail.log step fixed that, and I was able to see that indeed postfix was handling and forwarding mail to the alias.

2. I mistakenly believed I was able to telnet to other servers on port 25 from my laptop, just because I thought I'd done stuff in the past that would need that to work. But actually I can't. However I was able to telnet example.com 25 from another server so, again, stuff was actually working.

3. Sending mail to the alias from another server works, and comes through to my Gmail destination address.

4. It seems my problem is actually with Gmail... when I send the message to [email protected] from my Gmail account it does not show up. I since tried with aliases I had setup on another hosting... some work and some don't... leading to:

Conclusion:
it seems that Gmail will only accept mail for aliases that are configured under Settings > Accounts and Import > Send mail as ...unfortunately Gmail now requires you to specify a 3rd party SMTP server for it when setting up a new one, so it looks I will have to get to grips with TLS etc in my postfix install.

Answer 1

This Telnet log message

telnet: connect to address <droplet IP>: Operation timed out 

isn't caused by mynetworks configuration in postfix! The error indicated that either your telnet packet doesn't reach the docker IP address or postfix in docker doesn't respond to your telnet.

As you mention that you telnet from your own computer, then maybe your ISP is blocking port 25. However, because you mention that the email from outside can't go through and even the postfix log was empty then maybe the postfix container doesn't respond at all. Maybe you fail to bind DO droplet port to postfix docker port. Try to run netstat -tulpn | grep 25 from DO droplets to confirm that postfix is reachable from outside.

As I wasn't familiar with docker, then I can't offer exact solution here. However some googling result indicated that you have set the IPtables to do masquerading like the official documentation: Binding container ports to the host

Edit
Anyway your netstat output looks fine. It's indicated that it listen in IPv6 only. But this post and this post indicated that Ubuntu/Debian use IPv4-mapped IPv6 addresses method to provide the connection so maybe it is reachable from the outside IPv4 too.

For further troubleshooting, here I gave the least requirement to send email

• Some MTA (postfix,exim, IIS) listen on port 25. You can confirm this by run netstat and telnet to localhost
• MX record/A record must be properly configured.
• Internet host can reach port 25 on your server. This is means no firewall issue that dropped SMTP packet.

Because you introduced docker proxy to your stack then you must confirm

1. Packet received in DO droplet port 25. Try to run tcpdump port 25 when you send email to confirm that your host received the packet.
2. Docker proxy actually forward packet to postfix. Postfix always logs incoming SMTP connection.