> 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
> <[EMAIL PROTECTED]> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ietf
>
>
>
>
> _______________________________________________
> IETF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
IETF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
