There is Mail::GPG which seems like a good place to start. Are you looking at using that and having issues, or are you trying one of the general-purpose GPG or PGP modules?

If you're using a plain file-system based encryption module with which you're already familiar, I'd recommend at least considering encrypting the message with that then just attaching the encrypted message as a regular file with a general MIME-related mail module. You don't get exactly the same support from the MIME system for your encryption that way on the receiving end, though. If you control the receiving end that shouldn't be a problem.

While end-to-end encryption of the message payload solves certain problems, you might want to consider TLS mail as well. There is a Net::SMTP::TLS module that comes in handy there. There are also other modules that use it, like Email::Send::SMTP::TLS (which I've never used). I hacked on the NMS formmail program to get it to support Net::SMTP::TLS as a sending engine, though. If your email path always uses SSL or TLS anyway, this might not be necessary.

As far as good general mail modules that handle MIME, MIME::Lite is very popular for sending. Mail::Sender gets some praise, too. Mail::Builder looks promising but I haven't heard much from people using it. There are other modules for parsing MIME emails on the receiving end if you need to do that, too.

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

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?

I would offer two unrelated suggestions:

1. The communicating processes should, as a matter of course, send everything through an encrypted channel.   This could be software-implemented (e.g. SSL), or it could be a known-good VPN-capable hardware router.   This precaution will serve to protect all of the communications between the two parties, whether the traffic consists of “secret messages” or just “protocol.”   (Remember that whatever system you choose must provide for, not only encryption, but identity verification and data integrity as well.)
2. Don’t bother to “roll your own” implementation when a standard implementation already exists:   namely, S/MIME.

What you really want is for the entire communication process to be as transparent as possible.   “You are stuffing e-mail messages through a secure channel.   The recipient, whether it is a Perl program or not, receives the messages as-tendered.   It Just Works.™”   Both parties know that the messages came from their stated senders and were received as-tendered, but, insofar as possible, do not have to be inconvenienced by the process of obtaining these assurances.   “Yeah, it’s robust and secure.   Big Deal.” = Perfect.

I think stevieb means he's doing CGI (or some variation like mod_perl or FastCGI) behind the web server, and that the web connection between the browser and the web server is SSL. There's no need to intercept SSL, the web server will serve a CGI program over an SSL connection with no problems.

stevieb shouldn't have mentioned the web portion of the work, as it is quite irrelevant ;)

For completeness, I'm taking care of the web side of things with a mix of CGI::Application, DBIx::Class, a bunch of other modules along with some custom code, which is of course topped off at the presentation layer by Apache. SSL was mentioned to express that the input would be encrypted as it came in, and that the only unencrypted handoff would be in between the acceptance by a CGI app sanitizer/handler from the ass-end of the web server, and a hop (hopefully) right into another piece of code that would PGP it up for me for delivery

Steve

I literally *just* came back to reply to mischief, but this'll do

The reason for the encryption is thus: I have a friend's client who is a musician that plays a not-too-often-heard-of instrument. This client also happens to sell a lot of goods related to said instrument.

He is very much old-school, so he doesn't want a full-blown merchant account type setup, yet he is vehemently set on using email for communication (he does not like the web...I don't blame him ;) Currently, a potential client of his peruses his website, fills in a purchase form, prints it, and faxes it into the office.

After the form is manually validated, the client's client receives a phone call where credit card information is discussed.

Now, the client is not ready to go full-blown merchant-direct (which is what I'm used to writing code for), but he's been talked into going half way by my friend, as the number of orders coming in are now far greater than what all of his staff can handle.

So, web form displayed to the purchaser over SSL pushed out by an exclusive instance of Apache on a dedicated server. The form of course is simply a run through a CGI::Application module, so that there is no 'jumping' between an HTML page and my app (this allows me to 'watch' what is happening at all times through other code that I hook into my cgi stuff).

The info contained in the form will be cc and other personal info, so I don't want to store *any* information locally. My cgi:app forks the data through a sanitizer that I've previously written, and then is handed off to the wrapper that signs and encrypts the message via PGP. It is then handed off to another routine that will either push the encrypted/signed message to a local SMTP server (TLS) for delivery to the server that the client's mailbox resides (again, TLS) until he picks it up, or completely break RFCs by nuking it (as opposed to queuing) if delivery is not possible...in which case an error will be logged with but just very basic information of who, what, where and why.

Believe me, this is a huge step for him, and a wrapper to encrypt email that I can plug into any and all of my existing projects is something I've always wanted to do anyway. This has been a great learning experience for me on numerous levels. Besides, if someone wants to pay me decent money to learn about something I wanted to do anyway, who am I to bitch ;) You must understand/recall that I Am Not A Programmer

What I originally came back to this thread to say was that the following, combined with a few other lines of code:

#!/usr/bin/perl

use warnings;
use strict;

use MIME::Entity;
use Mail::GPG;
[download]

...works wonderfully!

...and that I have full intention on elaborating on my notes so that I can produce a front-to-back howto on the subject, starting with OS details and ending up with ./pgp.pl

Cheers,

Steve