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 ietf(_at_)megatron(_dot_)ietf(_dot_)org
original-envelope recepient=ietf(_at_)ietf(_dot_)org,
return-path=user(_at_)example(_dot_)com,
submitter=user(_at_)example(_dot_)com
new-envelope recepient=william(_at_)elan(_dot_)net,
return-path=ietf(_at_)ietf(_dot_)org, submitter=ietf(_at_)ietf(_dot_)org
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: ietf(_at_)ietf(_dot_)org
Original-Sender: secretary(_at_)example(_dot_)org
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 of the sender and may not reflect the
opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the
presence of computer viruses.
**************************************************************************