Markdown Version | Session Recording

Session Date/Time: 03 Dec 2024 16:00

EMAILCORE

Summary

The EMAILCORE working group met for an interim session to review progress on draft-ietf-emailcore-5321bis (d-36), discuss outstanding Gen-ART and Seg-Art review comments, and prepare for a Working Group Last Call. Key discussions included minor textual clarifications, the handling of EHLO/HELO, managing partial failures, and the integration of security-related extensions. The group reached consensus on several textual changes and outlined a path towards WG Last Call and subsequent ISG review for 5321bis, alongside plans for the emailcore-as document.

Key Discussion Points

• d-36 Review and Updates:
  • draft-ietf-emailcore-5322bis is considered stable.
  • draft-ietf-emailcore-5321bis (d-36) was the primary focus, with John reported to have addressed various comments in the latest version.
  • Reply Code Function Groups: John's changes to rearrange the section on reply codes by function group, based on the second digit as per RFC 821, and add clarifying text were accepted without objection.
  • ETURN Mention: The addition of a sentence mentioning ETURN when describing TURN was noted as non-controversial.
• EHLO vs. HELO Clarification:
  • A Seg-Art review suggestion was to explicitly add "or HELO" wherever EHLO was mentioned.
  • An alternative proposal by John, focusing on clarifying that HELO also resets transactions (like EHLO) in two specific places, was discussed.
  • The sense of those present was to adopt John's more minimal change, to avoid potential human error and introduce unnecessary verbosity by making widespread changes.
  • The suggestion to deprecate HELO was discussed and generally dismissed as unnecessary and potentially risky.
• Partial Failures/Success Ordering (Section 4.1.1.4):
  • A Gen-ART comment highlighted confusion in the paragraph order regarding partial failures, message acceptance, and partial success.
  • The proposal to swap the last two paragraphs in this section was accepted as it improved clarity without introducing unintended consequences.
• "MUST NOT lose message for frivolous reasons" Text:
  • The original text was identified as problematic.
  • Two alternative proposals were considered: one from Brøn and Todd using normative language, and another from Dave Crocker using non-normative language and explicitly mentioning discarding messages for good reasons.
  • A specific point of concern was whether to include "disk failures" as a frivolous reason.
  • A sense of those present indicated a slight preference for Brøn and Todd's version, which retains the normative "MUST" statement, as it was considered an interoperability issue. It was also agreed that "disk failures" should be dropped or reworded, and consistency between "piece of mail" and "message" should be addressed.
• "if content conforms to other contemporary standards" Text:
  • A Gen-ART query about the meaning of this phrase led to clarification regarding historical context where different content formats were allowed.
  • Two proposals for rephrasing were presented, with the second version, which more explicitly states expectations for header and content format on the public internet, receiving a slight preference. A minor textual adjustment (adding a comma) was suggested for readability.
• Security Related Extensions and References:
  • Concerns from security area directors about SMTP spoofability and the need to reference modern security practices (e.g., StartTLS, DKIM, SPF) were discussed.
  • There was strong opposition to including specific named extensions (especially DKIM, SPF) normatively in 5321bis, as they do not directly affect how SMTP works (unlike ESMTP UTF8, 8BITMIME, BDAT). DKIM/SPF were seen as potentially more relevant to 5322bis or subject to ongoing debate about their utility.
  • General statements about "channel security" were considered acceptable, but specific normative references to StartTLS or other tunneling mechanisms were deemed problematic for this document, particularly due to the complexity of hop-by-hop security in SMTP and the potential for a "deadly embrace" with forward references to the AS.
  • A suggestion to reference RFC 8314 (cleartext email obsolete) was rejected, as it primarily concerns message submission, not backbone SMTP, and is outside the scope of 5321bis.
  • The existing informative reference to the Applicability Statement (AS) in 5321bis was highlighted, with the understanding that the AS could contain more detailed security discussions.

Decisions and Action Items

• Function Group Clarification: Adopt John's d-36 changes to the reply code function group section and ETURN mention.
• EHLO/HELO Clarification: Adopt John's specific textual changes to clarify HELO's transaction reset behavior, rather than adding "or HELO" everywhere.
• Partial Failures/Success Paragraph Order: Swap the last two paragraphs in Section 4.1.1.4 of draft-ietf-emailcore-5321bis.
• "MUST NOT lose message..." Text: Adopt Brøn and Todd's proposed version, retaining the normative "MUST" language.
  • ACTION (Chair): Post to the mailing list regarding dropping or rewording "disk failures" in this context and standardizing usage between "piece of mail" and "message."
• "if content conforms to other contemporary standards" Text: Adopt John's Proposal 2, incorporating the suggested comma for improved readability.
• Security Extensions: Remove explicit references to specific security extensions (e.g., DKIM, SPF) from 5321bis. Maintain general discussion of channel security, avoiding normative references to specific mechanisms like StartTLS within 5321bis. The Shepherd's write-up for 5321bis will suggest that emailcore-as be read alongside for review. Rob's suggestion to reference RFC 8314 is rejected for 5321bis.
• ACTION (John): Incorporate all agreed-upon changes into draft-ietf-emailcore-5321bis (d-37).
• ACTION (Chair): Post d-37 to the mailing list for review and issue an explicit call for review of the minutes and d-37. Engage Rob on the mailing list regarding his security concerns, directing him to the AS document for detailed discussion.

Next Steps

• 5321bis Working Group Last Call:
  • John aims to post d-37 by the end of the current week or weekend.
  • The chairs will initiate a one-week Working Group Last Call for d-37, targeting completion by December 13th.
  • Todd will aim to open the ISG ballot for 5321bis before December 21st.
• Applicability Statement (emailcore-as) Interims:
  • The group agreed to schedule interims specifically for the emailcore-as document.
  • ACTION (Chair): Propose dates for January and potentially February interims for emailcore-as on the mailing list.
  • The realistic expectation is that 5321bis and emailcore-as will need to be published as a cluster due to the informative references between them.