--On Saturday, 31 March, 2007 20:37 +0200 Frank Ellermann
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.
Not inherently, although that will certainly be the common case
in practice in the next few years.
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
One thing that's IMO worse than bogus bounces are lost bounces.
Frank, this seems to me to be getting out onto the slippery
slope toward inventing new rule and requirements, but that is
just my personal opinion.
However, if you think a change should be made, it would be
helpful, at least to me, if you would propose something specific
for people to evaluate, rather than just pointing out issues.