Message Submission for Mail
RFC 4409
Document | Type |
RFC - Draft Standard
(April 2006; Errata)
Obsoleted by RFC 6409
Obsoletes RFC 2476
Was draft-gellens-submit-bis (individual in app area)
|
|
---|---|---|---|
Authors | John Klensin , Randall Gellens | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4409 (Draft Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group R. Gellens Request for Comments: 4409 QUALCOMM Obsoletes: 2476 J. Klensin Category: Standards Track April 2006 Message Submission for Mail Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay and final delivery are unaffected, and continue to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. Gellens & Klensin Standards Track [Page 1] RFC 4409 Message Submission for Mail April 2006 Table of Contents 1. Introduction ....................................................3 2. Document Information ............................................4 2.1. Definitions of Terms Used in This Memo .....................4 2.2. Conventions Used in This Document ..........................5 3. Message Submission ..............................................5 3.1. Submission Identification ..................................5 3.2. Message Rejection and Bouncing .............................5 3.3. Authorized Submission ......................................6 4. Mandatory Actions ...............................................7 4.1. General Submission Rejection Code ..........................7 4.2. Ensure All Domains Are Fully-Qualified .....................7 4.3. Require Authentication .....................................8 5. Recommended Actions .............................................8 5.1. Enforce Address Syntax .....................................8 5.2. Log Errors .................................................8 6. Optional Actions ................................................9 6.1. Enforce Submission Rights ..................................9 6.2. Enforce Permissions ........................................9 6.3. Check Message Data .........................................9 6.4. Support for the Postmaster Address .........................9 7. Interaction with SMTP Extensions ...............................10 8. Message Modifications ..........................................11 8.1. Add 'Sender' ..............................................11 8.2. Add 'Date' ................................................11 8.3. Add 'Message-ID' ..........................................11 8.4. Transfer Encode ...........................................11 8.5. Sign the Message ..........................................11 8.6. Encrypt the Message .......................................12 8.7. Resolve Aliases ...........................................12 8.8. Header Rewriting ..........................................12 9. Security Considerations ........................................12 10. IANA Considerations ...........................................13 11. Acknowledgements ..............................................13 12. Normative References ..........................................14 13. Informative References ........................................14 Gellens & Klensin Standards Track [Page 2] RFC 4409 Message Submission for Mail April 2006 1. Introduction SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA]. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA). In order to permit unconstrained communications, SMTP is not often authenticated during message relay.Show full document text