michael.dillon@xxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf