Hi Daniel, At 23:57 07-01-2008, Daniel Black wrote: >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?
Yes. >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. You can only compare if you have the z= tag. >I'd suggest once [.*] is detected that second sha1/256 hash state is need - >one for with and one for without the [.*]. We have to compute two hashes then. >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. The mailing list manager which generally breaks DKIM signatures adds a List- header. We have to be careful here as any "rules" we put in may be used for questionable motives. You are equating verification failures with "bad" mail. I consider the failures as unsigned mail. I don't reject on failures and as such I won't lose mailing list emails. If your (one-to-one) email is DKIM signed and verifies, it's easier for me to whitelist you without having to track any IP address change at your end. If the email goes through forwarders, it will still verify successfully. I'm not sure what you mean by actions and delays. I can also use DKIM for "reputation" assessments. >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..... The purpose of the l= tag is to avoid the steps above. >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. We still have to do a body rewrite as passing unsigned content opens the way for all kinds of tricks. >Unfudging should be easy. I think you'll need to maintain two (or more - see >below) hash states there after. Technically, there's nothing that prevents us from "unfudging". Is it worth it? We have to deal with the cases you mentioned which is non-trivial. >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. What if the number of lines appended changes in future? DKIM has no association with the Return-path address. It's easier to associate the return-path with some token instead of having DKIM do all these calculations. Regards, -sm ------------------------------------------------------------------------- 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
