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 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>) ;
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 ietf(_at_)megatron(_dot_)ietf(_dot_)org
original-envelope recepient=ietf(_at_)ietf(_dot_)org,
return-path=user(_at_)example(_dot_)com,
submitter=user(_at_)example(_dot_)com
new-envelope recepient=william(_at_)elan(_dot_)net,
return-path=ietf(_at_)ietf(_dot_)org, submitter=ietf(_at_)ietf(_dot_)org
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: ietf(_at_)ietf(_dot_)org
Original-Sender: secretary(_at_)example(_dot_)org
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: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/