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

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

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@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.

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