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 Almost Ready.

This is a re-review for version -38. I previously reviewed version -32
of this draft. Thanks for adopting most of my comments thus resolving
them. My apologies for the tardiness of this review. Not sure if it
even still useful at this point...

This document is an obsoleting revision of RFC 5321 on the Simple Mail
Transfer Protocol (SMTP), incorporating Errata, etc., that also
obsoletes RFCs 1846, 7504, and 7505.  It is a mix of specification,
operational, historic, and motivational information.  Changes from RFC
5321 are summarized in Appendix E. I did not review the
Acknowledgements or References sections or Appendices C or D. I mostly
looked at my previous comments and at the changes from -32 to -38.

Security
--------

The Security Considerations, Section 7, is improved and I consider it
acceptable. It defers much of Security to the "Applicability Statement
..." which is tolerable but seems to me to imply that the name of that
document should be changed to "Applicability Statement and Security
Considerations for IETF Core Email Protocols" or the like. The
Security Considerations section is certainly long enough and now
mentions all essential subtopics for SMTP security.

However, I still cannot understand why this document briefly mentions
(not discusses), in one sentence, PGP, S/MIME, and RFC 1847 but,
despite requests, does not mention any of DKIM / SPF / STARTTLS /
DMARC. Note that I am not asking for discussion of these protocols,
just that they be mentioned to roughly the same extent that PGP and
S/MIME are. Whenever I asked for this before, multiple responses from
multiple people have misrepresented me and claimed that I am asking
for a discussion of DKIM, etc., in this document. Thus far all of my
responses that I am merely asking for a mention have been ignored so
maybe if I am sufficiently verbose and say several times that I am only
asking for a mention, for one sentence to be added to this quite long
and verbose document, and that I am not asking for a discussion, it
will get through because that is all that I am doing, asking for a
mention and not a discussion.

Minor Issues
------------

There really should be subheadings on the groups in Section 4.2.2. It
is a little difficult at this point to determine why RFC 821
omitted these but I think it was simply an oversight or lack of
time. I continue to believe this section has some very small positive
value as it is but would be more valuable with subheadings.

While I understand it is too late to fix it, this document fails to be
a crisp protocol specification for implementers. Ideally, the protocol
specification (augmented by some crisp constructs such as a state
machine / table), the operational considerations, and the extensive if
diffuse historical information, would be in separate
sections/documents.

IANA Considerations
-------------------

The author asked me to look at the IANA Considerations. I'll try to
send a separate message on that soon.

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