From owner-ietf-msgtrk@imc.org Wed Nov 3 13:31:33 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08699 for ; Wed, 3 Nov 1999 13:31:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12401 for ietf-msgtrk-bks; Wed, 3 Nov 1999 10:13:32 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12397 for ; Wed, 3 Nov 1999 10:13:31 -0800 (PST) Received: from galileo.esys.ca (dhcp198-188.esys.ca [198.161.92.188]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id LAA23023 for ; Wed, 3 Nov 1999 11:13:34 -0700 From: Steve Hole Date: Tue, 2 Nov 1999 21:25:47 -0700 To: Message Tracking Working Group Subject: Proposal for the interactive message tracking protocol Message-ID: X-Mailer: Execmail for Win32 5.2 b1 Build (2) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would like to start discussion on the solution space for message tracking. To do this I am going to propose a solution strawman that I have discussed with a few other design team members (specifically Tony Hansen and Eric Allman). There are a number of other possible solution models and it would be nice to get more of them on the table. In addition to the requirements defined in the model document, I have added the following: 1. MUST be easy to deploy. The corollary of this is that SHOULD maximize reuse of existing, already deployed technology and infrastructure. 2. SHOULD extend existing protocols and not invent new ones. 3. SHOULD have a low implementation cost. This makes it easy to incorporate into existing products. As an aside, if people agree that these are a good set of requirements in general, we should probably add them in a requirements section of the model document. Interactive DSN. This solution fits into the "hybrid model" defined in the model document. I propose to add a "MTRK" extension command to SMTP that requests tracking information for a message from an MTA. The message is identified using a unique tracking identifier as described in the model document. The tracking agent requesting the tracking information is authenticated using some form of authenticator, not unlike the example used in the model document. The "MTRK" command returns to the tracking agent the computer parseable part of a DSN with the tracking information in it, or an error result. Possible errors would include "no permission", "never heard of this message", etc. We will want to extend the number of disposition states in DSN's to account for "in transit" states that result from interactive tracking. I haven't thought too much about the syntax of the SMTP request response. Didn't feel like it until there was some idea whether the idea has merit or not. There might be an issue with handing back response data like this in SMTP in that it would be somewhat larger than your average SMTP response. The things that I like about this solution are: 1. It leverages the existing support for DSN in tracking software. You clearly will want to be able to accept existing DSN information in a tracking agent, so using the existing syntax (even slightly extended) makes good use of existing implementations (if any). 2. It would be pretty simple to implement. It would be a single command/response extension using the standard SMTP extension framework. 3. It talks directly to MTAs which clearly are the source for tracking information. It is my intention to raise this as a potential solution during the working group meeting in next week. It would be nice to have some discussion about it on the list prior to the meeting. Cheers. --- Steve Hole MessagingDirect Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk@imc.org Thu Nov 4 10:07:19 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15573 for ; Thu, 4 Nov 1999 10:07:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA06701 for ietf-msgtrk-bks; Thu, 4 Nov 1999 06:57:43 -0800 (PST) Received: from web208.mail.yahoo.com (web208.mail.yahoo.com [128.11.68.108]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06697 for ; Thu, 4 Nov 1999 06:57:41 -0800 (PST) Message-ID: <19991104150015.10960.rocketmail@web208.mail.yahoo.com> Received: from [204.196.188.183] by web208.mail.yahoo.com; Thu, 04 Nov 1999 07:00:15 PST Date: Thu, 4 Nov 1999 07:00:15 -0800 (PST) From: Tomorrow SystemsInc Reply-To: TomorrowSys@yahoo.com Subject: Re: Proposal for the interactive message tracking protocol To: ietf-msgtrk@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this idea is a good one. In order to trace the complete path of a message, a "management station" will go from MTA to MTA to MTA, piecing the information together as it goes. This is a lot like the model for classic network management, where each "agent" is independent and aggregate staticstics about the network must be deduced from information returned from multiple agents. As far as the following goes: >There might be an issue > with handing back > response data like this in SMTP in that it would be > somewhat larger than > your average SMTP response. At what point does this apply ? Do you mean during the setup phase of an SMTP session only ? MTAs pass some very large messages, so the overhead of the message tracking response is probably about the same as a message unless there is a protocol-specific state where MTAs traditionally don't want to see a "larger than average SMTP response" as you describe above. Otherwise, what is the anticipated ratio of message tracking requests versus normal message traffic ? Is there a class of user who will want to saturate and MTA with message tracking requests ? Gordon ===== Gordon Jones Tomorrow Systems Incorporated Internet Consulting - Internet Software http://www.tomorrowsys.com (703) 309 - 8859 __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ietf-msgtrk@imc.org Thu Nov 4 14:15:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24636 for ; Thu, 4 Nov 1999 14:15:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11374 for ietf-msgtrk-bks; Thu, 4 Nov 1999 10:59:34 -0800 (PST) Received: from mail.bcbsfl.com ([157.174.220.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11370 for ; Thu, 4 Nov 1999 10:59:33 -0800 (PST) Received: from 157.174.228.221 by mail.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 04 Nov 99 13:59: 03 -0500 X-Server-Uuid: ce89229e-6f44-11d2-930e-00805f65671f Received: from 157.174.149.239 by wsse.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 04 Nov 99 09:02: 13 -0500 X-Server-Uuid: 1f3d01f6-3236-11d2-8b2f-00c04f971bc8 X-Server-Uuid: 25439fb6-7579-11d1-978b-00a024cc3d5c From: "Ward, Jon" To: "'TomorrowSys@yahoo.com'" , Subject: RE: Proposal for the interactive message tracking protocol Date: Thu, 4 Nov 1999 13:59:13 -0500 MIME-Version: 1.0 X-WSS-ID: 143F0809165355-01-02 X-WSS-ID: 143F4E6F49149-01-02 X-WSS-ID: 143F08FD127107-01-02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Message-ID: <143F08FD127107-01@Blue_Cross_Blue_Shield_of_Florida> Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Have we thought about the desired use and potential use of this? Depending upon the results desired, we may need to approach the design from different angles. A few possible features come to mind. We may want to realize a standardized Receipt Notification that will allow users to send a message and request the receipt notification. We may want to have the Read Notification. Other things like this would happen almost entirely at the Application layer. This could be done without modifying the function of SMTP. If we want, for example, to be able to troubleshoot an undelivered message by requesting information from each SMTP relay along the path, we may need to implement some sort of tracking log on each relay so that it can provide this information upon request. In any case, there must be some way to uniquely identify each message. This identifier may need to be the same across different boundaries of management responsibility. I am very much in favor of the message tracking concept. Do we have a scope of requirements or even a wish-list? Would we be the ones to brainstorm about this list? Jon Ward -----Original Message----- From: Tomorrow SystemsInc [mailto:tomorrowsys@yahoo.com] Sent: Thursday, November 04, 1999 10:00 AM To: ietf-msgtrk@imc.org Subject: Re: Proposal for the interactive message tracking protocol I think this idea is a good one. In order to trace the complete path of a message, a "management station" will go from MTA to MTA to MTA, piecing the information together as it goes. This is a lot like the model for classic network management, where each "agent" is independent and aggregate staticstics about the network must be deduced from information returned from multiple agents. As far as the following goes: >There might be an issue > with handing back > response data like this in SMTP in that it would be > somewhat larger than > your average SMTP response. At what point does this apply ? Do you mean during the setup phase of an SMTP session only ? MTAs pass some very large messages, so the overhead of the message tracking response is probably about the same as a message unless there is a protocol-specific state where MTAs traditionally don't want to see a "larger than average SMTP response" as you describe above. Otherwise, what is the anticipated ratio of message tracking requests versus normal message traffic ? Is there a class of user who will want to saturate and MTA with message tracking requests ? Gordon ===== Gordon Jones Tomorrow Systems Incorporated Internet Consulting - Internet Software http://www.tomorrowsys.com (703) 309 - 8859 __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ietf-msgtrk@imc.org Fri Nov 5 00:48:19 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01451 for ; Fri, 5 Nov 1999 00:48:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA06101 for ietf-msgtrk-bks; Thu, 4 Nov 1999 21:36:12 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06097 for ; Thu, 4 Nov 1999 21:36:11 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id AAA06555 for ; Fri, 5 Nov 1999 00:35:52 -0500 (EST) Received: from att.com ([135.197.44.138]) by maillennium.att.com (labmail) with SMTP id <19991105053315099016384ce>; Fri, 5 Nov 1999 05:33:16 +0000 Message-ID: <38226C86.4E58B9CF@att.com> Date: Fri, 05 Nov 1999 00:35:02 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Ward, Jon" CC: ietf-msgtrk@imc.org Subject: Re: Proposal for the interactive message tracking protocol References: <143F08FD127107-01@Blue_Cross_Blue_Shield_of_Florida> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Ward, Jon" wrote: > > Have we thought about the desired use and potential use of this? Depending > upon the results desired, we may need to approach the design from different > angles. > > A few possible features come to mind. We may want to realize a > standardized Receipt Notification that will allow users to send a > message and request the receipt notification. We may want to have > the Read Notification. Other things like this would happen almost > entirely at the Application layer. This could be done without > modifying the function of SMTP. If we want, for example, to be > able to troubleshoot an undelivered message by requesting > information from each SMTP relay along the path, we may need to > implement some sort of tracking log on each relay so that it can > provide this information upon request. In any case, there must be > some way to uniquely identify each message. This identifier may > need to be the same across different boundaries of management > responsibility. > > I am very much in favor of the message tracking concept. > > Do we have a scope of requirements or even a wish-list? Would we be the > ones to brainstorm about this list? Jon, Be sure and re-read the model document: draft-ietf-msgtrk-model-00.txt. Also re-read the following documents referenced by the model document: [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For- mat for Delivery Status Notifications", RFC 1894, Univer- sity of Tennessee, Octel Network Services, January 1996. [RFC-ESMTP-DSN] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, University of Tennessee, Janu- ary 1996. [RFC-MDN] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, National Institutes of Health, March 1998. Many of your questions and comments are covered by the above references. Tony Hansen tony@att.com From owner-ietf-msgtrk@imc.org Fri Nov 5 00:48:43 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01672 for ; Fri, 5 Nov 1999 00:48:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA06110 for ietf-msgtrk-bks; Thu, 4 Nov 1999 21:36:36 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06106 for ; Thu, 4 Nov 1999 21:36:34 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id AAA09874 for ; Fri, 5 Nov 1999 00:36:15 -0500 (EST) Received: from att.com ([135.197.44.138]) by maillennium.att.com (labmail) with SMTP id <19991105053339099016384ge>; Fri, 5 Nov 1999 05:33:40 +0000 Message-ID: <38226C9E.E348BD06@att.com> Date: Fri, 05 Nov 1999 00:35:26 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: TomorrowSys@yahoo.com CC: ietf-msgtrk@imc.org Subject: Re: Proposal for the interactive message tracking protocol References: <19991104150015.10960.rocketmail@web208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tomorrow SystemsInc wrote: > ... > As far as the following goes: > > >There might be an issue > > with handing back > > response data like this in SMTP in that it would be > > somewhat larger than > > your average SMTP response. > > At what point does this apply ? Do you mean during the > setup phase of an SMTP session only ? MTAs pass some > very large messages, so the overhead of the message > tracking response is probably about the same as a > message unless there is a protocol-specific state > where MTAs traditionally don't want to see a "larger > than average SMTP response" as you describe above. It's the opposite of the usual client-to-server ratio (large data segments compared to small server responses), but the comparison is apt. If the response to a tracking request were encapsulated in what essentially looks like a delivery notification, then it will be the size of a small mail message. > Otherwise, what is the anticipated ratio of message > tracking requests versus normal message traffic ? I expect it to be rather low. > Is there a class of user who will want to saturate and > MTA with message tracking requests ? Hmmm, good question. Tony Hansen tony@att.com From owner-ietf-msgtrk@imc.org Fri Nov 5 01:13:52 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01450 for ; Fri, 5 Nov 1999 00:48:18 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA06087 for ietf-msgtrk-bks; Thu, 4 Nov 1999 21:35:23 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06083 for ; Thu, 4 Nov 1999 21:35:21 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id AAA13951 for ; Fri, 5 Nov 1999 00:34:57 -0500 (EST) Received: from att.com ([135.197.44.138]) by maillennium.att.com (labmail) with SMTP id <19991105053225099016384ae>; Fri, 5 Nov 1999 05:32:26 +0000 Message-ID: <38226C54.898A9CBC@att.com> Date: Fri, 05 Nov 1999 00:34:12 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Hole CC: Message Tracking Working Group Subject: Re: Proposal for the interactive message tracking protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Hole wrote: > > I would like to start discussion on the solution space for message > tracking. To do this I am going to propose a solution strawman that I > have discussed with a few other design team members (specifically Tony > Hansen and Eric Allman). There are a number of other possible solution > models and it would be nice to get more of them on the table. > > In addition to the requirements defined in the model document, I have > added the following: > > 1. MUST be easy to deploy. The corollary of this is that SHOULD > maximize reuse of existing, already deployed technology and > infrastructure. > > 2. SHOULD extend existing protocols and not invent new ones. > > 3. SHOULD have a low implementation cost. This makes it easy to > incorporate into existing products. > > As an aside, if people agree that these are a good set of requirements > in general, we should probably add them in a requirements section of the > model document. Sounds reasonable. > Interactive DSN. > > This solution fits into the "hybrid model" defined in the model > document. I propose to add a "MTRK" extension command to SMTP that > requests tracking information for a message from an MTA. The message is > identified using a unique tracking identifier as described in the model > document. The tracking agent requesting the tracking information is > authenticated using some form of authenticator, not unlike the example > used in the model document. The "MTRK" command returns to the tracking > agent the computer parseable part of a DSN with the tracking information > in it, or an error result. Possible errors would include "no > permission", "never heard of this message", etc. > > We will want to extend the number of disposition states in DSN's to > account for "in transit" states that result from interactive tracking. The above is concentrating on the aspect of finding out the status of a message. We also need to design how to designate that a message is to be tracked and how to identify that message for later queries. > I haven't thought too much about the syntax of the SMTP request > response. Didn't feel like it until there was some idea whether the > idea has merit or not. There might be an issue with handing back > response data like this in SMTP in that it would be somewhat larger than > your average SMTP response. I agree that discussion on this aspect can be held off until later. > The things that I like about this solution are: > > 1. It leverages the existing support for DSN in tracking software. > You clearly will want to be able to accept existing DSN information > in a tracking agent, so using the existing syntax (even slightly > extended) makes good use of existing implementations (if any). > > 2. It would be pretty simple to implement. It would be a single > command/response extension using the standard SMTP extension > framework. > > 3. It talks directly to MTAs which clearly are the source for tracking > information. > > It is my intention to raise this as a potential solution during the > working group meeting in next week. It would be nice to have some > discussion about it on the list prior to the meeting. I'm looking forward to it. Tony Hansen tony@att.com From owner-ietf-msgtrk@imc.org Thu Nov 18 16:51:27 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24447 for ; Thu, 18 Nov 1999 16:51:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06364 for ietf-msgtrk-bks; Thu, 18 Nov 1999 13:32:45 -0800 (PST) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [209.157.59.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06360 for ; Thu, 18 Nov 1999 13:32:44 -0800 (PST) Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com (Mirapoint) with SMTP id AAF00832; Thu, 18 Nov 1999 13:34:07 -0800 (PST) Date: 18 Nov 1999 13:34:30 -0800 Message-ID: From: Tim Showalter X-Spook: Vince Foster Cocaine Ft. Knox Janet Reno Nazi Semtex Rule Psix To: ietf-msgtrk@imc.org Subject: Why message tracking cookies should be in the message headers Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I was asked to post the following to the mailing list at the WG meeting. There is one good reason that I can think of to put message tracking information in message headers instead of (or possibly in addition to) an SMTP argument. If we enable delegation of tracking (as current proposals seem to allow), the message recipient could track backwards after the message has been received. Tracking information can be sent through systems that may not accept it in SMTP. I can't claim that this behavior is necessarily useful. I haven't been able to think of a really strong reason for it in the last week. If the message has reached its destination, all the useful tracking information you're likely to find is in the Received headers. If the message hasn't reached its destination, you can't track it backwards. This leaves only two reasons for this approach: one, it enables users at both ends to do something that may amuse them; two, we may think of something clever later that involves going through an uncooperative MTA. If a message goes to multiple recipients with different cookies for each recipient, this method doesn't work. Tim