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.

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.

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

(Revised ballot from position on -40) 

No additional feedback on versions -41/-42.

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 ?