RFC 3461 Draft Standard Transport

Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

Status
Draft Standard. A maturity level the IETF retired in 2011. Documents that had reached it kept the label, so it still appears on current work such as RFC 5321.
Published
January 2003
Authors
K. Moore
Read it
rfc-editor.org · errata · DOI

Replaces RFC 1891: SMTP Service Extension for Delivery Status Notifications.

This document is current and has been amended. 5 later RFCs have changed part of it. Nothing on the RFC itself tells you this.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 66 must, 20 should, 23 may.

4 Additional parameters for RCPT and MAIL commands

  • MAYTherefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters.
  • MAY+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself.
  • MAY(A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.)

4.1 The NOTIFY parameter of the ESMTP RCPT command

  • MUSTIf the NOTIFY esmtp-keyword is used, it MUST have an associated esmtp-value, formatted according to the following rules, using the ABNF of RFC 822:
  • MAYMultiple notify-list-elements, separated by commas, MAY appear in a NOTIFY parameter; however, the NEVER keyword MUST appear by itself.

4.2 The ORCPT parameter to the ESMTP RCPT command

  • MUSTIf the ORCPT esmtp-keyword is used, it MUST have an associated esmtp-value, which consists of the original recipient address, encoded according to the rules below.
  • MUSTThe "addr-type" portion MUST be an IANA-registered electronic mail address-type (as defined in [3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document.
  • MAYThe entire ORCPT parameter MAY be up to 500 characters in length.
  • MUSTWhen initially submitting a message via SMTP, if the ORCPT parameter is used, it MUST contain the same address as the RCPT TO address (unlike the RCPT TO address, the ORCPT parameter will be encoded as xtext).
  • MUSTLikewise, when a mailing list submits a message via SMTP to be distributed to the list subscribers, if ORCPT is used, the ORCPT parameter MUST match the new RCPT TO address of each recipient, not the address specified by the original sender of the message.)
  • MUSTDue to limitations in the Delivery Status Notification format, the value of the original recipient address prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire.
  • MUSTIf an addr-type is defined for addresses which use characters outside of this repertoire, the specification for that addr-type MUST define the means of encoding those addresses in printable US-ASCII characters when are then encoded as xtext.

4.3 The RET parameter of the ESMTP MAIL command

  • MUSTIf the RET esmtp-keyword is used, it MUST have an associated esmtp-value, which is one of the following keywords:
  • MAYIf no RET parameter is supplied, the MTA MAY return either the headers of the message or the entire message for any DSN containing indication of failed deliveries.

4.4 The ENVID parameter to the ESMTP MAIL command

  • MUSTThe ENVID esmtp-keyword MUST have an associated esmtp-value.
  • MAYThe ENVID parameter MAY be up to 100 characters in length.
  • MUSTDue to limitations in the Delivery Status Notification format, the value of the ENVID parameter prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire.

4.5 Restrictions on the use of Delivery Status Notification parameters

  • MUST NOTThe RET and ENVID parameters MUST NOT appear more than once each in any single MAIL command.
  • SHOULDIf more than one of either of these parameters appears in a MAIL command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".
  • MUST NOTThe NOTIFY and ORCPT parameters MUST NOT appear more than once in any RCPT command.
  • SHOULDIf more than one of either of these parameters appears in a RCPT command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".

5 Conformance requirements

  • MUSTAn MTA which, when acting as an SMTP server, issues the DSN keyword in response to the EHLO command, MUST obey the rules below for a "conforming SMTP client" when acting as a client, and a "conforming SMTP server" when acting as a server.

5.1 SMTP protocol interactions

  • MUST(a) If an SMTP client issues a MAIL command containing a valid ENVID parameter and associated esmtp-value and/or a valid RET parameter and associated esmtp-value, a conforming SMTP server MUST return the same reply-code as it would to the same MAIL command without the ENVID and/or RET parameters.
  • MUST NOTA conforming SMTP server MUST NOT refuse a MAIL command based on the absence or presence of valid ENVID or RET parameters, or on their associated esmtp-values.
  • MUSTHowever, if the associated esmtp-value is not valid (i.e., contains illegal characters), or if there is more than one ENVID or RET parameter in a particular MAIL command, the server MUST issue the reply-code 501 with an appropriate message (e.g., "syntax error in parameter").
  • MUST(b) If an SMTP client issues a RCPT command containing any valid NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST return the same response as it would to the same RCPT command without those NOTIFY and/or ORCPT parameters.
  • MUST NOTA conforming SMTP server MUST NOT refuse a RCPT command based on the presence or absence of any of these parameters.
  • SHOULDHowever, if any of the associated esmtp-values are not valid, or if there is more than one of any of these parameters in a particular RCPT command, the server SHOULD issue the response "501 syntax error in parameter".

5.2 Handling of messages received via SMTP

  • MUST NOTNOTE: A DSN MUST NOT be returned to the sender for any message for which the return address from the SMTP MAIL command was NULL ("<>"), even if the sender's address is available from other sources (e.g., the message header).
  • SHOULDHowever, the MTA which would otherwise issue a DSN SHOULD inform the local postmaster of delivery failures through some appropriate mechanism that will not itself result in the generation of DSNs.

5.2.1 Relay of messages to other conforming SMTP servers

  • MUST(a) Any ENVID parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value.
  • MUST NOTIf no ENVID parameter was included in the MAIL command when the message was received, the ENVID parameter MUST NOT be supplied when the message is relayed.
  • MUST(b) Any RET parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value.
  • MUST NOTIf no RET parameter was included in the MAIL command when the message was received, the RET parameter MUST NOT supplied when the message is relayed.
  • MUST(c) If the NOTIFY parameter was supplied for a recipient when the message was received, the RCPT command issued when the message is relayed MUST also contain the NOTIFY parameter along with its associated esmtp-value.
  • MUST NOTIf the NOTIFY parameter was not supplied for a recipient when the message was received, the NOTIFY parameter MUST NOT be supplied for that recipient when the message is relayed.
  • MUST(d) If any ORCPT parameter was present in the RCPT command for a recipient when the message was received, an ORCPT parameter with the identical original-recipient-address MUST appear in the RCPT command issued for that recipient when relaying the message.
  • MUST NOT(For example, the MTA therefore MUST NOT change the case of any alphabetic characters in an ORCPT parameter.)
  • MAYIf no ORCPT parameter was present in the RCPT command when the message was received, an ORCPT parameter MAY be added to the RCPT command when the message is relayed.
  • MUSTIf an ORCPT parameter is added by the relaying MTA, it MUST contain the recipient address from the RCPT command used when the message was received by that MTA.

5.2.2 Relay of messages to non-conforming SMTP servers

  • MUST NOT(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when relaying the message.
  • MUST(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-value containing the keyword SUCCESS, and the SMTP server returns a success (2xx) reply-code in response to the RCPT command, the client MUST issue a "relayed" DSN for that recipient.
  • MUST(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-value containing the keyword FAILURE, and the SMTP server returns a permanent failure (5xx) reply-code in response to the RCPT command, the client MUST issue a "failed" DSN for that recipient.
  • MUST NOT(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-value of NEVER, the client MUST NOT issue a DSN for that recipient, regardless of the reply-code returned by the SMTP server.
  • MAYHowever, if the server returned a failure (5xx) reply-code, the client MAY inform the local postmaster of the delivery failure via an appropriate mechanism that will not itself result in the generation of DSNs.
  • MAYWhen attempting to relay a message to an SMTP server that does not support this extension, and if NOTIFY=NEVER was specified for some recipients of that message, a conforming SMTP client MAY relay the message for those recipients in a separate SMTP transaction, using an empty reverse-path in the MAIL command.
  • MUST NOT(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a success (2xx) reply-code in response to a RCPT command, the client MUST NOT issue any DSN for that recipient.
  • MUST(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a permanent failure (5xx) reply-code in response to a RCPT command, the client MUST issue a "failed" DSN for that recipient.

5.2.3 Local delivery of messages

  • MUST(a) If the NOTIFY parameter was supplied for that recipient, with an esmtp-value containing the SUCCESS keyword, the MTA MUST issue a "delivered" DSN for that recipient.
  • MUST NOT(b) If the NOTIFY parameter was supplied for that recipient which did not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for that recipient.
  • MUST NOT(c) If the NOTIFY parameter was not supplied for that recipient, the MTA MUST NOT issue a DSN.

5.2.4 Gatewaying a message into a foreign environment

  • SHOULDnotification thus issued will be translated into a DSN and delivered to the original sender, then the MTA SHOULD gateway the message into the foreign environment, requesting notification under the desired conditions, without itself issuing a DSN.
  • SHOULD(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the destination environment cannot return an appropriate notification on successful delivery, the MTA SHOULD issue a "relayed" DSN for that recipient.
  • MUST NOT(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a DSN MUST NOT be issued.
  • SHOULDIf possible, the MTA SHOULD direct the destination environment to not issue delivery notifications for that recipient.
  • SHOULD NOT(d) If the NOTIFY parameter was not supplied for a particular recipient, a DSN SHOULD NOT be issued by the gateway.
  • SHOULDThe gateway SHOULD attempt to ensure that appropriate notification will be provided by the foreign mail environment if eventual delivery failure occurs, and that no notification will be issued on successful delivery.
  • SHOULD(e) When gatewaying a message into a foreign environment, the return-of-content conditions specified by any RET parameter are nonbinding; however, the MTA SHOULD attempt to honor the request using whatever mechanisms exist in the foreign environment.

5.2.5 Delays in delivery

  • MAYIf a conforming MTA receives a message via the SMTP protocol, and is unable to deliver or relay the message to one or more recipients for an extended length of time (to be determined by the MTA), it MAY issue a "delayed" DSN for those recipients, subject to the following conditions:
  • MAY(a) If the NOTIFY parameter was supplied for a recipient and its value included the DELAY keyword, a "delayed" DSN MAY be issued.
  • MAY(b) If the NOTIFY parameter was not supplied for a recipient, a "delayed" DSN MAY be issued.
  • MUST NOT(c) If the NOTIFY parameter was supplied which did not contain the DELAY keyword, a "delayed" DSN MUST NOT be issued.

5.2.6 Failure of a conforming MTA to deliver a message

  • MUST(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-keyword containing the value FAILURE, a "failed" DSN MUST be issued by the MTA.
  • MUST NOT(b) If a NOTIFY parameter was supplied for the recipient which did not contain the value FAILURE, a DSN MUST NOT be issued for that recipient.
  • MAYHowever, the MTA MAY inform the local postmaster of the delivery failure via some appropriate mechanism which does not itself result in the generation of DSNs.
  • MUST(c) If no NOTIFY parameter was supplied for the recipient, a "failed" DSN MUST be issued.
  • MUSTIf a DSN is issued for such a recipient, the Action value MUST be "failed".

5.2.7 Forwarding, aliases, and mailing lists

  • MUSTIf the NOTIFY parameter for the list submission address contained the SUCCESS keyword, a "delivered" DSN MUST be returned to the sender of the original message.
  • MAYHowever, even if a "delivered" DSN was issued by the MTA, a mailing list which rejects a message submission MAY notify the sender that the message was rejected using an ordinary message instead of a DSN.
  • MAYThis address MAY be that of a process that recognizes DSNs and processes them automatically, but it MUST forward unrecognized messages to the human responsible for the list.
  • MUST NOT(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the redistributed message MUST NOT be derived from those of the original message.
  • MAY(c) The NOTIFY and RET parameters MAY be specified by the local postmaster or the list administrator.
  • SHOULDIf ORCPT parameters are supplied during redistribution to the list subscribers, they SHOULD contain the addresses of the list subscribers in the format used by the mailing list.
  • SHOULD NOTUnder normal circumstances, when a message arrives for an "alias" which has a single forwarding address, a DSN SHOULD NOT be issued.
  • SHOULDAny ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with the message as it is redistributed to the forwarding address.

5.2.8 DSNs describing delivery to multiple recipients

  • SHOULD NOTIf a DSN is issued for some recipients in an SMTP transaction and not for others according to the rules above, the DSN SHOULD NOT contain information for recipients for whom DSNs would not otherwise have been issued.

5.3 Handling of messages from other sources

  • MUSTHowever, if such requests are transmitted within the message itself (for example in the message headers), the requests MUST be removed from the message before it is transmitted via SMTP.
  • SHOULDFor messages gatewayed from non-SMTP sources and further relayed by SMTP, the gateway SHOULD, using the SMTP extensions described here, attempt to provide the delivery reporting conditions expected by the source mail environment.
  • SHOULDIf appropriate, any DSNs returned to the source environment SHOULD be translated into the format expected in that environment.

5.4 Implementation limits

  • MUSTA conforming MTA MUST accept ESMTP parameters of at least the following sizes:
  • SHOULD NOTHowever, user agents which use SMTP as a message submission protocol SHOULD NOT generate ENVID parameters which are longer than 38 characters in length.
  • MUSTA conforming MTA MUST be able to accept SMTP command-lines which are at least 1036 characters long (530 characters for the ORCPT and NOTIFY parameters of the RCPT command, in addition to the 512
  • MUSTIf other SMTP extensions are supported by the MTA, the MTA MUST be able to accept a command-line large enough for each SMTP command and any combination of ESMTP parameters which may be used with that command.

6.1 SMTP Envelope to be used with Delivery Status Notifications

  • MUSTThe DSN sender address (in the SMTP MAIL command) MUST be a null reverse-path ("<>"), as required by section 5.3.3 of [11].
  • MUST NOTWhen transmitting a DSN via SMTP, the RET parameter MUST NOT be used.
  • MAYThe NOTIFY parameter MAY be used, but its value MUST be NEVER.
  • MAYThe ENVID parameter (with a newly generated envelope-id) and/or ORCPT parameter MAY be used.

6.2 Contents of the DSN

  • SHOULDWhen the value of the RET parameter is FULL, the full message SHOULD be returned for any DSN which conveys notification of delivery failure.
  • MAY(However, if the length of the message is greater than some implementation-specified length, the MTA MAY return only the headers even if the RET parameter specified FULL.) If a DSN contains no notifications of delivery failure, the MTA SHOULD return only the headers.

6.3 Message/delivery-status fields

  • MUST(a) if an ENVID parameter was present on the MAIL command, an Original-Envelope-ID field MUST be supplied, and the value associated with the ENVID parameter must appear in that field.
  • MUST NOTIf the message was received via SMTP with no ENVID parameter, the Original-Envelope-ID field MUST NOT be supplied.
  • MUST(b) The Reporting-MTA field MUST be supplied.
  • MUSTIf Reporting MTA can determine its fully-qualified Internet domain name, the MTA- name-type subfield MUST be "dns", and the field MUST contain the fully-qualified domain name of the Reporting MTA.
  • MUST NOTIf the fully-qualified Internet domain name of the Reporting MTA is not known (for example, for an SMTP server which is not directly connected to the Internet), the Reporting-MTA field may contain any string identifying the MTA, however, in this case the MTA- name-type subfield MUST NOT be "dns".
  • MAY(c) Other per-message fields as defined in [3] MAY be supplied as appropriate.
  • MUST(d) If the ORCPT parameter was provided for this recipient, the Original-Recipient field MUST be supplied, with its value taken from the ORCPT parameter.
  • MUST NOTIf no ORCPT parameter was provided for this recipient, the Original-Recipient field MUST NOT appear.
  • MUST(e) The Final-Recipient field MUST be supplied.
  • MUSTIt MUST contain the recipient address from the message envelope.
  • MUST(f) The Action field MUST be supplied.
  • MUST(g) The Status field MUST be supplied, using a status-code from [6].
  • MUSTIf there is no specific code which suitably describes a delivery failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent failure) MUST be used.
  • MUST(h) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Remote-MTA field MUST be supplied for each of those recipients.
  • MUST(i) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients.
  • MAY(j) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be supplied for each recipient, which contains the address of that recipient which was presented to the remote SMTP server.
  • MAY(k) Other per-recipient fields defined in [3] MAY appear, as appropriate.

9.1 "rfc822" address-type

  • MUST NOTHowever, an MTA MUST NOT modify an address obtained from the message envelope to force it to conform to syntax rules.

9.2 "smtp" diagnostic-type

  • SHOULDFor a single-line SMTP reply to an SMTP command, the diagnostic-code SHOULD be an exact transcription of the reply.

9.3 "dns" MTA-name-type

  • SHOULDMTA names of type "dns" SHOULD be valid Internet domain names.

Every current email RFC