in reply to Module recommendations to send encrypted email

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.

  • Comment on Re: Module recommendations to send encrypted email

Replies are listed 'Best First'.
Re^2: Module recommendations to send encrypted email
by stevieb (Canon) on Sep 01, 2010 at 05:42 UTC

    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

[reply]

      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]

In Section Seekers of Perl Wisdom