Rajeev S writes:

As mentioned, here is my approach towards the full anonymization project.

AFAICS as far as described it will provide the outcomes you describe.

However, I don't understand the use case here. Most approaches use a single secret ID for each user. This is not just a matter of convenience for the developer, but a requirement in some cases. That is, the list members, although anonymous "in the real world", build trust relationships with each other in the list environment. "Full anonymity" is in any case difficult to achieve, as word choice, topic choice, grammatical construction, time of writing, etc fall into patterns over time.

Also, given your model of address-per-post, I'm again unclear on the use-case for off-list communication via the list server.

Finally, there are a number of sets of details you don't mention here but need to be discussed in your plan (even if you don't propose to implement them now, you need to ensure that you don't make it difficult to implement them!) First, there's a question of how the proposed off-list messaging is going to be handled. Those pseudo- random addresses are going to need to be made valid addresses to the host's MTA. That's MTA-dependent, and also will likely have security implications. To be sure that people don't inadvertantly reveal their identities just by hitting "R" those messages should be anonymized as well, so that any such replies have to go through the server too. Of course it's going to be impossible to prevent people from exchanging email addresses in the body of the text, but in that case it's really not your problem any more.

The second is cleaning up the rest of a post. The incoming trace headers typically identify the sender quite precisely. Quite likely you'll want to nuke everything that isn't required by the RFCs, in fact. You probably also should try to do something about .sigs, Message-ID (which is required), Date (also required, and which often gives timezone information) and other automatically added text.

Third, what about authentication for incoming posts? Do you care if people spoof addresses? I'm not sure this has any meaning in the one-shot address environment you propose, but that again is going to depend on the use case.

Fourth, you need to think about security for the encryption key and EmailMapper table, as well as any archives (you need to clean up archived posts before they go to the archive -- this is probably just a matter of where your Handler goes in the pipeline).

• Introduce a new model EmailMapper with attributes
  • ForeginKey to Address / User
  • seed, A 40 bit hash,unique
  • nuses, number of times this hash is used,max 5 or 10
• The approach is to encrypt the seed nuses times, with encryption algorithms like AES, each time the email ID is displayed.
• The email ID is displayed as <nuses><encrypted seed>
• The email is decrypted nuses times to find the parent seed and thereby point to the exact email address.
• A new seed should be generated for the user after a fixed number of attempts,say 5 or 10,as the repeated encryption routines can slow down the system.

The outcomes

• Everytime the user sends a message,his from address changes.
• At the same time, each of the from addresses point to the same user.
• The sender can use any stored address he has,like in the mail contacts,repeatedly, to contact with a user,as it has nuses attached with it.

So you need to store the addresses forever. How big might these tables grow? Could that be a problem?

Did you consider using the "seed" as a "salt" instead? Ie, regenerating the seed each time, adjoining it to the address, and encrypting the combination? That would allow you not store a database of addresses. Of course if the encryption were compromised, all the old posts could be identified, whereas in your scheme the EmailMapper table also needs to be compromised to get addresses.

Regards, and good luck with your proposal!