Re: Requirements for a filtering header

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

So far I see no fool proof way of establishing such trust across 
independent domains without prior relationships in a foolproof way even 
with all of the discussion going on for the past two weeks.

Even a standard header within one single administrative domain (ISP to 
end user) have enough useful utility. While I am aware of the forwarding 
case, I am not sure if it is possible to come up with some form of a 
trust mechanism for headers inside the standard itself. We can possible 
just leave this issue unresolved for the filter developers to sort out 
or leave enough extensibility in the standard for passing of trust 
information (a field for public key and signature?).

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

I am not sure what you mean by that. Can you elaborate?

Yakov