Network Working Group J. Levine
Internet-Draft Taughannock Networks
Updates: 5321 (if approved) January 25, 2019
Intended status: Standards Track
Expires: July 29, 2019

Update to Additional Registered Clauses in SMTP Received Headers


SMTP servers add Received: trace headers to mail messages to track their progress This document updates the registration criteria for Additional Registered Clauses in those headers to Expert Review, and adds two new clauses for Server Name Indication (SNI).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 29, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

SMTP servers add Received: trace headers to mail messages to track their progress. The syntax of those headers is defined in [RFC5321]. Each header can include optional Additional Registered Clauses that log information related to optional SMTP features.

This document updates the registration criteria for Additional Registered Clauses in those headers to Expert Review, and adds two new clauses for Server Name Indication (SNI). The headers can include Additional Registered Clauses that add information about optional SMTP features.

2. The Server Name Indication clause

Server Name Indication or SNI is an optional TLS feature that a TLS client can use to advise a server the name it expects the server to have. When used in the initial negotiation for a STARTTLS session it enables the server to use a certificate with the identity that the client expects, as is recommended in [RFC7817] and is required for SMTP MTA-STS. When a client presents a name using SNI, the server can log the name using the "sni" additional-registered-clause. When a client presents an encrypted name using ESNI the server can log the fact that the client did so.

IANA is requested to add two new entries to the additional-registered-clauses registry:

3. IANA Considerations

IANA is requested to update the Registration Procedure for the Additional-registered-clauses registry to Expert Review. The IESG will appoint the expert(s).

3.1. Guidance for Designated Expert

The Designated Expert is expected to check that a proposed Additional-registered-clause has a specification that is stable and detailed enough to implement the clause and interoperate. The Expert should ensure that the clause name is reasonably related to the information it represents, that the contents of the clause are well-defined, and that any external references it depends on, e.g., a vocabulary of keywords, are stable and well-defined.

4. Security Considerations

E-mail is subject to a vast range of threats and abuses. In a few circumstances, a new Additional-registered-clause might disclose information to a recipient that was otherwise unavailable. On the other hand, better logging usually makes it easier to diagnose failures and attacks.

If the SNI information in a STARTTLS negotiation is exchanged in encrypted form a mail server would generally not have access to the SNI, and can only log that ESNI was used.

5. References

5.1. Normative References

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

5.2. Uninformative References

[ESNI] Rescorla, E., Oku, K., Sullivan, N. and C. Wood, "Encrypted Server Name Indication for TLS 1.3", Internet-Draft draft-ietf-tls-esni-02, September 2018.
[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A. and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018.

Appendix A. Change history

00 to 01
Add new ESNI clause. Fix many typos.
New draft

Author's Address

John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 Phone: +1 831 480 2300 EMail: URI: