From owner-ietf-msgtrk@mail.imc.org Tue Jul 11 13:05:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09567 for ; Tue, 11 Jul 2000 13:05:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20506 for ietf-msgtrk-bks; Tue, 11 Jul 2000 09:54:08 -0700 (PDT) Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20494 for ; Tue, 11 Jul 2000 09:54:05 -0700 (PDT) Received: from jean-baptiste.sendmail.org (natted.Sendmail.COM [63.211.143.38]) by knecht.Sendmail.ORG (8.10.0/8.10.1) with ESMTP id e6BGtwY00613 for ; Tue, 11 Jul 2000 09:55:58 -0700 (PDT) Received: from jean-baptiste.sendmail.org (localhost.sendmail.org [127.0.0.1]) by jean-baptiste.sendmail.org (Switch-2.0.0/Switch-2.0.0) with ESMTP id e6BGt7o00894 for ; Tue, 11 Jul 2000 09:55:08 -0700 (PDT) Message-Id: <200007111655.e6BGt7o00894@jean-baptiste.sendmail.org> X-Mailer: exmh version 2.1.2 06/08/2000 To: ietf-msgtrk@imc.org From: Eric Allman X-URL: http://WWW.Sendmail.ORG/~eric Subject: MSGTRK pre-drafts Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_10298066860" Date: Tue, 11 Jul 2000 09:55:07 -0700 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message. --==_Exmh_10298066860 Content-Type: text/plain Enclosed are two "pre-drafts" -- they really aren't up for draft status yet, but I did want folks here get a glimpse of where they are going. eric --==_Exmh_10298066860 Content-Type: text/plain ; name="draft-ietf-msgtrk-smtpext.txt" Content-Description: draft-ietf-msgtrk-smtpext.txt Content-Disposition: attachment; filename="draft-ietf-msgtrk-smtpext.txt" Internet Draft E. Allman draft-ietf-msgtrk-smtpext-00.txt Sendmail, Inc. Valid for six months July XXX, 2000 SMTP Service Extension for Message Tracking Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 This document is a submission by the MSGTRK Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the msgtrk@imc.org mailing list. An archive of the mailing list may be found at http://www.ietf.org/archive/msgtrk Distribution of this memo is unlimited. 11.. AAbbssttrraacctt This memo defines an extension to the SMTP service whereby a client may query an SMTP server for the status of a message. 22.. IInnttrroodduuccttiioonn 22..11.. GGooaallss 22..22.. OOtthheerr ddooccuummeennttss draft-ietf-msgtrk-model-01.txt draft-ietf-msgtrk-trkstat-01.txt DSN MDN RFC 1894 AAllllmmaann [[PPaaggee 22]] IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 22..33.. CCoonnffoorrmmaannccee The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 33.. SSMMTTPP EExxtteennssiioonn OOvveerrvviieeww The Message Tracking SMTP service extension uses the SMTP ser- vice extension mechanism described in [XXX]. The following service extension is hereby defined: (1) The name of the SMTP service extension is "Message Track- ing". (2) The EHLO keyword value associated with this extension is "MTRK". (3) No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying options. XXX Should we indicate the maximum amount of time this server is willing to hold tracking info? (4) One optional parameter using the keyword "MTRK" is added to the MAIL FROM command. In addition, the ENVID parameter (as defined in RFC 1891 section 5.4) must be supported, with extensions as described below. AAllllmmaann [[PPaaggee 33]] IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 (5) The maximum length of a MAIL FROM command line is increased by XXX characters by the possible addition of the MTRK key- word and value. (6) One additional SMTP verb "MTRK" is defined by this exten- sion. 33..11.. TThhee MMeessssaaggee TTrraacckkiinngg SSMMTTPP SSeerrvviiccee EExxtteennssiioonn 33..22.. XXXXXX aannyy mmooddeell iinnffoo wwee nneeeedd 44.. TThhee EExxtteennddeedd MMAAIILL FFRROOMM CCoommmmaanndd The extended MAIL FROM command is issued by an SMTP client when it wishes to inform an SMTP server that message tracking information should be retained for a specified period. The extended MAIL FROM command is identical to the MAIL FROM command as defined in RFC 821 [XXX], except that a MTRK parameter appears after the address. 44..11.. TThhee MMTTRRKK ppaarraammeetteerr ttoo tthhee EESSMMTTPP MMAAIILL ccoommmmaanndd Any sender wishing to track a message must tag that message as trackable using the MTRK parameter to the MAIL FROM command. This parameter has the following syntax: mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ] mtrk-certifier = base64 ; authenticator mtrk-timeout = 1*9digit ; seconds until timeout XXX need to import base64 from somewhere AAllllmmaann [[PPaaggee 44]] IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 The mtrk-timeout field indicates the number of seconds until this tracking information will time out. Servers MAY ignore this value if it violates local policy. [XXX see draft- newman-deliver-03 for an explanation of why TTL instead of abso- lute time] The mtrk-certifier field is stored in the tracking database and used to authenticate future tracking requests. XXX Need expansion. 44..22.. UUssee ooff EENNVVIIDD To function properly, Message Tracking requires that each message have a unique identifier that is never reused by any other message. For that purpose, if the MTRK parameter is given, an ENVID parameter MUST be included, and the syntax of ENVID from RFC 1891 section 5.4 is extended as follows: envid-parameter = "ENVID=" unique-envid unique-envid = xtext "@" fqhn fqhn = xtext Any retransmissions of this message MUST assign a new ENVID. XXX define retransmission 55.. MMTTRRKK CCoommmmaanndd The MTRK ESMTP command is used to request tracking status information for a message that has previously been processed. AAllllmmaann [[PPaaggee 55]] IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 55..11.. CCoommmmaanndd ssyynnttaaxx The syntax of the MTRK command is: mtrk-command = "MTRK" LWSP unique-envid LWSP mtrk-authenticator mtrk-authenticator = base64 The unique-envid corresponds to a message that may have been previously seen by this MTA. The mtrk-authenticator validates the rights of this sender to request tracking information for the indicated unique-envid. 55..22.. CCoommmmaanndd sseemmaannttiiccss The MTRK command behaves as follows: (1) The indicated unique-envid is looked up in the local mes- sage tracking database. If that key is not found, the receiving MTA MUST immediately return a "no information" 5XXX response. (2) If the unique-envid is found in the database, the stored mtrk-certifier is compared against the transmitted mtrk- authenticator by computing the hash of the unique-envid concatenated with the mtrk-authenticator and comparing that to the stored mtrk-certifier. If these do not match, the sending MTA has not provided the correct mtrk- authenticator, and the receiving MTA MUST immediately return a "no information" 5XXX response. AAllllmmaann [[PPaaggee 66]] IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000 (3) If the certification phase succeeds, the receiving MTA returns a response as described below. 66.. RReessppoonnssee ssyynnttaaxx The response syntax obeys standard SMTP response syntax. Each line of response is prefixed with "250-2.5.6" (XXX the new 2.5.6 code must be standardized). The content of the response is the body of a message/tracking- status as defined in draft-ietf-msgtrk-trkstat-00. XXX Side comment: I notice that 2034 doesn't exempt EXPN and VRFY from enhanced status codes. This makes them potentially non- parseable. This may not be a problem. 77.. EExxppiirriinngg SSttaattuuss IInnffoorrmmaattiioonn Most hosts will want to expire tracking status information after some amount of time. When a sending MTA requests that mes- sage tracking information be kept, it may optionally ask for a spe- cific timeout. 88.. SSeeccuurriittyy IIssssuueess XXX who can track a message Once a message is tracked, someone can sniff and re-use AAllllmmaann [[PPaaggee 77]] --==_Exmh_10298066860 Content-Type: text/plain ; name="draft-ietf-msgtrk-trkstat.txt" Content-Description: draft-ietf-msgtrk-trkstat.txt Content-Disposition: attachment; filename="draft-ietf-msgtrk-trkstat.txt" Internet Draft E. Allman draft-ietf-msgtrk-trkstat-00.txt Sendmail, Inc. Valid for six months July XXX, 2000 The Message/Tracking-Status MIME Extension Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 This document is a submission by the MSGTRK Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the msgtrk@imc.org mailing list. An archive of the mailing list may be found at http://www.ietf.org/archive/msgtrk Distribution of this memo is unlimited. 11.. AAbbssttrraacctt This memo defines a MIME type for message tracking in the same spirit as RFC 1894, ``An Extensible Message Format for Delivery Status Notifications''. It is to be used in conjunction with draft-ietf-msgtrk-smtpext-01.txt. 22.. IInnttrroodduuccttiioonn This memo defines a MIME [XXX] content-type for reporting mes- sage tracking status information. A tracking status is issued to a requestor upon request. This memo defines only the format of the status information. An extension to SMTP [XXX] to label messages for further tracking and request tracking status is defined in a separate memo [XXX]. 22..11.. GGooaallss Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications [XXX]; generally, AAllllmmaann [[PPaaggee 22]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 a message tracking request will be issued only when a DSN has not been received within a reasonable timeout period. 22..22.. OOtthheerr ddooccuummeennttss draft-ietf-msgtrk-model-01.txt RFC 1894. Sections 1.3 (Terminology), 2.1.1 (General con- ventions for DSN fields), 2.1.2 ("*-type" subfields), 2.1.3 (Lexical tokens imported from RFC 822), 2.2.2 (The Reporting-MTA DSN field), 2.3.5 (Remote-MTA field), and 2.XXX of RFC 1894 are included by reference. DSN MDN RFC 2119. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to bbe interpreted as described in RFC 2119 [RFC-KEYWORDS]. 33.. FFoorrmmaatt ooff aa MMeessssaaggee TTrraacckkiinngg SSttaattuuss NNoottiiffiiccaattiioonn A MTSN can be returned as the body of an MTRK reply, or as a subtype of a MIME message with a top-level content type of multi- part/report (defined in [XXX]). When a multipart/report content is used to transmit a MTSN: (a) The report-type parameter of the multipart/report content is "tracking-status". AAllllmmaann [[PPaaggee 33]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 (b) The first component of the multipart/report contains a human- readable explanation of the MTSN, as described in [XXX]. (c) The second component of the multipart/report is of content- type message/tracking-status, as defined in this document. (d) If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. 33..11.. TThhee mmeessssaaggee//ttrraacckkiinngg--ssttaattuuss ccoonntteenntt--ttyyppee The message/tracking-status content-type is defined as fol- lows: MIME type name: message MIME subtype name: tracking-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when views by non-MIME mail readers. Security considerations: discussed in section XXX of this memo. The message/tracking-status report type for use in the multi- part/report is "tracking-status". The body of a message/tracking-status is modeled after RFC 1894, "An Extensible Message Format for Delivery Status Notifi- cations". The body of a message/tracking-status consists of one or more "fields" formatted to according to the ABNF of RFC 822 headers "fields" (see [XXX]). The per-message fields apear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each AAllllmmaann [[PPaaggee 44]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 group of per-recipient fields is preceded by a blank line. Using the ABNF of RFC 822, the syntax of the message/tracking- status content is as follows: tracking-status-content = per-message-fields 1*( CRLF per-recipient-fields ) The per-message fields are described in section XXX. The per- recipient fields are described in section XXX. 33..11..11.. GGeenneerraall ccoonnvveennttiioonnss ffoorr MMTTSSNN ffiieellddss Section 2.1.1 of RFC 1894 (General conventions for DSN fields) is included herein by reference. Notably, the defi- nition of xtext is identical to that of RFC 1894. 33..11..22.. **--ttyyppee ssuubbffiieellddss Section 2.1.2 of RFC 1894 (*-type subfields) is included herein by reference. Notably, the definitions of address- type, diagnostic-type, and MTA-name type are identical to that of RFC 1894. 33..11..33.. LLeexxiiccaall ttookkeennss iimmppoorrtteedd ffrroomm RRFFCC 882222 The following lexical tokens, defined in [XXX], are used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [XXX]. AAllllmmaann [[PPaaggee 55]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 33..22.. PPeerr--MMeessssaaggee MMTTSSNN FFiieellddss Some fields of an MTSN apply to all of the addresses in a single envelope. These fields may appear at most once in any MTSN. These fields are used to correlate the MTSN with the original message transaction and to provide additional informa- tion which may be useful to gateways. per-message-fields = [ original-envelope-id-field CRLF ] reporting-mta-field CRLF [ arrival-date CRLF ] *( extension-field CRLF ) 33..22..11.. TThhee OOrriiggiinnaall--EEnnvveellooppee--IIdd ffiieelldd The optional Original-Envelope-Id field is defined as in section 2.2.1 of RFC 1894. 33..22..22.. TThhee RReeppoorrttiinngg--MMTTAA ffiieelldd The Reporting-MTA field is defined as in section 2.2.2 of RFC 1894. 33..22..33.. TThhee AArrrriivvaall--DDaattee ffiieelldd The Arrival-Date field is defined as in section 2.2.5 of RFC 1894. 33..33.. PPeerr--RReecciippiieenntt MMTTSSNN ffiieellddss An MTSN contains information about attempts to deliver a message to one or more recipients. The delivery information for AAllllmmaann [[PPaaggee 66]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line. The syntax for the group of per-recipient fields is as fol- lows: per-recipient-fields = [ original-recipient-field CRLF ] final-recipient-field CRLF action-field CRLF status-field CRLF [ remote-mta-field CRLF ] [ last-attempt-date-field CRLF ] [ will-retry-until-field CRLF ] *( extension field CRLF ) 33..33..11.. OOrriiggiinnaall--RReecciippiieenntt ffiieelldd Section 2.3.1 XXX 33..33..22.. FFiinnaall--RReecciippiieenntt ffiieelldd 2.3.2 XXX 33..33..33.. AAccttiioonn ffiieelldd The Action field indicates the action performed by the Reporting-MTA as a result of its attempt to delivery the mes- sage to this recipient address. This field MUST be present for each recipient named in the MTSN. The syntax is as defined in section 2.3.3 of RFC 1894. XXX Do we want to have a "waiting for pickup" action? AAllllmmaann [[PPaaggee 77]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 33..33..44.. SSttaattuuss ffiieelldd The Status field is defined as in RFC 1894 section 2.3.4. A new code is added to RFC 1893, "Enhanced Mail System Status Codes", X.1.9 Message relayed to non-compliant mailer" The mailbox address specified was valid, but the mes- sage has been relayed to a system that does not speak this protocol; no further information can be pro- vided. 33..33..55.. RReemmoottee--MMTTAA ffiieelldd Reference 2.3.5 XXX 33..33..66.. LLaasstt--AAtttteemmpptt--DDaattee ffiieelldd Reference 2.3.7 XXX 33..33..77.. WWiillll--RReettrryy--UUnnttiill ffiieelldd Reference 2.3.8 XXX 33..44.. EExxtteennssiioonn ffiieellddss Reference 2.4 XXX 33..55.. DDiiffffeerreenncceess ffrroomm RRFFCC 11889944 AAllllmmaann [[PPaaggee 88]] IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000 Original-Envelope-Id keep Reporting-MTA keep DSN-Gateway relevant? Received-From-MTA keep? Arrival-Date keep Original-Recipient keep? Final-Recipient keep Action expand: need "queued". Is "expanded" relevant? Status expand: need "relayed" Remote-MTA keep Diagnostic-Code drop Last-Attempt keep Will-Retry-Until keep 44.. SSeeccuurriittyy IIssssuueess XXX To be completed. AAllllmmaann [[PPaaggee 99]] --==_Exmh_10298066860-- From owner-ietf-msgtrk@mail.imc.org Thu Jul 13 12:14:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26391 for ; Thu, 13 Jul 2000 12:14:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29902 for ietf-msgtrk-bks; Thu, 13 Jul 2000 08:47:25 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29895 for ; Thu, 13 Jul 2000 08:47:24 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0.Beta4/8.11.0.Beta4) id e6DFnOM98500; Thu, 13 Jul 2000 08:49:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14701.58628.747940.116079@horsey.gshapiro.net> Date: Thu, 13 Jul 2000 08:49:24 -0700 (PDT) From: Gregory Neil Shapiro To: Eric Allman Cc: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-Reply-To: <200007111655.e6BGt7o00894@jean-baptiste.sendmail.org> References: <200007111655.e6BGt7o00894@jean-baptiste.sendmail.org> X-Mailer: VM 6.75 under 21.2 (beta34) "Molpe" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit eric> Enclosed are two "pre-drafts" -- they really aren't up for draft eric> status yet, but I did want folks here get a glimpse of where they are eric> going. I noticed the documents still use an SMTP verb instead of an external protocol for querying tracking information. After the last IETF meeting, I thought we were looking towards breaking the query out into it's own service/protocol. From owner-ietf-msgtrk@mail.imc.org Fri Jul 14 03:00:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14043 for ; Fri, 14 Jul 2000 03:00:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06253 for ietf-msgtrk-bks; Thu, 13 Jul 2000 23:49:53 -0700 (PDT) Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06248 for ; Thu, 13 Jul 2000 23:49:52 -0700 (PDT) Received: from knecht.Sendmail.ORG (localhost.Neophilic.COM [127.0.0.1]) by knecht.Sendmail.ORG (8.10.0/8.10.1) with ESMTP id e6E6ptl13827; Thu, 13 Jul 2000 23:51:55 -0700 (PDT) Message-Id: <200007140651.e6E6ptl13827@knecht.Sendmail.ORG> X-Mailer: exmh version 2.1.2 06/08/2000 To: Gregory Neil Shapiro From: Eric Allman X-URL: http://WWW.Sendmail.ORG/~eric cc: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Mail from Gregory Neil Shapiro dated Thu, 13 Jul 2000 08:49:24 PDT <14701.58628.747940.116079@horsey.gshapiro.net> Date: Thu, 13 Jul 2000 23:51:55 -0700 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Erk. I think you're right. This never disappeared from my very early outline, hence my confusion. Just ignore that portion of the document. eric ============= In Reply To: =========================================== : From: Gregory Neil Shapiro : Subject: Re: MSGTRK pre-drafts : Date: Thu, 13 Jul 2000 08:49:24 -0700 (PDT) : eric> Enclosed are two "pre-drafts" -- they really aren't up for draft : eric> status yet, but I did want folks here get a glimpse of where they are : eric> going. : : I noticed the documents still use an SMTP verb instead of an external : protocol for querying tracking information. After the last IETF meeting, I : thought we were looking towards breaking the query out into it's own : service/protocol. From owner-ietf-msgtrk@mail.imc.org Fri Jul 14 03:05:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15441 for ; Fri, 14 Jul 2000 03:05:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06313 for ietf-msgtrk-bks; Thu, 13 Jul 2000 23:50:48 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06308 for ; Thu, 13 Jul 2000 23:50:47 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id CAA21703 for ; Fri, 14 Jul 2000 02:52:21 -0400 (EDT) Received: from att.com ([135.197.86.171]) by maillennium.att.com (labmail) with SMTP id <2000071406495809900784t2e> (Authid: tony@maillennium.att.com); Fri, 14 Jul 2000 06:49:59 +0000 Message-ID: <396EB828.14712A38@att.com> Date: Fri, 14 Jul 2000 02:50:16 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-msgtrk@imc.org Subject: two drafts submitted Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've just sent off two drafts to the I-D editors: Message Tracking Model and Requirements draft-ietf-msgtrk-model-02.txt Message Tracking Query Protocol draft-ietf-msgtrk-mtqp-00.txt For those who can't wait, I've also uploaded them to http://www.geocities.com/SiliconValley/Way/8115/draft-ietf-msgtrk-model-02.txt http://www.geocities.com/SiliconValley/Way/8115/draft-ietf-msgtrk-mtqp-00.txt Tony Hansen tony@att.com From owner-ietf-msgtrk@mail.imc.org Fri Jul 14 13:01:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01842 for ; Fri, 14 Jul 2000 13:01:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00313 for ietf-msgtrk-bks; Fri, 14 Jul 2000 09:41:22 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00309 for ; Fri, 14 Jul 2000 09:41:21 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e6EGhQl12344; Fri, 14 Jul 2000 10:43:26 -0600 From: Steve Hole Date: Fri, 14 Jul 2000 10:43:07 -0600 To: Tony Hansen Subject: Re: two drafts submitted Cc: ietf-msgtrk@imc.org In-Reply-To: <396EB828.14712A38@att.com> References: <396EB828.14712A38@att.com> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 14 Jul 2000 02:50:16 -0400 Tony Hansen wrote: > I've just sent off two drafts to the I-D editors: > > Message Tracking Model and Requirements > draft-ietf-msgtrk-model-02.txt It is my intention to have this document go to last call. I would like to deal with any issues with the document in Pittsburg and make a formal last call immediately after. Recall that this document will be issued as informational. It is a working document for the group to focus the conversation on the problem that we wanted to solve -- not on any solutions. The oither documents produced by Tony and Eric are solution documents and the place that we want to spend our time on debate. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk@mail.imc.org Fri Jul 14 13:39:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01845 for ; Fri, 14 Jul 2000 13:01:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00388 for ietf-msgtrk-bks; Fri, 14 Jul 2000 09:45:08 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00384 for ; Fri, 14 Jul 2000 09:45:06 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e6EGl4l12396; Fri, 14 Jul 2000 10:47:04 -0600 From: Steve Hole Date: Fri, 14 Jul 2000 10:46:45 -0600 To: Tony Hansen Subject: Re: two drafts submitted Cc: ietf-msgtrk@imc.org In-Reply-To: <396EB828.14712A38@att.com> References: <396EB828.14712A38@att.com> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 14 Jul 2000 02:50:16 -0400 Tony Hansen wrote: > Message Tracking Query Protocol > draft-ietf-msgtrk-mtqp-00.txt > > For those who can't wait, I've also uploaded them to > > http://www.geocities.com/SiliconValley/Way/8115/draft-ietf-msgtrk-model-02.txt > http://www.geocities.com/SiliconValley/Way/8115/draft-ietf-msgtrk-mtqp-00.txt Please, everyone, read these documents prior to Pittsburg. We will be discussing them in detail and, hopefully, coming to concensus on most of the details of the protocol. I will be asking Tony and Eric to do short presentations on the proposals, but I would like to have people do some thinking about this before we get into the meeting. We will also be doing another design team meeting prior to the working group meeting to make sure that we have solid proposals in hand for discussion. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk@mail.imc.org Fri Jul 14 14:13:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25769 for ; Fri, 14 Jul 2000 14:13:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02152 for ietf-msgtrk-bks; Fri, 14 Jul 2000 11:04:03 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02143 for ; Fri, 14 Jul 2000 11:04:01 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA26863; Fri, 14 Jul 2000 14:05:57 -0400 (EDT) Message-Id: <200007141805.OAA26863@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Eric Allman cc: Gregory Neil Shapiro , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Thu, 13 Jul 2000 23:51:55 PDT." <200007140651.e6E6ptl13827@knecht.Sendmail.ORG> Date: Fri, 14 Jul 2000 14:05:57 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd be curious as to the justification for creating a separate protocol for message tracking. to me it doesn't make any sense. Keith From owner-ietf-msgtrk@mail.imc.org Tue Jul 18 06:43:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17066 for ; Tue, 18 Jul 2000 06:43:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08468 for ietf-msgtrk-bks; Tue, 18 Jul 2000 03:33:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08463 for ; Tue, 18 Jul 2000 03:33:07 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13733; Tue, 18 Jul 2000 06:35:32 -0400 (EDT) Message-Id: <200007181035.GAA13733@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-msgtrk@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msgtrk-model-02.txt Date: Tue, 18 Jul 2000 06:35:32 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Tracking Protocol Working Group of the IETF. Title : Message Tracking Model and Requirements Author(s) : T. Hansen, K. Lin Filename : draft-ietf-msgtrk-model-02.txt Pages : 10 Date : 17-Jul-00 Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-model-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msgtrk-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msgtrk-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msgtrk-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msgtrk-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145938.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-msgtrk@mail.imc.org Fri Jul 21 09:54:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13556 for ; Fri, 21 Jul 2000 09:54:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28204 for ietf-msgtrk-bks; Fri, 21 Jul 2000 06:38:00 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28200 for ; Fri, 21 Jul 2000 06:37:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12873; Fri, 21 Jul 2000 09:40:38 -0400 (EDT) Message-Id: <200007211340.JAA12873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-msgtrk@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msgtrk-mtqp-00.txt Date: Fri, 21 Jul 2000 09:40:38 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Tracking Protocol Working Group of the IETF. Title : Message Tracking Query Protocol Author(s) : T. Hansen Filename : draft-ietf-msgtrk-mtqp-00.txt Pages : 9 Date : 20-Jul-00 Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with exten- sions to the ESMTP protocol to provide a complete message tracking solu- tion for the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-mtqp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msgtrk-mtqp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msgtrk-mtqp-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720141932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msgtrk-mtqp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msgtrk-mtqp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141932.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-msgtrk@mail.imc.org Wed Jul 26 16:19:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07035 for ; Wed, 26 Jul 2000 16:19:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00952 for ietf-msgtrk-bks; Wed, 26 Jul 2000 13:05:52 -0700 (PDT) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00948 for ; Wed, 26 Jul 2000 13:05:50 -0700 (PDT) Received: from gollum.esys.ca (localhost [127.0.0.1]) by gollum.esys.ca (8.10.2/8.10.2) with ESMTP id e6QK8eZ00663 for ; Wed, 26 Jul 2000 14:08:40 -0600 (MDT) Date: Wed, 26 Jul 2000 14:08:40 -0600 From: Lyndon Nerenberg To: ietf-msgtrk@imc.org Subject: linting draft-ietf-msgtrk-protocol-00.txt Message-ID: <110150000.964642120@gollum.esys.ca> X-Mailer: Mulberry/2.0.1a3 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are a few things that popped out during my initial read of the draft. Section 3: * line 2: s/message may issue the EHLO command/message MUST issue the EHLO command/ Section 4.2.1 s/the Tracking ID is REQUIRED to be/the Tracking ID MUST be/ "generational counter MUST be incremented by one." contradicts the followon sentence. Suggest: "generational counter MUST be incremented." and drop the following sentence (... small amount ...) (or provide a rational for it?). Section 4.2.2 s/This secret value MAY be a per-message secret/This secret value SHOULD be a per-message secret/ Is there a reason for MAY here instead of SHOULD? Section 4.2.4 "This value is then expressed as a series of 32 hexadecimal digits, either lower- or upper-case, transmitted in internet byte order (low-endian ???? )" This should read 'case independent'. "internet byte order" reads as if it applies to the US-ASCII string. This needs clarification that the ordering is of the underlying 16 byte binary string. Section 6.1 s/S: 25o /S: 250 / Section 7 There *are* security issues with the hash calculations, and with the requirements of section 4.2.2. We should at least draw attention to the hazards of reusing the secret. --lyndon From owner-ietf-msgtrk@mail.imc.org Wed Jul 26 16:48:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15227 for ; Wed, 26 Jul 2000 16:48:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01706 for ietf-msgtrk-bks; Wed, 26 Jul 2000 13:39:50 -0700 (PDT) Received: from localhost (p3EE06CFE.dip0.t-ipconnect.de [62.224.108.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01696 for ; Wed, 26 Jul 2000 13:39:46 -0700 (PDT) Received: from enode by company.mail with SMTP (MDaemon.v3.1.0.R) for ; Wed, 26 Jul 2000 22:42:26 +0200 Message-ID: <02b801bff742$01f13370$fe219c3e@enode> From: =?iso-8859-1?Q?Jens_M=FCller?= To: "Lyndon Nerenberg" , References: <110150000.964642120@gollum.esys.ca> Subject: Re: linting draft-ietf-msgtrk-protocol-00.txt Date: Wed, 26 Jul 2000 22:42:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: ietf-msgtrk@imc.org X-Return-Path: jens@unfaehig.de X-MDRcpt-To: ietf-msgtrk@imc.org Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Lyndon Nerenberg" To: Sent: Wednesday, July 26, 2000 10:08 PM Subject: linting draft-ietf-msgtrk-protocol-00.txt > Section 4.2.4 > > "This value is then expressed as a series of > 32 hexadecimal digits, either lower- or upper-case, transmitted in > internet byte order (low-endian ???? )" > > This should read 'case independent'. > > "internet byte order" reads as if it applies to the US-ASCII string. > This needs clarification that the ordering is of the underlying 16 byte > binary string. isn't it "Network Byte Order"? Jens From owner-ietf-msgtrk@mail.imc.org Thu Jul 27 09:33:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24624 for ; Thu, 27 Jul 2000 09:33:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20304 for ietf-msgtrk-bks; Thu, 27 Jul 2000 06:21:31 -0700 (PDT) Received: from d06lmsgate-3.emea.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20287 for ; Thu, 27 Jul 2000 06:21:22 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.emea.ibm.com (1.0.0) with ESMTP id OAA74918; Thu, 27 Jul 2000 14:16:01 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id OAA224616; Thu, 27 Jul 2000 14:23:55 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256929.00499964 ; Thu, 27 Jul 2000 14:23:53 +0100 X-Lotus-FromDomain: IBMGB To: Lyndon Nerenberg , ietf-msgtrk@imc.org Message-ID: <80256929.00499620.00@d06mta07.portsmouth.uk.ibm.com> Date: Thu, 27 Jul 2000 14:21:50 +0100 Subject: Re: linting draft-ietf-msgtrk-protocol-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: With regard to the security of the hashing - Steve Bellovin has written - in draft-ietf-iab-secmech-01.txt (which has long since expired) "5.2. HMAC HMAC [RFC2104] is the preferred shared-secret authentication technique. If both sides know the same secret key, HMAC can be used to authenticate any arbitrary message. This specifically includes random challenges, which means that HMAC is suitable for logins. The disadvantage, of course, is that the secret must be known in the clear by both parties. In many situations, this is undesirable. When suitable, HMAC should be used in preference to older techniques, notably keyed hash functions. Keyed hashes based on MD5 [RFC1321] are especially to be avoided, given the hints of weakness in MD5." Are we sure that the proposal in draft-ietf-msgtrk-protocol-00.txt isn't ignoring this advice ? Cheers, Paul -- Paul Ford-Hutchinson : EMEA eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 Lyndon Nerenberg on 26/07/2000 21:08:40 Please respond to Lyndon Nerenberg To: ietf-msgtrk@imc.org cc: (bcc: Paul V Ford-Hutchinson/UK/IBM) Subject: linting draft-ietf-msgtrk-protocol-00.txt Here are a few things that popped out during my initial read of the draft. Section 3: * line 2: s/message may issue the EHLO command/message MUST issue the EHLO command/ Section 4.2.1 s/the Tracking ID is REQUIRED to be/the Tracking ID MUST be/ "generational counter MUST be incremented by one." contradicts the followon sentence. Suggest: "generational counter MUST be incremented." and drop the following sentence (... small amount ...) (or provide a rational for it?). Section 4.2.2 s/This secret value MAY be a per-message secret/This secret value SHOULD be a per-message secret/ Is there a reason for MAY here instead of SHOULD? Section 4.2.4 "This value is then expressed as a series of 32 hexadecimal digits, either lower- or upper-case, transmitted in internet byte order (low-endian ???? )" This should read 'case independent'. "internet byte order" reads as if it applies to the US-ASCII string. This needs clarification that the ordering is of the underlying 16 byte binary string. Section 6.1 s/S: 25o /S: 250 / Section 7 There *are* security issues with the hash calculations, and with the requirements of section 4.2.2. We should at least draw attention to the hazards of reusing the secret. --lyndon From owner-ietf-msgtrk@mail.imc.org Thu Jul 27 17:23:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08750 for ; Thu, 27 Jul 2000 17:23:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13592 for ietf-msgtrk-bks; Thu, 27 Jul 2000 14:10:17 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13586 for ; Thu, 27 Jul 2000 14:10:13 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id RAA11953; Thu, 27 Jul 2000 17:12:36 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id RAA15801; Thu, 27 Jul 2000 17:10:29 -0400 (EDT) Received: from bhanji-pc.mitre.org (128.29.105.10) by mailhub2.mitre.org with SMTP id 4052441; Thu, 27 Jul 2000 17:12:28 EST Message-ID: <3980A3BF.E9B37A55@mitre.org> Date: Thu, 27 Jul 2000 17:03:59 -0400 From: "Shiraz G. Bhanji" Organization: The MITRE Corporation X-Mailer: Mozilla 4.73 [en]C-20000509M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: paulfordh@uk.ibm.com CC: Lyndon Nerenberg , ietf-msgtrk@imc.org Subject: Re: linting draft-ietf-msgtrk-protocol-00.txt References: <80256929.00499620.00@d06mta07.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul, I agree with your suggestion. To reinforce your quote from Steve Bellovin about MD5, I've been following the S/MIME WG and they have decided to move away from MD5 and mandated SHA-1 in the latest version of the S/MIME specs. Here's a quote from RFC 2633 on S/MIME v3 specs: "2.1 DigestAlgorithmIdentifier Sending and receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD support MD5 [MD5] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects." Since we are at the beginning of the development cycle, it would make sense for us to adopt the most current digest algos and not have to worry about backwards compatibility. Thanks. Shiraz paulfordh@uk.ibm.com wrote: > > With regard to the security of the hashing - Steve Bellovin has written - > in draft-ietf-iab-secmech-01.txt (which has long since expired) > > "5.2. HMAC > > HMAC [RFC2104] is the preferred shared-secret authentication > technique. If both sides know the same secret key, HMAC can be used > to authenticate any arbitrary message. This specifically includes > random challenges, which means that HMAC is suitable for logins. > > The disadvantage, of course, is that the secret must be known in the > clear by both parties. In many situations, this is undesirable. > > When suitable, HMAC should be used in preference to older techniques, > notably keyed hash functions. Keyed hashes based on MD5 [RFC1321] > are especially to be avoided, given the hints of weakness in MD5." > > Are we sure that the proposal in draft-ietf-msgtrk-protocol-00.txt isn't > ignoring this advice ? > > Cheers, > Paul > -- > Paul Ford-Hutchinson : EMEA eCommerce application security : > paulfordh@uk.ibm.com > MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 > > Lyndon Nerenberg on 26/07/2000 21:08:40 > > Please respond to Lyndon Nerenberg > > To: ietf-msgtrk@imc.org > cc: (bcc: Paul V Ford-Hutchinson/UK/IBM) > Subject: linting draft-ietf-msgtrk-protocol-00.txt > > Here are a few things that popped out during my initial read of the > draft. > > Section 3: > > * line 2: s/message may issue the EHLO command/message MUST issue the > EHLO command/ > > Section 4.2.1 > > s/the Tracking ID is REQUIRED to be/the Tracking ID MUST be/ > > "generational counter MUST be incremented by one." > > contradicts the followon sentence. Suggest: "generational counter MUST > be incremented." and drop the following sentence (... small amount ...) > (or provide a rational for it?). > > Section 4.2.2 > > s/This secret value MAY be a per-message secret/This secret value > SHOULD > be a per-message secret/ > > Is there a reason for MAY here instead of SHOULD? > > Section 4.2.4 > > "This value is then expressed as a series of > 32 hexadecimal digits, either lower- or upper-case, transmitted in > internet byte order (low-endian ???? )" > > This should read 'case independent'. > > "internet byte order" reads as if it applies to the US-ASCII string. > This needs clarification that the ordering is of the underlying 16 byte > binary string. > > Section 6.1 > > s/S: 25o /S: 250 / > > Section 7 > > There *are* security issues with the hash calculations, and with the > requirements of section 4.2.2. We should at least draw attention to > the hazards of reusing the secret. > > --lyndon From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 09:53:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22565 for ; Fri, 28 Jul 2000 09:53:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20784 for ietf-msgtrk-bks; Fri, 28 Jul 2000 06:41:54 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20775 for ; Fri, 28 Jul 2000 06:41:52 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA07846 for ; Fri, 28 Jul 2000 09:44:38 -0400 (EDT) Received: from att.com ([135.197.86.140]) by maillennium.att.com (labmail) with SMTP id <2000072813421609900k1u25e> (Authid: tony@maillennium.att.com); Fri, 28 Jul 2000 13:42:17 +0000 Message-ID: <39818C7B.C3656FEA@att.com> Date: Fri, 28 Jul 2000 09:36:59 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts References: <200007141805.OAA26863@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keith Moore wrote: > > I'd be curious as to the justification for creating a separate > protocol for message tracking. to me it doesn't make any sense. The proposal was made at Adelaide and there was little disagreement in the room. I agreed to put together a straw proposal for such a protocol. The question can certainly be brought up again in Pittsburgh. Like everything, it has its good points and its bad points. Here are a few: Good points: can administer message tracking server separately can do referrals to another server that is ONLY running MTQP server Bad points: another protocol, another port need to administer two servers now instead of just one Tony Hansen tony@att.com From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 10:02:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24801 for ; Fri, 28 Jul 2000 10:02:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23402 for ietf-msgtrk-bks; Fri, 28 Jul 2000 06:53:54 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23393 for ; Fri, 28 Jul 2000 06:53:53 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA02834; Fri, 28 Jul 2000 09:57:03 -0400 (EDT) Message-Id: <200007281357.JAA02834@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tony Hansen cc: Keith Moore , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 09:36:59 EDT." <39818C7B.C3656FEA@att.com> Date: Fri, 28 Jul 2000 09:57:03 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Bad points: > > another protocol, another port > > need to administer two servers now instead of just one need to keep msgtrk servers in sync with MTAs. Keith From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 11:58:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26885 for ; Fri, 28 Jul 2000 11:58:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07255 for ietf-msgtrk-bks; Fri, 28 Jul 2000 08:47:37 -0700 (PDT) Received: from d06lmsgate-3.emea.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07250 for ; Fri, 28 Jul 2000 08:47:34 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.emea.ibm.com (1.0.0) with ESMTP id QAA79774 for ; Fri, 28 Jul 2000 16:42:15 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id QAA14120 for ; Fri, 28 Jul 2000 16:50:09 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692A.0056FCB4 ; Fri, 28 Jul 2000 16:50:07 +0100 X-Lotus-FromDomain: IBMGB To: ietf-msgtrk@imc.org Message-ID: <8025692A.0056FBEB.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 16:36:33 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > > I'd be curious as to the justification for creating a separate > protocol for message tracking. to me it doesn't make any sense. It is unclear to me what the alternative would be. Can you elaborate ? Cheers, Paul -- Paul Ford-Hutchinson : EMEA eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 12:58:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10374 for ; Fri, 28 Jul 2000 12:58:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11558 for ietf-msgtrk-bks; Fri, 28 Jul 2000 09:48:39 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11553 for ; Fri, 28 Jul 2000 09:48:38 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA19664 for ; Fri, 28 Jul 2000 12:51:25 -0400 (EDT) Received: from att.com ([135.197.90.148]) by maillennium.att.com (labmail) with SMTP id <2000072816490709900k1uake> (Authid: tony@maillennium.att.com); Fri, 28 Jul 2000 16:49:07 +0000 Message-ID: <3981B986.EC83334A@att.com> Date: Fri, 28 Jul 2000 12:49:11 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: paulfordh@uk.ibm.com CC: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts References: <8025692A.0056FBEB.00@d06mta07.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The two choices on the table are: 1) Provide a separate protocol (the Message Tracking Query Protocol, or MTQP) that lets you query a message's tracking status. 2) As part of the MTRK SMTP extension, add a verb that lets you query a message's tracking status. It would be similar in a way to HELP, NOOP, EXPN and VRFY in that it's not used in the sending of mail messages. The original proposal was to do the second one. At Adelaide it was proposed that we do the first one. The support for a separate protocol was overwhelming among the people who were there. Tony Hansen tony@att.com paulfordh@uk.ibm.com wrote: > > Keith Moore wrote: > > > > I'd be curious as to the justification for creating a separate > > protocol for message tracking. to me it doesn't make any sense. > > It is unclear to me what the alternative would be. Can you elaborate ? From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 13:36:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20989 for ; Fri, 28 Jul 2000 13:36:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12431 for ietf-msgtrk-bks; Fri, 28 Jul 2000 10:26:46 -0700 (PDT) Received: from d06lmsgate-2.emea.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12427 for ; Fri, 28 Jul 2000 10:26:44 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.emea.ibm.com (1.0.0) with ESMTP id SAA67832; Fri, 28 Jul 2000 18:17:22 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id SAA223722; Fri, 28 Jul 2000 18:29:30 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692A.006013C2 ; Fri, 28 Jul 2000 18:29:25 +0100 X-Lotus-FromDomain: IBMGB To: Tony Hansen cc: ietf-msgtrk@imc.org Message-ID: <8025692A.006012C6.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 18:27:42 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I thought so. Given that SMTP is a subset of message transfer protocols, 2) would mean adding verbs and extensions to the rest of them too. http, ftp, pop3 and imap spring to mind. Whilst some of them might need extending to provide or understand the tracking ID hand-off, it seems that incorporating the querying mechanism only into SMTP wouldn't be terribly flexible. A particular example might be extending the EDI-INT AS2 spec (EDI, S/MIME and HTTP). Not an SMTP server in sight - but a definite need for a trackable message. 1) seems much more flexible in a heterogenous environment Paul -- Paul Ford-Hutchinson : EMEA eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 Tony Hansen wrote: The two choices on the table are: 1) Provide a separate protocol (the Message Tracking Query Protocol, or MTQP) that lets you query a message's tracking status. 2) As part of the MTRK SMTP extension, add a verb that lets you query a message's tracking status. It would be similar in a way to HELP, NOOP, EXPN and VRFY in that it's not used in the sending of mail messages. The original proposal was to do the second one. At Adelaide it was proposed that we do the first one. The support for a separate protocol was overwhelming among the people who were there. Tony Hansen tony@att.com paulfordh@uk.ibm.com wrote: > > Keith Moore wrote: > > > > I'd be curious as to the justification for creating a separate > > protocol for message tracking. to me it doesn't make any sense. > > It is unclear to me what the alternative would be. Can you elaborate ? From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 14:01:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26769 for ; Fri, 28 Jul 2000 14:01:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13233 for ietf-msgtrk-bks; Fri, 28 Jul 2000 10:51:58 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13221 for ; Fri, 28 Jul 2000 10:51:57 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA07164; Fri, 28 Jul 2000 13:55:09 -0400 (EDT) Message-Id: <200007281755.NAA07164@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: paulfordh@uk.ibm.com cc: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 16:36:33 BST." <8025692A.0056FBEB.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 13:55:09 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > It is unclear to me what the alternative would be. Can you elaborate ? at one time it was suggested that message tracking be implemented as an SMTP extension - the SMTPs would log message passage and you could consult them to track a message. From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 14:03:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27205 for ; Fri, 28 Jul 2000 14:03:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13080 for ietf-msgtrk-bks; Fri, 28 Jul 2000 10:46:37 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13072 for ; Fri, 28 Jul 2000 10:46:30 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA29263 for ; Fri, 28 Jul 2000 13:49:13 -0400 (EDT) Received: from att.com ([135.197.90.148]) by maillennium.att.com (labmail) with SMTP id <2000072817465509900k1ucje> (Authid: tony@maillennium.att.com); Fri, 28 Jul 2000 17:46:55 +0000 Message-ID: <3981C711.842455D@att.com> Date: Fri, 28 Jul 2000 13:46:57 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: paulfordh@uk.ibm.com CC: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts References: <8025692A.006012C6.00@d06mta07.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No, because the problem space was purposely limited to that of tracking a message until it has delivered to a user's mailbox or passed on to a network element for which tracking information cannot be provided. That is, pop3 and imap would not need additions. I can't say I've ever heard of ftp being used for message transfer, and http's use has typically been for message access (ala imap and pop) and not message transmission. Tony Hansen tony@att.com paulfordh@uk.ibm.com wrote: > > I thought so. > > Given that SMTP is a subset of message transfer protocols, 2) would mean > adding verbs and extensions to the rest of them too. > > http, ftp, pop3 and imap spring to mind. > > Whilst some of them might need extending to provide or understand the > tracking ID hand-off, it seems that incorporating the querying mechanism > only into SMTP wouldn't be terribly flexible. > > A particular example might be extending the EDI-INT AS2 spec (EDI, S/MIME > and HTTP). Not an SMTP server in sight - but a definite need for a > trackable message. > > 1) seems much more flexible in a heterogenous environment > > Paul > > -- > Paul Ford-Hutchinson : EMEA eCommerce application security : > paulfordh@uk.ibm.com > MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 > > Tony Hansen wrote: > > The two choices on the table are: > > 1) Provide a separate protocol (the Message Tracking Query Protocol, or > MTQP) that lets you query a message's tracking status. > > 2) As part of the MTRK SMTP extension, add a verb that lets you query a > message's tracking status. It would be similar in a way to HELP, NOOP, > EXPN and VRFY in that it's not used in the sending of mail messages. > > The original proposal was to do the second one. At Adelaide it was > proposed that we do the first one. The support for a separate protocol > was overwhelming among the people who were there. > > Tony Hansen > tony@att.com > > paulfordh@uk.ibm.com wrote: > > > > Keith Moore wrote: > > > > > > I'd be curious as to the justification for creating a separate > > > protocol for message tracking. to me it doesn't make any sense. > > > > It is unclear to me what the alternative would be. Can you elaborate ? From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 14:09:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28636 for ; Fri, 28 Jul 2000 14:09:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13599 for ietf-msgtrk-bks; Fri, 28 Jul 2000 11:00:57 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13595 for ; Fri, 28 Jul 2000 11:00:55 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA07324; Fri, 28 Jul 2000 14:04:08 -0400 (EDT) Message-Id: <200007281804.OAA07324@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: paulfordh@uk.ibm.com cc: Tony Hansen , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 18:27:42 BST." <8025692A.006012C6.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 14:04:08 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I thought so. > > Given that SMTP is a subset of message transfer protocols, 2) would mean > adding verbs and extensions to the rest of them too. uh, no. yes there are other message transfer protocols, but SMTP is the only message transfer protocol of interest. none of the other examples you cited are message transfer protocols. they can be employed to read messages or sometimes to submit messages, but they are not designed for this purpose. it's silly to say that every protocol that can possibly be used to transfer mail has to be extended to support message tracking, or even to say that an external message tracking protocol has to support the ability to track messages through arbitrary other protocols. > Whilst some of them might need extending to provide or understand the > tracking ID hand-off, it seems that incorporating the querying mechanism > only into SMTP wouldn't be terribly flexible. insisting that a protocol be too flexible is a good way to kill it. > A particular example might be extending the EDI-INT AS2 spec (EDI, S/MIME > and HTTP). Not an SMTP server in sight - but a definite need for a > trackable message. SMTP has explicit support for relaying. HTTP does not. I have a hard time understanding the need for message tracking when you only have two parties handling the message. yes, HTTP has proxies, but in the case of a transferring an EDI message you want to defeat them. there are probably good reasons to consider using an external protocol, but IMHO this isn't one of them. Keith From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 14:49:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09963 for ; Fri, 28 Jul 2000 14:49:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14504 for ietf-msgtrk-bks; Fri, 28 Jul 2000 11:40:47 -0700 (PDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14496 for ; Fri, 28 Jul 2000 11:40:45 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id TAA152908; Fri, 28 Jul 2000 19:31:39 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id TAA218066; Fri, 28 Jul 2000 19:43:31 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692A.0066DBDF ; Fri, 28 Jul 2000 19:43:29 +0100 X-Lotus-FromDomain: IBMGB To: Tony Hansen cc: ietf-msgtrk@imc.org Message-ID: <8025692A.0066D9BC.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 19:41:38 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen wrote: >No, because the problem space was purposely limited to that of tracking >a message until it has delivered to a user's mailbox or passed on to a >network element for which tracking information cannot be provided. Cannot because it doesn't or cannot because it can't. If this is absorbed into SMTP then non-SMTP transports will be the latter not the former. > That >is, pop3 and imap would not need additions. I can't say I've ever heard >of ftp being used for message transfer, It sure is. Quite common in the EDI world at the moment. > and http's use has typically >been for message access (ala imap and pop) and not message transmission. draft-ietf-ediint-as2-07.txt specifically uses http as the transport mechanism for EDI messages across the Internet - when those messages are also routed through EDI VANs or other message transport services, it would be nice to preserve the ability to track them. Paul From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 14:50:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10396 for ; Fri, 28 Jul 2000 14:50:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA14505 for ietf-msgtrk-bks; Fri, 28 Jul 2000 11:40:47 -0700 (PDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14497 for ; Fri, 28 Jul 2000 11:40:45 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id TAA134426; Fri, 28 Jul 2000 19:31:39 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id TAA218076; Fri, 28 Jul 2000 19:43:31 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692A.0066DB6E ; Fri, 28 Jul 2000 19:43:28 +0100 X-Lotus-FromDomain: IBMGB To: Keith Moore cc: ietf-msgtrk@imc.org Message-ID: <8025692A.0066D9BB.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 19:33:11 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: >paulfordh@uk.ibm.com wrote: >> >> Given that SMTP is a subset of message transfer protocols, 2) would mean >> adding verbs and extensions to the rest of them too. >uh, no. yes there are other message transfer protocols, but SMTP is >the only message transfer protocol of interest. none of the other >examples you cited are message transfer protocols. they can be >employed to read messages or sometimes to submit messages, but >they are not designed for this purpose. Ok - maybe not designed - but they _are_ used. >it's silly to say that >every protocol that can possibly be used to transfer mail has to >be extended to support message tracking, No - but it would be nice to allow those that are being used to do so. > or even to say that an >external message tracking protocol has to support the ability to >track messages through arbitrary other protocols. Umm - I'm confused by this. It seems that you are saying that msgtrk is for SMTP therefore it is silly to define it for anything other than SMTP - my contention is that SMTP is not the only way that people and systems interact with messages that require tracking and therefore tying msgtrk to SMTP is unnecessarily restrictive. >> Whilst some of them might need extending to provide or understand the >> tracking ID hand-off, it seems that incorporating the querying mechanism >> only into SMTP wouldn't be terribly flexible. >insisting that a protocol be too flexible is a good way to kill it. I didn't say the _protocol_ had to be flexible, just that the mechanism of implementation could make less assumptions about its environment i.e. didn't assume an existing SMTP session. >> A particular example might be extending the EDI-INT AS2 spec (EDI, S/MIME >> and HTTP). Not an SMTP server in sight - but a definite need for a >> trackable message. >SMTP has explicit support for relaying. HTTP does not. I have a >hard time understanding the need for message tracking when you only >have two parties handling the message. Often the http server involved is the front end to a whole system (and may indeed dump it to SMTP or some other message transfer mechanism for onward delivery) I don't agree that the http server will always be an end-point. >yes, HTTP has proxies, but in the case of a transferring an EDI message >you want to defeat them. I'm not 100% sure what this means here. >there are probably good reasons to consider using an external protocol, >but IMHO this isn't one of them. I suppose it comes down to the question - "Do you assume that any system or user that needs to track messages must be doing so through a purely SMTP environment ?" I guess the alternative is that, for those non-SMTP transfer protocols, they need to put up an SMTP-a-like on port 25 that only uses the msgtrk query commands - now that would be confusing. Paul From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 15:05:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15088 for ; Fri, 28 Jul 2000 15:05:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14946 for ietf-msgtrk-bks; Fri, 28 Jul 2000 11:53:30 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14942 for ; Fri, 28 Jul 2000 11:53:29 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e6SIukl08180 for ; Fri, 28 Jul 2000 12:56:46 -0600 From: Steve Hole Date: Fri, 28 Jul 2000 12:56:23 -0600 To: ietf-msgtrk@imc.org Subject: Fwd: message tracking proposed agenda Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is the agenda that Tony has proposed. It pretty much agrees with my thinking, except that I have added a section to review the decisions made in Adelaide. Keith Moore questioned the need for a new query protocol on a separate port, and we need to have our powder dry before we carry on. The result is an overall architecture that will want to express somewhere, and I don't see a document vehicle for doing that right now. Cheers. --- Begin Forwarded Message --- Date: Fri, 28 Jul 2000 12:59:59 -0400 From: Tony Hansen Subject: message tracking proposed agenda Sender: Tony Hansen To: Steve Hole Reply-To: Tony Hansen Message-ID: <3981BC0F.F574B059@att.com> Here's a proposal for the msgtrk agenda. Tony agenda bashing 5 min discuss model document 10 min Ready for last call? draft-ietf-msgtrk-model-02.txt review decisions taken at Adelaide meeting 10 min discuss message/tracking-status 25 min draft-ietf-msgtrk-trkstat.txt discuss MTRK smtp extension for tracking message 35 min draft-ietf-msgtrk-smtpext.txt (and draft-ietf-msgtrk-protocol-00.txt) discuss message tracking querying: 35 min Do we use a separate protocol or part of MTRK? draft-ietf-msgtrk-mtqp-00.txt Note: draft-ietf-msgtrk-trk.txt and draft-ietf-msgtrk-smtpext.txt were posted to the mailing list and are not in the internet-drafts repository. --- End Forwarded Message --- --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 15:13:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17720 for ; Fri, 28 Jul 2000 15:13:53 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15234 for ietf-msgtrk-bks; Fri, 28 Jul 2000 12:02:15 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15225 for ; Fri, 28 Jul 2000 12:02:13 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA08359; Fri, 28 Jul 2000 15:05:29 -0400 (EDT) Message-Id: <200007281905.PAA08359@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: paulfordh@uk.ibm.com cc: Keith Moore , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 19:33:11 BST." <8025692A.0066D9BB.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 15:05:29 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Keith Moore wrote: > > >paulfordh@uk.ibm.com wrote: > >> > >> Given that SMTP is a subset of message transfer protocols, 2) would mean > >> adding verbs and extensions to the rest of them too. > > >uh, no. yes there are other message transfer protocols, but SMTP is > >the only message transfer protocol of interest. none of the other > >examples you cited are message transfer protocols. they can be > >employed to read messages or sometimes to submit messages, but > >they are not designed for this purpose. > > Ok - maybe not designed - but they _are_ used. people do all kinds of silly things. people attempt to use knife tips to remove Philips head screws. that doesn't mean that we should try to cater to such things. it's usually hard enough to get the normal cases to work right. if you want to say that msgtrk should work over X.400 transports in addition to SMTP, that's worth considering... but probably not worthwhile considering that X.400 is mostly dead. but trying to define how to make msgtrk work over http, pop, imap, snail mail, or avian carriers - things that don't transfer messages reliably in the first place - doesn't seem worth the trouble. > > or even to say that an > >external message tracking protocol has to support the ability to > >track messages through arbitrary other protocols. > > Umm - I'm confused by this. It seems that you are saying that msgtrk is > for SMTP therefore it is silly to define it for anything other than SMTP - no I'm saying that it's silly to insist that it be usable for any random protocol that people use to transfer messages. > my contention is that SMTP is not the only way that people and systems > interact with messages that require tracking and therefore tying msgtrk to > SMTP is unnecessarily restrictive. my contention is that you often have to restrict the probem space in order to solve a useful subset of the general problem recently I sent off a radio to be repaired. I would love to have been able to track the movement of radio not only to its initial shipping destination, but also through its repair, and through its return shipment back to me. but I claim that the purpose of this group is to define how to track Internet mail, and the only standard protocol for transfer of Internet mail is SMTP. if you can find a way to make the protocol track messages (or parcels, whatever) over arbitrary transports, without modifying those transports, or making the protocol too complex, (don't forget to consider security requirements) and in such a way that the protocol is attractive to deploy , and which is not much more difficult than tracking SMTP messages, more power to you. what I don't accept is that it is necessary to widen the scope of this group to try to solve that problem. > >SMTP has explicit support for relaying. HTTP does not. I have a > >hard time understanding the need for message tracking when you only > >have two parties handling the message. > > Often the http server involved is the front end to a whole system (and may > indeed dump it to SMTP or some other message transfer mechanism for onward > delivery) I don't agree that the http server will always be an end-point. folks can use http as a user agent if they want to. but trying to use it as an intermediary for message transfer is something close to insane. HTTP doesn't (in practice) have the kind of status reporting necessary to say things like "I've accepted responsibility for delivery of this message". I really do not want this group to rathole on trying to define how to make HTTP work sanely enough so that you can track messages through it, when people shouldn't be relaying messages through it any way. > >there are probably good reasons to consider using an external protocol, > >but IMHO this isn't one of them. > > I suppose it comes down to the question - "Do you assume that any system or > user that needs to track messages must be doing so through a purely SMTP > environment ?" no, that's not the question. the question is whether this group can make more useful progress if it tries to solve the general message tracking problem, than if it tries only to solve the tracking problem for standard internet mail protocols. note that this is really a separate question from whether to do the queries through SMTP or some other protocol. Keith From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 17:48:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28525 for ; Fri, 28 Jul 2000 17:48:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19558 for ietf-msgtrk-bks; Fri, 28 Jul 2000 14:35:21 -0700 (PDT) Received: from d06lmsgate-2.emea.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19554 for ; Fri, 28 Jul 2000 14:35:19 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.emea.ibm.com (1.0.0) with ESMTP id WAA27258; Fri, 28 Jul 2000 22:25:58 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id WAA72626; Fri, 28 Jul 2000 22:38:06 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692A.0076D6F7 ; Fri, 28 Jul 2000 22:38:02 +0100 X-Lotus-FromDomain: IBMGB To: Keith Moore cc: ietf-msgtrk@imc.org Message-ID: <8025692A.0076D62B.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 22:32:22 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cutting to the bones ... msgtrk seems to have 2 thrusts (in addition to the framework) 1) a mechanism to provide and preserve a tracking id. 2) a mechanism to query the status. 1) Is defined only for SMTP. This I understand. If other transports need to provide or preserve this information then they will have to do so in an SMTP-friendly style. This limits the scope to a managable proportion. I agree that there is no value in turning the Tracking ID into some kind of monster that contains a "tracking id type", "originating system" or any other form of qualifier. If a message originates in a non-SMTP environment, but might need tracking through an SMTP one - then the ID should conform to the proposal, which is something that SMTP knows and loves. 2) Is what this discussion is all about. Do we have a new protocol or do we augment SMTP ? My belief is that, by choosing to augment the SMTP protocol to provide tracking information, we will end up with the situation where non-SMTP systems will put up an interface that will sit on the SMTP well-known port and behave in part like an SMTP server, but will, in fact, not be capable of Transfering Mail. They will simply be stubs for the msgtrk information that they need to provide. My contention is that, if we accept that such non-SMTP mail transfer systems are going to exist and they will wish to provide tracking information in a standard way - then this means we need to define a separate tracking protocol that can be implemented without pretending to be an impotent SMTP server. My question remains "do we accept that such non-SMTP mail transfer systems are going to exist and they will wish to provide tracking information in a standard way" All the stuff about screwdrivers and pocket-knives was trying to say that they do and they will. Paul From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 19:46:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24877 for ; Fri, 28 Jul 2000 19:46:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23612 for ietf-msgtrk-bks; Fri, 28 Jul 2000 16:35:15 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23607 for ; Fri, 28 Jul 2000 16:35:13 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA13118; Fri, 28 Jul 2000 19:38:30 -0400 (EDT) Message-Id: <200007282338.TAA13118@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: paulfordh@uk.ibm.com cc: Keith Moore , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 22:32:22 BST." <8025692A.0076D62B.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 28 Jul 2000 19:38:30 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ? All the stuff about screwdrivers and pocket-knives was trying to say that ? they do and they will. uh, no. it was trying to say that we shouldn't waste time trying to help people who misuse tools. From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 19:53:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26750 for ; Fri, 28 Jul 2000 19:53:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23740 for ietf-msgtrk-bks; Fri, 28 Jul 2000 16:46:00 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23736 for ; Fri, 28 Jul 2000 16:45:59 -0700 (PDT) Received: from monkeyboy.gshapiro.net (laslo.ne.mediaone.net [24.128.174.140]) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6SNn8199363 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Fri, 28 Jul 2000 16:49:17 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6SK6nx08757; Fri, 28 Jul 2000 13:06:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14721.59353.374276.494031@monkeyboy.gshapiro.net> Date: Fri, 28 Jul 2000 13:06:49 -0700 (PDT) From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: msgtrk-mtqp-00 comments X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The only document author is Tony but the page breaks list "Hansen, Allman". 2. Basic Operation - s/MTQP SERVER SENDS A GREETING/MTQP server sends a greeting/ - s/10 minutes' duration/10 minutes in duration/ (??) - Beyond an inactivity timeout, do we want to mention something like: "An MTQP server MAY limit the number of commands or total connection time to prevent denial of service attacks." 4. Track Command - The response is described as a "[MIME] mail message". I would prefer "[MIME] formatted part". To me, a "mail message" includes a Message-ID:, Date:, Received:, etc. headers. A MIME part does not. - We should have an example for the chaining response case: Example #XXX C: TRACK 1234567890ABCDEF S: +OK+ Tracking information follows S: Content-Type: multipart/report; report-type=tracking-status; S: boundary="1234567890ABCDEF" S: S: --1234567890ABCDEF S: Content-Type: message/tracking-status S: S: ... server1 details go here ... S: S: --1234567890ABCDEF S: Content-Type: message/tracking-status S: S: ... server2 details go here ... S: S: --1234567890ABCDEF-- S: . 9. IANA Considerations - Beyond "registered extensions", we also need a registered service name and port number. 10. Security Considerations - Since we are separating the protocol from SMTP, I think we should rely on only the security considerations of the other drafts. Specifically, this protocol has unique security considerations (see my next item). - Should mention use of an encrypted SMTP session, otherwise the tracking request is vulnerable to replay attacks such that outsiders who snoop a request can later get more information by sending the same information again (given that we don't have a shared secret to do APOP style authentication). 11. Protocol Syntax - There should be a blink line between the first text line and the beginning of the ABNF - There should be a newline before the second ';' comment character in the multi-char-success ABNF From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 19:53:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26763 for ; Fri, 28 Jul 2000 19:53:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23754 for ietf-msgtrk-bks; Fri, 28 Jul 2000 16:46:04 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23750 for ; Fri, 28 Jul 2000 16:46:03 -0700 (PDT) Received: from monkeyboy.gshapiro.net (laslo.ne.mediaone.net [24.128.174.140]) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6SNn8599363 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Fri, 28 Jul 2000 16:49:21 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6SJhhL08721; Fri, 28 Jul 2000 12:43:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14721.57967.329666.509057@monkeyboy.gshapiro.net> Date: Fri, 28 Jul 2000 12:43:43 -0700 (PDT) From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: msgtrk-model-02 comments X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 2. Definitions - Local Delivery Agent (DA): My personal opinion is this should be the "LDA" instead of the "DA". The "Local Delivery Agent" is a specific type of delivery agent (DA). 4. Requirements - We list a requirement of: "** SHOULD extend existing protocols and not invent new ones". However, we are inventing a new protocol (MTQP). We should therefore remove this requirement (or at least make it a MAY). From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 19:55:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27052 for ; Fri, 28 Jul 2000 19:55:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23767 for ietf-msgtrk-bks; Fri, 28 Jul 2000 16:46:17 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23763 for ; Fri, 28 Jul 2000 16:46:16 -0700 (PDT) Received: from monkeyboy.gshapiro.net (laslo.ne.mediaone.net [24.128.174.140]) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6SNn8799363 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK); Fri, 28 Jul 2000 16:49:23 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6SJd4g08712; Fri, 28 Jul 2000 12:39:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14721.57688.337073.596571@monkeyboy.gshapiro.net> Date: Fri, 28 Jul 2000 12:39:04 -0700 (PDT) From: Gregory Neil Shapiro To: Tony Hansen Cc: Keith Moore , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-Reply-To: <39818C7B.C3656FEA@att.com> References: <200007141805.OAA26863@astro.cs.utk.edu> <39818C7B.C3656FEA@att.com> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit tony> Good points: tony> can administer message tracking server separately tony> can do referrals to another server that is ONLY running MTQP server * Off loads the tracking work from the mail server. * There isn't a one to one match between MTA and tracking server. For example, consider a delivery to example.com which has the DNS records: example.com. IN MX 10 smtp.example.com. smtp.example.com. IN A 10.1.1.1 smtp.example.com. IN A 10.2.2.2 The message could go to either server. When tracking time comes, you don't know if the message went to 10.1.1.1 or 10.2.2.2 so holding the track server inside the SMTP protocol doesn't gain you anything. There would be one tracking server, that gathers information from both 10.1.1.1 and 10.2.2.2 in order to answer tracking requests for the name "smtp.example.com". tony> Bad points: tony> another protocol, another port tony> need to administer two servers now instead of just one moore> need to keep msgtrk servers in sync with MTAs. In response to Keith's bad point, yes, that is true but not a reason to include it within the SMTP protocol. That argument would mean that SMTP should do POP and IMAP as well since the final delivery MTA which handles local delivery to a mailbox and the POP server which reads mail from a mailbox must be kept in sync. Use compatible implementations doesn't require a single protocol. From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 19:55:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27242 for ; Fri, 28 Jul 2000 19:55:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23735 for ietf-msgtrk-bks; Fri, 28 Jul 2000 16:45:59 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23730 for ; Fri, 28 Jul 2000 16:45:57 -0700 (PDT) Received: from monkeyboy.gshapiro.net (laslo.ne.mediaone.net [24.128.174.140]) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6SNn8x99363 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Fri, 28 Jul 2000 16:49:12 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6SJqjG08736; Fri, 28 Jul 2000 12:52:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14721.58509.99070.300908@monkeyboy.gshapiro.net> Date: Fri, 28 Jul 2000 12:52:45 -0700 (PDT) From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: msgtrk-protocol-00 comments X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit General comments: 4. Additional Parameter for the MAIL FROM command - Is the SMTP command "MAIL" or "MAIL FROM"? - Do we want to entertain the idea of turning on tracking only for certain recipients? - s/after the recipient address/after the sender address/ (MAIL specifies sender, not recipient). 9. Authors' Addresses - Eric's address is 6603 Shellmound Street, Emeryville, CA 94608. - Eric can decide on the proper phone number to include. Assuming we are going with MTQP, the following changes should be made: 1. Introduction - "This memo defines an extension to the SMTP service that provides a message tracking solution that satisfies those requirements." - This isn't true, "this memo" will provide half of the solution with the msgtrk-mtqp draft providing the other half. 2. Framework - Remove "** a new SMTP verb, \"MTRK\" is defined." 5. Message Tracking Requests - Remove this section. 6.2. Message Tracking Request - Remove this section. If we are *not* going with MTQP, the following should be noted: 7. Security Considerations - Should mention use of an encrypted SMTP session, otherwise the tracking request is vulnerable to replay attacks such that outsiders who snoop a request can later get more information by sending the same information again (given that we don't have a shared secret to do APOP style authentication). From owner-ietf-msgtrk@mail.imc.org Fri Jul 28 20:21:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02895 for ; Fri, 28 Jul 2000 20:21:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA24104 for ietf-msgtrk-bks; Fri, 28 Jul 2000 17:12:39 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24100 for ; Fri, 28 Jul 2000 17:12:38 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA13807; Fri, 28 Jul 2000 20:15:39 -0400 (EDT) Message-Id: <200007290015.UAA13807@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Gregory Neil Shapiro cc: Tony Hansen , Keith Moore , ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-reply-to: Your message of "Fri, 28 Jul 2000 12:39:04 PDT." <14721.57688.337073.596571@monkeyboy.gshapiro.net> Date: Fri, 28 Jul 2000 20:15:39 -0400 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > moore> need to keep msgtrk servers in sync with MTAs. > > In response to Keith's bad point, yes, that is true but not a reason to > include it within the SMTP protocol. That argument would mean that SMTP > should do POP and IMAP as well since the final delivery MTA which handles > local delivery to a mailbox and the POP server which reads mail from a > mailbox must be kept in sync. Use compatible implementations doesn't > require a single protocol. point taken. Keith From owner-ietf-msgtrk@mail.imc.org Sat Jul 29 05:00:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10210 for ; Sat, 29 Jul 2000 05:00:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA26503 for ietf-msgtrk-bks; Sat, 29 Jul 2000 01:49:43 -0700 (PDT) Received: from d06lmsgate-3.emea.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26499 for ; Sat, 29 Jul 2000 01:49:40 -0700 (PDT) From: paulfordh@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.emea.ibm.com (1.0.0) with ESMTP id JAA103370; Sat, 29 Jul 2000 09:44:35 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.92) with SMTP id JAA128490; Sat, 29 Jul 2000 09:52:29 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025692B.0030BF1B ; Sat, 29 Jul 2000 09:52:26 +0100 X-Lotus-FromDomain: IBMGB To: Keith Moore cc: ietf-msgtrk@imc.org Message-ID: <8025692B.0030BD4F.00@d06mta07.portsmouth.uk.ibm.com> Date: Sat, 29 Jul 2000 09:49:55 +0100 Subject: Re: MSGTRK pre-drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >? All the stuff about screwdrivers and pocket-knives was trying to say that >? they do and they will. >uh, no. it was trying to say that we shouldn't waste time trying to help >people who misuse tools. Again a mis-communication - I meant "All the stuff that I was talking about, which you referred to with the line about screwdrivers and pocket-knives, was trying to say that they do and they will." Sorry for my ambiguous English. I editied for readability, thinking I had lost no clarity - obviously I was wrong. Paul From owner-ietf-msgtrk@mail.imc.org Mon Jul 31 01:06:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24007 for ; Mon, 31 Jul 2000 01:06:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25600 for ietf-msgtrk-bks; Sun, 30 Jul 2000 21:54:02 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25596 for ; Sun, 30 Jul 2000 21:54:00 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0/8.11.0) id e6V4vUm16749; Sun, 30 Jul 2000 21:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.1850.681815.613731@horsey.gshapiro.net> Date: Sun, 30 Jul 2000 21:57:30 -0700 (PDT) From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: Re: MSGTRK pre-drafts In-Reply-To: <14721.57688.337073.596571@monkeyboy.gshapiro.net> References: <200007141805.OAA26863@astro.cs.utk.edu> <39818C7B.C3656FEA@att.com> <14721.57688.337073.596571@monkeyboy.gshapiro.net> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit gshapiro> * Off loads the tracking work from the mail server. gshapiro> * There isn't a one to one match between MTA and tracking server. gshapiro> For example, consider a delivery to example.com which has the gshapiro> DNS records: gshapiro> example.com. IN MX 10 smtp.example.com. gshapiro> smtp.example.com. IN A 10.1.1.1 gshapiro> smtp.example.com. IN A 10.2.2.2 gshapiro> The message could go to either server. When tracking time comes, you gshapiro> don't know if the message went to 10.1.1.1 or 10.2.2.2 so holding the gshapiro> track server inside the SMTP protocol doesn't gain you anything. This point brings up another subtle issue. When an MUA submits a message which should be tracked, how does it know which system to contact using MTQP? MX and A records may change and the SMTP server isn't necessarily the MTQP server. A possible solution: 1. The EHLO "TRACK" reply include the hostname of the MQTP server: S: 220 smtp.ietf.org Greetings C: EHLO smtp.gshapiro.net S: 250-TRACK msgtrk.ietf.org S: 250 HELP or perhaps: S: 250-TRACK SERVER=msgtrk.ietf.org or perhaps: S: 250-TRACK SERVER=msgtrk1.ietf.org,msgtrk2.ietf.org Parameters on the reply could also allow for other information such as TTL=7D or something similar to indicate how long the server will be holding tracking data. 2. The MQTP protocol should support the ability to refer the client to another server in case the MTQP data is moved to another machine or for proxying. This ability is already being researched for the non-chaining case but regardless of whether chaining or referrals are used, we need the ability for other purposes such as this one. Ok, time for bed. From owner-ietf-msgtrk@mail.imc.org Mon Jul 31 10:33:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13473 for ; Mon, 31 Jul 2000 10:33:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08508 for ietf-msgtrk-bks; Mon, 31 Jul 2000 07:18:16 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [204.210.11.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08504 for ; Mon, 31 Jul 2000 07:18:13 -0700 (PDT) Received: from [169.254.102.15] (147.73.133.131) by turing.pensive.org with ESMTP (Eudora Internet Mail Server 3.0) for ; Mon, 31 Jul 2000 07:21:03 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora v5.0b8 for Macintosh Date: Mon, 31 Jul 2000 10:21:59 -0400 To: ietf-msgtrk@imc.org From: Randall Gellens Subject: msgtrk-model comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Originating Mail Submission Agent (MSA) > The Mail Submission Agent accepts a message from a User > Agent, adds or modifies whatever headers are appropriate > for the message's traversal through the Internet, and > injects the message into the network via a Message > Transfer Agent. An MSA is used, in lieu of the first MTA > by MUA's that do not create fully-compliant Internet mes- > sages, to submit messages into the SMTP delivery network. I'd suggest using: The Mail Submission Agent accepts a message from a User Agent, adds or modifies it as required for Internet standards and/or site policy, and injects the message into the network. The MSA may be the initial MTA or may hand off messages to an MTA. Minor nit: "them" is used with a singular noun in Section 6: > delegate his or her tracking > request to a third party by sending them A I think this should be changed to use "it". From owner-ietf-msgtrk@mail.imc.org Mon Jul 31 15:32:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00985 for ; Mon, 31 Jul 2000 15:32:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19827 for ietf-msgtrk-bks; Mon, 31 Jul 2000 12:20:30 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19822 for ; Mon, 31 Jul 2000 12:20:27 -0700 (PDT) Received: from monkeyboy.gshapiro.net (root@wireless-133-18.ietf.marconi.com [147.73.133.18]) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6VJNpN25319 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Mon, 31 Jul 2000 12:23:59 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6VJN0E07728; Mon, 31 Jul 2000 12:23:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.53779.649438.431875@monkeyboy.gshapiro.net> Date: Mon, 31 Jul 2000 12:22:59 -0700 (PDT) From: Gregory Neil Shapiro To: ietf-msgtrk@imc.org Subject: IETF 48: Message Track WG Meeting Notes X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Monday, July 31, 2000 13:00 Message Tracking Review current status - Want to finish within one or two more IETF meetings - Current document includes updates requested in Adelaide Model Document - Greg and Randy's comments in the mailing list will be addressed in a new, last-call draft Message Tracking Report Format - MIME message/tracking-status type - Steal from DSNs where-ever possible - Don't appear to need additional Action: values - How to handle referrals/rejections of query - In MIME report or in MTQP response - Add field "Remote-Tracking-Server:"? - Make it optional - Aversion to storing remote tracking server in tracking database - Therefore MTQP needs to handle requests for all possible resolutions of a Remote-MTA hostname. Message Tracking SMTP Extensions - TRACK EHLO response - Needed to introduce a new truly unique global message identifier - Should be ok - MAIL command MTRK= parameter specifies ID and possibly a timeout - Change to per-recipient tracking instead of per-message? - Match DSN behavior, move MTRK to RCPT instead of MAIL - Need to look at HMAC (MD5 alone of a concat isn't safe, ways to get back the secret). - Tag method used. - Chris volunteers to help with language. - Put authenticator information in this document instead of protocol - Advertise the TTL for tracking information on system? - Probably not the correct place since MTQP, not SMTP manages this Message Tracking Query Protocol - Move from part of SMTP to a separate protocol - Pros: - DoS attacks - Can administer server separately - Can do referrals to an MTQP-only sever - Offloads work from SMTP server - No 1-1 match between MTA and MTQP server - Could support tracking beyond foreign MTA gateways - Parallel w/ POP & IMAP for access - Cons: - Another protocol - Another port - Admin two servers instead of one - Need to keep MTQP server in sync with MTAs - IANA considerations - Keep as separate protocol (hum of consensus) - Steve will confirm on list - Commands: - Simple VERB PARAM ... CRLF - Verbs are case insensitive - Verbs defined are: - TRACK - NOOP - QUIT - Add STARTTLS as optional (unanimous hum of consensus) - Positive Responses - Current - Single line: +OK status info CRLF - Multi line: +OK+ status info CRLF - dot stuffed (simpler) - +OK+ status {count} CRLF - handles complex responses - Need both dot-stuff and count? - Crowd appears to feel dot-stuffing is fine - Negative responses - Current - -TEMP reason CRLF: temporary failure - -ERR reason CRLF: permanent failure - -BAD reason CRLF: protocol error - Desire for hierarchical error codes - Machine readable and extensible - Change to form: "-TEMP" *[ / "..."] - ... is a extensible token - Make clear distinction between -BAD and -ERR - Startup with a positive reply and optional list of capabilities/extensions. - STARTTLS will be the first extension - Have MTQP be listed in greeting (+OK+/MTQP) - Need an immediate referral mechanism - Tony to produce syntax for the next document revision - "-NO+ mtqp://tracking.server.fqdn/" (??) - NOOP command - NOOP - QUIT command - QUIT *ws - Crowd requests removal of *ws - TRACK command - ABNF: "TRACK" 1*WS tracking-id 1*WS auth-cookie *WS CRLF - Allow arbitrary WS? - If keep, need to show in example - Drop trailing *WS usage. - Chris volunteers to help with Security Considerations section Last time - Tracking at a firewall - Unique message identifier - Authentication review - Chris wrote, will help Eric with more work to be done - What happens if next step doesn't support tracking? - DoS attacks by tracking request saturations - Other security issues Summarize action items - Combine report format and tracking protocol into one document - But if MIME, need to keep as three documents - Will keep separate - Tony -01 draft - Eric -00 drafts - Deadline: August 30 From owner-ietf-msgtrk@mail.imc.org Mon Jul 31 21:41:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29203 for ; Mon, 31 Jul 2000 21:41:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA29604 for ietf-msgtrk-bks; Mon, 31 Jul 2000 18:30:37 -0700 (PDT) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29598 for ; Mon, 31 Jul 2000 18:30:36 -0700 (PDT) Received: from [10.81.78.127] (vpnap-g1-012068.qualcomm.com [10.13.12.68]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id SAA05938; Mon, 31 Jul 2000 18:33:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <14725.53779.649438.431875@monkeyboy.gshapiro.net> References: <14725.53779.649438.431875@monkeyboy.gshapiro.net> X-Mailer: QUALCOMM Eudora v5.0b8 for Macintosh Date: Mon, 31 Jul 2000 21:27:59 -0400 To: Gregory Neil Shapiro , ietf-msgtrk@imc.org From: Randall Gellens Subject: Re: IETF 48: Message Track WG Meeting Notes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:22 PM -0700 7/31/00, Gregory Neil Shapiro wrote: > - Change to per-recipient tracking instead of per-message? My recollection is that there was general consensus to do this. From owner-ietf-msgtrk@mail.imc.org Mon Jul 31 21:43:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29628 for ; Mon, 31 Jul 2000 21:43:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA29772 for ietf-msgtrk-bks; Mon, 31 Jul 2000 18:32:45 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29767 for ; Mon, 31 Jul 2000 18:32:43 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0/8.11.0) id e711aHT27226; Mon, 31 Jul 2000 18:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14726.10641.530752.220659@horsey.gshapiro.net> Date: Mon, 31 Jul 2000 18:36:17 -0700 (PDT) From: Gregory Neil Shapiro To: Randall Gellens Cc: ietf-msgtrk@imc.org Subject: Re: IETF 48: Message Track WG Meeting Notes In-Reply-To: References: <14725.53779.649438.431875@monkeyboy.gshapiro.net> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >> - Change to per-recipient tracking instead of per-message? randy> My recollection is that there was general consensus to do this. Yes, sorry I forgot to remove the '?'.