Diff for "LEP/DKIMAuthenticatedMail"

Not logged in - Log In / Register

Differences between revisions 1 and 2
Revision 1 as of 2010-05-13 12:46:57
Size: 2670
Editor: mbp
Comment: drafting
Revision 2 as of 2010-05-13 13:08:44
Size: 3083
Editor: mbp
Comment: more drafting; not ready yet
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
'''As a ''' developer using Launchpad<<BR>>
'''I want ''' Launchpad to trust mail I send from gmail without needing a separate GPG signature<<BR>>
'''so that ''' I can send Launchpad commands to control bugs, reviews, etc<<BR>>
'''As a ''' developer who uses Launchpad and gmail<<BR>>
'''I want ''' Launchpad to trust mail from me without demanding a separate GPG signature<<BR>>
'''so that ''' I can more easily send Launchpad commands to control bugs, reviews, etc<<BR>>
Line 15: Line 15:
Many of our users (50%?) use gmail, fastmail, etc. This would make interaction with Launchpad somewhat easier with them. Many of our users (50%?) use gmail, fastmail, yahoo mail, etc. This would make interaction with Launchpad somewhat easier with them.
Line 17: Line 17:
It is also useful in a negative direction in that we can reject spam that claims to be from a DKIM-authenticated domain. It is also useful in a negative direction in that we can reject mail that claims to be from a DKIM-authenticated domain but that is not correctly signed. This may eliminate some amount of spam or forgery. (But this does not seem to be a very significant source of spam or abuse at the moment.)
Line 19: Line 19:
This is not urgent -- more like itch-scratching -- but it may be easy. 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 [[http://hewgill.com/pydkim/|pydkim]] library that tells whether a particular mail is
Line 24: Line 26:
 * Launchpad/Canonical security specialists (elmo, ...?)
 * Launchpad LOSAs?
 * Product strategist
 * Launchpad/Canonical security specialists (elmo, kees, ...?)
 * Launchpad LOSAs (mthaddon?)
 * Product strategist (jml)
Line 41: Line 43:

Talk to the product strategist soon after cutting a first draft of this document

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.

Rationale

Many of our users (50%?) use gmail, fastmail, yahoo mail, etc. This would make interaction with Launchpad somewhat easier with them.

It is also useful in a negative direction in that we can reject mail that claims to be from a DKIM-authenticated domain but that is not correctly signed. This may eliminate some amount of spam or forgery. (But this does not seem to be a very significant source of spam or abuse at the moment.)

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

Stakeholders

  • Launchpad users, especially those without GPG integrated into their prefered mail client
  • Launchpad/Canonical security specialists (elmo, kees, ...?)
  • Launchpad LOSAs (mthaddon?)
  • Product strategist (jml)

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, and outcome.
  • This should be rolled out in a conservative way that does not risk suddenly rejecting or falsely trusting large amounts of mail. Perhaps we should apply it only for users in a particular group at first.

Subfeatures

  • none

Workflows

What are the workflows for this feature? Provide mockups for each workflow.

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.

Success

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.

LEP/DKIMAuthenticatedMail (last edited 2011-09-28 03:56:23 by mbp)