1
2
3
4
5
6
7Network Working Group C. Newman
8Request for Comments: 3848 Sun Microsystems
9Category: Standards Track July 2004
10
11
12 ESMTP and LMTP Transmission Types Registration
13
14Status of this Memo
15
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.
21
22Copyright Notice
23
24 Copyright (C) The Internet Society (2004).
25
26Abstract
27
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.
31
321. IANA Considerations
33
34 As directed by SMTP [2], IANA maintains a registry [7] of "WITH 6531:791 ../smtpserver/server.go:1894
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:
38
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
41 achieved.
42
43 o The new keyword "ESMTPS" indicates the use of ESMTP when STARTTLS
44 [1] is also successfully negotiated to provide a strong transport
45 encryption layer.
46
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).
50
51 o The new keyword "LMTP" indicates the use of LMTP [4].
52
53
54
55
56
57
58Newman Standards Track [Page 1]
59
60RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
61
62
63 o The new keyword "LMTPA" indicates the use of LMTP when the SMTP
64 AUTH extension is also used and authentication is successfully
65 achieved.
66
67 o The new keyword "LMTPS" indicates the use of LMTP when STARTTLS is
68 also successfully negotiated to provide a strong transport
69 encryption layer.
70
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).
74
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.
78
792. Implementation Experience
80
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.
84
853. Security Considerations
86
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.
93
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.
105
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
111
112
113
114Newman Standards Track [Page 2]
115
116RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
117
118
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.
122
1234. References
124
1254.1. Normative References
126
127 [1] Hoffman, P., "SMTP Service Extension for Secure SMTP over
128 Transport Layer Security", RFC 3207, February 2002.
129
130 [2] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
131 April 2001.
132
133 [3] Myers, J., "SMTP Service Extension for Authentication", RFC
134 2554, March 1999.
135
136 [4] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October
137 1996.
138
1394.2. Informative References
140
141 [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
142 "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
143
144 [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
145 August 1982.
146
1474.3. URIs
148
149 [7] <http://www.iana.org/assignments/mail-parameters>
150
151Author's Address
152
153 Chris Newman
154 Sun Microsystems
155 1050 Lakes Drive
156 West Covina, CA 91790
157 US
158
159 EMail: chris.newman@sun.com
160
161
162
163
164
165
166
167
168
169
170Newman Standards Track [Page 3]
171
172RFC 3848 ESMTP and LMTP Transmission Types Registration July 2004
173
174
175Full Copyright Statement
176
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.
180
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.
188
189Intellectual Property
190
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.
199
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.
206
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-
211 ipr@ietf.org.
212
213Acknowledgement
214
215 Funding for the RFC Editor function is currently provided by the
216 Internet Society.
217
218
219
220
221
222
223
224
225
226Newman Standards Track [Page 4]
227
228