Re: Moving forward ...

My upstream filter may know about something that breaks your downstream 
filter (in possibly damaging ways), and *need* to be able to stop that 
payload from getting to your filter.  I think the final answer here is 
going to have to be a blend of "don't modify unless you have to" with 
"if you have to modify, here's how you signal what you did, and why".  
Your suggestions make sense in a filtering world where there's no 
malicious or dangerous content, but when people may be actively trying 
to attack the filter chain to compromise machines or steal things, it 
doesn't work so good.

C

On Feb 26, 2004, at 9:25 AM, <[email protected]> wrote:

>> This is bad. I'd much prefer a system where my filter can
>> easily ignore anything done by other filters. Let the user
>> decide how to
>> integrate all the various recommendations.
>
> Yes, but the headers have to express this information in a way that
> lotsa different rule systems can understand them.  (from procmail to
> simple header pattern matching)