|
Often, part of what makes a great website great doesn't take place on the web at all. A great Internet site embraces other ways of communicating with its audience, and prime among them is email -- the quality of the confirmation messages, receipts, password reminders, newsletters and bulletins you send out.
After all, where would Facebook or LinkedIn be without the ability to send you email notices when a new friend or contact request is awaiting you on the website. The website may be at the center, but the emails keep drawing people back.
Email can also be an alternate input mechanism. For example, in his book Building Scalable Web Sites, Flickr architect Cal Henderson talks about the importance of allowing members to establish a special email address where they can send their photos, and the service will automatically add them to the member's account. Among other things, this feature allowed Flicker (now part of Yahoo!) to capitalize on the advent of email-capable camera phones.
Email generation and processing is a whole area of Internet programming and design that gets relatively little press, while the web takes all the glory, and yet it presents considerable complexity. Should your messages be formatted as text, as HTML, or both? If you send HTML mail, will the images in your message be displayed automatically or the desktop email or webmail program on the other end suppress their display. Will your message be delivered at all, or it will it be blocked or sidelined into a spam folder by some algorithm that thinks it has spotted some spam-like characteristics in the content of or the headers on your message?
You particularly need to consider these questions if you are conducting some custom capability for exchanging information with your users, rather than taking advantage of some email functionality built into your portal or e-commerce software. However, even if you are taking advantage of some packaged software capability you may occasionally need to dig into the weeds in order to figure out why your email is being rejected by some recipient's server or investigate complaints from customers who never received their receipts.
The best book on the subject I've found is Programming Internet Email by Dan Wood. The book is a few years old (1999), but the basics haven't changed. It would be nice to see an update on the material regarding defenses against spam and how to keep your own email from being classified as spam, however. As supplimentary reading, you may want to research the Sender Policy Framework, one of the newer developments that has emerged for helping email senders identify themselves and avoid having their email addresses hijacked by spammers.
The book includes code samples in Perl and Java, but I thought the more important parts were the explanations of the Internet standards that govern email, such as the structure of message headers and of the Multimedia Internet Mail Extensions (MIME), which are used to separate and classify the parts of a message and the content type of each part. An email message is transmitted as one long block of text, but the MIME separators tell your email program which parts to display as text or HTML and which should be decoded into binary attachments.
One useful technique for making your messages pretty, but also ensuring that everyone can read them clearly is to use the MIME multipart-alternative type as a wrapper around two alternative versions of the message, one in HTML and the other as plain text. Email clients like the one on my BlackBerry that don't deal well with HTML content can display the text version instead.
Because some email clients may not display the images in an email, or at least not by default, it's important to make sure that your message is still intelligible in a text-only view. I see this rule violated a lot, with retailer flyers that arrive in my inbox and are displayed in Thunderbird as an unintelligible mess of broken images, at least until I click the "display images" button. Gmail is similarly suspicious of images in HTML email. In both cases, the email programs are trying to protect you against a couple of things: (a) displaying some pornographic or otherwise offensive image that you don't want to see and (b) displaying an image that is only there to confirm receipt of the message -- that is, a spammer can detect when a request for an image on a remote server by monitoring the web address associated with that image.
There's another technique that involves sending the images with your message as attachments, which may work better in some cases. But I've also had that set off alarms with anti-spam programs that see those attachments as suspicious. (If anyone has figured this out better than I have, I'd love to hear from them).
In fact, most of the headaches I've encountered dealing with server-generated email are side effects of the battle against spam. After all, spam is almost by definition the result of some server somewhere cranking out messages to lots and lots of people who never asked for that communication, whatever it is. So your server generated email may well share some of the technical characteristics of that spam. Also, one characteristic of spam that anti-spam programs leverage is that spammers tend to do sloppy work, so any mistakes you make can hurt you.
For example, at one point I was getting email bounce notices complaining that certain messages I was sending out failed to provide all the required headers specified in the Internet RFC (Request for Comments) documents governing email. It turned out that the messages were missing the date header, which I assumed would be added automatically by the PHP classes and sample code I had used to build this solution for sending out calendar reminders to a membership group. The addition of a couple of lines of code to specify the date cleared that up.
On to the next problem.
Only registered users can write comments.
Please login or register. |
