Re: Last Call: draft-klensin-rfc2821bis

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
> records.
>
> (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 
reasonable.

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 
well.

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