7Network Working Group C. Hutzler
8Request for Comments: 5068
10Category: Best Current Practice Brandenburg InternetWorking
16 University of Cambridge Computing Service
20 Email Submission Operations: Access and Accountability Requirements
24 This document specifies an Internet Best Current Practices for the
25 Internet Community, and requests discussion and suggestions for
26 improvements. Distribution of this memo is unlimited.
30 Email has become a popular distribution service for a variety of
31 socially unacceptable, mass-effect purposes. The most obvious ones
32 include spam and worms. This note recommends conventions for the
33 operation of email submission and transport services between
34 independent operators, such as enterprises and Internet Service
35 Providers. Its goal is to improve lines of accountability for
36 controlling abusive uses of the Internet mail service. To this end,
37 this document offers recommendations for constructive operational
38 policies between independent operators of email submission and
39 transmission services.
41 Email authentication technologies are aimed at providing assurances
42 and traceability between internetworked networks. In many email
43 services, the weakest link in the chain of assurances is initial
44 submission of a message. This document offers recommendations for
45 constructive operational policies for this first step of email
46 sending, the submission (or posting) of email into the transmission
47 network. Relaying and delivery entail policies that occur subsequent
48 to submission and are outside the scope of this document.
58Hutzler, et al. Best Current Practice [Page 1]
60RFC 5068 Email Submission November 2007
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
67 3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 4
68 3.1. Best Practices for Submission Operation . . . . . . . . . 5
69 3.2. Transitioning to Submission Port . . . . . . . . . . . . . 6
70 4. External Submission . . . . . . . . . . . . . . . . . . . . . 6
71 4.1. Best Practices for Support of External Submissions . . . . 7
72 5. Message Submission Authentication/Authorization
73 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 8
74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
77 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
114Hutzler, et al. Best Current Practice [Page 2]
116RFC 5068 Email Submission November 2007
121 The very characteristics that make email such a convenient
122 communications medium -- its near ubiquity, rapid delivery, low cost,
123 and support for exchanges without prior arrangement -- have made it a
124 fertile ground for the distribution of unwanted or malicious content.
125 Spam, fraud, and worms have become a serious problem, threatening the
126 viability of email and costing end users and providers millions of
127 dollars in damages and lost productivity. In recent years,
128 independent operators including enterprises and ISPs have turned to a
129 number of different technologies and procedures, in an attempt to
130 combat these problems. The results have been mixed, at best.
132 En route to its final destination, email will often travel between
133 multiple independent providers of email transmission services. These
134 services will generally have no prior arrangement with one another
135 and may employ different rules on the transmission. It is therefore
136 difficult both to debug problems that occur in mail transmission and
137 to assign accountability if undesired or malicious mail is injected
138 into the Internet mail infrastructure.
140 Many email authentication technologies exist. They provide some
141 accountability and traceability between disparate networks. This
142 document aims to build upon the availability of these technologies by
143 exploring best practices for authenticating and authorizing the first
144 step of an email's delivery, from a Mail User Agent (MUA) to a Mail
145 Submission Agent (MSA), known as submission. Without strong
146 practices on email submission, the use of authentication technologies
147 elsewhere in the service provides limited benefit.
149 This document specifies operational policies to be used for the first
150 step of email sending, the submission -- or posting from an MUA to an
151 MSA as defined below -- of email into the transmission service.
152 These policies will permit continued, smooth operation of Internet
153 email, with controls added to improve accountability. Relaying and
154 delivering employ policies that occur after submission and are
155 outside the scope of this document. The policies listed here are
156 appropriate for operators of all sizes of networks and may be
157 implemented by operators independently, without regard for whether
158 the other side of an email exchange has implemented them.
160 It is important to note that the adoption of these policies alone
161 will not solve the problems of spam and other undesirable email.
162 However, these policies provide a useful step in clarifying lines of
163 accountability and interoperability between operators. This helps
164 raise the bar against abusers and provides a foundation for
165 additional tools to preserve the utility of the Internet email
170Hutzler, et al. Best Current Practice [Page 3]
172RFC 5068 Email Submission November 2007
175 NOTE: This document does not delve into other anti-spam operational
176 issues such as standards for rejection of email. The authors note
177 that this could be a valuable effort to undertake and encourage
182 The Internet email architecture distinguishes four message-handling
185 o Mail User Agents (MUAs)
187 o Mail Submission Agents (MSAs)
189 o Mail Transfer Agents (MTAs)
191 o Mail Delivery Agents (MDAs)
193 At the origination end, an MUA works on behalf of end users to create
194 a message and perform initial "submission" into the transmission
195 infrastructure, via an MSA. An MSA accepts the message submission,
196 performs any necessary preprocessing on the message, and relays the
197 message to an MTA for transmission. MTAs 'relay' messages to other
198 MTAs, in a sequence reaching a destination MDA that, in turn,
199 'delivers' the email to the recipient's inbox. The inbox is part of
200 the recipient-side MUA that works on behalf of the end user to
201 process received mail.
203 These architectural components are often compressed, such as having
204 the same software do MSA, MTA and MDA functions. However the
205 requirements for each of these components of the architecture are
206 becoming more extensive, so that their software and even physical
207 platform separation is increasingly common.
209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
211 document are to be interpreted as described in [RFC2119].
2133. Submission, Relaying, Delivery
215 Originally the MSA, MTA, and MDA architectural components were
216 considered to be a single unit. This was reflected in the practice
217 of having MSA, MTA, and MDA transfers all be performed with SMTP
218 [RFC2821] [RFC0821], over TCP port 25. Internet mail permits email
219 to be exchanged without prior arrangement and without sender
220 authentication. That is, the confirmed identity of the originator of
221 the message is not necessarily known by the relaying MTAs or the MDA.
226Hutzler, et al. Best Current Practice [Page 4]
228RFC 5068 Email Submission November 2007
231 It is important to distinguish MUA-to-MSA email submission, versus
232 MTA relaying, versus the final MTA-to-MDA transition. Submission
233 typically does entail a pre-established relationship between the user
234 of the client and operator of the server; equally, the MDA is
235 performing final delivery and can determine that it has an existing
236 relationship with the recipient. That is, MSAs and MDAs can take
237 advantage of having prior relationships with users in order to
238 constrain their transfer activities.
240 Specifically, an MSA can choose to reject all postings from MUAs for
241 which it has no existing relationship. Similarly, an MDA can choose
242 to reject all mail to recipients for which it has no arrangement to
243 perform delivery. Indeed, both of these policies are already in
2463.1. Best Practices for Submission Operation
248 Submission Port Availability:
250 If external submissions are supported -- that is, from outside a
251 site's administrative domain -- then the domain's MSAs MUST
252 support the SUBMISSION port 587 [RFC4409]. Operators MAY
253 standardize on the SUBMISSION port for both external AND LOCAL
254 users; this can significantly simplify submission operations.
258 MUAs SHOULD use the SUBMISSION port for message submission.
260 Submission Authentication:
262 MSAs MUST perform authentication on the identity asserted during
263 all mail transactions on the SUBMISSION port, even for a message
264 having a RCPT TO address that would not cause the message to be
265 relayed outside of the local administrative domain.
267 Submission Authorization:
269 An operator of an MSA MUST ensure that the authenticated identity
270 is authorized to submit email, based on an existing relationship
271 between the submitting entity and the operator. This requirement
272 applies to all mail submission mechanisms (MUA to MSA).
274 Submission Accountability after Submission:
276 For a reasonable period of time after submission, the message
277 SHOULD be traceable by the MSA operator to the authenticated
278 identity of the user who sent the message. Such tracing MAY be
282Hutzler, et al. Best Current Practice [Page 5]
284RFC 5068 Email Submission November 2007
287 based on transactional identifiers stored in the headers (received
288 lines, etc.) or other fields in the message, on audit data stored
289 elsewhere, or on any other mechanism that supports sufficient
290 post-submission accountability. The specific length of time,
291 after message submission, that traceability is supported is not
292 specified here. However, issues regarding transit often occur as
293 much as one week after submission.
295 Note that [RFC3848] defines a means of recording submission-time
296 information in Received header fields. This information can help
297 receive-side analysis software establish a sending MSA's
298 accountability and then make decisions about processing the
3013.2. Transitioning to Submission Port
303 In order to promote transition of initial message submission from
304 port 25 to port 587, MSAs MUST listen on port 587 by default and
305 SHOULD have the ability to listen on other ports. MSAs MUST require
306 authentication on port 587 and SHOULD require authentication on any
307 other port used for submission. MSAs MAY also listen on other ports.
308 Regardless of the ports on which messages are accepted, MSAs MUST NOT
309 permit relaying of unauthenticated messages to other domains. That
310 is, they must not be open relays.
312 As a default, MUAs SHOULD attempt to find the best possible
313 submission port from a list of alternatives. The SUBMISSION port 587
314 SHOULD be placed first in the list. Since most MUAs available today
315 do not permit falling back to alternate ports, sites SHOULD pre-
316 configure or encourage their users to connect on the SUBMISSION port
317 587, assuming that site supports that port.
3194. External Submission
321 An MUA might need to submit mail across the Internet, rather than to
322 a local MSA, in order to obtain particular services from its home
323 site. Examples include active privacy protection against third-party
324 content monitoring, timely processing, and being subject to the most
325 appropriate authentication and accountability protocols. Further,
326 the privacy requirement might reasonably include protection against
327 monitoring by the operator of the MUA's access network. This
328 requirement creates a challenge for the provider operating the IP
329 network through which the MUA gains access. It makes that provider
330 an involuntary recruit to the task of solving mass-effect email
331 problems: When the MUA participates in a problem that affects large
332 numbers of Internet users, the provider is expected to effect
333 remedies and is often expected to prevent such occurrences.
338Hutzler, et al. Best Current Practice [Page 6]
340RFC 5068 Email Submission November 2007
343 A proactive technique used by some providers is to block all use of
344 port 25 SMTP for mail that is being sent outbound, or to
345 automatically redirect this traffic through a local SMTP proxy,
346 except for hosts that are explicitly authorized. This can be
347 problematic for some users, notably legitimate mobile users
348 attempting to use their "home" MSA, even though those users might
349 already employ legitimate, port 25-based authentication.
351 This document offers no recommendation concerning the blocking of
352 SMTP port 25 or similar practices for controlling abuse of the
353 standard anonymous mail transfer port. Rather, it pursues the
354 mutually constructive benefit of using the official SUBMISSION port
357 NOTE: Many established practices for controlling abuse of port 25,
358 for mail that is being sent outbound, currently do exist. These
359 include the proxy of SMTP traffic to local hosts for screening,
360 combined with various forms of rate limits. The authors suggest
361 that a separate document on this topic would benefit the email
362 operations community.
3644.1. Best Practices for Support of External Submissions
366 Open Submission Port:
368 Access Providers MUST NOT block users from accessing the external
369 Internet using the SUBMISSION port 587 [RFC4409].
371 Traffic Identification -- External Posting (MSA) Versus Relaying
374 When receiving email from outside their local operational
375 environment, email service providers MUST distinguish between
376 unauthenticated email addressed to local domains (MX traffic)
377 versus submission-related authenticated email that can be
378 addressed anywhere (MSA traffic). This allows the MTA to restrict
379 relaying operations, and thereby prevent "open" relays. Note that
380 there are situations where this may not apply, such as secondary
381 MXs and related implementations internal to an operator's network
382 and within their control.
384 Figure 1 depicts a local user (MUA.l) submitting a message to an MSA
385 (MSA). It also shows a remote user (MUA.r), such as might be in a
386 coffee shop offering "hotspot" wireless access, submitting a message
387 to their "home" MSA via an authenticated port 587 transaction. The
388 figure shows the alternative of using port 587 or port 25 within the
389 MSA's network. This document makes no recommendations about the use
394Hutzler, et al. Best Current Practice [Page 7]
396RFC 5068 Email Submission November 2007
399 of port 25 for submission. The diagram merely seeks to note that it
400 is in common use and to acknowledge that port 25 can be used with
401 sufficient accountability within an organization's network.
403 HOME NETWORK DESTINATION
407 port | port port port
408 587/25 V 25 25 -------- 25
409 +-----+ +-----+ ****** / \ ****** +-----+ +-----+
410 | MSA |->| MTA |->* AP *->| |->* AP *->| MTA |->| MDA |
411 +--^--+ +-----+ ****** | INTERNET | ****** +-----+ +-----+
413 +-------<--------------|----+ |
418 AP = Access Provider * AP *
426 Figure 1: Example of Port 587 Usage via Internet
4285. Message Submission Authentication/Authorization Technologies
430 There are many competent technologies and standards for
431 authenticating message submissions. Two component mechanisms that
432 have been standardized include SMTP AUTH [RFC4954] and TLS [RFC3207].
433 Depending upon the environment, different mechanisms can be more or
434 less effective and convenient. Mechanisms might also have to be used
435 in combination with each other to make a secure system.
436 Organizations SHOULD choose the most secure approaches that are
439 This document does not provide recommendations on specific security
440 implementations. It simply provides a warning that transmitting user
441 credentials in clear text over insecure networks SHOULD be avoided in
442 all scenarios as this could allow attackers to listen for this
443 traffic and steal account data. In these cases, it is strongly
444 suggested that an appropriate security technology MUST be used.
450Hutzler, et al. Best Current Practice [Page 8]
452RFC 5068 Email Submission November 2007
4556. Security Considerations
457 Email transfer between independent administrations can be the source
458 of large volumes of unwanted email and email containing malicious
459 content designed to attack the recipient's system. This document
460 addresses the requirements and procedures to permit such exchanges
461 while reducing the likelihood that malicious mail will be
4667.1. Normative References
468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
469 Requirement Levels", BCP 14, RFC 2119, March 1997.
471 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
474 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
475 RFC 4409, April 2006.
4777.2. Informative References
479 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
480 RFC 821, August 1982.
482 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
483 Transport Layer Security", RFC 3207, February 2002.
485 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
486 Registration", RFC 3848, July 2005.
488 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
489 Extension for Authentication", RFC 4954, July 2007.
506Hutzler, et al. Best Current Practice [Page 9]
508RFC 5068 Email Submission November 2007
511Appendix A. Acknowledgments
513 These recommendations were first formulated during informal
514 discussions among members of Anti-Spam Technical Alliance (ASTA) and
515 some participants from the Internet Research Task Force's Anti-Spam
516 Research Group (ASRG).
518 Later reviews and suggestions were provided by: M. Allman, L.H.
519 Aestrand, N. Borenstein, S. Bortzmeyer, K. Chon, R. Clayton, B. Cole,
520 W. Dnes, V. Duchovni, E. Edelstein, F. Ellermann, M. Elvey, J.D.
521 Falk, N. Freed, J. Glube, A. Herzberg, J. Klensin, J. Levine, S.
522 Moonesamy, K. Moore, R. Nelson, C. Newman, C. O'Malley, S.
523 Ramasubramanian, R. Rognlie, J. St. Sauver, W. Schlitt, B. Shein, B.
533 EMail: cdhutzler@aol.com
534 URI: http://carlhutzler.com/blog/
538 Brandenburg InternetWorking
543 Phone: +1.408.246.8253
544 EMail: dcrocker@bbiw.net
549 QUALCOMM Incorporated
551 San Diego, CA 92121-1714
554 Phone: +1 858 651 4478
555 EMail: presnick@qualcomm.com
556 URI: http://www.qualcomm.com/~presnick/
562Hutzler, et al. Best Current Practice [Page 10]
564RFC 5068 Email Submission November 2007
569 6745 Christie Ave., Suite 350
573 Phone: +1 510 594 5501
574 EMail: eric+ietf-smtp@sendmail.org
578 University of Cambridge Computing Service
584 Phone: +44 797 040 1426
586 URI: http://dotat.at/
618Hutzler, et al. Best Current Practice [Page 11]
620RFC 5068 Email Submission November 2007
623Full Copyright Statement
625 Copyright (C) The IETF Trust (2007).
627 This document is subject to the rights, licenses and restrictions
628 contained in BCP 78, and except as set forth therein, the authors
629 retain all their rights.
631 This document and the information contained herein are provided on an
632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
641 The IETF takes no position regarding the validity or scope of any
642 Intellectual Property Rights or other rights that might be claimed to
643 pertain to the implementation or use of the technology described in
644 this document or the extent to which any license under such rights
645 might or might not be available; nor does it represent that it has
646 made any independent effort to identify any such rights. Information
647 on the procedures with respect to rights in RFC documents can be
648 found in BCP 78 and BCP 79.
650 Copies of IPR disclosures made to the IETF Secretariat and any
651 assurances of licenses to be made available, or the result of an
652 attempt made to obtain a general license or permission for the use of
653 such proprietary rights by implementers or users of this
654 specification can be obtained from the IETF on-line IPR repository at
655 http://www.ietf.org/ipr.
657 The IETF invites any interested party to bring to its attention any
658 copyrights, patents or patent applications, or other proprietary
659 rights that may cover technology that may be required to implement
660 this standard. Please address the information to the IETF at
674Hutzler, et al. Best Current Practice [Page 12]