Hi Murray, At 14:24 24-01-2008, Murray S. Kucherawy wrote: >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).
We may have the following headers which were not inserted by mail.example.com: Authentication-Results: mail.example.com; dkim=pass (1024-bit key) [EMAIL PROTECTED] or Authentication-Results: mail.example.com; [EMAIL PROTECTED]; dkim=pass For the first one, we might either do (a) or else reject the message as we don't consider a message having our authserv-id as valid. The second case is a malformed header where we can use (b) if we assume that the header won't be of a problem to parsers which process our Authentication-Results header. I would not consider this merely as a malformed header as it includes our authserv-id. As such, I suggest doing (c) or else rejecting the message. Note that reject is a policy decision here and it's up to the site to decide. >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. Agreed. People reading the header might also incorrectly assume that it was inserted by our MTA. >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. I don't like (c) either but I suggest considering as an option as we cannot assume that this header won't be used for questionable purposes. Regards, -sm ------------------------------------------------------------------------- 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
