📄 rfc1894.txt
字号:
Moore & Vaudreuil Standards Track [Page 12]
RFC 1894 Delivery Status Notifications January 1996
sender's environment recipient's environment
............................ ..........................................
: :
(1) : : (2)
+-----+ +--------+ +--------+ +---------+ +---------+ +------+
| | | | | | |Received-| | | | |
| |=>|Original|=>| |->| From |->|Reporting|-->|Remote|
| user| | MTA | | | | MTA | | MTA |<No| MTA |
|agent| +--------+ |Gateway | +---------+ +----v----+ +------+
| | | | |
| | <============| |<-------------------+
+-----+ | |(4) (3)
+--------+
: :
...........................: :.........................................
Figure 2. DSNs in the presence of gateways
(1) message is gatewayed into recipient's environment
(2) attempt to relay message fails
(3) reporting-mta (in recipient's environment) returns nondelivery
notification
(4) gateway translates foreign notification into a DSN
The mta-name portion of the Reporting-MTA field is formatted
according to the conventions indicated by the mta-name-type subfield.
If an MTA functions as a gateway between dissimilar mail environments
and thus is known by multiple names depending on the environment, the
mta-name subfield SHOULD contain the name used by the environment
from which the message was accepted by the Reporting-MTA.
Because the exact spelling of an MTA name may be significant in a
particular environment, MTA names are CASE-SENSITIVE.
2.2.3 The DSN-Gateway field
The DSN-Gateway field indicates the name of the gateway or MTA which
translated a foreign (non-Internet) delivery status notification into
this DSN. This field MUST appear in any DSN which was translated by
a gateway from a foreign system into DSN format, and MUST NOT appear
otherwise.
dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
Moore & Vaudreuil Standards Track [Page 13]
RFC 1894 Delivery Status Notifications January 1996
For gateways into Internet mail, the MTA-name-type will normally be
"smtp", and the mta-name will be the Internet domain name of the
gateway.
2.2.4 The Received-From-MTA DSN field
The optional Received-From-MTA field indicates the name of the MTA
from which the message was received.
received-from-mta-field =
"Received-From-MTA" ":" mta-name-type ";" mta-name
If the message was received from an Internet host via SMTP, the
contents of the mta-name subfield SHOULD be the Internet domain name
supplied in the HELO or EHLO command, and the network address used by
the SMTP client SHOULD be included as a comment enclosed in
parentheses. (In this case, the MTA-name-type will be "smtp".)
The mta-name portion of the Received-From-MTA field is formatted
according to the conventions indicated by the MTA-name-type subfield.
Since case is significant in some mail systems, the exact spelling,
including case, of the MTA name SHOULD be preserved.
2.2.5 The Arrival-Date DSN field
The optional Arrival-Date field indicates the date and time at which
the message arrived at the Reporting MTA. If the Last-Attempt-Date
field is also provided in a per-recipient field, this can be used to
determine the interval between when the message arrived at the
Reporting MTA and when the report was issued for that recipient.
arrival-date-field = "Arrival-Date" ":" date-time
The date and time are expressed in RFC 822 'date-time' format, as
modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
2.3 Per-Recipient DSN fields
A DSN contains information about attempts to deliver a message to one
or more recipients. The delivery information for any particular
recipient is contained in a group of contiguous per-recipient fields.
Each group of per-recipient fields is preceded by a blank line.
Moore & Vaudreuil Standards Track [Page 14]
RFC 1894 Delivery Status Notifications January 1996
The syntax for the group of per-recipient fields is as follows:
per-recipient-fields =
[ original-recipient-field CRLF ]
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ diagnostic-code-field CRLF ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
2.3.1 Original-Recipient field
The Original-Recipient field indicates the original recipient address
as specified by the sender of the message for which the DSN is being
issued.
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
generic-address = *text
The address-type field indicates the type of the original recipient
address. If the message originated within the Internet, the
address-type field field will normally be "rfc822", and the address
will be according to the syntax specified in [6]. The value
"unknown" should be used if the Reporting MTA cannot determine the
type of the original recipient address from the message envelope.
This field is optional. It should be included only if the sender-
specified recipient address was present in the message envelope, such
as by the SMTP extensions defined in [4]. This address is the same
as that provided by the sender and can be used to automatically
correlate DSN reports and message transactions.
2.3.2 Final-Recipient field
The Final-Recipient field indicates the recipient for which this set
of per-recipient fields applies. This field MUST be present in each
set of per-recipient data.
Moore & Vaudreuil Standards Track [Page 15]
RFC 1894 Delivery Status Notifications January 1996
The syntax of the field is as follows:
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
The generic-address subfield of the Final-Recipient field MUST
contain the mailbox address of the recipient (from the transport
envelope) as it was when the message was accepted for delivery by the
Reporting MTA.
The Final-Recipient address may differ from the address originally
provided by the sender, because it may have been transformed during
forwarding and gatewaying into an totally unrecognizable mess.
However, in the absence of the optional Original-Recipient field, the
Final-Recipient field and any returned content may be the only
information available with which to correlate the DSN with a
particular message submission.
The address-type subfield indicates the type of address expected by
the reporting MTA in that context. Recipient addresses obtained via
SMTP will normally be of address-type "rfc822".
NOTE: The Reporting MTA is not expected to ensure that the address
actually conforms to the syntax conventions of the address-type.
Instead, it MUST report exactly the address received in the envelope,
unless that address contains characters such as CR or LF which may
not appear in a DSN field.
Since mailbox addresses (including those used in the Internet) may be
case sensitive, the case of alphabetic characters in the address MUST
be preserved.
2.3.3 Action field
The Action field indicates the action performed by the Reporting-MTA
as a result of its attempt to deliver the message to this recipient
address. This field MUST be present for each recipient named in the
DSN.
The syntax for the action-field is:
action-field = "Action" ":" action-value
action-value =
"failed" / "delayed" / "delivered" / "relayed" / "expanded"
Moore & Vaudreuil Standards Track [Page 16]
RFC 1894 Delivery Status Notifications January 1996
The action-value may be spelled in any combination of upper and lower
case characters.
"failed" indicates that the message could not be delivered to the
recipient. The Reporting MTA has abandoned any attempts to
deliver the message to this recipient. No further
notifications should be expected.
"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. Additional notification messages may be
issued as the message is further delayed or successfully
delivered, or if delivery attempts are later abandoned.
"delivered" indicates that the message was successfully delivered to
the recipient address specified by the sender, which
includes "delivery" to a mailing list exploder. 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 gatewayed
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.
Using the terms "mailing list" and "alias" as defined in
[4], section 7.2.7: An action-value of "expanded" is only
to be used when the message is delivered to a multiple-
recipient "alias". An action-value of "expanded" SHOULD
NOT be used with a DSN issued on delivery of a message to a
"mailing list".
NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might
seem to be redundant with the 'status' field, this is not the case.
In particular, a "temporary failure" ("4") status code could be used
with an action-value of either "delayed" or "failed". For example,
assume that an SMTP client repeatedly tries to relay a message to the
mail exchanger for a recipient, but fails because a query to a domain
Moore & Vaudreuil Standards Track [Page 17]
RFC 1894 Delivery Status Notifications January 1996
name server timed out. After a few hours, it might issue a "delayed"
DSN to inform the sender that the message had not yet been delivered.
After a few days, the MTA might abandon its attempt to deliver the
message and return a "failed" DSN. The status code (which would
begin with a "4" to indicate "temporary failure") would be the same
for both DSNs.
Another example for which the action and status codes may appear
contradictory: If an MTA or mail gateway cannot deliver a message
because doing so would entail conversions resulting in an
unacceptable loss of information, it would issue a DSN with the
'action' field of "failure" and a status code of 'XXX'. If the
message had instead been relayed, but with some loss of information,
it might generate a DSN with the same XXX status-code, but with an
action field of "relayed".
2.3.4 Status field
The per-recipient Status field contains a transport-independent
status code which indicates the delivery status of the message to
that recipient. This field MUST be present for each delivery attempt
which is described by a DSN.
The syntax of the status field is:
status-field = "Status" ":" status-code
status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
; White-space characters and comments are NOT allowed within a
; status-code, though a comment enclosed in parentheses MAY follow
; the last numeric subfield of the status-code. Each numeric
; subfield within the status-code MUST be expressed without
; leading zero digits.
Status codes thus consist of three numerical fields separated by ".".
The first sub-field indicates whether the delivery attempt was
successful (2 = success, 4 = persistent temporary failure, 5 =
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -