PGP encrypted / multipart templated emails for Django

A new keyword argument is introduced (body_html_type) to allow for setting mimetype in send_mail and send_mail_template() functions. It defaults to 'text/html', just as it was in the original code.

The change allows to e.g. correctly open encrypted emails in gmail with mailvelope. Such scenario requires to set body_html_type to 'application/pgp-encrypted' or 'text/plain'. Without it, using the default value, opening an email results in "Error! Could not read this encrypted message: Error: Unknown ASCII armor type" for the scenario.

The change is supposed to be neutral and extends the basic use and api. Thus, I hope it can be merged. Thanks in advance!

Adrian

Hey Stephen,

Any chance we can get a new PyPI release soon? It appears that https://github.com/stephenmcd/django-email-extras/pull/42 is necessary for Django 1.11 support.

Thanks!

If the encryption of a mail body fails, e.g. because the key is expired, python-gnupg just returns an empty string, which then becomes the mail body. See python-gnupg docs:

Note Any public key provided for encryption should be trusted, otherwise encryption fails but without any warning. This is because gpg just prints a message to the console, but does not provide a specific error indication that the Python wrapper can use.

This pull request aims to make it easier to add custom error handling in this case. It's easy to tell that the encryption failed: encrypted == "" and body != "". In this case utils.get_failed_encryption_body(body, addr) would be called, where body is the original/unencrypted body. That method just returns settings.FAILED_ENCRYPTION_BODY, which is set to "" (so, it's the same result as before), but could be overwritten with a more useful message. More important (for me), utils.get_failed_encryption_body(body, addr) can be easily monkey patched, which allows to add any kind of custom error handling and to return whatever could be useful.

The current signature of email_extras.utils.send_mail:

def send_mail(subject, body_text, addr_from, addr_to, fail_silently=False,
              attachments=None, body_html=None, connection=None, headers=None):

is supposed to mimic the signature of django.core.mail.send_mail:

def send_mail(subject, message, from_email, recipient_list,
              fail_silently=False, auth_user=None, auth_password=None,
              connection=None, html_message=None):

but it doesn't quite manage it.

This ensures that our send_mail function completely mimics Django's send_mail function.

Changes:

• The body_html option should be renamed to html_message, but to ensure backwards compatibility I kept them both and made sure users only specified one of them, and threw a warning if body_html was used.
• The addr_to argument was renamed to recipient_list. This is more of a cosmetic change than anything else, but it should reduce the cognitive burden for anybody comparing the source code for each function.
• Used Python's dict() constructor and Django's values_list() to create the dictionary of (address, use_asc) pairs without explicit loops (read: more Pythonic).
• The auth_user and auth_password options were added, and used if the connection option was None. This is exactly how Django's send_mail function uses them.
• Updated send_mail_template to use the new argument/option names.

Hi Stephen,

First off, thanks for making a great and useful app. I would like to use this app in a python 3 environment. Would it be possible to release a version that has python 3 support?

As far as I can tell, only a few changes are required:

• In utils.py:54 the unicode() call has to be replaced by django.utils.encoding.smart_text() or something similar.
• In models.py the unicode() functions have to be replaced by str() functions, a @python_2_unicode_compatible decorator can be added for python2 compatibility. (see https://docs.djangoproject.com/en/dev/topics/python3/)

This is useful if you want to open HTML parts of emails in your web browser and you want to see the non-HTML parts in your terminal, or logged to a file.

This adds a new option EMAIL_EXTRAS_ACTUAL_DEBUG_BACKEND and passes email onto it.

The default for this is Django's console backend, so non-HTML parts will display in the developer's terminal. To completely turn that off, the option should be django.core.mail.backends.dummy.EmailBackend.

Hi, I'm trying to figure out how the GPL plays with Python imports.

I'm working on a closed-source project where we want to sign and encrypt certain email (read: password reset emails, notifications of changes to sensitive settings, suspicious authentication/authorization notifications, etc., but especially password reset emails).

I'd like to use django-email-extras because it seems to be the most mature and maintained project that supports this, and it's licensed under the BSD-3 clause license.

~~However, it depends on and imports Python code from python-gnupg, which is licensed under the GPLv3. And the GPL being copyleft, that would seem to imply that - as long as this project depends on and imports code from python-gnupg - this project could only be licensed under a GPLv3 compatible license. And the BSD-3 clause is compatible, but if I depend on or import code from django-email-extras, the viral nature of copyleft licenses would mean that my code would then have to be licensed under a GPLv3 compatible license.~~

~~Can anybody assuage my fears of using this project? Does the FSF consider Python imports to be dissimilar from C's #includes and binary linking? Is there something I'm not seeing that prevents the viral nature of the GPL from subsuming code that imports code from this project?~~

~~Or should I keep looking for a similar project with completely compatible licensing requirements?~~

Thanks!

Edit: Answered my own question. See my comment

While using email_extras (ver. 0.3.2) I came across an exception while attempting to send encrypted mail to a set of addresses for which gpg keys existed (= no unencrypted emails expected). In this case unencrypted + encrypted (from send_mail) had a form [[], ['mail1@...'], ['mail2@...']] and encrypt_if_key() failed. My pull request solves this problem. Hopefully, it's acceptable. If so, I would much appreciate a swift release of the updated pip module (0.3.3).

Last but not least, thanks a lot for your great work! :)

Hi Stephen

Taken a while since I was distracted but I return with a PR with regards to #11.

I've tested with encrypted and non-encrypted messages and it behaves as we discussed/you suggested in the ticket.

Happy to rework things if the implementation is not to your taste, or leave you to do so.

I was getting an error in backends. It said that BaseEmailBackend was not defined. I added the line:

from django.core.mail.backends.base import BaseEmailBackend

and now it works. I don't know how this worked before.

Thanks for your packages!

Glenn

Hello

At the moment (correct me if I'm wrong) it seems like we cannot send an email to multiple recipients with the same email. I assume the code is structured like this to support encryption.

Is there any room for modification of the library to support this?

Some thoughts on approaches ...

1. Modifying send_mail to support both single and multiple recipient modes could be a bit messy and may also break users expectations. For example, you could not send to multiple recipients and support USE_GNUPG. (Maybe an exception could be thrown?)
2. Adding a new multiple recipient send mail function could end up duplicating functionality in the existing send_mail function.

I'm happy to have a go and submit a PR if this is something that you want in the library.

Thanks for your time.

Ben.

With the newest release 0.3.4 it seems there is a missing migration which makes lots of CI fail. It'd be necessary to add a new version as soon as possible including those migrations.

Hi Stephen, it would be nice to make tag for distinguish installed version. Latest merge fix compatibility with Django 1.11. But this important change can not be reflected by pip installation! Can you create tag please?

Thanks Zdeněk

Should be applied after/on top of #39. I will rebase this on top of master once that gets merged in.

The first six commits are from #39.

TODO:

• [x] Fix some bugs uncovered by tests
• [x] Add tests for email_extras.utils.send_mail function
• [x] Add tests for the model save() and delete() functions
• [x] Add tests for the encrypting backend from #39
• [x] Add tests BrowsableEmailBackend
• [x] Add tests for has_add_permission on Address admin
• [x] Improve coverage for existing test cases (key.email_addresses property)
• [x] Add tests for signing outgoing mail
• [x] Add tests for management command
• [x] Add tests for forms
• [x] Add tests for default exception handlers, and tests to make sure custom exception handlers are called
• [x] Figure out what the behavior should be when ALWAYS_TRUST is False and add tests for that ~~- is this even useful? Everything broke when I turned that off...~~ Test for this added from @theithec's comment
• [x] Add Travis CI integration
• [x] Add flake8 check
• [x] Add Travis build status badge and Coveralls coverage status badge to README

~~There's only one line of crypto code that isn't tested: email_extras/backends.py:72~~

This PR now has 100% test coverage for django-email-extras!

Further work for future PRs:

• Add create, update, and delete functions to the queryset on the models so queryset functions operate the same way model functions do
• Move the save() and delete() functions from the models into their own pre_save, post_save, and pre_delete signal handlers and wire them up in email_extras/apps.py. This should allow us to use serialized fixtures in tests.
• Make the models swappable

This is my first attempt at this, so feedback and criticism is more than welcome!

This is extremely similar to email_extras.utils.send_mail, but it's a mixin for mail backends.

The main problem I have with django-email-extras is that third-party app developers have to explicitly opt-in to using it by calling our send_mail function. I am using django-accounts and django-allauth to handle user registration/login/forgotten passwords, and they use Django's built-in one from django.core.mail.

I think encryption should be as easy to implement and use as possible (while still remaining actually secure), so this is an attempt in that direction. With this backend configured all mail Django sends will be sent through this backend, and opportunistically encrypted along the way (if the user has uploaded a key).

I also mixed it in with Django's built-in backends, so there's Encrypting*EmailBackend for the Console, Locmem, Filebased, and Smtp backends.

~~I am explicitly not adding code to upload the key to keyservers because python-gnupg does not yet support generating key revocation certificates, so I don't want users to upload keys they can't easily revoke.~~ I added code to the new email_signing_key management command to automatically upload the key to one of more specified keyservers.

TODO:

• [x] Add management command/s for generating signing key? uploading to keyservers? with flag to skip if already exists?
• [x] Optionally sign outgoing email with generated key
• [x] Remove more specific exceptions and add a configurable exception handler for failed messages. I think this is a better way to handle things than simply throwing exceptions, because third party apps won't be expecting failed encryption exceptions or properly handle them.
• [x] Add user friendly messages when SIGNING_KEY_FINGERPRINT specified a key that doesn't exist
• [x] Document the process for how to add a signing key:
  1. Adjust EMAIL_EXTRAS_SIGNING_KEY_DATA
  2. ~~Fire up server, browse to admin for keys~~
  3. ~~Hit the "Generate signing key" button~~ Run the email_signing_key command to generate a signing key
  4. Copy displayed fingerprint
  5. Set EMAIL_EXTRAS_SIGNING_KEY_FINGERPRINT to copied fingerprint
  6. Restart server

Edit: Thought of more/better ways to go about things.