Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Python3's email.message.EmailMessage #1409

Open
pazz opened this issue Jun 11, 2019 · 5 comments
Open

Use Python3's email.message.EmailMessage #1409

pazz opened this issue Jun 11, 2019 · 5 comments

Comments

@pazz
Copy link
Owner

pazz commented Jun 11, 2019

We've moved on to python3 which is great, but we do not yet make use of the new email libs API to create messages.

This allows to transparently create messages with "attachments" and "html alternatives" without the need to maually fumble sround with MIME parts. See here for examples.
Switching to message creation using this API should also deal with the weird encoding issues we have for header values (e.g. #1408 and many others).

Taking the long view, I believe that alot should replace the explicit "envelope" class in favour of making envelope mode simple operate on email.message.EmailMessages.

As a first step, it should be fairly easy to replace the ceode in alot.db.envelope.Envelope that creates an email message, using the examples from the module docs linked above.

Ideally, we would rely on some external module to create PGP/MIME or S/MIME signatures etc.
Does anyone have experience with python3's EmailMessage and PGP/MIME?

@dkg
Copy link
Collaborator

dkg commented Jun 19, 2019

I don't have any experience with wrapping python3's EmailMessage in PGP/MIME or S/MIME. i'd start with focusing on PGP/MIME -- but in any case key management seems like the hardest problem, harder than just how you do the wrapping.

I've just recommended that the gpg python module grow the interface you're looking for so that there is one canonical place for doing the right thing with this, and alot wouldn't need to maintain it directly.

As another possible approach without adding too many dependencies, is that, notmuch already uses GMime internally -- and GMime has python bindings via GObject Introspection (see debian package gir1.2-gmime-3.0) that might be useful, as they include cryptographic controls. This is still a lot closer to the wire format than i think you want, though, not nearly at the level of abstraction offered by EmailMessage yet.

@dkg
Copy link
Collaborator

dkg commented Jun 19, 2019

(the gpg python module seems like a good place to fix things if you're using gpg, which i currently assume alot is doing; if the idea is to use something other than gpg, then there may be other steps you want to consider)

@dkg
Copy link
Collaborator

dkg commented Jun 19, 2019

You might also take a look at some of the hints in juliank's recent blog post (i don't think you want to do exactly what he's doing there, but it's related and i think he's got the structural parts in decent shape)

@pazz
Copy link
Owner Author

pazz commented Jun 29, 2019

Thanks for the comments and pointers @dkg!
I agree that I'd be ideal if the gpg python module could provide such a functionality. Not only would it simplify alot's codebase significantly but I also suspect that this will have a positive impact on the wider popularity of PGP/MIME mails because I'd make it so much easier to pgp-i-fy stuff!

If anyone comes across an intermediate solution I'd be very interested as well, because I'd really like to clean up and update alot's message creation using the new email API without breaking existing pgp/mime features.

Update, FTR: Juliank's code actually uses the (old) email.message.Message API which I'm trying to replace in alot.

@pazz
Copy link
Owner Author

pazz commented Aug 11, 2019

#1421 replaces our homebrew "accumulate_body" method to extract a messages "body text" with simpler code based on python 3.6's EmailMessage API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants