On 2021-11-22 16:48 +0000, Claus Assmann <mutt+...@esmtp.org> wrote: > On Mon, Nov 22, 2021, Aaron Poffenberger wrote: > > > some MTAs reject emails where fqdn of the Message-ID does not have a > > reverse look-up, returning the error: > > What do you mean by "reverse look-up" here? > A FQDN might have an A/AAAA or MX record, not a PTR record. > > > <user>@*sbcglobal.net*: 550 5.7.1 Connections not accepted from > > servers without a valid sender domain.alph758 Fix reverse DNS for <ip > > address> > > "reverse DNS for <ip> address" sounds like a PTR entry for the > client IP which is connecting to the server. > > I'm not sure the problem is really related to "fqdn of the Message-ID", > could you give a real example: > sending from the same host using the same addresses but two different > Message-ID - only one of which fulfills the requirement you stated.
I send an email to <user>@sbcglobal.net from my laptop (e.g., host.example.org). It generates a Message-ID (e.g., yzvdeadzbeeff...@host.exmaple.com). host.example.com has no DNS record of it's own because it's behind a NAT'd firewall at my house. example.com is the mailing domain. example.com has a publicly routable address (e.g., 198.51.100.1). There's also a reverse-DNS entry from 198.51.100.1 to example.com, as well as SPF, DKIM, and DMARC records. sbcglobal.net will fail delivery of the message with the following error: <user>@*sbcglobal.net*: 550 5.7.1 Connections not accepted from servers without a valid sender domain.alph758 Fix reverse DNS for 198.51.100.1 N.B. Any ATT-related domain will issue the same errors. I've run into with <user>@att.net. ------------------------ I know this is related to Message-ID because if I go into muttrc(5) and put `set hostname="example.com"` and send again to u...@sbcglobal.net, the message goes through without issue. I blogged about the fix a while back and have been contacted by other users who had the same problem. The same fix worked for them as well. Clearly ATT are going beyond the requirements of rfc2822 in requiring the fqdn of the Message-ID to have a reverse look-up entry that points to the outbound MTA ip address (in this example, 195.51.100.1), but it's still happening. And the error message from sbcglobal.net/ATT is not clear that that's the problem. But the fix works. Also, as noted in my original, setting the fqdn of the Message-ID to the fqdn of the From address make sense. When I'm sending email from my laptop through gmail.com, the Message-ID picks-up the fqdn of my laptop rather than using gmail.com. All emails from my laptop sent through `smtp.gmail.com` have the form <%z...@host.example.com> rather than <%z...@gmail.com>. Perhaps for some users it makes sense for the Message-ID to from from MUA host, but there's an argument to be made that it should come from the domain of the user's email address. Cheers, --Aaron
