--On Thursday, 01 April, 2021 20:24 -0400 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
It appears that Sam Varshavchik <mrsam(_at_)courier-mta(_dot_)com> said:
My viewpoints are somewhat dated. The persona-non-grata
status of MXs pointing to CNAMEs – that verbiage appears
to be new to the current SMTP standard, I checked and did
not find any equivalent language in the prior one; so my
implementation reflected that.
The author of 5321 is on this list so perhaps he recalls what
the motivation for the change was. I'm sure it wasn't
accidental.
No, and my apologies if parts of what follow sounds like a rant.
Actually, the rule is in RFC 1123 Section 5.2.2 with the text
in5321 as just a clarification. My memory of that part of the
discussion in the late 1980s is very vague, but I think that it
includes some concern about the combination of performance, what
action should be taken on a CNAME loop if one were detected, and
the whole situation being error-prone. That combines with the
obvious: because users are not expected to see those target
names, there is no good reason to have them be anything but
final (1123 says "canonical") names. Approximately the same
reasoning applies to the DATA of one MX record, when resolved,
pointing to another MX record with the addition of questions of
what would then be two sets of priorities would mean in that
case.
Once upon a time, we used to try to design protocols so that the
functionality that was needed was available but that the number
of different ways to do something was minimized, more or less on
the assumption that two or three ways to do the same thing
created opportunities for errors, vulnerabilities, and/or the
need to make the specifications to make things more complicated
by considering the interactions. So, given that there is no
real reason why an MX RR should point to either another MX RR, a
CNAME RR, or, for that matter, TXT or anything else, why allow
it.
Noting my recent comments about how 2821 (and hence 5321 and the
evolving 5321bis) were assembled, 5321 is inconsistent about
where it says "don't do that", "if you do that, bad things may
happen and what they are and what you should do about them lies
outside the specification", and "if you decide to violate the
rule in Section X.Y.Z, then you should...". In general, there
are reasons for each case, but there are probably exceptions.
But the bottom line here, as John and others have suggested, is
that the right answer to the question in the subject line is
that an SMTP sender encountering an MX record whose DATA points
to a CNAME (or anything other than an address record) should
just treat the message as undeliverable, a popular
implementation or two notwithstanding. And worrying about
validating the clearly invalid just does not make a lot of sense.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp