Message Submission
RFC 2476

Document Type RFC - Proposed Standard (December 1998; No errata)
Obsoleted by RFC 4409
Was draft-gellens-submit (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2476 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        R. Gellens
Request for Comments: 2476                                     QUALCOMM
Category: Standards Track                                    J. Klensin
                                                                    MCI
                                                          December 1998

                           Message Submission

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 (1998).  All Rights Reserved.

Table of Contents

    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
      2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
      2.2.  Conventions Used in this Document . . . . . . . . . . .   4
    3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
      3.1.  Submission Identification . . . . . . . . . . . . . . .   4
      3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
      3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
      3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
    4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
      4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
      4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
    5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
      5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
      5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
    6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
      6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
      6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
      6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
      6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
    7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
    8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
      8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . .  9
      8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
      8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10

Gellens & Klensin           Standards Track                     [Page 1]
RFC 2476                   Message Submission              December 1998

      8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
      8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
      8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
      8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
      8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  10
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
   10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
   13.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  15

1.  Abstract

   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
   which accepts message submissions from MUAs is termed a Message
   Submission Agent (MSA).

   Messages being submitted are in some cases finished (complete)
   messages, and in other cases are unfinished (incomplete) in some
   aspect or other.  Unfinished messages need to be completed to ensure
   they conform to [MESSAGE-FORMAT], and later requirements.  For
   example, the message may lack a proper 'Date' header field, and
   domains might not be fully qualified.  In some cases, the MUA may be
   unable to generate finished messages (for example, it might not know
   its time zone).  Even when submitted messages are complete, local
   site policy may dictate that the message text be examined or modified
   in some way.  Such completions or modifications have been shown to
   cause harm when performed by downstream MTAs -- that is, MTAs after
   the first-hop submission MTA -- and are in general considered to be
Show full document text