ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] MX pointing to CNAME

2016-08-24 11:46:03
On 8/24/2016 11:41 AM, John C Klensin wrote:

--On Wednesday, August 24, 2016 12:18 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:

Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:

but I'd like to hear your opinion on the issue.

MX -> CNAME is not allowed according to the RFCs but sensible
implementations support it in the obvious way. There was a
massive flamewar on this topic during the work on RFC 5321
leading to some awkward verbiage in section 5.1:

    Any other response, specifically including a value that
will return a    CNAME record when queried, lies outside the
scope of this Standard.

In defense (or at least explanation) of that awkwardness (and
several similar cases), what, IMO, 5321 really should have said
is that am implementation utilizing, rather than refusing to
follow, such a MX -> CNAME -> <something> set of DNS entries was
not conforming to the standard and that anyone who did it anyway
needed to be extra careful to be sure they didn't get tangled up
in DNS entry loops (e.g., MX -> CNAME1 -> CNAME2 -> CNAME1) or
other weirdnesses (e.g.,  MX1 -> CNAME1 -> MX2 -> ???) and to
have good diagnostics if they did.

An AD or two were determined to not let us say the first
(inconsistent with the 2119 normative statements/position) and
sorting out exactly how to say the second would have taken a lot
of time and might have produced another flame war.    So the
position taken in 5321 is "outside the scope of the Standard"
or, less politely, "we aren't going to tell you what the issues
are with that stupid and risky thing or how to do it if you
decide to, so, if you do, you are on your own".

And yes, this too is on the list of reasons I've had trouble
getting motivated about 5321bis.

     john

On a related note, lately I've been seeing more MX records pointing to "Localhost" and "No.Longer.available" exchange host names. At least with LocalHost, it resolves to something but you have to watch for the internal SMTP loop backs. I don't see RFC5321 guidance to best handle the LocalHost MX exchanges. Loop Detection (via Received lines) is the suggested way, but I noticed a major DKIM signing loop as well so I added code to skip the MX "LocalHost" exchange on the outbound side and force a bounce.

I prefer the NXDOMAIN approach if people are going to be creating "fake" "Stub" MX exchange records rather than getting rid of them.

--
HLS



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp