← Back to team overview

launchpad-dev team mailing list archive

Re: [rfc] DKIM Authentication

 

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/>



Follow ups