--On Sunday, July 31, 2016 12:21 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
If by "resolving CNAMEs", you mean doing DNS resolution to
obtain A or MX records ...
No, I meant this part of RFC 1123:
5.2.2 Canonicalization: RFC-821 Section 3.1
The domain names that a Sender-SMTP sends in MAIL and
RCPT commands MUST have been "canonicalized," i.e.,
they must be fully-qualified principal names or domain
literals, not nicknames or domain abbreviations. A
canonicalized name either identifies a host directly or
is an MX name; it cannot be a CNAME.
I think we all agree that was a mistake, and CNAMEs are fine
in MAIL and RCPT and you shouldn't mess with them, but I can't
find any place this advice has been explicitly deprecated.
Try Section 2.3.5 of RFC 5321 (or its predecessor in 2821, which
was a tad less explicit):
# Only resolvable, fully-qualified domain names (FQDNs) are
# permitted when domain names are used in SMTP. In other
# words, names that can be resolved to MX RRs or address
# (i.e., A or AAAA) RRs (as discussed in Section 5) are
# permitted, as are CNAME RRs whose targets can be resolved,
# in turn, to MX or address RRs. Local nicknames or
# unqualified names MUST NOT be used. There are two
# exceptions to the rule requiring FQDNs:
PS: Even 5321 says the EHLO argument can't be a CNAME.
Yes, that is the bulleted first exception pointed to above.
With apologies to those with whom I just went through this on
another list, the only ambiguity I can find in that is whether
CNAME chains, e.g.,
a.example.com. CNAME b.example.com.
b.example.com. CNAME c.example.com.
c.example.com. MX 0 smtp.example.com.
is permitted My sense is that it would be at least, a dumb
practice even if the above text does not prohibit it. But I
think the intent of the above-quoted text is, in fact, to
prohibit it or at least to justify SMTP clients and servers
treating the situation, if encountered, harshly.
Section 1.2 of RFC 5321, second full paragraph, is also fairly
explicit about its relationship to RFC 1123 mail transport
material. So, with the CNAME chain question as a possible
exception, I think we really did manage to be explicit enough in
this particular case. YMMD, in which case specific suggestions
for what needs to be fixed and how to fix it would be welcome.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp