Subject: [Emailcore] rfc5321bis-04 and notes from minutes

From: John C Klensin <[email-masked]>
Date: Sun, 03 Oct 2021 00:30:07 -0400

Hi.  Pete getting the new version of 5322bis posted motivated
me a bit although I've been working on this on and off since
the meeting during IETF 111.

As I sort of promised (although much later than I intended) I
have gone through the minutes [1], updated rfc5321bis
accordingly, and posted a new version (-04). For the avoidance
of doubt, helping the co-chairs map out what to do next, and in
the hope that people will catch errors or omissions and tell
me, The bullet points from the minutes that seem to apply to
5321bis are below ("###" is a point from the minutes; "-->"
identifies an action in -04 or comment). Any document
references there are to -04. 

The "no mail accepted" issues are discussed in a separate note.

Note that several people volunteered to post text or
suggestions/ comments that have not appeared: consider
yourselves reminded.

best,
   john

[1]
https://datatracker.ietf.org/meeting/111/materials/minutes-111-emailcore-00 

   ---------------

Note that this list, derived from the minutes, is complementary
to, but does not replace, the change log in Appendix H.3.8 of
-04.

### Trace header fields
   --> Agreed at meeting that lone Return=path is ok.  There
      does not seem to be a restriction in 5321bis to be
	  removed. 

### Can other fields exist between Trace and Resent-* fields?
   --> Meeting conclusion: no change needed in 5321bis

### RFC5321 beter(sic) definition of trace fields
### Slide 11 (3.6.3 and 7.6) Better definition of trace header
   fields
   --> Awaiting clear instructions from WG.

### Ticket 20: removal of SEND,SAML,SOML
    --> Done (I think -- see note in G.7.13)

### Ticket 14: Review of size limits
   -->  Ticket closed, no action

### Extension keywords starting with X
### private-use commands with X
### change "MUST be registered unless X" to SHOULD be
    registered 
   --> Awaiting mailing list discussion and proposed text from
      Barry

### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM
   --> Done.  Did not remove quite as much as suggested; want
   to get a consensus call/ ruling from the chairs.

### Ticket 19 - requirements for domain name and IP address in
   EHLO 
  --> Deferred to mailing list.  Meeting actions to Viktor and
     maybe Allessandro.  Inserted note about pointer to the
	 A/S.

### Use of top-level domains where FQDN is expected not
interoperable
  --> Deferred, awaiting text.  Johne Levine took action
     during meeting

## AOB (Ticket #8 - IANA registry)
  --> Based on message thread ("Subject: Re: [Emailcore] 
     Ticket #8: Need a registry of header fields that are Ok
	 to add after submission".  Discussion on list between
	 2021-07-27 and 2021-08-05), while we seem to agree on the
	 principle, no conclusion has been reached about where the
	 registry goes nor about which document should do it. No
	 5321bis action in the -04 draft.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Oct 2021 18:04:34 +0200

On Sun 03/Oct/2021 06:30:07 +0200 John C Klensin wrote:
>       maybe Alessandro.  Inserted note about pointer to the
> 	 A/S.

The HELO name is also referenced in the 6th paragraph of Section 4.1.4 "Order 
of Commands":

    An SMTP server MAY verify that the domain name argument in the EHLO
    command actually corresponds to the IP address of the client.
    [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP
    server MAY verify that the domain name argument in the EHLO command
    has an address record matching the IP address of the client." ]]
    However, if the verification fails, the server MUST NOT refuse to
    accept a message on that basis.  Information captured in the
    verification attempt is for logging and tracing purposes.  Note that
    this prohibition applies to the matching of the parameter to its IP
    address only; see Section 7.9 for a more extensive discussion of
    rejecting incoming connections or mail messages.

That text is inconsistent with Section 2.1 "Handling of the Domain Argument to 
the EHLO Command" of the A/S:

    If the "Domain" argument to the EHLO command does not have an address
    record in the DNS that matches the IP address of the client, the SMTP
    server may refuse any mail from the client as part of established
    anti-abuse practice.

Both paragraphs refer to forward DNS matching with the client's IP address, but 
there are other checks that mail servers frequently carry on, such as reverse 
DNS matching (Section 3 of RFC 7601) and SPF's "HELO" identity check (Section 
2.3 of RFC 7208).  For this spec to be generally applicable, I'd strike most of 
the 6th paragraph of Section 4.1.4.  For example, reducing it to a two-liner:

    An SMTP server MAY verify the domain name argument in the EHLO
    command.  See A/S [xx] for further discussion.

Note that such kind of statement may make the preceding 5th paragraph somewhat 
puzzling if it isn't obvious to the reader that address literals are accepted 
for authenticated submission only (on whatever port).  Since this specification 
also contains information that is important to its use as mail submission, it 
may be worth to make that point explicit.

Best
Ale
--

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 04 Oct 2021 15:15:01 +0100

Hi John,
Thank you for the summary. I commented on your list below.

> https://datatracker.ietf.org/meeting/111/materials/minutes-111-emailcore-00 

Right. I think a change in 5322bis is needed now. I will followup separately.

>    --> Awaiting clear instructions from WG.

I think there were specific suggestions in my slides for IETF 111, but I will followup on this separately.

>     --> Done (I think -- see note in G.7.13)

There is one more change to be done, as discussed on the mailing list. I will send you a separate email.

>    -->  Ticket closed, no action

Yes.

>    --> Awaiting mailing list discussion and proposed text from

I just reminded Barry as well.

>    to get a consensus call/ ruling from the chairs.

Todd is in charge of this ticket, I will ask him to comment.

>      maybe Allessandro.  Inserted note about pointer to the

I think there is specific text suggested in the ticket already. Todd should comment as the ticket owner.

>   --> Deferred, awaiting text.  Johne Levine took action

I think this was addressed in A/S as per suggestion from John L.

> 	 5321bis action in the -04 draft.  

I will review and followup on this.

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Oct 2021 10:20:55 -0400

Alessandro,

I'm going to sit back for a while and let the WG discuss most of
the issues you have raised (or decide to not do so).  However,
one comment:

At least from my perspective, the reason the charter was written
to give priority to 5321bis and 5322bis (I note the charter was
never revised to include benchmarks) was, in large measure, to
avoid getting into race conditions or other arguments about
inconsistencies between 5321bis or 5322bis and the A/S.  So I
would hope that we can concentrate on what the two base
documents should say (or not say) and getting that right and
inserting forward pointers to the A/S when appropriate.  We
should, I think, concentrate on finishing those base docs and
then bringing the A/S into alignment with both those forward
pointers and the base document text.

If others (especially the WG Chairs) disagree, we should
probably get that sorted out really soon.

best,
   john

--On Sunday, October 3, 2021 18:04 +0200 Alessandro Vesely
<[email-masked]> wrote:

>>    --> Deferred to mailing list.  Meeting actions to Viktor
>>    and maybe Alessandro.  Inserted note about pointer to the
>> 	 A/S.
> 
> 
> The HELO name is also referenced in the 6th paragraph of
> Section 4.1.4 "Order of Commands":
> 
> That text is inconsistent with Section 2.1 "Handling of the
> Domain Argument to the EHLO Command" of the A/S:
> 
> Both paragraphs refer to forward DNS matching with the
> client's IP address, but there are other checks that mail
> servers frequently carry on, such as reverse DNS matching
> (Section 3 of RFC 7601) and SPF's "HELO" identity check
> (Section 2.3 of RFC 7208).  For this spec to be generally
> applicable, I'd strike most of the 6th paragraph of Section
> 4.1.4.  For example, reducing it to a two-liner:
> 
> Note that such kind of statement may make the preceding 5th
> paragraph somewhat puzzling if it isn't obvious to the reader
> that address literals are accepted for authenticated
> submission only (on whatever port).  Since this specification
> also contains information that is important to its use as mail
> submission, it may be worth to make that point explicit.
> 
> 
> Best
> Ale
> --

---

From: Pete Resnick <[email-masked]>
Date: Mon, 04 Oct 2021 09:37:42 -0500

>  Right. I think a change in 5322bis is needed now. I will followup 

I believe the current text in 5322bis-02 is what we agreed to, and 
anything else was left for the AS. Do I have that wrong?

pr

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 04 Oct 2021 16:40:14 +0100

Hi Pete,

Your change was almost perfect ;-). But see below,

On Mon, Oct 4, 2021, at 3:37 PM, Pete Resnick wrote:
>>> Trace header fields
>>> Can other fields exist between Trace and Resent-* fields?
>>> 
> I believe the current text in 5322bis-02 is what we agreed to, and anything else was left for the AS. Do I have that wrong?
> 
IMHO, you've included a change that was not agreed. In Section 3.6 ABNF of "fields" you remove "*optional-field" after "trace". I think it should be added back, as we had a discussion about whether optional-fields which are not trace fields are allowed between trace section and resent header fields. I believe the discussion at IETF 111 concluded that allowing for this is fine.

Best Regards,
Alexey

---

From: Pete Resnick <[email-masked]>
Date: Mon, 04 Oct 2021 12:04:47 -0500

On 4 Oct 2021, at 10:40, Alexey Melnikov wrote:

> IMHO, you've included a change that was not agreed. In Section 3.6 
> ABNF of "fields" you remove "*optional-field" after "trace". I think 
> it should be added back, as we had a discussion about whether 
> optional-fields which are not trace fields are allowed between trace 
> section and resent header fields. I believe the discussion at IETF 111 
> concluded that allowing for this is fine.

Ah, OK. I misunderstood. Just to confirm: Though optional-field is now 
allowed *in* trace, and therefore syntactically can appear between 
blocks of trace and resent (because return and received are optional in 
trace), we also want optional-field to syntactically appear *between* 
trace and resent to make it clear that there can be optional-fields that 
are part of trace and optional-fields that are not part of trace. That 
seems perfectly reasonable. I just want to make sure what was agreed.

pr

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 04 Oct 2021 18:15:10 +0100

Hi Pete,

> seems perfectly reasonable. I just want to make sure what was agreed.

Exactly!

Best Regards,
Alexey

---

From: Todd Herr <[email-masked]>
Date: Tue, 12 Oct 2021 10:00:32 -0400

On Mon, Oct 4, 2021 at 10:15 AM Alexey Melnikov <[email-masked]>
wrote:

> I am happy with the current text for the second paragraph of section
3.6.2, which now reads:

This specification does not deal with the verification of return
paths. Server efforts to verify a return path and actions to be
taken under various circumstances are outside the scope of this
specification.

> should comment as the ticket owner.
Ticket 19 as currently written proposes the following...

Replace this paragraph from section 4.1.4 of RFC 5321:

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9
<https://datatracker.ietf.org/doc/html/rfc5321#section-7.9> for a more
extensive discussion of
   rejecting incoming connections or mail messages.

With this:

An SMTP server MAY verify that the domain argument in the EHLO command has
an address

record matching the IP address of the client.

There is other proposed text in the ticket, text proposing action to take
if the verification fails, text for which there is not yet consensus on its
content, but text for which this thread
<https://mailarchive.ietf.org/arch/msg/emailcore/3sY7hkk5ZAKR7zt40ucV3CZZXVQ/>
seemed
to arrive at the consensus that anything said on the topic should be in the
Applicability Statement, and not 5321bis. I anticipate further discussion
on *that* text, obviously.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 13 Oct 2021 10:18:29 +0200

On Tue 12/Oct/2021 16:00:32 +0200 Todd Herr wrote:
> On Mon, Oct 4, 2021 at 10:15 AM Alexey Melnikov wrote:
>>
> I am happy with the current text for the second paragraph of section 3.6.2

+1, neat and concise.

>     An SMTP server MAY verify that the domain argument in the EHLO command
>     has an address record matching the IP address of the client.
> 
> seemed to arrive at the consensus that anything said on the topic should be
> in the Applicability Statement, and not 5321bis. I anticipate further
> discussion on *that* text, obviously.

The thread pointed shows a generic disagreement on the exact checks carried out 
by various servers, possibly having different criteria for public Internet, 
known hosts, and private networks, all of which implement SMTP.

I re-propose the text I already proposed:

      An SMTP server MAY verify the validity of the domain name argument in
      the EHLO command.   See [A/S] for further discussion.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Oct 2021 19:21:10 -0400

Alexey, 

Again thanks for the comments and sorry for the delay in getting
to this.  Most comments that have been acted on or that do not
involve further action in 5321bis have been removed for brevity.

--On Monday, October 4, 2021 15:15 +0100 Alexey Melnikov
<[email-masked]> wrote:

>...

Another reminder :-(

>...
> There is one more change to be done, as discussed on the
> mailing list. I will send you a separate email.

Done.

>...

I do not believe we have heard from him.  As a starting point
for further discussion, in rfc5321bis-05 I have simply removed
all mention of "X" from that paragraph and minimally restated
the requirement for registration.  If we either want to reduce
the requirement from MUST... IESG-approved or to put in words
explicitly deprecating "X-" in this document, I await text (and,
if needed, tickets).
 
> Todd is in charge of this ticket, I will ask him to comment.

Done per (partially off-list) discussion.  For this and the next
item, more work will be needed for the A/S, probably including
either contact information for the Protocol Police when the ISP
supporting a server refuses to supply (or demands a hefty fee
for) reverse mapping to anything but an ITU-style location
identifer or a discussion of why something like

   EHLO be-302-cr11.newark.nj.xxxx.example.net

would be a good idea.

See also the two CREFs in the current (rfc5321bis-05) text.

> I think there is specific text suggested in the ticket
> already. Todd should comment as the ticket owner.

See above.  I await further instructions if the text in
rfc5321bis-05 is not sufficient.

>...

I think I'm still awaiting that.

best,
   john

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Oct 2021 14:37:23 -0400

On Fri, Oct 22, 2021 at 7:21 PM John C Klensin <[email-masked]> wrote

> See also the two CREFs in the current (rfc5321bis-05) text.

The current text in 5321bis (rev -05)
<https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-05.txt#section-3.6.2>
is

   specification.for use in delivery notifications.

Outside of the seemingly extraneous "for use in delivery notifications",
I'm fine with that, and will be closing the ticket.

> rfc5321bis-05 is not sufficient.
The proposed text in ticket 19 is:

An SMTP server MAY verify that the domain name argument in the EHLO command
has an address record matching the IP address of the client.

Ale has proposed an alternative of:

An SMTP server MAY verify the validity of the domain name argument in the
EHLO command.

(Ale has also proposed adding "See [A/S] for further discussion." to
whichever sentence is ultimately chosen, and I'm in favor of that.)

My concern with Ale's proposed text here is that "validity" is not defined
in the context of the phrase "validity of the domain name argument". The
previous paragraph in 5321bis starts with "The SMTP client MUST, if
possible, ensure that the domain parameter to the EHLO command is a primary
host name as specified for this command in Section 2.3.5
<https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-05.txt#section-2.3.5>."
and section 2.3.5 speaks of a requirement "that only fully-qualified
domain names
appear in SMTP transactions on the public Internet" and that's all a lot of
context to go through to suss out what's meant by "validity of the domain
name argument in the EHLO command".

So how about this?

An SMTP server MAY verify that the domain name argument in the EHLO command
is a fully-qualified domain name. See [A/S] for further discussion.

--