updated msgtrk drafts
Eric Allman <[email protected]> Fri, 28 Mar 2003 14:12:56 -0800
| Newsgroups | gmane.ietf.msgtrk |
|---|---|
| Message-ID | <2147483647.1048860776@[10.210.202.39]> |
--==========2147514699==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Enclosed are updates of two of the msgtrk drafts,
draft-ietf-msgtrk-{trkstat,smtpext}-05.txt, for publication. They
incorporate IESG comments on the previous version.
Thanks
eric
--==========2147514699==========
Content-Type: text/plain; charset=iso-8859-1;
name="draft-ietf-msgtrk-trkstat-05.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-msgtrk-trkstat-05.txt";
size=23648
=0A=0A=0A=0AInternet Draft =
E. Allman=0Adraft-ietf-msgtrk-trkstat-05.txt =
Sendmail, Inc.=0AValid for six months =
March 19, 2003=0AUpdates: RFC 1893=0A=0A=0A=0A=0A An =
Extensible Message Format for Message Tracking Responses=0A=0A =
<draft-ietf-msgtrk-trkstat-05.txt>=0A=0AStatus of This =
Memo=0A=0A This document is an Internet-Draft and is in full =
conformance=0Awith all provisions of Section 10 of RFC2026. =
Internet-Drafts are=0Aworking documents of the Internet Engineering =
Task Force (IETF), its=0Aareas, and its working groups. Note that =
other groups may also=0Adistribute working documents as =
Internet-Drafts.=0A=0A Internet-Drafts are draft documents valid =
for a maximum of six=0Amonths and may be updated, replaced, or =
obsoleted by other documents=0Aat any time. It is inappropriate to =
use Internet-Drafts as reference=0Amaterial or to cite them other =
than as "work in progress."=0A=0A The IETF takes no position =
regarding the validity or scope of any=0Aintellectual property or =
other rights that might be claimed to=0Apertain to the implementation =
or use of the technology described in=0Athis document or the extent =
to which any license under such rights=0Amight or might not be =
available; neither does it represent that it has=0Amade any effort to =
identify any such rights. Information on the=0AIETF's procedures =
with respect to rights in standards-track and=0Astandards-related =
documentation can be found in BCP-11. Copies of=0Aclaims of rights =
made available for publication and any assurances of=0Alicenses to be =
made available, or the result of an attempt made to=0Aobtain a =
general license or permission for the use of such =
proprietary=0Arights by implementors or users of this specification =
can be obtained=0Afrom the IETF Secretariat.=0A=0A The IETF =
invites any interested party to bring to its attention=0Aany =
copyrights, patents or patent applications, or other =
proprietary=0Arights which may cover technology that may be required =
to practice=0Athis standard. Please address the information to the =
IETF Executive=0ADirector.=0A=0A The list of current =
Internet-Drafts can be accessed at:=0A=0A =
http://www.ietf.org/ietf/1id-abstracts.txt=0A=0AThe list of =
Internet-Draft Shadow Directories can be accessed at:=0A=0A =
http://www.ietf.org/shadow.html=0A=0A=0A This document is a =
submission by the MSGTRK Working Group of the=0AInternet Engineering =
Task Force (IETF). Comments should be =
submitted=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0Ato the [email protected] mailing list. =
An archive of the mailing=0Alist may be found at=0A=0A =
http://www.imc.org/ietf-msgtrk/index.html=0A=0A=0A Distribution =
of this memo is unlimited.=0A=0A1=081.=08. =
A=08Ab=08bs=08st=08tr=08ra=08ac=08ct=08t=0A=0A Message =
Tracking is expected to be used to determine the=0A status of =
undelivered e-mail upon request. Tracking is used in=0A =
conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and=0A =
Message Disposition Notifications [RFC-MDN]; generally, a message=0A =
tracking request will be issued only when a DSN or MDN has not =
been=0A received within a reasonable timeout period.=0A=0A =
This memo defines a MIME [RFC-MIME] content-type for message=0A =
tracking status in the same spirit as RFC 1894, ``An Extensible=0A =
Message Format for Delivery Status Notifications'' [RFC-DSN-STAT].=0A =
It is to be issued upon a request as described in ``Message=0A =
Tracking Query Protocol'' [DRAFT-MTRK-MTQP]. This memo defines=0A =
only the format of the status information. An extension to SMTP=0A =
[RFC-ESMTP] to label messages for further tracking and request=0A =
tracking status is defined in a separate memo =
[DRAFT-MTRK-SMTPEXT].=0A=0A2=082.=08. O=08Ot=08th=08he=08er=08r =
D=08Do=08oc=08cu=08um=08me=08en=08nt=08ts=08s a=08an=08nd=08d =
C=08Co=08on=08nf=08fo=08or=08rm=08ma=08an=08nc=08ce=08e=0A=0A =
The model used for Message Tracking is described in [DRAFT-=0A =
MTRK-MODEL].=0A=0A Message tracking is intended for use as a =
"last resort"=0A mechanism. Normally, Delivery Status =
Notifications (DSNs) [RFC-=0A DSN-SMTP] and Message Disposition =
Notifications (MDNs) [RFC-MDN]=0A would provide the primary =
delivery status. Only if no response is=0A received from either of =
these mechanisms would Message Tracking be=0A used.=0A=0A =
This document is based on [RFC-DSN-STAT]. Sections 1.3=0A =
(Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2=0A =
("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC=0A =
822) of [RFC-DSN-STAT] are included into this document by=0A =
reference. Other sections are further incorporated as described=0A =
herein.=0A=0A Syntax notation in this document conforms to =
[RFC-ABNF].=0A=0A The following lexical tokens, defined in =
[RFC-MSGFMT], are=0A used in the ABNF grammar for MTSNs: atom, =
CHAR, comment, CR, CRLF,=0A DIGIT, LF, linear-white-space, SPACE, =
text. The date-time lexical=0A token is defined in =
[RFC-HOSTREQ].=0A=0A The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL=0A NOT", "SHOULD", "SHOULD NOT", =
"RECOMMENDED", "MAY", and "OPTIONAL"=0A in this document are to be =
interpreted as described in RFC 2119=0A =
[RFC-KEYWORDS].=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
2=082]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A3=083.=08. =
F=08Fo=08or=08rm=08ma=08at=08t o=08of=08f a=08a =
M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g =
S=08St=08ta=08at=08tu=08us=08s =
N=08No=08ot=08ti=08if=08fi=08ic=08ca=08at=08ti=08io=08on=08n=0A=0A =
A Message Tracking Status Notification (MTSN) is intended to=0A =
be returned as the body of a Message Tracking request [DRAFT-MTRK-=0A =
MTQP]. The actual body MUST be a multipart/related =
[RFC-RELATED]=0A with type parameter of "message/tracking-status"; =
each subpart MUST=0A be of type "message/tracking-status" as =
described herein. The=0A multipart/related body can include =
multiple message/tracking-status=0A parts if an MTQP server chains =
requests to the next server; see=0A [DRAFT-MTRK-MODEL] and =
[DRAFT-MTRK-MTQP] for more information about=0A chaining.=0A=0A =
3=083.=08.1=081.=08. T=08Th=08he=08e =
m=08me=08es=08ss=08sa=08ag=08ge=08e/=08/t=08tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-s=08st=08ta=08at=08tu=08us=08s =
c=08co=08on=08nt=08te=08en=08nt=08t-=08-t=08ty=08yp=08pe=08e=0A=0A =
The message/tracking-status content-type is defined as=0A =
follows:=0A=0A MIME type name: message=0A =
MIME subtype name: tracking-status=0A Optional =
parameters: none=0A Encoding considerations: "7bit" =
encoding is sufficient and=0A MUST =
be used to maintain readability=0A =
when viewed by non-MIME mail readers.=0A Security =
considerations: discussed in section 4 of this memo.=0A=0A=0A =
The body of a message/tracking-status is modeled after=0A =
[RFC-DSN-STAT]. That body consists of one or more "fields"=0A =
formatted to according to the ABNF of RFC 2822 header "fields"=0A =
(see [RFC-MSGFMT]). The per-message fields appear first,=0A =
followed by a blank line. Following the per-message fields are=0A =
one or more groups of per-recipient fields. Each group of per-=0A =
recipient fields is preceded by a blank line. Note that there=0A =
will be a blank line between the final per-recipient field =
and=0A the MIME boundary, since one CRLF is necessary to =
terminate the=0A field, and a second is necessary to introduce =
the MIME boundary.=0A Formally, the syntax of the =
message/tracking-status content is=0A as follows:=0A=0A =
tracking-status-content =3D=0A per-message-fields =
1*( CRLF per-recipient-fields )=0A=0A The per-message fields are =
described in section 3.2. The per-=0A recipient fields are =
described in section 3.3.=0A=0A 3=083.=08.1=081.=08.1=081.=08. =
G=08Ge=08en=08ne=08er=08ra=08al=08l =
c=08co=08on=08nv=08ve=08en=08nt=08ti=08io=08on=08ns=08s =
f=08fo=08or=08r M=08MT=08TS=08SN=08N =
f=08fi=08ie=08el=08ld=08ds=08s=0A=0A Section 2.1.1 =
(General conventions for DSN fields) of=0A [RFC-DSN-STAT] is =
included herein by reference. Notably, the=0A definition of =
xtext is identical to that of that document.=0A=0A =
3=083.=08.1=081.=08.2=082.=08. *=08*-=08-t=08ty=08yp=08pe=08e =
s=08su=08ub=08bf=08fi=08ie=08el=08ld=08ds=08s=0A=0A =
Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is=0A =
included herein by reference. Notably, the definitions of=0A =
address-type, diagnostic-type, and MTA-name type =
are=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
3=083]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A identical to that of RFC =
1894.=0A=0A=0A 3=083.=08.2=082.=08. =
P=08Pe=08er=08r-=08-M=08Me=08es=08ss=08sa=08ag=08ge=08e =
M=08MT=08TS=08SN=08N F=08Fi=08ie=08el=08ld=08ds=08s=0A=0A =
Some fields of an MTSN apply to all of the addresses in a=0A =
single envelope. These fields may appear at most once in any=0A =
MTSN. These fields are used to correlate the MTSN with the=0A =
original message transaction and to provide additional=0A =
information which may be useful to gateways.=0A=0A =
per-message-fields =3D=0A =
original-envelope-id-field CRLF=0A =
reporting-mta-field CRLF=0A arrival-date-field =
CRLF=0A *( extension-field CRLF )=0A=0A=0A =
3=083.=08.2=082.=08.1=081.=08. T=08Th=08he=08e =
O=08Or=08ri=08ig=08gi=08in=08na=08al=08l-=08-E=08En=08nv=08ve=08el=08l=
o=08op=08pe=08e-=08-I=08Id=08d f=08fi=08ie=08el=08ld=08d=0A=0A =
The Original-Envelope-Id field is defined as in section=0A =
2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED.=0A=0A =
3=083.=08.2=082.=08.2=082.=08. T=08Th=08he=08e =
R=08Re=08ep=08po=08or=08rt=08ti=08in=08ng=08g-=08-M=08MT=08TA=08A =
f=08fi=08ie=08el=08ld=08d=0A=0A The Reporting-MTA field =
is defined as in section 2.2.2=0A of [RFC-DSN-STAT]. This =
field is REQUIRED.=0A=0A 3=083.=08.2=082.=08.3=083.=08. =
T=08Th=08he=08e =
A=08Ar=08rr=08ri=08iv=08va=08al=08l-=08-D=08Da=08at=08te=08e =
f=08fi=08ie=08el=08ld=08d=0A=0A The Arrival-Date field =
is defined as in section 2.2.5 of=0A [RFC-DSN-STAT]. This =
field is REQUIRED.=0A=0A=0A 3=083.=08.3=083.=08. =
P=08Pe=08er=08r-=08-R=08Re=08ec=08ci=08ip=08pi=08ie=08en=08nt=08t =
M=08MT=08TS=08SN=08N f=08fi=08ie=08el=08ld=08ds=08s=0A=0A =
An MTSN contains information about attempts to deliver a=0A =
message to one or more recipients. The delivery information for=0A =
any particular recipient is contained in a group of contiguous=0A =
per-recipient fields. Each group of per-recipient fields is=0A =
preceded by a blank line.=0A=0A The syntax for the group =
of per-recipient fields is as=0A follows:=0A=0A =
per-recipient-fields =3D=0A =
original-recipient-field CRLF=0A =
final-recipient-field CRLF=0A action-field CRLF=0A =
status-field CRLF=0A [ =
remote-mta-field CRLF ]=0A [ =
last-attempt-date-field CRLF ]=0A [ =
will-retry-until-field CRLF ]=0A *( =
extension-field CRLF )=0A=0A=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
=
[=08[P=08Pa=08ag=08ge=08e =
4=084]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A 3=083.=08.3=083.=08.1=081.=08. =
O=08Or=08ri=08ig=08gi=08in=08na=08al=08l-=08-R=08Re=08ec=08ci=08ip=08p=
i=08ie=08en=08nt=08t f=08fi=08ie=08el=08ld=08d=0A=0A The =
Original-Recipient field is defined as in section=0A 2.3.1 of =
[RFC-DSN-STAT]. This field is REQUIRED.=0A=0A =
3=083.=08.3=083.=08.2=082.=08. =
F=08Fi=08in=08na=08al=08l-=08-R=08Re=08ec=08ci=08ip=08pi=08ie=08en=08n=
t=08t f=08fi=08ie=08el=08ld=08d=0A=0A The required =
Final-Recipient field is defined as in=0A section 2.3.2 of =
[RFC-DSN-STAT]. This field is REQUIRED.=0A=0A =
3=083.=08.3=083.=08.3=083.=08. A=08Ac=08ct=08ti=08io=08on=08n =
f=08fi=08ie=08el=08ld=08d=0A=0A The required Action =
field indicates the action performed=0A by the Reporting-MTA =
as a result of its attempt to deliver=0A the message to this =
recipient address. This field MUST be=0A present for each =
recipient named in the MTSN. The syntax is=0A as defined in =
section 2.3.3 of RFC 1894. This field is=0A REQUIRED.=0A=0A =
Valid actions are:=0A=0A failed The message =
could not be delivered. If DSNs=0A have been =
enabled, a "failed" DSN should already=0A have =
been returned.=0A=0A delayed The message is currently =
waiting in the MTA=0A queue for future delivery. =
Essentially, this=0A action means "the message =
is located, and it is=0A here."=0A=0A =
delivered The message has been successfully delivered to=0A =
the final recipient. This includes "delivery"=0A =
to a mailing list exploder. It does not=0A =
indicate that the message has been read. No=0A =
further information is available; in particular,=0A =
the tracking agent SHOULD NOT attempt further=0A =
"downstream" tracking requests.=0A=0A expanded =
The message has been successfully delivered to=0A =
the recipient address as specified by the=0A =
sender, and forwarded by the Reporting-MTA=0A =
beyond that destination to multiple additional=0A =
recipient addresses. However, these additional=0A =
addresses are not trackable, and the tracking=0A =
agent SHOULD NOT attempt further "downstream"=0A =
tracking requests.=0A=0A relayed The message has been =
delivered into an=0A environment that does not =
support message=0A tracking. No further =
information is available;=0A in particular, the =
tracking agent SHOULD NOT=0A attempt further =
"downstream" tracking requests.=0A=0A transferred The =
message has been transferred to another=0A =
MTRK-compliant MTA. The tracking agent SHOULD=0A =
attempt further "downstream" tracking =
requests=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
5=085]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A unless that =
information is already given in a=0A chaining =
response.=0A=0A opaque The message may or may not have =
been seen by=0A this system. No further =
information is=0A available or =
forthcoming.=0A=0A There may be some confusion between =
when to use=0A "expanded" versus "delivered". Whenever =
possible, "expanded"=0A should be used when the MTA knows =
that the message will be=0A sent to multiple addresses. =
However, in some cases the=0A delivery occurs to a program =
which, unknown to the MTA,=0A causes mailing list expansion; =
in the extreme case, the=0A delivery may be to a real mailbox =
that has the side effect of=0A list expansion. If the MTA =
cannot ensure that this delivery=0A will cause list =
expansion, it should set the action to=0A "delivered".=0A=0A =
3=083.=08.3=083.=08.4=084.=08. S=08St=08ta=08at=08tu=08us=08s =
f=08fi=08ie=08el=08ld=08d=0A=0A The Status field is =
defined as in RFC 1894 section=0A 2.3.4. A new code is added =
to RFC 1893 [RFC-EMSSC],=0A "Enhanced Mail System Status =
Codes",=0A=0A X.1.9 Message relayed to non-compliant =
mailer"=0A=0A The mailbox address specified was =
valid, but the=0A message has been relayed to a =
system that does not=0A speak this protocol; no =
further information can be=0A provided.=0A A =
2.1.9 Status field MUST be used exclusively with a=0A =
"relayed" Action field. This field is REQUIRED.=0A=0A =
3=083.=08.3=083.=08.5=085.=08. =
R=08Re=08em=08mo=08ot=08te=08e-=08-M=08MT=08TA=08A =
f=08fi=08ie=08el=08ld=08d=0A=0A The Remote-MTA field is =
defined as in section Reference=0A 2.3.5 of [RFC-DSN-STAT]. =
This field MUST NOT be included if=0A no delivery attempts =
have been made or if the Action field=0A has value "opaque". =
If delivery to some agent other than an=0A MTA (for example, =
a Local Delivery Agent) then this field MAY=0A be included, =
giving the name of the host on which that agent=0A was =
contacted.=0A=0A 3=083.=08.3=083.=08.6=086.=08. =
L=08La=08as=08st=08t-=08-A=08At=08tt=08te=08em=08mp=08pt=08t-=08-D=08D=
a=08at=08te=08e f=08fi=08ie=08el=08ld=08d=0A=0A The =
Last-Attempt-Date field is defined as in section=0A Reference =
2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if=0A any =
delivery attempt has been made and the Action field does=0A =
not have value "opaque", in which case it will specify when=0A =
it last attempted to deliver this message to another MTA or=0A =
other Delivery Agent. This field MUST NOT be included if no=0A =
delivery attempts have been =
made.=0A=0A=0A=0A=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
6=086]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A 3=083.=08.3=083.=08.7=087.=08. =
W=08Wi=08il=08ll=08l-=08-R=08Re=08et=08tr=08ry=08y-=08-U=08Un=08nt=08t=
i=08il=08l f=08fi=08ie=08el=08ld=08d=0A=0A The =
Will-Retry-Until field is defined as in section=0A Reference =
2.3.8 of [RFC-DSN-STAT]. If the message is not in=0A the =
local queue or the Action field has the value ``opaque''=0A =
the Will-Retry-Until field MUST NOT be included; otherwise,=0A =
this field SHOULD be included.=0A=0A 3=083.=08.4=084.=08. =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
f=08fi=08ie=08el=08ld=08ds=08s=0A=0A Future extension =
fields may be defined as defined in=0A section 2.4 of =
[RFC-DSN-STAT].=0A=0A 3=083.=08.5=085.=08. =
I=08In=08nt=08te=08er=08ra=08ac=08ct=08ti=08io=08on=08n =
B=08Be=08et=08tw=08we=08ee=08en=08n M=08MT=08TA=08As=08s =
a=08an=08nd=08d L=08LD=08DA=08As=08s=0A=0A A message that =
has been delivered to a Local Delivery Agent=0A (LDA) that =
understands message tracking (in particular, an LDA=0A speaking =
LMTP [RFC-LMTP] that supports the MTRK extension)=0A SHOULD pass =
the tracking request to the LDA. In this case, the=0A Action =
field for the MTA->LDA exchange will look the same as a=0A =
transfer to a compliant MTA; that is, a "transferred" tracking=0A =
status will be issued.=0A=0A=0A4=084.=08. =
S=08Se=08ec=08cu=08ur=08ri=08it=08ty=08y =
C=08Co=08on=08ns=08si=08id=08de=08er=08ra=08at=08ti=08io=08on=08ns=08s=
=0A=0A 4=084.=08.1=081.=08. =
F=08Fo=08or=08rg=08ge=08er=08ry=08y=0A=0A Malicious servers =
may attempt to subvert message tracking=0A and return false =
information. This could result in misdirection=0A or =
misinterpretation of results.=0A=0A 4=084.=08.2=082.=08. =
C=08Co=08on=08nf=08fi=08id=08de=08en=08nt=08ti=08ia=08al=08li=08it=08t=
y=08y=0A=0A Another dimension of security is =
confidentiality. There=0A may be cases in which a message =
recipient is autoforwarding=0A messages but does not wish to =
divulge the address to which the=0A messages are autoforwarded. =
The desire for such confidentiality=0A will probably be =
heightened as "wireless mailboxes", such as=0A pagers, become =
more widely used as autoforward addresses.=0A=0A MTA =
authors are encouraged to provide a mechanism which=0A enables =
the end user to preserve the confidentiality of a=0A forwarding =
address. Depending on the degree of confidentiality=0A =
required, and the nature of the environment to which a message=0A =
were being forwarded, this might be accomplished by one or more=0A =
of:=0A=0A (a) respond with a "relayed" tracking status when =
a message is=0A forwarded to a confidential forwarding =
address, and=0A disabling further message tracking =
requests.=0A=0A (b) declaring the message to be delivered, =
issuing a=0A "delivered" tracking status, re-sending the =
message to the=0A confidential forwarding address, and =
disabling further=0A message tracking =
requests.=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
7=087]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A The tracking algorithms MUST =
NOT allow tracking through=0A list expansions. When a message =
is delivered to a list, a=0A tracking request MUST respond with =
an "expanded" tracking status=0A and MUST NOT display the =
contents of the list.=0A=0A=0A5=085.=08. I=08IA=08AN=08NA=08A =
C=08Co=08on=08ns=08si=08id=08de=08er=08ra=08at=08ti=08io=08on=08ns=08s=
=0A=0A IANA is to register the SMTP extension defined in =
section 3.=0A=0A=0A6=086.=08. =
A=08Ac=08ck=08kn=08no=08ow=08wl=08le=08ed=08dg=08ge=08em=08me=08en=08n=
t=08ts=08s=0A=0A Several individuals have commented on and =
enhanced this draft,=0A including Tony Hansen, Philip Hazel, Alexey =
Melnikov, Lyndon=0A Nerenberg, Chris Newman, Gregory Neil Shapiro, =
and Dan Wing.=0A=0A=0A7=087.=08. =
N=08No=08or=08rm=08ma=08at=08ti=08iv=08ve=08e =
R=08Re=08ef=08fe=08er=08re=08en=08nc=08ce=08es=08s=0A=0A =
[DRAFT-MTRK-MODEL]=0A T. Hansen, ``Message Tracking Model and =
Requirements.''=0A draft-ietf-msgtrk-model-03.txt. November =
2000.=0A=0A [DRAFT-MTRK-MTQP]=0A T. Hansen, ``Message =
Tracking Query Protocol.'' draft-ietf-=0A msgtrk-mtqp-01.txt. =
November 2000.=0A=0A [DRAFT-MTRK-SMTPEXT]=0A E. Allman, =
``SMTP Service Extension for Message Tracking.''=0A =
draft-ietf-msgtrk-smtpext-05.txt. March 2003.=0A=0A [RFC-ABNF]=0A =
Crocker, D., Editor, and P. Overell, ``Augmented BNF for=0A =
Syntax Specifications: ABNF'', RFC 2234, November 1997.=0A=0A =
[RFC-EMSSC]=0A G. Vaudreuil, ``Enhanced Mail System Status =
Codes.'' RFC=0A 1893. January 1996.=0A=0A [RFC-HOSTREQ]=0A =
R. Braden (ed.), ``Requirements for Internet Hosts --=0A =
Application and Support.'' STD 3, RFC 1123. October 1989.=0A=0A =
[RFC-KEYWORDS]=0A S. Bradner, ``Key words for use in RFCs to =
Indicate=0A Requirement Levels.'' RFC 2119. March =
1997.=0A=0A [RFC-MIME]=0A N. Freed and N. Borenstein, =
``Multipurpose Internet Mail=0A Extensions (MIME) Part One: =
Format of Internet Message=0A Bodies.'' RFC 2045. November =
1996.=0A=0A [RFC-MSGFMT]=0A P. Resnick, editor, ``Internet =
Message Format.'' RFC 2822.=0A April =
2001.=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e =
8=088]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e/=08/T=08Tr=08ra=08ac=08ck=08ki=08i=
n=08ng=08g-=08-S=08St=08ta=08at=08tu=08us=08s =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A [RFC-RELATED]=0A E. Levinson, =
``The MIME Multipart/Related Content-type.'' RFC=0A 2387. =
August 1998.=0A=0A=0A8=088.=08. =
I=08In=08nf=08fo=08or=08rm=08ma=08at=08ti=08io=08on=08na=08al=08l =
R=08Re=08ef=08fe=08er=08re=08en=08nc=08ce=08es=08s=0A=0A =
[RFC-DSN-SMTP]=0A K. Moore, ``SMTP Service Extension for =
Delivery Status=0A Notifications.'' RFC 1891. January =
1996.=0A=0A [RFC-DSN-STAT]=0A K. Moore and G. Vaudreuil, =
``An Extensible Message Format for=0A Delivery Status =
Notifications.'' RFC 1894. January 1996.=0A=0A [RFC-ESMTP]=0A =
Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.=0A =
Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869.=0A =
November 1995.=0A=0A [RFC-LMTP]=0A J. Myers, ``Local Mail =
Transfer Protocol.'' RFC 2033.=0A October 1996.=0A=0A =
[RFC-MDN]=0A R. Fajman, ``An Extensible Message Format for =
Message=0A Disposition Notifications.'' RFC 2298. March =
1998.=0A=0A=0A9=089.=08. A=08Au=08ut=08th=08ho=08or=08r'=08's=08s =
A=08Ad=08dd=08dr=08re=08es=08ss=08s=0A=0A Eric Allman=0A =
Sendmail, Inc.=0A 6425 Christie Ave, 4th Floor=0A =
Emeryville, CA 94608=0A U.S.A.=0A=0A E-Mail: =
[email protected]=0A Phone: +1 510 594 5501=0A Fax: +1 =
510 594 =
5429=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AA=08Al=08=
ll=08lm=08ma=08an=08n =
[=08[P=08Pa=08ag=08ge=08e 9=089]=08]=0A=0C
--==========2147514699==========
Content-Type: text/plain; charset=iso-8859-1;
name="draft-ietf-msgtrk-smtpext-05.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-msgtrk-smtpext-05.txt";
size=19075
=0A=0A=0A=0AInternet Draft =
E. Allman=0Adraft-ietf-msgtrk-smtpext-05.txt =
Sendmail, Inc.=0AValid for six months =
T. Hansen=0AUpdates: RFC 1891 =
AT&T Laboratories=0A =
March 19, 2003=0A=0A=0A=0A=0A SMTP =
Service Extension=0A for Message =
Tracking=0A=0A =
<draft-ietf-msgtrk-smtpext-05.txt>=0A=0AStatus of This Memo=0A=0A =
This document is an Internet-Draft and is in full conformance=0Awith =
all provisions of Section 10 of RFC2026. Internet-Drafts =
are=0Aworking documents of the Internet Engineering Task Force =
(IETF), its=0Aareas, and its working groups. Note that other groups =
may also=0Adistribute working documents as Internet-Drafts.=0A=0A =
Internet-Drafts are draft documents valid for a maximum of =
six=0Amonths and may be updated, replaced, or obsoleted by other =
documents=0Aat any time. It is inappropriate to use Internet-Drafts =
as reference=0Amaterial or to cite them other than as "work in =
progress."=0A=0A The IETF takes no position regarding the =
validity or scope of any=0Aintellectual property or other rights that =
might be claimed to=0Apertain to the implementation or use of the =
technology described in=0Athis document or the extent to which any =
license under such rights=0Amight or might not be available; neither =
does it represent that it has=0Amade any effort to identify any such =
rights. Information on the=0AIETF's procedures with respect to =
rights in standards-track and=0Astandards-related documentation can =
be found in BCP-11. Copies of=0Aclaims of rights made available for =
publication and any assurances of=0Alicenses to be made available, or =
the result of an attempt made to=0Aobtain a general license or =
permission for the use of such proprietary=0Arights by implementors =
or users of this specification can be obtained=0Afrom the IETF =
Secretariat.=0A=0A The IETF invites any interested party to bring =
to its attention=0Aany copyrights, patents or patent applications, or =
other proprietary=0Arights which may cover technology that may be =
required to practice=0Athis standard. Please address the information =
to the IETF Executive=0ADirector.=0A=0A The list of current =
Internet-Drafts can be accessed at:=0A=0A =
http://www.ietf.org/ietf/1id-abstracts.txt=0A=0AThe list of =
Internet-Draft Shadow Directories can be accessed at:=0A=0A =
http://www.ietf.org/shadow.html=0A=0C=0AI=08In=08nt=08te=08er=08rn=08n=
e=08et=08t D=08Dr=08ra=08af=08ft=08t =
M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A This document is a submission by =
the MSGTRK Working Group of the=0AInternet Engineering Task Force =
(IETF). Comments should be submitted=0Ato the [email protected] =
mailing list. An archive of the mailing=0Alist may be found at=0A=0A =
http://www.imc.org/ietf-msgtrk/index.html=0A=0A=0A =
Distribution of this memo is unlimited.=0A=0A=0A1=081.=08. =
A=08Ab=08bs=08st=08tr=08ra=08ac=08ct=08t=0A=0A This memo =
defines an extension to the SMTP service whereby a=0A client may =
mark a message for future tracking.=0A=0A=0A2=082.=08. =
O=08Ot=08th=08he=08er=08r =
D=08Do=08oc=08cu=08um=08me=08en=08nt=08ts=08s a=08an=08nd=08d =
C=08Co=08on=08nf=08fo=08or=08rm=08ma=08an=08nc=08ce=08e=0A=0A =
The model used for Message Tracking is described in [DRAFT-=0A =
MTRK-MODEL].=0A=0A Doing a Message Tracking query is intended =
as a "last resort"=0A mechanism. Normally, Delivery Status =
Notifications (DSNs) [RFC-=0A DSN-SMTP] and Message Disposition =
Notifications (MDNs) [RFC-MDN]=0A would provide the primary =
delivery status. Only if the message is=0A not received, or there =
is no response from either of these=0A mechanisms should a Message =
Tracking query be issued.=0A=0A The definition of the base64 =
token is imported from section=0A 6.8 of [RFC-MIME]. =
Formally,=0A=0A base64 =3D %2b / %2f / %x30-39 / %x41-5a / =
%x61-7a=0A=0A=0A The definition of the DIGIT token is imported =
from [RFC-=0A MSGFMT]. Formally,=0A=0A DIGIT =3D =
%x30-39=0A=0A=0A Syntax notation in this document conforms to =
[RFC-ABNF].=0A=0A The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL=0A NOT", "SHOULD", "SHOULD NOT", =
"RECOMMENDED", "MAY", and "OPTIONAL"=0A in this document are to be =
interpreted as described in RFC 2119=0A =
[RFC-KEYWORDS].=0A=0A=0A3=083.=08. S=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
O=08Ov=08ve=08er=08rv=08vi=08ie=08ew=08w=0A=0A The Message =
Tracking SMTP service extension uses the SMTP=0A service extension =
mechanism described in [RFC-ESMTP]. The=0A following service =
extension is hereby =
defined:=0A=0A=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
2=082]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A (1) The name of the SMTP service =
extension is "Message=0A Tracking".=0A=0A (2) The EHLO =
keyword value associated with this extension is=0A =
"MTRK".=0A=0A (3) No parameters are allowed with this EHLO =
keyword value.=0A Future documents may extend this =
specification by specifying=0A parameters to this keyword =
value.=0A=0A (4) One optional parameter using the keyword "MTRK" =
is added to=0A the MAIL command. In addition, the ENVID =
parameter of the=0A MAIL command (as defined in RFC 1891 =
sections 5.4) MUST be=0A supported, with extensions as =
described below. The ORCPT=0A parameter of the RCPT command =
(as defined in RFC 1891=0A section 5.2) MUST also be =
supported. All semantics=0A associated with ENVID and ORCPT =
described in RFC 1891 MUST=0A be supported as part of this =
extension.=0A=0A (5) The maximum length of a MAIL command line =
is increased by 40=0A characters by the possible addition of =
the MTRK keyword and=0A value. Note that the 507 character =
extension of RCPT=0A commands for the ORCPT parameter and =
the 107 character=0A extension of MAIL commands for the =
ENVID parameter as=0A mandated by RFC 1891 [RFC-DSN-SMTP] =
must also be included.=0A=0A (6) No SMTP verbs are defined by =
this extension.=0A=0A=0A4=084.=08. T=08Th=08he=08e =
E=08Ex=08xt=08te=08en=08nd=08de=08ed=08d M=08MA=08AI=08IL=08L =
C=08Co=08om=08mm=08ma=08an=08nd=08d=0A=0A The extended MAIL =
command is issued by an SMTP client when it=0A wishes to inform an =
SMTP server that message tracking information=0A should be retained =
for future querying. The extended MAIL command=0A is identical to =
the MAIL command as defined in [RFC-SMTP], except=0A that MTRK, =
ORCPT, and ENVID parameters appear after the address.=0A=0A =
4=084.=08.1=081.=08. T=08Th=08he=08e M=08MT=08TR=08RK=08K =
p=08pa=08ar=08ra=08am=08me=08et=08te=08er=08r t=08to=08o =
t=08th=08he=08e E=08ES=08SM=08MT=08TP=08P M=08MA=08AI=08IL=08L =
c=08co=08om=08mm=08ma=08an=08nd=08d=0A=0A Any sender =
wishing to request the retention of data for=0A further tracking =
of message must first tag that message as=0A trackable by =
creating two values A and B:=0A=0A A =3D =
some-large-random-number=0A B =3D SHA1(A)=0A=0A The =
large random number A is calculated on a host-dependent=0A =
basis. See [RFC-RANDOM] for a discussion of choosing good=0A =
random numbers. This random number MUST be at least 128 bits=0A =
but MUST NOT be more than 1024 bits.=0A=0A The 128-bit hash =
B of A is then computed using the SHA-1=0A algorithm as =
described in [NIST-SHA1].=0A=0A The sender then base64 =
encodes value B and passes that=0A value as the mtrk-certifier =
on the MAIL command:=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
3=083]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A mtrk-parameter =3D "MTRK=3D" =
mtrk-certifier [ ":" mtrk-timeout ]=0A mtrk-certifier =3D =
base64 ; authenticator=0A mtrk-timeout =3D =
1*9DIGIT ; seconds until timeout=0A=0A=0A A is stored =
in the originator's tracking database to=0A validate future =
tracking requests as described in [DRAFT-MTRK-=0A MTQP]. B is =
stored in tracking databases of compliant receiver=0A MTAs and =
used to authenticate future tracking requests.=0A=0A The =
mtrk-timeout field indicates the number of seconds that=0A the =
client requests that this tracking information be retained=0A on =
intermediate servers, as measured from the initial receipt of=0A =
the message at that server. Servers MAY ignore this value if it=0A =
violates local policy. In particular, servers MAY silently=0A =
enforce an upper limit to how long they will retain tracking=0A =
data; this limit MUST be at least one day.=0A=0A If no =
mtrk-timeout field is specified then the server=0A should use a =
local default. This default SHOULD be 8-10 days=0A and MUST be =
at least one day. Notwithstanding this clause, the=0A =
information MUST NOT be expired while the message remains in the=0A =
queue for this server: that is, an MTQP server MUST NOT deny=0A =
knowledge of a message while that same message sits in the MTA=0A =
queue.=0A=0A If the message is relayed to another =
compliant SMTP server,=0A the MTA acting as the client SHOULD =
pass an mtrk-timeout field=0A equal to the remaining life of =
that message tracking=0A information. Specifically, the =
tracking timeout is decremented=0A by the number of seconds the =
message has lingered at this MTA=0A and then passed to the next =
MTA. If the decremented tracking=0A timeout is less than or =
equal to zero, the entire MTRK parameter=0A MUST NOT be passed =
to the next MTA; essentially, the entire=0A tracking path is =
considered to be lost at that point.=0A=0A See =
[RFC-DELIVERYBY] section 4 for an explanation of why a=0A =
timeout is used instead of an absolute time.=0A=0A =
4=084.=08.2=082.=08. U=08Us=08se=08e o=08of=08f =
E=08EN=08NV=08VI=08ID=08D=0A=0A To function properly, =
Message Tracking requires that each=0A message have a unique =
identifier that is never reused by any=0A other message. For =
that purpose, if the MTRK parameter is=0A given, an ENVID =
parameter MUST be included, and the syntax of=0A ENVID from RFC =
1891 section 5.4 is extended as follows:=0A=0A =
envid-parameter =3D "ENVID=3D" unique-envid=0A unique-envid =
=3D local-envid "@" fqhn=0A local-envid =3D xtext=0A =
fqhn =3D xtext=0A=0A The unique-envid MUST be =
chosen in such a way that the same=0A ENVID will never be used =
by any other message sent from this=0A system or any other =
system. In most cases, this means setting=0A fqhn to be the =
fully qualified host name of the =
system=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
4=084]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A generating this ENVID, and =
local-envid to an identifier that is=0A never re-used by that =
host.=0A=0A In some cases, the total length of (local-envid =
+ fqhn + 1)=0A (for the `@' sign) may exceed the total =
acceptable length of=0A ENVID (100). In this case, the fqhn =
SHOULD be replaced by the=0A SHA1(fqhn) encoded into BASE64. =
After encoding, the 160 bit=0A SHA-1 will be a 27 octet string, =
which limits local-envid to 72=0A octets. Implementors are =
encouraged to use an algorithm for the=0A local-envid that is =
reasonably unique. For example, sequential=0A integers have a =
high probability of intersecting with sequential=0A integers =
generated by a different host, but a SHA-1 of the=0A current =
time of day concatenated with the host's IP address and=0A a =
random number are unlikely to intersect with the same=0A =
algorithm generated by a different host.=0A=0A Any =
resubmissions of this message into the message=0A transmission =
system MUST assign a new ENVID. In this context,=0A =
"resubmission" includes forwarding or resending a message from a=0A =
user agent, but does not include MTA-level aliasing or=0A =
forwarding where the message does not leave and re-enter the=0A =
message transmission system.=0A=0A 4=084.=08.3=083.=08. =
F=08Fo=08or=08rw=08wa=08ar=08rd=08di=08in=08ng=08g =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g =
C=08Ce=08er=08rt=08ti=08if=08fi=08ie=08er=08rs=08s=0A=0A =
MTAs SHOULD forward unexpired tracking certifiers to=0A =
compliant mailers as the mail is transferred during regular hop-=0A =
to-hop transfers. If the "downstream" MTA is not MTRK-=0A =
compliant, then the MTRK=3D parameter MUST be deleted. If the=0A =
downstream MTA is DSN-compliant, then the ENVID and ORCPT=0A =
parameters MUST NOT be deleted.=0A=0A If aliasing, =
forwarding, or other redirection of a=0A recipient occurs, and =
the result of the redirection is exactly=0A one recipient, then =
the MTA SHOULD treat this as an ordinary=0A hop-to-hop transfer =
and forward the MTRK=3D, ENVID=3D, and ORCPT=3D=0A values; these =
values MUST NOT be modified except for=0A decrementing the =
mtrk-timeout field of the MTRK=3D value, which=0A MUST be =
modified as described in section 4.1 above.=0A=0A MTAs MUST =
NOT copy MTRK certifiers when a recipient is=0A aliased, =
forwarded, or otherwise redirected and the redirection=0A =
results in more than one recipient. However, an MTA MAY=0A =
designate one of the multiple recipients as the "primary"=0A =
recipient to which tracking requests shall be forwarded; other=0A =
addresses MUST NOT receive tracking certifiers. MTAs MUST NOT=0A =
forward MTRK certifiers when doing mailing list =
expansion.=0A=0A=0A5=085.=08. =
S=08Se=08ec=08cu=08ur=08ri=08it=08ty=08y =
C=08Co=08on=08ns=08si=08id=08de=08er=08ra=08at=08ti=08io=08on=08ns=08s=
=0A=0A 5=085.=08.1=081.=08. D=08De=08en=08ni=08ia=08al=08l =
o=08of=08f s=08se=08er=08rv=08vi=08ic=08ce=08e=0A=0A An =
attacker could attempt to flood the database of a server=0A by =
submitting large numbers of small, tracked messages. In this=0A =
case, a site may elect to lower its maximum retention =
period=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
5=085]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A retroactively.=0A=0A =
5=085.=08.2=082.=08. =
C=08Co=08on=08nf=08fi=08id=08de=08en=08nt=08ti=08ia=08al=08li=08it=08t=
y=08y=0A=0A The mtrk-authenticator value (``A'') must be =
hard to=0A predict and not reused.=0A=0A The =
originating client must take reasonable precautions to=0A =
protect the secret. For example, if the secret is stored in a=0A =
message store (e.g., a "Sent" folder), the client must make sure=0A =
the secret isn't accessible by attackers, particularly on a=0A =
shared store.=0A=0A Many site administrators believe that =
concealing names and=0A topologies of internal systems and =
networks is an important=0A security feature. MTAs need to =
balance such desires with the=0A need to provide adequate =
tracking information.=0A=0A In some cases site =
administrators may want to treat=0A delivery to an alias as =
final delivery in order to separate=0A roles from individuals. =
For example, sites implementing=0A ``postmaster'' or =
``webmaster'' as aliases may not wish to=0A expose the identity =
of those individuals by permitting tracking=0A through those =
aliases. In other cases, providing the tracking=0A information =
for an alias is important, such as when the alias=0A points to =
the user's preferred public address.=0A=0A Therefore, =
implementors are encouraged to provide=0A mechanisms by which =
site administrators can choose between these=0A =
alternatives.=0A=0A=0A6=086.=08. I=08IA=08AN=08NA=08A =
C=08Co=08on=08ns=08si=08id=08de=08er=08ra=08at=08ti=08io=08on=08ns=08s=
=0A=0A IANA is to register the SMTP extension defined in =
section 3.=0A=0A=0A7=087.=08. =
A=08Ac=08ck=08kn=08no=08ow=08wl=08le=08ed=08dg=08ge=08em=08me=08en=08n=
t=08ts=08s=0A=0A Several individuals have commented on and =
enhanced this draft,=0A including Philip Hazel, Alexey Melnikov, =
Lyndon Nerenberg, Chris=0A Newman, and Gregory Neil =
Shapiro.=0A=0A=0A8=088.=08. =
N=08No=08or=08rm=08ma=08at=08ti=08iv=08ve=08e =
R=08Re=08ef=08fe=08er=08re=08en=08nc=08ce=08es=08s=0A=0A =
[DRAFT-MTRK-MODEL]=0A T. Hansen, ``Message Tracking Model and =
Requirements.''=0A draft-ietf-msgtrk-model-03.txt. November =
2000.=0A=0A [DRAFT-MTRK-MTQP]=0A T. Hansen, ``Message =
Tracking Query Protocol.'' draft-ietf-=0A msgtrk-mtqp-01.txt. =
November 2000.=0A=0A [RFC-ABNF]=0A Crocker, D., Editor, and =
P. Overell, ``Augmented BNF =
for=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
6=086]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A Syntax Specifications: ABNF'', =
RFC 2234, November 1997.=0A=0A [RFC-ESMTP]=0A Rose, M., =
Stefferud, E., Crocker, D., Klensin, J. and N.=0A Freed, =
``SMTP Service Extensions.'' STD 10, RFC 1869.=0A November =
1995.=0A=0A [RFC-KEYWORDS]=0A S. Bradner, ``Key words for =
use in RFCs to Indicate=0A Requirement Levels.'' RFC 2119. =
March 1997.=0A=0A [RFC-MIME]=0A N. Freed and N. Borenstein, =
``Multipurpose Internet Mail=0A Extensions (MIME) Part One: =
Format of Internet Message=0A Bodies.'' RFC 2045. November =
1996.=0A=0A [NIST-SHA1]=0A NIST FIPS PUB 180-1, ``Secure =
Hash Standard.'' National=0A Institute of Standards and =
Technology, U.S. Department of=0A Commerce. May 1994. =
DRAFT.=0A=0A [RFC-SMTP]=0A J. Klensin, editor, ``Simple Mail =
Transfer Protocol.'' RFC=0A 2821. April =
2001.=0A=0A=0A9=089.=08. =
I=08In=08nf=08fo=08or=08rm=08ma=08at=08ti=08io=08on=08na=08al=08l =
R=08Re=08ef=08fe=08er=08re=08en=08nc=08ce=08es=08s=0A=0A =
[RFC-DELIVERYBY]=0A D. Newman, ``Deliver By SMTP Service =
Extension.'' RFC 2852.=0A June 2000.=0A=0A =
[RFC-DSN-SMTP]=0A K. Moore, ``SMTP Service Extension for =
Delivery Status=0A Notifications.'' RFC 1891. January =
1996.=0A=0A [RFC-MDN]=0A R. Fajman, ``An Extensible Message =
Format for Message=0A Disposition Notifications.'' RFC 2298. =
March 1998.=0A=0A [RFC-RANDOM]=0A D. Eastlake, S. Crocker, =
and J. Schiller, ``Randomness=0A Recommendations for =
Security.'' RFC 1750. December 1994.=0A=0A=0A1=0810=080.=08. =
A=08Au=08ut=08th=08ho=08or=08rs=08s'=08' =
A=08Ad=08dd=08dr=08re=08es=08ss=08se=08es=08s=0A=0A Eric =
Allman=0A Sendmail, Inc.=0A 6425 Christie Ave, 4th =
Floor=0A Emeryville, CA 94608=0A U.S.A.=0A=0A =
E-Mail: [email protected]=0A Phone: +1 510 594 5501=0A =
Fax: +1 510 594 5429=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e =
7=087]=08]=0A=0C=0AI=08In=08nt=08te=08er=08rn=08ne=08et=08t =
D=08Dr=08ra=08af=08ft=08t M=08Me=08es=08ss=08sa=08ag=08ge=08e =
T=08Tr=08ra=08ac=08ck=08ki=08in=08ng=08g E=08ES=08SM=08MT=08TP=08P =
E=08Ex=08xt=08te=08en=08ns=08si=08io=08on=08n =
M=08Ma=08ar=08rc=08ch=08h 1=0819=089,=08, =
2=0820=0800=0803=083=0A=0A=0A Tony Hansen=0A AT&T =
Laboratories=0A Middletown, NJ 07748=0A U.S.A.=0A=0A =
Phone: +1 732 420 8934=0A E-Mail: =
[email protected]=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=0A=0AA=08Al=08ll=08lm=08ma=08an=08n &=08& =
H=08Ha=08an=08ns=08se=08en=08n =
[=08[P=08Pa=08ag=08ge=08e 8=088]=08]=0A=0C
--==========2147514699==========--