From owner-ietf-msgtrk@mail.imc.org Thu Apr 5 20:25:08 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16864 for ; Thu, 5 Apr 2001 20:25:07 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA28261 for ietf-msgtrk-bks; Thu, 5 Apr 2001 17:21:40 -0700 (PDT) Received: from knecht.Neophilic.COM (knecht.sendmail.org [209.31.233.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA28257 for ; Thu, 5 Apr 2001 17:21:38 -0700 (PDT) Received: from jean-baptiste.sendmail.org (natted.Sendmail.COM [63.211.143.38]) by knecht.Neophilic.COM (8.12.0.Beta5/8.12.0.Beta7) with ESMTP id f360LdqD092475 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 5 Apr 2001 17:21:42 -0700 (PDT) Received: from jean-baptiste.sendmail.org (localhost.sendmail.org [127.0.0.1]) by jean-baptiste.sendmail.org (8.11.1.Alpha0/8.11.1.Alpha0) with ESMTP id f35MxkM08616; Thu, 5 Apr 2001 15:59:46 -0700 (PDT) Message-Id: <200104052259.f35MxkM08616@jean-baptiste.sendmail.org> X-Mailer: exmh version 2.1.2 06/08/2000 To: Chris Newman From: Eric Allman X-URL: http://WWW.Sendmail.ORG/~eric cc: ietf-msgtrk@imc.org Subject: Re: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt In-reply-to: Mail from Chris Newman dated Wed, 28 Mar 2001 16:33:27 PST <158887.985797207@nifty-jr.west.sun.com> Date: Thu, 05 Apr 2001 15:59:46 -0700 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: : From: Chris Newman : Date: Wed, 28 Mar 2001 16:33:27 -0800 : Missing the reference for [RFC-RANDOM]: : Eastlake, D., Crocker, S. and J. Schiller, "Randomness : Recommendations for Security", RFC 1750, December 1994. Fixed, thanks. : This paragraph from 4.2: : : Any retransmissions of this message MUST assign a new : ENVID. In this context, "retransmission" includes forwarding or : resending a message. : : appears to contradict this paragraph from 4.3: : : If aliasing, forwarding, or other redirection of messages : to a single recipient occurs, then the MTA SHOULD treat this as : an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, : and ORCPT= values; these values MUST NOT be modified. : ---- : I think you need to distinguish between the different types of forwarding. : One class is "public automated unconditional MTA-level forwarding" which is : always tracked. Private manual conditional UA-level forwarding is likely : never tracked. Then there's a bunch of gray areas (e.g., MTA-level Sieve : redirect) which may require a site-level or user-level choice. I've changed 4.2 to read: Any resubmissions of this message into the message trans- mission system MUST assign a new ENVID. In this context, "resubmission" includes forwarding or resending a message from a user agent, but does not include MTA-level aliasing or forward- ing where the message does not leave and re-enter the message transmission system. : Some discussion of the privacy issues with respect to tracking forwarded : messages is in order. If the forwarding isn't public information, the : tracking system may need to suppress some of the results. An example would : be a webmaster@domain.com address forwarded to an individual. Perhaps the : site doesn't want that individual's name known to reduce headhunter calls. I've added the following paragraph to 5.2: In some cases site administrators may want to treat deliv- ery to an alias as final delivery in order to separate roles from individuals. For example, sites implementing ``postmas- ter'' or ``webmaster'' as aliases may not wish to expose the identity of those individuals by permitting tracking through those aliases. Does this address your concern? : ---- : MTAs SHOULD take precautions to make certain that message : tracking cannot be used to explore internal topologies of net- : works. : ---- : I think this is too strong. Trying to hide internal names and topologies : through obfuscation is little more than security through obscurity and in : practice can reduce security since it can make attacks harder to trace. : I'd say: : : Many sites believe that concealing names and topologies of internal : systems is an important security feature. MTAs need to balance : such desires with the need to obtain adequate tracking information : for inappropriate messages, including those from internal sources. I reworded this slightly: Many site administrators believe that concealing names and topologies of internal systems and networks is an important security feature. MTAs neeed to balance such desires with the need to provide adequate tracking information. : - Chris : eric From owner-ietf-msgtrk@mail.imc.org Thu Apr 5 20:25:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16887 for ; Thu, 5 Apr 2001 20:25:27 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA28296 for ietf-msgtrk-bks; Thu, 5 Apr 2001 17:23:07 -0700 (PDT) Received: from knecht.Neophilic.COM (knecht.sendmail.org [209.31.233.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA28288 for ; Thu, 5 Apr 2001 17:23:02 -0700 (PDT) Received: from jean-baptiste.sendmail.org (natted.Sendmail.COM [63.211.143.38]) by knecht.Neophilic.COM (8.12.0.Beta5/8.12.0.Beta7) with ESMTP id f360LnqD092478 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 5 Apr 2001 17:23:05 -0700 (PDT) Received: from jean-baptiste.sendmail.org (localhost.sendmail.org [127.0.0.1]) by jean-baptiste.sendmail.org (8.11.1.Alpha0/8.11.1.Alpha0) with ESMTP id f360LMM08968; Thu, 5 Apr 2001 17:21:22 -0700 (PDT) Message-Id: <200104060021.f360LMM08968@jean-baptiste.sendmail.org> X-Mailer: exmh version 2.1.2 06/08/2000 To: Chris Newman From: Eric Allman X-URL: http://WWW.Sendmail.ORG/~eric cc: ietf-msgtrk@imc.org Subject: Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt In-reply-to: Mail from Chris Newman dated Wed, 28 Mar 2001 17:08:27 PST <285171.985799306@nifty-jr.west.sun.com> Date: Thu, 05 Apr 2001 17:21:22 -0700 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: : From: Chris Newman : Date: Wed, 28 Mar 2001 17:08:27 -0800 : Message tracking is intended for use as a "last resort" mecha- : nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- : SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would : provide the primary delivery status. Only if no response from : either of these mechanisms would Message Tracking be used. : : The last sentence needs a verb. Fixed. : A Message Tracking Status Notification (MTSN) is intended to : be returned as the body of a Message Tracking request [DRAFT-MTRK- : MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] : with type of "tracking-status"; each subpart MUST be type "mes- : sage/tracking-status" as described herein. : : The multipart/related type parameter takes a media type, so: : : ... The actual body MUST be a multipart/related [RFC-RELATED] : with type parameter of message/tracking-status. Fixed. : ... That body consists of one or more "fields" for- : matted to according to the ABNF of RFC 822 headers "fields" (see : [RFC-MSGFMT]). : : headers -> header Fixed. : The body of a message/tracking-status is modeled after : [RFC-DSN-STAT]. That body consists of one or more "fields" for- : matted to according to the ABNF of RFC 822 headers "fields" (see : [RFC-MSGFMT]). The per-message fields appear first, followed by : a blank line. Following the per-message fields are one or more : groups of per-recipient fields. Each group of per-recipient : fields is preceded by a blank line. Formally, the syntax of the : message/tracking-status content is as follows: : : I'd be inclined to add something like: : : Note that there will be a blank line between the final per-recipient field : and the MIME boundary, since one CRLF is necessary to terminate the field, : and a second is necessary to introduce the MIME boundary. Agreed. : delivered The message has been successfully delivered to : the final recipient. This includes "delivery" : to a mailing list exploder. It does not indi- : cate that the message has been read. No further : information is available; in particular, the : tracking agent SHOULD NOT attempt further "down- : stream" tracking requests. : : expanded The message has been successfully delivered to : the recipient address as specified by the : sender, and forwarded by the Reporting-MTA : beyond that destination to multiple additional : recipient addresses. However, these additional : addresses are not trackable, and the tracking : agent SHOULD NOT attempt further "downstream" : tracking requests. : ... : The tracking algorithms MUST NOT allow tracking through : list expansions. When a message is delivered to a list, a : tracking request MUST respond with an "expanded" tracking status : and MUST NOT display the contents of the list. : : I'm unclear under what conditions to use "delivered" or "expanded" for : mailing lists or aliases. Please fix. This wording was taken nearly as is from 1894, and the intent was to keep things fairly parallel to that spec. I'm open to suggestions. Anyone? : ---- : 3.5. Interaction Between MTAs and LDAs : : A message that has been delivered to an LDA that under- : stands message tracking (in particular, an LDA ... : : You need to associate "LDA" with the expansion of the acronym in section : 3.3.5. Either expand it once here as well, or use the acronym in 3.3.5. I'm expanding it in 3.5. : A note on my security consideration suggestion for the SMTPEXT document, a : reference to the security considerations section in this document would : suffice. Already dealt with, as indicated in my previous message. Do you still think a cross-reference is warranted? : - Chris Thanks for the comments. eric From owner-ietf-msgtrk@mail.imc.org Thu Apr 5 21:00:45 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17214 for ; Thu, 5 Apr 2001 21:00:45 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id RAA00887 for ietf-msgtrk-bks; Thu, 5 Apr 2001 17:57:38 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA00883 for ; Thu, 5 Apr 2001 17:57:36 -0700 (PDT) Received: from i-gotmail (i-gotmail.red.iplanet.com [192.18.73.46]) by netscape.com (8.10.0/8.10.0) with ESMTP id f360vGS18142; Thu, 5 Apr 2001 17:57:16 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built Mar 11 2001)) with ESMTP id <0GBC00JCBIN74H@we-gotmail.red.iplanet.com>; Thu, 05 Apr 2001 17:57:08 -0700 (PDT) Date: Thu, 05 Apr 2001 17:57:14 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt In-reply-to: <200104060021.f360LMM08968@jean-baptiste.sendmail.org> To: Eric Allman Cc: ietf-msgtrk@imc.org Message-id: <1772928.986493434@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.1.0a3 (Mac OS/PPC) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <200104060021.f360LMM08968@jean-baptiste.sendmail.org> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT --On Thursday, April 5, 2001 17:21 -0700 Eric Allman wrote: > This wording was taken nearly as is from 1894, and the intent was to > keep things fairly parallel to that spec. I'm open to suggestions. > Anyone? My suggestion is to use "expanded" for _all_ cases where there are multiple recipients. If a user sends to a list and gets a "delivered" notification, their assumption will be that the message has been delivered to all list recipients. So any use of "delivered" with a multiple recipients is likely to result in a "user astonishment" scenario. Since those are bad, stick to "expanded". The only caveat would be if a site has a local alias sent to multiple recipients, and wishes to conceal the fact the address is a list. Then "delivered" would be OK. > Already dealt with, as indicated in my previous message. Do you still > think a cross-reference is warranted? A non-normative cross-reference would be nice. When I'm considering only the security implications of a protocol, I look only at the security considerations and anything it references. But the text you added is good enough. - Chris From owner-ietf-msgtrk@mail.imc.org Thu Apr 5 21:57:07 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18738 for ; Thu, 5 Apr 2001 21:57:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA03040 for ietf-msgtrk-bks; Thu, 5 Apr 2001 18:54:26 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA03034 for ; Thu, 5 Apr 2001 18:54:24 -0700 (PDT) Received: from i-gotmail (i-gotmail.red.iplanet.com [192.18.73.46]) by netscape.com (8.10.0/8.10.0) with ESMTP id f360g0S16095; Thu, 5 Apr 2001 17:42:00 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built Mar 11 2001)) with ESMTP id <0GBC00J85HXP4H@we-gotmail.red.iplanet.com>; Thu, 05 Apr 2001 17:41:50 -0700 (PDT) Date: Thu, 05 Apr 2001 17:41:58 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt In-reply-to: <200104052259.f35MxkM08616@jean-baptiste.sendmail.org> To: Eric Allman Cc: ietf-msgtrk@imc.org Message-id: <1717876.986492518@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.1.0a3 (Mac OS/PPC) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <200104052259.f35MxkM08616@jean-baptiste.sendmail.org> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT --On Thursday, April 5, 2001 15:59 -0700 Eric Allman wrote: > I've added the following paragraph to 5.2: > > In some cases site administrators may want to treat deliv- > ery to an alias as final delivery in order to separate roles > from individuals. For example, sites implementing ``postmas- > ter'' or ``webmaster'' as aliases may not wish to expose the > identity of those individuals by permitting tracking through > those aliases. > > Does this address your concern? Not bad, but I'd be tempted to add something like: In other cases, providing the tracking information for an alias is important, such as when the alias points to the user's preferred public address. > Many site administrators believe that concealing names and > topologies of internal systems and networks is an important > security feature. MTAs neeed to balance such desires with the > need to provide adequate tracking information. Sounds good to me, but "need" only has two "e"s. - Chris