> 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
> [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
