If dkim-filter encounters an Authentication-Results: header it can't parse because it doesn't conform to the latest draft, should it:
a) delete such headers b) ignore such headers c) try at least to determine the "authserv-id" (usually the hostname that supposedly added the request) and then decide whether or not to delete it I'm inclined to implement (a) but be willing to do (b) as an option. The filter currently does (b). The risk of doing (b) is that a naive MUA or filter downstream that doesn't bother to check the correctness of the header format might interpret an older header, which could've been forged but was let through dkim-filter because it couldn't be fully parsed for analysis. I don't particularly like (c) because by the time this is a standard, there should only be one form to parse and use by any filtering agent or MUA, and thus trying to remember all historical formats or common malformations will make the code highly complicated. Comments welcome. In the absence of good argument in favour of (c) or some other solution, I'll probably opt to implement (a) as the default and (b) as an override. -MSK ------------------------------------------------------------------------- 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
