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

--On Monday, March 26, 2001 18:37 -0500 [email protected] 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.
>
>	 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

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 protected] 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