John C Klensin wrote:
ITYM "A or AAAA", at some point (maybe not now) we've to
check all potential IPv6 issues.
I vote for "now". Have fixed this one per my prior note and
also changed section 5 to use "address RR" instead (and define
it on first use).
Good, but there might be IPv6 considerations needing more than
only "A or AAAA": What about IPv6 only MXs ? Is it okay if an
IPv4 mailer tries to forward MAIL FROM:<some(_at_)user(_dot_)example>, and
the MXs of user.example offer only IPv6 ? I think the opposite
case isn't critical, IPv6 has a way to reach IPv4.
Is it okay to reject any "IPv6 required" reverse-path from the
POV of IPv4 only mailers deciding to reject or accept the mail ?
Even if the mail has a "ready for DKIM" stamp and an "SPF PASS",
plus a "vouch by reference" certificate, and it's on a Tuesday
with all IPv4 octets smaller than 128, there's no clear way to
report errors or send DSNs later. Or any RFC 3864 auto-replies.
One thing that's IMO worse than bogus bounces are lost bounces.
Frank