Re: Last Call: draft-klensin-rfc2821bis

[Mark Andrews <[e-mail]>]

> 
> 
> --On Wednesday, 26 March, 2008 14:26 -0700 "Hallam-Baker,
> Phillip" <[e-mail]> 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

	Doug's issue, which sparked off this latest debate, would
	be addressed by codifying "MX 0 .".  This would allow hosts
	to say that do not accept email and any email (MAIL FROM)
	claiming to come from such a domain to be dropped in the
	SMTP session.

	Note: this does not prevent email coming from such hosts
	as it would be applied to "MAIL FROM" not "HELO".  You could
	still get mail from your fridge, it would just not be from
	fridge@<hostname>. You would have to configure the email
	address like you do today when you use your ISP's mail
	domain.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf