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

: From:  Chris Newman <[email protected]>
: 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 [email protected] 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