Re^2: Module recommendations to send encrypted email

mischief...

Thank you for all of the feedback.

First, I'd like to be a bit more specific irt my desire:

site visitor fills in form with private data
info is sanitized and prepped to be passed through `insert encryption method here' before being sent to a *single, known* email address
info is signed/crypted, in which my app and the recip MUA have mutual keys. These keys (private and public, on both sides) will not be shared anywhere else
recip MUA opens the encrypted email as normal, after entering their passphrase upon first execution of said MUA
recip is a user...I need PGP set up once at their end, and forever there after, things stay consistent

TLS(/SSL) is all well and good, but it doesn't provide enough protection, given that there may be some MTAs in between that may not negotiate it. Kudos on your work with NMS Formmail btw ;)

I use both MIME::Lite and Mail::Sender heavily, and have those modules so deeply entrenched in some of my projects that I have a local tag in case that a FBSD upgrade changes the code in an unexpected way.

I'm working right now on attempting to perform a basic kludge between Mail::GPG and MIME::Entity, but my fresh OS install is acting like a little biatch, and refusing to install numerous dependencies. However, that's not a Perl issue, so we'll leave that alone ;)

I much appreciate your very informative response.

Cheers,

-stevieb

Comment on Re^2: Module recommendations to send encrypted email

Replies are listed 'Best First'.
Re^3: Module recommendations to send encrypted email by mr_mischief (Monsignor) on Sep 01, 2010 at 06:42 UTC
I mentioned TLS is in case you need the headers and such protected in addition to the mail body being encrypted. It's not a substitute unless you control all points between the sender and the recipient. Since you do have just the one recipient, connecting with TLS directly to the recipient's MX could be useful if it supports that standard. You'd still need to protect the message on the hard drives of the MX and spam filter/virus checking/IMAP/POP/mailspool servers and between such servers, which the end-to-end encryption of GPG is great for handling. There are basically three ways to send a PGP/GPG encrypted message. There's the old inline way with ASCII armored data. There's the specific MIME+GPG way. Then there's the encrypt separately and just attach way, in which case a smart MUA might figure out the MIME info for the file on sending or receiving anyway. Since you want MUA support, either inline (for MUAs that use that dated standard) or MIME+GPG is the most likely route so your recipient won't have to save then decrypt the file as distinct steps. Mail::GPG handles both the GPG+MIME of RFC 3156 and the older ASCII armored inline sending and reading of RFC 2440. That means it really shouldn't be a problem. You could even test both ways with your user's MUA. Have you looked at the documentation for the Mail::GPG module? Is there some specific question you have about that, or some specific concern about how it may not meet your needs?	[reply]

Replies are listed 'Best First'.

Re^3: Module recommendations to send encrypted email
by mr_mischief (Monsignor) on Sep 01, 2010 at 06:42 UTC

I mentioned TLS is in case you need the headers and such protected in addition to the mail body being encrypted. It's not a substitute unless you control all points between the sender and the recipient. Since you do have just the one recipient, connecting with TLS directly to the recipient's MX could be useful if it supports that standard. You'd still need to protect the message on the hard drives of the MX and spam filter/virus checking/IMAP/POP/mailspool servers and between such servers, which the end-to-end encryption of GPG is great for handling.

There are basically three ways to send a PGP/GPG encrypted message. There's the old inline way with ASCII armored data. There's the specific MIME+GPG way. Then there's the encrypt separately and just attach way, in which case a smart MUA might figure out the MIME info for the file on sending or receiving anyway. Since you want MUA support, either inline (for MUAs that use that dated standard) or MIME+GPG is the most likely route so your recipient won't have to save then decrypt the file as distinct steps.

Mail::GPG handles both the GPG+MIME of RFC 3156 and the older ASCII armored inline sending and reading of RFC 2440. That means it really shouldn't be a problem. You could even test both ways with your user's MUA.

Have you looked at the documentation for the Mail::GPG module? Is there some specific question you have about that, or some specific concern about how it may not meet your needs?

[reply]