Update to Message Submission for MailStandcore LLCstandards@standcore.com
Application
emailThis memo adds updated advice for e-mail message submission.This memo also offers guidance to software that constructs a message
envelope from a message's headers prior to submission.IntroductionMessage submission prepares a message for
SMTP mail transmisson. This memo provides updated advice for submission agents.This memo also offers guidance to software that constructs a message
envelope from a message's headers prior to submission.Conventions Used in This DocumentExamples use the 'example.net' domain.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.Interaction with SMTP ExtensionsThe following table lists Standards Track and Experimental SMTP
extensions published since that are applicable to message
submission,
Recent SMTP extensions applicable to submission
Keyword
Name
Submission
Reference
MT-PRIORITY
Priority Message Handling
MAY
SMTPUTF8
Internationalized email address
SHOULD
RRVS
Require Recipient Valid Since
MAY
REQUIRETLS
Require TLS
MAY
Message ModificationsAs described in , sites MAY modify submissions to ensure compliance with standards and
site policy. This section describes additional modifications
that are often considered useful.Adjust Recipient HeadersIf the message contains a Bcc header field, the MSA SHOULD delete it
to avoid leaking the address to other recipients.If the message contains neither a To nor a Cc header field, the MSA MAY
add a Bcc header field containing no additional information, or containing
only an empty address group.
While allows messages that have
no recipient headers, MUAs often display them poorly.Generating SMTP Commands from Message Header FieldsSome systems extract sender and recipient addresses from
a header section
without other information in a mail submission protocol, or otherwise
generate SMTP commands from Internet Message Format header fields
when such a message is initially created.There are problems with this approach. For example, there
have been repeated problems with proper handling of "bcc" copies and
redistribution lists when information that conceptually belongs to
the mail envelope is not separated early in processing from header
field information (and kept separate).It is recommended that an MUA provide its MSA
with an envelope separate from the message itself.
However, if the envelope is not supplied, the envelope SHOULD be
generated as follows:
Each recipient address from a TO, CC, or BCC header field SHOULD
be copied to a RCPT command This includes any
addresses listed in a "group".
Any BCC header fields
SHOULD then be removed from the header section. Once this
process is completed, the remaining header fields SHOULD be
checked to verify that at least one TO or CC header field
remains. If none do, then a BCC header field with no additional
information SHOULD be inserted.
The return address in the MAIL command SHOULD, if possible, be
derived from the system's identity for the submitting (local)
user, and the "From:" header field otherwise. If there is a
system identity available, it SHOULD also be copied to the Sender
header field if it is different from the address in the From
header field. (Any Sender header field that was already there
SHOULD be removed.) Systems may provide a way for submitters to
override the envelope return address, but may want to restrict
its use to privileged users. This will not prevent mail forgery,
but may lessen its incidence.
Submission based on message header field information alone
MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
system into an SMTP environment. Additional information to construct
an envelope must come from some source in the other environment,
whether supplemental header fields or the foreign system's envelope.Attempts to gateway messages using only their header "To" and "Cc"
fields have repeatedly caused mail loops and other behavior adverse
to the proper functioning of the Internet mail environment. These
problems have been especially common when the message originates from
an Internet mailing list and is distributed into the foreign
environment using envelope information. When these messages are then
processed by a header-section-only remailer, loops back to the
Internet environment (and the mailing list) are almost inevitable.Security ConsiderationsThis memo does not change the security considerations in .IANA ConsiderationsThis memo makes no reqeuests to IANA. TBDAcknowledgmentsWe thank John Klensin, Pete Resnick, and TBD for helpful comments.Normative ReferencesInformative ReferencesMajor Changes to RFC 6409
Add extensions SMTPUTF8, MT-PRIORITY, RRVS, REQUIRETLS to