Re: Requirements for a filtering header

Yakov Shafranovich 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?
> 
> Can this be left to the filter to decide in each chain? Lets say that I 
> get a incoming email at the edge and the first filter at the SMTP server 
> will take any such headers out. HOWEVER, the filters downstream in the 
> chain can be configured to leave the headers alone by a configuration 
> option outside the scope of such standard. The trust between filters in 
> chains is a local administrative issue rather than a internet wide issue.
> 
> This of course is based on an assumption that there is a no need for 
> exchanging filtering results across domains that have no prior 
> relationships with each other. Domains with prior relationships can be 
> set to trust each other somehow. If anyone disagrees, I would love to 
> hear it.

I strongly disagree. I think it should be an absolute requirement that all 
such headers be left in except by software directly controlled by the 
recipient. I don't want to see mail forwarded from one address to a 
destination ISP account getting all prior headers stripped by the stupid ISP 
servers.

We should ensure that trust of each header can be determined by the user, 
without respect to any prior arrangements. Take a weird example, in which a 
user has an address, [email protected], forwarding to [email protected]. Suppose 
the user trusts the results of the filters at forwarder.tld, but not at 
isp.tld. If isp.tld were allowed to strip headers, that could cause the user 
a royal pain in the neck.
What is the benefit of allowing servers to strip them, rather than 
proscribing stripping and specifying the header in such a way that the user 
(and software under the user's control) can interpret them based on the 
user's knowledge and trust?

>>> If these are satisfied, than I would like to ask for some folks to
>>> volunteer to write up a requirements draft from which we can continue 
>>> the discussion.
>>
>> Please try not to be so document focused, at least until the point 
>> where we're actually writing a specification. If it's that important, 
>> I can throw this stuff in the wiki.
> 
> Ok. I am simply trying to figure out a way to move things along. A 
> document seemed like a good idea to me, all of you are free to make 
> other suggestions.

OK, understood. Perhaps you can set up sectional change-notification on the 
wiki, so that edits there are posted here, and can then be commented on?

>> 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
>> 2. Fields
>>    a) mandatory
>>    b) optional, but specified in the base spec
>>    c) IANA registration of new fields
>> 3. Name of this header
> 
> Someone (Dave?) already put some stuff on this in the Wiki 
> (http://www.shaftek.org/wiki/wiki.pl?Filtering_Standards/Filtered_Header).

David Nicol (I believe it was him) and I wrote that.

Philip Miller