From owner-ietf-msgtrk@mail.imc.org Fri Mar 28 17:15:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21662 for ; Fri, 28 Mar 2003 17:15:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SMDG023418 for ietf-msgtrk-bks; Fri, 28 Mar 2003 14:13:16 -0800 (PST) Received: from knecht.Neophilic.COM (knecht.sendmail.org [209.31.233.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SMDEg23413 for ; Fri, 28 Mar 2003 14:13:14 -0800 (PST) Received: from irma.neophilic.com (natted.Sendmail.COM [63.211.143.38]) by knecht.Neophilic.COM (8.12.8/8.13.0.PreAlpha0) with ESMTP id h2SMCvaJ014133 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Mar 2003 14:12:57 -0800 (PST) Received: from csxcpxw2k.smi.sendmail.com (localhost [127.0.0.1]) by irma.neophilic.com (8.12.8/8.12.2) with ESMTP id h2SMCuYR001781; Fri, 28 Mar 2003 14:12:57 -0800 (PST) Date: Fri, 28 Mar 2003 14:12:56 -0800 From: Eric Allman To: internet-drafts@ietf.org cc: ietf-msgtrk@imc.org Subject: updated msgtrk drafts Message-ID: <2147483647.1048860776@[10.210.202.39]> X-Mailer: Mulberry/3.0.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========2147514699==========" X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BALANCE_FOR_LONG_20K,MIME_EXCESSIVE_QP, SPAM_PHRASE_00_01 version=2.43 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========2147514699========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit 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-Disposition: attachment; filename="draft-ietf-msgtrk-trkstat-05.txt"; size=23648 Content-Transfer-Encoding: quoted-printable =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 = =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 ietf-msgtrk@imc.org 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: = eric@Sendmail.COM=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-Disposition: attachment; filename="draft-ietf-msgtrk-smtpext-05.txt"; size=19075 Content-Transfer-Encoding: quoted-printable =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 = =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 ietf-msgtrk@imc.org = 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: eric@Sendmail.COM=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: = tony@att.com=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==========--