Re: Realisticness of header rearrangement

On Mon, Apr 05, 2004 at 06:49:57PM -0400, Philip Miller wrote:
> However, adding this counter requires a lot more than copying the Received 
> timestamp. Using the Received timestamp means looking at the top Received 
> header, which will be at the top, as required by RFC 2821. Finding a 
> counter value greater than all previous values requires parsing every 
> previous tag header, some of which could have been rearranged downward by 
> non-conformant MTAs.

Indeed.  I've been thinking of that as one of the benefits of an
increasing-value ID, not as a drawback.  It provides for
position-independent tagging.  One of the thoughts was to make the ID
part of the fixed-format section of the header, so that elaborate
parsing is not required in order to find the ID when generating a new
one.  To introduce a new ID you'd have a mandatory header where the ID
is defined, e.g.:

    Tagged:  2345  name=blamspam version=8.2

(or "Filtered-by" or whatever).  Other related headers inserted at the
same step could reference the same ID, using an optional value syntax
(e.g. tag=value) following any fixed-format information.

    X-Spam-Score:  5.3  tag-id=2345

i.e. you'd have one defining header and zero or more joined headers.


> If someone comes up with a more aesthetically pleasing way to match tag to 
> Received header, with similar or better functional characteristics than the 
> Received-timestamp, I'm all ears.

I see "Received" as an overlapping set of information not necessarily
tied to the filter-produced headers.  There should be enough
information in the filter-generated headers to uniquely identify the
locus of operation of the filter.

mm