IETF core email draft 30 revises SMTP confidentiality requirements
News
IETF EMAILCORE draft-ietf-emailcore-as-30, published on 26 August 2026 at 23:03:58 UTC, revises how the applicability statement expresses SMTP confidentiality requirements. The official Datatracker draft page shows an active Internet-Draft in IESG Evaluation::AD Followup, with five unresolved DISCUSS positions. Revision 30 responds to Area Director and DISCUSS comments raised during IESG review after IETF Last Call.
This draft is not a production mandate
Revision 30 is a non-final Internet-Draft. It is not an approved RFC, a current production requirement, a mandate, a rollout, or a deadline. Operators should not change production behavior solely because this draft was posted, and there is no compliance date.
The wording matters to SMTP and MTA implementers, mailbox providers, delivery platform operators, postmasters, and security teams because a final specification can influence future interoperability guidance, transport-security policy, cleartext fallback decisions, and conformance claims. The immediate task is review and testing, not a rushed configuration change.
What changed between draft 29 and draft 30
Revision 29 was posted after IETF Last Call but before IESG evaluation began. Draft 30 records a focused response to that review. The largest operationally relevant edit is the rewrite of Section 6, especially Section 6.5, together with related changes in Security Considerations. Other edits tighten references, explain recommendation-level language, and remove MUA guidance that did not belong in an SMTP applicability statement.
|
|
|
|---|---|---|
TLS reference | RFC 8446 | RFC 9846 |
Section 6 | Separate rules | Local-policy model |
Security text | Brief hop warning | Policy and hop limits |
References | Mostly informative | Requirements normative |
Recommendations | Some unexplained | Rationales added |
MUA guidance | Section 3.3 | Removed |
Material changes recorded in the revision 30 change log
The primary TLS citation now points to RFC 9846 instead of RFC 8446. RFC 9846 is the July 2026 TLS 1.3 specification that obsoletes RFC 8446, so this is a reference update to the current TLS base specification. It does not create a new SMTP deployment date or announce a separate EMAILCORE TLS rollout.
Several citations attached to requirements have moved from informative to normative references. Most SHOULD and SHOULD NOT statements now include reasons, which helps implementers understand when deviation is justified. Former Section 3.3, "Reuse of Existing Messages," has been removed because message user agent behavior is outside this draft's intended scope.
How the confidentiality requirement changed
Draft 29 expressed three separate normative ideas. SMTP servers had to implement a confidentiality mechanism, senders had to use confidentiality when it was available and accepted, and receivers were prohibited from requiring senders to use over-the-wire confidentiality. IESG comments challenged the internal consistency and security effect of that last requirement.
Draft 29 wording
- Server implementation: SMTP servers had to implement confidentiality.
- Sender use: Senders had to use it when available and accepted.
- Receiver rule: Receivers could not require confidentiality.
Draft 30 wording
- Sender use: Senders MUST use confidentiality when available and accepted.
- Receiver capability: Receivers MUST accept mail with or without confidentiality.
- Deployment behavior: Local policy decides each particular circumstance.
The critical distinction is capability versus deployed policy. Draft 30 asks a conforming receiver implementation to be capable of handling protected and unprotected SMTP. It then leaves the actual decision for a route, tenant, destination, or security domain to local policy. That avoids reading the document as a universal order to accept cleartext in every environment.
The sender obligation remains strong: when confidentiality is available and the receiver accepts it, the sender MUST use it. That language supports normal STARTTLS negotiation while allowing an operator to set stricter failure behavior through policy.
Draft 30 does not abandon STARTTLS
Section 2.4 still proposes Secure SMTP over TLS, through STARTTLS, as an extension that SMTP senders and receivers MUST support. The rewrite changes how receiver capability and local policy are expressed. It does not remove mandatory STARTTLS support from the draft.
What opportunistic STARTTLS means in practice
With opportunistic STARTTLS, the receiving MTA advertises STARTTLS after EHLO. The sending MTA attempts a TLS handshake and sends the message over the protected connection if negotiation succeeds. Under an opportunistic policy, a failed handshake or missing STARTTLS advertisement can lead to a later cleartext attempt so mail still moves.
Illustrative opportunistic STARTTLS exchangetext
S: 220 mx.example.net ESMTP C: EHLO sender.example S: 250-mx.example.net S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS # Success: continue over TLS # Failure: local policy decides retry, defer, or cleartext
That fallback protects delivery but weakens assurance. An on-path actor can interfere with STARTTLS advertisement or negotiation when no authenticated enforcement policy prevents downgrade. Monitoring only the percentage of encrypted mail is therefore incomplete. Operators also need failure reasons, fallback counts, affected destinations, certificate results, and whether a retry changed the protection state.
TLS also protects one SMTP hop at a time. A message can pass through several relays, and each hop negotiates independently. Intermediate MTAs normally receive plaintext and can store it in readable form. Successful TLS on the first connection does not prove protected transport across the entire route, and it does not provide end-to-end message confidentiality.
Opportunistic STARTTLS flow with local-policy fallback choices
Where enforced confidentiality fits
MTA-STS, DANE for SMTP, and RequireTLS address cases where opportunistic fallback is not enough. They do not make SMTP end-to-end encrypted, but they can tell a supporting sender to avoid cleartext delivery for a protected hop and to defer or fail when the required protection cannot be established.
MTA-STS lets a receiving domain publish an HTTPS policy describing acceptable MX hosts and a TLS enforcement mode. DANE for SMTP binds TLS expectations to DNSSEC-authenticated TLSA records. RequireTLS carries a per-message requirement so supporting systems know that delivery must remain protected rather than silently downgrade.
Each mechanism depends on sender support and careful policy handling. Draft 30 says support for these enforcement mechanisms is increasing but is not mandatory. Their use remains a capability and local-policy decision rather than a new universal requirement created by this revision.
|
|
|
|
|---|---|---|---|
STARTTLS | One hop | SMTP greeting | Policy dependent |
MTA-STS | Domain MX | DNS and HTTPS | Defer or fail |
DANE | Domain MX | DNSSEC records | Defer or fail |
RequireTLS | One message | Message signal | Do not downgrade |
How common SMTP confidentiality mechanisms change fallback behavior
For teams that choose MTA-STS, Suped's hosted MTA-STS workflow manages the policy endpoint through two CNAME records, without requiring separate web hosting. That is an operational option for enforcing a chosen policy, not a requirement or deadline created by draft 30.
Before enforcement, verify that every legitimate MX hostname is covered, certificates validate correctly, policy retrieval works, and senders can retry safely during temporary failures. A bad enforcement policy can defer valid mail even when the underlying TLS service is healthy.
MTA-STS checker
Scan DNS, policy files, MX records, and SMTP TLS support.
?/9tests passed
A policy check should be paired with live SMTP tests. DNS and HTTPS publication can look correct while an MX presents the wrong certificate, omits STARTTLS, negotiates an unacceptable protocol, or behaves differently on another route.
Enforced transport also leaves intermediate systems able to process message content. If the security objective requires protection from every relay and storage system, transport controls alone do not meet it. Message-level encryption must be assessed separately.
Practical checks for operators now
Production posture should remain based on current RFCs, contractual requirements, risk decisions, and observed interoperability. Draft 30 is useful input for implementation review, especially where software currently treats receiver capability and deployed acceptance policy as the same control.
- Keep STARTTLS enabled: Do not disable existing inbound or outbound TLS support because Section 6.5 changed.
- Measure negotiation: Record STARTTLS offers, handshake success, protocol selection, and certificate outcomes.
- Watch fallback: Alert on cleartext retries, sudden route changes, and repeated downgrade patterns.
- Review local policy: Separate implementation capability from inbound acceptance and outbound failure decisions.
- Test failure modes: Exercise expired certificates, hostname mismatch, missing STARTTLS, and interrupted handshakes.
- Choose enforcement deliberately: Use MTA-STS, DANE, or RequireTLS where authenticated protected transport is required.
- Track IESG changes: Recheck the draft state, DISCUSS positions, and later revisions before changing conformance plans.
Transport review should sit beside email-authentication review, since TLS protects a connection while DMARC, SPF, and DKIM address domain and message authentication. Suped's domain health checker can verify that broader DNS posture. It does not replace MTA logs, TLS telemetry, or route-specific certificate testing.
Security teams should define what happens when confidentiality cannot be established. An outbound route can defer, fail, or permit cleartext according to policy and the mechanism in use. An inbound service can retain protocol capability while applying stricter rules to selected traffic. Document those decisions so an implementation update does not silently reset them.
Why final wording matters
If the applicability statement becomes an RFC, implementers can use its normative language when claiming conformance. The revised text can also influence default MTA behavior, interoperability tests, procurement requirements, and operational guidance about cleartext fallback. That makes the distinction between support, use, acceptance capability, and local policy more than an editorial detail.
Mailbox providers and delivery platforms should pay close attention to later edits around applicability scope. Public Internet delivery has different interoperability pressure than a closed environment with controlled peers. Draft 30 gives local policy more explicit authority, but unresolved DISCUSS positions mean the IESG can still request changes before approval.
Do not treat draft language as final conformance text
The Datatracker state and open DISCUSS positions show that review is continuing. Record any implementation assumptions against revision 30, rerun tests against later revisions, and wait for an approved RFC before treating this wording as final standards language.
Treat draft 30 as a review signal, not a deadline
Draft 30 keeps STARTTLS support in scope, preserves the sender requirement to use confidentiality when available and accepted, and rewrites receiver behavior around capability plus local policy. It also updates the TLS reference, strengthens reference classification and recommendation rationale, and removes out-of-scope MUA text.
It remains a non-final Internet-Draft in IESG Evaluation::AD Followup with unresolved DISCUSS positions. It is not an approved RFC, current production requirement, mandate, rollout, or deadline. Keep STARTTLS operating, observe fallback and certificate behavior, review local policy, test enforcement paths, and track the IESG record. Do not change production solely because revision 30 was published.
