ietf
[Top] [All Lists]

RE: Last Call: draft-klensin-rfc2821bis

2008-03-27 15:18:01


--On Wednesday, 26 March, 2008 14:26 -0700 "Hallam-Baker,
Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:

 
I don't undestand the reasoning here.
 
My understanding is that we implicitly deprecated receivers
relying on fallback to A in 2821. 

We did no such thing.

Section 5 makes it clear
that you look for MX first and that MX takes priority.  

Yes.  And that has been the rule since MX records were
introduced, a rule that was reinforced by RFC 1123.  This is not
news.  It has also been the case --since RFC 974, over 22 years
ago-- that, if the MX lookup fails, one looks for an A RR. RFC
2821 changed nothing in that regard.  People have repeated that
to you multiple times.  

It is thus not compliant to look at AAAA records today and I
see no reason to change this in the future.

This is also not true, but the reason is more subtle.  If 2821
said "don't look for an AAAA record and use it as a default"
then, certainly, looking for it after the MX lookup failed would
not be non-complaint.  But it says no such thing.   

Instead, there is a question of whether the text in 2821 should
be interpreted as "look for address records if the MX fails" or
"look for a A RR if the MX fails and, if it isn't found, give
up".  The first interpretation is strongly supported by general
advice to implementers of applications to make IPv6 behave as
much like IPv4 as possible unless there is a clear reason to not
do so.  Either interpretation is plausible, and we've got
examples of running code that implements the former.  There may
also be cases of the latter in production servers, but we
haven't asked and I don't, personally, know of any.  Leaving the
ambiguity, long-term, is not reasonable.

So 2821bis does what a "bis", and a document going for Draft
Standard, is supposed to do, and that is reflect existing
practice and clear up ambiguities.  Saying nothing is not, IMO,
an option.  Deprecating the A MX default is not an option.  And,
given current practice, prohibiting the current default is, IMO,
inappropriate unless real harm to the mail system is
demonstrated.  No one has done that, at least in any message
I've read.  

That current default --both types of address records are
available-- is also, by far, the safer one if some
implementations assume that the MX is required and others assume
that it is not. One could make a different argument, but whether
to permit or prohibit using an AAAA record for an MX default is
the only question.  And we cannot say "MAY" because it would
guarantee inconsistent and unpredictable behavior.

But, whatever the decision, it is highly constrained.  Arguing
on the basis of deprecation of a feature that did not occur, or
arguing for removal of a function on which many thousands of
hosts are depending is, at best, a waste of everyone's time.

Mail is a service lookup, not a host name lookup. Support for
use of fallback to IPv4 host name lookup is a historical
accident due to the fact that the distinction was not
understood at the time. We do not require IPv6 host name
fallback, 

This, to put it politely, is nonsense.  I don't know that I can
say anything else without violating IETF list norms for postings.

IPv6 host name fallback has a significant cost that
will have immediate impact on every mail service lookup that
is compliant.

No.  At most it will have a one DNS lookup impact on mail server
lookups that are not associated with MX records.  If the sender
prefers IPv4 over IPv6, it will have that impact only if there
is no A record present and there are some other valid records
for the domain name.  If the sender prefers IPv6 over IPv4, then
it adds nothing.  

In an IETF that believes the potential recursion of URNs and
NAPTR records is reasonable, it is really hard for me to get
excited about that one possible extra lookup.   YMMD, of course.

   john



_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf