Email Anonymization Similar to Craigslist in C#

Question

I am developing a site for which I would like to protect buyers by anonymizing their email addresses.Similar to craigslist's system, when a seller needs to contact a buyer they should be able to send an email to an anonymized address such as [email protected] which will then be routed to the user's email address.

My plan right now is to:

1. Set up a bucket (catch-all) inbox
2. Generate a random key for each buyer which will be the user specific ('1425415125' above) section of the email address
3. Monitor the bucket inbox and parse out this user specific section. Once I know the user, the email can be forwarded to the correct address

My questions are as follows:

1. Can you see any issues with the above solution
2. Are there any open source solutions to the existing problem
3. Are there any gotchas that one should be aware of when developing such a system?

Thanks in advance

JP

Tomi

While both answers below were insightful, I am starting a bounty to see what additional information - especially that pertaining to c# specific solutions - I can find – Tomi

While it doesn't get me any bounty, I think this issue was already solved here on SO. – Graecize

Answer 1

I did something related, though not quite the same. I setup a catch all inbox on my existing pop3 server (you probably have one already I'm guessing). I then used OpenPop.NET to read all new messages on a timer (say every 30 seconds). In my case I stopped at just processing the messagse but it's easy enough to generate a new message to the appropriate address and copy the body over, then send the new message out on your SMTP server.

One problem I see with your setup, and maybe it's just a misunderstanding on my part, is that while you are protecting the users original email address they will continue to be reachable at [email protected] basically forever. If I understand the way craigslist works, each posting has a different email address, and once the posting has been deleted/removed (or shortly after) the email address stops working. This makes it so that people can't just keep bugging you on that email address. The solution to this issue is easy, just make the email address coorespond to a post id or some other id rather then the users id in the database. The lookup will be just as quick but they will have a new email address each time.

Mcdowell

In terms of protecting email addresses - the anonymized email addresses will be refreshed at set intervals so that, for example, one day [email protected] will be valid and later that email address will point to nobody and instead the same user will be contactable at [email protected] – Tomi

This is messy.. what if the buyer and the seller correspond through the email rehashing? the buyer won't be able to reach the seller any more. I agree with @Patricker that the Id should be related to the posting id. – Bac

@Variant, there are some key business-specific concerns that you are not aware of. For my purposes, this is exactly the behavior I want. – Tomi

Answer 2

You may wish to look at mail "piping" - the ability for someone to send an email to a mail server, which then gets thrown immediately to an executable, which then forwards your mail onto the recipient (by pulling the real email address from the database based on the incoming address from the piped message).

My personal recommendation would be to check out HMailServer, which has a COM API (the admin side is written in PHP, hence the requirement for legacy interop), is free and open-source, and is very well-documented. It doesn't have mail piping built-in, but is easily extensible given the API and support for scripts which run on server-side message events

HTH,

Benjamin

Aqualung

Answer 3

I think this solution will make sense and is in use in a lot of cases. The hardest part is actually receiving the messages. You can actually handle all of this within your web app if you need to. I wrote a blog post highlighting a couple of ways to receive email in your web app. It applies mainly to Rails but the concepts should be transferable.

Maggio

They're a competitor, but Mailgun might do the trick here. They will allow you to receive emails to a central mailbox and parse them for whatever you need. – Photochronograph

Answer 4

The way you are lookimg to do it is the way I created a similar service. I would not recommend you writing your own smtp server. Use an existing mailserver and just use polling or some event based api.

The benefits of using a 3rd party mailserver is you can use existing backup and management tools on it.

Edit: I just noticed this has beed answered here with a better explanation. Pipe incoming email to a script on Windows IIS SMTP?

Snowy

Answer 5

I do not see any problem with your setup, infact that is correct way to do because if your scheduled application fails, the emails will still be in the catch-all email box. Only once the email has been successfully delivered to somebody, the email should be deleted. You will be able to monitor and log the activity of your own application to monitor progress and failures.

I do not recommend Piping because, if for any reason piping goes successfully but your exe crashes, you will loose the email. Tracking will be difficult. Scheduling the jobs will not be possible.

If your application is independent of mail server, it is easy to manage it and replace your mail server whenever possible. It is easy to extend.

In this you will have to use some pop reader library, and schedule your application to run frequently.

Ameba

Answer 6

In addition to email, you may consider a pull rather than push delivery mechanism, e.g: a message center web frontend or RSS feed. I say this because deliverability problems to various ISPs can be very difficult to troubleshoot and in my experience your users will never believe it's their ISP.

Bromide