launchpad development
DKIMAuthenticatedMail
Mail with a DKIM signature should be trusted similarly to GPG-signed mail. See bug 316272.
As a developer who uses Launchpad and gmail
I want Launchpad to trust mail from me without demanding a separate GPG signature
so that I can more easily send Launchpad commands to control bugs, reviews, etc
Many mail services now send Domain Keys Identified Mail giving reasonably strong authentication that the mail was sent by the domain it claims to have been sent by. This is typically attached without needing any action by the user.
Breaking news
As of (the next rollout after) 16 Sep 2011, DKIM will also be accepted if the Sender address in a validated account address. This should mean Launchpad will accept mail sent through gmail, even if you have a From address that's not at gmail, as long as you have validated your gmail address.
As of 13 Dec 2010, second-party DKIM is accepted for both creating new bugs and modifying existing bugs, but you must send mail with a From address in the signing domain. Specifically, if you are sending mail from gmail, you must use your @gmail.com address. Fixing this is bug bug 643223 and is the next step.
As of 20 September 2010, DKIM is accepted for changes to existing bugs. Because of bug 643219 it doesn't work for mail to new@. You must use the dkim-signed address (eg foo@gmail.com) as the From address. See bug 316272 for more.
To debug this on lpnet, look in /srv/launchpad.net-logs/scripts/loganberry/process-mail.log.
Rationale
Many of our users (50%?) use gmail, fastmail, yahoo mail, etc. This would make interaction with Launchpad somewhat easier with them.
This is not urgent: more like itch-scratching.
However, it may be easy to implement. There is already an IAuthenticatedMail interface in Launchpad, and there is already a pydkim library that tells whether a particular mail is authentic or not.
Stakeholders
- Launchpad users, especially those without GPG integrated into their prefered mail client
- Launchpad/Canonical security specialists (elmo, kees, ...?)
- Launchpad LOSAs (mthaddon?)
- Product strategist
- ScottK (dkim expert)
Constraints
- When DKIM-signed mail is received by Launchpad, it should be treated as authenticated and be able to contain mp votes, bug commands, etc.
- When invalid DKIM mail is received, it should be rejected. (optional)
- Either way, we should log the sender, message-id, dkim signature, dkim debug log, and outcome.
- This should be rolled out in a conservative way that does not risk suddenly rejecting or falsely trusting large amounts of mail.
Subfeatures
Deployment steps:
- Just log the results of the check, without taking any other action: date, sender, message-id, dkim outcome
- Let this run for a while and then look at the logs.
- For a subset of users, start treating messages with valid signatures as authenticated and every other case as unauthenticated.
- Do this for all users, and announce it
- For a subset of users, start rejecting messages with invalid signatures, with an explanation of the problem (bearing in mind the message may well have been forged.)
- Ditto globally
Workflows
When Launchpad receives mail, it checks whether it is DKIM-signed. The results of this can be: valid, invalid, or inconclusive, not signed, or internal error.
Success
Bugs are at: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=dkim
How will we know when we are done?
Sending mail from gmail to new@bugs.l.n creates a new bug (rather than, as at present, complaining that it's not signed.)
How will we measure how well we have done?
- Graph the number of mails received with good or bad dkim signatures
- Blog about this and hope for positive responses
Thoughts?
Put everything else here. Better out than in.
- The biggest problem seems to be a concern that many domains using DKIM signing do not prevent intra-domain or cross-user spoofing.
See for example http://mipassoc.org/pipermail/ietf-dkim/2007q4/008136.html
- A previous version of this spec said that we could reject messages that do not verify; however the DKIM documentation strongly discourages this on the grounds that they are likely to have been inadvertently modified in transit. So we should just treat them as untrusted.
- Do we want multiple levels of trust? Probably not: gpg is stronger in theory but not clearly stronger in practice here, because the main weakness seems to be whether the user protects their credentials well, not which mechanism they use. Let's default to keeping it simple.
This seems contradictory: "Probably not; gpg is so much stronger that it is worth doing"? -- jml, <<Date(2010-05-20T10:23:14Z)>>
It was a typo: I meant to say 'not so much'. -- mbp 2010-05-20 20:30:40
- This doesn't help with cases where Launchpad sends encrypted mail, but that's irrelevant. There are few such cases.
- Error messages and help must be set up to mention that both gpg and dkim would be acceptable.
Can we get a list of the templates to change on to this LEP? -- jml, <<Date(2010-05-20T10:23:14Z)>>
It looks like this can hook into authenticateEmail reasonably cleanly.
There are some interesting cases like when Gmail is letting you send email with the From address in a non-gmail domain. It may be reasonable to check the launchpad Person has both addresses associated with their account. gmail signs both the sender (foo@gmail.com) and from (foo@example.com) fields so we should be ok.
- What if the DKIM is invalid but there's a valid GPG signature or vice versa?
- elmo notes this may increase pressure to sign outgoing mail from Canonical/Launchpad.
- DKIM relies on DNS to fetch server public keys; it could be spoofed by a determined DNS attack. This is according to elmo probably an acceptable risk.
- I'm assuming this will not create substantial additional server load: another hash and a DNS lookup should be cheap compared to a gpg check.
We'll need to add a new external dependency on pydkim (or whatever.) It is packaged as python-dkim in Lucid, at least.
- python-dkim can write out a (fairly nerdy) debug log, which we can retain on the server for troubleshooting. It can also tell whether a failed verification is because the body mismatches the expected hash, or for some other reason. This might be useful eventually to expose to the user.
- If somebody uses a system that persistently sends broken DKIM, we don't want to whine about it on every single message they send. There is a field that says how strictly the messages should be checked, but it may not be trustworthy. Perhaps it's best to just start soft and see what happens.
- Launchpad lists seem to break dkim signatures for a reason I've not yet identified. That doesn't seem like particularly a problem here because we do not expect to receive mail to Launchpad via a list.
