draft-ietf-msgtrk-trkstat-01.txt   draft-ietf-msgtrk-trkstat-02.txt 
Internet Draft E. Allman Internet Draft E. Allman
draft-ietf-msgtrk-trkstat-01.txt Sendmail, Inc. draft-ietf-msgtrk-trkstat-02.txt Sendmail, Inc.
Valid for six months March 20, 2001 Valid for six months July 6, 2001
Updates: RFC 1893 Updates: RFC 1893
The Message/Tracking-Status MIME Extension The Message/Tracking-Status MIME Extension
<draft-ietf-msgtrk-trkstat-01.txt> <draft-ietf-msgtrk-trkstat-02.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 dis-
tribute working documents as Internet-Drafts. tribute 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
skipping to change at page 2, line ? skipping to change at page 2, line ?
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
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission by the MSGTRK Working Group of the This document is a submission by the MSGTRK Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the msgtrk@imc.org mailing list. An archive of the mailing list to the ietf-msgtrk@imc.org mailing list. An archive of the mailing
may be found at list may be found at
http://www.ietf.org/archive/msgtrk 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 sta-
tus of undelivered e-mail upon request. Tracking is used in con- tus of undelivered e-mail upon request. Tracking is used in con-
junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes- junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
sage Disposition Notifications [RFC-MDN]; generally, a message sage 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
skipping to change at page 2, line ? skipping to change at page 2, line ?
is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. 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" mecha-
nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-
SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would
provide the primary delivery status. Only if no response from provide the primary delivery status. Only if no response is
either of these mechanisms would Message Tracking be used. received from either of these mechanisms would Message Tracking be
used.
This document is based on [RFC-DSN-STAT]. Sections 1.3 (Ter- This document is based on [RFC-DSN-STAT]. Sections 1.3 (Ter-
minology), 2.1.1 (General conventions for DSN fields), 2.1.2 minology), 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 refer-
ence. Other sections are further incorporated as described herein. ence. 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
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 of "tracking-status"; each subpart MUST be type "mes- with type parameter of "message/tracking-status"; each subpart MUST
sage/tracking-status" as described herein. be type "message/tracking-status" as described herein.
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 fol-
lows: lows:
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" for-
matted to according to the ABNF of RFC 822 headers "fields" (see matted to according to the ABNF of RFC 822 header "fields" (see
[RFC-MSGFMT]). The per-message fields appear first, followed by [RFC-MSGFMT]). The per-message fields appear first, followed by
a blank line. Following the per-message fields are one or more a blank line. Following the per-message fields are one or more
groups of per-recipient fields. Each group of per-recipient groups of per-recipient fields. Each group of per-recipient
fields is preceded by a blank line. Formally, the syntax of the fields is preceded by a blank line. Note that there will be a
message/tracking-status content is as follows: blank line between the final per-recipient field and the MIME
boundary, since one CRLF is necessary to terminate the field,
and a second is necessary to introduce the MIME boundary. For-
mally, the syntax of the message/tracking-status content is 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
skipping to change at page 5, line 37 skipping to change at page 5, line 47
"downstream" tracking requests. "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.
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 avail-
able or forthcoming. able or forthcoming.
There may be some confusion between when to use
"expanded" versus "delivered". Whenever possible, "expanded"
should be used when the MTA knows that the message will be
sent to multiple addresses. However, in some cases the
delivery occurs to a program which, unknown to the MTA,
causes mailing list expansion; in the extreme case, the
delivery may be to a real mailbox that has the side effect of
list expansion. If the MTA cannot ensure that this delivery
will cause list expansion, it should set the action to
"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 mes-
sage has been relayed to a system that does not speak sage has been relayed to a system that does not speak
skipping to change at page 6, line 31 skipping to change at page 6, line 55
Will-Retry-Until field MUST NOT be included; otherwise, this Will-Retry-Until field MUST NOT be included; otherwise, this
field is REQUIRED. field is REQUIRED.
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 sec-
tion 2.4 of [RFC-DSN-STAT]. tion 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 an LDA that under- A message that has been delivered to a Local Delivery Agent
stands message tracking (in particular, an LDA speaking LMTP (LDA) that understands message tracking (in particular, an LDA
[RFC-LMTP] that supports the MTRK extension) SHOULD pass the speaking LMTP [RFC-LMTP] that supports the MTRK extension)
tracking request to the LDA. In this case, the Action field for SHOULD pass the tracking request to the LDA. In this case, the
the MTA->LDA exchange will look the same as a transfer to a com- Action field for the MTA->LDA exchange will look the same as a
pliant MTA; that is, a "transferred" tracking status will be transfer to a compliant MTA; that is, a "transferred" tracking
issued. status will be issued.
4. Security Issues 4. Security Issues
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
skipping to change at page 7, line 59 skipping to change at page 8, line 28
[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. Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. Novem-
ber 1995.
November 1995.
[RFC-HOSTREQ] [RFC-HOSTREQ]
R. Braden (ed.), ``Requirements for Internet Hosts -- Applica- R. Braden (ed.), ``Requirements for Internet Hosts -- Applica-
tion and Support.'' STD 3, RFC 1123. October 1989. tion 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 Require-
ment Levels.'' RFC 2119. March 1997. ment Levels.'' RFC 2119. March 1997.
[RFC-LMTP] [RFC-LMTP]
 End of changes. 11 change blocks. 
23 lines changed or deleted 38 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/