My understanding of S/MIME isn't excellent, so I figure there are things I could be confused about which may make this a bit wrong.. I figure a command line S/MIME program which could easily be integrated into a remailer wouldhave the following features: A) limit on number of multiple concurrent procersses doing decryption. Remailer spams have the bad effect of spwaning hundreds of concurrent PGPs on the mailhost, bringing things to halt. Limiting number of concurrent decryptions would help this problem. B) A strong interaction with the UNIX shell, with the program returning a return code based on whether or not the decryption succeeded. (Remailers only do decryptions...) That way a remailer could something like: #!/bin/sh if smime -f < incoming-message > /tmp/decrypted.$$ then # Process /tmp/decrypted fi rm incoming-message rm /tmp/decrypted.$$ The option would also be a very low-cruft-output -- there would be none of that PGP v2.6.2 stuff that PGP sends out. Just the decrypted output and if the message cant be decrypted, nothing gets output. (Maybe a -q option for that..) I think the smime should be easily plugged into premail as well, but I don't know premail to know what would be necessary for that. I suspect Raph would have some input on that matter.
The other day I was wondering what it would take to make an anonymous remailer for an S/MIME client. Implementing S/MIME from scratch is a lot of work given the lack of a public domain implementation, but it seems that a remailer could be built on top of a commercial email product that supported S/MIME. The question is: What features should a commercial S/MIME email product have to make it easy to support a remailer? Are there a small set of command line options that would greatly simplify a remailer implementation? --Bob Baldwin
-- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org