> At 19:32 25-03-2008, Bill Manning wrote: > > er... what about zones w/ A & AAAA rr's and no MX's? > > when I pull the A rr's, you are telling me that SMTP > > stops working? That is so broken. > > SMTP will still work as the above case is covered by the implicit MX rule. > > At 20:02 25-03-2008, Willie Gillespie wrote: > >I don't think disabling MX lookups altogether is a smart move. There > >could be a variety of reasons I want my A or AAAA records to point to > >one server, and my mail to go to a different server altogether. > > The draft is not proposing that MX lookups should be disabled. > > The definition of "Address records" was clarified in the draft to > cover AAAA RRs. The objection raised was about that. > > In an IPv4-only world, the implicit MX rule is viewed as a useful > feature by some. Mail notifications (Cron, web server generated) > sent from core3.example.com will be delivered if there is an A RR and > no MX RR for core3.example.com. In an IPv6-only world, the feature > can be useful as well. > > Some people mentioned that this is a legacy feature. There are > domains which are used to provide web services only. These domains > do not wish to receive mail. To get around the implicit MX rule, they use: > > example.net IN A 192.0.2.1 > example.net IN MX 0 . Which is not documented in any RFC despite being a good idea. It is easy to turn "MX 0 ." into "This domain doesn't support email" as "." is not confusable with a hostname. There is no reason to look up addresses records for "." > or else they point the MX to an invalid hostname: > > example.com IN A 192.0.2.2 > example.com IN MX 0 dev.null. Which could just be a misconfiguration. You still have to look up addresses for "dev.null". > If the implicit MX rule is depreciated for IPv6, the above won't be needed. It's still needed to prevent the A lookup. > The implicit MX rule creates an ambiguity during the transition from > IPv4 to IPv6. That's discussed in Section 5.2 of the draft: > > "The appropriate actions to be taken will either depend on local > circumstances, such as performance of the relevant networks and any > conversions that might be necessary, or will be obvious > (e.g., an IPv6-only client need not attempt to look up > A RRs or attempt to reach IPv4-only servers). Designers of > SMTP implementations that might run in IPv6 or dual stack > environments should study the procedures above, especially the > comments about multihomed hosts, and, preferably, provide mechanisms > to facilitate operational tuning and mail interoperability between > IPv4 and IPv6 systems while considering local circumstances." > We could look at the question by asking whether the fallback MX > behavior should be an operational decision. But then we would be > treating IPv4 and IPv6 differently. > > Regards, > -sm > > _______________________________________________ > 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