Rocco --

...and then Rocco Rutte said...
% 
% Hi,
% 
% * David T-G [05/17/02 15:43:40 CEST] wrote:
% > ...and then Rocco Rutte said...
% 
% > Well, yeah; the point was that we don't need mutt's cool features here
% > since the mail interface isn't doing the encrypting.
% 
% Right, we (isn't it still only me who wants to solve something ;-)

Good enough.


% don't need mutt at all. I've tested a few things and found out
% two facts. First of all, I now know that it works. And second,

Good!


% I totally forgot that I'm running procmail on my machine which
% rewrites the content-type header so that I don't need Esc+P at
% all...

This is probably OK since you're generating the mail and it's pretty
simple, but I'd still be careful with that rewrite rule; it *can* break
things.  Moreover, given the scenario you describe below, you don't need
it.


% 
% > Will the mail also be delivered to the user, or are you just doing a
% > fancy version of a .forward file?
% 
% Only forward. I just want to redirect mails to user@machine to
% another account encrypted with my key (because I don't want
% any mail to be forwarded as plaintext).

Good enough.  I've done much the same thing when I made my nightly
backups and then put the files up for anon ftp retreival by cron.


% 
...
% > header that says it's an RFC822 message and mutt would read it pretty
% > transparently.  I dunno how the mix of MIME and not-MIME would work,
% > but experimentation should answer that for you.
% 
% What I'm going to do is to simply encrypt the content without
% any ugly hack. I put it in a mailbox on my machine and run
% some shellscript(s) over it to recover the original and write
% them back to another folder.

Ah.  Well, if *that* is the case...

What I would do is make a null-passphrase key pair specifically for this
purpose.  Then put the public key on the forwarding side and do the

  | gpg --encrypt --armor --recipient 0xNNNNNNNN \
    | mailx -s "autoencrypted forwarded mail" [EMAIL PROTECTED]

as previously discussed.  Then comes the fun part:

On the receiving side, something like

  :0 :
  * Subject:.autoencrypted.forwarded.mail
  {

    :0 f :
    | gpg --decrypt

    :0 :
    =MyCatchFolder

  }

will catch and *autodecrypt* it and, voila, you have the mail exactly as
it arrived at the original machine after a nonetheless safe transit (and
it requires no fancy ssh port forwarding and catching on your destination
system but, instead, goes through the public SMTP system).

Of course, the code above is untested, and to be safe I would use the
procmailex backup copy rule to save, say, 25 messages on *each* side,
and perhaps even pump the forwarding mail thru formail to add a no-loop
header of some sort on the way out, but you get the idea.


% 
% Cheers, Rocco.


HTH & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

Attachment: msg28220/pgp00000.pgp
Description: PGP signature

Reply via email to