in reply to Module recommendations to send encrypted email

Just curious...why the need for the encryption for the emailing part? Is it an invoice from a shopping cart web app or such? if you absolutely have to then you have to..but if there's room to wiggle, i'd rethink the design instead of dealing with certificates, signing, encrypting, and securely sending emails. for example, bank doesn't send statements directly to customer. instead they just send an email letting the customer know the statement is available online, when the customer securely logs in. the only really (mostly) acceptable way for secure email is on a private encrypted network.
the hardest line to type correctly is: stty erase ^H
  • 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 02, 2010 at 02:29 UTC

    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;

    ...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