> 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 > <dotis@xxxxxxxxxxxxxx> 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 > > IETF@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf