Email Submission Operations: Access and Accountability Requirements
RFC 5068
Document | Type |
RFC - Best Current Practice
(November 2007; No errata)
Updated by RFC 8314
Also known as BCP 134
Was draft-hutzler-spamops (individual in ops area)
|
|
---|---|---|---|
Authors | Carl Hutzler , Dave Crocker , Eric Allman , Pete Resnick , Tony Finch | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5068 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Dan Romascanu | ||
Send notices to | sah@428cobrajet.net, hardie@qualcomm.com, sandersr@corp.earthlink.net |
Network Working Group C. Hutzler Request for Comments: 5068 BCP: 134 D. Crocker Category: Best Current Practice Brandenburg InternetWorking P. Resnick QUALCOMM Incorporated E. Allman Sendmail, Inc. T. Finch University of Cambridge Computing Service November 2007 Email Submission Operations: Access and Accountability Requirements Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services. Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. Hutzler, et al. Best Current Practice [Page 1] RFC 5068 Email Submission November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 4 3.1. Best Practices for Submission Operation . . . . . . . . . 5 3.2. Transitioning to Submission Port . . . . . . . . . . . . . 6 4. External Submission . . . . . . . . . . . . . . . . . . . . . 6 4.1. Best Practices for Support of External Submissions . . . . 7 5. Message Submission Authentication/Authorization Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Hutzler, et al. Best Current Practice [Page 2] RFC 5068 Email Submission November 2007 1. Introduction The very characteristics that make email such a convenient communications medium -- its near ubiquity, rapid delivery, low cost, and support for exchanges without prior arrangement -- have made it a fertile ground for the distribution of unwanted or malicious content. Spam, fraud, and worms have become a serious problem, threatening the viability of email and costing end users and providers millions of dollars in damages and lost productivity. In recent years, independent operators including enterprises and ISPs have turned to a number of different technologies and procedures, in an attempt to combat these problems. The results have been mixed, at best. En route to its final destination, email will often travel between multiple independent providers of email transmission services. These services will generally have no prior arrangement with one another and may employ different rules on the transmission. It is therefore difficult both to debug problems that occur in mail transmission and to assign accountability if undesired or malicious mail is injected into the Internet mail infrastructure. Many email authentication technologies exist. They provide some accountability and traceability between disparate networks. This document aims to build upon the availability of these technologies byShow full document text