Subject: [Emailcore] The RDATA of a DNS record with RRTYPE=MX

From: John C Klensin <[email-masked]>
Date: Fri, 04 Feb 2022 14:42:04 -0500

Hi.

I have recently had it drawn to my attention that the rule
established as "This can be avoided" in RFC 974, and stated very
clearly in RFC 1123, that the domain in the RDATA for an MX
record MUST resolve to an address record and not a CNAME is not
crystal clear in RFC 5321 or in anything I/we have done so far
in 5321bis.   The current discussion in Section 2.3.5 of the
latter talks about what domain names are allowed to be but is
really about domain names in addresses, e.g., MAIL, RCPT and, in
principle, EHLO and VRFY, arguments, not in MX targets.  It says 

	"For example, a domain may refer to a host alias (label
	of a CNAME RR) or the label of Mail eXchanger records"

I believe we thought that and the surrounding text was clear but
it may have been a tad too subtle.  To save someone else doing
the research I just did, primary host names are explicitly
required in domain names used in EHLO commands (See Section
2.3.5 of rfc5321bis).

We reviewed the prohibition on CNAMEs in MX RDATA in DRUMS and
again in YAM and decided to leave that prohibition unchanged.  I
hope we do not have to go through that discussion again.
Assuming we do not, I propose that, for the avoidance of any
doubt, we make things clear by making a small change in the
(revised in -09) Section 5.1:

Old:
	When a domain name associated with an MX RR is looked up
	and the associated data field obtained, the data field
	of that response MUST contain a domain name that
	conforms to the specifications of Section 2.3.5.

New:
	When a domain name associated with an MX RR is looked up
	and the associated data field obtained, the data field
	of that response MUST contain a domain name that
	conforms to the specifications of Section 2.3.5.  That
	domain name also MUST resolve to a primary host name,
	i.e., it is not allowed to be an alias.

If anyone has strong objections to that change (which, again, is
a clarification, not a substantive change to what SMTP allows),
please speak up and explain your reasons.

   john

---

From: "Peter J. Holzer" <[email-masked]>
Date: Fri, 4 Feb 2022 21:25:52 +0100

> 	i.e., it is not allowed to be an alias.

I would prefer "... also MUST be a primary host name ..." as in the
penultimate paragraph of section 2.3.5.

"Resolve to  a primary host name" for me implies that a DNS lookup would
be necessary to get the primary host name.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [email-masked]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Feb 2022 16:07:35 -0500

--On Friday, February 4, 2022 21:25 +0100 "Peter J. Holzer"
<[email-masked]> wrote:

> I would prefer "... also MUST be a primary host name ..." as
> in the penultimate paragraph of section 2.3.5.
> 
> "Resolve to  a primary host name" for me implies that a DNS
> lookup would be necessary to get the primary host name.

Definite improvement.  Thanks.

However, I had not read the subsequent paragraph (the one
starting "When a domain name associated...") closely enough
(this is why I ask the WG before making this sort of change).
It already asks that the domain name be queried (the DNS lookup
to which you object) and then handwaves the CNAME issue ("Any
other response, specifically including a value that will return
a CNAME record when queried, lies outside the scope of this
Standard." and then points to RFC 2181.  I don't know whether
the several updates to 2181 clouds that advice.  More important,
continuing to reference it from 5321bis will take us into
downref territory.  

So, I'm not going to try to write text right now and would
appreciate input and advice from you and others.  However, given
recent pushback on another spec that said "MUST do this but, if
you don't then...", I'm inclined to see if we can clean things
up considerably.    In particular, if "MUST be a primary host
name" is good enough, I wonder if we can eliminate most or all
of that subsequent paragraph rather than dragging things out.

thanks,
   john

---

From: Giovanni Bechis <[email-masked]>
Date: Tue, 15 Feb 2022 16:13:49 +0100

> of that subsequent paragraph rather than dragging things out.
I think that specifying that if "MUST be a primary host name" is
clear enough and at least a part of the subsequent part can be removed.

 Giovanni