[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-29 00:34:42
On Wed, 26 Mar 2008, Jim Fenton wrote:
I keep trying to understand why the SMTP use of AAAA records should be any
different than its use of A records.  Haven't heard a solid explanation,
nevermind seen consensus forming around it.

It seems there are two ways of looking at this:

(1) AAAA records in the IPv6 world should do exactly same things as A
records in the IPv4 world, so SMTP should look for an AAAA record in the
absence of an MX record, just as A records are used in the absence of MX

(2) Although some SMTP servers will continue to be found through A
records for legacy reasons, there is no longer a good reason for any new
server not to have a published MX record.  SMTP clients (senders) will,
of course, need to continue to look up A records, but since there is
currently no significant use of AAAA records for email routing, we
should not perpetuate this legacy in IPv6 as it is in IPv4.

These are both reasonable positions, but I'm in camp (2).  The
additional use of AAAA records for email address resolution would add
complexity to at least some implementations and test cases, and it
something that should never be needed:  v6 mail handlers will just
publish MX records.  There is probably a small DNS efficiency argument
as well, especially if the MX, A, and AAAA requests are not made together.

I agree with Jim's characterization and IMHO both positions are 

I also prefer (2) because I don't think the original "A fallback" was 
meant to stay there very long and we just never got around to 
deprecating that feature.  If you ask a random sampling of postmasters 
and DNS domain owners, I doubt many would even remember right off the 
bat that such a fallback exists.  Further, given that the feature in 
and of itself does not provide any additional value, I don't see why 
the practise should be propagated to IPv6.

But if the majority were to favour (1), that would be fine with me as 

Additionally I believe this is not an issue we as the IETF should get 
stuck at for a longer period.  Reaching closure, whichever decision it 
is, in the timescale of a couple of months, is IMHO better than a very 
strong consensus on the approach.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IETF mailing list