[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-26 00:58:49

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 will be delivered if there is an A RR and 
no MX RR for  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:   IN A   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:   IN A   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.


IETF mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
IETF mailing list