ietf-mailsig
[Top] [All Lists]

Re: Duplication of headers for email signatures

2004-11-15 21:09:36
At 01:37 PM 11/15/04 -0800, Jim Fenton wrote:
Identified Internet Mail includes the copied headers as part of the IIM-Signature header. As far as I can tell, this handles all of the cases you're describing. Is there a problem with this approach that is solved by having separate copied headers?

No problems there. In fact if the originator signs, say Subject:, Sender: and Date: and then each forwarder signs Resent-Sender:, Subject: and Resent-Date: then IIM tracks all changes in those fields. I wonder why there'd be a need to track changes in headers not included in the signature, nothing could be verified.

Ed

<mailto:EdLevinson(_at_)ResultsLifeCoaching(_dot_)com>EdLevinson(_at_)ResultsLifeCoaching(_dot_)com wrote:
On the subject of names for headers containing the original names the name needs to convey what information the header contains, a brainstorming session generating lots of choices could be useful.

We must also deal, as you've suggested, with multiple changes. I'm concerned about asking MTAs to preserve grouping a set of headers. We know we can't count on order being preserved today. Here's a suggestion, use Changed-<header name>: From=<original>; To=<new>. A bit wordy I'll admit but it allows tracing the changes without imposing additional effort on MTAs

Ed

At 10:03 PM 11/4/04 -0800, william(at)elan.net wrote:
On Thu, 4 Nov 2004 <mailto:EdLevinson(_at_)ResultsLifeCoaching(_dot_)com>EdLevinson(_at_)ResultsLifeCoaching(_dot_)com wrote:

> At 07:51 PM 11/4/04 -0800, william(at)elan.net wrote:
> >P.S. The prefix name "Duplicated-" is just example, I've no idea what is
> >good prefix name to use for something like this, if you have good name
> >for it, please say so.
>
> A suggestion:
> In a group of Resent- headers, say from a mailing list that alters the
> Subject: and From:, the list agent could add Resent-Unaltered-Subject: and
> Resent-Unaltered-From:.  I believe this clearly describes what happened.
>
> "Resent-Unaltered-" would be the standard prefix. This form also provides
> easy extension to other situations.

It would be better to stay away from "Resent-" headers because they are
used in case of manual forwarding (reinjection of the message that was
delivered for delivery to new person) and are used to represent the name
of the person (and other new message parameters) who is reinserting
the message.

I'm however considering replacing concept of Original-* and New-* headers
from emailredirection-traceheaders draft with one new type of header
(most likely Original-*) with meaning that it represents value of the
header at the time it was added. So in case when header is added
before "Redirected:" header its the value before redirection occured
(i.e. before forwarding or mail list processing) while New-* would be
replaced by having the same header added above "Redirected:" header
representing new changed value after the redirection.

In this concept its also not necessary for all headers to be put together
as one batch, all mail program needs to do is make sure that first from
the top header of this name (i.e. Original-From) has the same value as
"From:" and then it does not need to add it again. This is works well for
mail signatures, i.e. it is not necessary for program adding mail
signature to duplicate the headers value each time (i.e. when message
is resigned by next MTA), it just needs to make sure the previously added
Duplicated- header (which might have been added by MTA that added previous
signature or possibly added by forwarder after Redirected header) has the
same value as real header at the time signature is added (and if its not
only then does it add new Duplicated- trace header).

--
William Leibzon
Elan Networks
<mailto:william(_at_)elan(_dot_)net>william(_at_)elan(_dot_)net

Ed Levinson  47 Clive Street  Metuchen, NJ 08840  USA
A Coach for Technology Professionals
T: +1 732 494 1606  F: +1 732 494 4495
mailto:EdLevinson(_at_)ResultsLifeCoaching(_dot_)com 
http://www.ResultsLifeCoaching.com
<Prev in Thread] Current Thread [Next in Thread>