Session Date/Time: 05 Nov 2025 19:30

EMAILCORE

Summary

The EMAILCORE working group met with the primary goal of finalizing the Applicability Statement (AS) document and discussing the status and remaining work on the IANA Registry document. Key discussions revolved around proposed textual changes to the AS, including objections from Rob Sayre that were largely rejected by the working group, and minor tweaks to scope statements which found consensus. A specific point of debate concerned clarifying the use of STARTTLS with mandatory TLS mechanisms like DANE and MTA-STS. For the IANA document, its adoption as a working group document was confirmed, and a significant change was approved regarding the applicability of SMTP extensions on submission ports. The overall sentiment was a strong desire to wrap up the working group's efforts.

Key Discussion Points

Administrative Matters:
- Reminder of BCP 78/79 and the IETF Code of Conduct.
- Session was recorded; attendees encouraged to join Meetecho.
- Shared note-taking was available.
Document Status Update:
- RFC 5322bis and RFC 5321bis have been approved.
- IANA issues related to RFC 5321bis have been resolved since Madrid.
- EmailCore-25 (Applicability Statement) was posted after working group last call completion.
Review of Recent Changes to the Applicability Statement (AS):
- Rob Sayre's Objections:
  - Suggestions to remove Section 3.3 ("reuse of existing messages") were rejected because the document is not updating the Submission RFC.
  - Suggestions to add an HTML5 reference back to the section on email address validation issues were rejected. Arguments against included HTML5 being a moving target and observed issues often being implementation bugs rather than spec problems. The section's intent is to highlight observed issues in the wild.
  - Other editorial suggestions from Rob Sayre were reviewed and generally rejected by the working group, with editors considering them as stylistic preferences or wanting to retain context.
- General Review of Tickets: A detailed review of all closed tickets (v16-v25) was deemed unnecessary given time constraints.
Discussion on Specific Tickets for the AS:
- Ticket: Clarifying Mandatory TLS (Rob Sayre's suggested text: "These mechanisms are also using STARTTLS.")
  - The existing text describes opportunistic TLS (STARTTLS without identity verification) and mandatory TLS (which builds on it). The proposed clarification aimed to explicitly state that mandatory TLS mechanisms like DANE and MTA-STS also use STARTTLS.
  - Victor pointed out that DANE, in particular, can be used for implicit TLS (e.g., on port 465) where STARTTLS is not applicable.
  - John Levine and Barry Leiba expressed concerns that adding the text might create more confusion than clarity and preferred to avoid further tweaks.
  - Ken confirmed that DANE on port 465 is not "opportunistic TLS," which is the specific context of the sentence under discussion. Therefore, for opportunistic TLS on port 25, the original statement (without the proposed addition) is technically correct.
  - Decision: A poll of those present indicated a strong preference (17 to 3) to not add the proposed text. The existing text was deemed correct in context without the addition.
  - Action Item: Victor was encouraged to open a new ticket with specific suggested text if he believes further clarification regarding MTSC/DANE security is needed.
- Ticket: Scope Statements for Message-Level Authentication:
  - Problem 1: Text stating message-level authentication (e.g., S/MIME) is "outside the scope of this document as they outside of scope of SMTP." This was considered outdated as the AS is no longer solely about SMTP.
  - Proposed Change: Modify to "a more detailed discussion of this mechanism is also outside the scope of this document," retaining it as a pointer.
  - Decision: Consensus was to adopt this change.
  - Problem 2: Text in the SMTP Authentication section stating it "is not the case that this is in scope for this document," despite SMTP AUTH being introduced earlier.
  - Proposed Change: Strike this sentence as redundant and outdated.
  - Decision: Consensus was to strike the sentence.
- New Security Mechanism: Jim Fenton raised the point of "Required TLS," a standards-track specification (distinct from MTA-STS) that addresses similar threats and is now seeing deployment (e.g., in Postfix development snapshots).
  - Decision: Jim Fenton was granted a final allowance to open a ticket within 20 minutes to add a reference to "Required TLS" in Section 6.1.3 of the AS, ideally with suggested text. No further new tickets will be accepted.
IANA Registry Document Discussion (Alexey Melnikov, editor):
- Document Status: The document's adoption was delayed due to administrative oversight (chairs being busy, draft posted under an incorrect name). It has now been correctly posted as a working group draft and officially adopted. Changes since then are mostly editorial.
- Substantial Change: SMTP extensions described in RFC 5321bis (e.g., EHLO keywords) were previously defaulting to "MUST NOT" for submission (port 587) based on rules in 6409, unless explicitly specified otherwise.
- Proposed Change: Change the default applicability for these extensions on submission ports from "MUST NOT" to "MAY," as they are expected to be used there (e.g., HELP). This aligns with practical deployment and avoids potential NOMCOM non-compliance issues.
- Decision: Appears to be consensus to adopt this change.
- Remaining Work: Alexey needs to calculate the lengths of added field values for some SMTP extensions, as these are not specified in their respective RFCs. Ken and John volunteered to verify these calculations.
- Table Formatting: The document uses three tables instead of one wide table for extension names and field changes for better readability. No strong objections were raised to this approach.
DANE for SMTP Clarification (Jim Fenton): Jim Fenton sought clarification on whether DANE for SMTP requires the use of TLS. John Levine confirmed from experience that it absolutely does, as its purpose is to make TLS mandatory and provide downgrade resistance.

Decisions and Action Items

Decisions:

Rob Sayre's suggested changes to the Applicability Statement regarding Section 3.3 (reuse of existing messages) and HTML5 reference were rejected by the working group.
The proposed clarification for Mandatory TLS (adding "These mechanisms are also using STARTTLS") in the Applicability Statement was rejected (poll: 17 to 3).
The text in the Applicability Statement about message-level authentication being "outside the scope of this document as they outside of scope of SMTP" will be changed to "a more detailed discussion of this mechanism is also outside the scope of this document."
The sentence in the Applicability Statement's SMTP Authentication section stating it "is not the case that this is in scope for this document" will be struck.
The IANA registry document's changes, particularly changing the default applicability for SMTP extensions on submission ports from "MUST NOT" to "MAY," were accepted by consensus.
The use of three separate tables instead of one for listing IANA extension changes in the IANA registry document was accepted.

Action Items:

Editors (John and Ken): Perform the remaining revisions on the Applicability Statement based on the meeting's decisions.
Victor: Open a ticket with specific suggested text if he feels more clarity is needed about MTSC/DANE security in the Applicability Statement.
Jim Fenton: Open a ticket within 20 minutes of the meeting's conclusion with suggested text to add a reference to "Required TLS" in Section 6.1.3 of the Applicability Statement. (This is the final allowed new ticket for this document).
Alexey Melnikov: Explicitly reach out to IANA and the RFC Editor regarding the formal handling and adoption status of the IANA registry document.
Alexey Melnikov: Calculate the length of added field values for specific SMTP extensions in the IANA registry document.
Ken and John: Verify Alexey Melnikov's calculations for the IANA registry document.

Next Steps

The Applicability Statement document will proceed to IETF last call after the outstanding edits are completed.
A new version of the IANA registry document will be posted by the end of the year, with a plan to finalize it by March.
The working group aims to conclude its work after these documents are processed.