Re: Requirements for a filtering header

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

We don't need to establish trust across domains (i.e. between forwarder and 
ISP). We only need to establish trust between the user and each individual 
domain. Typically, a user would only trust their ISP's servers, the servers 
of a forwarder acting under their direction, and those of mailing lists the 
user subscribes to. All of these have a prior relationship, in a sense, with 
the user. We just want to ensure that the ISP at the receiving end of the 
last hop doesn't make utilising those prior relationships with the forwarder 
and mailing list impossible.

We can continue this discussion in a separate thread, as it does not pertain 
directly to the composition of a draft set of requirements.

> Even a standard header within one single administrative domain (ISP to 
> end user) have enough useful utility. 

I don't agree with that at all. I think it would be very harmful to utility 
to force the user into such an arrangement.

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

First, I don't think this is something filter developers will resolve in a 
reasonable, consistent, and *interoperable* way.
Second, I think we can provide a standard way to sign these headers fairly 
easily, but I believe that should be in addition to some simpler mechanism.

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

Can you configure the wiki software to email the list when any changes are 
made to the Filtering section of the wiki?

Philip Miller

P.S.: Can we do some real-time discussion? It might ease the back-and-forth 
traffic between individual participants on the list.
How's room 'asrg-filtering' on ietf.xmpp.org sound?