I made a bit more progress on this last Friday, to the point I now have a merge proposal up[1], and if somebody would like to do a pass over it that would be much appreciated.
It turns out that the python-dkim package has some bugs with regard to signing messages. The version in lucid will probably be enough for actual use in verification but to sign messages inside the test suite and to cover every case we'd need an updated version. There are various possibilities: 1- just paste the verbatim signed message into the test, so that we don't need a fixed python-dkim to run it 2- make a branch for it with our fixes and put that in as a source branch dependency 3- push it upstream, into the package, backport the package, etc Since the library is so relatively small I like the idea of doing #1 or #2. Of course I'll also offer the patches upstream. I monkeypatched dns resolution so that the tests don't depend on anything actually on the net. Here are some policy questions people may choose to comment on: * Bad signatures are just treated like 'no signature', ie they don't cause the message to bounce. This is probably a good idea for now. * We log some information about the checks. * When this is deployed, it will straight away start trusting all dkim signatures. It's not specific to beta users or chosen domains or anything, but we could do a soft launch before we start telling people about it. If something has a DKIM signature, it's trusted. * Is it worth putting in a feature flag to let sysadmins turn this on and off without redeploying? Is there any infrastructure for that? * There is a 'testing' field in the signature that says mail should not be bounced based on the signature being wrong. I still trust mails that have this set, for three reasons: the dkim library doesn't expose it; gmail sets it and I want gmail to work; and it seems unlikely to 'fail open' in the sense that the domain will start randomly signing untrustworthy mail. Much more likely that the signature will be broken. * We also don't make any assertions about the content of the signature, so if the sender doesn't for example choose to sign the message id we won't check it. Perhaps it would be useful but I don't think it's needed for now. -- Martin <http://launchpad.net/~mbp/> _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
