Last Call Review of draft-ietf-emailcore-rfc5321bis-31
review-ietf-emailcore-rfc5321bis-31-secdir-lc-eastlake-2024-10-11-01

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is Has Issues.

This document is an obsoleting revision of RFC 5321 on the Simple Mail Transfer
Protocol (SMTP), incorporating Errata, etc. It is a mix of specification,
operational, and historic information. Changes from RFC 5321 are summarized in
Appendix F. I did not review the Acknowledgements or References sections or
Appendices C or E.

Security
--------

This document has an extensive Security Considerations section which covers
most points. But I have the following suggestions:

Section 7: Could be clearer on what the threat model is.

Section 7.1, particularly re 1st paragraph: Shouldn't there be some mention of
DMARC (RFC 7489) and DKIM (RFC 6376) and perhaps other things that don't come
to my mind immediately?

Section 7.1, particularly re 2nd paragraph: I think it would be useful to
mention something like the following: 1. Transport authentication between SMTP
systems could improve the authenticity of the Received line added by a server
but does  not protect those lines against modification, in violation of this
document, by subsequent SMTP systems. 2. Nation State intelligence agencies and
others on occasion, have been known, even in the case of extremely high
bandwidth traffic mixing many streams, for example between large data centers,
as well as lower bandwidth connections, to capture and hold immense quantities
of raw traffic for potential later analysis, so there may be good reason to
encrypt transmissions between SMTP systems.

Non-Security
------------

Section 6.1, 6.2: I do not quite understand saying that something is
mandatory/required and then talking about where it is impossible or impractical
to do that thing. Section 6.1 says, concerning a host holding an email message,
"It MUST NOT lose the message for frivolous reasons, such as because the host
later crashes ...". "frivolous" does not seem very well defined for a mandatory
implementation requirement. The only examples given later of non-frivolous
reasons seem to be spam or "hostile" (infected?) messages. Maybe this should be
more like "In so far as practical, messages MUST NOT be accidentally lost. For
example, messages and their processing state should be committed to
non-volatile storage until responsibility is taken for that message by the next
host in the delivery path." or something like that. In Section 6.2, how does it
make sense to say that something is required and impractical?

Minor
-----

Global: RFC 821 is obsolete. It was published 42 years ago and obsoleted 21
years ago. Is there really a need for references to it in this document?

Section 1.2, last paragraph: Future commitments always seem a bit risky.
Suggest replacing "forthcoming" with "planned".

Section 2.3.5, last paragraph (before the final two bullet points): The first
sentence of this paragraph is of questionable grammar and, in any case,
extremely hard to parse. Assuming I have parsed it correctly, how about "Unless
further restricted in this document, domain names used in SMTP are names that
can be resolved to MX or address (A or AAAA) RRs (see also Section 5), or to
CNAME RRs that can be resolved to an MX or address RR."

Section 2.3.12, first sentence: Appears to have missing text and/or have
grammatical errors and is hard to parse. How about something like : "This
document distinguishes between two concepts: (1) an "SMTP session (aka "mail
session") that starts when a connection is made between client and server and
ends when than connection terminates", and (2) a "mail transaction that is
started and terminated by particular SMTP commands."

Section 3.5.1/4.1.1.3: I saw the text in Section 1.3 about this, but it still
seems dubious to include real domain names like foo.com and xyz.com in
examples. Is it really going to cause confusion to go with example.com or the
like? (In any case, if you are using "foo" or "bar" or "foobar", you should
consider adding RFC 3092 to the references.)

Section 4.1.3: Please use IPv4 addresses reserved for documentation. There are
plenty available, particularly any in 192.0.2/24, 198.51.100.0/24, and
203.0.113.0/24. See
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Section 4.1.3: Isn't a "1*" prefix, as in 1*dcontent, superfluous?

Section 4.1.4, etc.: Why isn't there a state diagram? Instead, we have somewhat
verbose and redundant prose that is basically trying to provide a state diagram
and transition rules.

Section 4.1.4, page 48, 5th paragraph: Says server can verify domain name
argument in EHLO command. Can it also do that for HELO? And what should it do
if the verification fails?

Section 4.1.4, page 49, 3rd paragraph: This "MAIL MUST NOT be sent" text seems
confusing at a minimum. To most readers MAIL is "being sent" with every RCPT
command, with the DATA command, and with every new line of mail content. Please
re-word it so it's something about "initiating" the sending of mail or the like.

Section 4.2, page 50, right after the ABNF: the "where ..." construct is
normally used to provide more information for something appearing in the
immediately preceding ABNF/diagram/whatever but "Greeting" does not occur in
the ABNF which is confusing. Reading further, apparently the actual quoted word
"Greeting" is not meant, which is also confusing. If it's any generic greeting
message, maybe just use lower case unquoted greeting.

Section 4.2, page 51, first complete paragraph: For the IETF, what is the
difference between a Standard and a Standards-Track specification? It seems
like bad practice to put IANA assignment criterion in the middle of body text
like this.

Section 4.2.2: OK, but what are these "Functional Groups"? Some sort of
subheadings (not necessarily part of the hierarchical numbering) are needed.

Section 4.3.2, for EHLO 450 says "see note above" but it seems unclear what
note how far above.

Section 4.5.3.2: It seems confusing that the first paragraph talks about "each
buffer of the data transfer" but there is only one mail data buffer at the
server for a particular mail message and the subject of 4.5.3.2.5 uses "block"
while the contents of 4.5.3.2.5 uses "chunk" and "TCP SEND call"s.

Section 8.1.1.1, last paragraph: The existing IANA model is intended to
minimize IANA "judgement" and, in general, make IANA's job mechanical. Since
the idea is to avoid name conflicts, this document should request one table
with the assignment model indicated in a column or the like.

Section 8.3, first line: Should be phrased as a request to IANA such as "IANA
is requested to reorganize the Mail Parameters Registry Group as follows:"

Section 8.3, item (1) and Item (4): "should be" -> "is".

Section 8.3, item (2): Should not tell IANA to "consider" anything. Either ask
IANA to do it or don't ask IANA to do it. This is all going to get massaged in
connection with IESG/IANA review anyway. And what IANA cares most about is
clarity and lack of ambiguity.

Section 8.3, item (3): It is generally not IANA's job to review registry names
to judge whether they are "appropriate" which seems like a technical question
rather than a clerical question. Perhaps IANA could chime in on whether a
Registry name was excessively long or confusing similar to another registry or
the like, but if you want to change the registry name, just request IANA to do
that. (Actually, with the change above, all these points are part of a request
to IANA.)

Section 8.3, items (...): Changes in line with the above.

Section 8.3, items (5) and (6): suggest combining these so it is clear what
"Those bullets ..." refers to.

Section 8.3, item (9): Appears to have an open technical question that should
be resolved.

Appendix D: I think this one paragraph of material should be somewhere in
Section 3.7.

Nits
----

Section 1.1, 3rd paragraph: The words that occur to me immediately when I think
of this feature of SMTP is "store and forward". Consider replacing the first
sentence with "An important feature of SMTP is its ability to sequentially
transport mail across a network multiple times, behavior usually referred to as
"store and forward" or "SMTP mail relaying" (see Section 3.6).

Section 1.2, 1st paragraph: Suggest adding a paragraph break between "...
Appendix F." and "This document ..."

Section 2.1, last paragraph, first line: "suggested" -> "discussed" Seems like
more than a suggestion to me.

Section 2.3.6: I think the word "carefully" should be deleted here as
superfluous.

Section 3.5.2: Name of section should include EXPN.

Section 4.1.1: Suggest removing the parenthesis around the parenthetical.  It
seems like a fine top-level sentence and a reader might wonder why it is in
parenthesis. For example, they might somehow think that it weakens the "SHOULD".

Section 4.1.1.1, first 2 words: "These command" -> "EHLO and HELO"

Section 4.1.1.3, 2nd paragraph: I think the word "required" should be deleted
here as superfluous. It also reads a bit oddly.

Section 4.1.2, 2nd paragraph, page 46: There are peculiar extra spaces in the
fourth line of this paragraph, at least in the .txt version. (I understand that
extra white space is needed in the next to last line of the paragraph.)

Section 4.2.4.1, last sentence: delete parentheses.

Section 4.4.1, first sentence: Use of "field" here feels wrong. A field is
usually part of a line. Suggest using "line".

Section 5.1, page 75, first paragraph: "... the SMTP server ..." -> "... an
SMTP server ..."

Section 5.1, page 75, 3rd paragraph: "... preference label," -> "... preference
value," (They are numbers, not strings.)

Section 8.1.1.1: Delete occurrences of "Paragraph 2".

Sections 8.1.1.3 and 8.3: There are many references to “Paragraph 2, Item …” in
these sections. The “Paragraph 2” seems superfluous extra words since the
sections have only one numbered list in each of them and I would have said
there is actually only one paragraph in each of these sections and the list of
items is part of that paragraph.

Matters of Personal Taste
-------------------------

Section 2.3.10, last line: "both sides of them" -> "both of their sides".

Section 4.2.4.2, 2nd line: "follows." -> "follows:"

I dislike the square bracketed number style of references, as opposed to
[RFCxxxx]. It's longer and, as long as the RFCs in the References section are
in numeric order, which they always should be, not significantly faster or
easier to look up.

I would replace all references to ANSI X3.4-1968 with references to RFC 20.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com