Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-44

[Ballot comment]
I was not part of the previous ballot, and therefore I do not wish to raise a DISCUSS for additional transport concerns.

However,  I do consider the following comments about Section 4.1.3 as important and would have raised this as a major concern if this were the first ballot, this concerns :

“  For
  IPv6 and other forms of addressing that might eventually be
  standardized, the form consists of a standardized "tag" that
  identifies the address syntax, a colon, and the address itself, in a
  format specified as part of the relevant standards (i.e., RFC 5952
  [14] for IPv6).“

(1)  This text could be read as implying the wrong message about IPv6 maturity. I would strongly recommend that you reword this to explicitly state the IPv6 case in one sentence or sentences. Then, (if you then see the need), the I-D to detail what to do about other addressing that may eventually be standardised.

(2)  I think it would be a real nuisance to have a non-standard representation for IPv6 literals when debugging transport connections, and therefore it is important to provide a clear guidance, so I support Eric’s V's comment:

As there is an IPv4 example, strongly suggest adding an IPv6 example as well,
e.g., "IPv6:2001:db8:cafe::25”.
- Please do reach out to others if you’d like help to construct this example.

[Ballot comment]
Hi John,

Thank you for the effort put into this document.

I trust the responsible AD for the accuracy of the technical content.

I quickly check https://author-tools.ietf.org/diff?doc_1=rfc5321&doc_2=draft-ietf-emailcore-rfc5321bis. Please find below some few comments:

# 2.1.  Basic Structure

Next-hop SMTP Client is added to the figure since 5321, but there is no similar mention in the narrative text surrounding the figure or elsewhere in the spec. There are other variations of "next hop *" and "next-hop *", but not the one depicted in the figure.

Likewise, there is no mention of "Submission Systems" in this section. There are only two uses in the documents, both only in titles.

# DNS Terminology

CURRENT: "labels" in DNS terminology, RFC 1035 [2]

We do have better DNS terminology documents since 1035. Referring to https://datatracker.ietf.org/doc/html/rfc9499#section-2 would be superior.

Likewise, the new discussion around "preferred name syntax" is better handled if offloaded to rfc9499#section-2 (search for “Host name”)

# Some commentary text would be better if removed

There are many in the draft. Examples are "to a history of problems" (without providing hints, it is difficult to digest the intent here).

Also, "Message Submission Servers [50] have somewhat more flexibility" but how is this useful for that part of the spec.

Idem for comments such as "(the latter also instructs the server to close the SMTP session)", etc.

# Redundant statements

There are many that I think removing would simplify the flow. For example, we have “An SMTP session, often called a "mail session"” (2.3.12) and then “An SMTP session (or "mail session")” (3.1.).

# Some stale changes

It seems the bis changes many occurrences that used to have “xxx response” to “xxx reply” but there are still some uses in the text such as “421 response” and few others.

# Display problem

Please check this para in 4.1.1.3:

  The forward-path consists of the required destination mailbox.�� When
  mail reaches its ultimate destination, the SMTP server inserts it
  into the destination�mailbox in accordance with its host mail
  conventions.

Cheers,
Med

[Ballot comment]
Many, many thanks to Donald Eastlake for multiple secdir reviews.

Most of the issues I saw with the last version have been cleaned up.  More bike shedding on this draft isn't useful. 

I still have one comment - very much not blocking, and I don't expect a response, let alone a change.

Complexity:  I found the complexity of the text confusing.  A standard should be clear, succinct  and concise.  RFC822 is 43 pages (minus appendices), this draft is 101 pages.  This draft is not clear and concise.  If I were queen (and I'm not), I'd move the history, discussion, and guidance elsewhere.  I can't imagine attempting to develop an implementation using this as it stands.

[Ballot comment]
Balloting a NoObj ballot based on my previous ballot and after reviewing the diffs:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-emailcore-rfc5321bis-38&url2=draft-ietf-emailcore-rfc5321bis-42&difftype=--html

Therefore repeating some non-blocking comments that were not addressed:

### Section 4.1.1.3

Why not using example.org rather than foo.org ?

### Section 4.1.3

As there is an IPv4 example, strongly suggest adding an IPv6 example as well,
e.g., "IPv6:2001:db8:cafe::25"

### Section 4.2.1

As FTP is about to be made historic, is it still worth comparing SMTP codes
with FTP codes ?

The document completed a supplementary Last Call on 4 March 2025. Outcome of this Last Call was to proceed with a normative reference to the forthcoming Applicability Statement.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-emailcore-rfc5321bis-42, which is currently in Last Call, and has the following comments:

We will work to implement the actions in this document.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-04-04):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, andy@hxr.us, draft-ietf-emailcore-rfc5321bis@ietf.org, emailcore-chairs@ietf.org, emailcore@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Simple Mail Transfer Protocol) to Internet Standard

This supplementary Last Call is for the sole purpose of verifying rough consensus exists for issues which were raised by and as a result of the SECDIR review of this document that have been addressed in version -42.

The SECDIR review can be found here:

https://datatracker.ietf.org/doc/review-ietf-emailcore-rfc5321bis-31-secdir-lc-eastlake-2024-10-11/

...and the WG's response to it is a long thread that began here:

https://mailarchive.ietf.org/arch/msg/emailcore/EHs584ejRsJ29M1X1RO1-zt5IV0/

...and a diff between the SECDIR-reviewed version and the current version can be found here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-emailcore-rfc5321bis-38&url2=draft-ietf-emailcore-rfc5321bis-42&difftype=--html

Please limit your feedback to responding to this specific question.
-- END --


The IESG has received a request from the Revision of core Email
specifications WG (emailcore) to consider the following document: - 'Simple
Mail Transfer Protocol'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-04-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document is a specification of the basic protocol for Internet
  electronic mail transport.  It (including text carried forward from
  RFC 5321) consolidates, updates, and clarifies several previous
  documents, making all or parts of most of them obsolete.  It covers
  the SMTP extension mechanisms and best practices for the contemporary
  Internet, but does not provide details about particular extensions.
  The document also provides information about use of SMTP for other
  than strict mail transport and delivery.  This document replaces RFC
  5321, the earlier version with the same title, and supersedes RFCs
  1846, 7504, and 7505, incorporating all the relevant information in
  them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3463: Enhanced Mail System Status Codes (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc3848: ESMTP and LMTP Transmission Types Registration (Draft Standard - Internet Engineering Task Force (IETF) stream)
    draft-ietf-emailcore-as: Applicability Statement for IETF Core Email Protocols (None - Internet Engineering Task Force (IETF) stream)

IANA notes on -40, with major issues labeled as “REQUIRED” or “STRONG”:

- RESOLUTION REQUIRED: the document needs to tell us to close the SMTP
Service Extension Parameters registry. It might also tell us to provide
a note that says "These entries have been incorporated into the SMTP
Service Extension registry's 'EHLO Parameters' field."

- STRONG RECOMMENDATION: I’m not sure about totally removing “8.1.1.2.
Add VRFY to the Registry” and placing it only in the instructions for
us, given that the first part of the IC section is meant for readers who
won't be interested in instructions for IANA.

Why not fill this in with a revised version of the intro from Section
8.3.3.3? "While it is not strictly an extension (nor is EXPN), to
improve clarity IANA should add VRFY to the SMTP Service Extensions
registry. See Section 8.3.3.3 for registration details." Then 8.3.3.3
could say, "IANA should add VRFY to the SMTP Service Extensions registry
immediately before the entry for EXPN.  Fields should be:"

- RESOLUTION REQUIRED: 8.1.1.3: The current registry has a "Notes"
column that contains multiple references to RFC 5321, but the list of
fields here doesn't include "Notes." Should this field be retained? If
so, it should probably be listed here. If you do keep that column,
should the references in it be updated?

- RECOMMENDATION:  8.1.1.3:  It might also be a good idea to include an
optional “Reference” here. We’ll keep the column anyway, but if an FCFS
applicant wants to fill in all of the fields with text instead of a link
to a spec, they won’t have a field that suggests it. In addition, an RFC
will sometimes need to list an earlier document as the reference for a
new assignment.

- 8.1.1.3: It might be useful to add a sentence like ‘Can be listed as
“Not supplied” for non-IETF registrations.’ to the end of the
description for the “Description” and “Length Added” fields, i.e. within
the list itself. Also, is it correct/sufficient to say “text must be
incorporated into the registry” for the “Description” field if it can
also be marked “Not supplied”?

- STRONG REQUEST: In 8.1.3, in ‘The “Mail Transmission Types” registry
group […] is a registry of link and protocol identifiers’, please change
“registry group” to just “registries” or something like “registry
grouping,” and then change that “registry” to “set.” This
group-within-a-group setup is an almost-one-off that we don’t have a
term for, and because 8126bis (-00 to be posted this week, I think) is
going to ask that “registry group” be used to refer specifically to the
whole group of registries collected in a file/web page, it would be good
to use something looser in this instance.

- RESOLUTION REQUIRED: Section 8.1.3 says, “Link and protocol
identifiers in addition to those specified in this document may be
registered only according to the “RFC Required” procedure described in
RFC 8126/ BCP 26 [3].” To us, “link and protocol identifiers” appears to
be referring to everything under Mail Transmission Types. However,
Section 8.1.4 says that Additional Registered Received: Clauses,” which
is one of the three registries there, should have IETF Review as its
procedure. If that’s correct, could you adjust “Link and protocol
identifiers in addition to those specified in this document” to name
just the two registries that RFC Required applies to?

- 8.2's item #5 seems to belong to another section (not sure which).

- STRONG REQUEST: About the explanation at the top of 8.2: I’d asked
that this be removed when it was only a comment just because we
implemented the 5321 actions either just before IANA was moved to ICANN
or shortly after, at which point IANA itself couldn’t have interpreted
the document in this way. ICANN may have had an adviser available, but
we were much more likely to have been helped by someone from the IETF or
ISI.

However, the real issue for us, which I should have gone into, is that
we don't want readers who aren't familiar with the process to infer that
part of IANA’s remit is to make technically-informed registry decisions,
like determining which potential fields are important enough to appear
in one. No issues with saying that IANA screwed up, but could “decisions
made” and “not made optimally” in the first sentence be changed to
something like “actions taken” and “not implemented optimally”? Then, in
the third sentence, “IANA chose to capture” could just be “IANA
captured" or "IANA mistakenly captured”.

- STRONG REQUEST: About the registration procedure in 8.3.3.1, item #3:
we’d strongly prefer to change “Either ‘Model 1’ or ‘Model 2’ as
described in Section 8.1.1.1 of <>” to “Either Model 1
(Standards Track or Experimental RFC) or Model 2 (First Come First
Served) as described in Section 8.1.1.1 of <>," rather
than provide no hint to readers at all, especially given that the
"RegAuth" field itself will be populated with "IETF" or "FCFS".
Referring to “Model 1” and “Model 2” at all is cryptic enough to send
users to the document for more information. There’s no reason to not
suggest a general shape to the procedures, or to make people go the
document to find out that one of the paths forward is easy.

- RESOLUTION REQUIRED: 8.3.3.2: the instructions are incomplete. Key
issues: 1) the document doesn’t tell us (here or in 8.1.1.3) how to fill
in the “Length Added” field for existing registrations; 2) it mentions
the contact, but not the change controller; and 3) the document doesn’t
tell us how to fill in any of the fields (aside from RegMethod) for the
two legacy registrations. It suggests the spec as the default for some
fields, but neither legacy registration has a spec.

Is the intention that we not include “Length Added” or Message
Submission Use and Values” in the registry?

Once the missing information is available, for clarity, I’d suggesting
replacing the existing items with something like this:

1) IANA should update the SMTP Service Extensions registry to include
all of the fields listed in Section 8.1.1.3.

2) Values for the “EHLO Parameters” field will be copied from the
now-closed “SMTP Service Extension Parameters” registry, with “None”
listed for any Service Extensions that did not appear in that registry.

3) The “RegMethod” field can be populated with “IETF,” “FCFS,” or
“Legacy” (the first two of which reflect the registration procedures
described in Section 8.1.1). “Legacy” will be applied to the “VERB” and
“ONEX” registrations, and “IETF” will be applied to all other
registrations that predate the publication of this document.

4) For the “IETF” registrations referred to above, the “Contact” and
“Change Controller” will be listed as the IETF, and the new “Additional
Verbs,” and “"MAIL/RCPT Parameter Values," fields will
be populated with the contents of the registration’s “Reference” field.
"Length Added" will be populated with "Not supplied."

5) For the legacy “VERB” and “ONEX” registrations, the “Contact” and
“Change Controller” will be taken from the reference field, and the
remaining fields will be filled in with "Not supplied" [if this is
correct].

- 8.3.4 looks like it should have a fourth item that says something like
"Further changes are described in Sections 8.1.3 and 8.1.4."

- RESOLUTION REQUIRED: we need the document to tell us how or whether to
replace the references to RFC 5321 in these locations as well as at
https://www.iana.org/assignments/mail-parameters:

https://www.iana.org/assignments/acme
https://www.iana.org/assignments/jmap
https://www.iana.org/assignments/message-headers
https://www.iana.org/assignments/service-names-port-numbers
https://www.iana.org/assignments/uri-schemes/prov/smtp

A blanket “All references to RFC 5321 at the following URLs should be
replaced with references to this document:” and, if necessary, “All
references to RFC 5321 at the following URLs should be left in place:”
would be fine.

(I apologize for not posting earlier Last Call notes in the datatracker. I thought that the distribution list had been limited intentionally.)

[Ballot comment]
Thanks for addressing my discuss points in -39.

I note the remaining questions regarding the IANA registration template changes.

I would suggest eliminating the comments from this section as well.

Noting JCK's objection to cluttering the template, I think a reference to the section that defines the syntax is fine.
An exemplar registration would not hurt if there is concern the template won't be used properly, or that people will not read section references.

[Ballot comment]
Thanks for addressing my previous DISCUSS point (see the archived ballot at: https://mailarchive.ietf.org/arch/msg/emailcore/Ec0LujkaG361VqDTNDYcZ3ymACA/


## COMMENTS (non-blocking)

### Presence of comments in the text

Like Roman, I find disturbing to still have (at this stage) comments in the text. Is this I-D fully baked and supported by the WG ? (I guess so after WGLC and IETF last call of course).

Especially in section 4.5.3.2.1 that hints that a Last Comment was not acted upon.

### Section 2.3.3

s/"Submission Server" (MSA)/"Message Submission Agent" (MSA)/ ?

### Section 2.3.5

Suggest s/fully-qualified name (often referred to as an FQDN/fully-qualified *domain* name (often referred to as an FQDN/

### Section 3.4.2

The first paragraph is confusing at first reading as I read it as "in all cases, MAIL must be rewritten" and later in 3.4.2.1 it is clear that it is not rewritten. Suggest removing the text about MAIL rewriting from the 1st paragraph.

### Section 3.6.2

Is it "Message Submission Servers" or "MSA" per section 2.3.3 ?

### Section 4.1.1.3

Why not using example.org rather than foo.org ?

### Section 4.1.3

As there is an IPv4 example, strongly suggest adding an IPv6 example as well, e.g., "IPv6:2001:db8:cafe::25"

### Section 4.2.1

As FTP is about to be made historic, is it still worth comparing SMTP codes with FTP codes ?

[Ballot comment]
I'm listing this as 'no objection', but only because 'piling on' might not be useful.  I supporting Eric, Orie, Roman, and Paul's discusses.

Apologies for two points:  I did not manage to make it through the whole draft, and these comments are possibly more direct than I'm used to giving on a ballot.

Security:  It is no longer 1982.  Many protocols manage to make breaking changes to improve security and still provide functional standards (TLS, IPsec, etc).  They do this in a variety of ways (versioning, for example).  It is time to do that with SMTP.  It is shocking to me that this draft is being considered with literally no mandatory security mechanisms. I support Paul's discuss.

References: (style comment)  I found the double links for references to be distracting and the [#] look like footnotes.

Incomplete draft: the inclusion of issue numbers and overlapping comments made it obvious that this is not a completed draft.  I support Roman's discuss.

Complexity:  I found the complexity of the text confusing.  A standard should be clear, succinct  and concise.  RFC822 is 43 pages (minus appendices), this draft is 101 pages, hardly concise.  This draft is not clear and concise, move the history, discussion, and guidance elsewhere.  I can't imagine attempting to develop an implementation using this as it stands.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-emailcore-rfc5321bis-38
CC @evyncke

Thank you for the work put into this document. As for most -bis draft, I have only reviewed the diff (also suggested in the shepherd's write-up)

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Alexey Melnikov for the shepherd's detailed write-up including the WG consensus, the justification of the intended status, and detailed context around this -bis document.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 4.1.3

RFC 4291 is not really about IPv6 address format (it is about the IPv6 addressing architecture), the reference here is RFC 5952 (A Recommendation for IPv6 Address Text Representation).

[Ballot comment]

## COMMENTS (non-blocking)

### Presence of comments in the text

Like Roman, I find disturbing to still have (at this stage) comments in the text. Is this I-D fully baked and supported by the WG ? (I guess so after WGLC and IETF last call of course).

Especially in section 4.5.3.2.1 that hints that a Last Comment was not acted upon.

### Section 2.3.3

s/"Submission Server" (MSA)/"Message Submission Agent" (MSA)/ ?

### Section 2.3.5

Suggest s/fully-qualified name (often referred to as an FQDN/fully-qualified *domain* name (often referred to as an FQDN/

### Section 3.4.2

The first paragraph is confusing at first reading as I read it as "in all cases, MAIL must be rewritten" and later in 3.4.2.1 it is clear that it is not rewritten. Suggest removing the text about MAIL rewriting from the 1st paragraph.

### Section 3.6.2

Is it "Message Submission Servers" or "MSA" per section 2.3.3 ?

### Section 4.1.1.3

Why not using example.org rather than foo.org ?

### Section 4.1.3

As there is an IPv4 example, strongly suggest adding an IPv6 example as well, e.g., "IPv6:2001:db8:cafe::25"

### Section 4.2.1

As FTP is about to be made historic, is it still worth comparing SMTP codes with FTP codes ?

[Ballot discuss]
** Is this document done?  It appears to be incomplete and include annotations where further discussion is necessary.

-- There are numerous sections (e.g., Section 1.2, 1.3, 2.2.1, 2.3.1, etc.) which contain annotations with a “//” which suggest that further refinement and discussion is necessary.  For example, in Section 2.3.12, “  // Last call comment indicated that the text below was in need of a // rewrite.  WG should check the revised form below.  Ticket #99”

-- There is a “note on reading this draft” which says “Each one of these contains notes about suggestions and unresolved issues.  These drafts will presumably lead to another, cleaned-up, draft for IESG review (with or without an additional IETF Last Call).”  Why would there be unresolved issues in a document being reviewed by the IESG?  Unresolved issues strongly suggests the document is not ready for IESG review.

-- Section 8.3.2
8.3.2.  Changes to the top-level "MAIL Parameters" Registry Group
  // Note in draft (up to the IESG, presumably in consultation with
  // IANA whether this note appears in some form in the final version):
  // The quantity and complexity of the changes below is largely due to
  // registry organization decisions made in the fairly distant past by
  // IANA and, in retrospect, not made optimally.

The IESG needs to make decision on the final content of text?  What is the process for a WG document to suggest text in a document which is supposed to be done and the IESG decides whether to include it?

** Section 8.1.1.1
  Model 1:  IETF Review and Approval
            The document goes through the normal IETF review and
            approval process, culminating in a published Standards
            Track, BCP, Experimental, or, in rare cases specifically
            approved by the IESG, an IETF Stream Informational RFC.
            The intent is that the extension and its specification will
            represent careful IETF community review and consensus on
            its technical merits, utility, and clarity of explanation.
            The change controller for all such extensions will be the
            IETF.

            This model is approximately equivalent to "IETF Review" as
            described in RFC 8126/ BCP 26 [3], but involves a stronger
            preference for a Standards Track or Experimental
            publication as a result.

It appears this text is relaxing the current registration procedure from “Standards Action or IESG-Approved Experimental RFC” as currently documented in https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-2 to something else.  However, the guidance is ambiguous.

-- As written it looks like “IETF Review”.  In what way is it just “approximately equivalent to ‘IETF Review’”?

-- What is the additional consideration that the IESG is supposed to give due to “… or, in rare cases specifically approved by the IESG, an IETF Stream Informational RFC.”  By definition, the IESG is going to approve all of these documents?  What are the circumstances where the IESG would _deny_ an informational RFC brought to it?

[Ballot discuss]
** Is this document done?  It appears to be incomplete an include annotations where further discussion is necessary.

-- There are numerous sections (e.g., Section 1.2, 1.3, 2.2.1, 2.3.1, etc.) which contain annotations with a “//” which suggest that further refinement and discussion is necessary.  For example, in Section 2.3.12, “  // Last call comment indicated that the text below was in need of a // rewrite.  WG should check the revised form below.  Ticket #99”

-- There is a “note on reading this draft” which says “ Each one of these contains notes about suggestions and unresolved issues.  These drafts will presumably lead to another, cleaned-up, draft for IESG review (with or without an additional IETF Last Call).”  Why would there be unresolved issues in a document being reviewed by the IESG?  Unresolved issues suggests the document is not ready for IESG review.

-- Section 8.3.2
8.3.2.  Changes to the top-level "MAIL Parameters" Registry Group
  // Note in draft (up to the IESG, presumably in consultation with
  // IANA whether this note appears in some form in the final version):
  // The quantity and complexity of the changes below is largely due to
  // registry organization decisions made in the fairly distant past by
  // IANA and, in retrospect, not made optimally.

The IESG needs to make decision on the final content of text?  What is the process for a WG document to suggest text in a document which is supposed to be done and the IESG decides whether to include it?

** Section 8.1.1.1
  Model 1:  IETF Review and Approval
            The document goes through the normal IETF review and
            approval process, culminating in a published Standards
            Track, BCP, Experimental, or, in rare cases specifically
            approved by the IESG, an IETF Stream Informational RFC.
            The intent is that the extension and its specification will
            represent careful IETF community review and consensus on
            its technical merits, utility, and clarity of explanation.
            The change controller for all such extensions will be the
            IETF.

            This model is approximately equivalent to "IETF Review" as
            described in RFC 8126/ BCP 26 [3], but involves a stronger
            preference for a Standards Track or Experimental
            publication as a result.

It appears this text is relaxing the current registration procedure from “Standards Action or IESG-Approved Experimental RFC” as currently documented in https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-2 to something else.  However, the guidance is ambiguous.

-- As written it looks like “IETF Review”.  In what way is it just “approximately equivalent to ‘IETF Review’”?

-- What is the additional consideration that the IESG is supposed to give due to “… or, in rare cases specifically approved by the IESG, an IETF Stream Informational RFC.”  By definition, the IESG is going to approve all of these documents?  What are the circumstances where the IESG would _deny_ an informational RFC brought to it?

[Ballot comment]
** I support the DISCUSS position of Paul Wouters.  Based on the last-call list, there does not appear to be consensus on the treatment of the Security Considerations in this document.  Furthermore, there does not appear to be normative guidance on the handling security and privacy issues for a protocol subject to the internet threat model.

[Ballot comment]
I'm stealing Zahed's ballot text: "No objection from transport protocol specific issues, but I would like to see Paul's concerns are addressed. Hence, supporting his discuss."

[Ballot discuss]
There are two issues here. One of process and one of content

There seems to be no clear consensus on whether SMTP should be promoted
to Internet Standard without recommending (or requiring) the proper
minimum security of transport encryption using STARTTLS. There was a
discussion on whether to add this or not to the document or to the AS. It
was seen as a compromise to place this in the AS, and have a Normative
reference. But now this reference is an Informative reference and thus
seems to again lack clear consensus. As Security AD, I also believe
the minimum is a normative reference to what are essential security and
privacy requirements of defacto internet connected SMTP.

The process question is whether this document should have had another
IETF LC after the change of using an Informative reference to the AS
document to confirm consensus. I believe if this was done, it would have
shown a lack of consensus on the specific solution to the security issues
raised by a number of people (including me).

As such, I think the document is not ready to move forward.

Note that I did not further evaluate the document in detail at this point,
although I have read earlier versions of this document during the security and
STARTTLS discussions.

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-emailcore-rfc5321bis-38
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5321bis-38.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### Use of BCP 14 in the appendix

```
5251   // 20241107 Ticket #108.  Tentative conclusion at meeting: leave
5252   // alone unless there is considerable insistence on changing "SHOULD"
5253   // to "MUST".
```

Reading of the appendix should not be necessary to safely or interoperably implement the protocol, except where the appendix is directly referenced as normative from the body.

I'd prefer to see the deprecations, and any other normative changes listed in the body of the document.

This comment applies to Appendix B and D.

### Deprecating HELO

```
1761   // Some of the discussion surrounding "(or HELO)" (see Ticket #116)
1762   // suggest that it may be time to deprecate HELO entirely, i.e., turn
1763   // it into a SHOULD NOT.  Ticket #123.
```

Is it time?

### alternative text discussions

```
3722   // A discussion of the four alternatives -- original, Donald
3723   // Eastlake's, Bron/Todd's, and Dave's -- and criteria for making a
3724   // change and which one appears at
3725   //
```

Not clear to me how to handle this comment.

[Ballot comment]

## Comments

### foo.com, foo-u.edu, generic.com, bar.org

Suggest using "example.com" or "domain.example", "university.example" etc...

Be aware that xyz.com -> https://gen.xyz/ ...

### SHOULD -> should?

```
1488   received for them.  Implementations generally SHOULD be more
1489   aggressive about address verification in the case of VRFY than in the
1490   case of RCPT, even if it takes a little longer to do so.
```

Also:

```
3204   In extreme cases -- such as to contain a denial of service attack or
3205   other breach of security -- an SMTP server may block mail directed to
3206   Postmaster.  However, such arrangements SHOULD be narrowly tailored
3207   so as to avoid blocking messages that are not part of such attacks.
```

### BCP 14 keywords in ABNF comments

```
2198   Local-part    = Dot-string / Quoted-string
2199                   ; MAY be case-sensitive
```

```
2285   Standardized-tag  = Ldh-str
2286                   ; Standardized-tag MUST be specified in a
2287                   ; Standards-Track RFC and registered with IANA
2288                   ; See Section 8.1.2.
```

```
3158   Addtl-Link    = Atom
3159                   ; Additional standard names for links are
3160                   ; registered with the Internet Assigned Numbers
3161                   ; Authority (IANA).  "Via" is primarily of value
3162                   ; with non-Internet transports.  SMTP servers
3163                   ; SHOULD NOT use unregistered names.
```

It would be better to just refer to a section, instead of including BCP 14 keywords as ABNF comments.

### Which useful functionality?

```
3957   This specification does not further address the authentication issues
3958   associated with SMTP other than to advocate that useful functionality
3959   not be disabled in the hope of providing some small margin of
3960   protection against a user who is trying to fake mail.
```

I recommend removing this sentence.

### Double should

```
4010   EXPN available only to authenticated requestors.  Implementations
4011   SHOULD still provide support for EXPN, but sites SHOULD carefully
4012   evaluate the tradeoffs.
```

The second should is implied in the first?

### How to be certain?

```
4025   Before a client uses the 251 or 551 reply codes from a RCPT command
4026   to automatically update its future behavior (e.g., updating the
4027   user's address book), it should be certain of the server's
4028   authenticity.  If it does not, it may be subject to a man in the
4029   middle attack.
```

Provide some options, or make this a SHOULD?

### Security through obscurity?

```
4033   There has been an ongoing debate about the tradeoffs between the
4034   debugging advantages of announcing server type and version (and,
4035   sometimes, even server domain name) in the greeting response or in
4036   response to the HELP command and the disadvantages of exposing
4037   information that might be useful in a potential hostile attack.  The
4038   utility of the debugging information is beyond doubt.  Those who
4039   argue for making it available point out that it is far better to
4040   actually secure an SMTP server rather than hope that trying to
4041   conceal known vulnerabilities by hiding the server's precise identity
4042   will provide more protection.  Sites are encouraged to evaluate the
4043   tradeoff with that issue in mind; implementations SHOULD minimally
4044   provide for making type and version information available in some way
4045   to other network hosts.
```

I'd prefer to see SHOULD / SHOULD NOT on the specific security sensitive parameters, and leave the rest of this kind of text for the archives.

### MUST NOT use optional FOR?

```
4055   be aware of it.  Also, the optional FOR clause should not be supplied
4056   when the same message is sent to multiple recipients in the same mail
4057   transaction in order not to inadvertently disclose the identities of
4058   "blind copy" recipients to others.
```

## Nits

### 4yz used before definition

```
2120   command).  If the connection is closed prematurely due to violations
2121   of the above or system or network failure, the server MUST cancel any
2122   pending transaction, but not undo any previously completed
2123   transaction, and generally MUST act as if the command or transaction
2124   in progress had received a temporary error (i.e., a 4yz response).
```

RFC5321bis Document Shepherd Write-up

# Document Shepherd Write-Up for Group Documents

*This version of the template is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.



## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The EMAILCORE working group’s charter was to perform a "limited review and
revision" of documents that describe a widely installed and used protocol.
Participation in the working group was generally limited to a
dozen or so individuals, owing in large part to the group’s work being
focused on revising fifteen year old documents that are themselves
forth-generation revisions of originals first published in 1982.

When reviewing this document, it is strongly suggested that you refer to:
https://author-tools.ietf.org/iddiff?url1=rfc5321&url2=draft-ietf-emailcore-rfc5321bis

Also, please read  for various
security considerations related to email systems.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy about particular points, although quite a lot of
polite, thorough and sometimes slow discussion about the details of
specific sections. Also the WG spent quite a bit of time updating
(modernizing) IANA registration policies for various registries, as
well as reviewing whether particular features were still in use. In
the latter case, the WG erred on the side of caution to keep some less
widely used options in order not to break implementations currently
complying with RFC 5321.

Extensive SecDir and DnsDir reviews uncovered some smaller issues
(like outdated text or some unclear things), but -38 is believed
to address all major (and many minor) comments, and it reflects
WG consensus on the rest of proposed suggestions.

One possible remaining issue is whether any text about TLS needs
to be specified (note that STARTTLS is an extension specified in
a separate RFC and most of discussions of its use are in
draft-ietf-emailcore-as).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No known threats of appeal.

4. For protocol documents, are there existing implementations of the contents
of the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as [RFC 7942][3] recommends) or elsewhere
(where)?

There are countless implementations of the contents of the document, including
open source and proprietary clients and server, as well as libraries in many
programming languages.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

While SMTP is in wide use, both inside and outside
the IETF, review beyond those who participated in the WG was not considered
necessary. We had a good cross-section of people in the WG, and the task was
to preserve compatibility with all existing implementations.

SecDir, DnsDir and GenArt reviews were helpful in finding some outdated text
in the document. Some proposed changes are out of scope due to the WG Charter.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No MIBs, YANG, new media type, or URI type specifications in this document.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the [recommended validation tools][4] for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF rules in the document have undergone thorough manual review by members
of the working group during this cycle, as well as during each publishing cycle
for previous revisions of this document (RFCs 821, 2821, and 5321).
Alexey Melnikov used a formal ABNF checker on ABNF extracted from -29.
Some small errors were found and they were fixed in -30.

There were no further ABNF changes between version 30 and 38.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
Reviews?

There was an extensive discussion on the list about the use of the terms
"ASCII" and "US-ASCII". The experts seemed satisfied that the use of the
terms in this document is reasonable and correct. No other "common issues"
appeared problematic.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type of RFC publication being requested is Internet Standard. RFC 2026,
Section 4.1.3, Internet Standard, reads:

  A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community.

This document (5321bis) updates the definition of the SMTP protocol
used for sending "electronic mail" messages, its extensibility
and mentions some very common SMTP extensions (mostly as examples
of extensibility). This protocol has significant implementation and
successful operational experience. Futhermore, the fact that electronic
mail in the form of mailing lists serves as the foundation for much of
the work that IETF Working Groups accomplish seems to stand as the primary
evidence that electronic mail provides a significant benefit to the Internet
community, to say nothing of electronic mail's role as a communication tool
for individuals across the globe.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To the
best of your knowledge, have all required disclosures been filed? If not,
explain why. If yes, summarize any relevant discussion, including links to
publicly-available messages when applicable.

All reasonable efforts have been made to remind authors of IPR disclosure
obligations. No required disclosures exist to be filed.

Do note that the BCP *78* template used in this document is the pre-5378
template. Given the age of some of the text in this document, it is impossible
to assure that all rights have been obtained to be able to claim full
permission.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the
[idnits][8] tool is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)


ID-Nits checker complains about a few things, which are either in RFC Editor notes
that will be removed or is mistaken:

  ** The abstract seems to contain references ([55]), which it shouldn't.
    Please replace those with straight textual mentions of the documents in
    question.

  -- The draft header indicates that this document obsoletes RFC7504, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC7505, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC1846, but the
    abstract doesn't seem to mention this, which it should.

ID-Nits also complains:

  == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
    document.

which is as expected in a bis document.

There is a warning about weird spacing. This is in regards to an example
that is using such spacing deliberately.

ID-Nits is reporting duplicated references, but it is mistaken:

  -- Duplicate reference: RFC20, mentioned in '5', was also mentioned in '4'.

  -- Duplicate reference: RFC1035, mentioned in '8', was also mentioned in
    '7'.

  -- Duplicate reference: RFC5321, mentioned in '64', was also mentioned in
    '55'.

  -- Duplicate reference: RFC5321, mentioned in '66', was also mentioned in
    '64'.

(In particular, [64] and [66] are errata, not RFC 5321)


ID-Nits is correct that [60] is not referenced.


15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

Normative and Informative references are properly classified as such.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
References?

ANSI X3.4-1968 is not officially available freely, but it is findable easily
on the web.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

There is a normative reference to RFC 821 in regards to use of features
that were removed in this revision of SMTP.

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

This document is intended to obsolete RFC 5321, RFC 1846, RFC 7504 and RFC 7505,
and is noted as such.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section has significant updates to bring the document
in line with modern IETF practices (in particular to make registration
of SMTP extensions easier, as well as to clarify the registration template).

Any referenced IANA registries have been clearly identified.

No new registries are created by this document, however some missing
values were identified in existing registries. For example see Section 8.3.3.3

Registration procedures for various existing registries were updated
or clarified. In some cases extra registration fields were added.

The document also contains instructions for IANA about reorganizing
the Mail Parameters Registry Group.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

None. See the answer to 20) for more details.

RFC5321bis Document Shepherd Write-up

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.



## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The EMAILCORE working group’s charter was to perform a "limited review and
revision" of documents that describe a widely installed and used protocol.
Participation in the working group was generally limited to a
dozen or so individuals, owing in large part to the group’s work being
focused on revising fifteen year old documents that are themselves
forth-generation revisions of originals first published in 1982.

When reviewing this document, it is strongly suggested that you refer to:
https://author-tools.ietf.org/iddiff?url1=rfc5321&url2=draft-ietf-emailcore-rfc5321bis

Also, please read  for various
security considerations related to email systems.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy about particular points, although quite a lot of polite,
thorough and sometimes slow discussion about the details of specific sections.
Also the WG spent quite a bit of time updating (modernizing) IANA registration policies
for various registries, as well as reviewing whether particular
features were still in use. In the latter case, the WG erred on the side of caution
to keep some less widely used options in order not to break implementations
currently complying with RFC 5321.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No known threats of appeal.

4. For protocol documents, are there existing implementations of the contents
of the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as [RFC 7942][3] recommends) or elsewhere
(where)?

There are countless implementations of the contents of the document, including
open source and proprietary clients and server, as well as libraries in many
programming languages.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

While SMTP is in wide use, both inside and outside
the IETF, review beyond those who participated in the WG was not considered
necessary. We had a good cross-section of people in the WG, and the task was
to preserve compatibility with all existing implementations.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No MIBs, YANG, new media type, or URIs in this document.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the [recommended validation tools][4] for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF rules in the document have undergone thorough manual review by members
of the working group during this cycle, as well as during each publishing cycle
for previous revisions of this document (RFCs 821, 2821, and 5321).
Alexey Melnikov used a formal ABNF checker on ABNF extracted from -29.
Some small errors were found and they were fixed in -30.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
Reviews?

There was an extensive discussion on the list about the use of the terms
"ASCII" and "US-ASCII". The experts seemed satisfied that the use of the
terms in this document is reasonable and correct. No other "common issues"
appeared problematic.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type of RFC publication being requested is Internet Standard. RFC 2026,
Section 4.1.3, Internet Standard, reads:

  A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community.

This document (5321bis) updates the definition of the SMTP protocol
used for sending "electronic mail" messages, its extensibility
and mentions some very common SMTP extensions (mostly as examples
of extensibility). This protocol has significant implementation and
successful operational experience. Futhermore, the fact that electronic
mail in the form of mailing lists serves as the foundation for much of
the work that IETF Working Groups accomplish seems to stand as the primary
evidence that electronic mail provides a significant benefit to the Internet
community, to say nothing of electronic mail's role as a communication tool
for individuals across the globe.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To the
best of your knowledge, have all required disclosures been filed? If not,
explain why. If yes, summarize any relevant discussion, including links to
publicly-available messages when applicable.

All reasonable efforts have been made to remind authors of IPR disclosure
obligations. No required disclosures exist to be filed.

Do note that the BCP *78* template used in this document is the pre-5378
template. Given the age of some of the text in this document, it is impossible
to assure that all rights have been obtained to be able to claim full
permission.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the
[idnits][8] tool is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)


ID-Nits checker complains about a few things, which are either in RFC Editor notes
that will be removed or is mistaken:

  ** The abstract seems to contain references ([54]), which it shouldn't.
    Please replace those with straight textual mentions of the documents in
    question.

  -- The draft header indicates that this document obsoletes RFC7504, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC7505, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC1846, but the
    abstract doesn't seem to mention this, which it should.

ID-Nits also complains:

  == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
    document.

which is as expected in a bis document.


There is a warning about weird spacing. This is in regards to an example
that is using such spacing deliberately.


ID-Nits is reporting duplicated references, but it is mistaken:

  -- Duplicate reference: RFC20, mentioned in '5', was also mentioned in '4'.

  -- Duplicate reference: RFC1123, mentioned in '10', was also mentioned in
    '8'.

  -- Duplicate reference: RFC5321, mentioned in '63', was also mentioned in
    '54'.

  -- Duplicate reference: RFC5321, mentioned in '65', was also mentioned in
    '63'.

(In particular, [63] and [65] are errata, not RFC 5321)


ID-Nits is correct that [63] is not referenced and that reference [9]
(RFC 8499) was obsoleted by RFC 9499.



15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

Normative and Informative references are properly classified as such.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
References?

ANSI 3.4 1986 is not officially available freely, but it is findable easily
on the web.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

There is a normative reference to RFC 821 in regards to use of features
that were removed in this revision of SMTP.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

This document is intended to obsolete RFC 5321, RFC 1846, RFC 7504 and RFC 7505,
and is noted as such.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).


The IANA Considerations section has significant updates to bring the document
in line with modern IETF practices (in particular to make registration
of SMTP extensions easier, as well as to clarify the registration template).

Any referenced IANA registries have been clearly identified.

No new registries are created by this document, however some missing
values were identified in existing registries. For example see Section 8.2

The document also contains some instructions to IANA about reorganizing
the Mail Parameters Registry Group.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-emailcore-rfc5321bis-31. If any part of this review is inaccurate, please let us know.

IANA has a question about the actions requested in the IANA Considerations section of this document.

Upon approval of this document, IANA will work with the author to implement the IANA Considerations in section 8 of the current draft with the understanding that there is no revision to RFC 8126 currently being considered by the IETF community. We understand that there are existing references in many registries to RFC 5321, RFC 7404, and RFC 7405, including (and this is a non-exhaustive list):

RFC 5321:

https://www.iana.org/assignments/acme
https://www.iana.org/assignments/address-literal-tags
https://www.iana.org/assignments/jmap
https://www.iana.org/assignments/mail-parameters
https://www.iana.org/assignments/message-headers
https://www.iana.org/assignments/service-names-port-numbers
https://www.iana.org/assignments/uri-schemes/prov/smtp

RFC 7404 and 7405:

https://www.iana.org/assignments/smtp-enhanced-status-codes

IANA Question -> We understand that this document will replace the existing references to these RFCs in these registries. Could you confirm if this understanding is correct?

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-10):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-ietf-emailcore-rfc5321bis@ietf.org, emailcore-chairs@ietf.org, emailcore@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Simple Mail Transfer Protocol) to Internet Standard


The IESG has received a request from the Revision of core Email
specifications WG (emailcore) to consider the following document: - 'Simple
Mail Transfer Protocol'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document is a specification of the basic protocol for Internet
  electronic mail transport.  It (including text carried forward from
  RFC 5321) consolidates, updates, and clarifies several previous
  documents, making all or parts of most of them obsolete.  It covers
  the SMTP extension mechanisms and best practices for the contemporary
  Internet, but does not provide details about particular extensions.
  The document also provides information about use of SMTP for other
  than strict mail transport and delivery.  This document replaces RFC
  5321, the earlier version with the same title, and supersedes RFCs
  1846, 7504, and 7505, incorporating all the relevant information in
  them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3463: Enhanced Mail System Status Codes (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc3848: ESMTP and LMTP Transmission Types Registration (Draft Standard - Internet Engineering Task Force (IETF) stream)

RFC5321bis Document Shepherd Write-up

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.



## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The EMAILCORE working group’s charter was to perform a "limited review and
revision" of documents that describe a widely installed and used protocol.
Participation in the working group was generally limited to a
dozen or so individuals, owing in large part to the group’s work being
focused on revising fifteen year old documents that are themselves
forth-generation revisions of originals first published in 1982.

When reviewing this document, it is strongly suggested that you refer to:
https://author-tools.ietf.org/iddiff?url1=rfc5321&url2=draft-ietf-emailcore-rfc5321bis


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy about particular points, although quite a lot of polite,
thorough and sometimes slow discussion about the details of specific sections.
Also the WG spent quite a bit of time updating (modernizing) IANA registration policies
for various registries, as well as reviewing whether particular
features were still in use. In the latter case, the WG erred on the side of caution
to keep some less widely used options in order not to break implementations
currently complying with RFC 5321.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No known threats of appeal.

4. For protocol documents, are there existing implementations of the contents
of the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as [RFC 7942][3] recommends) or elsewhere
(where)?

There are countless implementations of the contents of the document, including
open source and proprietary clients and server, as well as libraries in many
programming languages.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

While SMTP is in wide use, both inside and outside
the IETF, review beyond those who participated in the WG was not considered
necessary. We had a good cross-section of people in the WG, and the task was
to preserve compatibility with all existing implementations.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No MIBs, YANG, new media type, or URIs in this document.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the [recommended validation tools][4] for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF rules in the document have undergone thorough manual review by members
of the working group during this cycle, as well as during each publishing cycle
for previous revisions of this document (RFCs 821, 2821, and 5321).
Alexey Melnikov used a formal ABNF checker on ABNF extracted from -29.
Some small errors were found and they were fixed in -30.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
Reviews?

There was an extensive discussion on the list about the use of the terms
"ASCII" and "US-ASCII". The experts seemed satisfied that the use of the
terms in this document is reasonable and correct. No other "common issues"
appeared problematic.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type of RFC publication being requested is Internet Standard. RFC 2026,
Section 4.1.3, Internet Standard, reads:

  A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community.

This document (5321bis) updates the definition of the SMTP protocol
used for sending "electronic mail" messages, its extensibility
and mentions some very common SMTP extensions (mostly as examples
of extensibility). This protocol has significant implementation and
successful operational experience. Futhermore, the fact that electronic
mail in the form of mailing lists serves as the foundation for much of
the work that IETF Working Groups accomplish seems to stand as the primary
evidence that electronic mail provides a significant benefit to the Internet
community, to say nothing of electronic mail's role as a communication tool
for individuals across the globe.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To the
best of your knowledge, have all required disclosures been filed? If not,
explain why. If yes, summarize any relevant discussion, including links to
publicly-available messages when applicable.

All reasonable efforts have been made to remind authors of IPR disclosure
obligations. No required disclosures exist to be filed.

Do note that the BCP *78* template used in this document is the pre-5378
template. Given the age of some of the text in this document, it is impossible
to assure that all rights have been obtained to be able to claim full
permission.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the
[idnits][8] tool is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)


ID-Nits checker complains about a few things, which are either in RFC Editor notes
that will be removed or is mistaken:

  ** The abstract seems to contain references ([54]), which it shouldn't.
    Please replace those with straight textual mentions of the documents in
    question.

  -- The draft header indicates that this document obsoletes RFC7504, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC7505, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document obsoletes RFC1846, but the
    abstract doesn't seem to mention this, which it should.

ID-Nits also complains:

  == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
    document.

which is as expected in a bis document.


There is a warning about weird spacing. This is in regards to an example
that is using such spacing deliberately.


ID-Nits is reporting duplicated references, but it is mistaken:

  -- Duplicate reference: RFC20, mentioned in '5', was also mentioned in '4'.

  -- Duplicate reference: RFC1123, mentioned in '10', was also mentioned in
    '8'.

  -- Duplicate reference: RFC5321, mentioned in '63', was also mentioned in
    '54'.

  -- Duplicate reference: RFC5321, mentioned in '65', was also mentioned in
    '63'.

(In particular, [63] and [65] are errata, not RFC 5321)


ID-Nits is correct that [63] is not referenced and that reference [9]
(RFC 8499) was obsoleted by RFC 9499.



15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

Normative and Informative references are properly classified as such.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
References?

ANSI 3.4 1986 is not officially available freely, but it is findable easily
on the web.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

There is a normative reference to RFC 821 in regards to use of features
that were removed in this revision of SMTP.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

This document is intended to obsolete RFC 5321, RFC 1846, RFC 7504 and RFC 7505,
and is noted as such.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).


The IANA Considerations section has significant updates to bring the document
in line with modern IETF practices (in particular to make registration
of SMTP extensions easier, as well as to clarify the registration template).

Any referenced IANA registries have been clearly identified.

No new registries are created by this document, however some missing
values were identified in existing registries. For example see Section 8.2

The document also contains some instructions to IANA about reorganizing
the Mail Parameters Registry Group.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/