I have read the many answers to many similar questions, but have not found exactly this question or any answer that helped.
I have a Postfix 2.11 server (mail-server.example.com) that is strictly for outgoing email. It works fine if it is able to send the email on the first try. However, for performance reasons, if it cannot send the email on the first try and instead wants to defer it, I have configured smtp_fallback_relay so that it forwards the email to another server (deferred-mail.example.com) that handles only deferred emails.
smtp_fallback_relay = [deferred-mail.example.com]
If, from my trusted IP (mynetworks), I send an email to either server destined for [email protected], either server will accept it and try to send it to Gmail. Because my server IP is new, Gmail rejects the email from either server with 421 (temporary deferral). As expected, the deferred-mail server simply puts the message in its deferred queue and tries again later.
The weird part is that while mail-server will send the message to Gmail to begin with, after receiving the 421, it attempts to send the mail to deferred-mail, but gives up and instead bounces the message, saying "mail for gmail.com loops back to myself". I see no logs on the deferred-mail server saying anything about what is going on.
So both servers are configured to accept mail and relay it to Gmail if the client is trusted, and the deferred-mail trusts mail-server (I can send to a Gmail address when directly connecting to deferred-mail from `mail-server), so how is Postfix coming up with this "loop" and why is it bouncing the email instead of relaying it?
Update and clarification about the logs below.
For privacy reasons, I am not posting the actual domain name or IP addresses we are using. Throughout this post and in the log excerpt below, I have replaced the actual root domain name we are using with example.com.
This setup was copied from a working email cluster. I am confident that it is theoretically sound, and suspect it is just a matter of some setting not being correctly replaced or translated. It is just that with this odd behavior and seemingly incorrect error message, I cannot figure out what to change, and that is why I am asking for help.
- "Greeted me with my own hostname" is not a mistake or problem
When sending emails via SMTP, the sender begins by identifying itself by host name. Big mail processors like Gmail and Yahoo take several steps to assess the reputation of the sender. With IPv4, two of the first things they did were
- Record the IP address of the sender and build up a record of the quality and quantity of emails coming from that specific IP address
- Verify that the reverse DNS record for that IP address maps back to the host name the sender identified itself with
If the IP address has a bad reputation or the reverse DNS does not match the sender host name, the receiver would be much more likely to mark the email as Spam regardless of anything else.
For both these reasons, both mail-server.example.com and deferred-mail.example.com are behind the same NAT Gateway that
- Has a static IP address, so all email comes from the same IP address with the same reputation (
REDACTED-PUBLIC-IPv4in the log excerpt below) - Has a reverse DNS record that identifies that IP address as
mail-server.example.com
For that reason, when deferred-mail.example.com identifies itself in an SMTP session, it identifies itself as mail-server.example.com. This is correct, desired behavior and not an uncommon situation for the reasons stated above. (deferred-mail.example.com points to a private IP address, 10.111.14.181 in the logs below and does not have a reverse DNS record.)
- IPv6 failure is not a mistake or problem
Our server stack does not currently have IPv6 enabled. Because we are using a new domain name, we have zero domain reputation, so we want to stick to IP reputation until we have a solid domain reputation established. (Because IPv6 addresses are disposable, they will never be an adequate basis for reputation.)
Therefore, the failures to reach Gmail's IPv6 servers aspmx.l.google.com and alt2.aspmx.l.google.com are expected and not particularly a problem, although if there is a setting that I can set to keep postfix from even trying to reach IPv6 addresses, please let me know so I can make that change.
Answer to disabling IPv6 attempts: Add this to your main.cf
inet_protocols = ipv4
Per request, here are redacted logs of the error:
postfix/smtpd[26668]: 50F7C5B81: client=ip-10-111-7-75.us-west-2.compute.internal[10.111.7.75]
postfix/cleanup[26682]: 50F7C5B81: message-id=<>
opendkim[36]: 50F7C5B81: can't determine message sender; accepting
postfix/qmgr[143]: 50F7C5B81: from=<REDACTED-SENDER>, size=279, nrcpt=1 (queue active)
postfix/smtp[26686]: 50F7C5B81: host aspmx.l.google.com[74.125.197.26] said: 421-4.7.0 [REDACTED-PUBLIC-IPv4 15] Our system has detected that this message is 421-4.7.0 suspicious ...
postfix/smtp[26686]: connect to aspmx.l.google.com[2607:f8b0:400e:c07::1a]:25: Cannot assign requested address
postfix/smtp[26686]: connect to alt2.aspmx.l.google.com[2607:f8b0:4001:c56::1a]:25: Cannot assign requested address
postfix/smtp[26686]: 50F7C5B81: host alt2.aspmx.l.google.com[142.250.152.27] said: 421-4.7.0 [REDACTED-PUBLIC-IPv4 15] Our system has detected that this message is 421-4.7.0 suspicious ...
postfix/smtp[26686]: warning: host deferred-mail.example.com[10.111.14.181]:25 greeted me with my own hostname mail-server.example.com
postfix/smtp[26686]: warning: host deferred-mail.example.com[10.111.14.181]:25 replied to HELO/EHLO with my own hostname mail-server.example.com
postfix/smtp[26686]: 50F7C5B81: to=<[email protected]>, relay=deferred-mail.example.com[10.111.14.181]:25, delay=26, delays=24/0.01/1.5/0, dsn=5.4.6, status=bounced (mail for gmail.com loops back to myself)
log messages here about sending bounce email to sender
have been removed
postfix/bounce[26688]: 50F7C5B81: sender non-delivery notification: AEA8A5B83
postfix/qmgr[143]: 50F7C5B81: removed
According to a post I found in a forum somewhere, using any port other than port 25 will disable the mail loop detection that I was running into. However, I have been unable to find any authoritative source for either why the mail was considered looping or why changing the connection port made a difference. I will leave this question open for an answer that points to authoritative sources.
The solution that worked for me was to add TLS certificates and enable SMTP and TLS on port 587 on
deferred-mail.example.comand change the configuration onmail-server.example.comtoI think this is more than is necessary; the post said any port other than 25 would do. I did it this way because I wanted to correctly set up TLS on port 587 anyway.
A loop is detected because the destination server is replying with the hostname that sending server is configured with. It is that simple.
The code is a bit convoluted, but a convincing section (note the two different error messages for the same actual condition) is https://github.com/vdukhovni/postfix/blob/2595917e491dfe704390b9bf1100bcdd35b21ae8/postfix/src/smtp/smtp_proto.c#L548-L563
To avoid this problem I recommend re-examining the reasons that are pushing you to use the same hostname on both your hosts. Maybe they don't really need to be the same? Maybe just the hostname as used by postfix could be different? Maybe you can configure a secondary listener on the second host that has a different hostname (another port)? Maybe you can disable the warning, but that can be dangerous since you are modifying things; the next modification could be an unexpected loop that would not be caught.