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.