Re: Last Call: draft-klensin-rfc2821bis

[Mark Andrews <[e-mail]>]

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf