> Write a small perl daemon to proxy the connection to the smtp server > (preferably on localhost+some other port). > > Accept the entire message, encrypt, forward to smtp server, and pass the > return code back to the connecting client (in case of an undeliverable > status). This is more complicated than it sounds. The script would need to check the recipient and make sure the message was deliverable - which would mean digging through virtuser, expanding aliases, checking access.db, etc. You also need to worry about promisc relay protection. You can get by without doing this, since Sendmail will just bounce the message later, but it will probably cause problems. We have an application that needs to accept mail for domains where we don't have the list of valid recipients (it is an SMTP proxy like you describe). What happened was, a spammer would do a dictionary attack against a domain, and we would accept and process every message, and re-deliver them to the customer's server. This is a small cluster of P3's and P4's sending something like 10 messages/second to a customer's Exchange box, which subsequently melted. Exchange actually has this very problem - Exchange 5 and 2k both blindly accept all messages to the local domain, and don't do the recipient check and alias expansion stuff until the SMTP connection is closed and the message is queued. Then it sends a bounce if the recipient is invalid. This is a real problem for some Exchange sites I know, since they have to accept every message they get to their domain, then bounce it. If the sender's address is invalid (common with spam), then they have to queue that message for a number of days, until it double-bounces to postmaster. Word is that MS is fixing it in the next release. Now, on to Bob's question. I think the easiest way to do it is to set up 1 Sendmail in queue-only mode (sendmail -bd -ODeliveryMode=q). Then have a small perl script (hey!) that picks up the new messages, encrypts them, and then drops them into another directory that has a 2nd sendmail copy that runs in queue-processing mode (sendmail -q1s). The only gotcha I can think of is that Sendmail is going to give you both a qf and df - and you only want to encrypt the message part, and not the stuff Sendmail uses to process the message. So you could only encrypt the df, but that would leave the Subject un-encrypted. You could experiment with encrypting only the qf lines that begin with H (Header lines), but Sendmail might not like those results either. The cleanest way might be to setup a new delivery agent, Mencrypt, that delivers to a wrapper script that runs the encryption, and then re-mails it through the Sendmail command. Your script would take the message in on stdin, and then send the encrypted output back into a new instance of Sendmail for delivery to the remote side. This would even give you the option of having a hashtable of recipients/domains to encrypt for - and you would just add a ruleset that looks the recipient up in the hash. If they're in there, then set the delivery agent to Mencrypt. Another option would be to have Sendmail deliver the message normally, but into a special mailbox (so you'd map *@domain.com to "encryptedbox" in virt or something). Then just PGP the plaintext mailbox and deliver the encrypted message through Sendmail (just grok the recipient from the message before you encrypt). This mailbox could even be a named pipe, into a perl script (hey!), that does all of the above. Then you don't have to worry about having 2 messages in the box simultaneously, wiping out the box, etc. Or you can hack procmail to do the encryption before delivery into a mailbox (assuming the recipients are local). The procmail source is nasty (at least it used to be), but is workable. Basically, lots of options depending on your specific requirements. Please ignore any further rambling from me. > Write a small perl daemon to proxy the connection to the smtp server > (preferably on localhost+some other port). > > Accept the entire message, encrypt, forward to smtp server, and pass the > return code back to the connecting client (in case of an undeliverable > status). > > Crypt::GPG is available via CPAN. > > > > > -- > > Bob Tanner <tanner at mn-linux.org> | Phone : (952)943-8700 > > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 > > -- > Matthew S. Hallacy FUBAR, LART, BOFH Certified > http://www.poptix.net GPG public key 0x01938203 > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > http://www.mn-linux.org tclug-list at mn-linux.org > https://mailman.real-time.com/mailman/listinfo/tclug-list > Adam Maloney Systems Administrator Sihope Communications _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list