michael(_dot_)dillon(_at_)bt(_dot_)com wrote:
Let me throw another idea into the mix. What if we were to
recommend a transition architecture in which an MTA host
ran two instances of the MTA software, one binding only to
IPv4 addresses, and the other binding to only IPv6 addresses.
Assume that there will be some means for the two MTA software
instances to exchange messages when their DNS queries return
the wrong kind of addresses (A or AAAA). The IPv4 MTA can
continue to use the rules regarding MX records with A record
fallback. The IPv6 MTA could require SRV records to identify
destinations and have no AAAA fallback.
it's not as if we want mail that is initially submitted via
SMTP-over-IPv4 to be treated differently from the mail that is initially
submitted via SMTP-over-IPv6. if an MX for a domain has presence on
both IPv4 and IPv6, there's no reason that an SMTP client shouldn't try
to contact that MX using either IPv4 or IPv6.
as for using SRV for this case, it's pointless. MX already works fine;
SRV would require an extra DNS lookup with the attendant delay,
overhead, and potential for failure. using SRV is also more disruptive
with no benefit that I can see.
It immediately seems obvious that some issues surrounding
an architecture of email systems during the IPv4-IPv6 transition,
are well out of scope of RFC28821bis.
perhaps, but I disagree that this is one of those issues.
more broadly, I think what we're seeing is an example of why our model
for revision of our standards is broken. what you seem to be arguing
is that since we can't get everything settled with 2821bis immediately,
we should indefinitely defer any further changes to it - even when we
have good reason to believe there are problems that we can fix in the
near term and that it's better to fix them now than later.
really what we should be doing is periodically (or continuously)
maintaining our specifications as new requirements issues are
identified. we need to develop a better sense of which kinds of
changes/improvements/fixes can be made without a major rewrite/rethink
and which ones require a process like that which produced rfc2821.
Keith
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf