Session Date/Time: 07 Mar 2023 17:00

EMAILCORE

Summary

The EMAILCORE interim meeting made progress on several open issues across the 5321bis, 5322bis, and Applicability Statement (AS) documents. Key discussions revolved around clarifying the syntax and operational semantics of Trace header fields, their IANA registration, and appropriate guidance for Mail User Agents (MUAs). Decisions were made to refine existing text and delegate specific review and drafting tasks to address lingering concerns, with a cautious optimism that the working group is moving towards concluding these documents.

Key Discussion Points

Issue 74: Syntax for Received: Header Fields:
- The discussion focused on clarifying the existing text in 5322bis regarding the syntax for Received: header fields, explicitly stating that it is defined in 5321bis when used by SMTP.
- Pete Resnick noted the text might be repetitive but acceptable. John Levine confirmed it addresses concerns about potential conflicts between 5322bis and 5321bis.
- Dave Crocker raised a point about layer confusion if the transport isn't SMTP, to which Pete Resnick clarified that 5322bis doesn't normatively reference 5321bis but provides a broad syntax that 5321bis can further restrict.
- Decision: General agreement to clarify the text as proposed, emphasizing the definition in 5321bis for SMTP usage.
Optional Field in Top-Level ABNF for Header Fields (Issue 86):
- The working group revisited a previous decision to retain an "optional field" in the top-level ABNF for header fields, which raised concerns about encouraging new block types beyond Trace: and Received:.
- Pete Resnick explained that Trace: fields are already extensible, and Received: blocks don't require this top-level extensibility. He argued that the "optional field" was an error introduced in 5322bis and wasn't present in 2822.
- Dave Crocker concurred that it was likely an unintended addition in 5322bis.
- Decision: There were no objections to removing the top-level "optional field" from the ABNF, correcting what was identified as a past mistake.
IANA Registration Procedure for Trace Fields (Issue 86 related):
- A central point of contention was where the IANA registration procedure for annotating Trace fields (i.e., a flag in the message header field names registry) should reside: 5322bis, the AS, or a new document.
- John Levine advocated for 5322bis, arguing that fundamental registration instructions belong in base documents.
- Pete Resnick expressed reservations about adding new semantics of "Trace" to 5322bis (an Internet Standard track document), leaning towards the AS or a separate document due to the operational implications that might need to be defined.
- Dave Crocker strongly stated that an Applicability Statement should discuss application, not define core technology or registries. He suggested that if "Trace" is merely a flag in the existing registry, 5322bis could accommodate it.
- Decision: Tentatively agreed to move existing IANA registration text related to Trace fields from John Levine's draft to Pete Resnick's 5322bis document to test if it "sticks." The group acknowledged that further discussion on operational considerations might revisit this decision.
Appendix B in 5321bis: Generating SMTP Commands from IMF Header Fields:
- The group considered whether Appendix B of 5321bis needed updating regarding submission processes.
- John Levine reported a lack of substantive comments on the mailing list, suggesting the current text, with minor tweaks for terminology, is largely correct.
- Action Item: John Levine and Camilo Ruiz were asked to double-check the text.
Operational Requirements in 5321bis (Sections 7.8, 7.9, 6.2):
- Review of sections 7.8 ("Local Operational Requirements and Resistance to Attacks") and 7.9 ("Scope of Operations of SMTP Servers") in 5321bis, along with pointers from section 6.2.
- Action Item: Camilo Ruiz and John Levine were asked to double-check these sections. A specific deadline for review will be set by the chair.
Applicability Statement Issues: Trusting Received: Header Fields (Issue 85):
- Discussion on text for the AS that advises users to trust only self-inserted Received: fields and exercise caution with conclusions derived from other agents' insertions.
- Dave Crocker suggested recasting the text to define what Received: fields are and are not useful for, rather than focusing on distrust.
- Action Item: Dave Crocker offered to propose alternative text for this section of the AS.
Applicability Statement Issues: Trace Header Field Use in MUAs (Issue 84):
- A proposal was made to recommend that MUAs strip Trace header fields when performing an "edit as new message" operation.
- John Levine and Dave Crocker noted that this topic extends beyond just Trace fields and touches on broader MUA principles for message generation, which the WG has historically avoided specifying in detail.
- John Levine suggested reframing the text to advise MUAs to be careful about clearing out irrelevant header fields from the previous message, using Trace fields as an example.
- Action Item: John Levine will propose rephrased text for the AS on MUA behavior when creating new messages from old ones, covering the stripping of old header fields (with Trace fields as an example).
Applicability Statement Issues: What Constitutes a Trace Field / Operational Implications (Issue 86 related):
- Further discussion on the definition and implications of a Trace field, particularly in the context of the registry flag.
- A sense of those present indicated a preference for minimalist text in 5322bis to define Trace fields as "informational stuff that is put into the message as it traverses different systems," with the AS addressing operational guidance (e.g., MUA stripping under certain conditions, trustworthiness warnings, the "topmost" property).
- Decision: General agreement to pursue minimal text in 5322bis and elaborate on operational aspects and trustworthiness in the AS.
- Action Item: Pete Resnick and John Levine will collaborate on refining this text for both 5322bis and the AS.
Applicability Statement Issues: Use of TLS with SMTP and Submission (Issue 83):
- The need to clarify the relationship between SMTP, submission, and TLS usage in the AS was discussed, specifically addressing potential loose ends regarding TLS and "no protection in storage."
- John Levine emphasized the importance of avoiding over-promising security benefits ("hop-by-hop TLS is not sufficient for protection") and applying similar caution to other technologies like DANE/DMARC.
- Action Item: John Levine volunteered to review the text on TLS use in the AS, focusing on accurate portrayal of security implications and limitations.

Decisions and Action Items

Issue 74 (Received: Syntax): Clarify text in 5322bis that Received: header field syntax is defined in 5321bis when used by SMTP.
Optional Field in Top-Level ABNF: Remove the top-level "optional field" from the ABNF in 5322bis.
IANA Registration for Trace Fields: Tentatively move existing IANA registration text related to Trace fields from John Levine's document to 5322bis. Further operational discussion may revisit.
Appendix B Review (5321bis): John Levine and Camilo Ruiz to double-check the text.
Operational Requirements Review (5321bis): John Levine and Camilo Ruiz to double-check sections 7.8, 7.9, and 6.2.
Issue 85 (Trace Field Trustworthiness in AS): Dave Crocker to propose alternative text for the AS.
Issue 84 (MUA Stripping Trace Fields in AS): John Levine to propose rephrased text for the AS.
Issue 86 (Trace Field Definition/Implications): Pete Resnick and John Levine to collaborate on refining text for 5322bis (minimal definition) and the AS (operational guidance).
Issue 83 (TLS Use in AS): John Levine to review text on TLS use in the AS, focusing on avoiding over-promising security and clarifying limitations.

Next Steps

The chairs will set specific deadlines for the volunteers to review and propose new text.
The working group aims for earlier revisions of 5321bis and 5322bis based on these changes.
Chairs will actively nudge participants to conduct thorough reviews before the working group enters Last Call, particularly for 5321bis, to ensure consistency across the documents.