UpdatedBEST CURRENT PRACTICEIETF streamBCP134

RFC 5068: Email Submission Operations: Access and Accountability Requirements

Still current, but amended. Parts of this document are changed or extended by RFC 8314. Read both.

In plain English — editorial summary, not part of the RFC

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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Document record

Document ID
RFC5068
Published
November 2007
Authors
C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch
Status
BEST CURRENT PRACTICE
Stream
IETF
Area
Pages
12
Also known as
BCP134
Updated by:
RFC 8314

Topics

Referenced by

One later RFC formally updates or obsoletes part of this document.

Related documents

Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/5068-email-submission-operations-access-and-accountability-requirements