0

Config: Postfix on a Linux machine, static broadband address but because it's residential service, the provider will not provision reverse DNS PTR records for us. We're working on alternatives, but the system has been running like this for 2 years with no noticeable effect besides AT&T and Craigslist refusing mail from us.

A PTR record lookup for (our IP with quads reversed).in-addr.arpa returns our-ip.location.subnet.cablecompany.com, but there is no forward record matching that.

The system has SPF and OpenDKIM, no DMARC. No patches/updates/changes to system recently.

Last week a user on Gmail sent mail to an alias on our system that expands to a mix of addresses on various systems. The mail was delivered to all of the non-Gmail addresses the alias expands to.

Five days later, our Postfix install sent the user a bounce containing a list of entries for every Gmail address on the alias, with a form like the following:
________@gmail.com (expanded from <(alias)@(our host)>): host alt1.gmail-smtp-in.l.google.com[209.85.202.27] said: 550-5.7.25 [(our ip address)] The IP address sending this message does not have a 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not 550-5.7.25 point to the sending IP. As a policy, Gmail does not accept messages 550-5.7.25 from IPs with missing PTR records. Please visit 550-5.7.25 https://support.google.com/mail/answer/81126#ip-practices for more 550 5.7.25 information.

Messages from local users to this alias deliver fine to all addresses. So, local user -> postfix alias -> everywhere is ok, and gmail -> postfix alias -> everywhere-except-gmail is ok, but gmail -> postfix alias -> gmail waits five days and gripes We have not tested sending from not-local-but-not-gmail addresses.

Can anyone explain to me what's going on?

Kellarnen
  • 1
  • The previous origin of the message is of little importance in this context - the policy applies to all situations where mail is entering Google systems without authentication. – anx Aug 09 '22 at 07:19
  • Your logs (or manual queue inspection, try `postqueue -p`) should have more detailed information. It is not unusual to reject connections such that individual messages remain in the queue (in your case: for 5 days) until someone deals with the problem. – anx Aug 09 '22 at 07:21
  • It totally makes sense that a DNS PTR issue would be treated as a temp failure by Gmail, so the message would be retried until it timed out five days later. The previous origin of the message should not matter, but it does, which is what I find so mysterious. As I said in the second to last paragraph of the original post, mail to this alias from a local user delivers to Gmail accounts, but mail from Gmail users to the same alias does not. – Kellarnen Aug 11 '22 at 05:24

0 Answers0