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.

Authentication and authorization of initial submissions have become increasingly important, driven by changes in security requirements and rising expectations that submission servers take responsibility for the message traffic they originate.

For example, due to the prevalence of machines that have worms, viruses, or other malicious software that generate large amounts of spam, many sites now prohibit outbound traffic on the standard SMTP port (port 25), funneling all mail submissions through submission servers.

In addition to authentication and authorization issues, messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in one or more aspects. Unfinished messages may 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 (e.g., 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, e.g., to conceal local name or address spaces. 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 outside the province of standardized MTA functionality.

Separating messages into submissions and transfers allows developers and network administrators to more easily do the following:

• Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail

• Implement authenticated submission, including off-site submission by authorized users such as travelers

• Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission

• Detect configuration problems with a site's mail clients

• Provide a basis for adding enhanced submission services in the future

This memo describes a low-cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.