Re: houston.rr.com MX fubar?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Thu, 17 Jan 2008, Mark Andrews wrote:
> >
> > 	a) when RFC 2821 was written IPv6 existed and RFC 2821 acknowledged
> > 	   its existance.  It did DID NOT say synthesize from AAAA.
> 
> RFC 2821 only talks about IPv6 domain literals. The MX resolution
> algorithm in section 5 is written as if in complete ignorance of IPv6 so
> it is reasonable to interpret it in the way that RFC 3974 does. If you
> wanted to rule out MX synthesis from AAAA then it should have been written
> down ten years ago. It's too late now.

	We 99.9% of the time write down what we should do.  We very
	rarely write down what we shouldn't do. 

	Just because *you* think it was written in complete ignoranance
	doesn't mean that it was.  If you follow what is written down
	there NOTHING breaks.  If you think you know better then things
	break.

> > > They have already been upgraded in this way. Even without fallback-to-
> > > AAAA, they have to be upgraded to handle IPv6 anyway, because the IPv4
> > > MX lookup algorithm breaks as I described in
> > > http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html
> >
> > 	MX additional section is a optimization.  The lack of AAAA or
> > 	A records is NOT a bug.
> 
> Perhaps you could explain why the problem I described in the URL above
> isn't actually a problem.

	It is not as problem.  Additional records have ALWAYS been
	optional.  Any MTA that doesn't look for address records
	if they are missing from the additional section is *broken*
	and won't work in a pure IPv4 world let alone a mixed
	IPv4/IPv6 world.
	
	The few cases where there have been such MTA's they get
	fixed / replaced because they fail to deliver email.  I've
	seen reports that a nameserver was broken because it failed
	to add additional records (usually because they were not
	in the cache).  Once you point out that it is the MTA that
	is broken that is the last of the complaint.

	There will always be developers that fail to read the
	specifications.  When the complaint comes that something
	is broken you bring out the specification and point out the
	fault.

	Mark

> Tony.
> -- 
> f.a.n.finch  <dot@xxxxxxxx>  http://dotat.at/
> FISHER: WEST 4 OR 5, BACKING SOUTHEAST BECOMING CYCLONIC 5 TO 7, PERHAPS GALE
> 8 LATER. ROUGH. RAIN LATER. MODERATE OR GOOD.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]