Re: Realisticness of header rearrangement

On Apr 09 2004, Mark E. Mallett wrote:
> 
> My perspective is this:  you don't trust the historical filter trail
> at all (these "tagged" or "filtered-by" equivalents to trace fields).
> You trust fixed headers inserted by the filters that you know are
> operating on your behalf.

I understand this, and I have nothing to object against the philosophy
of this approach. But like all approaches we've discussed, this one
has weaknesses.

The biggest weakness I can think of is that it's not automatic. 
Every player in the delivery chain must be aware of who's who, ie
which filters are trustable. 

For example, your MUA needs to know that SpamAssassin is going to
insert its headers. That's a piece of information you have to input
manually into your MUA, because in your system, there is no automatic
way of verifying trustworthyness of an inserted tag.

If you change your MUA tomorrow, you'll have to type into the new MUA
that it should trust SA, too. If next week, your sysadmin replaces SA
with Brightmail, you'll need to go into your MUA and tell it to
disregard SA headers, and trust BM headers. All of these have to be
done by hand. Moreover, you'd better read the MOTD from your sysadmin
where he's talking about the switch from SA to BM, otherwise you won't
know to make the switch. 

All of this is easy to do on a small/personal scale, but on a large
scale it's a weakness of the approach. 

To be able to scale, you would want a MUA to look through an incoming
mail and figure out for itself what can be trusted, and what can't.

Trusting nothing is not an option, as then you'd have no spam
filtering at all, except for messages stopped upstream.

> 
> I think one problem with this discussion is that we are flailing around
> with different suggestions for headers without having a common notion
> of the overall environment or the goals for such headers.  Mine
> is fairly simple (and perhaps naive-- I'm willing to have that
> corrected if true):
> 
>  - trace headers are only for exposition to the curious;
>  - fixed headers are for productive use.
> 

We have a small list of typical headers used by some filters already,
that's in an earlier thread titled "header inventory".

A quick read through gives the following different purposes for
inserted headers:

- filter version + hostname, maybe date filtered

- spam level/score as computed by filter (score can be paired with
  method used, when there are several possible methods) 

- details/explanations about available information used for scoring, 
  for example which relays were trusted, which weren't, or a list of
  elementary tests which contributed to the score

- external query results (for queries to RBL or similar)

- user convenience headers. For example, a link/URL, to allow 
  better/simpler integration between filter and MUA (POPFile does
  this). 

- markings to indicate the message has already been scored or seen.
  A marking can also be used to help learning filters do certain
  operations. For example, if user wants to "unlearn" a message, the 
  filter looks up the marking to verify the message can be unlearned.
  Maybe the marking includes a password to verify that the user is 
  allowed to unlearn. 

- some filters overwrite their own tags, other filters leave their
  own tags be and simply add another instance of the same tag 
  with current scores. This is in case the same filter brand is used
  at several sites during transport, so the user can see them all.

--
Laird Breyer.