On Thu, 24 Jan 2008 15:31:38 -0800 (PST) "Murray S. Kucherawy" <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
