7Network Working Group C. Newman
8Request for Comments: 3848 Sun Microsystems
9Category: Standards Track July 2004
12 ESMTP and LMTP Transmission Types Registration
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (2004).
28 This registers seven new mail transmission types (ESMTPA, ESMTPS,
29 ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of
30 a Received header in an Internet message.
35 protocol types" for use in the "with" clause of the Received header
36 in an Internet message. This registry presently includes SMTP [6],
37 and ESMTP [2]. This specification updates the registry as follows:
39 o The new keyword "ESMTPA" indicates the use of ESMTP when the SMTP
40 AUTH [3] extension is also used and authentication is successfully
43 o The new keyword "ESMTPS" indicates the use of ESMTP when STARTTLS
44 [1] is also successfully negotiated to provide a strong transport
47 o The new keyword "ESMTPSA" indicates the use of ESMTP when both
48 STARTTLS and SMTP AUTH are successfully negotiated (the
49 combination of ESMTPS and ESMTPA).
51 o The new keyword "LMTP" indicates the use of LMTP [4].
58Newman Standards Track [Page 1]
60RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
63 o The new keyword "LMTPA" indicates the use of LMTP when the SMTP
64 AUTH extension is also used and authentication is successfully
67 o The new keyword "LMTPS" indicates the use of LMTP when STARTTLS is
68 also successfully negotiated to provide a strong transport
71 o The new keyword "LMTPSA" indicates the use of LMTP when both
72 STARTTLS and SMTP AUTH are successfully negotiated (the
73 combination of LSMTPS and LSMTPA).
75 o The references for the ESMTP and SMTP entries in the registry
76 should be updated to the latest specification [2] since both RFC
77 821 and RFC 1869 [5] are obsoleted by RFC 2821.
792. Implementation Experience
81 The ESMTPA, ESMTPS and ESMTPSA keywords have been implemented in
82 deployed email server software for several years and no problems have
83 been reported with their use.
853. Security Considerations
87 Use of these additional keywords provides trace information to
88 indicate when various high-level security framing protocols are used
89 for hop-to-hop transport of email without exposing details of the
90 specifics of the security mechanism. This trace information provides
91 an informal way to track the deployment of these mechanisms on the
92 Internet and can assist after-the-fact diagnosis of email abuse.
94 These keywords are not normally protected in transport which means
95 they can be modified by an active attacker. They also do not
96 indicate the specifics of the mechanism used, and therefore do not
97 provide any real-world security assurance. They should not be used
98 for mail filtering or relaying decisions except in very controlled
99 environments. As they are both cryptic and hidden in trace headers
100 used primarily to diagnose email problems, it is not expected they
101 will mislead end users with a false sense of security. Information
102 with a higher degree of reliability can be obtained by correlating
103 the Received headers with the logs of the various Mail Transfer
104 Agents through which the message passed.
106 The trace information provided by these keywords and other parts of
107 the Received header provide a significant benefit when doing after-
108 the-fact diagnosis of email abuse or problems. Unfortunately, some
109 people in a misguided attempt to hide information about their
110 internal servers will strip Received headers of useful information
114Newman Standards Track [Page 2]
116RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
119 and reduce their ability to correct security abuses after they
120 happen. The result of such misguided efforts is usually a reduction
121 of the overall security of the systems.
1254.1. Normative References
127 [1] Hoffman, P., "SMTP Service Extension for Secure SMTP over
128 Transport Layer Security", RFC 3207, February 2002.
130 [2] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
133 [3] Myers, J., "SMTP Service Extension for Authentication", RFC
136 [4] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October
1394.2. Informative References
141 [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
142 "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
144 [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
149 [7] <http://www.iana.org/assignments/mail-parameters>
156 West Covina, CA 91790
159 EMail: chris.newman@sun.com
170Newman Standards Track [Page 3]
172RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
175Full Copyright Statement
177 Copyright (C) The Internet Society (2004). This document is subject
178 to the rights, licenses and restrictions contained in BCP 78, and
179 except as set forth therein, the authors retain all their rights.
181 This document and the information contained herein are provided on an
182 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
183 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
184 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
185 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
186 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
187 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
191 The IETF takes no position regarding the validity or scope of any
192 Intellectual Property Rights or other rights that might be claimed to
193 pertain to the implementation or use of the technology described in
194 this document or the extent to which any license under such rights
195 might or might not be available; nor does it represent that it has
196 made any independent effort to identify any such rights. Information
197 on the procedures with respect to rights in RFC documents can be
198 found in BCP 78 and BCP 79.
200 Copies of IPR disclosures made to the IETF Secretariat and any
201 assurances of licenses to be made available, or the result of an
202 attempt made to obtain a general license or permission for the use of
203 such proprietary rights by implementers or users of this
204 specification can be obtained from the IETF on-line IPR repository at
205 http://www.ietf.org/ipr.
207 The IETF invites any interested party to bring to its attention any
208 copyrights, patents or patent applications, or other proprietary
209 rights that may cover technology that may be required to implement
210 this standard. Please address the information to the IETF at ietf-
215 Funding for the RFC Editor function is currently provided by the
226Newman Standards Track [Page 4]