ESMTP and LMTP Transmission Types Registration
Extracted elements (10)
Stripping Received headers of useful trace information in a misguided attempt to hide internal server details reduces overall system security by impairing after-the-fact diagnosis of email abuse and security incidents.
The ESMTPA, ESMTPS, and ESMTPSA keywords had been implemented in deployed email server software for several years prior to registration with no reported problems, establishing their practical interoperability before standardization.
The keyword ESMTPA in the Received header 'with' clause indicates use of ESMTP combined with successful SMTP AUTH (RFC 2554) authentication.
The keyword ESMTPS in the Received header 'with' clause indicates use of ESMTP combined with successfully negotiated STARTTLS (RFC 3207) providing strong transport encryption.
The keyword ESMTPSA in the Received header 'with' clause indicates use of ESMTP with both STARTTLS and SMTP AUTH successfully negotiated, combining ESMTPS and ESMTPA.
The keyword LMTP in the Received header 'with' clause indicates use of LMTP (RFC 2033) as the mail transfer protocol.
The keyword LMTPA indicates use of LMTP with successful SMTP AUTH authentication; LMTPS indicates LMTP with successfully negotiated STARTTLS; LMTPSA indicates LMTP with both STARTTLS and SMTP AUTH successfully negotiated.
IANA maintains a registry of 'WITH protocol types' for use in the 'with' clause of the Received header. This document adds seven new keywords: ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, and LMTPSA, and updates the references for existing SMTP and ESMTP entries to RFC 2821.
The keywords provide trace information indicating when high-level security framing protocols (STARTTLS, SMTP AUTH) are used for hop-to-hop email transport, supporting after-the-fact diagnosis of email abuse without exposing mechanism details.
These transmission-type keywords are not normally protected in transport and can be modified by an active attacker; they do not reveal specifics of the security mechanism and therefore provide no real-world security assurance. They SHOULD NOT be used for mail filtering or relaying decisions except in very controlled environments.