From: "bill.stewart@pleasantonca.ncr.com +1-510-484-6204" <wcs@anchor.ho.att.com> The obvious implementation is to add a Generate-Return-Address: header so you can use it if you want it, but won't get one otherwise. Yep, that's one way that fits in with the cypherpunk remailer syntax; another way would be to have a separate address that you used to explicitly start a conversation, eg reply-remailer@somewhere.edu Hmmm... you could in fact make the Generate-Return-Address: header take the actual return address you want to use, like a Reply-To: header. That would be nice. (I'd been assuming that it would use the normal reply address - Reply-To:, From:, envelope address; in that order depending on which was given) The encryption definitely needs some sort of random padding, though CBC with a random IV plus length-padding at the end should probably suffice. Exactly my thoughts. Or make it a stream cypher with random IV. Public key has the advantage that the operator doesn't *need* a database. If you want to implement use-once addresses (or use-N-times), you could include a tag with the address (such as the IV), and reject future messages using that tag (e.g. save a hash of the tag). I think you missed the point - with your scheme it's still technically possible to decrypt the address years afterwards - you're relying on the remailer to always stay secure; with a delete-the-key scheme you couldn't even if you were hung upsidedown from the ceiling from your toenails by the gestapo. (Though you might want to...) - so a corrupted remailer would limit damage to only live keys that arrived after it was corrupted and not its entirely history of dead ones from the period beforehand. > - What we would really like is for the recipient to hit the "reply" button > and be able to send his mail back. Matt Ghio's remailer+62647629379278@wherever.com syntax does this fine. The problem is 99% of mailers don't support that syntax, and although it can be added by clever sendmail hacks, it can't be added unless you have root access, and the philosophy of cypherpunk remailers/keyservers/etc is that they run on random accounts with no special privileges. Hence why putting the address in the body is more portable. Also random remailer names are likely to draw less attention in your system's outgoing-mail logs that addresses that are obvious remailers. If desired, you could implement anonymous bit-bucket addresses this way as well, though they're somewhat more useful if your remailer generates encrypted outgoing messages. Alternatively, you can *always* generate either a real or a bit-bucket return address, and leave it up to the sender to inform the recipient that there's a probably-working return path. I don't like the idea of replying and no knowing if it'll get there - in fact, I meant to say earlier, if a reply is sent on a key that has expired I'd expect the remailer to bounce an error report back saying that the key had expired. G