Re: Last Call: draft-klensin-rfc2821bis

[Mark Andrews <[e-mail]>]

> Doug,
> 
> I'm sorry, but I can't understand what you are talking about.
> That is at least in part because you are using vocabulary that
> does not appear in 2821bis or other common IETF standardized
> email technology.  You also seem to be making assumptions that
> aren't part of the 2821 model (whether they are valid or not).
> 
> In 2821 and its predecessors, MX records and the associated
> preferences were specified as the preferred mechanism for
> finding the next-hop SMTP server.   There was also a special
> case, originally part of a transition mechanism for RFC 974,
> that, if no MX records were found for a particular name, one or
> more A RRs would be located for the name and treated as if they
> were the targets of an MX record with preference zero.
> 
> While various implementations have been more permissive over
> time, the data field in an MX RR has always been expected to be
> a DNS name that would, in turn, resolve to one or more A RRs.
> 
> That is the mechanism that has been used for Internet mail over
> IPv4 for many years.  
> 
> Now, as far as I know, 2821bis makes only two changes in this
> area.  The first is to be explicit about the expected data value
> in MX records.  The second is to explicitly specify that names
> with AAAA records are permitted as an alternative to names with
> A records.  Without that change, which was anticipated in 2821
> but not as explicit because of the state of development
> experience at the time, it would be impossible to run SMTP over
> IPv6 without local imaginative extensions of the standard.
> 
> It does not provide for an extension of the "if there are no MX
> records, look for an A RR" model because the mailing list
> concluded that the transition mechanism was not needed for IPv6
> transition and because it would have required the standard to
> specify preferential rules for A and AAAA records.   It seemed
> much better to let those configuring mail systems to use the
> existing MX preference mechanism to specify what treatment they
> thought appropriate.
> 
> That is really all the material to which you refer does (or
> changes).
> 
> Now, are you suggesting that:
> 
> (1) It is time to abandon the current Internet email fabric in
> terms of, e.g., your "notify and retrieve" proposals?
> 
> (2) That we should not specify operation of SMTP over IPv6 but
> either prohibit that or leave it to the imagination?
> 
> (3) That MX records are so useless that we should deprecate them
> and embark on some other "discovery" mechanism rather than
> updating 2821?
> 
> (4) Something else?
> 
>       john

	I think Doug is saying don't let domains with just AAAA
	records be treated as valid RHS of email.  Today we
	have to add records to domains with A records to say that
	these are not valid RHS of email.  With MX synthesis
	from AAAA you create the same problem for domains with
	AAAA records.

		user@<A record owner>
		user@<MX record owner>
		user@<AAAA record owner>  * don't allow this.
 
	Mark
 
> --On Thursday, 20 March, 2008 09:33 -0700 Douglas Otis
> <[e-mail]> wrote:
> 
> > While this response may be a bit late, the change in section
> > 5.1   indicating SMTP server discovery now explicitly supports
> > IPv6 address   records represents a significant change from
> > RFC2821.
> > 
> > While a desire to retain current practices has some
> > justification,   extending an already dubious and archaic
> > practice to the explicit use   of IPv6 raises significant
> > questions.
> > 
> > The level of misuse afflicted upon SMTP often results in an  
> > exploration of DNS SMTP discovery records to determine whether
> > a   purported domain might be valid in the forward direction.
> > To remain   functional, reverse DNS checks are often avoided
> > due to the poor level   of maintenance given this zone.  A
> > move to deprecate A records for   discovery when performing
> > these checks to ascertain domain validity   would favourably
> > impact the level of undesired transactions.  To   combat
> > rampant domain spoofing, some domains also publish various  
> > types of SMTP related policy records.  To counter problems
> > related to   wildcard policy records, a lack of policy may be
> > conditioned upon   presences of possible SMTP discovery
> > records.
> > 
> > Adding IPv6 to the list transactions needed to qualify SMTP
> > domains   that is predominately triggered by geometrically
> > growing levels of   abuse or misuse appears to be a remarkably
> > poor choice.  To suggest a   domain might reply upon this
> > mechanism again appears to be remarkably   poor advice.
> > Reliance upon a communication system should not be  
> > predicated upon such a questionable mechanisms.  During the
> > next   disaster, would you want FEMA to not use MX records or
> > to depend upon   IPv6 address records?  Not including IPv6 as
> > a discovery record would   better protect networks in the face
> > of growing misuse of SMTP while   also better ensuring the
> > integrity of SMTP.
> > 
> > -Doug
> > _______________________________________________
> > IETF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> 
> _______________________________________________
> IETF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
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