Summary

  • Revision 30 of the IETF EMAILCORE applicability statement says SMTP receiving implementations must be able to accept mail with or without transport confidentiality, but places the choice in a particular circumstance with local policy. It is an Internet-Draft in IESG follow-up, not a published RFC.
  • The wording differs from revision 29's instruction that receivers must not require confidentiality. A public discussion in late September asks whether the revised capability requirement clarifies interoperability or imposes an unnecessary universal design constraint. It has not established a resolved IESG outcome.

Imagine an administrator who refuses a cleartext SMTP session at the edge of a private mail environment. That refusal says something about the administrator's policy. It does not, by itself, tell us whether the receiving software could process the same session if configured differently. The difference is normally hidden beneath the word “supports.” In draft-ietf-emailcore-as-30, it becomes the subject of a capital-letter requirement.

Section 6.5 says SMTP senders must use confidentiality when it is available and accepted by the receiver. It then says receivers must be able to accept mail with or without confidentiality, while what either side does in a particular circumstance remains a local policy matter. Revision 29 used a different receiver formulation: receivers must not require confidentiality from senders. The authors' change log records a rewrite of the security section during IESG review. The text moved from a direct prohibition on a receiving requirement toward an implementation capability coupled to a policy reservation.

That is a real textual distinction, even if its operational effect is still contested.

The review has not finished merely because the wording changed. The Datatracker still identifies revision 30 as an active Internet-Draft in “AD Followup.” The public ballot continues to show DISCUSS positions, some filed against the previous revision and addressing different issues. An 18 September response from editor John Klensin to Roman Danyliw describes part of the exchange as personal and not yet reviewed by the working group. On 28 September Eric Rescorla argued that, if the new requirement adds nothing beyond existing practice, it should be removed rather than retained as an unnecessary norm.

Rob Sayre's contemporaneous reply emphasized the difference between an implementation's capability and an operator's choice and expected more operators to insist on TLS. Those are named participants' positions, not an IETF decision or a census of deployed mail servers.

Nor is this the first time Internet mail has carried an interoperability limit on encryption requirements. RFC 3207 says a publicly referenced SMTP server must not require STARTTLS for local delivery, while a server not publicly referenced may require it. That existing rule is scoped to a particular class of server and mechanism. It should not be stretched into a claim that every SMTP service must admit every unencrypted connection, or that an operator loses the ability to use other security policy. The EMAILCORE proposal is being argued at a different layer: what baseline ability all conforming receiving implementations should retain.

The other direction is message-specific. RFC 8689's REQUIRETLS lets a sender require protected handling for an individual message across supporting relays and prefer failure over a fallback to cleartext. BTW has already covered that mechanism from the message's point of view. It does not settle whether generic receiving software must retain a cleartext acceptance path. A per-message promise, a public-MX baseline, an implementation capability and an operator's admission rule belong to four different decisions.

This is why the current debate has more significance than an edit to a security paragraph. A standards-track applicability statement can shape vendor defaults and the vocabulary administrators use to justify choices. If “must be able” is interpreted as “must allow,” operators could mistake a software conformance statement for a mandate to loosen local policy. If a universal capability requirement is unnecessary, retaining it can still create a future compatibility burden.

Conversely, removing every cleartext capability from a receiver can make exceptional interoperability or recovery more difficult even when its normal policy is encryption-only. The draft does not quantify either burden, and its status does not entitle anyone to claim a new rule is already binding.

Sources