Thanks for your comments.
I wasn't considering putting interactiveness into James itself, but into a completely new Mailet designed for the task that can be used only if desired.
The kind of thing I'm imagining (partly as a learning exercise) is probably very similar to what you have developed.
I'm considering (based on zero knowledge at present) a generic translating Mailet into which one or more translators could be plugged.
One of these optional translators would be an interactive content certifier/encryptor.
The issue of interactivity is actually one of security - if it doesn't ask for your password each time it encrypts/certifies, then it has to be given it in some persistent manner - not ideal.
My intention here is that it's only ever going to be run on the machine you send mail from and so the dialog will appear as if it had been displayed by the mailer in response to the send.
I'm not that familiar with Private Idaho, but the concept is very similar except that it's using your own personal keyring rather than one stored on a remote server.
Now all I have to do is find out how :-)
Darrell DeBoer wrote:
007801c147d3$8cc002f0$e900a8c0@daz2000">Hi Paul
The issue your facing is similar to one that I'd like to look at solving
with James. Basically, I want a local SMTP server which can modify the
sender "identity" (From, Reply-To) based on a set of Rules. This means that
I no longer will have to select different identities for different
recipients manually, I can base this on a set of rules.
I've already done a little hack of the RemoteDelivery mailet to this end. My
KMail client had a bug which caused it to always use the default identity
for the SMTP FROM header. This meant that all of my mailing list messages
always went to moderation, since they appeared to be from an "unsubscribed"
address. A simple change which mapped particular recipients to a particular
SMTP FROM address worked a treat.
As for "popping up a dialog", I'd hesitate to try to put this into James
itself. I would think the server should always run without manual
intervention. Proba bly a better plan would be:
1) Set up rules which deal with common cases automatically.
2) When the rules don't match the email, send to a location (say a
MailRepository) for further processing.
3) Have a separate app which monitors the MailRepository, pops up a window
for input, and resubmits the mail for processing once a response is made.
If this is just bleeding obvious, sorry about that.
ciao
Daz
----- Original Message -----
From: "Paul Sidnell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 28, 2001 1:20 PM
Subject: Idea: using James for encrypting/certifying mailsMy problem:
1. I want to easily/swiftly sign my outgoing mails with PGP/GPG
2. Mail tool plugins for this are bad except for Outlook [Express]
3. I'll never use Outlook [Express] on a machine I value :-)
My Plan:
Put an SMTP proxy on my local machine. As outbound mails pass through, itpops up a dialog box asking me what action to take; either:a) just send it.
b) certify it - it then asks for my password.
c) encrypt it, getting my pwd and using the recipient to identify whichkey to use.It is of course slightly more horrid than this since it will have todecode the mime structure and just encrypt/certify the top level text part,
but hey, that's what the JavaMail api is for...(I've got a really nasty prototype that isolates the actual message froman ESMTP transaction by pattern matching on the \n\r\n\r<message>\n\r.\n\r
and i've just realised that it's doomed to fail)My Questions:
Is James a good platform for this?
I've been hunting for a good Java SMTP server with the ability to plug intransformation components and James is the best I've come across although it
has "a few" more features than I need. A modified version of the remote
delivery Mailet seems like the place to start.Is this a mad idea?
Anything I've overlooked?
Might anyone else want this capability?
Thanks
--
Paul Sidnell
Electric Pocket
http://electricpocket.com
--------------------------------------------------------------------- Tounsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Sidnell Electric Pocket http://electricpocket.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
