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@xxxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
