Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-08

From: John C Klensin <[email-masked]>
Date: Fri, 31 Dec 2021 15:01:40 -0500

EMAILCORE WG participants,

As promised, I have just posted
draft-ietf-emailcore-rfc5321bis-08.  With the exception of an
attempt to consolidate and clarify the discussion and "domain
name" and their usage, changes here reflect discussion and
agreement during the December 9 interim that have not been
reopened (and apparently left unresolved) on the mailing list.
See Appendix H.3.12 for details.  

In the process of doing the revision, I've discovered a few
small additional possible issues and done some rewriting, as
discussed below.  I have not added them to Appendix G because
they may be trivial and not worth fixing.  If people feel as if
they are issues, open a ticket and I'll pick them up in Appendix
G in -09.  They are:

(1) This is mostly just a heads-up for people suggesting new
text, but "host name" (with "primary" in front of, whatever that
means, is [still] defined in Section 2.3.5 as "a domain name
that resolves to an address RR".  As I have understood it, that
means no labels with CNAME records and no labels with only MX
and no A RRs.  We should be careful about accidentally
introducing the use of "host" or "host name" elsewhere.
Presumably, if there were DNS records of 

  example.com.   IN A  1.2.3.4
  example2.com.  IN A  1.2.3.4  and
  example.net.   IN A  1.2.3.4

(rather than using CNAMEs) one could talk about that host as
having one of those names as the "primary host name", but I can
find no support in RFC 1034 or any of its successors for that.

Or, if we means that restriction to address RRs to apply only to
"primary host names" (by some definition that does not appear to
be in 5321bis or referenced from it), does that usage require
clarification?  

If it is relevant, note that RFC 1034 talks about "hosts"
frequently but in ways that I believe always refers to things
with addresses and does not define "host name".  It does use the
term "host name" but, AFAICT, only for things that could have
been defined as hosts in the then-current HOSTS.TXT spec (RFCs
952 and 953), again implying things that have addresses with no
indirection, and in the context of the preferred syntax (Section
3.5, which affects their syntax, not their definition).  Section
5.2.1 talks specifically about "translating between host names
and addresses" but nowhere does there appear to be text implying
mapping between a host name and anything else.   There is more,
but you see the point.   Section 3.3 of RFC 1034 also rather
specifically discusses the syntax of mailbox naming.   And 1034
uses "primary" in the context of names only to equate "primary
name" with "canonical name" and in opposition to "alias" in the
discussion in Section 3.6.2.  

I have not checked the host table specs.  It is entirely
possible that they talk about a "primary name" or "primary host
name" to distinguish the first name on the line from aliases to
its right, but, if we need to depend on unreferenced text from
those specs in 2022, we are in serious trouble.

RFC 1123 does not appear to change any of the above.  However,
Section 2.2 says "Host domain names MUST be translated to IP
addresses..." which reinforces the above.  And RFC 8499
identifies (but does not fix) the confusion, explaining that
"host name" can also refer to the preferred name syntax (or not)
or the leftmost label in an FQDN.  And the only context in which
is uses "primary" is in reference to an authoritative server.
In other words, 8499 does not help.

Neither RFC 2821 nor 5321 update 1034 and I don't see anything
in what we have discussed that would require it, but we should
be quite careful about tampering that things that might affect
that text.

Conclusion: it is not clear what information or restrictions
"primary host name" provides that "host name" does not.  Perhaps
we should have dropped "primary" in RFC 2821 or 5321.  At this
point, while the text might be more clear with it, probably fear
of making seemingly trivial changes that might increase
confusion or cause unintended consequences argue against making
a change... and I'm kicking myself for the time wasted doing the
research.    Again, if you disagree, say something and open a
ticket.

(2) Section 2.3.11 says "address normally consists of user and
domain specifications".   Given other things we have tightened
up and the submission server cases, "normally" may be a source
of confusion.  Should it be dropped or the phrase changed to
"except in the special case of 'postmaster' (Section 2.3.5) an
address consists of user and domain specifications..." ?

(3) "Domain" is defined in 4.1.2 as 

   Domain    = sub-domain *("." sub-domain)
   sub-domain  = Let-dig [Ldh-str]

Section 2.3.5 clearly says "one or more components" and then
goes on to say
	"This makes the requirement, described in more detail
	below, that only fully-qualified domain names appear in
	SMTP transactions on the public Internet, particularly
	important where top-level domains are involved."

but does not spell out any issues with those names -- the
sentence was apparently intended to avoid a historical problem
in which single-label FQDNs have been confused with abbreviated
names (which 5321bis no longer addresses).  They have also, IIR,
caused considerable discussion within ICANN as to whether they
should be permitted in the root. 

However, 2.3.5 also said "Local nicknames or unqualified names
MUST NOT be used", which either prohibited single-label FQDNs or
contradicts other text in the section.  That sentence has been
removed from -08.

Should something further be said about this?  That sentence put
back in but "unqualified names" dropped from it?  FWIW, my
current guess is that the answer is "yes, more is needed" but in
the A/S, not 5321bis.  

(4) While Section 5.1 has been fairly significantly overhauled,
it may still be confusing and may need more work.   It appears
to me as if there was an attempt to distinguish between an SMTP
sender /client acting as a relay and something else, but the
only odd case I can identify would arise with an SMTP server
that identifies itself in an MX record for the original mailbox
domain and then decides to process the message by some non-SMTP
mechanism (e.g., forwarding direct by LMTP or some other means)
or to start rewriting addresses.  If that is the issue, it isn't
really "Locating the Target Host" (the title of 5.1) in the
usual sense and the relevant text should probably be somewhere
else.

As you have probably inferred from the above, I strongly suggest
careful reading of the new (-08) versions of Section 2.3.5 and
5.1.

Happy New Year!
    john