Re: [dkim-milter-discuss] Dealing with malformed Authentication-Results:

[Scott K. <iet...@ki...>]

On Thu, 24 Jan 2008 15:31:38 -0800 (PST) "Murray S. Kucherawy" 
<ms...@se...> wrote:
>On Thu, 24 Jan 2008, Scott Kitterman wrote:
>> OTOH, dkim-filter isn't a general purpose auth-results processor. 
>> Personally I think removal violates the principle of least suprise.  I 
>> think it would be wrong, for example, for dkim-filter to remove an SPF 
>> related header.  It'd be equally wrong for SIDF milter to mess with dkim 
>> headers.
>
>If dkim-filter can parse the header and determines it's not returning a 
>DKIM result, it's ignored by default (you can configure it to remove all 
>headers if you want, but that's not the default).
>
>I'm wondering about the particular case of one that's malformed, i.e. 
>doesn't conform to the "standard" for formatting an 
>Authentication-Results: header and thus can't be parsed.  The section of 
>the A-R draft that talks about removing the header says we should remove 
>A-R headers that claim to come from inside our trust boundaries, but if 
>you can't tell either way, what's the right thing to do: err on the side 
>of least change, or err on the side of protecting possibly naive filtering 
>agents, MUAs or users?

Well if they don't parse as auth-results headers, then they aren't really 
auth-results headers.  So I guess I'm on the side of least change.

Naive filtering agents or MUAs are just buggy and should be fixed.  Not 
sure what to do about the users....

Scott K