Subject: I-D ACTION:draft-ietf-msgtrk-smtpext-01.txt

From: [email-masked]
Date: Mon, 26 Mar 2001 18:37:36 -0500

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		: SMTP Service Extension for Message Tracking
	Author(s)	: E. Allman, T. Hansen
	Filename	: draft-ietf-msgtrk-smtpext-01.txt
	Pages		: 7
	Date		: 23-Mar-01
	
This  memo  defines an extension to the SMTP service whereby a   client may mark a message for future tracking.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-smtpext-01.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-smtpext-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-msgtrk-smtpext-01.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.

---

From: Chris Newman <[email-masked]>
Date: Wed, 28 Mar 2001 16:33:27 -0800

--On Monday, March 26, 2001 18:37 -0500 [email-masked] wrote:

> 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.
>

Missing the reference for [RFC-RANDOM]:
    Eastlake, D., Crocker, S. and J. Schiller, "Randomness
    Recommendations for Security", RFC 1750, December 1994.

----
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.

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 [email-masked] address forwarded to an individual.  Perhaps the 
site doesn't want that individual's name known to reduce headhunter calls.

----
           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.

		- Chris

---

From: Steve Hole <[email-masked]>
Date: Thu, 29 Mar 2001 11:34:16 -0700

> redirect) which may require a site-level or user-level choice.

I think that we should presume that sieve redirection is done during final
delivery and is directed by the user 100% of the time.   I'm sure that 
there are arguments for other uses which is fine, but I think that it 
intent that matters.   If it is a user rule, then it is final delivery and
that is in MUA land.   Final delivery through the sieve engine should 
terminate tracking (I think).

> site doesn't want that individual's name known to reduce headhunter calls.

Hmm ... so this would typically hit the aliasing engine in most MTA's.   
Unless I'm mistaken, we have recommended treating this exactly as DSN 
does, which I believe differentiates between final recipient and original 
recipient.   Does the DSN spec allow for site specification of whether or 
not they will report differences between orignal and final recipient?

In any case, the answer to the above question doesn't really matter.   We 
should just do as DSN does I think.

Cheers.

---
Steve Hole
Chief Technology Officer
ACI - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922