Ballot for draft-ietf-emailcore-as
Discuss
Yes
No Objection
Summary: Has 5 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
* Very many of the references appear that they should be normative and not informative. And possibly with a downref needed for RFC6973 if it's normative. * I'm not sure why this is standards track. It really seems like a BCP. Many of the recommendations are based on current deployment and adoption of standards, which will evolve in time. That seems best suited to "Best *Current* Practice". Why is that not the case? In defense of the 'MUST NOT' for confidentiality, Barry Leiba said: > The issue has to be put into the perspective of what *this document* > is meant to do. Again: this document is an Applicability Statement > that's telling implementers and deployers what they need to do in > order to interoperate on the Internet *today*. emphasis from Barry Leiba. There are more references to current deployment.
I do want to express my thanks to the editors for a well written draft; and after reading all the last call comments, I believe I understand the position of the WG and the editors and that this is a consensus draft. Thanks to Shivan for the SECDIR review and Murray K. for the shepherding doc. * I support Deb's discuss. I believe that the 'MUST NOT' in 6.5 is too strong and would be better suited to a statement such as: "Implementations MUST continue to include an option to receive email without requiring confidentiality. Local deployments MAY choose to require confidentiality by requiring STARTTLS before fully accepting an email under the consideration that such a choice would be actively blocking valid non-malicious mail traffic." * I also agree with Roman's discuss; the applicability of this appears to be open-Internet operation? In the last call traffic there was some comments about local operation (within a domain) vs external acceptance. This nuance, when appropriate, doesn't seem to be well reflected in this document.
Section 6.5, last para: I understand that this is the hotly contested part of the specification. In this day and age, having strong language for not protecting traffic across the wire is irresponsible (my opinion, but it is why they pay me). I'm objecting to the strength of the language, not the existence of a 'way out of the situation' language. My comments/options are these: - I do think that #1 and #2 above are capable of standing alone, one could merely delete the last para - I think that the 'MUST NOT' is incredibly strong and a 'softer' term will also work, be that a 'MAY NOT' or something 'not BCP 14'ish like 'can not'. - The other tact to take here is to turn it around and encourage SMTP-senders to 'SHOULD' implement the capability to encrypt (or protect) messages (with the second to last para providing rationale). Section 9: Of course, this might be the perfect (better?) place to explain the risk that a SMTP-sender takes by not implementing the capability to encrypt (or otherwise protect) the data as it traverses the Internet. I would be happy to help with this language.
Thanks to Shivan Sahib for their multiple secdir reviews. Section 6.1.2: s/man-in-the-middle/person-in-the-middle. Section 6.1.3: Is this specification encouraging support for these protocols? If so, it is hard to discern from the current text. A simple change to the last sentence would make it more obvious. Perhaps '...in this section is increasing, and encouraged, but is not yet...'. Of course, I assume that reducing the opportunity of a 'person-in-the-middle' attack is a good thing. References: I suggest leaving a note for the RFC Editor to replace RFC8446 with RFC9846 (draft-ietf-tls-8446bis, currently in Auth48) should it be published prior to this specification. References: While RFC9325 is listed, it might be more prudent to list BCP195, which loops in deprecations and will mandate TLS1.3 when draft-ietf-uta-require-tls13 (in Auth48) is published.
# Éric Vyncke INT AD comments for draft-ietf-emailcore-as-29 CC @evyncke Thank you for the work put into this document, it is probably long due... Please find below some blocking DISCUSS (but easy to fix), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Murray Kucherawy for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-emailcore-as-29-intdir-telechat-von-hugo-2026-06-28/ (mainly minor nits) Other thanks to Dave Lawrence, the DNS directorate reviewer: https://datatracker.ietf.org/doc/review-ietf-emailcore-as-29-dnsdir-telechat-tale-2026-06-24/ I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Section 2.4 Why not a "MUST" in `All of those SHOULD be supported` as this sounds like a good action. See also: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ ### Section 3.3 Why not a "MUST" in `When performing such functions, the MUA SHOULD` as this sounds like a good action. See also: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
## COMMENTS (non-blocking) ### Use of "we" Who is the "we" in sections 4.1 and 6.1 ? The authors ? The WG ? The IETF community ? Please avoid ambiguities. ### No Happy Eyeball discussion I find it very sad that I don't see any discussion about RFC 8305 (Happy Eyeball) that could have been used to give a slight preference to IPv6 over IPv4 when resolving/connecting to a MX. ### Section 2.1 s/record/ressource record/ (to be pedantic) ### Section 6.5 As the issue has been raised to a DISCUSS level by other ADs, I will only support these DISCUSS about `In order to maximize interoperation and avoid refusal of legitimate messages, SMTP-receivers MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms.` A "SHOULD NOT" is probably better (and the "in order..." is the required IESG BCP14 guidance).
Thanks to the authors and the WG for their work on this document. There is the point about normative references that Gunter has raised in his ballot as a comment. I am bringing it up as a discussion point while trying to list (but there were too many and I could not finish) the references that should be classified as normative based on my reading (I could be wrong, happy to be corrected). [I-D.ietf-emailcore-rfc5321bis] [I-D.ietf-emailcore-rfc5322bis] [RFC2034] [RFC2920] [RFC3207] [RFC3464] [RFC4954] [RFC5248] ... I apologize but I ran out of time at this point :-( I trust the authors will review the list and correct the classification.
I would also like to request the authors to cross-check if some the following (and there may be others) should use their BCP14 keyword equivalents. "This is particularly important for software that validates user-input fields, where case changes are tempting, but must be avoided." "This is actually just a special case of a principle, discussed in Section 2.3.11 of [I-D.ietf-emailcore-rfc5321bis] and elsewhere, that nothing other than the final delivery system should attempt to interpret or alter the local-part of an address. In particular, they MUST NOT:" .... please consider if the first sentence is framed as a SHOULD NOT for other that the final delivery system. "As already specified in Section 4 of RFC 4954, cleartext credentials MUST NOT be sent without TLS, and deployments should require use of an effective confidentiality mechanism, with SMTP AUTH such as TLS." ... perhaps SHOULD or RECOMMENDED instead of the should?
** The guidance and observations on the use of confidentiality are not self-consistent and lead to risky guidance. (a) Section 2.4 says “As a result, the following extensions MUST be supported by SMTP senders and receivers: * Secure SMTP over Transport Layer Security [RFC3207]” – I take this to mean all senders and receivers conformant to this document must have support for STARTTLS (b) Section 6.1.2 says “Most modern implementations of SMTP support this [opportunistic encryption] method and so a substantial portion of email traffic is encrypted during its time transiting from the client to the next server.” – I take this to mean that there are a minority (since this text says “most”) of “modern implementations” which don’t conform to this draft, since conformance means supporting STARTTLS. This language appears to be consistent with (a) acknowledging that implementers and operators may make choices contrary to the RFC’s guidance. (c) Section 6.3 says “ … and deployments should require use of an effective confidentiality mechanism, with SMTP AUTH such as TLS.” – I take this to mean servers and receivers should have some kind of confidentiality mechanism. We know from the constraints imposed by (a), every conformant sender and receiver minimally supports STARTTLS. This language is consistent with (a). (d) Section 6.5 say “there are many implementations of SMTP that are still in widespread use in both private and Internet-connected networks that either do not support over-the-wire confidentiality or that are configured to not use it when sending messages” – This may be true, but these implementations are already non-conformant to this draft on the requirements set out in (a). This is the first introduction of consideration for “private networks”. (e) Section 6.5 says “In order to maximize interoperation and avoid refusal of legitimate messages, SMTP-receivers MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms. While that provision is extremely important to promote delivery of legitimate messages whenever possible, mechanisms that provide confidentiality are still strongly preferred when they are feasible.” -- This is the start of my confusion. Why can’t SMTP-receivers require over-the-wire confidentiality? Support for STARTTLS is already mandatory to support. From the perspective of this draft, each sender has at least one viable confidentiality approach. If a sender doesn’t support STARTTLS, then it is already not conformant to this draft. It isn’t clear why normative, interoperability language is being written to cover non-compliant behavior on this issue. If this is about tracking reality, why is it acceptable to require STARTTLS in (a), but then note in (b) and (d) that this isn’t really supported in certain instances. ** As Section 6.5 alludes to both private and public networks sending email (see text quoted in (d) and (e) above, and my next discuss point on this applicability statement being unclear in applicable domain), why are there interoperability concerns on a private network requiring weak security practices? Why can’t the private network operator have autonomy to set local policies, to include implementation of confidentiality? ** Consistent with Deb Cooley’s DISCUSS position, this document is leaving a security issue by allowing clear-text SMTP for conformant end-points. Rather than allowing local policy to accept risk (e.g.,“SHOULD use a confidentiality mechanism”) or enabling the feature they are already required to support (aka, “MUST use a confidentiality mechanism”), this text is taking the choice out of the hands of operators who want to be conformant and forcing risky behavior (aka, “MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms”). This is inconsistent with ** The “applicability domain” element of an applicability statement seems to be missing. This document is an Applicability Statement [RFC2026], Section 3.2 that provides guidance in the use of the Internet's core email specifications, the Simple Mail Transfer Protocol (SMTP) What is the “applicability domain” of this set of recommendations? Is it the “public internet”? Do they apply to a closed intranet? Sections like the following refer to the public internet, but others do not. There is also a reference to private networks. To what kind of networks does this document apply? -- Section 2.2. Use of Address Literals, “The address-literal ABNF non-terminal is used in various places in [I-D.ietf-emailcore-rfc5321bis] grammar. However, for SMTP connections over the public internet, …” -- Section 4.3. “Where those other rules allow syntax variations that the IETF specifications cited above do not, those variations should be avoided because they are unlikely to be accepted across the Internet email environment.” -- Section 6.5. “That said, there are many implementations of SMTP that are still in widespread use in both private and Internet-connected networks”
Thank you to Vijay Gurbani for the GENART review. I support the DISCUSS positions of Deb Cooley and Ketan Talaulikar. ** Section 2.3 2.3. Use of Addresses in Top-Level Domains Hence, for reliable service, mail SHOULD NOT use addresses that contain single label domains. An unqualified SHOULD NOT. When is it appropriate to use such addresses? ** Section 2.4 Similarly, the following extensions SHOULD be supported by SMTP senders and receivers: * Command Pipelining [RFC2920] * Internationalized Email [SMTPUTF8] Delivery Status Notifications [RFC3461] requests, while recommended and useful if supported, have not been widely implemented and deployed. Mail systems that send such requests should be prepared for systems that receive them to not recognize or support them. Note that this extension for notification requests is distinct from the format of notifications defined in [RFC3464] and [RFC6533], and the special media type defined in [RFC6522]. All of those SHOULD be supported. -- “SHOULD” both senders and receivers support RFC3461, RFC3464, RFC6533, and RFC6522? The text isn’t clear. For RFC2920 and SMTPUTF8, a crisper statement of applicability for the sender and receiver is made. -- These are all “unqualified SHOULDs” on implementers. When can this advice be ignored? ** Section 3.1 In particular, use of empty quoted strings is discouraged in "received-token" (a component of a Received header field) and "local-part" (left hand side of email addresses). What does this guidance mean relative to interoperability? Discouraged isn’t even a defined key word. This can be ignored, then? Should s/discouraged/SHOULD NOT/ ** Section 3.3. Unqualified SHOULD When performing such functions, the MUA SHOULD: * Remove all header fields unknown to the MUA * Remove any header fields that are only pertinent to the transport of the original message, such as trace header fields (see Section 3.6.7 of [I-D.ietf-emailcore-rfc5322bis]) When should this not be done by the MUA? ** Section 3.4 3.4. Group Syntax "Group" syntax [I-D.ietf-emailcore-rfc5322bis] [RFC6854] has been a long-standing construct in the specification, going back to RFC 822 [RFC822], but it has had little use in all that time. It is therefore possible that use of it in a message will conform with the specifications but not be supported by some implementations. What is an implementer/operator supposed to do with this guidance beyond what is already documented in other RFCs? What novel guidance is provided here? ** Section 4.1. It isn’t clear how an implementer is supposed to interpret this section. On the one hand the text points out that local-part “MUST be treated as case sensitive” but then roughly says ignore that advice if you want “maximum interoperability”. Are there other places where normative, mandatory guidance should be ignored for “maximum interoperability”? ** Section 4.1 Since only the final delivery system can properly interpret the local-part of an address, originating and transit/relay mail systems are discouraged from making any assumptions as to address equivalence or from making any changes to local-parts containing such delimiters. Same feedback as in Section 3.1. What does discouraged mean? When is it acceptable to modifier content with delimiters? ** Section 5. As a result, IMF generators and parsers are expected to support MIME. What does “expected” mean? Is this MIME support mandatory?
Thanks to Valery Smyslov for the ARTART review.
Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-emailcore-as-29 # Normative reference classification looks wrong. The draft has only RFC2026, RFC2045, RFC2119, and RFC8174 as normative references. Section 2.4 says SMTP senders and receivers MUST support STARTTLS/RFC3207 and 8BITMIME/RFC6152, and SHOULD support PIPELINING/RFC2920 and SMTPUTF8. These are currently informative references. That seems incorrect. # Core protocol references are informative, but the AS depends on them normatively. The document is an Applicability Statement for SMTP and IMF and repeatedly uses 5321bis/5322bis as the basis for syntax and behavior. They are currently informative. Given the AS makes recommendations that depend on those specs, I would expect both I-D.ietf-emailcore-rfc5321bis and I-D.ietf-emailcore-rfc5322bis to be normative. # Section 2.1: EHLO domain reverse/forward matching guidance is operationally common, but “may refuse” is lowercase. If intended as protocol advice, consider MAY. # Section 2.3: The 2025 TLD MX numbers are empirical. Consider citing the source or method, not only RFC7085. # Section 3.1: “empty quoted string” should probably be “empty quoted strings” in one sentence. # Section 3.3: “Remove all header fields unknown to the MUA” may be too strong operationally; this risks deleting extension fields that should be preserved. Consider “fields that are unsafe or not understood in this reuse context”. # Section 4.3: “implementations are encouraged to strip trailing dots” could conflict with “do not alter local-parts” principles, though this is domain-part only. Consider saying this applies only during input normalization before SMTP use, not in transit. # Section 5: If IMF generators/parsers are “expected to support MIME”, RFC2045 as normative is OK, but MIME is more than RFC2045. Consider whether RFC2046/2047/2048/2049 should be cited. # Section 6.2: DMARC reference should likely be updated from RFC7489 to RFC9989. Kind Regards, Gunter Van de Velde Routing Area Director
Section 6.5, Confidentiality Requirements, MUST items and MUST NOT paragraph: 708 > 1. confidentiality (for example, the STARTTLS extension) MUST be 709 > implemented by SMTP servers in order to at least provide over- 710 > the-wire confidentiality during an individual SMTP exchange, and 711 > 712 > 2. confidentiality MUST be used when sending if it is available and 713 > accepted by the receiving server. 714 > 715 > That said, there are many implementations of SMTP that are still in 716 > widespread use in both private and Internet-connected networks that 717 > either do not support over-the-wire confidentiality or that are 718 > configured to not use it when sending messages. Hence, receiving 719 > server implementations will often be expected to be capable of 720 > receiving such messages. 721 > 722 > Therefore: 723 > In order to maximize interoperation and avoid refusal of legitimate 724 > messages, SMTP-receivers MUST NOT require SMTP-senders to use over- 725 > the-wire confidentiality mechanisms. While that provision is 726 > extremely important to promote delivery of legitimate messages 727 > whenever possible, mechanisms that provide confidentiality are still 728 > strongly preferred when they are feasible. Setting aside Deb Cooley's DISCUSS on the appropriateness of the "MUST NOT" itself, my concern is about the internal logical gap the text leaves open. Item 2 already requires senders to use TLS whenever it is "available and accepted by the receiving server." When that condition is met, the sender is under a MUST obligation. The "MUST NOT require" in the final paragraph is therefore most relevant to the case where the sender lacks TLS capability altogether. The text does not state this explicitly: it says SMTP-receivers MUST NOT require confidentiality without explaining that the underlying rationale is to accommodate senders that are incapable of providing it. As written, a reader could reasonably (if incorrectly) infer that the MUST NOT overrides Item 2 -- i.e., that a sender that has TLS capability may nonetheless forgo it because the receiver is forbidden from insisting on it. I believe making the scope of the MUST NOT explicit (e.g., "...in order to ensure delivery from senders that do not support over-the-wire confidentiality") would reduce the confusion that has surrounded this section through multiple revisions. --- Section 9, Security Considerations: 751 > Security and privacy considerations are discussed throughout this 752 > document as they pertain to the referenced specifications. Special 753 > note should be taken of the interaction between confidentiality and 754 > authentication mechanisms that are applicable to Internet links and 755 > therefore potentially sensitive to the multi-hop design of SMTP. 756 > Unless the relevant messages and mechanisms are protected from 757 > tampering or content exposure on systems that are the endpoints of 758 > those links, the security of the mechanisms depends on trust in those 759 > intermediate endpoints. For a document that imposes MUST-level security requirements (implement TLS, use TLS when sending, never send cleartext credentials without TLS), I find this five-sentence section inadequate. Per RFC 3552, security considerations should enumerate the threats being mitigated and the residual risks remaining after the prescribed mitigations are applied. In my view, this section should at minimum: (a) identify the threats that the MUST requirements address (e.g., passive monitoring per BCP 188, active MITM attacks against opportunistic TLS), (b) describe the residual risk when the MUST NOT for receivers accommodates cleartext delivery (an unprotected link in the SMTP hop chain remains fully exposed), and (c) note what this document does not protect (e.g., confidential storage at intermediate MTAs, end-to-end content protection). Deb Cooley has offered to help with language here; I would welcome that addition. --- Section 6.2, Message-Level Authentication, DMARC bullet: 643 > * DMARC [RFC7489] relies on SPF and DKIM to allow for validation of 644 > the domain in the visible From header. I concur with Gunter Van de Velde's comment here. --- Section 3.3, Reuse of Existing Messages, first SHOULD bullet: 336 > When performing such functions, the MUA SHOULD: 337 > 338 > * Remove all header fields unknown to the MUA The advice to remove ALL unknown header fields strikes me as broader than intended. Many deployed email systems carry extension header fields (for filtering, classification, threading, or protocol purposes) that are not understood by every MUA but play a role in the delivery or handling ecosystem. Blanket removal would silently discard these fields, potentially breaking downstream processing. The second bullet already handles trace fields specifically. I would suggest the first bullet be narrowed -- for example, to fields with transport semantics or privacy implications that are meaningless or potentially harmful in the context of a re-used message -- or that a brief rationale be added explaining why removal of all unknown fields is nonetheless the right policy here. --- Section 5, Use of Multipurpose Internet Mail Extensions (MIME): 503 > MIME features such as non-textual message bodies, multi-part message 504 > bodies, and the use of character sets other than US-ASCII in message 505 > bodies have become nearly ubiquitous in contemporary email. As a 506 > result, IMF generators and parsers are expected to support MIME. The phrase "are expected to support MIME" uses informal language where a formal BCP 14 requirement level seems intended. Since RFC 2045 is already listed as a normative reference, I would suggest replacing "are expected to" with "MUST" or "SHOULD" (depending on the intended strength) to be consistent with the rest of the document's normative guidance.
# IESG review of draft-ietf-emailcore-as-29 CC @MikeBishop ## Comments ### Intended Status This reads very much like a BCP. What new protocol elements does it define that make it Standards Track, rather than "how best to use the existing SMTP specs" guidance? ### Section 6.5, paragraph 7 It seems to me that "maximize interoperation" and "avoid refusal of legitimate messages" are the explanations that would generally accompany a SHOULD NOT. There are bad results if you don't follow this guidance, so beware if you make that choice. Therefore, I question making this a MUST NOT. That is to say, I support Deb's DISCUSS. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `man`; alternatives might be `individual`, `people`, `person` * Term `traditional`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Outdated references Reference `[RFC7489]` to `RFC7489`, which was obsoleted by `RFC9989`, `RFC9990`, and `RFC9991` (this may be on purpose). Reference `[RFC822]` to `RFC822`, which was obsoleted by `RFC2822` (this may be on purpose). ### Grammar/style #### "Table of Contents", paragraph 1 ``` order to promote interoperability amongst senders, receivers, and intermediar ^^^^^^^ ``` Do not mix variants of the same word ("amongst" and "among") within a single text. #### Section 1.1, paragraph 1 ``` gainst spam and other attacks. In addition SMTP (and Message Format) extensio ^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "addition". #### Section 2.2, paragraph 1 ``` have never been widely used nor well supported. In 2013 [RFC7085] found 18 TL ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 2.4, paragraph 8 ``` d header field) and "local-part" (left hand side of email addresses). For ex ^^^^^^^^^ ``` Did you mean the adjective "left-hand"? #### Section 3.3, paragraph 1 ``` of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementatio ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 4.3, paragraph 7 ``` h as non-textual message bodies, multi-part message bodies, and the use of c ^^^^^^^^^^ ``` This word is normally spelled as one.
Thanks to the authors for the effort put into this AS. Thanks also to Jürgen Schönwälder for the OPSDIR review.
I strongly support the existing DISCUSS ballots, especially with regards to requiring support for unprotected communication, but that point has already been well-made. I presume the reference re-classification will be trivial editorial work that requires no further commentary. I have no other concerns.