Internet and e-mail policy and practice
including Notes on Internet E-mail


2005
Months
Jun

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed


Home :: Email

12 Jun 2005

Mailing list best technical practices Email

You might think that it wouldn't be hard to run an e-mail mailing list, but you'd be sadly mistaken. (By "run", here I mean the technical parts of adding and removing addresses, sending mail, amd receiving responses. At Yahoo Groups, it's Yahoo running the lists, not the list managers.)

I've seen a few BCP (Best Current Practices) documents floating around like ISIPP's standards from a meeting last September.

So as not to miss the boat, here's mine.

  • 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.

  • 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-registration, 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.


  posted at: 16:11 :: permanent link to this entry :: 0 comments
Stable link is https://jl.ly/Email/bcp.html

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
It turns out you don’t need a license to hunt for spam.
27 days ago

A keen grasp of the obvious
Italian Apple Cake
585 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed



© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.