draft-ietf-msgtrk-trkstat-02.txt   draft-ietf-msgtrk-trkstat-03.txt 
Internet Draft E. Allman Internet Draft E. Allman
draft-ietf-msgtrk-trkstat-02.txt Sendmail, Inc. draft-ietf-msgtrk-trkstat-03.txt Sendmail, Inc.
Valid for six months July 6, 2001 Valid for six months November 2, 2001
Updates: RFC 1893 Updates: RFC 1893
The Message/Tracking-Status MIME Extension The Message/Tracking-Status MIME Extension
<draft-ietf-msgtrk-trkstat-02.txt> <draft-ietf-msgtrk-trkstat-03.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also dis- areas, and its working groups. Note that other groups may also
tribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
skipping to change at page 2, line ? skipping to change at page 2, line ?
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the ietf-msgtrk@imc.org mailing list. An archive of the mailing to the ietf-msgtrk@imc.org mailing list. An archive of the mailing
list may be found at list may be found at
http://www.imc.org/ietf-msgtrk/index.html http://www.imc.org/ietf-msgtrk/index.html
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
1. Abstract 1. Abstract
Message Tracking is expected to be used to determine the sta- Message Tracking is expected to be used to determine the
tus of undelivered e-mail upon request. Tracking is used in con- status of undelivered e-mail upon request. Tracking is used in
junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes- conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and
sage Disposition Notifications [RFC-MDN]; generally, a message Message Disposition Notifications [RFC-MDN]; generally, a message
tracking request will be issued only when a DSN or MDN has not been tracking request will be issued only when a DSN or MDN has not been
received within a reasonable timeout period. received within a reasonable timeout period.
This memo defines a MIME [RFC-MIME] content-type for message This memo defines a MIME [RFC-MIME] content-type for message
tracking status in the same spirit as RFC 1894, ``An Extensible tracking status in the same spirit as RFC 1894, ``An Extensible
Message Format for Delivery Status Notifications'' [RFC-DSN-STAT]. Message Format for Delivery Status Notifications'' [RFC-DSN-STAT].
It is to be issued upon a request as described in ``Message Track- It is to be issued upon a request as described in ``Message
ing Query Protocol'' [DRAFT-MTRK-MTQP]. This memo defines only the Tracking Query Protocol'' [DRAFT-MTRK-MTQP]. This memo defines
format of the status information. An extension to SMTP [RFC-ESMTP] only the format of the status information. An extension to SMTP
to label messages for further tracking and request tracking status [RFC-ESMTP] to label messages for further tracking and request
is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
2. Other Documents and Conformance 2. Other Documents and Conformance
The model used for Message Tracking is described in [DRAFT- The model used for Message Tracking is described in [DRAFT-
MTRK-MODEL]. MTRK-MODEL].
Message tracking is intended for use as a "last resort" mecha- Message tracking is intended for use as a "last resort"
nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-
SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]
provide the primary delivery status. Only if no response is would provide the primary delivery status. Only if no response is
received from either of these mechanisms would Message Tracking be received from either of these mechanisms would Message Tracking be
used. used.
This document is based on [RFC-DSN-STAT]. Sections 1.3 (Ter- This document is based on [RFC-DSN-STAT]. Sections 1.3
minology), 2.1.1 (General conventions for DSN fields), 2.1.2 (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2
("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC
822) of [RFC-DSN-STAT] are included into this document by refer- 822) of [RFC-DSN-STAT] are included into this document by
ence. Other sections are further incorporated as described herein. reference. Other sections are further incorporated as described
herein.
Syntax notation in this document conforms to [RFC-ABNF]. Syntax notation in this document conforms to [RFC-ABNF].
The following lexical tokens, defined in [RFC-MSGFMT], are The following lexical tokens, defined in [RFC-MSGFMT], are
used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,
DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical
token is defined in [RFC-HOSTREQ]. token is defined in [RFC-HOSTREQ].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119 in this document are to be interpreted as described in RFC 2119
[RFC-KEYWORDS]. [RFC-KEYWORDS].
3. Format of a Message Tracking Status Notification 3. Format of a Message Tracking Status Notification
A Message Tracking Status Notification (MTSN) is intended to A Message Tracking Status Notification (MTSN) is intended to
be returned as the body of a Message Tracking request [DRAFT-MTRK- be returned as the body of a Message Tracking request [DRAFT-MTRK-
MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] MTQP]. The actual body MUST be a multipart/related [RFC-RELATED]
with type parameter of "message/tracking-status"; each subpart MUST with type parameter of "message/tracking-status"; each subpart MUST
be type "message/tracking-status" as described herein. be of type "message/tracking-status" as described herein. The
multipart/related body can include multiple message/tracking-status
parts if an MTQP server chains requests to the next server; see
[DRAFT-MTRK-MODEL] and [DRAFT-MTRK-MTQP] for more information about
chaining.
3.1. The message/tracking-status content-type 3.1. The message/tracking-status content-type
The message/tracking-status content-type is defined as fol- The message/tracking-status content-type is defined as
lows: follows:
MIME type name: message MIME type name: message
MIME subtype name: tracking-status MIME subtype name: tracking-status
Optional parameters: none Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and Encoding considerations: "7bit" encoding is sufficient and
MUST be used to maintain readability MUST be used to maintain readability
when viewed by non-MIME mail readers. when viewed by non-MIME mail readers.
Security considerations: discussed in section 4 of this memo. Security considerations: discussed in section 4 of this memo.
The body of a message/tracking-status is modeled after The body of a message/tracking-status is modeled after
[RFC-DSN-STAT]. That body consists of one or more "fields" for- [RFC-DSN-STAT]. That body consists of one or more "fields"
matted to according to the ABNF of RFC 822 header "fields" (see formatted to according to the ABNF of RFC 2822 header "fields"
[RFC-MSGFMT]). The per-message fields appear first, followed by (see [RFC-MSGFMT]). The per-message fields appear first,
a blank line. Following the per-message fields are one or more followed by a blank line. Following the per-message fields are
groups of per-recipient fields. Each group of per-recipient one or more groups of per-recipient fields. Each group of per-
fields is preceded by a blank line. Note that there will be a recipient fields is preceded by a blank line. Note that there
blank line between the final per-recipient field and the MIME will be a blank line between the final per-recipient field and
boundary, since one CRLF is necessary to terminate the field, the MIME boundary, since one CRLF is necessary to terminate the
and a second is necessary to introduce the MIME boundary. For- field, and a second is necessary to introduce the MIME boundary.
mally, the syntax of the message/tracking-status content is as Formally, the syntax of the message/tracking-status content is
follows: as follows:
tracking-status-content = tracking-status-content =
per-message-fields 1*( CRLF per-recipient-fields ) per-message-fields 1*( CRLF per-recipient-fields )
The per-message fields are described in section 3.2. The per- The per-message fields are described in section 3.2. The per-
recipient fields are described in section 3.3. recipient fields are described in section 3.3.
3.1.1. General conventions for MTSN fields 3.1.1. General conventions for MTSN fields
Section 2.1.1 (General conventions for DSN fields) of Section 2.1.1 (General conventions for DSN fields) of
[RFC-DSN-STAT] is included herein by reference. Notably, the [RFC-DSN-STAT] is included herein by reference. Notably, the
definition of xtext is identical to that of that document. definition of xtext is identical to that of that document.
3.1.2. *-type subfields 3.1.2. *-type subfields
Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is
included herein by reference. Notably, the definitions of included herein by reference. Notably, the definitions of
address-type, diagnostic-type, and MTA-name type are identi- address-type, diagnostic-type, and MTA-name type are
cal to that of RFC 1894. identical to that of RFC 1894.
3.2. Per-Message MTSN Fields 3.2. Per-Message MTSN Fields
Some fields of an MTSN apply to all of the addresses in a Some fields of an MTSN apply to all of the addresses in a
single envelope. These fields may appear at most once in any single envelope. These fields may appear at most once in any
MTSN. These fields are used to correlate the MTSN with the MTSN. These fields are used to correlate the MTSN with the
original message transaction and to provide additional informa- original message transaction and to provide additional
tion which may be useful to gateways. information which may be useful to gateways.
per-message-fields = per-message-fields =
original-envelope-id-field CRLF original-envelope-id-field CRLF
reporting-mta-field CRLF reporting-mta-field CRLF
arrival-date CRLF arrival-date CRLF
*( extension-field CRLF ) *( extension-field CRLF )
3.2.1. The Original-Envelope-Id field 3.2.1. The Original-Envelope-Id field
The optional Original-Envelope-Id field is defined as in The Original-Envelope-Id field is defined as in section
section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED. 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED.
3.2.2. The Reporting-MTA field 3.2.2. The Reporting-MTA field
The Reporting-MTA field is defined as in section 2.2.2 The Reporting-MTA field is defined as in section 2.2.2
of [RFC-DSN-STAT]. This field is REQUIRED. of [RFC-DSN-STAT]. This field is REQUIRED.
3.2.3. The Arrival-Date field 3.2.3. The Arrival-Date field
The Arrival-Date field is defined as in section 2.2.5 of The Arrival-Date field is defined as in section 2.2.5 of
[RFC-DSN-STAT]. This field is REQUIRED. [RFC-DSN-STAT]. This field is REQUIRED.
3.3. Per-Recipient MTSN fields 3.3. Per-Recipient MTSN fields
An MTSN contains information about attempts to deliver a An MTSN contains information about attempts to deliver a
message to one or more recipients. The delivery information for message to one or more recipients. The delivery information for
any particular recipient is contained in a group of contiguous any particular recipient is contained in a group of contiguous
per-recipient fields. Each group of per-recipient fields is per-recipient fields. Each group of per-recipient fields is
preceded by a blank line. preceded by a blank line.
The syntax for the group of per-recipient fields is as fol- The syntax for the group of per-recipient fields is as
lows: follows:
per-recipient-fields = per-recipient-fields =
original-recipient-field CRLF original-recipient-field CRLF
final-recipient-field CRLF final-recipient-field CRLF
action-field CRLF action-field CRLF
status-field CRLF status-field CRLF
[ remote-mta-field CRLF ] [ remote-mta-field CRLF ]
[ last-attempt-date-field CRLF ] [ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ] [ will-retry-until-field CRLF ]
*( extension-field CRLF ) *( extension-field CRLF )
3.3.1. Original-Recipient field 3.3.1. Original-Recipient field
The optional Original-Recipient field is defined as in The Original-Recipient field is defined as in section
section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED. 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED.
3.3.2. Final-Recipient field 3.3.2. Final-Recipient field
The required Final-Recipient field is defined as in sec- The required Final-Recipient field is defined as in
tion 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED. section 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED.
3.3.3. Action field 3.3.3. Action field
The required Action field indicates the action performed The required Action field indicates the action performed
by the Reporting-MTA as a result of its attempt to deliver by the Reporting-MTA as a result of its attempt to deliver
the message to this recipient address. This field MUST be the message to this recipient address. This field MUST be
present for each recipient named in the MTSN. The syntax is present for each recipient named in the MTSN. The syntax is
as defined in section 2.3.3 of RFC 1894. This field is as defined in section 2.3.3 of RFC 1894. This field is
REQUIRED. REQUIRED.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
have been enabled, a "failed" DSN should already have been enabled, a "failed" DSN should already
have been returned. have been returned.
delayed The message is currently waiting in the MTA delayed The message is currently waiting in the MTA
queue for future delivery. Essentially, this queue for future delivery. Essentially, this
action means "the message is located, and it is action means "the message is located, and it is
here." here."
delivered The message has been successfully delivered to delivered The message has been successfully delivered to
the final recipient. This includes "delivery" the final recipient. This includes "delivery"
to a mailing list exploder. It does not indi- to a mailing list exploder. It does not
cate that the message has been read. No further indicate that the message has been read. No
information is available; in particular, the further information is available; in particular,
tracking agent SHOULD NOT attempt further "down- the tracking agent SHOULD NOT attempt further
stream" tracking requests. "downstream" tracking requests.
expanded The message has been successfully delivered to expanded The message has been successfully delivered to
the recipient address as specified by the the recipient address as specified by the
sender, and forwarded by the Reporting-MTA sender, and forwarded by the Reporting-MTA
beyond that destination to multiple additional beyond that destination to multiple additional
recipient addresses. However, these additional recipient addresses. However, these additional
addresses are not trackable, and the tracking addresses are not trackable, and the tracking
agent SHOULD NOT attempt further "downstream" agent SHOULD NOT attempt further "downstream"
tracking requests. tracking requests.
relayed The message has been delivered into an environ- relayed The message has been delivered into an
ment that does not support message tracking. No environment that does not support message
further information is available; in particular, tracking. No further information is available;
the tracking agent SHOULD NOT attempt further in particular, the tracking agent SHOULD NOT
"downstream" tracking requests. attempt further "downstream" tracking requests.
transferred The message has been transferred to another transferred The message has been transferred to another
MTRK-compliant MTA. The tracking agent SHOULD MTRK-compliant MTA. The tracking agent SHOULD
attempt further "downstream" tracking requests. attempt further "downstream" tracking requests
unless that information is already given in a
chaining response.
opaque The message may or may not have been seen by opaque The message may or may not have been seen by
this system. No further information is avail- this system. No further information is
able or forthcoming. available or forthcoming.
There may be some confusion between when to use There may be some confusion between when to use
"expanded" versus "delivered". Whenever possible, "expanded" "expanded" versus "delivered". Whenever possible, "expanded"
should be used when the MTA knows that the message will be should be used when the MTA knows that the message will be
sent to multiple addresses. However, in some cases the sent to multiple addresses. However, in some cases the
delivery occurs to a program which, unknown to the MTA, delivery occurs to a program which, unknown to the MTA,
causes mailing list expansion; in the extreme case, the causes mailing list expansion; in the extreme case, the
delivery may be to a real mailbox that has the side effect of delivery may be to a real mailbox that has the side effect of
list expansion. If the MTA cannot ensure that this delivery list expansion. If the MTA cannot ensure that this delivery
will cause list expansion, it should set the action to will cause list expansion, it should set the action to
"delivered". "delivered".
3.3.4. Status field 3.3.4. Status field
The Status field is defined as in RFC 1894 section The Status field is defined as in RFC 1894 section
2.3.4. A new code is added to RFC 1893 [RFC-EMSSC], 2.3.4. A new code is added to RFC 1893 [RFC-EMSSC],
"Enhanced Mail System Status Codes", "Enhanced Mail System Status Codes",
X.1.9 Message relayed to non-compliant mailer" X.1.9 Message relayed to non-compliant mailer"
The mailbox address specified was valid, but the mes- The mailbox address specified was valid, but the
sage has been relayed to a system that does not speak message has been relayed to a system that does not
this protocol; no further information can be pro- speak this protocol; no further information can be
vided. provided.
A 2.1.9 Status field MUST be used exclusively with a A 2.1.9 Status field MUST be used exclusively with a
"relayed" Action field. This field is REQUIRED. "relayed" Action field. This field is REQUIRED.
3.3.5. Remote-MTA field 3.3.5. Remote-MTA field
The Remote-MTA field is defined as in section Reference The Remote-MTA field is defined as in section Reference
2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if
no delivery attempts have been made or if the Action field no delivery attempts have been made or if the Action field
has value "opaque". If delivery to some agent other than an has value "opaque". If delivery to some agent other than an
MTA (for example, a Local Delivery Agent) then this field MAY MTA (for example, a Local Delivery Agent) then this field MAY
skipping to change at page 6, line 42 skipping to change at page 6, line 42
The Last-Attempt-Date field is defined as in section The Last-Attempt-Date field is defined as in section
Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if
any delivery attempt has been made and the Action field does any delivery attempt has been made and the Action field does
not have value "opaque", in which case it will specify when not have value "opaque", in which case it will specify when
it last attempted to deliver this message to another MTA or it last attempted to deliver this message to another MTA or
other Delivery Agent. This field MUST NOT be included if no other Delivery Agent. This field MUST NOT be included if no
delivery attempts have been made. delivery attempts have been made.
3.3.7. Will-Retry-Until field 3.3.7. Will-Retry-Until field
The Will-Retry-Until field is defined as in section Ref- The Will-Retry-Until field is defined as in section
erence 2.3.8 of [RFC-DSN-STAT]. If the message is not in the Reference 2.3.8 of [RFC-DSN-STAT]. If the message is not in
local queue or the Action field has the value ``opaque'' the the local queue or the Action field has the value ``opaque''
Will-Retry-Until field MUST NOT be included; otherwise, this the Will-Retry-Until field MUST NOT be included; otherwise,
field is REQUIRED. this field SHOULD be included.
3.4. Extension fields 3.4. Extension fields
Future extension fields may be defined as defined in sec- Future extension fields may be defined as defined in
tion 2.4 of [RFC-DSN-STAT]. section 2.4 of [RFC-DSN-STAT].
3.5. Interaction Between MTAs and LDAs 3.5. Interaction Between MTAs and LDAs
A message that has been delivered to a Local Delivery Agent A message that has been delivered to a Local Delivery Agent
(LDA) that understands message tracking (in particular, an LDA (LDA) that understands message tracking (in particular, an LDA
speaking LMTP [RFC-LMTP] that supports the MTRK extension) speaking LMTP [RFC-LMTP] that supports the MTRK extension)
SHOULD pass the tracking request to the LDA. In this case, the SHOULD pass the tracking request to the LDA. In this case, the
Action field for the MTA->LDA exchange will look the same as a Action field for the MTA->LDA exchange will look the same as a
transfer to a compliant MTA; that is, a "transferred" tracking transfer to a compliant MTA; that is, a "transferred" tracking
status will be issued. status will be issued.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
4.1. Forgery 4.1. Forgery
Malicious servers may attempt to subvert message tracking Malicious servers may attempt to subvert message tracking
and return false information. This could result in misdirection and return false information. This could result in misdirection
or misinterpretation of results. or misinterpretation of results.
4.2. Confidentiality 4.2. Confidentiality
Another dimension of security is confidentiality. There Another dimension of security is confidentiality. There
may be cases in which a message recipient is autoforwarding mes- may be cases in which a message recipient is autoforwarding
sages but does not wish to divulge the address to which the mes- messages but does not wish to divulge the address to which the
sages are autoforwarded. The desire for such confidentiality messages are autoforwarded. The desire for such confidentiality
will probably be heightened as "wireless mailboxes", such as will probably be heightened as "wireless mailboxes", such as
pagers, become more widely used as autoforward addresses. pagers, become more widely used as autoforward addresses.
MTA authors are encouraged to provide a mechanism which MTA authors are encouraged to provide a mechanism which
enables the end user to preserve the confidentiality of a for- enables the end user to preserve the confidentiality of a
warding address. Depending on the degree of confidentiality forwarding address. Depending on the degree of confidentiality
required, and the nature of the environment to which a message required, and the nature of the environment to which a message
were being forwarded, this might be accomplished by one or more were being forwarded, this might be accomplished by one or more
of: of:
(a) respond with a "relayed" tracking status when a message is (a) respond with a "relayed" tracking status when a message is
forwarded to a confidential forwarding address, and dis- forwarded to a confidential forwarding address, and
abling further message tracking requests. disabling further message tracking requests.
(b) declaring the message to be delivered, issuing a "deliv- (b) declaring the message to be delivered, issuing a
ered" tracking status, re-sending the message to the confi- "delivered" tracking status, re-sending the message to the
dential forwarding address, and disabling further message confidential forwarding address, and disabling further
tracking requests. message tracking requests.
The tracking algorithms MUST NOT allow tracking through The tracking algorithms MUST NOT allow tracking through
list expansions. When a message is delivered to a list, a list expansions. When a message is delivered to a list, a
tracking request MUST respond with an "expanded" tracking status tracking request MUST respond with an "expanded" tracking status
and MUST NOT display the contents of the list. and MUST NOT display the contents of the list.
5. References 5. Acknowledgements
Several individuals have commented on and enhanced this draft,
including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon
Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.
6. References
[DRAFT-MTRK-MODEL] [DRAFT-MTRK-MODEL]
T. Hansen, ``Message Tracking Model and Requirements.'' T. Hansen, ``Message Tracking Model and Requirements.''
draft-ietf-msgtrk-model-03.txt. November 2000. draft-ietf-msgtrk-model-03.txt. November 2000.
[DRAFT-MTRK-MTQP] [DRAFT-MTRK-MTQP]
T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf- T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf-
msgtrk-mtqp-01.txt. November 2000. msgtrk-mtqp-01.txt. November 2000.
[DRAFT-MTRK-SMTPEXT] [DRAFT-MTRK-SMTPEXT]
E. Allman, ``SMTP Service Extension for Message Tracking.'' E. Allman, ``SMTP Service Extension for Message Tracking.''
draft-ietf-msgtrk-smtpext-00.txt. December 2000. draft-ietf-msgtrk-smtpext-00.txt. December 2000.
[RFC-ABNF] [RFC-ABNF]
Crocker, D., Editor, and P. Overell, ``Augmented BNF for Syn- Crocker, D., Editor, and P. Overell, ``Augmented BNF for
tax Specifications: ABNF'', RFC 2234, November 1997. Syntax Specifications: ABNF'', RFC 2234, November 1997.
[RFC-DSN-REPT] [RFC-DSN-REPT]
G. Vaudreuil, ``The Multipart/Report Content Type for the G. Vaudreuil, ``The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages.'' RFC 1892. Reporting of Mail System Administrative Messages.'' RFC 1892.
January 1996. January 1996.
[RFC-DSN-SMTP] [RFC-DSN-SMTP]
K. Moore, ``SMTP Service Extension for Delivery Status Notifi- K. Moore, ``SMTP Service Extension for Delivery Status
cations.'' RFC 1891. January 1996. Notifications.'' RFC 1891. January 1996.
[RFC-DSN-STAT] [RFC-DSN-STAT]
K. Moore and G. Vaudreuil, ``An Extensible Message Format for K. Moore and G. Vaudreuil, ``An Extensible Message Format for
Delivery Status Notifications.'' RFC 1894. January 1996. Delivery Status Notifications.'' RFC 1894. January 1996.
[RFC-EMSSC] [RFC-EMSSC]
G. Vaudreuil, ``Enhanced Mail System Status Codes.'' RFC G. Vaudreuil, ``Enhanced Mail System Status Codes.'' RFC
1893. January 1996. 1893. January 1996.
[RFC-ESMTP] [RFC-ESMTP]
Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.
Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. Novem- Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869.
ber 1995. November 1995.
[RFC-HOSTREQ] [RFC-HOSTREQ]
R. Braden (ed.), ``Requirements for Internet Hosts -- Applica- R. Braden (ed.), ``Requirements for Internet Hosts --
tion and Support.'' STD 3, RFC 1123. October 1989. Application and Support.'' STD 3, RFC 1123. October 1989.
[RFC-KEYWORDS] [RFC-KEYWORDS]
S. Bradner, ``Key words for use in RFCs to Indicate Require- S. Bradner, ``Key words for use in RFCs to Indicate
ment Levels.'' RFC 2119. March 1997. Requirement Levels.'' RFC 2119. March 1997.
[RFC-LMTP] [RFC-LMTP]
J. Myers, ``Local Mail Transfer Protocol.'' RFC 2033. Octo- J. Myers, ``Local Mail Transfer Protocol.'' RFC 2033.
ber 1996. October 1996.
[RFC-MDN] [RFC-MDN]
R. Fajman, ``An Extensible Message Format for Message Disposi- R. Fajman, ``An Extensible Message Format for Message
tion Notifications.'' RFC 2298. March 1998. Disposition Notifications.'' RFC 2298. March 1998.
[RFC-MIME] [RFC-MIME]
N. Freed and N. Borenstein, ``Multipurpose Internet Mail N. Freed and N. Borenstein, ``Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bod- Extensions (MIME) Part One: Format of Internet Message
ies.'' RFC 2045. November 1996. Bodies.'' RFC 2045. November 1996.
[RFC-MSGFMT] [RFC-MSGFMT]
D. Crocker, ``Standard for the Format of ARPA Internet Text P. Resnick, editor, ``Internet Message Format.'' RFC 2822.
Messages.'' RFC 822. August 1982. April 2001.
[RFC-RELATED] [RFC-RELATED]
E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC
2387. August 1998. 2387. August 1998.
6. Author's Address 7. Author's Address
Eric Allman Eric Allman
Sendmail, Inc. Sendmail, Inc.
6603 Shellmound 6425 Christie Ave, 4th Floor
Emeryville, CA 94608 Emeryville, CA 94608
U.S.A. U.S.A.
E-Mail: eric@Sendmail.COM E-Mail: eric@Sendmail.COM
Phone: +1 510 594 5501 Phone: +1 510 594 5501
Fax: +1 510 594 5411 Fax: +1 510 594 5429
 End of changes. 41 change blocks. 
104 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/