Ok all you developers out there…
I don’t care what language you write in or how good you think you are, there are some basic rules for sending email that seem to be continuously neglected which only causes unecessary drama for everyone around you.
I don’t care if you’re an internal/intranet developer, or work for eBay. It’s the same basic rules.
Being both a developer and a mail admin myself, I know this stuff gets complicated real fast. And I’ll also assume you haven’t been trained better.
So assuming you want to keep on developing code, here is what you should know…
1. ALWAYS follow ALL of the rules below
a. Whether sending 1 email or 60,000, the rules are always the same – no shortcuts!
2. ALWAYS authenticate, if you have the option!
a. Security is always important. Having proper permission to send/relay email is step 1, not step 99.
3. ALWAYS use SMTP TLS/SSL, if you have the option!
a. Again security is important, and you don’t want to be the developer who allows highly sensitive data and/or credentials to be read by a 12 year old, with a free network sniffer (http://www.wireshark.org/ or http://blogs.technet.com/netmon/), and then posted on MySpace.
b. No matter what you’ve heard, it’s too darn easy (and fun) to sniff network traffic.
4. ALWAYS specify a proper email subject, even during testing.
a. Blank subjects are bad form (see #6) and plain useless to all concerned.
5. ALWAYS insure a valid FROM and/or REPLY-TO email address.
a. Bogus data here increases the possibility that a server you are sending through can get blacklisted (worst case) or just poor email delivery (best case).
6. ALWAYS well form all emails sent, especially if you’re including attachments.
a. Using a good class (which is maintained by folks who know better) usually resolves this. Otherwise same concerns as #5.
b. If you aren’t using a class, then I expect to you to understand and have memorized all of these RFCs: RFC 821, RFC 822, RFC 2821, RFC 2822, RFC 2487, RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049
7. ALWAYS consider how to handle send failures in the event you are developing synchronous code.
a. If you are asked to write code to send an email, presumably the recipient is expecting one.
b. Failing to properly handle errors means that the recipient is left hanging which only leads to a shortened development career.
8. ALWAYS insure you can enable and see debugging internals of your mail code.
a. You can’t blame the mail admin folks if you have no idea what your email code is ACTUALLY doing.
b. They can’t AND won’t help unless you can provide PROOF of what is failing – they need to see the entire transaction. It’s the whole needle in the haystack thing. No mail admin wants to dig through a billion lines of logs to find your dumb mistake.
9. ALWAYS consider your email send volume and plan accordingly.
a. Don’t assume you’re allowed to send 6 million emails – you’re not. When in doubt ASK.
b. Network throttling and limiting is implemented for a valid purpose – to keep bad stuff from happening. You know the Vulcan saying… The needs of the many, outweigh the needs of the few, and YOU!
c. Uh bandwidth costs money. Even if you’re not paying for it, someone is. And that someone will find you (or worse your boss) and get the money and/or pounds of flesh. Unless you’re the developer writing the next version of Google Earth or Microsoft Word, you can expect it.
I won’t even go into how to properly test your email code before going into production, because I will assume you can take it from here. Right?
Those are the basics. Learn ‘em, live ‘em, love ‘em.
