How about a more radical approach, just forbid "IPv6 only"
for the moment somewhere in section 5 ? "IPv6 only" is IMO
completely against the spirit of "if it can't receive mail
it has no business to send mail".
Frank, that's too radical.
I don't think so. For "foreign" stuff there are already tons
of MUSTard that addresses in the envelope and in the header
are supposed to work in the environment where they are used.
Strictly speaking it's not allowed to use <some(_at_)thing(_dot_)local>
in Internet messages or SMTP envelopes in the public Internet
as defined by STD 10, because we have no way to send a reply
or error report to <some(_at_)thing(_dot_)local> if we're not in the
same local net.
There MUST be a gateway fixing this before it reaches us. If
not it's a standards violation. Very likely it's also spam
and/or a criminal offense like most mails today.
The EAI folks are just designing a complete new overlay net
for port 25 traffic, so far they have an SMTP extension and
a new superset of message/rfc822, and maybe they opt for a
new MIME version implemented by redefining MIME Version 1.0.
IPv6 only addresses are not better than UTF8SMTP addresses,
<some(_at_)thing(_dot_)local>, or Fido addresses, they MUST go through
a gateway replacing them by something users in IPv4 only nets
For starters the MAIL FROM has to work. That's essential for
SMTP. And it's enforced by receivers employing some kind of
"call back verification". Even if it's as little as checking
that the domain in question has an associated IPv4 address.
And a plausible (receiver's POV) MAIL FROM isn't enough, the
end user getting the mail would also like to click a "reply"
button, expecting that the Reply-To (or From) address work.
There can be numerous cases where it won't work in practice,
that's just the "S" in SMTP, but if it systematically doesn't
work it's a violation of the spec.
In any case, the SMTP adds its own identifier to the reverse-path.