[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-25 07:54:38
Bill Manning wrote:

FWIW, I'd like that...
Clarity can be established and interoperability _improved_ 
by limiting discovery to just A and MX records.  Perhaps a
note might be included that at some point in the future MX
records may become required.
Again, I have no problem with this approach if that's what
the consensus is.
...and that, too.  
so what is supposed to happen when I remove all "A" RR's from
my zones?

I'm not sure if we are talking about the same issue.  For SMTP
as it used to be since RFC 821 clients trying to find a server
accepting mail for x(_at_)y(_dot_)example look for y.example MX records,
and if they got something they locate corresponding servers
"by name" (A or AAAA), all details as explained in 2821bis.  

If they got nothing with their MX query RFC (2)821 and 2821bis
said that the client should try y.example directly "by name",
it could be an ordinary host with an SMTP server at port 25.

For various reasons mentioned in this thread this "fallback"
or "implicit MX rule" isn't a good idea today, and some folks
like to get rid of it for AAAA.   RFC 2821 didn't say that
this is also supposed to work for IPv6, and therefore 2821bis
isn't forced to stick to it.

The proposed note about the old A-fallback suggests that hosts
still relying on the "implicit MX" should get an explicit MX.

For the client almost nothing changes, it still tries q=mx,
now getting the y.example name, and then it can get the IP
"by name" (or use the additional info in the q=mx reply).

For the domain with only one SMTP host also almost nothing is
new, it is only encouraged (by the proposed note) to publish
this name in an MX record.

You are not supposed to remove any A records from your zones.
You are not supposed to do anything at all, because you have
MX records as it should be... :-)


IETF mailing list