Re: header inventory

On Mon, Mar 15, 2004 at 10:29:33AM +1000, Laird Breyer wrote:
> Just a quick argument about one of your points (we're starting to 
> see some trends with filter headers posted so far, but it's still 
> early to generalize too much, I think).
> 
> On Mar 12 2004, Mark E. Mallett wrote:
> 
> > One could encapsulate a reasonable amount of information in this sort
> > of header, while optionally still adding other X- headers as well,
> > perhaps with a requirement that those other headers be added directly
> > above (or below) the standard "Filtered-By" header.
> 
> Headers can be rearranged in transit, so it's not a good idea to rely
> on their ordering.

I agree, actually.  I don't like positional mandates.  (BTW I've seen
fairly strong opinions on other lists about how evil it is to allow
filters to insert headers at any other place than the beginning.)

Of course, we are talking about headers without saying why we are
talking about them, and I am sure there are different reasons for
inserting a header.  The "why" that I was thinking of is leaving a
trail indicating what filters touched a message; making sure that each
filter along the way could put its unique stamps on a message, and
being able to disambiguate them later.  You would have a "this filter
saw this message at this point" along with some information about what
the filter did or saw.  It's not enough to just say
    "X-Myfilter-Score:  3.6"
because you have no idea where this was inserted; plus you have
the possibility of multiple instances of "Myfilter" touching a message
along the way, sometimes at the same server.  So I suggested that
there be a tuple that identified where "this point" is.  I don't have
a definite answer about what should be in that tuple, but figured that
could be open to discussion.  I made up some examples for exposition
only, not for proposal.

Such a header line would not necessarily have to have any particular
position in the header.  My positional remark was a throw-away comment
about having a way to relate the multiple headers that a filter might
insert.  (There is precedence for this:  trace fields such as
"received" are supposed to be prepended and not altered.)  Personally I
think there are better solutions:  e.g. one might be to have the
filter-identifying header include a unique token, and related headers
also contain that token so that one could do a join on them.  E.g.:

    Filtered-By:  filter=spamanoid ip4=10.0.0.1 tag="mem"
    	mark=2340914nber234
    X-score:  mark=2340914nber234  10.6


> If ordering is important, a better system consists in embedding a
> counter which can be sorted on by anybody who needs to see headers in
> chronological order.

Indeed, that's another example.  

-mm-