kilabit.info
Build | sr.ht | GitHub | Twitter

The DSN specifications contains four document set describing the delivery status report service: Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports (RFC 3461), a MIME content for the reporting of delivery reports (RFC 3462), an enumeration of extended status codes (RFC 3463), and a multipart container for the delivery report (RFC 3464).

1. Extension for DSN (RFC 3461)

xtext = *( xchar / hexchar )

xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
        except for "+" and "=".

; "hexchar"s are intended to encode octets that cannot appear
; as ASCII characters within an esmtp-value.

hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits

The EHLO extension name is DSN.

This extension add two optional parameters to MAIL commands: RET and ENVID.

This extension add two optional parameters to RCTP commands: NOTIFY and ORCPT.

SMTP server MUST return the same reply-code as it would to the same MAIL/RCPT command without parameters.

SMTP server MUST NOT refuse a MAIL/RCPT command based on the absence or presence of valid parameters.

If the value is invalid or more than one ENVID or RET in MAIL command, the server MUST issue the reply-code "501 syntax error in parameter".

A DSN MUST NOT be returned to the sender if SMTP MAIL command was NULL ("<>"), even if the sender’s address is available from other sources (e.g., the message header). Instead, it SHOULD inform the local postmaster of delivery failures.

1.1. Relaying to other confirming SMTP server

Any DSN extension parameter that is received MUST also appear on MAIL and/or RCPT command which the message is relayed.

An ORCPT parameter MAY be added to the RCPT command when the message is relayed using address from RCPT command.

1.2. Relaying to non-conforming SMTP server

If NOTIFY paramater contains SUCCESS and SMTP server return a success (2xx) to RCPT command, client MUST issue a "relayed" DSN for that recipient.

If NOTIFY parameter contains "FAILURE" and SMTP server return a permanent failure (5xx) to RCPT command, client MUST issue a "failed" DSN for that recipient.

If NOTIFY parameter contains NEVER and SMTP server return a success or permanent failure (5xx) to RCPT command, client MUST NOT issue a DSN that recipient. Client MAY inform the local postmaster of the delivery failure.

If NOTIFY parameter contains NEVER, client MAY use "<>" on separate MAIL command.

If no NOTIFY parameter, and server return a success, client MUST NOT issue any DSN for that recipient.

If no NOTIFY parameter, and server return 5xx, client MUST issue a "failed" DSN for that recipient.

1.3. Local Delivery

If NOTIFY contains SUCCESS, MTA MUST issue "delivered" DSN for that recipient.

If NOTIFY contains SUCCESS or no NOTIFY parameter, MTA MUST NOT issue a DSN for that recipient.

1.4. Delays in delivery

If NOTIFY contains DELAY or no NOTIFY parameter, MTA MAY issue "delayed" DSN for that recipient.

If NOTIFY parameter is issued without DELAY keyword, MTA MUST NOT issue "delayed" DSN for that recipient.

1.5. Failure on delivery

If NOTIFY parameter contains FAILURE or no NOTIFY parameter, a "failed" DSN MUST be issued.

If NOTIFY parameter does not contains FAILURE, DSN MUST NOT be issued, but it MAY inform the local postmaster via mechanism that does not using DSN.

1.6. Mailing List

If NOTIFY parameter contains SUCCESS, and the message is placed on list’s mailbox or accepted by list’s server, a "delivered" DSN must be issued.

When redistributed to members of mailing list,

  • The envelope return address is rewritten to point to the list maintainer.

  • The ENVID, NOTIFY, RET, and ORCPT parameters MUST NOT be derived from the original message.

  • The NOTIFY and RET parameters MAY be specified by the list administrator.

  • ORCPT parameter SHOULD contain the address of member.

1.7. MAIL RET Parameter

"RET=" "FULL" / "HDRS"

FULL requests that the entire message be returned in any "failed" DSN issued for this recipient.

HDRS only the headers of the message be returned.

It MAY be up to 8 characters.

The parameter value is case insensitive.

If no RET parameter is defined or their value is emtpy, MTA MAY return headers only or full message.

If a DSN contains no indications of delivery failure, only the headers of the message SHOULD be returned.

1.8. MAIL ENVID Parameter

"ENVID=" *xtext

ENVID, or enveloper identifier, purpose is to allow the sender of a message to identify the transaction for which the DSN was issued.

It MAY be up to 100 characters.

The ENVID MUST consist of printable (graphic and white space) characters from the US-ASCII.

1.9. RCPT NOTIFY Parameter

"NOTIFY=" "NEVER" / ("SUCCESS" [ "," "FAILURE"] [ "," "DELAY" ])

The NEVER keyword MUST appear by itself.

"NEVER" requests that a DSN not be returned to the sender under any conditions.

"SUCCESS" or "FAILURE" value indicated that a DSN be issued on successful delivery or delivery failure, respectively.

"DELAY" indicates the sender’s willingness to receive "delayed" DSNs.

It MAY be up to 28 characters.

The absence of a NOTIFY parameter MAY be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.

1.10. RCPT ORCPT Parameter

"ORCPT=" addr-type ";" xtext

ORCPT parameter is used to specify an "original" recipient address that corresponds to the actual recipient.

It MUST have an associated value.

It MAY be up to 500 characters.

When used on personal message, it MUST contain the same address as the RCPT TO address.

When used on mailing-list, the ORCPT parameter MUST match the new RCPT TO address of each recipient, not the address specified by the original sender of the message.

1.11. Format of delivery notifications

MAIL command argument MUST be a null ("<>").

RCPT command argument is copied from the original message MAIL command.

The RET parameter MUST NOT be used. The NOTIFY parameter MAY be used, with value MUST be NEVER. The ENVID and/or ORCPT parameter MAY be used.

The MIME message is "multipart/report" with "report-type" is "delivery-status".

2. Multipart-Report Content Type (RFC 3462)

This section provide summary and notes on implementation of "multipart/report" MIME type on SMTP protocol as defined in RFC 3462.

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind.

Format of content-type,

"Content-Type:" SP "multipart/report;"
	FWS "report-type=" report-type ";"
	FWS "boundary=" boundary

When used to send a report, it MUST be the top-level MIME content type.

The Multipart/Report content-type contains either two or three sub- parts, in the following order:

1. (Required) The first body part contains human readable message.

2. (Required) A machine parse-able body part containing an account of the reported message handling event. The purpose of this body part is to provide a machine-readable description of the conditions that caused the report to be generated, along with details not present in the first body part that may be useful to human experts. An initial body part, "message/delivery-status" is defined in RFC 3464 (see below).

3. (Optional) A body part containing the returned message or a portion thereof.

2.1. The text/rfc822-headers content-type

Format,

"Content-Type:" SP "text/rfc822-headers"

The text/rfc822-headers body part should contain all the RFC822 header lines from the message which caused the report.

3. Enhanced Mail System Status Codes (RFC 3463)

Syntax,

status-code = class "." subject "." detail
class = "2"/"4"/"5"
subject = 1*3digit
detail = 1*3digit

White-space characters and comments are NOT allowed within a status-code.

Each numeric sub-code within the status-code MUST be expressed without leading zero digits.

3.1. Class

  • 2.XXX.XXX Success

  • 4.XXX.XXX Persistent Transient Failure

  • 5.XXX.XXX Permanent Failure

3.2. Subject

  • X.0.XXX Other or Undefined Status

  • X.1.XXX Addressing Status. Problem on sender’s recipient address.

    • X.1.0 Other address status

    • X.1.1 Bad destination mailbox address

    • X.1.2 Bad destination system address

    • X.1.3 Bad destination mailbox address syntax

    • X.1.4 Destination mailbox address ambiguous

    • X.1.5 Destination mailbox address valid

    • X.1.6 Mailbox has moved

    • X.1.7 Bad sender’s mailbox address syntax

    • X.1.8 Bad sender’s system address

  • X.2.XXX Mailbox Status. Problem on receiver.

    • X.2.0 Other or undefined mailbox status

    • X.2.1 Mailbox disabled, not accepting messages

    • X.2.2 Mailbox full

    • X.2.3 Message length exceeds administrative limit.

    • X.2.4 Mailing list expansion problem

  • X.3.XXX Mail System Status. Problem on receiver (destination MTA).

    • X.3.0 Other or undefined mail system status

    • X.3.1 Mail system full

    • X.3.2 System not accepting network messages

    • X.3.3 System not capable of selected features

    • X.3.4 Message too big for system

  • X.4.XXX Network and Routing Status. Problem receiver (destination MTA).

    • X.4.0 Other or undefined network or routing status

    • X.4.1 No answer from host

    • X.4.2 Bad connection

    • X.4.3 Routing server failure

    • X.4.4 Unable to route

    • X.4.5 Network congestion

    • X.4.6 Routing loop detected

    • X.4.7 Delivery time expired

  • X.5.XXX Mail Delivery Protocol Status

    • X.5.0 Other or undefined protocol status

    • X.5.1 Invalid command

    • X.5.2 Syntax error

    • X.5.3 Too many recipients

    • X.5.4 Invalid command arguments

    • X.5.5 Wrong protocol version

  • X.6.XXX Message Content or Media Status.

    • X.6.0 Other or undefined media error

    • X.6.1 Media not supported

    • X.6.2 Conversion required and prohibited

    • X.6.3 Conversion required but not supported

    • X.6.4 Conversion with loss performed

    • X.6.5 Conversion failed

  • X.7.XXX Security or Policy Status.

    • X.7.0 Other or undefined security status

    • X.7.1 Delivery not authorized, message refused

    • X.7.2 Mailing list expansion prohibited

    • X.7.3 Security conversion required but not possible

    • X.7.4 Security features not supported

    • X.7.5 Cryptographic failure

    • X.7.6 Cryptographic algorithm not supported

    • X.7.7 Message integrity failure

4. Message Format for DSN (RFC 3464)

This section provide summary and notes on implementation of DSN on SMTP protocol as defined in RFC 3464.

A DSN is a "multipart/report" MIME message with three components,

1. Human readable explanation of the DSN 2. Machine readable delivery-status 3. Original message

4.1. Human readable explanation of the DSN

Format,

Date: {timestamp-with-zone}
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
To: <owner-info-mime@cs.utk.edu>
MIME-Version: 1.0
Content-Type: message/report;
	report-type=delivery-status;
	boundary="{boundary}"
Subject: Returned mail: Cannot send message for 5 days

--{boundary}

	(Explain the notification in human readable format)

The "From" field of message header of DSN SHOULD contain the address of human who responsible at Reporting-MTA and SHOULD be chosen so that DSN will not generate mail loops.

The "To" field of message header and "RCPT TO:" parameter is return-path from "MAIL FROM:" command.

4.2. Machine readable explanation of DSN

Header format,

CRLF
"--" boundary CRLF
"Content-Type: message/delivery-status" CRLF
CRLF
message-fields
CRLF
1*(recipient-fields)

The body of this sub-part contain message-fields and one or more recipient-fields.

Any header that start with "X-" are extension fields; such names are reserved for experimental use.

Each sender-specified recipient address SHOULD result in at most one "delivered" or "failed" DSN for that recipient

4.2.1. Format for message-fields

[ "Original-Envelope-Id:" SP envelope-id CRLF ]
"Reporting-MTA:" SP mta-type ";" MTA-name CRLF
[ "DSN-Gateway:" SP "dns;" MTA-name CRLF ]
[ "Received-From-MTA:" SP "dns;" MTA-name CRLF ]
[ "Arrival-Date" ":" date-time CRLF ]

The "Original-Envelope-ID" MUST be supplied if original message MAIL command contains ENVID, except when a DSN is issued by the sender’s MTA itself (Sender MTA = Reporting MTA)

If no ENVID parameter, the "Original-Envelope-ID" field MUST NOT be supplied.

The "envelope-id" is CASE-SENSITIVE. The DSN MUST preserve the original case and spelling of the envelope-id.

MTA-type MUST be "dns" if MTA is connected to internet, otherwise it SHOULD be "x-local-hostname".

MTA-name are case sensitive. MTA-name SHOULD be valid Internet domain names. If such domain names are not available, a domain-literal containing the internet protocol address is acceptable.

DSN-Gateway field MUST appear in any DSN that was translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.

Received-From-MTA field indicates the name of the Reporting MTA.

Arrival-Date field indicates the date and time at which the message arrived at the Reporting MTA.

4.2.2. Format for recipient-fields

[ "Original-Recipient:" SP address-type ";" generic-address CRLF ]
"Final-Recipient:" SP address-type ";" generic-address CRLF
"Action:" SP action-value CRLF
"Status:" SP status-code CRLF
[ "Remote-MTA: dns;" mta-name CRLF ]
[ "Diagnostic-Code:" SP diagnostic-type ";" *text CRLF ]
[ "Last-Attempt-Date:" date-time CRLF ]
[ "Final-Log-ID:" *text CRLF ]
[ "Will-Retry-Until" ":" date-time CRLF ]
Original-Recipient and Final-Recipient

address-type field is "rfc822".

address-type field is "unknown" if the Reporting MTA cannot determine the type of the original recipient address from the message envelope.

The generic-address sub-field of Original-Recipient field is recipient address in the message envelope.

The generic-address sub-field of the Final-Recipient field MUST contain the mailbox address of the recipient (from the transport envelope), as it was when the Reporting MTA accepted the message for delivery.

The case of alphabetic characters in the address MUST be preserved.

If sender supplied ORCPT parameter, the Original-Recipient MUST be supplied, otherwise this field MUST NOT appear.

Action

action-value is case insensitive, with one of the following values,

  • "failed" indicates that the message could not be delivered to the recipient.

  • "delayed" indicates that the Reporting MTA has so far been unable to deliver or relay the message, but it will continue to attempt to do so.

  • "delivered" indicates that the message was successfully delivered to the recipient address specified by the sender. It does not indicate that the message has been read. This is a terminal state and no further DSN for this recipient should be expected.

  • "relayed" indicates that the message has been relayed or gateway-ed into an environment that does not accept responsibility for generating DSNs upon successful delivery. This action-value SHOULD NOT be used unless the sender has requested notification of successful delivery for this recipient.

  • "expanded" indicates that the message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. An action-value of "expanded" differs from "delivered" in that "expanded" is not a terminal state. Further "failed" and/or "delayed" notifications may be provided. This value SHOULD NOT be used with a DSN issued on delivery of a message to a "mailing list".

Status

Each numeric sub-field within the status-code MUST be expressed without leading zero digits.

See section for its value.

Remote-MTA

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.

Diagnostic-Code

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, with diagnostic-type is set to "smtp".

Last-Attempt-Date

The Last-Attempt-Date field gives the date and time of the last attempt to relay, gateway, or deliver the message (whether successful or unsuccessful) by the Reporting MTA.

It MUST NOT be included if the actual date and time of the last delivery attempt are not available.

Final-Log-ID

This can be useful as an index to the final-mta’s log entry for that delivery attempt.

Will-Retry-Until

This header is for "delayed" status, which inform the final MTA the data and time when the message will be abandoned if delivery is keep failing.

4.3. Original message

This sub-part contains the original message headers and/or message data, depends on the value of RET parameter on RCPT command.