Re: Last Call: draft-klensin-rfc2821bis

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf