From: Murray S. K. <ms...@se...> - 2008-01-24 23:31:47
|
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? |