ietf-mxcomp
[Top] [All Lists]

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

2004-09-28 12:12:51

-----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(_at_)megatron(_dot_)ietf(_dot_)org
  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(_at_)megatron(_dot_)ietf(_dot_)org
  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-----