This topic is off topic. I have marked the subject as such. On 09/05/2012 09:40 PM, NMTUser X <...@gmail.com> wrote: > Would it be possible to send mail to myself encrypted in pgp/gpg, > use a token at the beginning of the email with the correct email > address (which is on the local network) have procmail or spamassassin > parse all incoming messages, strip the headers, decrypt the message, > and reinsert it into the mail spool to be forwarded to the correct > person? If so where do I begin to look? Could (gpgzip) attachments > be preserved? > > This would allow me to continue to use gpg I could ditch google and > use ANY mail forwarding agent - even hushmail - and I could keep my > professional life intact.
Okay, full stop before I tell you how to do this.
WTF are you doing using google if you're this paranoid? Not only are
they an advertiser giving you a service so they can farm your data for
profit, but they're also stats gurus who are insanely good at exactly
that! Continuing to use them but sending all mail to a remailer will
still grant them full access to your mail folders, so they still get all
that data anyway.
You appear to be trying to hack your way into privacy with Google.
Knock it off, there's no way you can make it work. (The only thing I
can think of would essentially be serving everything yourself and using
some kind of hack of their IMAP system for free cloud storage. This is
stupid as you can do far better -- consider hushmail or an ec2 system.)
I am therefore going to assume you're on an email infrastructure you
trust (for outgoing SMTPS, incoming IMAPS/POP3S, and secure storage of
your inbox/folders). This means I will reinterpret your question as one
that asks about masking the sender and recipient while in the clear over
the internet and leaving a minimal footprint overall. A further
assumption is that your recipients have and use PGP. Otherwise, there's
really no point in this exercise.
If your recipients use SSL to connect to their email infrastructure and
you trust that infrastructure, you're done already; your message
should(?) be encrypted point-to-point and therefore only visible to the
trusted infrastructures on each end. Anybody sniffing the traffic sees
only the two IPs involved. PGP is merely an extra layer protecting you
from misplaced trust (nosy admins, service providers getting subpoenaed,
insecure server backups, etc).
Otherwise, there isn't much you can do unless you have at least partial
trust.
Here's a draft that can do most of that:
Create user encryptedmail in the recipient's email infrastructure (or on
a proxy if you really want that kind of thing). Create a file at
/etc/mail/pgp-key-map with lines like "123ABC78=j...@example.com" (sans
quotes) that maps known keys (8-char IDs) to approved recipient emails.
Give encrypteduser this procmail recipe:
# Extract keys from message, get addresses from map file
KEY_RECIPS=`gpg --decrypt 2>&1 |perl -ne '/key, ID ([0-9A-F]{8}),/ &&
print "$1\n"' |grep -Fwf- /etc/mail/pgp-key-map |sed 's/^[^=]*=//'`
# If mapped keys were found and we're not looped, add anti-loop header
:0fhw
* KEY_RECIPS ?? @
* !^X-Proxied-By: encryptedmail@
|formail -A "X-Proxied-By: encryptedm...@example.com
# Forward if above matched and was successful
:0a
! $KEY_RECIPS
The sending end is easy, though your encryption agent won't be happy
about encrypting a message to an address that isn't being sent to. You
can encrypt /after/ signing rather than before and then alter your
"from" address to be uninformative if you want to hide this side (just
watch out for SPF and spam detection that keys on the sender
name/address). The recipient will be able to identify you by your
signature after decrypting the message. Remember that the Subject is
still in the clear.
Note: the "bad guys" can do this too, unless the PGP keys are
unpublished. That makes this security through obscurity; it's not
(currently) worth their while to look for because nobody does it and
it's much harder than merely scraping the To/Cc fields. There is other
identifying information in the headers that can be (painfully) extracted
as well. The above proposal does have those minor holes but is the best
~transparent way of doing this that I can think of short of a full-blown
remailer, which is only transparent to the recipient (after procmail
magic) since it would involve hackery at the client level for wrapping
up and sending a double-encrypted message.
Note 2: This has a hole spammers can exploit. You really need some way
of ensuring that the encryptedmail@proxy address is accessible only to
you. You can do this with procmail by isolating some piece of your
messages (ideally the PGP signature, but if you need to hide that,
perhaps a specific IP or a DKIM-signed From address).
signature.asc
Description: OpenPGP digital signature
