On Tue, 8 Jan 2008 05:20:44 am Murray S. Kucherawy wrote: > On Mon, 7 Jan 2008, Daniel Black wrote: > > perhaps the verification process could almost brute force the email list > > mangles. This would involve: > > 1. attempting the subject line unfudges (removing []) > > s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/' > > 2. attempting to remove the last 5 (configurable) lines off the email and > > see if that passes. > > You certainly could do this, though it could require recomputing the hash > several times which is a bit on the expensive side, and dangerous if you > have an MTA waiting for a response from the server.
Is the incremental hash state approach acceptable? I was looking at ./libdkim/dkim-canon.c and it does seem like a non-trival amount of effort. > It's also worth noting that the discussions among the original DKIM > implementors, as I recall, leaned in the direction of recommending that a > failed signature should still be considered failed even if you can > determine what mangling took place to cause it to fail, and thus determine > what the original signed message looked like. If you can determine what the original signed message looked like and it verified ok can it be considered a pass? "Yes" would certianly make it more useful to admins. Especially to those that don't want to debug dkim failures every time a user adds themselves to an email list. Admins may need to think wider to determine if this would introduce risk in replay attacks by the appending short amounts of text. > This is to some extent what > the "z=" tag is for. Useful for debugging a failure with the assumed cooperation of the sender in adding the "z=" flag. Not sure any admin would want to be debugging for email list traffic for DKIM failures considering its a known risk in the standard. > > Yes this going to be really ugly to implement. Is it worth it? > > > > Am I missing something in the standard that says a verifying server > > should not attempt to verify the original signature? > > There's nothing in the standard that makes that improper. In fact the > standard is deliberately vague on the topic of interpreting > multiply-signed messages. It's up to the verifier to decide how to handle > them. The only guidance it provides is to say that one can't rely on the > order of the signatures to be meaningful because we've seen header order > get mangled in transit before. > > The current libdkim implementation evaluates all of them by default, in > the order in which they appear in the headers. The filter doesn't allow > you to say which one(s) to prefer, but it could if that turns out to be a > good idea. The library allows the caller to specify which ones it wants > to consider and in which order. This would make sence on a small volume server where you add a signature now and then for emailing lists that you choose to trust. A large volume server would require the user to self manage a whitelist of signatures for themselves which isn't impossible either. -- Daniel Black -- Proudly a Gentoo Linux User. Gnu-PG/PGP signed and encrypted email preferred http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x76677097 GPG Signature D934 5397 A84A 6366 9687 9EB2 861A 4ABA 7667 7097
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
