I'd be glad if people stopped asking for PFS in email. Email can not have PFS. If you actually implements PFS over email, it becomes instant messaging.
Yes, you can cargo cult the PFS algorithms over the email infrastructure, but if you save the temporary key, it's not PFS anymore, and guess what, if you want to save your message to reading later, you'll have to save the temporary key too.
> Pond messages are asynchronous, but are not a record; they expire automatically a week after they are received.
That's not email.
Ok, that's less "instant" than most instant messaging system. But it has the same trade-off. It has a bigger time window when messages can be decrypted, and messages last for longer.
If you give-up on reading your email latter, yes, you can have some kind of forward secrecy.
But the idea of perfect forward secrecy is not that your locally stored mail is securely encrypted in the future, but instead that mail that was intercepted in transfer should not become readable, even if your key is later recovered.
With your locally saved mail/messages it is up to you how to and whether to securely store them. You can save them decrypted if you are not worried about getting your device stolen. You can securely delete them if you think that you can not keep their content safe. You can do anything in between, it's your choice to make.
Isn't it enough to automatically change the public key used to encrypt messages sent to you periodically, signing the updates with your own master key? (where the master key is only to be used for signing, not decryption)
When you change the public encryption key, you decrypt all messages received under the old key, re-encrypt with a local key, and destroy the private decryption key.
This way, someone getting your private encryption key cannot decrypt intercepted ciphertext he got before your last key change.
Obviously it requires to change PGP to get a new signed encryption key every time (unless there's some extension that already does it?)
You'll be interested in TextSecure's Axolotl for asynchronous messaging - if you have a concept of a "conversation", you definitely can design your crypto to prevent decrypting "prior" messages.
Yes, you can cargo cult the PFS algorithms over the email infrastructure, but if you save the temporary key, it's not PFS anymore, and guess what, if you want to save your message to reading later, you'll have to save the temporary key too.