Using GPG to create virtual email addresses
Mon Sep 29 02:02:02 CEST 2003
I am interested in using GPG to create virtual email addresses such that:
* The address is unique for every sender/reciever pair.
* The address will change if the sender or reciever changes keys.
* The admin doesn't have to do anything for a new valid virtual address
* The reciever can have different processing rules based on the trust
the reciever has in the sender.
* The origional encoded data is not sensitive or directly used.
* The system should be easy to use (transparent if possible) in the MUA
* The system should enable the MTA to make SMTP time decisions decisions
to accept or reject delivery.
* The virtual address should be hard for a 3rd party to create.
Sender jacob@my_other_mailserver.com sends to
email@example.com, but the address is changed to
jacob+JPO/F?WE/ASDIOD@cachevalley.com before it is sent from the MUA to
the sending MTA.
The destination SMTP server (cachevalley.com) does a lookup after the
MAIL FROM and RCPT TO commands verifying that jacob+JPO/F?WE/ASDIOD is a
valid address for firstname.lastname@example.org and it was sent from and
encoded by jacob@my_other_mailserver.com. Direct mails to
email@example.com may or may not be accepted based on other
The receiving mail server doesn't need to have it's recipient's private
key. It is enough for it to decode using the sender's public key and
then verify that the result was encoded by the recipient's public key.
In many aspects GPG seemes like a good fit. GPG plugins are available to
many MUA platforms. The security is enhanced by a trust metric. Users of
GPG are able to revoke old public keys and submit new ones at any time,
the other party just needs to have their software fetch the latest
public key before processing the data.
The first obstacle to me seems to be the size of the encoded data.
RFC2821, section 188.8.131.52 says that the maximum lenght of local-part is
64 characters. The local-part after encryption needs to be RFC email
My question to this group is this:
Is there a method of encoding available to GPG such that it could make
the local-part restrictions target and still have enough data to
validate that encoding was created using a combination of the sender's
private key and the receiver's public key (possibly by having been
encoded twice, in that order).
Perhaps I don't even need the jacob+ part of the local-part. If that was
not necessary then all 64 characters would be available to GPG. If the
identity is necessary, maybe it should be <recipient gpg id>+<encrypted
username> for better length control.
As I mentioned in the requirements section, the encrypted 'data' isn't
realy used, except as a target of the encryption. Maybe there is some
'light signature' option that would work better. I think it would be
best if either party could change their current public key and have that
change reflected in all future virtual addresses until the next change,
and yet have the new address recognized shortly after the change is made.
If GPG cannot and will not accommodate this, is there some encoding
scheme out there that does?
MUA - Mail User Agent (Mutt, Pine, Outlook)
MTA - Mail Transport Agent (Sendmail, Postfix, Exim)
More information about the Gnupg-users