Re: Requirements for a filtering header

Philip Miller wrote:

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

The interesting question is how to determine trust. This is a much 
harder question to solve than it seems especially for headers (reminds 
me of something mentioned in the SMTP-VERIFY subgroup). Perhaps we 
should leave the issue open and move on to the rest.

What I am trying to determine is whether forcing filters to keep all 
header will make things force. If you state that headers SHOULD not be 
removed but MAY be removed is they look suspicious, that may be less of 
a problem than saying "never remove".

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

The Received header is not easily extensible while this has to be. 
Historically, the MIME-like convention has been used for headers that 
demand extensibility.

Yakov