On Tue, 8 Jan 2008 03:38:16 am you wrote: > At 02:48 07-01-2008, Daniel Black wrote: > >For other email lists, like this one, you need to account for the > > [listname] tags. > > You can include the original subject on signing and do a comparison > with the new subject line before using the original subject for > verification.
Clarifing just to make sure I understand you: Subject: email list handling Sign this origination subject line ^ and on verification compare new subject like Subject: [dkim-milter-discuss] email list handling to the original and indentify that only [dkim-milter-discuss] was added. and because of this verify using the original? If you receive an email you only receive one subject so how do you compare the original if you don't know it. Could compare it to a z= header if the sender added it. I'd suggest once [.*] is detected that second sha1/256 hash state is need - one for with and one for without the [.*]. > >my opinion is that gracefull handling of email lists fudges will > > ultimately determine if DKIM is readily adopted in an organisation. > > It's one-to-one communication that's more important and that's where > DKIM can make a difference. Mailing list failures aren't critical > unless we do an outright reject on verification failures. True - but how do you identify a mailing list compared to a normal email reliably? What kind of actions/delays/implementations would occur in an organisation to gain the integrity of DKIM for one-to-one and not loose mailing list emails. > You are > right in that organisations may push off adoption until mailing lists > are handled gracefully. > > >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. > > > >Yes this going to be really ugly to implement. Is it worth it? > > If we want to increase the pass rate only, it may be worth it. The > last lines would have to be removed which means doing a body > rewrite. Rather than a body rewrite, the milter maintains a buffer of the last X lines. These last X lines will not be added to the running hash state until the final verification (milter eom). That way the last complete hash is the total of the final hash state including the buffer. If this doesn't verify then.. Take the hash state with 1 added line and verify....and failing that... Take the hash state with 2 added lines.....and failing that... Take the hash state with X-1 added lines..... > That has a significant overhead. Hopefully the stateful hash calculation is significantly less than body rewrite. Its certianly less expensive that a total hash recaluation over the entire message X times. > I made a suggestion above > on how the subject line can be unfudged. Unfudging should be easy. I think you'll need to maintain two (or more - see below) hash states there after. Additional hash calculation time: Best case - no subject changes and no addition lines (i.e. a typical non-email ilst message) Same amount of hash calculation is performed. Second Case - subject header modified - no added lines - person just happens to add a [XXX] in the header. Hash is calculated twice over the entire message - once with and one without the header unfudged Ugly Case - subject header mutulation - person just happens to add [XXX] [YYY] [ZZZ] to the subject line Hash calculated 4 times over the entire message. 3 after selectively omiting each [] value and once for the original. Worst Case: header modified (assumed once) and X-1 lines added before a passed verification Hash is calculated up till the final state twice Hash is appened (X-1) * 2 for a number of lines Absolute Worst Case: header modified by adding Y x [ ] values to the header and X-1 lines added before a passed verification Hash is calculated up till the final state Y+1 times Hash is appened (X-1) * (Y + 1) for a number of lines After all this it is probably worth associating the number of lines appended and the [XXX] value with the mailing list (return path address?) so future calculations can be optimised. Given the ads at the bottom of this list just changed this sounds like a potentially fault possible technique that also allows for changes. -- 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
