Re: Processed-By (or Transmitted-By) header concept

[jm@xxxxxxxxxx (Justin Mason)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Danny Angus writes:
> William,
> 
> The problem I see with this is that multiple hops cannot be used in
> conjunction with New-xx and Original-xx headers.
> What you'd have to do would be to use a single header which both identifies
> the hop that changed the headers and records the change.
> 
> Lets assume that the regular headers are rewritten and therefore contain
> the "new" values, so we only really need to preserve the history.
> That can be accomodated in the "Processed by" by simply inserting the
> original values for the fields logged as changed.
> 
> Processed-By: odin.ietf.org (ip=[132.151.1.176])
>   on-behalf-of ietf@xxxxxxxxxxxxxxxxx
>   changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue,
> 
> Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue
> 
>   process-type maillist (list-id=<ietf.ietf.org>) ;
> 
> As for the name, call it like it is. If this is to address the issues of
> automatic (c.f. by a users explicit action) re-insertion of messages into
> the delivery system call it
> "Reinserted-by"
> 
> But... also add a timestamp so we can accurately order these things
> 
> Reinserted-By: odin.ietf.org (ip=[132.151.1.176])
>   on-behalf-of ietf@xxxxxxxxxxxxxxxxx
>   changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue,
> 
> Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue
> 
>   process-type maillist (list-id=<ietf.ietf.org>) ; Tue, 28 Sep 2004
> 00:43:21 -0700 (PDT)
> 
> At the end of the day though it still looks like a mechanism by which
> someone could fabricate a whole imagined history for a message, rather than
> anything upon which we could rely.

I think that's unavoidable in a lot of cases -- the best approach to
deal with that is to either

  - (a) do not trust anything that wasn't added by a machine on
    your own network, or

  - (b) know where your "trust boundaries" lie, and stop looking
    once the message has gone one step beyond that boundary, since
    any other tracking info is possibly forged.

This is the approach we take in SpamAssassin when dealing with
Received headers.

- --j.

> d.
> 
> ---
> Danny Angus
> (apache james)
> 
> > Together with it introduced are
> > Original-???? headers which are to be used to preserve original
> > values of the headers that are being changed.
> 
> ***************************************************************************
> 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 Limi!
>  ted.
> 
> This footnote also confirms that this email message has been swept for the presence of computer viruses.
> 
> **************************************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFBWbelQTcbUG5Y7woRAinfAJ9baMvdKH5H1Z42n2BBoiPRBRMXfQCcCLmH
z4v5dh3Jc5MdwYuD6/Hmb18=
=tnhX
-----END PGP SIGNATURE-----