Re: Minor is. It's not a pardigm change

Dave Crocker writes:
> John R Levine wrote:
> > Quite true.  If the goal is to maximize the total amount of mail 
> > delivered to mail servers, legit mail, spam, blowback, phishes, 
> > whatever, then fallback to AAAA is definitely the right thing to do. 
> >  But is that really what we're trying to accomplish?
> I thought the goal was to add v6 support to Internet mail.
Adding IPv6 support to internet mail forces a question: If there isn't 
an MX RR for a given domain, does the SMTP client fall back to looking 
up an A RR, A or AAAA, or A and AAAA? We have to choose, and all of 
them represent a change.
Look up only A: What John wants, and what I think is best, and what most 
IPv4-only hosts do today. IPv6-only hosts would have to look up A and 
forward mail to such destinations via a relay, and IPv6-only mail 
servers would need to have an MX record pointing at them.
This is a change because it means that IPv6-only hosts aren't presumed 
to run mail servers by default, which also implies that code cannot 
make an email address by concatenating some localpart with the host's 
FQDN.
This is not a change because old mail servers do exactly this.

Look up either A or AAAA: A-only hosts would look up A, AAAA-only hosts 
would look up AAAA, dual-protocol hosts would look up both, and an 
address would be deliverable or not depending on who's sending.
This is a change because for the first time, an address can be valid 
despite there being neither an MX or an A RR for the domain. (I think 
this would break the MUA I'm using, actually. It has a typo check on 
To/Cc which uses an MX+A lookup.)
This is not a change because old mail servers (IPv4-only) do exactly 
this (look up A only, not AAAA, and not X25 not ISDN either).
Look up both A and AAAA: All hosts would have to look up both address 
types, and if they cannot reach the presumed destination, forward the 
mail to a dual-protocol relay.
This is a change because vast numbers of IPv4-only hosts today do not 
look up AAAA records when an MX lookup fails.
This is not a change because at least some of the software written in 
the past five years does this.
> A rather simple and straightforward task that the current draft 
> satisfies reasonably, modulo the usual wordsmith-hacking.
I read the -06 draft as permitting the last two alternatives ("A or 
AAAA", "A and AAAA"). 2821 itself says A.
> It appears that there has been a spontaneous desire for some spiffy 
> new goals to be overloaded onto that one, long-standing 
> *requirement*.
> This amounts to retro-active re-design on-the-fly.
We can't escape redesigning this. IPv6 forces us to.

I like falling back to A only. That imposes no new requirements on 
existing code or IPv4-only hosts, and it doesn't make unrealistic 
presumptions about what software runs on future IPv6-only devices.
Arnt