Ok, I've assigned "Issue 12"* to the IPv6 relationship issues so
we don't lose track of them. More below.
--On Saturday, 31 March, 2007 22:37 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
John C Klensin wrote:
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.
Not necessarily, you already have similar considerations in
2.3.8 derived from 1123 5.3.7.
You could add a note that MTAs accepting "IPv6 mail" and
forwarding it as "IPv4" are considered as gateways if the
reverse-path cannot be reached via IPv4. Then they MAY either
the rewrite reverse-path to something working in an IPv4
environment, or they MAY reject it.
It's probably not yet obvious that this is a *gateway*
scenario.
Actually, it feels at least as much like a layer violation,
since SMTP-over-IPv4 and SMTP-over-IPv6 are both SMTP-over-IP,
as it does like a gateway one. I'm very troubled by this one
and don't know quite what to do about it.
propose something specific for people to evaluate, rather than
just pointing out issues.
1123 5.3.7D offers (about RFC 822 addresses, your 3.7.4):
5.3.7D: they must be effective and useful for sending replies.
= 3.7.4: and MUST be effective and useful for sending replies.
I'm not sure what 1123 5.3.7F means for this issue, 3.7.5 is
clearer:
| If the foreign environment has no equivalent concept, the
| gateway must select and use a best approximation, with the
| message originator's address as the default of last resort.
Assuming that "IPv6 only" is a kind of "foreign environment"
for IPv4 mailers that's not good enough if the "last resort"
is still "IPv6 only".
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".
On the one hand, the "no substantive changes" rule, combined
with my impression that we don't have a lot of operational
experience with this, argues for just that solution. On the
other, having to prohibit IPv6 (or IPv6-without-IPv4) in 2007
seems strange and very unfortunate. RFC3974, which does derive
from operational experience, doesn't shed a lot of light on
this: a quick summary is that IPv4-only is ok, IPv6-only is ok,
but, for mixtures or unknown destinations, any IPv6 host had
better be running dual-stack with some IPv4 MX records. That
document contains a few statements that I believe to be serious
errors (perhaps the reason it was published as an independent
submission with strong disclaimers), but it is at least a
thoughtful attempt to explore the problem.
I need consensus advice on this one.
john
* Issue 11 was assigned to getting rid of the "A RR" references
in favor of something more general. Those changes have already
been made in the working version of -02.