On Tue, 2004-09-28 at 12:12, Justin Mason wrote:
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.
This is also a good reason to reconsider the use of an authenticated
HELO domain and Received headers. This name never relies upon anything
beyond the adjacent agent outside the local domain. It is dead simple
for a mailbox domain to reference a list of root names for all approved
mail transfer agents. Use this information, obtained in one DNS query,
to detect spoofing. No address entries are needed to support this
mechanism and open-ended lists are not a problem.
-Doug