From owner-ietf-msgtrk@mail.imc.org Thu Mar 8 07:11:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23048 for ; Thu, 8 Mar 2001 07:11:35 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA19561 for ietf-msgtrk-bks; Thu, 8 Mar 2001 03:57:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19556 for ; Thu, 8 Mar 2001 03:57:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22334; Thu, 8 Mar 2001 06:57:02 -0500 (EST) Message-Id: <200103081157.GAA22334@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-msgtrk@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msgtrk-mtqp-02.txt Date: Thu, 08 Mar 2001 06:57:02 -0500 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Tracking Protocol Working Group of the IETF. Title : Message Tracking Query Protocol Author(s) : T. Hansen Filename : draft-ietf-msgtrk-mtqp-02.txt Pages : 17 Date : 07-Mar-01 Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with exten- sions to the ESMTP protocol to provide a complete message tracking solu- tion for the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-mtqp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msgtrk-mtqp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msgtrk-mtqp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307142650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msgtrk-mtqp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msgtrk-mtqp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142650.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-msgtrk@mail.imc.org Fri Mar 16 18:58:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15557 for ; Fri, 16 Mar 2001 18:58:42 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA23795 for ietf-msgtrk-bks; Fri, 16 Mar 2001 15:49:06 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA23791 for ; Fri, 16 Mar 2001 15:49:05 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06254 for ; Fri, 16 Mar 2001 15:49:08 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08075 for ; Fri, 16 Mar 2001 15:49:07 -0800 (PST) Date: Fri, 16 Mar 2001 15:46:19 -0800 From: Chris Newman To: ietf-msgtrk@imc.org Subject: message/tracking-status validation Message-ID: <6719650.984757579@localhost> X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've updated my message validation utility to support message/tracking-status validation: Incidentally, the examples in the mtqp draft don't fare very well (I'll send a private message to the author with details). - Chris From owner-ietf-msgtrk@mail.imc.org Sat Mar 17 19:49:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10768 for ; Sat, 17 Mar 2001 19:49:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA05865 for ietf-msgtrk-bks; Sat, 17 Mar 2001 16:39:59 -0800 (PST) Received: from horsey.gshapiro.net (jzx8vv@horsey.gshapiro.net [209.220.147.178]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05861 for ; Sat, 17 Mar 2001 16:39:57 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.0.Beta5/8.12.0.Beta5) id f2I0e1hP030839; Sat, 17 Mar 2001 16:40:01 -0800 (PST) Message-ID: <15028.992.833276.919238@horsey.gshapiro.net> Date: Sat, 17 Mar 2001 16:40:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200103081157.GAA22334@ietf.org> References: <200103081157.GAA22334@ietf.org> X-Mailer: VM 6.91 under 21.2 (beta42) "Poseidon" XEmacs Lucid From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: Comments on draft-ietf-msgtrk-mtqp-02.txt Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 2. Basic Operation > ... > If the host is not found, the MTQP client then does an MX lookup for the > server host using DNS MX records. This line needs more explanation. How are these MX records used? Based on preference? Just the first? How about when equal preferences? > 2.1. Tracking Service DNS Considerations > ... > In both cases, note that the tracking service for a given mail > domain MUST be able to handle the queries for all messages destined for > that mail domain. Is sending a referral to another MTQP server sufficient in satisfying this MUST? > 2.3. Responses > ... > All response lines are terminated by a CRLF pair and are limited to 998 > characters before the CRLF. Just a note that this differs from RFC821's 512 character (including CRLF) limit. This probably doesn't matter. > 3. Initialization and Option Response > ... > "/" "unavailable" > "/" "admin" > "/" "unknown" > "/" "referral" "=" net_loc These should be defined. Also net_loc should be defined somewhere. > [Command sections] Should we add a "HELP" command? > 4. TRACK Command > ... > Mtrk-secret is the secret A described in [RFC-TRACK-ESMTP], encoded using > base64. Reference RFC2045 for the definition of base64? > 6.1. Processing After the STARTTLS Command > ... > After the TLS handshake has been completed What is TLS handshake can't be successfully completed? RFC 2487BIS says: After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection. > 6.1. Processing After the STARTTLS Command > ... > If the MTQP server decides that the level of authentication or privacy is > not high enough for it to continue, it SHOULD reply to every MTQP command > from the client (other than a QUIT command) with a negative "-BAD" response > and a response code of "/insecure". Should also accept the STARTTLS command to renegotiate, possibly with a different client certificate to gain an acceptable level of authentication. I'm not convinced that this is necessarily needed or a good idea, but it may be worth considering. > 9. URL Format > ... > mtqp:///track// > mtqp://:/track// In both cases, the mtrk-secret appears to be open for sniffing. Do we need an mtqps: to indicate STARTTLS is required? > 9.1. MTQP URL Syntax > ... > mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret This differs from the text directly above. Above, envid and mtrk-secret are separated by "/", here they are separated by ":". > 11. Security Considerations > ... > Both the STMP client and server must check the result of the TLS Replace "STMP" with "MTQP". > 11. Security Considerations > ... > The SMTP client and server should note carefully the result of the > TLS negotiation. Replace "SMTP" with "MTQP". Alternatively, remove this paragraph as it pretty much repeats what is said in the previous paragraph. > 12. Protocol Syntax > ... > client-command = track-command / starttls-command / quit-command / comment-command > ... > command-response = success-response / temp-response / error-response / bad-response Maybe wrap these better, e.g.: client-command = track-command / starttls-command / quit-command / comment-command command-response = success-response / temp-response / error-response bad-response > 16. Full Copyright Statement > ... > Copyright (C) The Internet Society (1999). All Rights Reserved. This should probably include 2000 and 2001. From owner-ietf-msgtrk@mail.imc.org Sat Mar 17 19:49:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10783 for ; Sat, 17 Mar 2001 19:49:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA05879 for ietf-msgtrk-bks; Sat, 17 Mar 2001 16:40:07 -0800 (PST) Received: from horsey.gshapiro.net (vup4uv@horsey.gshapiro.net [209.220.147.178]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05874 for ; Sat, 17 Mar 2001 16:40:05 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.0.Beta5/8.12.0.Beta5) id f2I0e9wQ030842; Sat, 17 Mar 2001 16:40:09 -0800 (PST) Message-ID: <15028.1001.145953.111187@horsey.gshapiro.net> Date: Sat, 17 Mar 2001 16:40:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: VM 6.91 under 21.2 (beta42) "Poseidon" XEmacs Lucid From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: draft-ietf-msgtrk-trkstat-00.txt Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I found some issues while rereading this document: 3.3.3. Action field The required Action field indicates the action performed by the Reporting-MTA as a result of its attempt to delivery the message to this recipient address. ^^^^^^^^ Typo: "delivery" should be "deliver". 3.3.7. Will-Retry-Until field The Will-Retry-Until field is defined as in section Ref- erence 2.3.8 of [RFC-DSN-STAT]. This field is REQUIRED if the message is still in the MTA queue. This field MUST NOT be included if the message is not in the local queue. This appears to conflict with using Action: opaque. The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list. The "expanded" action is not listed in the "3.3.3. Action field" section and should be added. From owner-ietf-msgtrk@mail.imc.org Tue Mar 20 18:16:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00701 for ; Tue, 20 Mar 2001 18:16:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA22384 for ietf-msgtrk-bks; Tue, 20 Mar 2001 14:38:20 -0800 (PST) Received: from knecht.Neophilic.COM (knecht.sendmail.org [209.31.233.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA22373 for ; Tue, 20 Mar 2001 14:38:13 -0800 (PST) Received: from jean-baptiste.sendmail.org (pcp001417pcs.wireless.meeting.ietf.org [135.222.67.149]) by knecht.Neophilic.COM (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2KMcFKl037960 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 Mar 2001 14:38:16 -0800 (PST) Received: (from eric@localhost) by jean-baptiste.sendmail.org (8.11.1.Alpha0/8.11.1.Alpha0) id f2KMbuZ03075; Tue, 20 Mar 2001 14:37:56 -0800 (PST) Date: Tue, 20 Mar 2001 14:37:56 -0800 (PST) Message-Id: <200103202237.f2KMbuZ03075@jean-baptiste.sendmail.org> To: ietf-msgtrk@imc.org From: Eric Allman X-URL: http://WWW.Sendmail.ORG/~eric Subject: updated draft-ietf-msgtrk-trkstat & -smtpext Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-8000914160" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message. --==_Exmh_-8000914160 Content-Type: text/plain I thought I would run these by the list before submitting them for publication. If there are any comments before Thursday, I'll incorporate them, otherwise I'll submit them as is. eric --==_Exmh_-8000914160 Content-Type: text/plain ; name="draft-ietf-msgtrk-trkstat.txt" Content-Description: draft-ietf-msgtrk-trkstat.txt Content-Disposition: attachment; filename="draft-ietf-msgtrk-trkstat.txt" Internet Draft E. Allman draft-ietf-msgtrk-trkstat-00.txt Sendmail, Inc. Valid for six months March 20, 2001 Updates: RFC 1893 The Message/Tracking-Status MIME Extension Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html This document is a submission by the MSGTRK Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the msgtrk@imc.org mailing list. An archive of the mailing list may be found at http://www.ietf.org/archive/msgtrk Distribution of this memo is unlimited. 1. Abstract Message Tracking is expected to be used to determine the sta- tus of undelivered e-mail upon request. Tracking is used in con- junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes- sage Disposition Notifications [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 1894, ``An Extensible Message Format for Delivery Status Notifications'' [RFC-DSN-STAT]. Internet Draft Message/Tracking-Status March 20, 2001 It is to be issued upon a request as described in ``Message Track- ing Query Protocol'' [DRAFT-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. 2. Other Documents and Conformance The model used for Message Tracking is described in [DRAFT- MTRK-MODEL]. Message tracking is intended for use as a "last resort" mecha- nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if no response from either of these mechanisms would Message Tracking be used. This document is based on [RFC-DSN-STAT]. Sections 1.3 (Ter- minology), 2.1.1 (General conventions for DSN fields), 2.1.2 ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 822) of [RFC-DSN-STAT] are included into this document by refer- ence. Other sections are further incorporated as described herein. Syntax notation in this document conforms to [RFC-ABNF]. The following lexical tokens, defined in [RFC-MSGFMT], are used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [RFC-HOSTREQ]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 3. Format of a Message Tracking Status Notification A Message Tracking Status Notification (MTSN) is intended to be returned as the body of a Message Tracking request [DRAFT-MTRK- MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] with type of "tracking-status"; each subpart MUST be type "mes- sage/tracking-status" as described herein. 3.1. The message/tracking-status content-type The message/tracking-status content-type is defined as fol- lows: MIME type name: message MIME subtype name: tracking-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 4 of this memo. Allman [Page 2] Internet Draft Message/Tracking-Status March 20, 2001 The body of a message/tracking-status is modeled after [RFC-DSN-STAT]. That body consists of one or more "fields" for- matted to according to the ABNF of RFC 822 headers "fields" (see [RFC-MSGFMT]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Formally, the syntax of the message/tracking-status content is as follows: tracking-status-content = per-message-fields 1*( CRLF per-recipient-fields ) The per-message fields are described in section 3.2. The per- recipient fields are described in section 3.3. 3.1.1. General conventions for MTSN fields Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definition of xtext is identical to that of that document. 3.1.2. *-type subfields Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definitions of address-type, diagnostic-type, and MTA-name type are identi- cal to that of RFC 1894. 3.2. Per-Message MTSN Fields Some fields of an MTSN apply to all of the addresses in a single envelope. These fields may appear at most once in any MTSN. These fields are used to correlate the MTSN with the original message transaction and to provide additional informa- tion which may be useful to gateways. per-message-fields = original-envelope-id-field CRLF reporting-mta-field CRLF arrival-date CRLF *( extension-field CRLF ) 3.2.1. The Original-Envelope-Id field The optional Original-Envelope-Id field is defined as in section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED. 3.2.2. The Reporting-MTA field The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN-STAT]. This field is REQUIRED. Allman [Page 3] Internet Draft Message/Tracking-Status March 20, 2001 3.2.3. The Arrival-Date field The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN-STAT]. This field is REQUIRED. 3.3. Per-Recipient MTSN fields An MTSN contains information about attempts to deliver a message to one or more recipients. The delivery information for any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line. The syntax for the group of per-recipient fields is as fol- lows: per-recipient-fields = original-recipient-field CRLF final-recipient-field CRLF action-field CRLF status-field CRLF [ remote-mta-field CRLF ] [ last-attempt-date-field CRLF ] [ will-retry-until-field CRLF ] *( extension-field CRLF ) 3.3.1. Original-Recipient field The optional Original-Recipient field is defined as in section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED. 3.3.2. Final-Recipient field The required Final-Recipient field is defined as in sec- tion 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED. 3.3.3. Action field The required Action field indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient address. This field MUST be present for each recipient named in the MTSN. The syntax is as defined in section 2.3.3 of RFC 1894. This field is REQUIRED. Valid actions are: failed The message could not be delivered. If DSNs have been enabled, a "failed" DSN should already have been returned. delayed The message is currently waiting in the MTA queue for future delivery. Essentially, this action means "the message is located, and it is Allman [Page 4] Internet Draft Message/Tracking-Status March 20, 2001 here." delivered The message has been successfully delivered to the final recipient. This includes "delivery" to a mailing list exploder. It does not indi- cate that the message has been read. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "down- stream" tracking requests. expanded The message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. However, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests. relayed The message has been delivered into an environ- ment that does not support message tracking. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests. transferred The message has been transferred to another MTRK-compliant MTA. The tracking agent SHOULD attempt further "downstream" tracking requests. opaque The message may or may not have been seen by this system. No further information is avail- able or forthcoming. 3.3.4. Status field The Status field is defined as in RFC 1894 section 2.3.4. A new code is added to RFC 1893 [RFC-EMSSC], "Enhanced Mail System Status Codes", X.1.9 Message relayed to non-compliant mailer" The mailbox address specified was valid, but the mes- sage has been relayed to a system that does not speak this protocol; no further information can be pro- vided. A 2.1.9 Status field MUST be used exclusively with a "relayed" Action field. This field is REQUIRED. 3.3.5. Remote-MTA field The Remote-MTA field is defined as in section Reference 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if no delivery attempts have been made or if the Action field has value "opaque". If delivery to some agent other than an MTA (for example, a Local Delivery Agent) then this field MAY be included, giving the name of the host on which that agent Allman [Page 5] Internet Draft Message/Tracking-Status March 20, 2001 was contacted. 3.3.6. Last-Attempt-Date field The Last-Attempt-Date field is defined as in section Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt has been made and the Action field does not have value "opaque", in which case it will specify when it last attempted to deliver this message to another MTA or other Delivery Agent. This field MUST NOT be included if no delivery attempts have been made. 3.3.7. Will-Retry-Until field The Will-Retry-Until field is defined as in section Ref- erence 2.3.8 of [RFC-DSN-STAT]. If the message is not in the local queue or the Action field has the value ``opaque'' the Will-Retry-Until field MUST NOT be included; otherwise, this field is REQUIRED. 3.4. Extension fields Future extension fields may be defined as defined in sec- tion 2.4 of [RFC-DSN-STAT]. 3.5. Interaction Between MTAs and LDAs A message that has been delivered to an LDA that under- stands message tracking (in particular, an LDA speaking LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the tracking request to the LDA. In this case, the Action field for the MTA->LDA exchange will look the same as a transfer to a com- pliant MTA; that is, a "transferred" tracking status will be issued. 4. Security Issues 4.1. Forgery Malicious servers may attempt to subvert message tracking and return false information. This could result in misdirection or misinterpretation of results. 4.2. Confidentiality Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding mes- sages but does not wish to divulge the address to which the mes- sages are autoforwarded. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses. MTA authors are encouraged to provide a mechanism which enables the end user to preserve the confidentiality of a for- warding address. Depending on the degree of confidentiality Allman [Page 6] Internet Draft Message/Tracking-Status March 20, 2001 required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of: (a) respond with a "relayed" tracking status when a message is forwarded to a confidential forwarding address, and dis- abling further message tracking requests. (b) declaring the message to be delivered, issuing a "deliv- ered" tracking status, re-sending the message to the confi- dential forwarding address, and disabling further message tracking requests. The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list. 5. References [DRAFT-MTRK-MODEL] T. Hansen, ``Message Tracking Model and Requirements.'' draft-ietf-msgtrk-model-03.txt. November 2000. [DRAFT-MTRK-MTQP] T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf- msgtrk-mtqp-01.txt. November 2000. [DRAFT-MTRK-SMTPEXT] E. Allman, ``SMTP Service Extension for Message Tracking.'' draft-ietf-msgtrk-smtpext-00.txt. December 2000. [RFC-ABNF] Crocker, D., Editor, and P. Overell, ``Augmented BNF for Syn- tax Specifications: ABNF'', RFC 2234, November 1997. [RFC-DSN-REPT] G. Vaudreuil, ``The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.'' RFC 1892. January 1996. [RFC-DSN-SMTP] K. Moore, ``SMTP Service Extension for Delivery Status Notifi- cations.'' RFC 1891. January 1996. [RFC-DSN-STAT] K. Moore and G. Vaudreuil, ``An Extensible Message Format for Delivery Status Notifications.'' RFC 1894. January 1996. [RFC-EMSSC] G. Vaudreuil, ``Enhanced Mail System Status Codes.'' RFC 1893. January 1996. [RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. Allman [Page 7] Internet Draft Message/Tracking-Status March 20, 2001 November 1995. [RFC-HOSTREQ] R. Braden (ed.), ``Requirements for Internet Hosts -- Applica- tion and Support.'' STD 3, RFC 1123. October 1989. [RFC-KEYWORDS] S. Bradner, ``Key words for use in RFCs to Indicate Require- ment Levels.'' RFC 2119. March 1997. [RFC-LMTP] J. Myers, ``Local Mail Transfer Protocol.'' RFC 2033. Octo- ber 1996. [RFC-MDN] R. Fajman, ``An Extensible Message Format for Message Disposi- tion Notifications.'' RFC 2298. March 1998. [RFC-MIME] N. Freed and N. Borenstein, ``Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bod- ies.'' RFC 2045. November 1996. [RFC-MSGFMT] D. Crocker, ``Standard for the Format of ARPA Internet Text Messages.'' RFC 822. August 1982. [RFC-RELATED] E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC 2387. August 1998. 6. Author's Address Eric Allman Sendmail, Inc. 6603 Shellmound Emeryville, CA 94608 U.S.A. E-Mail: eric@Sendmail.COM Phone: +1 510 594 5501 Fax: +1 510 594 5411 Allman [Page 8] --==_Exmh_-8000914160 Content-Type: text/plain ; name="draft-ietf-msgtrk-smtpext.txt" Content-Description: draft-ietf-msgtrk-smtpext.txt Content-Disposition: attachment; filename="draft-ietf-msgtrk-smtpext.txt" Internet Draft E. Allman draft-ietf-msgtrk-smtpext-00.txt Sendmail, Inc. Valid for six months T. Hansen Updates: RFC 1891 AT&T Laboratories March 20, 2001 SMTP Service Extension for Message Tracking Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html This document is a submission by the MSGTRK Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the msgtrk@imc.org mailing list. An archive of the mailing list may be found at http://www.ietf.org/archive/msgtrk Distribution of this memo is unlimited. 1. Abstract This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. Internet Draft Message Tracking ESMTP Extension March 20, 2001 2. Other Documents and Conformance The model used for Message Tracking is described in [DRAFT- MTRK-MODEL]. Doing a Message Tracking query is intended as a "last resort" mechanism. Normally, Delivery Status Notifications (DSNs) [RFC- DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if the message is not received, or there is no response from either of these mecha- nisms should a Message Tracking query be issued. The definition of the base64 token is imported from section 6.8 of [RFC-MIME]. Syntax notation in this document conforms to [RFC-ABNF]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 3. SMTP Extension Overview The Message Tracking SMTP service extension uses the SMTP ser- vice extension mechanism described in [RFC-ESMTP]. The following service extension is hereby defined: (1) The name of the SMTP service extension is "Message Track- ing". (2) The EHLO keyword value associated with this extension is "MTRK". (3) No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying options. (4) One optional parameter using the keyword "MTRK" is added to the MAIL FROM command. In addition, the ENVID and ORCPT parameters (as defined in RFC 1891 sections 5.4 and 5.2 respectively) MUST be supported, with extensions as described below. (5) The maximum length of a MAIL FROM command line is increased by 40 characters by the possible addition of the MTRK key- word and value. Note that a further extension of 614 char- acters for the ORCPT and ENVID parameters is required by RFC-DSN-EXT]. (6) No SMTP verbs are defined by this extension. Allman & Hansen [Page 2] Internet Draft Message Tracking ESMTP Extension March 20, 2001 4. The Extended MAIL FROM Command The extended MAIL FROM command is issued by an SMTP client when it wishes to inform an SMTP server that message tracking information should be retained for future querying. The extended MAIL FROM command is identical to the MAIL FROM command as defined in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear after the address. 4.1. The MTRK parameter to the ESMTP MAIL command Any sender wishing to track a message must first tag that message as trackable by creating two values A and B: A = some-large-random-number B = SHA1(A) The large random number A is calculated on a host-dependent basis. See [RFC-RANDOM] for a discussion of choosing good ran- dom numbers. This random number MUST be at least 128 bits but MUST NOT be more than 1024 bits. The 128-bit hash B of A is then computed using the SHA-1 algorithm as described in [NIST-SHA1]. The sender then base64 encodes value B and passes that value as the mtrk-certifier on the MAIL FROM command: mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ] mtrk-certifier = base64 ; authenticator mtrk-timeout = 1*9digit; seconds until timeout A is stored in the originator's tracking database to vali- date future tracking requests as described in [DRAFT-MTRK-MTQP]. B is stored in tracking tracking databases of compliant MTAs and used to authenticate future tracking requests. The mtrk-timeout field indicates the number of seconds that the client requests that this tracking information be retained on intermediate servers, as measured from the initial receipt of the message at that server. Servers MAY ignore this value if it violates local policy. In particular, servers MAY silently enforce an upper limit to how long they will retain tracking data; this limit MUST be at least one day. If no mtrk-timeout field is specified then the server should use a local default. This default SHOULD be 8-10 days and MUST be at least one day. Notwithstanding this clause, the information MUST NOT be expired while the message remains in the queue for this server: that is, an MTQP server MUST NOT deny knowledge of a message while that same message sits in the MTA queue. If the message is relayed to another compliant SMTP server, the MTA acting as the client SHOULD pass an mtrk-timeout field Allman & Hansen [Page 3] Internet Draft Message Tracking ESMTP Extension March 20, 2001 equal to the remaining life of that message tracking informa- tion. Specifically, the tracking timeout is decremented by the number of seconds the message has lingered at this MTA and then passed to the next MTA. If the decremented tracking timeout is less than or equal to zero, the entire MTRK parameter MUST NOT be passed to the next MTA; essentially, the entire tracking path is considered to be lost at that point. See [RFC-DELIVERYBY] section 4 for an explanation of why a timeout is used instead of an absolute time. 4.2. Use of ENVID To function properly, Message Tracking requires that each message have a unique identifier that is never reused by any other message. For that purpose, if the MTRK parameter is given, an ENVID parameter MUST be included, and the syntax of ENVID from RFC 1891 section 5.4 is extended as follows: envid-parameter = "ENVID=" unique-envid unique-envid = local-envid "@" fqhn local-envid = xtext fqhn = xtext The unique-envid MUST be chosen in such a way that the same ENVID will never be used by any other message sent from this system or any other system. In most cases, this means setting fqhn to be the fully qualified host name of the system generat- ing this ENVID, and local-envid to an identifier that is never re-used by that host. Any retransmissions of this message MUST assign a new ENVID. In this context, "retransmission" includes forwarding or resending a message. 4.3. Forwarding Tracking Certifiers MTAs SHOULD forward unexpired tracking certifiers to com- pliant mailers as the mail is transferred during regular hop-to- hop transfers. If the "downstream" MTA is not MTRK-compliant, then the MTRK= parameter MUST be deleted. If the downstream MTA is DSN-compliant, then the ENVID and ORCPT parameters MUST NOT be deleted. If aliasing, forwarding, or other redirection of messages to a single recipient occurs, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified. MTAs MUST NOT copy MTRK certifiers when relaying a message to multiple recipients. An MTA MAY designate one recipient in a multi-recipient alias as the "primary" recipient to which track- ing requests shall be forwarded; other addresses SHALL NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certi- fiers when doing mailing list expansion. Allman & Hansen [Page 4] Internet Draft Message Tracking ESMTP Extension March 20, 2001 5. Security Issues 5.1. Denial of service An attacker could attempt to flood the database of a server by submitting large numbers of small, tracked messages. In this case, a site may elect to lower its maximum retention period retroactively. 5.2. Confidentiality The mtrk-authenticator value (``A'') must be hard to pre- dict and not reused. The originating client must take reasonable precautions to protect the secret. For example, if the secret is stored in a message store (e.g., a "Sent" folder), the client must make sure the secret isn't accessible by attackers, particularly on a shared store. MTAs SHOULD take precautions to make certain that message tracking cannot be used to explore internal topologies of net- works. 6. References [DRAFT-MTRK-MODEL] T. Hansen, ``Message Tracking Model and Requirements.'' draft-ietf-msgtrk-model-03.txt. November 2000. [DRAFT-MTRK-MTQP] T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf- msgtrk-mtqp-01.txt. November 2000. [RFC-ABNF] Crocker, D., Editor, and P. Overell, ``Augmented BNF for Syn- tax Specifications: ABNF'', RFC 2234, November 1997. [RFC-DELIVERYBY] D. Newman, ``Deliver By SMTP Service Extension.'' RFC 2852. June 2000. [RFC-DSN-REPT] G. Vaudreuil, ``The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.'' RFC 1892. January 1996. [RFC-DSN-SMTP] K. Moore, ``SMTP Service Extension for Delivery Status Notifi- cations.'' RFC 1891. January 1996. [RFC-DSN-STAT] K. Moore and G. Vaudreuil, ``An Extensible Message Format for Delivery Status Notifications.'' RFC 1894. January 1996. Allman & Hansen [Page 5] Internet Draft Message Tracking ESMTP Extension March 20, 2001 [RFC-EMSSC] G. Vaudreuil, ``Enhanced Mail System Status Codes.'' RFC 1893. January 1996. [RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. Novem- ber 1995. [RFC-KEYWORDS] S. Bradner, ``Key words for use in RFCs to Indicate Require- ment Levels.'' RFC 2119. March 1997. [RFC-MDN] R. Fajman, ``An Extensible Message Format for Message Disposi- tion Notifications.'' RFC 2298. March 1998. [RFC-MIME] N. Freed and N. Borenstein, ``Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bod- ies.'' RFC 2045. November 1996. [RFC-MSGFMT] D. Crocker, ``Standard for the Format of ARPA Internet Text Messages.'' RFC 822. August 1982. [RFC-RANDOM] [RFC-RELATED] E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC 2387. August 1998. [NIST-SHA1] NIST FIPS PUB 180-1, ``Secure Hash Standard.'' National Institute of Standards and Technology, U.S. Department of Com- merce. May 1994. DRAFT. [RFC-SMTP] J. Postel, ``Simple Mail Transport Protocol.'' RFC 821. August 1982. 7. Authors' Addresses Eric Allman Sendmail, Inc. 6603 Shellmound Emeryville, CA 94608 U.S.A. E-Mail: eric@Sendmail.COM Phone: +1 510 594 5501 Fax: +1 510 594 5411 Allman & Hansen [Page 6] Internet Draft Message Tracking ESMTP Extension March 20, 2001 Tony Hansen AT&T Laboratories Lincroft, NJ 07738 U.S.A. Phone: +1 732 576 3207 E-Mail: tony@att.com Allman & Hansen [Page 7] --==_Exmh_-8000914160-- From owner-ietf-msgtrk@mail.imc.org Mon Mar 26 18:46:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20990 for ; Mon, 26 Mar 2001 18:46:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA07309 for ietf-msgtrk-bks; Mon, 26 Mar 2001 15:38:04 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA07299 for ; Mon, 26 Mar 2001 15:38:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20633; Mon, 26 Mar 2001 18:37:36 -0500 (EST) Message-Id: <200103262337.SAA20633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-msgtrk@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt Date: Mon, 26 Mar 2001 18:37:36 -0500 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Tracking Protocol Working Group of the IETF. Title : SMTP Service Extension for Message Tracking Author(s) : E. Allman, T. Hansen Filename : draft-ietf-msgtrk-smtpext-01.txt Pages : 7 Date : 23-Mar-01 This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-smtpext-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msgtrk-smtpext-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msgtrk-smtpext-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010323090555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msgtrk-smtpext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msgtrk-smtpext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010323090555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-msgtrk@mail.imc.org Mon Mar 26 18:46:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21012 for ; Mon, 26 Mar 2001 18:46:19 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA07340 for ietf-msgtrk-bks; Mon, 26 Mar 2001 15:38:16 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA07334 for ; Mon, 26 Mar 2001 15:38:15 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20647; Mon, 26 Mar 2001 18:37:39 -0500 (EST) Message-Id: <200103262337.SAA20647@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-msgtrk@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt Date: Mon, 26 Mar 2001 18:37:38 -0500 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Tracking Protocol Working Group of the IETF. Title : The Message/Tracking-Status MIME Extension Author(s) : E. Allman Filename : draft-ietf-msgtrk-trkstat-01.txt Pages : 8 Date : 23-Mar-01 Message Tracking is expected to be used to determine the sta- tus of undelivered e-mail upon request. Tracking is used in con- junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes- sage Disposition Notifications [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msgtrk-trkstat-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msgtrk-trkstat-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010323090606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msgtrk-trkstat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msgtrk-trkstat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010323090606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-msgtrk@mail.imc.org Wed Mar 28 19:51:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15974 for ; Wed, 28 Mar 2001 19:51:52 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA15187 for ietf-msgtrk-bks; Wed, 28 Mar 2001 16:40:50 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA15182 for ; Wed, 28 Mar 2001 16:40:48 -0800 (PST) Received: from i-gotmail (i-gotmail.red.iplanet.com [192.18.73.46]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2T0euL23943 for ; Wed, 28 Mar 2001 16:40:56 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built Mar 11 2001)) with ESMTPS id <0GAX00I6ROK145@we-gotmail.red.iplanet.com> for ietf-msgtrk@imc.org; Wed, 28 Mar 2001 16:40:51 -0800 (PST) Date: Wed, 28 Mar 2001 16:33:27 -0800 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt In-reply-to: <200103262337.SAA20633@ietf.org> To: ietf-msgtrk@imc.org Message-id: <158887.985797207@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <200103262337.SAA20633@ietf.org> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT --On Monday, March 26, 2001 18:37 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Message Tracking Protocol > Working Group of the IETF. > > Title : SMTP Service Extension for Message Tracking > Author(s) : E. Allman, T. Hansen > Filename : draft-ietf-msgtrk-smtpext-01.txt > Pages : 7 > Date : 23-Mar-01 Missing the reference for [RFC-RANDOM]: Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. ---- This paragraph from 4.2: Any retransmissions of this message MUST assign a new ENVID. In this context, "retransmission" includes forwarding or resending a message. appears to contradict this paragraph from 4.3: If aliasing, forwarding, or other redirection of messages to a single recipient occurs, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified. ---- I think you need to distinguish between the different types of forwarding. One class is "public automated unconditional MTA-level forwarding" which is always tracked. Private manual conditional UA-level forwarding is likely never tracked. Then there's a bunch of gray areas (e.g., MTA-level Sieve redirect) which may require a site-level or user-level choice. Some discussion of the privacy issues with respect to tracking forwarded messages is in order. If the forwarding isn't public information, the tracking system may need to suppress some of the results. An example would be a webmaster@domain.com address forwarded to an individual. Perhaps the site doesn't want that individual's name known to reduce headhunter calls. ---- MTAs SHOULD take precautions to make certain that message tracking cannot be used to explore internal topologies of net- works. ---- I think this is too strong. Trying to hide internal names and topologies through obfuscation is little more than security through obscurity and in practice can reduce security since it can make attacks harder to trace. I'd say: Many sites believe that concealing names and topologies of internal systems is an important security feature. MTAs need to balance such desires with the need to obtain adequate tracking information for inappropriate messages, including those from internal sources. - Chris From owner-ietf-msgtrk@mail.imc.org Wed Mar 28 20:19:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16281 for ; Wed, 28 Mar 2001 20:19:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA17327 for ietf-msgtrk-bks; Wed, 28 Mar 2001 17:15:48 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA17322 for ; Wed, 28 Mar 2001 17:15:47 -0800 (PST) Received: from i-gotmail (i-gotmail.red.iplanet.com [192.18.73.46]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2T1FtL00607 for ; Wed, 28 Mar 2001 17:15:55 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built Mar 11 2001)) with ESMTPS id <0GAX00K78Q6DEH@we-gotmail.red.iplanet.com> for ietf-msgtrk@imc.org; Wed, 28 Mar 2001 17:15:50 -0800 (PST) Date: Wed, 28 Mar 2001 17:08:27 -0800 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt In-reply-to: <200103262337.SAA20647@ietf.org> To: ietf-msgtrk@imc.org Message-id: <285171.985799306@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <200103262337.SAA20647@ietf.org> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT --On Monday, March 26, 2001 18:37 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Message Tracking Protocol > Working Group of the IETF. > > Title : The Message/Tracking-Status MIME Extension > Author(s) : E. Allman > Filename : draft-ietf-msgtrk-trkstat-01.txt > Pages : 8 > Date : 23-Mar-01 Message tracking is intended for use as a "last resort" mecha- nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if no response from either of these mechanisms would Message Tracking be used. The last sentence needs a verb. A Message Tracking Status Notification (MTSN) is intended to be returned as the body of a Message Tracking request [DRAFT-MTRK- MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] with type of "tracking-status"; each subpart MUST be type "mes- sage/tracking-status" as described herein. The multipart/related type parameter takes a media type, so: ... The actual body MUST be a multipart/related [RFC-RELATED] with type parameter of message/tracking-status. ---- ... That body consists of one or more "fields" for- matted to according to the ABNF of RFC 822 headers "fields" (see [RFC-MSGFMT]). headers -> header ---- The body of a message/tracking-status is modeled after [RFC-DSN-STAT]. That body consists of one or more "fields" for- matted to according to the ABNF of RFC 822 headers "fields" (see [RFC-MSGFMT]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Formally, the syntax of the message/tracking-status content is as follows: I'd be inclined to add something like: Note that there will be a blank line between the final per-recipient field and the MIME boundary, since one CRLF is necessary to terminate the field, and a second is necessary to introduce the MIME boundary. ---- delivered The message has been successfully delivered to the final recipient. This includes "delivery" to a mailing list exploder. It does not indi- cate that the message has been read. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "down- stream" tracking requests. expanded The message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. However, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests. ... The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list. I'm unclear under what conditions to use "delivered" or "expanded" for mailing lists or aliases. Please fix. ---- 3.5. Interaction Between MTAs and LDAs A message that has been delivered to an LDA that under- stands message tracking (in particular, an LDA ... You need to associate "LDA" with the expansion of the acronym in section 3.3.5. Either expand it once here as well, or use the acronym in 3.3.5. ---- A note on my security consideration suggestion for the SMTPEXT document, a reference to the security considerations section in this document would suffice. - Chris From owner-ietf-msgtrk@mail.imc.org Thu Mar 29 13:46:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02284 for ; Thu, 29 Mar 2001 13:46:25 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA19711 for ietf-msgtrk-bks; Thu, 29 Mar 2001 10:35:25 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19707 for ; Thu, 29 Mar 2001 10:35:24 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id LAA26049; Thu, 29 Mar 2001 11:34:19 -0700 From: Steve Hole Date: Thu, 29 Mar 2001 11:34:16 -0700 To: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt Cc: ietf-msgtrk@imc.org In-Reply-To: <158887.985797207@nifty-jr.west.sun.com> References: <158887.985797207@nifty-jr.west.sun.com> <200103262337.SAA20633@ietf.org> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 28 Mar 2001 16:33:27 -0800 Chris Newman wrote: > I think you need to distinguish between the different types of > forwarding. > One class is "public automated unconditional MTA-level forwarding" which is > always tracked. Private manual conditional UA-level forwarding is likely > never tracked. Then there's a bunch of gray areas (e.g., MTA-level Sieve > redirect) which may require a site-level or user-level choice. I think that we should presume that sieve redirection is done during final delivery and is directed by the user 100% of the time. I'm sure that there are arguments for other uses which is fine, but I think that it intent that matters. If it is a user rule, then it is final delivery and that is in MUA land. Final delivery through the sieve engine should terminate tracking (I think). > Some discussion of the privacy issues with respect to tracking forwarded > messages is in order. If the forwarding isn't public information, the > tracking system may need to suppress some of the results. An example would > be a webmaster@domain.com address forwarded to an individual. Perhaps the > site doesn't want that individual's name known to reduce headhunter calls. Hmm ... so this would typically hit the aliasing engine in most MTA's. Unless I'm mistaken, we have recommended treating this exactly as DSN does, which I believe differentiates between final recipient and original recipient. Does the DSN spec allow for site specification of whether or not they will report differences between orignal and final recipient? In any case, the answer to the above question doesn't really matter. We should just do as DSN does I think. Cheers. --- Steve Hole Chief Technology Officer ACI - MessagingDirect Phone: 780-424-4922 From owner-ietf-msgtrk@mail.imc.org Thu Mar 29 13:57:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03507 for ; Thu, 29 Mar 2001 13:57:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA20683 for ietf-msgtrk-bks; Thu, 29 Mar 2001 10:52:08 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA20679 for ; Thu, 29 Mar 2001 10:52:07 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id LAA26078; Thu, 29 Mar 2001 11:51:31 -0700 From: Steve Hole Date: Thu, 29 Mar 2001 11:51:28 -0700 To: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt Cc: ietf-msgtrk@imc.org In-Reply-To: <285171.985799306@nifty-jr.west.sun.com> References: <285171.985799306@nifty-jr.west.sun.com> <200103262337.SAA20647@ietf.org> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 28 Mar 2001 17:08:27 -0800 Chris Newman wrote: > The tracking algorithms MUST NOT allow tracking through > list expansions. When a message is delivered to a list, a > tracking request MUST respond with an "expanded" tracking status > and MUST NOT display the contents of the list. > > I'm unclear under what conditions to use "delivered" or "expanded" for > mailing lists or aliases. Please fix. Once again, we refer back to the detailed definitions for each of these occurrences in the DSN spec. Delivery to a mailing list gets the "expanded" response. Delivery to a single alias "relays" normally with a change in the final recipient. Delivery to multiple-recipient aliases are handled in one of three ways, implementation defined. I don't believe that we want to screw down the multiple-recipient aliases choices any tighter, but we could consider it. I would be inclined to directly reference section 6.2.7, with specific changes for any additional or modified status codes used because we are referencing along the chain of delivery. I don't think that there are any. Cheers. --- Steve Hole Chief Technology Officer ACI - MessagingDirect Phone: 780-424-4922