Sponsored by:

GFi MailEssentials
Hosted Spam Filtering
30 day trial FREE!

About Spam
Help for Users
Help for Sysadmins
Help for Marketers
Join Us
Link to Us
Site Index
About Us
Editor's Blog

Promote Responsible Net
Commerce: Fight Spam!
Fight Spam with Anti-spam Software for Exchange Server, now try it for 30days for FREE!

Bulk e-mail HOWTO

Some technical points:

DO follow all the RFCs, as noted below.

DO use real To: and From: addresses. The To: address can be either the list address or the recipient address. The From: address should at the least be something that will catch "unsubscribe" or "remove" responses and act on them them.

DO use a consistent From: address, since people use it to sort and whitelist your mail.

DO use a valid envelope MAIL FROM. If you send separate messages, use VERP or some other system that will identify the bouncing address.

DON'T resend a message that's rejected with a 5xx code. DO wait a reasonable time before retrying a message rejected with 4xx, and only retry it a finite number of times.

DO collect and count bounces, and remove addresses that bounce repeatedly.

DON'T put removed addresses back on the list "just in case the bounces were a mistake."

If your message is in HTML, DO include all of the MIME message headers that identify it as HTML. (You'd think this would be obvious, but mailers from the NY Times to Air Canada send HTML messages missing the mime-version header.)

DON'T use Javascript or other security-challenged features in HTML mail. Most mail programs don't run Javascript in mail messages anyway.

DON'T use "web bugs" (images with a CGI query string) in HTML mail messages. These are frequently used in spam to "confirm" address validity, and some mail clients will block them.

DON'T use IFRAME html tags in HTML mail messages; they are commonly used in viruses, and some virus-blockers will block them.

DO remove any addresses that people tell you to remove. DON'T insist that people send "remove" from the subscribed address, use your web unsubscribe page, or otherwise argue with remove requests.

For new subscriptions, DO positively confirm that the address you have is in fact the one that the user meant to subscribe. A remarkable number of people don't know their own address.

Some less technical points:

DO send mail on a regular schedule, like once a week or once a month, so users don't forget that they subscribed.

DO use straightforward subject lines and message bodies. Misleading subject lines are a highly reliable way to identify viruses and spam.

DO say why the recipient is getting the message, e.g. "you signed up for the cheese of the month list on September 4, 1997." If you get addresses from co-reg, tell the recipient where they signed up, and not just "one of our marketing partners."

DO make it easy for people to change or cancel their subscription, like a link at the bottom that takes them to a web page that already knows what their address is. If you make it hard to unsubscribe, users and system managers will block your mail rather than waste time arguing.

DON'T send huge messages. If you want to include a 100K graphic or animation, put it on your web server and link to it. Your friends will stop being your friends about the second time they have to download your 200K missive over a dialup link.

DON'T believe anything that a list vendor tells you about the source of an "opt-in" list. Whatever the people on the list opted into, it's unlikely to have been mail from you.

John Levine / Trumansburg NY / Primary Perpetrator of "The Internet for Dummies" and Information Superhighwayman wanna-be & Justin Mason (http://jmason.org/)