Session Date/Time: 11 Feb 2025 16:00

EMAILCORE

Summary

The EMAILCORE working group held its second interim meeting to discuss the progress on the Applicability Statement (AS) and the 5321bis documents. Key discussions revolved around resolving open issues in the AS document, particularly concerning email address syntax, STARTTLS requirements, and the distinction between hop-by-hop and end-to-end security. Significant attention was also given to the IANA considerations for 5321bis, leading to a proposal for a new, separate document to address existing registry inconsistencies and future maintenance. The working group aims to finalize 5321bis and the AS document for publication soon.

Key Discussion Points

AS Document Status and Open Issues:
- Six open tickets have been closed based on version 12 text, with no objections raised.
- Issue 93 (SMTP AUTH): Text proposed for section 6.5. A participant noted a conflict where the document states SMTP AUTH is out of scope but then discusses and recommends it. It was suggested to open a separate issue to determine if SMTP AUTH should remain in scope.
- Issue 112 (Introductory Text): Text originally for 5321bis was merged into the AS, serving as an introduction to Section 6 on confidentiality and authentication. This was considered non-controversial.
- DKIM Reference (Issue 110): While a reference exists, it was suggested to improve the explanation of DKIM's function and potentially mention ongoing discussions (e.g., DKIMv2) that challenge its implied effectiveness.
- Quoted Strings: Text related to keywords in examples was removed. An example of an empty quoted string in a display name was added. The reintroduction of text and examples for empty quoted strings in the local part was proposed and largely accepted based on clarification that empty quoted strings never work, while other quoted strings generally do.
- C-name handling (Issue 92): Clarification was added in 5321bis, but proposed text for the AS has not yet been provided by the designated participant.
- Message Authenticity (Issue 130): It was noted that 5321bis discusses OpenPGP and S/MIME for authenticity, while the AS primarily focuses on confidentiality. The AS needs to cover both.
- Header Protection (Issue 131): With S/MIME potentially allowing encryption without header protection, it was suggested that the AS reference additional documents like the "Slums header protection" document (currently in the IESG queue) for comprehensive header protection.
WhatWG ABNF Reference in AS:
- The AS document currently references a WhatWG document for recommended email address syntax. Concerns were raised that this syntax is "broken" by IETF standards (e.g., disallowing quoted strings, allowing sequential dots in some cases not permitted by 5321bis, and not supporting non-ASCII internationalized addresses).
- The "living document" nature of WhatWG specifications was also a concern, as changes could introduce new inconsistencies.
- Initial discussion explored including a correct ABNF directly in the AS, but the broader question of whether the AS should reference WhatWG work at all was raised, given its scope outside the working group.
Inconsistency on "For: Clause" (MUST NOT vs. SHOULD NOT):
- The AS stated "MUST NOT generate the For: Clause", while 5321bis uses "SHOULD NOT copy the rcpt to command arguments to the header section".
- It was argued that "SHOULD NOT" is more appropriate, acknowledging rare cases where a server might have a specific reason to include such information.
STARTTLS Requirements in AS:
- Discussion focused on the strength of recommendation for STARTTLS usage (e.g., "MUST" vs. "SHOULD").
- Arguments against "MUST" included scenarios where STARTTLS might be superfluous (e.g., with other security mechanisms), create interoperability problems (by preventing cleartext delivery from legacy systems), or be politically problematic (national mandates against encryption).
- The current text states that servers "MUST support" STARTTLS, which was largely seen as non-controversial, but the extent to which the AS should mandate its use was debated.
- A need for clearer terminology in the AS regarding hop-by-hop versus end-to-end protection, vulnerabilities, and the "ends" (users, systems) involved in security mechanisms was identified.
5321bis IANA Considerations and Registry Cleanup:
- 5321bis is nearing completion, but IANA review highlighted inconsistencies and missing information in existing SMTP Services registries.
- An analysis revealed "brokenness" in existing registry entries (e.g., missing entries for certain E-hello parameters, inconsistent specification of "length added" fields).
- A proposal was made to not block 5321bis for a full cleanup of existing IANA registry entries. Instead, a separate draft will be created to:
  - Assume the new column added by 5321bis to the SMTP Services registry.
  - Fix existing entries and fill in missing information from other RFCs.
  - This separate draft would then be taken to the IANA Maintenance working group.
- John Klensin expressed concern that this split could lead to 5321bis receiving pushback for "inadequately defined" fields if a normative forward reference to the new draft is demanded, delaying 5321bis publication. Alexey indicated he had positive discussions with IANA and Murray Kucherawy about the split.
- Discussion regarding required fields for IANA registrations, particularly "description", where it was proposed that "description" should be mandatory for new registrations (both IETF and first-come-first-served models).
- The role of a "notes" field in the registry for special cases was also discussed, with a sense that it should be kept due to its common use in other registries.

Decisions and Action Items

AS Issue 51 (WhatWG ABNF): Reopen Issue 51 on GitHub. The AS will propose its own correct ABNF for recommended simple email address syntax for maximum interoperability. The normative reference to the WhatWG document will likely be removed, with explanatory text about the issues if the WhatWG syntax is mentioned at all. (Decision based on sense of those present, further mailing list discussion for final text).
AS "For: Clause" Inconsistency: Change "MUST NOT" to "SHOULD NOT" in the AS regarding the generation of the "For:" header clause, aligning with 5321bis.
AS Terminology Section: Editors will propose edits to introduce a terminology section in the AS document, defining terms like "endpoints," "channels," "client," and "server," and ensure consistent usage throughout the document.
AS "Description" Field for IANA Registrations: Tentative decision to make the "description" field mandatory for new registrations in both IETF and First-Come-First-Served models for clarity.
IANA SMTP Services Registry Cleanup: Alexey Melnikov will author a separate draft to fix and fill in existing and missing information in the IANA SMTP Services registry, based on 5321bis changes. This draft will not block 5321bis completion and will be submitted to the IANA Maintenance working group. John Klensin offered to collaborate on this draft.
AS STARTTLS Usage: The discussion regarding the strength of the STARTTLS usage requirement (MUST vs. SHOULD) and the appropriate level of explanation will be continued on the mailing list.
AS Review of John Klensin's Comments: Participants are requested to review John Klensin's detailed WGLC comments on the AS document posted to the mailing list, providing feedback before editors proceed with proposed changes.

Next Steps

IANA (Ayana) will post their latest comments on 5321bis to the data tracker or mailing list.
Alexey Melnikov will begin working on 5321bis-41, pending the review of meeting minutes and notes.
The Working Group Last Call for the AS document will be concluded.
Further discussions on the mailing list will address unresolved topics from this interim meeting and WGLC comments on the AS.
Alexey Melnikov will prepare and post the new draft for IANA SMTP Services registry cleanup before the Bangkok IETF.