Building Scalable Web Sites

Chapter 6. Email

We can extend the usefulness of web applications by providing additional channels in which users can get data in and out. Typical web applications already use email as a channel for outputting data to users in the form of alerts and notifications. Email can also be used to drive engagement and usage by pulling users back into the application.

A flip side of using email for outputting data is to use it as a vector for receiving user data. This gets a little bit trickier and requires some knowledge of email infrastructure and protocols. In this chapter we’ll look at what receiving email can add to an application, how to implement email receiving semantics, and the various pitfalls that occur along the way.

Receiving Email

Enabling your application to receive and process email can present some interesting possibilities and potentially add a lot of value to the product. If you think of applications as a core of logic and data at the center of a big distributed system, email can become just another input and output vector. Our applications already send email to notify users of events—a more suitable transport than HTTP since it’s asynchronous—so allowing the same interaction in reverse allows for extended asynchronous actions around your application. In this way, a user can interact with your application without visiting the web site. This can be both good and bad, but we’ll look at that more in Chapter 11 when we discuss public APIs.

There are many actions and behaviors ...