In December of 1998 RFC 2476 was released.
A few years later in April of 2006, RFC 4409 was released and obsoleted RFC 2476.
The purpose of these RFC's was to introduce the concept of a Message Submission Program.
In the days before these RFC's one sendmail daemon preformed a lot of different mail related functions.
The concepts introduced in RFC were an attempt to set specific job functions to be carried out by different processes and not to have one process continue to preform all mail related tasks.
In the old days Sendmail was primarily a message router but you could use it to read and write messages. Another function of sendmail was to insure that messages met e-mail specifications.
Although this is still true, you now have the option to have one process accept messages for the machine and another process whose sole function is to simply route the messages.
One process doesn't need to insure that outgoing mail meets the specifications for a properly formed mail message and then route that message towards its final destination.
One process can now ensure that the message is well formed and another process can then take that well formed message and then send it on its way.
Message routing still uses port 25 and Message Submission uses port 587.
From the RFC:
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.
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).
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 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).
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
Essentially what this does is the following:
Any message that enters the system on port 587 is assumed to be a new message. The software ensures that the messages is well formed or rejects the message.
Any message that enters the system on port 25 is assumed to be a message that needs help being routed to its final destination.
You can still use port 25 for message submission but it is recommended that if you choose to do this then you designate some servers as message submission servers and other servers as the more traditional message transfer agent (message router).
MSA's and MTA's can be configured to reject messages.
An MSA (port 587) MUST do all of the following:
General Submission Rejection Code
Ensure All Domains Are Fully-Qualified
Require Authentication
The MSA SHOULD do all of the following:
Enforce Address Syntax
Log Errors
The MSA MAY do any of the following:
Enforce Submission Rights
Enforce Permissions
Check Message Data
Support for the Postmaster Address
Interaction with SMTP Extensions
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference:
Keyword Name Submission
---------- -------------------------- ----------
PIPELINING Pipelining SHOULD
ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD
ETRN Extended Turn MUST NOT
... Extended Codes SHOULD
DSN Delivery Status Notification SHOULD
SIZE Message size MAY
... 521 reply code MUST NOT
CHECKPOINT Checkpoint/Restart MAY
BINARYMIME Binary MIME MAY
CHUNKING Chunking MAY
8BITMIME Use 8-bit data SHOULD
AUTH Authentication MUST
STARTTLS Start TLS MAY
NO-SOLICITING Notification of no soliciting MAY
MTRK Message Tracking MAY
Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
Sites MAY modify submissions to ensure compliance with standards and site policy. This may include the following:
Add 'Sender'
Add 'Date'
Add 'Message-ID'
Transfer Encode
Sign the Message
Encrypt the Message
Resolve Aliases
Header Rewriting
Message submission is controlled by the submit.cf file.
Next Section: Architecture - 5 of 32