Re: Last Call: draft-klensin-rfc2821bis

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