Re: Requirements for a filtering header

Yakov Shafranovich wrote:
> Philip Miller wrote:
>> 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.

It would be much better if we can authenticate trust relations implied by 
the header and ignore, or even specially consider, other tags. I just don't 
see the benefit of throwing away information, as long as we know what can be 
trusted.

>>> 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. 

I wrote the above with the Received header in mind, which runs completely 
contrary to this, and would be the most likely comparison.

> 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).

Isn't is possible to fold a header across multiple lines? I'll go test this 
somehow.

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

I think we had a long debate about that. Current email standards don't 
guarantee ordering for any header but Received, and one non-conformant 
intermediate system can screw it up.

>>> 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?

Not sure. It could depend on whether we're looking to match a Received 
header. A locally recognizable name would be sufficient, too. I'd still 
prefer having an unambiguous reference to an administrative domain, which 
means IP or FQDN.

>>>    b) optional, but specified in the base spec
>>
>> My list of these would be:
>> 1. Virus - yes/no

What I really meant here was 'Infected - yes/no'. I think this merits 
special treatment, while spam doesn't, because it is quite objective. Either 
a message matches the signature of a known virus, or it does not.

>> 2. Virus name
> 
> What about more than one virus?

When was the last time you've seen this?

>> 3. Virus forges headers (more specific? necessary at all?)
> 
> What's the point of #3?

Let other software know that sending a bounce could be a useless/harmful 
thing. This is knowledge that makes sense to put in a virus scanner, rather 
than an MTA, because the scanner's virus definitions are the most logical 
place to record this property of a virus.

>> 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"

Yea, I think it could. I guess virus doesn't really need a standard field. 
However, doing it this way would mean standardizing the meaning of a 
specific value of the category field, which seems unattractive to me.
Something to discuss further, I guess.

>>> 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.

I only mentioned 'Processed' because I don't think it had been suggested 
before. Perhaps we should make a list, and put it to a vote when eveything 
else is specified? Or perhaps one will naturally come to the front, as a 
result of the verbiage used in the draft specification.

Good night.

Sincerely,
Philip Miller