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 .
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.
If the implicit MX rule is depreciated for IPv6, the above won't be needed.
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