Clarification of purpose.

[uragit]

Okay, so it's not really an issue, but...

I'm starting to make a bunch of code changes in my repository but wanted to check that my understanding of the purpose of gpg-mailgate is in accord with others on the project so I can make sure I steer my changes in the right direction, or at least accommodate other's purposes when I make changes.

I noticed the original project at http://code.google.com/p/gpg-mailgate/ would encrypt email to a specific set of domain names, which was almost entirely opposite to my purposes, so I found it a bit confusing.

The current project here at ajgon/gpg-mailgate seems much more in accordance with my goals. I'm running postfix to handle my personal inbound/outbound email on my own single-user linux box, and wanted to encrypt any outbound email whenever postfix can find a suitable public key.

I don't encrypt inbound email (which is easy to achieve by making sure that my own public key isn't available so no encryption happens).

I only need to handle 100 items/day so it doesn't need to be super efficient.

The main problem with public key encryption of email is that not enough people use it, so I would always favor any changes that make the system easier to install/configure/run, even if this is at a slight cost in efficiency, or even results in some emails going unecrypted (as opposed to not getting delivered at all, for example if there is some misconfiguration of keys). I would also like to see more robustness under failure conditions, and more debugging messages in the logfiles. Ultimately I would like to see all major linux distributions include public key encryption options in their default setups.

So, is this in line with what you're all using it for or are there other use cases I should keep in mind when making changes? Please let me know. I'm happy to write code but would prefer to make the changes that are also useful to others because it will make it easier to keep my code synchronized with the main project.

[defuse]

I don't use this at the moment, but my use case is encrypting incoming mail so that it is encrypted while it is stored on my server and in my email client. So, if someone got control of my server or my PC, they would not be able to read the message bodies of my existing mail without knowing my private key.

I don't use it the way @uragit does, where it is used to encrypt outgoing mail. Outbound encryption should happen in the mail client, using an extension like Enigmail, so that the plaintext message is not exposed while being sent to the server or while being stored on the server. I think it's much more secure that way, and if you're using Thunderbird, it's just as easy.

[uragit]

@defuse, interesting points. I prefer to encrypt at the MTA (postfix) level because I want to only have unencrypted email to deal with in my own folders (in particular wishing to avoid the problem of having my sent folder be full of items I can't read because they're encrypted with somebody else's public key). Yes, I could also CC everything to myself so at least it would be decryptable using my own private key but I'd rather just have everything in plain text once it hits my own computer, reserving encryption for the data that is leaving my network to travel the public networks. (As an extension of this, I may add another postfix content filter that decrypts inbound email if it's PGP encrypted.)

Your use case also makes a lot of sense, but exists at a higher level of security than my own. I just want to avoid my email being routinely sucked into the huge databases of governments/corporations, willing to take the chance of a more specific threat against my own server.

(I use mutt for my email client which is perhaps not as functional as thunderbird for dealing with pgp encryption.)

It also occurs to me that I'm a bit old-fashioned, reading my email only using mutt, on an xterm, at my computer. If I was also using POP/IMAP and reading the email on multiple mobile devices then I would probably be more inclined to keep it encrypted.

Thanks for the feedback. I'll make sure I make no changes in my repository that would negatively impact using the code for inbound encryption.

[ajgon]

Hey @uragit!

First of all, thanks for all the amazing work you did. It's always nice to see, that project you took is living on it's own :) Secondly - my use case of this project (and how it all started) was simple. I wanted to have backup of all my emails on some commercial provider servers (in this case ZOHO) - because let's face it, their server are way more reliable, than my little box next to my machine :) So all wanted from it, was CCing all my ingoing and outgoing emails, to that zoho.com machine, while encrypting it in the process. And that was my one and only case.

Anyway, I'll keep an eye on your fork, and will try to merge all the gpg-mailgate changes from time to time.

Thanks!

[uragit]

@ajgon, Interesting use case! Makes sense, but I'm curious to know how you're actually achieving it; it's not obvious to me how you would do it with the current gpg-mailgate system. I'd added an extra-recipient option to help with debugging in my fork but this still wouldn't achieve your goal.

Easy enough to tell your mail client to CC your external account, but how are you getting all inbound email to encrypt and CC to the external account? (Hmmm, come to think of it, an old-fashioned .forward file might achieve this, or perhaps some .procmailrc work.)

Perhaps there should be an option in gpg-mailgate for this, although based on my own experience I'd have a ferocious amount of spam be forwarded through postfix to the remote site (and, as it would be encrypted, spamassassin would no longer be able easily to throw it out).

[rietta]

My use case is to make sure that outgoing email from web applications are encrypted when the recipient's GnuPG key is known. Each deployed server instance - some apps have many server instances - has a local Postfix satellite server whose only job is to accept outgoing mail from the Ruby on Rails application process and then relay it it the transactional SMTP provider. I investigated adding GPGME support into ActionMailer, but am able to use gpg-mailgate to accomplish the encryption of outgoing mail in a way that seems like a more natural layer. In theory the Rails app is the MUA, but in this case, encrypting before relaying the message on for delivery seems like the right place.