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

And FYI - I really do appreciate all suggestions I received both public 
and private ones. They are all very helpfull and even if I do not respond
to you directly, I'm gratefull for you participation in development
of this idea.

William

On Tue, 28 Sep 2004, william(at)elan.net wrote:

> On Tue, 28 Sep 2004, Danny Angus wrote:
> 
> > 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.
> 
> I'll have recomendations how they can, basicly saying that Original-*
> headers that follow Processed-By and that are specifically mentioned in
> Processed-By changed list should be considered to be part of the same
> trace data.
>  
> > 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 [email protected]
> >   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>) ;
> 
> I partially agree with it, especially as it concerns envelope data.
> I note that RFC2821 identities are in standard mailbox format and its
> easier to add them as part of the header line, but RFC2822 headers
> have more complex structure and its difficult to encapsulate them
> as part of trace header, so I prefer to simly allow MTAs to copy them
> as is into "Original-" header.
> 
> So my solution is thus that changes to envelope data would be reported
> as part of the Processed-By header (just like it is done currently
> in Received headers) but that Original-xxx headers stay for reporting
> values that RFC2822 headers had before they were changed.
> 
> Youre suggestion about timestamp is also appropriate and I already thought
> it might be good idea myself before too. 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 [email protected]
>    original-envelope [email protected],
>     [email protected], [email protected]
>    new-envelope [email protected], 
>      [email protected], [email protected]
>    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: [email protected]
> Original-Sender: [email protected]
> 
> 
> I'll note that NOT ALL headers that are listed in "changed-headers"
> are present as separate Original-* headers. Those that are not present
> are considered to have been added rather then changed, so of the above
> the two headers that have been changed are "To" and "Sender" while
> "CC" and "List-ID" have beed added by mail list but there were not
> previously in the email message data. This brings the question if it is 
> better to separate these into "changed-headers" and "added-headers"?
> 
> > 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"
> 
> 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. That is why my original name was
> "Trasmitted-By" - it reflects that changes are being done during
> transmission of the message, however the name does not well show
> that header informs about changes in message parameters, so I think
> I'm going to continue with "Processed-By" name.
> 
> > 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.
> 
> That is obsolutely true and I'll have to mention this in the "Security 
> Considerations" section. So this header is nothing more then new kind
> trace header like Received that is intended to aid systems that are 
> trying to see what happened to the message in transit and they are 
> supposed to view this with the same level of believe as received headers.
> 
> However if ultimately we develop an automated email signature system
> than it would be possible to provide by means of encryption algorithm
> to confirm that headers were indeed added by whoever claimed it and
> then its a matter if you trust that system to report what happened 
> to email in truthfull way or not. 
> 
> On this note, in the next version of MTA Signatures proposal, I'll have a 
> better way to sign trace headers (actually it'll look closer to Yahoo DK 
> with header signature line that will reflect signing of multiple headers 
> proceeding the line - but with actual encryption data being still in the 
> separate PKCS7 MIME attachment).
> 
> ---
> William Leibzon, Elan Networks:
>  mailto: [email protected]
> Anti-Spam and Email Security Research Worksite:
>  http://www.elan.net/~william/emailsecurity/