6.1. 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 eventsa more suitable transport than HTTP since it's asynchronousso 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 that drop out of having support for receiving mail, and principles and techniques in this chapter can be applied to any of these, especially when file attachments are involved. Let's look at a few of the most common features that we can build on top of such support:

File uploads

Uploading files is a real pain in regular web applications, especially when there are many individual small files. For each file, the user must click on a browse button, navigate his filesystem to locate the file, and click OK. For a user uploading 50 files, this process must be repeated 50 times, for a total of 150 actions.

For technically savvy users, we could allow the upload of a single ZIP file (or other archive) that we would then unpack server-side to get the files we need. There are a couple of drawbacks to this approach, howeverin addition to requiring that your users can operate the archiving software, you need to make sure your users have the software installed on their machines. Once they can create an archive, you need to deal with odd contingencies in archive formatting, including path and filename weirdness and archive passwords. If that weren't enough to worry about, you'll also need to protect yourself from ZIP bombing, in which a small archive file unpacks to be a huge multiterabyte monster. Not the best of situations to be in.

With email support, users can instead drag and drop all of their attachments into their mail client, and upload them all in a single action. This largely depends on their mail clientweb mail sucks in the same way our application does. This has been solved by a few web mail providers in the form of native apps to allow drag-and-drop uploading. So the rule here is as beforeavoid reinventing the wheel. Mail and web mail application creators have already put in the time and effort to make file upload easy, so we can leverage that work.

For large files this can start to degrade, as transfer between clients and mail transfer agents (MTAs) takes longer and longer. Email is best suited to small attachments such as text files, small documents, and small images.

Because of the broadcast nature of email, an application can join a mailing list and then pluck content and attachments from it for processing and archiving. A mailing list can also be used as a way of sending content to multiple applications at once.

Mobile blogging

Many mobile devices (including phones, smart phones, PDAs, etc.) support the sending of email, even in cases where they don't support any kind of web browsing. This ubiquitous interface allows you to offer mobile input file support with no special infrastructurejust instruct users to email their content to your application.

This can enable simple text interaction, such as blog posts, or mobile content delivery, including photos, audio, and video.

Support tracking

If your application includes a customer ticket support framework, then the ability to carry on an email dialog with your users becomes important. By allowing your support application to receive email, you can track support cases as they develop and collect case tracking in a single place.

The advantages over simply using email on both ends here are clearin a centralized application, multiple support personnel can share cases without having to rely on IMAP or shared Exchange folders. Support cases can be tightly integrated with the rest of your application: a single click opens up all other cases for that user, the user's account details, or all other related cases.

Simple automation and APIs

If you can receive and reply to emails, then your application can support a complete email-based interface. Commands are received as emails, parsed, and executed, returning an email response. This process of not trapping the user into having to visit a web page to perform an action fits well with the emerging Web 2.0 paradigmoffering alterative interfaces and APIs to manipulate user data.

The canonical example is a mailing-list management application. While allowing you to subscribe via a web interface, you can also send an email to request subscription, as well as probe the system for list information by sending email with subject lines formatted in a certain way.