[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New anon mailer idea?
Hal writes:
> - You'd want this feature to be optional. Some people might not want
> their anonymity limited by having their return address recorded, even
> in encrypted form.
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.
The encryption definitely needs some sort of random padding,
though CBC with a random IV plus length-padding at the end
should probably suffice.
> - The use of a symmetric cypher is a very nice way of getting the use-once
> capability, along with the "burn after reading" effect of a remailer
> chain which destroys itself as it goes. But it could be a considerable
> burden on the remailer operator to maintain the database. One possibility
> would be to fix a maximum time limit on how long the return addresses are
> kept "alive" and require some real money to keep them longer.
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).
You could also implement time-limits by including an expiration date.
Perhaps something S-Key like might be applicable, if you want to stick
to private-key methods?
> - 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 [email protected] syntax does this fine.
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.
Bill