[BlueOnyx:21601] Re: 550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR

[Jeff Folk]

> On Dec 21, 2017, at 5:26 PM, Michael Stauber <mstauber at blueonyx.it> wrote:
> 
> That's my experience as well: If CentOS 7 is hooked up to a network that
> supports IPv6 (even if that server only has IPv4 configured), then some
> services might end up using IPv6 as well. At least for outgoing
> connections if the target supports IPv6. In that case it might even
> prefer to use IPv6 even if IPv4 is available at the destination.
> 
> There are some factors that can throw a wrench into that. Like if you
> use a DNS-resolver that only serves IPv4.

This is really starting to chap by backside. On my other 5208R (CentOS 6.9) that I’ve not had this issue with - Just had a customer notify me that they were having trouble sending to Comcast with this error:

> From: Mail Delivery Subsystem [mailto:MAILER-DAEMON at box1.qzoneinc.net <mailto:MAILER-DAEMON at box1.qzoneinc.net>] 
> Sent: Friday, December 22, 2017 3:03 PM
> To: agent at davisjohnstone.com <mailto:agent at davisjohnstone.com>
> Subject: Returned mail: see transcript for details
> 
> The original message was received at Fri, 22 Dec 2017 15:02:56 -0600 from
> cpe-24-243-103-228.rgv.res.rr.com <http://cpe-24-243-103-228.rgv.res.rr.com/> [24.243.103.228]
> 
>   ----- The following addresses had permanent fatal errors -----
> <susanmyerscough at comcast.net <mailto:susanmyerscough at comcast.net>>
>    (reason: 554 resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/>
> resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/> 2605:6000:7b44:b00:21d:9ff:fe1e:9f...
> requirement. For more information, refer to:
> http://postmaster.comcast.net/smtp-error-codes.php#554 <http://postmaster.comcast.net/smtp-error-codes.php#554>)
> 
>   ----- Transcript of session follows ----- ... while talking to
> mx2.comcast.net <http://mx2.comcast.net/>.:
> <<< 554 resimta-ch2-24v.sys.comcast.net <http://resimta-ch2-24v.sys.comcast.net/> resimta-ch2-24v.sys.comcast.net <http://resimta-ch2-24v.sys.comcast.net/>
> 2605:6000:7b44:b00:21d:9ff:fe1e:9fe Comcast requires that all mail servers
> must have a PTR record with a valid Reverse DNS entry. Currently your mail
> server does not fill that requirement. For more information, refer to:
> http://postmaster.comcast.net/smtp-error-codes.php#554 <http://postmaster.comcast.net/smtp-error-codes.php#554>
> ... while talking to mx1.comcast.net <http://mx1.comcast.net/>.:
> <<< 554 resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/> resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/>
> 2605:6000:7b44:b00:21d:9ff:fe1e:9fe Comcast requires that all mail servers
> must have a PTR record with a valid Reverse DNS entry. Currently your mail
> server does not fill that requirement. For more information, refer to:
> http://postmaster.comcast.net/smtp-error-codes.php#554 <http://postmaster.comcast.net/smtp-error-codes.php#554>
> 554 5.0.0 Service unavailable
> Reporting-MTA: dns; box1.qzoneinc.net <http://box1.qzoneinc.net/>
> Received-From-MTA: DNS; cpe-24-243-103-228.rgv.res.rr.com <http://cpe-24-243-103-228.rgv.res.rr.com/>
> Arrival-Date: Fri, 22 Dec 2017 15:02:56 -0600
> 
> Final-Recipient: RFC822; susanmyerscough at comcast.net <mailto:susanmyerscough at comcast.net>
> Action: failed
> Status: 5.5.0
> Diagnostic-Code: SMTP; 554 resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/> resimta-po-03v.sys.comcast.net <http://resimta-po-03v.sys.comcast.net/> 2605:6000:7b44:b00:21d:9ff:fe1e:9fe Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more information, refer to: http://postmaster.comcast.net/smtp-error-codes.php#554 <http://postmaster.comcast.net/smtp-error-codes.php#554>
> Last-Attempt-Date: Fri, 22 Dec 2017 15:02:58 -0600

Looked to me like Comcast was picking up the IP of the desktop sending the message to my server (on rev.res.rr.com), so I enabled ‘hide previous headers’ and had my customer try again. Failure with the same message. Acting on a hunch that they were blocking my non-PTR IPv6 (and not telling me), I applied the faux IPv4/IPv6 CLIENT_OPTIONS line to this server and the mail was accepted.

I swear… Running a well configured mail server has never been easy, but these arbitrary requirements of PTR records for mail delivery on a not quite ready for prime time IPv6 are making this a nightmare.

I hope everyone has a blessed and merry Christmas!

Cheers,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20171222/e6c6c3cf/attachment.html>