Greg Sims: > We divided our outbound email into two streams: transactional and > bulk. Each of the streams uses different ip addresses. One ip for > transactional email and a randmap group of four ips for bulk email. > The transactional email is sent from domain @raystedman.org. The bulk > email is sent from a subdomain @devotion.raystedman.org. > > The ip addresses used for all of our outbound transfers are configured > using raystedman.org for both forward and reverse DNS. For example, > if one of the bulk hostnames is t4.raystedman.org pointing to 1.2.3.4. > Dig -x 1.2.3.4 (reverse dns) points back to t4.raystedman.org. The > master.cf transports are configured with: > > -o smtp_bind_address=1.2.3.4 > -o smtp_helo_name=t4.raystedman.org > > I believe this is a fairly standard setup for the domain. > > We are receiving a few entries in our maillogs that look like this: > > Oct 23 02:04:12 mail0.raystedman.org t4/smtp[38639]: C422783FDAA: > to=<em...@prodigy.net>, > relay=al-ip4-mx-vip1.prodigy.net[144.160.235.143]:25, delay=3.7, > delays=0.04/0/3.6/0.02, dsn=5.7.1, status=bounced (host > al-ip4-mx-vip1.prodigy.net[144.160.235.143] said: 550 5.7.1 > Connections not accepted from servers without a valid sender > domain.alph765 Fix reverse DNS for 1.2.3.4 (in reply to MAIL FROM > command))
The exact message, incluing the name 'alph765' of the cluster with broken reverse DNS: https://forums.att.com/conversations/att-internet-email-security/prodigynet-reverse-dns-lookup-is-broken/5f07b53ac17a063d9bfecdb8 It affects multiple domains hosted at AT&T: https://community.spiceworks.com/topic/2093608-reverse-dns-record-for-email-rejected-by-sbcglobal https://www.netsolinc.com/prodigy-email-issues/ This is what I did when GMAIL was randomly bouncing mail because of some bogus DNS error: /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: gmail.com google: /etc/postfix/master.cf google unix - - y - - smtp -o soft_bounce=yes (there is no support to specify a lookup table for parameters such as soft_bounce, smtp_bind_address, and so on). Of course one would have to scale this up to your requirements, and monitor logs for legitimate rejects. In your case setting a short maximum_queue_life_time may be sufficient to avoid hannering sites with dead recipient addresses. Wietse
