Creating a Dynamic Email Drop Box Series
Part 1 The author discusses the creation of an email drop box that would allow a site’s users to accept data into their profiles via email sent to accounts that didn’t physically exist.
Part 2 In this article we will take a look at the first half of our task list.
Part 3 In this article we’re going to build the drop box application.
I was monitoring StackOverflow recently and came across an interesting issue regarding the creation of an email drop box that would allow a site’s users to accept data into their profiles via email sent to accounts that didn’t physically exist. At first read through the problem I figured “hey, no problem”! I posted a paragraph or two regarding how I would go about addressing this issue and left it at that.
On my way home from work I started to think a bit more about that problem. It was interesting to me from a social networking point of view. As I thought it over “what about this” light bulbs went off in my head. My initial suggestions to the fix might have been over-simplifying the issue. It wasn’t just a matter of creating an email address, downloading the emails, and parsing out the content from those emails. There was a lot more to it than that!
You might be wondering why you would even need such a feature. Let’s start there.
Why might I need a “Drop Box” feature?
3mindMe.com is probably my best example of how far one could take a feature like this. Their (very simple) site allows you to forward an email to yourself in the future. What’s that? In their words:
“What does 3mindMe.com do? Basically, we're a gateway to your future self: email us anything, and we'll mail it back to you at a future time and date of your choosing.”
How do they do this? Using a drop box style feature. They allow you to forward an email to their system with the time that you would like that email sent back to you appended to 3mind.com in the TO field. An example of this is email@example.com. But they take it WAY past just a simple 5pm. You could forward an email to them with the words “5 minutes before January 1st 2008” in the subject line. Or you could do one better and forward the email to 5minutesBeforeJanuary1st2008@3mindme.com!
Not everyone is going to need functionality such as 3mindMe.com. Let’s take this concept a bit further and apply it something more real world. In most social networking sites you have features such as blog posts, status updates, messaging systems, etc. All of these features could easily benefit from having email integration backing or feeding them. You could allow your users to send an email to firstname.lastname@example.org with a subject of “status – leaving work, heading to the bar on 6th street!” Your system could then pick up that email and parse it into the appropriate area of your site for the appropriate users. A blog post could be performed via email in the same way. A message could be sent to multiple users of the site too.
Still don’t see a purpose for this feature? Frequently when you build a community site such as Match.com, Craigslist.com, or any other site that might allow their users to send direct communications to one another, users might want to use anonymous emailing. This might be needed for a couple of reasons. If you ad revenue is generated off of your traffic you want to force people to come through your system to communicate with one another for as long as possible (they will exchange emails eventually though!). Also, in the case of a dating site, the users won’t want to give out their contact details until they know the other person isn’t “creepy”. This can be achieved by creating dynamic email addresses and assigning them to a given user such as email@example.com.
Another interesting scenario for dynamic email addresses can be seen in Google’s use of address alias’. They allow you to add pseudo aliases to your account by way of adding a plus sign and a tag to your account firstname.lastname@example.org where “andrewsiemer” is my gmail account and “workrelated” is the tag that I want applied to any emails sent with that alias. You can then use Google’s filtering to route any email sent to that address to my “work related” folder. Take a look at all the ways that they are using aliases and become a “gmail ninja”.
Now let’s look at what we need to do to create these features.
In order to design a feature of this nature we must first define what our requirements are.
Table 1: User stories that make up this feature
A network administrator needs to create a email@example.com account in our pop3 server that can receive all incoming emails for *@domain.com (a catch all box via a wild-card entry).
We need the ability to connect to a pop3 server to gain access to the emails stored in our drop box account. This connection should provide us with all of the standard POP3 commands such as connecting to the server, listing the emails, downloading the emails, deleting the emails, etc.
We need to be able to parse the content of an email into a more useable format.
We will need a mechanism that can match user accounts with the email addresses. We will need to match the sender and recipients to valid accounts in the system. We will use the email address of the sender to locate the sending account. We will use the username part of the recipient email addresses to locate the recipient accounts.
We need to be able route emails to appropriate features of the site by way of tagging. Tagging will be performed by way of our subject line. The first word in the subject line followed by a dash will serve as our tag identifier. If the tag is unknown the message will go the user’s inbox.
“Status” tag support
When a user sends an email to their account with the “status” tag we will update the user’s status with the content of the subject line.
“Post” tag support
When a user sends an email to their account with the “post” tag we will add a new blog post to their account. We will use the content of the subject as the title of the post and the body of the email as the body of the blog post.
Anonymous user emails
Similar to cragslist, a user should be able to send an email to a user that doesn’t match any of their account data but instead matches a system key that is related to the account. This would be an anonymous emailing capability. firstname.lastname@example.org
Drop box monitor
We will need a drop box monitor that periodically processes any received emails.
In this article we started to take a look at the concept of an email drop box. We discussed some cool ways that a feature like this might fit into your application. We took a look at some existing implementations of this concept. Then we broke this feature down into its key components in the form of user stories.
In my second article we will start to dig into our user stories a bit more and determine what the specific technical details are for each story. We will then work on the first few user stories. By the end of the second article we will have our email account set up and configured appropriately, we will build a pop3 client library, and take care of basic parsing of the emails.
In my third article we will wrap this series up. We will address our account matching needs. We will then extend our basic email parsing to support tag based feature identification and the actual processing of the emails. And finally we will move our application into a window service for stable server deployment.
I am a 33 year old, ex-Army Ranger, father of 6, geeky software engineer that loves to code, teach, and write. In my spare time (ha!) I like playing with my 6 kids, horses, and various other animals.
This author has published 29 articles on DotNetSlackers. View other articles or the complete profile here.
Please login to rate or to leave a comment.