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

From: Alessandro Vesely <[email-masked]>
Date: Sat, 1 Jan 2022 18:35:41 +0100

Happy new year to all participants!

On Fri 31/Dec/2021 21:01:40 +0100 John C Klensin wrote:
> 
> (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..." ?

IMHO Section 2.3.11 is good as is.  However, a paragraph recalling that 
postmaster has to be accepted by the MTA software and its actual mailbox 
defined as an alias would be a cool improvement.  Perhaps, some subsection of 
Section 3.4 is a better place than 2.3.11 for that.

> (4) While Section 5.1 has been fairly significantly overhauled,
> it may still be confusing and may need more work.

Maybe it's me, but the following sentence seems to be wrong.  Its meaning is 
clear (to me) but the language sounds lacking:

                    If there are no records left at that point, it is an
    error condition, and a 5yz reply code generated (terminating the mail
    transaction) or the message MUST be returned as undeliverable.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Jan 2022 16:16:12 -0500

> Happy new year to all participants!

Happy new year to you and others too.

> IMHO Section 2.3.11 is good as is.  However, a paragraph
> recalling that postmaster has to be accepted by the MTA
> software and its actual mailbox defined as an alias would be a
> cool improvement.  Perhaps, some subsection of Section 3.4 is
> a better place than 2.3.11 for that.

That becomes a question of how often we should say it and when
repeating it becomes irritating noise.  Section 2.3.5 does
mention it, 4.1.1.3 talks about it again, and there is an
extended discussion along with an explicit "MUST be supported"
in 4.5.1.

Personal opinion: if we don't drop "normally", we are covered.
If we remove "normally", maybe we should mention the
"postmaster" case as I suggested in my note (maybe with
additional references to 4.1.1.3 and 4.5.1 but that could also
be getting tedious).  But going as far as adding a paragraph to
2.3.11 seems repetitive to me.  As to 3.4, I was already
concerned when I rearranged it that things were creeping in
there that don't belong.  While one could configure a local
system to treat "postmaster" or
"[email-masked]" as an alias for some local
user/administrator or set of them, there is nothing in the spec,
and probably should not be, that requires it to treated as
anything but the name of a local mailbox.  So, if more is
needed, not in 3.4.
 
>> (4) While Section 5.1 has been fairly significantly
>> overhauled, it may still be confusing and may need more work.
> 
> 
> Maybe it's me, but the following sentence seems to be wrong.
> Its meaning is clear (to me) but the language sounds lacking:
> 

It was moved from somewhere else and slightly enhanced. The text
was awkward in its original form and location, but is, IMO, no
worse in the current ones.  I considered some alternatives, but
they got a lot longer.  On the other hand, that might have just
been my lack of imagination when I was working on those sections.

Suggestions of replacement text welcome.  

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2022 17:07:35 -0500

It appears that John C Klensin  <[email-masked]> said:
>(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.

I fear that the least bad thing we can do is to leave host names alone
and say you can in principle send mail to any LDH domain that has an
address or MX or a CNAME that resolves to one.  This does not make
me happy but I can't think of any alternatives that don't make me
even less happy.

>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 

Yeah, that was the .CS problem

(which 5321bis no longer addresses).  They have also, IIR,
>caused considerable discussion within ICANN as to whether they
>should be permitted in the root. 

No contracted TLDs have an A or MX and I am pretty sure that none
of them are asking for an exception.  As we reported eight years
ago in RFC 7085, a fair number of ccTLDs do have an A or an MX
but as far as I can tell none of them actually accept mail except
perhaps .AI for the address n@ai.  Some are just strange, notably
that .GT and .TT had MX's pointed at Gmail for nearly a decade,
without as far as I can tell ever asking Google if that was a
good idea.

Can 5321bis just say that the domain must always be a FQDN and
an applicability statement say that single-component domains
don't work reliably in mail addresses?

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Jan 2022 17:39:22 -0500

--On Saturday, January 1, 2022 17:07 -0500 John Levine
<[email-masked]> wrote:

>> 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.
> 
> I fear that the least bad thing we can do is to leave host
> names alone and say you can in principle send mail to any LDH
> domain that has an address or MX or a CNAME that resolves to
> one.  This does not make me happy but I can't think of any
> alternatives that don't make me even less happy.

AFAICT, that is what the spec says now, the little peculiarity
that seems to ban single-label names notwithstanding.

>> in which single-label FQDNs have been confused with
>> abbreviated names 
> 

Not quite.  The CS problem, at least as I saw it play out, had
to do with abbreviating tom.cs.univ.edu, dick.cs.univ.edu, etc.,
as "tom.cs" and "dick.cs" to distinguish them from
tom.phy.univ.edu and dick.math.univ.edu.  When "CS" became a
valid TLD, the systems within that university that were calmly
mapping tom.cs to tom.cs.univ.edu prevented access to, e.g.,
jakub.cs.

> No contracted TLDs have an A or MX and I am pretty sure that
> none of them are asking for an exception.  As we reported
> eight years ago in RFC 7085, a fair number of ccTLDs do have
> an A or an MX but as far as I can tell none of them actually
> accept mail except perhaps .AI for the address n@ai.  Some are
> just strange, notably that .GT and .TT had MX's pointed at
> Gmail for nearly a decade, without as far as I can tell ever
> asking Google if that was a good idea.
> 

5321bis says that now.  And I agree that the A/S the right place
to address "don't work reliably".

thanks,
  john