From ???@??? Wed May 27 08:54:58 1998 Return-Path: X-Envelope-From: gbjones@mitre.org Received: (qmail 16625 invoked from network); 26 May 1998 16:54:45 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 26 May 1998 16:54:45 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA1776498 for ; Tue, 26 May 1998 12:49:27 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id MAA11336 for ; Tue, 26 May 1998 12:54:43 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 160096; Tue, 26 May 1998 12:54:43 EST Message-ID: <356AF39C.D3EEFCF6@mitre.org> Date: Tue, 26 May 1998 12:53:48 -0400 From: gbjones@mitre.org (Gordon B. Jones) Organization: The MITRE Corp. X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: GK@acm.org (Graham Klyne) cc: gbjones@mitre.org Subject: Re: MIME message management, etc. References: <3.0.32.19980526170544.00a799d0@pop.dial.pipex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Here is the PROPOSED charter. We're still waiting to hear from the IETF on the definitive status of the charter. If you're interested, please subscribe to the mailing list and be on the lookout for a meeting entitled msgtrk at the next IETF. I gave Malcom detailed instructions for getting on the list. We also need volunteers to help write the documents. Gordon ------------------------- Message Tracking Working Group (msgtrk) - --------------------------------------- Charter Chair(s): Gordon B. Jones Applications Area Director(s) Harald Alvestrand Keith Moore Area Advisor Keith Moore Mailing lists: General Discussion: msgmib-list@mail91.mitre.org To Subscribe: listserv@mitre.org In Body: subscribe msgmib-list Archive: sloop-1.esinet.org/pub/msgmib-archive Description of Working Group: The Message Tracking Working Group will design a diagnostic protocol for message originator, message recipient, and administrative access to information about the submission, transport, and delivery of a message. For each of these classes of users there will be different requirements and security implications. The group will produce two standards track documents: a message tracking model document and a protocol document. The model will describe the message tracking problem by identifying the entities involved (e.g., message relays or "MTAs", management agents), define relationships between the entities, define approaches for inter-domain message tracking, and address security issues. The types of messages to be tracked include RFC 822bis messages, and optionally others. The protocol will contain variables and elements of procedure to implement the message tracking model. The protocol will provide the necessary security and privacy features, and will exclude services provided by existing mail systems. The resulting protocol will be useful for fault, performance, and security purposes. Using the message tracking protocol it will be possible to issue queries about messages that were previously sent and obtain responses containing information about those messages. For instance, a query might contain a unique message ID or an originator name, and the response might contain the disposition time and disposition status (delivered/non-delivered) of the message. Goals and Milestones: Jun 1 Post an Internet Draft of the message tracking model Aug 1 Post revised draft of message tracking model 42nd IETF discuss protocol, finish model Oct 15 post final draft of model, post Internet Draft of protocol Nov 25 Post revised draft of protocol 43rd IETF discuss protocol Feb 1 Post final draft of protocol From ???@??? Mon Aug 10 17:07:16 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 28119 invoked from network); 10 Aug 1998 14:27:00 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 10 Aug 1998 14:27:00 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA64526 for ; Mon, 10 Aug 1998 10:18:35 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id KAA22938; Mon, 10 Aug 1998 10:22:53 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA22222; Mon, 10 Aug 1998 10:22:30 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1163277 for MSGMIB-LIST@MAIL91.MITRE.ORG; Mon, 10 Aug 1998 10:22:07 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA22201; Mon, 10 Aug 1998 10:22:03 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id KAA22654 for ; Mon, 10 Aug 1998 10:22:02 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 320789; Mon, 10 Aug 1998 10:16:53 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <35CF009D.94A3ACA7@mitre.org> Date: Mon, 10 Aug 1998 10:15:57 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: Message Tracking Meeting at the 42nd IETF To: Multiple recipients of list MSGMIB-LIST There will be a message tracking meeting at the 42nd IETF on Thursday, August 27 at 1 p.m. Here is a tentative agenda. See you there: 1. Review Charter and Charter status 2. Review model document (some of the below may already be complete from the last meeting): a.Review levels of users or "adminisrative levels" b.Review model draft document (Vaudreuil). What types of messaging "events" will we be tracking ? What is the scope ? What components are involved ? c. Revisit requirements for queries: what items are available for message tracking (e.g. sender, recipient, message ID, and so on) at each administrative level, and which ones ought to be available ? 3. Security a. Given that we know who the "users" of the information are, what security features are necessary to support each type of user ? What message tracking information is each user allowed to "see" ? How do you handle inter-domain users ? 4. Protocol Issues (if we ever get that far) a. What protocols are available to do this job, and what does the group think ? b. What security mechanisms are available in the chosen protocol (TCP, SNMPv3, SSL) to support the security features, and exactly how is the technical information employed ? From ???@??? Wed Sep 02 15:00:01 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 27711 invoked from network); 2 Sep 1998 11:37:50 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 2 Sep 1998 11:37:50 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA53834 for ; Wed, 2 Sep 1998 07:28:29 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA03553; Wed, 2 Sep 1998 07:36:57 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA27419; Wed, 2 Sep 1998 07:36:55 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1196523 for MSGMIB-LIST@MAIL91.MITRE.ORG; Wed, 2 Sep 1998 07:36:50 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA25709; Wed, 2 Sep 1998 07:36:44 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id HAA03527 for ; Wed, 2 Sep 1998 07:36:43 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 388910; Wed, 02 Sep 1998 07:36:44 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <35ED2D9A.839AB7FC@mitre.org> Date: Wed, 2 Sep 1998 07:35:55 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: Results of msgtrk BOF Meeting To: Multiple recipients of list MSGMIB-LIST The msgtrk BOF meeting at the 42nd IETF was well-attended with lively discussion. As a result, several scoping decisions made by the group will affect the draft charter. In the next message, I'm going to post a revised draft charter. Please post your comments (yea or nea) to the list. If the charter looks ok, I'll request that an IETF working group be created. Gordon From ???@??? Wed Sep 02 15:00:02 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 1102 invoked from network); 2 Sep 1998 11:41:08 -0000 Received: from sandstorm.dial.pipex.net (158.43.128.20) by snowstorm.dial.pipex.net with SMTP; 2 Sep 1998 11:41:08 -0000 Received: (qmail 799 invoked from network); 2 Sep 1998 11:41:07 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 2 Sep 1998 11:41:07 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA11798 for ; Wed, 2 Sep 1998 07:31:43 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA03900; Wed, 2 Sep 1998 07:40:14 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA30117; Wed, 2 Sep 1998 07:40:13 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1196538 for MSGMIB-LIST@MAIL91.MITRE.ORG; Wed, 2 Sep 1998 07:40:12 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA29929; Wed, 2 Sep 1998 07:40:11 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id HAA03887 for ; Wed, 2 Sep 1998 07:40:11 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 388923; Wed, 02 Sep 1998 07:40:11 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mime-Autoconverted: from 8bit to quoted-printable by mbunix.mitre.org id HAA03887 Message-Id: <35ED2E6A.5E06F27A@mitre.org> Date: Wed, 2 Sep 1998 07:39:22 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: Revised Draft Charter To: Multiple recipients of list MSGMIB-LIST Message Tracking Working Group (msgtrk) --------------------------------------- Charter Chair(s): Gordon B. Jones Applications Area Director(s) Keith Moore moore@cs.utk.edu Patrik Falstrom paf@swip.net Mailing lists: General Discussion: msgmib-list@mail91.mitre.org To Subscribe: listserv@mitre.org In Body: subscribe msgmib-list Archive: sloop-1.esinet.org/pub/msgmib-archive Description of Working Group: The Message Tracking Working Group will design a diagnostic protocol for a message originator to request information about the submission, transport, and delivery of a message independently of its delivery status. The group will produce two standards track documents: a message tracking model document and a protocol document. The model will state how message tracking is enabled, identify the entities involved (e.g., MTAs, “trace servers”), define how and when message tracking requests are issued and answered, define approaches for inter-domain message tracking, and address security issues. The types of messages to be tracked include RFC 822bis messages, and optionally others. Messages will be tracked from the time they enter the messaging network up until the time they are delivered (e.g. to an end-user’s mailbox or a proprietary mail system). The group will design one or more protocols to implement message tracking as described above. Goals and Milestones: Oct 15 Post an Internet Draft of the message tracking model Nov 15 Post revised draft of message tracking model 43rd IETF discuss protocol, finish model Jan 1 post final draft of model, post Internet Draft of protocol Feb 15 Post revised draft of protocol 44 th IETF discuss protocol May 1 Post final draft of protocol From ???@??? Wed Sep 02 22:33:41 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 1565 invoked from network); 2 Sep 1998 20:37:49 -0000 Received: from sandstorm.dial.pipex.net (158.43.128.20) by snowstorm.dial.pipex.net with SMTP; 2 Sep 1998 20:37:49 -0000 Received: (qmail 4364 invoked from network); 2 Sep 1998 20:37:47 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 2 Sep 1998 20:37:47 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA53052 for ; Wed, 2 Sep 1998 16:28:25 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id QAA29912; Wed, 2 Sep 1998 16:36:29 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA11831; Wed, 2 Sep 1998 16:36:18 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1197555 for MSGMIB-LIST@MAIL91.MITRE.ORG; Wed, 2 Sep 1998 16:35:38 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA12417; Wed, 2 Sep 1998 16:34:34 -0400 Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id QAA28537 for ; Wed, 2 Sep 1998 16:34:24 -0400 (EDT) Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id QAA02545 for ; Wed, 2 Sep 1998 16:38:32 -0400 (EDT) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id QAA03029 for ; Wed, 2 Sep 1998 16:33:33 -0400 (EDT) Received: by mta2.lotus.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256673.00717D40 ; Wed, 2 Sep 1998 16:39:36 -0400 X-Lotus-Fromdomain: LOTUS@MTA Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Message-Id: <85256673.00717992.00@mta2.lotus.com> Date: Wed, 2 Sep 1998 16:29:01 -0400 Reply-To: Ken_Lin/SSW/Lotus@LOTUS.COM Sender: public list for IETF message management software group From: Ken Lin Subject: Re: Revised Draft Charter Comments: cc: Virginia_Cox/SSW/Lotus@lotus.com, Gordon_Hegfield/SSW/Lotus@lotus.com, Tom_Levandusky/SSW/Lotus@lotus.com, Frank_Palazzo/SSW/Lotus@lotus.com, Brian_Ramsey/SSW/Lotus@lotus.com, David_Schneck/SSW/Lotus@lotus.com, Denise_Shipley/SSW/Lotus@lotus.com, Mark_Skurla/SSW/Lotus@lotus.com, Jean_Thompson/SSW/Lotus@lotus.com, Mike_Heinz/SSW/Lotus@lotus.com, Steve_Scarfone/SSW/Lotus@lotus.com, Robert_Miles/SSW/Lotus@lotus.com, Grace_Kim/SSW/Lotus@lotus.com To: Multiple recipients of list MSGMIB-LIST Here are my comments. Please pardon my unfamiliarity with WG charters. > Message Tracking Working Group (msgtrk) > --------------------------------------- > > Charter > > Chair(s): > > Gordon B. Jones > > Applications Area Director(s) > > Keith Moore moore@cs.utk.edu > Patrik Falstrom paf@swip.net > > Mailing lists: > > General Discussion: msgmib-list@mail91.mitre.org 1) An IMC member offered up hosting it in his domain. > To Subscribe: listserv@mitre.org > In Body: subscribe msgmib-list 2) Since "MIB" is misleading, it has been suggested to rename the list to msgtrk. > Archive: sloop-1.esinet.org/pub/msgmib-archive 3) Clarify that the archive is accessed via FTP (someone asked about that in the BOF) > > Description of Working Group: > > > The Message Tracking Working Group will design a diagnostic > protocol for a message originator to request information about the 4) At the BOF we agreed that tracking by recipient and administrator are out of scope. Do we need to be explicit about that here or is the "message originator" passage good enough? > submission, transport, and delivery of a message independently of 5) In the next paragraph we say "The types of messages to be tracked include RFC 822bis messages, and optionally others." Did we have something in mind by "optionally others"? If not, the following sentence fragment here would be better: "submission, transport, and delivery of RFC 822 messages..." > its delivery status. > > The group will produce two standards track documents: a message > tracking model document and a protocol document. The model will > state how message tracking is enabled, identify the entities > involved (e.g., MTAs, ôtrace serversö), define how and when 6) It might be better to remove the parenthetical comment since "MTAs, trace servers" are the entities the model document will describe. > message tracking requests are issued and answered, define > approaches for inter-domain message tracking, and address security > issues. The types of messages to be tracked include RFC 822bis > messages, and optionally others. Messages will be tracked from the 7) Remove "The types of messages ... and optionally others" if we agree with bullet 5). > time they enter the messaging network up until the time they are > delivered (e.g. to an end-userÆs mailbox or a proprietary mail 8) In the BOF, there was discussion about the end point. Both "final delivery" and "drop" were used instead of "delivered". The sample usage for "drop" was "dropped to an IMAP server" rather than "delivered to an IMAP server". Any ideas on the wording for the end point? > system). > > The group will design one or more protocols to implement message > tracking as described above. > > Goals and Milestones: > > Oct 15 Post an Internet Draft of the message tracking model > > Nov 15 Post revised draft of message tracking model > > 43rd IETF discuss protocol, finish model > > Jan 1 post final draft of model, post Internet Draft of protocol > > Feb 15 Post revised draft of protocol > > 44 th IETF discuss protocol > > May 1 Post final draft of protocol > From ???@??? Thu Sep 03 18:50:53 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 13980 invoked from network); 3 Sep 1998 15:46:04 -0000 Received: from sandstorm.dial.pipex.net (158.43.128.20) by snowstorm.dial.pipex.net with SMTP; 3 Sep 1998 15:46:04 -0000 Received: (qmail 8112 invoked from network); 3 Sep 1998 15:46:03 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 3 Sep 1998 15:46:03 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA66914 for ; Thu, 3 Sep 1998 11:36:40 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id LAA19596; Thu, 3 Sep 1998 11:43:52 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA02591; Thu, 3 Sep 1998 11:43:47 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1199620 for MSGMIB-LIST@MAIL91.MITRE.ORG; Thu, 3 Sep 1998 11:43:46 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA02614; Thu, 3 Sep 1998 11:43:25 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id LAA19360; Thu, 3 Sep 1998 11:42:43 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 393741; Thu, 03 Sep 1998 11:42:43 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 References: <85256673.00717992.00@mta2.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <35EEB8C4.E39D8D53@mitre.org> Date: Thu, 3 Sep 1998 11:41:56 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: Re: Revised Draft Charter Comments: To: Ken_Lin/SSW/Lotus@lotus.com To: Multiple recipients of list MSGMIB-LIST Ken, I'll state my individual opinion. See below. Ken_Lin/SSW/Lotus@lotus.com wrote: > Here are my comments. Please pardon my unfamiliarity with WG charters. > > > Message Tracking Working Group (msgtrk) > > --------------------------------------- > > > > Charter > > > > Chair(s): > > > > Gordon B. Jones > > > > Applications Area Director(s) > > > > Keith Moore moore@cs.utk.edu > > Patrik Falstrom paf@swip.net > > > > Mailing lists: > > > > General Discussion: msgmib-list@mail91.mitre.org > > 1) An IMC member offered up hosting it in his domain. > > > To Subscribe: listserv@mitre.org > > In Body: subscribe msgmib-list > Ok. He meant hosting it at the IMC itself. I say we do this but we should also submit the charter in the meantime if it happens too slowly. > 2) Since "MIB" is misleading, it has been suggested to rename the list > to msgtrk. > ok > > Archive: sloop-1.esinet.org/pub/msgmib-archive > > 3) Clarify that the archive is accessed via FTP (someone asked about > that in the BOF) > ok > > > > Description of Working Group: > > > > > > The Message Tracking Working Group will design a diagnostic > > protocol for a message originator to request information about the > > 4) At the BOF we agreed that tracking by recipient and administrator > are out of scope. Do we need to be explicit about that here or is the > "message originator" passage good enough? > We discussed the possibility of delegation, so administrator is not entirely out of scope. I would just leave this. > > submission, transport, and delivery of a message independently of > > 5) In the next paragraph we say "The types of messages to be tracked > include RFC 822bis messages, and optionally others." Did we have > something in mind by "optionally others"? If not, the following > sentence fragment here would be better: > "submission, transport, and delivery of RFC 822 messages..." > ok > > its delivery status. > > > > The group will produce two standards track documents: a message > > tracking model document and a protocol document. The model will > > state how message tracking is enabled, identify the entities > > involved (e.g., MTAs, ttrace serversv), define how and when > > 6) It might be better to remove the parenthetical comment since "MTAs, > trace servers" are the entities the model document will describe. > ok > > message tracking requests are issued and answered, define > > approaches for inter-domain message tracking, and address security > > issues. The types of messages to be tracked include RFC 822bis > > messages, and optionally others. Messages will be tracked from the > > 7) Remove "The types of messages ... and optionally others" if we agree > with bullet 5). > ok > > time they enter the messaging network up until the time they are > > delivered (e.g. to an end-userFs mailbox or a proprietary mail > > 8) In the BOF, there was discussion about the end point. Both "final > delivery" and "drop" were used instead of "delivered". The sample > usage for "drop" was "dropped to an IMAP server" rather than "delivered > to an IMAP server". Any ideas on the wording for the end point? > I was playing with the idea of "discharged onward to an entity that is not itself an MTA". > > system). > > > > The group will design one or more protocols to implement message > > tracking as described above. > > > > Goals and Milestones: > > > > Oct 15 Post an Internet Draft of the message tracking model > > > > Nov 15 Post revised draft of message tracking model > > > > 43rd IETF discuss protocol, finish model > > > > Jan 1 post final draft of model, post Internet Draft of protocol > > > > Feb 15 Post revised draft of protocol > > > > 44 th IETF discuss protocol > > > > May 1 Post final draft of protocol > > From ???@??? Fri Sep 04 17:57:16 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 3801 invoked from network); 4 Sep 1998 14:27:48 -0000 Received: from sandstorm.dial.pipex.net (158.43.128.20) by snowstorm.dial.pipex.net with SMTP; 4 Sep 1998 14:27:48 -0000 Received: (qmail 24138 invoked from network); 4 Sep 1998 14:27:44 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 4 Sep 1998 14:27:44 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA49980 for ; Fri, 4 Sep 1998 10:18:14 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id KAA23417; Fri, 4 Sep 1998 10:26:21 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA15161; Fri, 4 Sep 1998 10:26:18 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1202862 for MSGMIB-LIST@MAIL91.MITRE.ORG; Fri, 4 Sep 1998 10:26:11 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA16272; Fri, 4 Sep 1998 10:26:07 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id KAA23362; Fri, 4 Sep 1998 10:26:06 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 396613; Fri, 04 Sep 1998 10:26:05 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F26A3BFC0AAB405517FB02B5" Message-Id: <35EFF82F.78311821@mitre.org> Date: Fri, 4 Sep 1998 10:24:47 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: draft-ietf-jones-msgtrk-def-00.txt Comments: To: internet-drafts@ietf.org To: Multiple recipients of list MSGMIB-LIST MSGTRK BOF G. Jones [gbjones@mitre.org] INTERNET-DRAFT B. Ernst [bruce_ernst@lotus.ssw.com] draft-ietf-jones-msgtrk-def-00.txt G. Vaudreuil [gregv@ons.octel.com] Expires: February 1999 Basic Definition of Message Tracking Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast). Abstract This document defines message tracking as a prelude to the creation of a message tracking model. Message tracking is a messaging management function; it provides the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. Definition Message tracking refers, in its simplest form, to determining the path an RFC822 message has taken, its current location, and its characteristics. Message tracking allows the originator of a message to issue a request about a previously sent message, the answer to which contains the delivery status, delivery time, delivered recipients, and other information about the message. This is different from the delivery status notification (DSN) function in use today, because DSNs are requested at the time of submission and are generated automatically; alternatively a tracking request is generated independently of the previously submitted message's status and is done so on demand. This capability is analogous to the service provided by carriers of conventional paper mail - the ability to quickly locate where a package is, and to determine whether or not the package has been delivered to its destination. An Internet-standard approach will allow development of message tracking applications that can operate in a multi-vendor messaging environment, and will encourage operation of the function across administrative boundaries. One might ask: why should there be a standard for message tracking when Internet domains will be unwilling to open themselves up to outside tracking requests ? This is one reason why we design and implement Internet standards. So that there is a reliable, secure, agreed upon mechanism for message tracking that people will be willing to use. Companies have implemented and are implementing message tracking today. Standardization of this technique will aid the Internet user community, make Internet messaging more profitable, and fulfill a key messaging management need. Reasons for Message Tracking Message tracking is useful for determining the whereabouts and status of "lost" messages, and for several other purposes: o When there is a lack of trust in the messaging system, such as when an originator claims a message failed to be delivered, the point of failure may be isolated. This includes messages that were never delivered or messages that were delivered incorrectly. Message tracking thus adds to the overall reliability of the mail system; o Per-message information can be used for accounting, billing, and performance purposes. Traffic can be itemized on a per-origin or per- destination basis by system or originator. This typically involves two steps - collection of message traffic data, followed by the gehe time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). o Message tracking information adds security in that the origins of potential security threats can be more precisely determined. If a system were flooded with traffic, for instance, the origin of this traffic would become known. Message tracking information is suitable for routine security audits containing the details of messaging traffic over specific time intervals; o End-to-end delivery time could be measured; o Message tracking would aid in message loop detection, since unique message identifiers of looping messages, when these exist, would be recorded multiple times; o Performance characteristics about the type of messaging traffic could be determined, such as when an inbound message causes the creation of multiple outbound messages, and the percentage of messages that were actually delivery reports or receipts. This is valuable for performance measurement, among other reasons; o Standardized message tracking information acts as a bridge between dissimilar messaging systems and dissimilar messaging communities; Tracking Messages on the Public Internet One might ask: why bother to track messages if a majority of public Internet traffic is point to point; messages don't live long enough to be trackable, and are not an interesting event to track since you always know the next point ? Just because you know where a message went that doesn't mean you know what happened to it, how fast it got there, or what was in it. As the Internet is used more and more for commercial/official purposes a logging function is commonly embedded in the messaging system internally. Even if most of the message traffic is point to point, this point-to-point traffic is inter-domain, across firewalls, and thus it is even more important to have a reliable tracking mechanism that organizations can agree on. It is something that intra-domain messaging users want. Even if 95% of transactions are point to point, the 5% that is non point-to-point is still a huge amount of traffic, and this is exactly the traffic that users will want to track. Once messaging traffic enters an intranet or domain of any size it invariably encounters a more hierarchical routing structure. Who is Allowed to Track Messages Only the originators of messages are allowed to track their messages. Optionally, an originator may delegate this responsibility to a third party, but this is left for future study. How Tracking is Done: Requests and Responses The originator will issue a message tracking request using the Unique Message Identifier plus security information. The originator (of both the message and the query at this point) will receive optional response criteria such as the message disposition, delivered recipients, delivery time, and the names of MTAs that handled the message. Security for Message Originators One option for message security is that the originator calculates a hash A to be equal to the hash of the message ID + time stamp + a per-user secret. The user then calculates hash B to be the hash of A. The user includes B in the submitted message, and retains A. Later, when the user makes a message tracking request to the messaging system or tracking entity, it submits A in the racking request. The entity receiving the tracking request then uses A to calculate B, since it was already provided B, verifying that the requestor is authentic. Summarily A = H(message ID + time stamp + secret) B = H(A) If the originator of a message were to delegate his or her tracking request to a third party by sending them A, this would be vulnerable to snooping over unencrypted sessions, but the user can decide on a message-by-message basis if this risk is acceptable. Three Possible Architectures There are ways of accomplishing message tracking without mandating the addition of large amounts of new infrastructure on the participants. Optionally, if more infrastructure is proven to be a good and necessary thing, it should be considered. In all cases, messages are only tracked from the time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). The three architectural alternatives offered by the start-up working group to date might be called "ask later", "ask now", and "ask someone else." Under "ask later", a user requests tracking as a service when submitting a message, and then at a later time issues a separate tracking request to the mail system. The user receives a response to the request from the tracking entity. This has the advantage of being deployable within the existing SMTP infrastructure. Under "ask now", a user requests tracking as a service while submitting a message, and receives a step-by-step report contemporaneously from each MTA that handles the message. This provides the user with a high level of service, but also causes extra overhead: an additional message generated for each hop the original message takes. Under "ask someone else", the user issues a separate message tracking request to an entity other than the messaging system at a later time. The user receives a response to the request from this same third-party tracking entity. This has the advantage of allowing tracking to occur when the messaging process has failed but the platform is still working. It also off-loads the tracking function from the messaging system itself. It may, however, require new infrastructure in order to support it. One possibility would be to implement "ask now" and "ask later" as SMTP extensions. One could implement "ask someone else" as a UDP- or TCP-based protocol, among other options. Acknowledgments Thanks to all those who participated in the message tracking meetings. Many thanks to Ned Freed and Harald Alvesrand for the hashing material. Internet Draft Expires February 1999 Internet Draft From ???@??? Fri Sep 04 17:57:31 1998 Return-Path: X-Envelope-From: owner-msgmib-list@MAIL91.MITRE.ORG Received: (qmail 12889 invoked from network); 4 Sep 1998 16:07:41 -0000 Received: from mail.acm.org (199.222.69.4) by depot.dial.pipex.com with SMTP; 4 Sep 1998 16:07:41 -0000 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA04238 for ; Fri, 4 Sep 1998 11:58:07 -0400 Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id MAA15863; Fri, 4 Sep 1998 12:05:42 -0400 (EDT) Received: from mail91.mitre.org by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA23908; Fri, 4 Sep 1998 12:05:41 -0400 Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 1203157 for MSGMIB-LIST@MAIL91.MITRE.ORG; Fri, 4 Sep 1998 12:05:38 -0400 Received: from mbunix by mail91.mitre.org (5.65v4.0/1.1.8.2/22Jun94-0628PM) id AA26317; Fri, 4 Sep 1998 12:05:37 -0400 Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id MAA15840; Fri, 4 Sep 1998 12:05:36 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 397090; Fri, 04 Sep 1998 12:05:36 EST X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <35F00F81.64E3D020@mitre.org> Date: Fri, 4 Sep 1998 12:04:18 -0400 Reply-To: "Gordon B. Jones" Sender: public list for IETF message management software group From: "Gordon B. Jones" Organization: The MITRE Corp. Subject: *** IMPORTANT *** msgmib List is Moving Comments: cc: paul.hoffman@mitre.org To: Multiple recipients of list MSGMIB-LIST msgmib-list is moving to ietf-msgtrk@imc.org by the end of today. You should be automatically subscribed to the new list. Please post future messages there. Gordon From owner-ietf-msgtrk Wed Sep 9 09:40:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23492 for ietf-msgtrk-bks; Wed, 9 Sep 1998 09:40:22 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23488 for ; Wed, 9 Sep 1998 09:40:21 -0700 (PDT) Message-Id: <199809091640.JAA23488@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 09 Sep 1998 09:45:25 -0700 To: ietf-msgtrk@imc.org From: Paul Hoffman / IMC Subject: Fwd: I-D ACTION:draft-jones-msgtrk-def-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk The first draft for this group has just been put into the Internet Drafts directory. It is also available at . >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-jones-msgtrk-def-00.txt >Date: Wed, 09 Sep 1998 10:45:31 -0400 >Sender: cclark@ns.cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Basic Definition of Message Tracking > Author(s) : G. Jones, B. Ernst, G. Vaudreuil > Filename : draft-jones-msgtrk-def-00.txt > Pages : 3 > Date : 08-Sep-98 > >This document defines message tracking as a prelude to the creation of >a message tracking model. Message tracking is a messaging management >function; it provides the ability to find out, after the fact, the path >that a particular message took through the messaging system, the current >status of that message, and its characteristics. > >Internet-Drafts are 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-jones-msgtrk-def-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-jones-msgtrk-def-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-jones-msgtrk-def-00.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. >Content-Type: text/plain >Content-ID: <19980908140148.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-jones-msgtrk-def-00.txt > > > --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-msgtrk Tue Sep 15 18:43:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA21317 for ietf-msgtrk-bks; Tue, 15 Sep 1998 18:43:05 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA21313 for ; Tue, 15 Sep 1998 18:43:04 -0700 (PDT) Message-Id: <199809160143.SAA21313@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 15 Sep 1998 18:48:26 -0700 To: ietf-msgtrk@imc.org From: Paul Hoffman / IMC Subject: Has anyone kept an archive of this mailing list? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk Greetings. The archive that Gordon kept of the archive is not usable by our archiving software because it is missing most of the useful headers (no fault of his). Has anyone on this list been keeping their own archive? If so, and it's in mbox format (also known as "Berkeley mail format"), please let me know and I'll take whover's is most complete to use for the IMC archive. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-msgtrk Thu Sep 17 10:24:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24100 for ietf-msgtrk-bks; Thu, 17 Sep 1998 10:24:36 -0700 (PDT) Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24096 for ; Thu, 17 Sep 1998 10:24:33 -0700 (PDT) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id NAA06340 for ; Thu, 17 Sep 1998 13:30:32 -0400 (EDT) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 425083; Thu, 17 Sep 1998 13:30:31 EST Message-ID: <360146E1.A95BC0A3@mitre.org> Date: Thu, 17 Sep 1998 13:29:05 -0400 From: gbjones@MITRE.ORG (Gordon B. Jones) Organization: The MITRE Corp. X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ietf-msgtrk@imc.org Subject: Draft CHARTER (again) Content-Type: multipart/mixed; boundary="------------6D860CCA8EA2F1193A6B39FF" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------6D860CCA8EA2F1193A6B39FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6D860CCA8EA2F1193A6B39FF Content-Type: text/plain; charset=us-ascii; name="charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="charter.txt" Message Tracking Working Group (msgtrk) --------------------------------------- Charter Chair(s): Gordon B. Jones Applications Area Director(s) Keith Moore moore@cs.utk.edu Patrik Falstrom paf@swip.net Mailing lists: General Discussion: ietf-msgtrk@imc.org To Subscribe: ietf-msgtrk-request@imc.org In Body: subscribe Archive:http://www.imc.org/ietf-msgtrk/mail-archive/ Description of Working Group: The Message Tracking Working Group will design a diagnostic protocol for a message originator to request information about the submission, transport, and delivery of a message regardless of its delivery status. The group will produce two standards track documents: a message tracking model document and a protocol document. The model will state how message tracking is enabled, identify the entities involved, define how and when message tracking requests are issued and answered, define approaches for inter-domain message tracking, and address security issues. The submission, transport, and delivery of RFC 822bis messages will be tracked from the time such messages enter the messaging network up until the time they are discharged (e.g. to an IMAP server, to an end-user's mailbox, or a proprietary mail system). The group will design one or more protocols to implement message tracking as described above. Goals and Milestones: Oct 15 Post an Internet Draft of the message tracking model Nov 15 Post revised draft of message tracking model 43rd IETF discuss protocol, finish model Jan 1 post final draft of model, post Internet Draft of protocol Feb 15 Post revised draft of protocol 44 th IETF discuss protocol May 1 Post final draft of protocol --------------6D860CCA8EA2F1193A6B39FF-- From owner-ietf-msgtrk Fri Dec 4 07:28:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12945 for ietf-msgtrk-bks; Fri, 4 Dec 1998 07:28:34 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12939 for ; Fri, 4 Dec 1998 07:28:32 -0800 (PST) From: Ken_Lin/SSW/Lotus@LOTUS.COM Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA03014 for ; Fri, 4 Dec 1998 10:39:24 -0500 (EST) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA06860 for ; Fri, 4 Dec 1998 10:31:41 -0500 (EST) Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 852566D0.005605CD ; Fri, 4 Dec 1998 10:39:35 -0500 X-Lotus-FromDomain: LOTUS@MTA To: ietf-msgtrk@imc.org Message-ID: <852566D0.005604D9.00@mta2.lotus.com> Date: Fri, 4 Dec 1998 10:23:14 -0500 Subject: MSGTRK WG at IETF? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@imc.org Precedence: bulk I see a MSGTRK WG is listed for the upcoming IETF (see http://www.ietf.org/meetings/agenda.txt) although it has no agenda (see http://www.ietf.org/meetings/wg_agenda_orlando.html) listed. What's up? From owner-ietf-msgtrk Tue Dec 15 08:57:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06646 for ietf-msgtrk-bks; Tue, 15 Dec 1998 08:57:54 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA06642 for ; Tue, 15 Dec 1998 08:57:53 -0800 (PST) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Tue Dec 15 12:02:07 EST 1998 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Tue Dec 15 12:02:05 EST 1998 Received: from aleatory.research.bell-labs.com (aleatory.research.bell-labs.com [135.104.46.50]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA00046 for ; Tue, 15 Dec 1998 12:02:05 -0500 (EST) Received: (from dmk@localhost) by aleatory.research.bell-labs.com (8.8.6/8.8.6) id MAA22686 for ietf-msgtrk@imc.org; Tue, 15 Dec 1998 12:02:05 -0500 (EST) Date: Tue, 15 Dec 1998 12:02:05 -0500 (EST) From: Dave Kristol Message-Id: <199812151702.MAA22686@aleatory.research.bell-labs.com> To: ietf-msgtrk@imc.org Subject: simple problem statement Sender: owner-ietf-msgtrk@imc.org Precedence: bulk The WG session in Orlando was largely a rehash of the BOF session in Chicago. I had the following summary in my notes from Chicago, and I thought they might help the folks who will be revising the WG charter, problem statement, and requirements document. Dave Kristol ======================== How do you turn tracking on? If it's always on, there's a considerable cost throughout the network to track messages that no one may ever ask about. If you have to turn tracking on explicitly, which is much less resource-intensive, you'll probably always discover that you haven't asked for tracking for the message that got lost and that you therefore needed to track. When do you find out what happened? Is notification about the disposition of a message automatic, or do you have to ask what happened to it? In the latter case, how long should the tracking information be retained? (How much later can you ask about a message?) Whom do you ask? What is the protocol for querying about the disposition of a message? At what points along the message's delivery path can you get tracking information? (Can you query the hops within a company's internal email system?) Who is allowed to ask? What security is in place to ensure that only authorized parties can ask about the disposition of a message? How do you authenticate their identity? From owner-ietf-msgtrk Fri Jan 15 10:43:06 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23731 for ietf-msgtrk-bks; Fri, 15 Jan 1999 08:44:13 -0800 (PST) Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23700; Fri, 15 Jan 1999 08:43:43 -0800 (PST) Date: Fri, 15 Jan 1999 08:43:43 -0800 (PST) Message-Id: <199901151643.IAA23700@mail.proper.com> From: List Manager of ietf-msgtrk To: ietf-msgtrk@imc.org Subject: How to be removed from this list Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. Occasionally, people will sign up for a mailing list and forget how to be removed. This message is a reminder for those folks. First off, when you subscribe to a mailing list, you almost always get a first message from the list owner telling you about the mailing list, and explaining how to unsubscribe. It is always a good idea to keep those messages, since you never know when you will need to unsubscribe. This is particularly useful when you change email addresses, because it is difficult to unsubscribe from a list after you have a different mailing address. In the case of this list, the method to unsubscribe is to send a message to: ietf-msgtrk-request@imc.org with the single word: unsubscribe in the body of the message. This is the same as it always has been. To make this easier for you, I have crafted this message so that you should be able to simply reply to this message, and the reply address should be ietf-msgtrk-request@imc.org (although some mail clients screw this up...). Remove everything from the body of the reply, and put in the single word: unsubscribe If you have tried this method, and the mailing list software won't let you unsubscribe, it is probably because your address has changed. In that case, please send a message to subs@imc.org stating which list (or lists) you want to unsubscribe from, and what you think your previous address was. There is a human (that's me!) who will then try to take care of your request, often within a few days. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-msgtrk Tue Feb 9 07:04:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07083 for ietf-msgtrk-bks; Tue, 9 Feb 1999 07:04:57 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA07079 for ; Tue, 9 Feb 1999 07:04:56 -0800 (PST) From: Ken_Lin/SSW/Lotus@LOTUS.COM Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA23842 for ; Tue, 9 Feb 1999 10:15:37 -0500 (EST) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA14450 for ; Tue, 9 Feb 1999 10:05:54 -0500 (EST) Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 hotfix 1 (767.1 12-15-1998)) id 85256713.0053F66F ; Tue, 9 Feb 1999 10:17:05 -0500 X-Lotus-FromDomain: LOTUS@MTA To: ietf-msgtrk@imc.org Message-ID: <85256713.0053F3F4.00@mta2.lotus.com> Date: Tue, 9 Feb 1999 09:52:14 -0500 Subject: Message Tracking Session at 44th IETF? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Looking at http://www.ietf.org/meetings/agenda.txt, I don't see Message Tracking on the agenda. Does anyone know if one is planned? From owner-ietf-msgtrk Thu Mar 25 10:31:20 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03408 for ietf-msgtrk-bks; Thu, 25 Mar 1999 10:31:20 -0800 (PST) Received: from web201.mail.yahoo.com ([128.11.68.101]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03404 for ; Thu, 25 Mar 1999 10:31:18 -0800 (PST) Message-ID: <19990325184041.2545.rocketmail@web201.mail.yahoo.com> Received: from [128.11.68.102] by web201.mail.yahoo.com; Thu, 25 Mar 1999 10:40:41 PST Date: Thu, 25 Mar 1999 10:40:41 -0800 (PST) From: Tomorrow SystemsInc Subject: draft-jones-msgtrk-def-01.txt To: internet-drafts@ietf.org Cc: ietf-msgtrk@imc.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-846930886-922387241=:2426" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --0-846930886-922387241=:2426 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --0-846930886-922387241=:2426 Content-Type: text/plain; name="draft-jones-msgtrk-def-01.txt" Content-Description: draft-jones-msgtrk-def-01.txt Content-Disposition: inline; filename="draft-jones-msgtrk-def-01.txt" MSGTRK BOF G. Jones [TomorrowSys@yahoo.com] INTERNET-DRAFT B. Ernst [bruce_ernst@lotus.ssw.com] draft-jones-msgtrk-def-01.txt G. Vaudreuil [gregv@ons.octel.com] Expires: September 1999 Basic Definition of 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. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast). Abstract This document defines message tracking as a prelude to the creation of a message tracking model. Message tracking is a messaging management function; it provides the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. Definition Message tracking refers, in its simplest form, to determining the path an RFC822 message has taken, its current location, and its characteristics. Message tracking allows the originator of a message to issue a request about a previously sent message, the answer to which contains the delivery status, delivery time, delivered recipients, and other information about the message. This is different from the delivery status notification (DSN) function in use today, because DSNs are requested at the time of submission and are generated automatically; alternatively a tracking request is generated independently of the previously submitted message's status and is done so on demand. This capability is analogous to the service provided by carriers of conventional paper mail - the ability to quickly locate where a package is, and to determine whether or not the package has been delivered to its destination. An Internet-standard approach will allow development of message tracking applications that can operate in a multi-vendor messaging environment, and will encourage operation of the function across administrative boundaries. One might ask: why should there be a standard for message tracking when Internet domains will be unwilling to open themselves up to outside tracking requests ? This is one reason why we design and implement Internet standards. So that there is a reliable, secure, agreed upon mechanism for message tracking that people will be willing to use. Companies have implemented and are implementing message tracking today. Standardization of this technique will aid the Internet user community, make Internet messaging more profitable, and fulfill a key messaging management need. Reasons for Message Tracking Message tracking is useful for determining the whereabouts and status of "lost" messages, and for several other purposes: o When there is a lack of trust in the messaging system, such as when an originator claims a message failed to be delivered, the point of failure may be isolated. This includes messages that were never delivered or messages that were delivered incorrectly. Message tracking thus adds to the overall reliability of the mail system; o Per-message information can be used for accounting, billing, and performance purposes. Traffic can be itemized on a per-origin or per- destination basis by system or originator. This typically involves two steps - collection of message traffic data, followed by the gehe time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). o Message tracking information adds security in that the origins of potential security threats can be more precisely determined. If a system were flooded with traffic, for instance, the origin of this traffic would become known. Message tracking information is suitable for routine security audits containing the details of messaging traffic over specific time intervals; o End-to-end delivery time could be measured; o Message tracking would aid in message loop detection, since unique message identifiers of looping messages, when these exist, would be recorded multiple times; o Performance characteristics about the type of messaging traffic could be determined, such as when an inbound message causes the creation of multiple outbound messages, and the percentage of messages that were actually delivery reports or receipts. This is valuable for performance measurement, among other reasons; o Standardized message tracking information acts as a bridge between dissimilar messaging systems and dissimilar messaging communities; Tracking Messages on the Public Internet One might ask: why bother to track messages if a majority of public Internet traffic is point to point; messages don't live long enough to be trackable, and are not an interesting event to track since you always know the next point ? Just because you know where a message went that doesn't mean you know what happened to it, how fast it got there, or what was in it. As the Internet is used more and more for commercial/official purposes a logging function is commonly embedded in the messaging system internally. Even if most of the message traffic is point to point, this point-to-point traffic is inter-domain, across firewalls, and thus it is even more important to have a reliable tracking mechanism that organizations can agree on. It is something that intra-domain messaging users want. Even if 95% of transactions are point to point, the 5% that is non point-to-point is still a huge amount of traffic, and this is exactly the traffic that users will want to track. Once messaging traffic enters an intranet or domain of any size it invariably encounters a more hierarchical routing structure. Who is Allowed to Track Messages Only the originators of messages are allowed to track their messages. Optionally, an originator may delegate this responsibility to a third party, but this is left for future study. How Tracking is Done: Requests and Responses The originator will issue a message tracking request using the Unique Message Identifier plus security information. The originator (of both the message and the query at this point) will receive optional response criteria such as the message disposition, delivered recipients, delivery time, and the names of MTAs that handled the message. Security for Message Originators One option for message security is that the originator calculates a hash A to be equal to the hash of the message ID + time stamp + a per-user secret. The user then calculates hash B to be the hash of A. The user includes B in the submitted message, and retains A. Later, when the user makes a message tracking request to the messaging system or tracking entity, it submits A in the racking request. The entity receiving the tracking request then uses A to calculate B, since it was already provided B, verifying that the requestor is authentic. Summarily A = H(message ID + time stamp + secret) B = H(A) If the originator of a message were to delegate his or her tracking request to a third party by sending them A, this would be vulnerable to snooping over unencrypted sessions, but the user can decide on a message-by-message basis if this risk is acceptable. Three Possible Architectures There are ways of accomplishing message tracking without mandating the addition of large amounts of new infrastructure on the participants. Optionally, if more infrastructure is proven to be a good and necessary thing, it should be considered. In all cases, messages are only tracked from the time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). The three architectural alternatives offered by the start-up working group to date might be called "ask later", "ask now", and "ask someone else." Under "ask later", a user requests tracking as a service when submitting a message, and then at a later time issues a separate tracking request to the mail system. The user receives a response to the request from the tracking entity. This has the advantage of being deployable within the existing SMTP infrastructure. Under "ask now", a user requests tracking as a service while submitting a message, and receives a step-by-step report contemporaneously from each MTA that handles the message. This provides the user with a high level of service, but also causes extra overhead: an additional message generated for each hop the original message takes. Under "ask someone else", the user issues a separate message tracking request to an entity other than the messaging system at a later time. The user receives a response to the request from this same third-party tracking entity. This has the advantage of allowing tracking to occur when the messaging process has failed but the platform is still working. It also off-loads the tracking function from the messaging system itself. It may, however, require new infrastructure in order to support it. One possibility would be to implement "ask now" and "ask later" as SMTP extensions. One could implement "ask someone else" as a UDP- or TCP-based protocol, among other options. Acknowledgments Thanks to all those who participated in the message tracking meetings. Many thanks to Ned Freed and Harald Alvesrand for the hashing material. Internet Draft Expires September 1999 Internet Draft --0-846930886-922387241=:2426-- From owner-ietf-msgtrk Thu Apr 1 06:19:41 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA24078 for ietf-msgtrk-bks; Thu, 1 Apr 1999 06:19:41 -0800 (PST) Received: from web203.mail.yahoo.com (web203.mail.yahoo.com [128.11.68.103]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA24070 for ; Thu, 1 Apr 1999 06:19:40 -0800 (PST) Message-ID: <19990401141850.27695.rocketmail@web203.mail.yahoo.com> Received: from [207.155.215.68] by web203.mail.yahoo.com; Thu, 01 Apr 1999 06:18:50 PST Date: Thu, 1 Apr 1999 06:18:50 -0800 (PST) From: Tomorrow SystemsInc Subject: Forwarded Comments from Chris Newman To: ietf-msgtrk@imc.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1804289383-922976330=:27569" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --0-1804289383-922976330=:27569 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note: forwarded message attached. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --0-1804289383-922976330=:27569 Content-Type: message/rfc822 X-Apparently-To: tomorrowsys@yahoo.com via mdd201.mail.yahoo.com Received: from thor.innosoft.com (192.160.253.66) by mta113.yahoomail.com with SMTP; 31 Mar 1999 22:32:49 -0800 Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01J9HMZQNR6W8WWDLI@INNOSOFT.COM> for TomorrowSys@yahoo.com; Wed, 31 Mar 1999 18:23:25 PST Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0F9H00A01NWA9O@elvira.innosoft.com> for TomorrowSys@yahoo.com; Wed, 31 Mar 1999 18:21:47 -0800 (PST) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0F9H007IHNWAPY@elvira.innosoft.com>; Wed, 31 Mar 1999 18:21:46 -0800 (PST) Date: Wed, 31 Mar 1999 18:23:00 -0800 (PST) From: Chris Newman Subject: draft-jones-msgtrk-def-01.txt Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: TomorrowSys@yahoo.com, bruce_ernst@lotus.ssw.com, gregv@ons.octel.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Content-Length: 2923 I just read your draft. You may forward these comments to the msgtrack list, but I don't have time to follow this work closely. I'm dubious of the requirement to know the path the message took. The primary need for this is to find out where the message _is_. Now it may be easy to also supply path information, but it shouldn't be a design goal, IMHO. Your security proposal has a flaw -- if you use a secret, you should use HMAC (RFC 2104) so: A = HMAC(message ID + time stamp, secret) B = H(A) I also think you could do much better while still only using hash-based operations. The problem with your proposed algorithm is that once you've issued a request for tracking information that request is subject to replay and dictionary attack. Further, if someone sees the message, it is subject to a simple dictionary attack since they know the Message ID and can guess the timestamp so the secret can probably be found given a couple messages. Here's an alternate proposal (simplified version of draft-newman-auth-scram-03.txt). MID -- Message-ID gennonce -- a one-time random nonce which the client keeps with the message ID but never sends over the wire. Gennonces shouldn't occur in a guessable sequence. cnonce -- client-generated unique nonce snonce -- server-generated unique nonce salt -- a salting factor, considered to be public. Similar to the 2-char salt in Unix /etc/passwd, but should be longer. A = HMAC(MID, secret + gennonce) B = H(A) C = H(B) D = HMAC(MID, A) In the message: C, D, MID Client keeps per-message: gennonce, MID User knows: secret Authentication handshake over interactive TCP: C: MID, cnonce S: snonce, server-name C: B XOR HMAC(MID + cnonce + snonce + server-name, C) server verifies client by checking that: H(client-message XOR HMAC(MID + cnonce + snonce + server-name, C)) is equal to "C". server proves it's seen the message with: S: HMAC(MID + cnonce + snonce + salt + server-name, D) Advantages: * TCP-session's use of cnonce and snonce prevent replay attacks and precomputed dictionary attacks. * the server can't lie about a message if it hasn't seen it. * spoof-server/eavesdropper doesn't gain ability to track the message * separation of "gennonce" and "secret" provides a clear per-message secret and a per-user secret (password). If the per-message secret is binary and the combination sufficiently large, dictionary attacks aren't feasible unless "gennonce" leaks. * In previous proposal, any reuse of "secret" would mean an eavesdropper of one tracking request could track all messages which used that secret. ---- I should also note that draft-newman-deliver-02.txt currently in IETF last call, implements the "ask now" facility (unauthenticated) as a side-effect of its primary purpose. This was quite popular at the mailrev BOF where it was reviewed. - Chris --0-1804289383-922976330=:27569-- From owner-ietf-msgtrk Thu Apr 1 13:20:52 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03488 for ietf-msgtrk-bks; Thu, 1 Apr 1999 13:20:52 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03484 for ; Thu, 1 Apr 1999 13:20:51 -0800 (PST) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id FAA32459 for ; Fri, 2 Apr 1999 05:29:35 -0700 From: Steve Hole Date: Thu, 1 Apr 1999 14:21:54 -0700 To: ietf-msgtrk@imc.org Subject: Restarting the Message Tracking working group Message-ID: X-Mailer: Execmail for Motif Version 5.0.1 Beta 1 Build (44) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have been asked by Keith Moore and Patrik Faltstrom to take over as working group chair for the message tracking working group. To kick that off I am sending a series of messages that deal with administative issues for the working group and some focus bits to get the discussion going again. I tried to break each of the major things into a separate message so that separate (and hopefully focused) threads can develop on each of them. No pun intended :-) Cheers. --- Steve Hole Execmail Inc. Mailto:Steve.Hole@execmail.com Phone: 780-424-4922 From owner-ietf-msgtrk Thu Apr 1 15:47:23 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA04906 for ietf-msgtrk-bks; Thu, 1 Apr 1999 15:47:23 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA04902 for ; Thu, 1 Apr 1999 15:47:22 -0800 (PST) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id HAA00328 for ; Fri, 2 Apr 1999 07:56:14 -0700 From: Steve Hole Date: Thu, 1 Apr 1999 16:48:32 -0700 To: IETF Message Tracking Working Group Subject: A quick review of the charter Message-ID: X-Mailer: Execmail for Motif Version 5.0.1 Beta 1 Build (44) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is the text from the charter specifying what work is to be done. This is simply provided for review by the working group to make sure that subsequent discussions are focused on the stated goals for the working group. --- Description of Working Group: The Message Tracking Working Group will design a diagnostic protocol for a message originator to request information about the submission, transport, and delivery of a message regardless of its delivery status. The group will produce two standards track documents: a message tracking model document and a protocol document. The model will state how message tracking is enabled, identify the entities involved, define how and when message tracking requests are issued and answered, define approaches for inter-domain message tracking, and address security issues. The submission, transport, and delivery of RFC 822bis messages will be tracked from the time such messages enter the messaging network up until the time they are discharged (e.g. to an IMAP server, to an end-user's mailbox, or a proprietary mail system). --- I don't personally see any reasons to change this. Changing it at all would be very difficult and require review by the IESG. --- Steve Hole Execmail Inc. Mailto:Steve.Hole@execmail.com Phone: 780-424-4922 From owner-ietf-msgtrk Thu Apr 1 16:15:22 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05307 for ietf-msgtrk-bks; Thu, 1 Apr 1999 16:15:22 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05303 for ; Thu, 1 Apr 1999 16:15:21 -0800 (PST) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA00405 for ; Fri, 2 Apr 1999 08:24:16 -0700 From: Steve Hole Date: Thu, 1 Apr 1999 17:16:35 -0700 To: IETF Message Tracking List Subject: Proposed schedule changes Message-ID: X-Mailer: Execmail for Motif Version 5.0.1 Beta 1 Build (44) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Following is a change to the schedule proposed in the original charter. Beyond simply pushing the dates back, I also made some changes to the ordering of events. Changes were based on hallway discussion held in Minneapolis. If I don't hear anything back on this issue within a week I will submit the new schedule to the AD's for approval and update to the existing charter. Goals and Milestones as represented in current charter: Nov 98 - Post an Internet Draft of the message tracking model Nov 98 - Post revised draft of message tracking model Dec 98 - Meet at Orlando IETF to discuss I-Ds Jan 99 - Post final draft of model, post Internet Draft of protocol Feb 99 - Post revised draft of protocol Mar 99 - Meet at 44th IETF May 99 - Post final draft of protocol Proposed new Goals and Milestones: Jun 1998 - Post initial ID defining message tracking model Jul 1998 - Meet at Oslo IETF to discuss model ID Aug 1998 - Post revised ID defining message tracking model Sep 1999 - Post initial ID defining message tracking protocol Nov 1999 - Meet at Washington IETF to discuss model and protocol IDs Feb 2000 - Post final ID defining message tracking model Feb 2000 - Post revised ID defining message tracking protocol Mar 2000 - Meet at Adelaide IETF to discuss protocol ID May 2000 - Post final ID defining message tracking protocol Cheers. --- Steve Hole Execmail Inc. Mailto:Steve.Hole@execmail.com Phone: 780-424-4922 From owner-ietf-msgtrk Thu Apr 1 16:41:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05626 for ietf-msgtrk-bks; Thu, 1 Apr 1999 16:41:03 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05622 for ; Thu, 1 Apr 1999 16:41:01 -0800 (PST) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA00444 for ; Fri, 2 Apr 1999 08:49:56 -0700 From: Steve Hole Date: Thu, 1 Apr 1999 17:42:12 -0700 To: ETF Message Tracking Working Group Subject: Model document authors Message-ID: X-Mailer: Execmail for Motif Version 5.0.1 Beta 1 Build (44) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The following message reflects the fact that I don't really know some of the original folks in this working group. I apologize for not knowing first names and such. I am starting this bit as if I know nothing about any of the folks involved -- which is almost true. The first deliverable for the working group is document that describes the architectural model for a messaging tracking system. A document has been created by the original core participants in the working group: G. Jones [TomorrowSys@yahoo.com] B. Ernst [bruce_ernst@lotus.ssw.com] G. Vaudreuil [gregv@ons.octel.com] An (updated I believe) draft has recently been submitted by G. Jones which reflects the work that was done earlier in the working group. It is not clear that all of the original authors are still participating in the working group. If possible I would like to hear from the authors and/or designated replacements. In Minneapolis, Tony Hansen from ATT and Ken Lin from Lotus volunteered to work as document editors. My understanding is that Ken Lin is the designated replacement for B. Ernst from Lotus. Two issues: 1. Could the various authors listed on the draft please contact me with new email addresses and an indication on their willingness to continue. 2. We seem to have lots of folks who want to participate in the authoring of the model document. I would really like to see one chief-in-charge author who is on the hook for delivering the document. Others can contribute and share the by-line if that is important but I think that we really want an owner. It would be a good thing to have this set of issues resolved by the end of next week. Cheers. --- Steve Hole Execmail Inc. Mailto:Steve.Hole@execmail.com Phone: 780-424-4922 From owner-ietf-msgtrk Thu Apr 1 16:48:18 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05726 for ietf-msgtrk-bks; Thu, 1 Apr 1999 16:48:18 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05722 for ; Thu, 1 Apr 1999 16:48:17 -0800 (PST) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA00452 for ; Fri, 2 Apr 1999 08:57:12 -0700 From: Steve Hole Date: Thu, 1 Apr 1999 17:49:31 -0700 To: ETF Message Tracking Working Group Subject: Fwd: thoughts on message tracking models Message-ID: X-Mailer: Execmail for Motif Version 5.0.1 Beta 1 Build (44) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This message from Tony Hansen nicely summarizes some of the hallway discussion in Minneapolis. Note that the conversation resulted from queries at the general apps area meeting about the status of message tracking, where it was going etc. There are many participants who were not present and this certainly goes over some things that have been discussed already (presumably). I would like to take the approach that we are hitting the "reset" button on the working group. As such, this and the draft serve as a basis point for discussion on the model. If we find that we have good concensus on the model, then this should go quickly. As I don't have good evidence either way, I'll presume that we need to review everything and make sure that we are in good standing before moving on. I'll post my own thoughts on this later this evening. Cheers. --- Begin Forwarded Message --- Date: Wed, 17 Mar 1999 22:40:22 -0500 From: Tony Hansen Subject: thoughts on message tracking models Sender: Tony Hansen To: Steve.Hole@execmail.com, Ken_Lin@lotus.com Reply-To: Tony Hansen Message-ID: <36F075A6.6D66A13@att.com> I wanted to capture some of our conversations regarding message tracking and subsequent thoughts I've had on the topic. This can probably form the genesis of a model document. Message Tracking Models There are a number of dimensions across which the message tracking solution space can be split: How is message tracking enabled? Tracking is automatically done for all messages using information extracted from the message header and body. A request to enable tracking is carried within the envelope, e.g., an ESMTP extension request would indicate that tracking should occur. A request to enable tracking is carried within the message, e.g., a special header. How is the information gathered? The information is sent back to the user, e.g., using email messages similar to DSNs and MDNs. The information is transmitted by each MTA to a third party (identified somehow) using some sort of protocol. The information is kept locally to each MTA server or set of servers. What message transitions will cause message tracking to be declared finished? Deposit into a mailbox. Crossing a firewall? Forwarded by an MTA as specified by a user? Forwarded by a sieve filter? Sent on by a reflector list exploder? Sent on by a mailing list exploder? How is information gathered by a tracking client? In the case of DSN/MDN-like messages being sent back to the user, it's automatic. An ESMTP extension would provide a new verb to query message tracking instead of sending a new message. A new TCP protocol would provide a way of querying message tracking. A new UDP protocol would provide a way of querying message tracking. How are hops from one machine to another handled? The server on one machine queries the next machine in the list before returning info. (forwarding) The server provides information on the next machine and the tracking client queries the next machine. (referral) What format should the information be provided in? key: value DSN XML Is information from DSNs and MDNs merged in with tracking information by the tracking client? What information is reported? time of entry time of delivery time (queued for exit | exited) time (queued for exit | exited to tracking host | exited to non-tracking host) system exited to Are MX names or A names recorded? How is authentication of a tracking requester done? various token exchange / validation schemes exist --- End Forwarded Message --- --- Steve Hole Execmail Inc. Mailto:Steve.Hole@execmail.com Phone: 780-424-4922 From owner-ietf-msgtrk Tue Apr 13 08:53:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14428 for ietf-msgtrk-bks; Tue, 13 Apr 1999 08:53:14 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14424 for ; Tue, 13 Apr 1999 08:53:12 -0700 (PDT) From: Ken_Lin/SSW/Lotus@LOTUS.COM Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id MAA14803 for ; Tue, 13 Apr 1999 12:01:56 -0400 (EDT) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA23773 for ; Tue, 13 Apr 1999 11:50:25 -0400 (EDT) Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256752.00580909 ; Tue, 13 Apr 1999 12:01:34 -0400 X-Lotus-FromDomain: LOTUS@MTA To: ietf-msgtrk@imc.org Message-ID: <85256752.005808D4.00@mta2.lotus.com> Date: Tue, 13 Apr 1999 11:49:22 -0400 Subject: Re: Model document authors Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: You are correct, Bruce Ernst will no longer be participating. I will be continuing in his absence. From owner-ietf-msgtrk Wed May 26 07:21:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01081 for ietf-msgtrk-bks; Wed, 26 May 1999 07:21:35 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01073 for ; Wed, 26 May 1999 07:21:33 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id WAA08000 for ; Wed, 26 May 1999 22:32:57 -0600 From: Steve Hole Date: Tue, 25 May 1999 23:20:54 -0600 To: IETF Messaging Tracking List Subject: Official document authors Message-ID: X-Mailer: Execmail for Win32 Version 5.0.2 Beta 1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The winners in the document author pool are Ken Lin from Lotus and Tony Hansen from ATT. They will be working initially on the model document. We may choose different author(s) for the protocol specification work. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk Wed May 26 07:21:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01082 for ietf-msgtrk-bks; Wed, 26 May 1999 07:21:35 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01074 for ; Wed, 26 May 1999 07:21:33 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id WAA07997; Wed, 26 May 1999 22:32:57 -0600 From: Steve Hole Date: Tue, 25 May 1999 23:17:25 -0600 To: IETF Message Tracking List Subject: Moving the working group forward Cc: Keith Moore Message-ID: X-Mailer: Execmail for Win32 Version 5.0.2 Beta 1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: It is clear that this working group suffers from an extreme lack of interest. Either people are too busy or the topic is not important enough to get any of its own inertia. So, I feel compelled to take (drastic??) action. I propose the following: 1. I wish to form a "design team" that is responsible for doing research, strawman requirements proposals, strawman protocols designs etc. The goal is to get concrete proposals on the table that the working group can then work with a as starting point in discussion. 2. I propose to convene the first meeting of the design team in Oslo. The goals for the Oslo meeting are: - refine the requirements section of the model - define at least two model options that can be discussed on the mailing list and/or subsequent meetings - define a "solution space" for the models described above Note that I am proposing to discuss potential solutions when the problem is not completely scoped. I had hoped (as had many others) that we would get a clear problem statement out before doing anything on the solution side, but I fear that this has stifled productive engineering conversation. When I say "solution space", I mean a "set of possible solutions that seem to apply to the models that we define". Nothing written in stone, just some things that we can frame the discussion around. 3. Make up the design team based upon the following criteria: - level of interest in the subject - experience in IETF process - experience with implementations/designs that currently address all or part of the problem - expects to attend IETF meetings - has some time to contribute I'm going to ask a few individuals based upon their demonstrated knowledge in messaging in general, but am willing to consider anyone in the working group who feels they meet some or all of the criteria above. I'm not going to be too fussy here. I'd like to keep the size to < 10 members, but I'm not too worried about that :-) I'll send out private messages to those people who I explicitly would like to solicit for this job. Anyone who is interested can send me mail immediately to toss in their hat. Missing Oslo is not a disqualifier. I hope that we can get enough together to do some damage. 4. Solicit people to post intentionally provocative messages that offend people to the point where they feel they MUST reply. It seemed to work for DRUMS! Just KIDDING Keith. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk Fri Jun 11 15:26:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA12880 for ietf-msgtrk-bks; Fri, 11 Jun 1999 15:26:19 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA12876 for ; Fri, 11 Jun 1999 15:26:18 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id QAA23307; Fri, 11 Jun 1999 16:27:36 -0600 From: Steve Hole Date: Fri, 11 Jun 1999 16:27:36 -0600 To: Ken Lin/SSW/Lotus Subject: Re: MsgTrk WG is not listed in http://www.ietf.org/meetings/agenda.txt Cc: ietf-msgtrk@imc.org Reply-To: Steve Hole Message-ID: X-Mailer: Execmail for Motif 5.0.2 b1 Build (55) -- UNLICENSED Demonstration Copy MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET="us-ascii" Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I included the list in the response, because there have been a few questions asked of me in private. Killing birds ... On Tue, 08 Jun 1999 17:21:37 GMT Ken Lin/SSW/Lotus wrote: > I assume the WG meeting in Oslo is still planned but just hasn't made it > onto http://www.ietf.org/meetings/agenda.txt yet? There will not be a formal working group meeting. Rather there will be a design team meeting that is informal and much smaller. There seems to be no point to having a large group sit through a meeting where there is no work to report on. Keith is trying to get a smaller room for us with (hopefully) a whiteboard in it. > As I think I previously mentioned, I will be away from mid-June through > mid-July so I will not be able to attend Oslo. robert_miles@lotus.com will > be attending this meeting in my place. That's too bad, but I'm glad that someone else can attend. Nick also indicated that he would be able to attend. I will announce the intent for a design team meeting at the application area meeting at the start of the week and any logistical items can be handled at that time. > I haven't heard from anyone on how we will proceed with the model document, > perhaps one of you can get back to me before June 16 when I will be away. The focus for the design team meeting in Oslo will be to come up with a process for getting the model document together. I hope that we can get some good work on the model document itself at the same time. We will have to take all proposals to the list subsequently, but a good solid set of proposals is crucial. There is just no momentum to this work right now and I think a focus group can get that going. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk Fri Jul 16 01:37:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA11845 for ietf-msgtrk-bks; Fri, 16 Jul 1999 01:37:17 -0700 (PDT) Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA11841 for ; Fri, 16 Jul 1999 01:37:16 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id EAA23653 for ; Fri, 16 Jul 1999 04:38:02 -0400 (EDT) Received: from att.com (secure.research.att.com[135.207.25.14](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990716083559un100992mbe>; Fri, 16 Jul 1999 08:35:59 +0000 Message-ID: <378EEF18.8DD0E700@att.com> Date: Fri, 16 Jul 1999 04:36:40 -0400 From: Tony Hansen X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-msgtrk@imc.org Subject: MSGTRK IETF45 design session meeting notes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Meeting Notes Message Tracking (msgtrk) Working Group Model Design Session IETF 45, July 13, 1999 Steve Hole (chair) ietf-msgtrk[-request]@imc.org Please send corrections and additions to the list. (+ lines show original text from slides) (Robert Miles, from Lotus, shared his notes with me. His contributions are gratefully accepted.) + Administrivia + History: The original leaders have moved off, so we're doing a full reset on the schedule. + Current state of the union: Steve Hole has taken over as WG chair + Why a design meeting? Today's meeting is a design meeting; no milestones will be addressed at this meeting, but will be addressed on the list. + Notifications of patents Lotus has a patent pending on "message tracking", but we think it's restricted to message tracking using via "SNMP". Issue: We need to know the boundaries of the Lotus patent application and the WG needs to make sure that it's designs are in a different space. + Scope for this Meeting + intended to get the WG moving - accept controversy + open discussion within the framework of objectives + Steve will represent the existing work + Steve reserves the right to call a rathole on any issue +Not in Scope for the meeting + charter milestone reassessment this obviously must be done, but will be done on the list. + Objectives for the Meeting + 1) define an owner author for the doc the model design document + 2) gain direction for the document authors + 3) initiate other design (breakout) sessions e.g., bar BOFs + 4) sanity check on whether to continue at all + 5)