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

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.

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 ?

Thank you for addressing my DISCUSS feedback and also the feedback from Paul.

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.

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."

No objection from transport protocol specific issues, but I would like to see Paul's concerns are addressed. Hence, supporting his discuss.