Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept

William,

<snipped some stuff I'm not going to disagree with/>

> So here is example of new format
> that I propose for this trace header:

Processed-By: odin.ietf.org (ip=[132.151.1.176])
   on-behalf-of [email protected]
   original-envelope [email protected],
    [email protected], [email protected]
   new-envelope [email protected],
     [email protected], [email protected]
   changed-headers To, List-ID, Sender, CC
   process-type maillist (list-id=<ietf.ietf.org>) ;
    Tue, 28 Sep 2004 00:43:21 -0700 (PDT)
Original-To: [email protected]
Original-Sender: [email protected]


I think it is too much (header bloat, to coin a phrase), but I don't have
anything very constructive to say at this point beyond that fact that I
believe we should take every step to avoid duplication of information in
(or between) the envelope or(/and) the message headers.

Meaning that I would prefer (simply as a purist) a standard which mandated
existing optional behaviour, rather than duplicate the optional with a
mandatory alternative.
Instead of MAY add some piece of data to an existing header type, make it
SHOULD instead and already those people who implement the option will be
compliant with that new thing and messages won't bloat.

<more sniping..>

>The header is intended for use by MTAs doing automated procesing
>during transmission of the message, not by processes done by MUA.
>In fact the text might even state that if user-action forwarding
>is done than it maybe more appropriate to use Resent- headers
>instead of Procesed-By header.

Ok I already got this, it relates to .forward, .aliases and mailinglist
scenarios.
The only reason we believe that we can't use Resent headers...:

" Resent fields SHOULD be added to any message that is reintroduced by
   a user into the transport system.  A separate set of resent fields
   SHOULD be added each time this is done."

... is ...:

" They MUST NOT be used in the normal
   processing of replies or other such automatic actions on messages."

So if there is any requirement at all it is to handle
"automatic actions on a message by which that message is automatically
reintroduced _on behalf of_ a user into the transport system"

Hence I still maintain that "Reinserted" or "Reintroduced" would
disambiguate the purpose of the headers, and compliment "Resent".

<more snipping/>

I agree with your brief analysis of security, in particular with the point
that it would be no less trustworthy than any existing mechanism. However I
will continue to question the value of having such a big new burden (the
transport and processing of all that new data) without there being any
mechanism to ensure that it has any real added-value for the recipient at
all.

d.




***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those o
 f the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************