From owner-ietf-msgtrk@imc.org Thu Dec 23 05:02:34 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 FAA19580 for ; Thu, 23 Dec 1999 05:02:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03702 for ietf-msgtrk-bks; Thu, 23 Dec 1999 01:42:11 -0800 (PST) Received: from leeloo.icicle.ch (roland@m14-077.echo.ch [212.254.210.77]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03698 for ; Thu, 23 Dec 1999 01:42:07 -0800 (PST) Received: from localhost (roland@localhost) by leeloo.icicle.ch (8.9.3/8.9.3) with ESMTP id KAA00505 for ; Thu, 23 Dec 1999 10:43:38 +0100 X-Authentication-Warning: leeloo.icicle.ch: roland owned process doing -bs Date: Thu, 23 Dec 1999 10:43:29 +0100 (CET) From: Roland Brand X-Sender: roland@leeloo.icicle.ch To: Message Tracking Working Group Subject: New proposal for the interactive message tracking protocol Message-ID: 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 about a counter-proposal for a message tracking system. This solution fits to the post-hoc model defined in the model document. Instead of adding a new command to SMTP for tracking, I would rather create a new tracking protocol. SMTP would then only have to be slightly adapted, so that it logs every message traversal. The logged information would have to be written to a database in a unified way, so that every message gets a unique tracking identifier, as described in the model document. A special tracking entity would then use this database to answer tracking requests. These requests use some form of authenticator, which may be the one described in the model document. The user would then have a tracking agent, which collects the information about a particular message from the different tracking entities. The advantages of this solution are: 1. The same tracking protocol can also be used for other systems than SMTP. It could then provide information about the whereabouts of a message in an X.400 or even a proprietary system. Furthermore there could be information as "fetched through POP3" and so on. 2. The tracking activity is kept away from the e-mail system, so that an SMTP server cannot be saturated with tracking requests by malicious users. 3. It requires only slight changes in SMTP, namely to generate the logs. This prevents us from creating a real monster of a protocol. From my point of view the protocol independency mentioned in point 1 is of primary importance, since it increases the quality of the tracking service a lot. The other protocols would only have to create the same kind of log entries, so that the software used for tracking could be remain exactly the same. I am about to build a prototype implementation during my diploma thesis at the Swiss Federal Institute of Technology and I would appreciate to get your opinion on it. Yours sincerely --- Roland Brand Student at Swiss Federal Institute of Technology (ETH) roland@vis.ethz.ch From owner-ietf-msgtrk@imc.org Thu Dec 23 21:14:36 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 VAA05698 for ; Thu, 23 Dec 1999 21:14:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15478 for ietf-msgtrk-bks; Thu, 23 Dec 1999 17:53:43 -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 RAA15474 for ; Thu, 23 Dec 1999 17:53:41 -0800 (PST) Received: from messagingdirect.com (2-097-edm.dial.worldgate.ca [207.167.2.97]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id SAA22493; Thu, 23 Dec 1999 18:57:49 -0700 Message-ID: <3862D259.DFD2FFD0@messagingdirect.com> Date: Thu, 23 Dec 1999 18:54:33 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Roland Brand CC: Message Tracking Working Group Subject: Re: New proposal for the interactive message tracking protocol References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roland Brand wrote: > > I would like to start discussion about a counter-proposal for a message > tracking system. > > This solution fits to the post-hoc model defined in the model document. > Instead of adding a new command to SMTP for tracking, I would rather > create a new tracking protocol. SMTP would then only have to be slightly > adapted, so that it logs every message traversal. The logged information > would have to be written to a database in a unified way, so that every > message gets a unique tracking identifier, as described in the model > document. > > A special tracking entity would then use this database to answer tracking > requests. These requests use some form of authenticator, which may be the > one described in the model document. > > The user would then have a tracking agent, which collects the information > about a particular message from the different tracking entities. > > The advantages of this solution are: > > 1. The same tracking protocol can also be used for other systems than > SMTP. It could then provide information about the whereabouts of a message > in an X.400 or even a proprietary system. Furthermore there could be > information as "fetched through POP3" and so on. > > 2. The tracking activity is kept away from the e-mail system, so that an > SMTP server cannot be saturated with tracking requests by malicious users. > > 3. It requires only slight changes in SMTP, namely to generate the logs. > This prevents us from creating a real monster of a protocol. > > From my point of view the protocol independency mentioned in point 1 is of > primary importance, since it increases the quality of the tracking service > a lot. The other protocols would only have to create the same kind of log > entries, so that the software used for tracking could be remain exactly > the same. > > I am about to build a prototype implementation during my diploma thesis at > the Swiss Federal Institute of Technology and I would appreciate to get > your opinion on it. > > Yours sincerely > > --- > Roland Brand > Student at Swiss Federal Institute of Technology (ETH) > roland@vis.ethz.ch From owner-ietf-msgtrk@imc.org Thu Dec 23 21:27:20 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 VAA05749 for ; Thu, 23 Dec 1999 21:27:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA18869 for ietf-msgtrk-bks; Thu, 23 Dec 1999 18:11:14 -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 SAA18857 for ; Thu, 23 Dec 1999 18:11:11 -0800 (PST) Received: from messagingdirect.com (2-097-edm.dial.worldgate.ca [207.167.2.97]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id TAA22505; Thu, 23 Dec 1999 19:15:33 -0700 Message-ID: <3862D681.EA8F750B@messagingdirect.com> Date: Thu, 23 Dec 1999 19:12:17 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Roland Brand , Message Tracking Working Group Subject: Re: New proposal for the interactive message tracking protocol References: <3862D259.DFD2FFD0@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, the previous message was accidental! > > The advantages of this solution are: > > > > 1. The same tracking protocol can also be used for other systems than > > SMTP. It could then provide information about the whereabouts of a message > > in an X.400 or even a proprietary system. Furthermore there could be > > information as "fetched through POP3" and so on. > > > > 2. The tracking activity is kept away from the e-mail system, so that an > > SMTP server cannot be saturated with tracking requests by malicious users. This is good point. > > 3. It requires only slight changes in SMTP, namely to generate the logs. In most cases MTA already generate logs. The only change would be to add records to some sort of temporary message tracking database. Saying that, it would be simpler to extend SMTP than create new protocol. Writing to message tracking database would be already in MTA, so it would be easy in many cases to add querying the database. IMHO, adding such query command would be as easy as adding support for VRFY command when server already has RCPT TO:. > > This prevents us from creating a real monster of a protocol. Anyway, to leverage existing code it is better if not to extend SMTP, but at least use SMTP syntax. Also in Washington it was proposed to use DSN format for the response to such command. > > From my point of view the protocol independency mentioned in point 1 is of > > primary importance, since it increases the quality of the tracking service > > a lot. The other protocols would only have to create the same kind of log > > entries, so that the software used for tracking could be remain exactly > > the same. > > > > I am about to build a prototype implementation during my diploma thesis at > > the Swiss Federal Institute of Technology and I would appreciate to get > > your opinion on it. > > > > Yours sincerely > > > > --- > > Roland Brand > > Student at Swiss Federal Institute of Technology (ETH) > > roland@vis.ethz.ch