Re: Requirements for a filtering header

Philip Miller wrote:
> Philip Miller wrote:
> 
>>> 2. If there is a rough consensus as to what issues need to be solved for
>>> such header to be useful.
>>
>>
>> Major existing issue:
>> Should the header appear only once, representing the results of the
>> last-acting (and therefore most trusted?) filter, or should it appear 
>> once
>> for each analysis action?
> 
> 
> I believe that such a header should appear in a message as many times as 
> that message is processed by any relevant piece of software that passes 
> the message on rather than rejecting it outright. This allows the user 
> (and the software acting on the user's behalf) access to as much data 
> about a message as possible.
> 

I still think that the filters should be given an option to delete all 
prior headers if so configured. An example would be email coming from 
outside the domain vs. email coming from a filter upstream in a trusted 
chain.

>> At any rate, once we have the above major issue resolved, I see the 
>> need for the following things to be determined:
>> 1. Syntax of this header
> 
> 
> I would prefer strict key-value pairs, but if we go with some fixed 
> fields, I'm fine with that too, just so long as there is room for 
> specified extension with a low barrier to entry.
> 

A MIME-like format with "key=value1; key2=value2" has been historically 
used for header fields. We do have to keep in mind the length limits 
(mentioned in the Wiki) and perhaps allow for a possibility to header 
splitting (if the length becomes a problem).

Also, what about ordering of fields? Do we mandate a specific order?

>> 2. Fields
>>    a) mandatory
> 
> 
> I would support making a number of fields mandatory in all instances of 
> the header, including:
> 1. Host on which processing occurs

IP, FQDN, or both? Local name perhaps?

> 2. Timestamp of processing
> 3. Name of processing software
> 4. Version of processing software
> 
>>    b) optional, but specified in the base spec
> 
> 
> My list of these would be:
> 1. Virus - yes/no
> 2. Virus name

What about more than one virus?

> 3. Virus forges headers (more specific? necessary at all?)

What's the point of #3?

> 4. General Classification - i.e. what POPFile is designed to provide
> 5. Confidence in General Classification - statistical certainty of result
> 
> Note that a set of spam-specific fields is quite superfluous. The value 
> of the 'General Classification' field can be 'spam' or 'junk' or 
> whatever, and the user can set all such things to go in one folder, be 
> deleted, get a challenge, etc.
> 

Could "virus" be part of the classification scheme? For example:

"category=virus; confidence=90%; x-virus-name=blah"

>>    c) IANA registration of new fields
> 
> 
> I think this is absolutely crucial to success, and I see no reason not 
> to require full syntax specification of the values such fields will 
> contain.
> 

Agreed.

>> 3. Name of this header
> 
> 
> Right now, I'm leaning towards the most-generic 'Processed', as a more 
> active sounding parallel to 'Received'.
> 

Tagged, Filtered, come to mind as well.

Yakov