Re: daily response Wednesday 17 mar

On Wed, Mar 17, 2004 at 11:12:31AM -0600, David Nicol wrote:
> 
> I prefer one header with all the data crammed into it in a series
> of well-defined key=value pairs rather than many headers each with
> its own extension of the header name.
> 
>   NOT PREFERRED BY DN:
>   Filtered-By: foobarbazfilter
>   Filtered-By-Version: 1.2devel20070317build2
>   Filtered-By-Heuristic-Probability-Is-Ham: 93
>   Filtered-By-Heuristic-Probability-Is-Spam: 12
> 
>   PREFERRED BY DN:
>   Filtered-By: foobarbazfilter version=1.2devel20070317build2
>     spamp=12 spamq=93

I think there are at least two sorts of filter-stamp headers that can
coexist.

One is the single one that encapsulates everything a filter did, and
provides a unique stamp of the filter's presence and its locus of
operation.  This would be like the "DN preferred" one.  (I still
believe that some kind of location marker is needed: whether it be a
made-up ID or a sequence number or an address-- a sequence number
(such as suggested by Laird earlier) does seem neat and tidy, although
that choice might make it a little harder to track down the filtering
spot several steps back).  Whatever the unique ID is, it would also
allow a filter to emit several Filter-ID lines tied together by
that same ID: this would be useful for extended annotation.

The other is something less complex, that can easily be identified by
the next stage, and that isn't necessarily preserved (can be
deleted or overwritten by each filter in turn).  E.g.
    "X-Spam-Score: 5.6"
would be an example, as would a tag in the subject line at final delivery.

Among other things, having a filter produce both formats would allow
a migration to the more complex "Filter-Id" audit trail while keeping
compatibility with existing formats that are already widely used.
Newer software can deal with the more complex Filter-ID lines (and
will have the opportunity to access information from each filtering stage).
Existing software can continue to look at the same old fixed-format
lines it is already expecting.

Does that makes sense?


> Which brings another requirement.  We must decide what MUA we want to
> support.  Reccomending munging the Subject line seems to be a good practice
> for things like list servers.

Maybe it's the time of night, but I don't follow.  Support an MUA
in what way?  I would think we would have a goal of not breaking
any existing operation, while providing better data for future software
to use.  But why pick a MUA ?


> Maybe we can agree on and produce a BCP on subject line alterations.

I think I'll give that, er, subject, a rest for a bit :-)

mm