James S. Huggins' Refrigerator Door: Click here to go to my Home Page. best practices for ezine newsletter publishing and list management; qwerty
[/h/cpy1/bottom-panel-1-basic-NEW.htm] .
best practices for ezine newsletter publishing and list management - - - Photo of an @ sign above the world - - - Original photo copyright scorpion26 - - - Licensed through iStockphoto.com
 
   

Best Practices for ezine Newsletter Publishing and List Management

This document provides my set of best practices for ezine newsletter publishing and list management.

I have searched for ezine best practices, newsletter best practices, list management best practices and several other best practices keywords. And, I have used these other resources for both general inspiration and specific concepts. But ultimately, the responsibility for this list is my own.


History of My Best Practices for ezine Newsletter Publishing and List Management

I send out an ezine (newsletter) called Snippets . And I manage that newsletter on my own computer using Gammadyne Mailer. Because I have substantial control over the processing of Snippets subscriptions and mailings, I began looking for Best Practices to adopt for my list management and ezine newsletter broadcasts.

Recently, I also created a small "private" ezine. 1 This additional ezine increased my need to both standardize and improve my ezine processing.

As I began my search, I remembered encountering an organization known as MAPS 2 (Mail Abuse Prevention System) and their document called "Basic Mailing List Management Principles for Preventing Abuse". 3 That document provided a beginning.

Continued searching also led me to BestPrac.org and their ideas, as well as other resources I have listed below.  

I've used these resources, together with my information, observations and insights, to construct this list of Best Practices

I follow these Best Practices in managing all of my lists, particularly those I host on my own site with Gammadyne Mailer.


Best Practices for ezine Newsletter Publishing and List Management

Best Practice 1
Confirm that new subscribers want to subscribe before adding them to the list.

In the ezine business, this is known as "confirmed opt-in", "verified opt-in" or "double opt-in". 4 No one is added to the list until he has somehow responded 5 to an email message confirming the request. This attempts to prevent the receipt of unrequested email and also prevent someone from signing up an email address without the owner's knowledge. 6     (maps1, mlp001, mmc3)

Best Practice 2
Use a unique, unguessable code to ensure confirmations are valid.

The system must generate a unique, unguessable code to function as a "subscription confirmation code" (SCC) as part of a confirmed opt-in process. This code must be:

  • Created and recorded when a subscription is requested,
  • Included in the confirmation request email sent to the subscriber,
  • Returned by the subscriber and matched against the code recorded for the original request.

Use this same process to confirm other requests (e.g., web based unsubscription requests). 

The code should be "unguessable" to ensure that no one else can guess it to subscribe the address owner against their will.     (cmo)

Best Practice 3
Permit confirmation from other than the subscriber address.

Some subscribers will subscribe a forwarding address. It may be difficult for them to reply "from" that forwarding address. Permit confirmation emails to be returned to you from any address.

Best Practice 4
If any request (e.g., subscription or unsubscription) is confirmed from a second address, return confirmations to both addresses.

Returning confirmation to both addresses helps to reduce the probability of malicious subscriptions.

Best Practice 5
Screen "vacation replies", "out of office replies" and "autoresponders" to prevent such responses from constituting confirmation.

An automated reply (e.g., "vacation replies", "out-of-office replies" and autoresponder messages should not be considered valid confirmation messages, even if the reply quotes the unique code.     (cmo)

NB: while I am committed to supporting this best practice, investigation and experimentation continues for the best way to identify such responses. If you have any information, drop me a line.

Best Practice 6
Confirm unsubscription requests originating on the web or which are "click-thru". Optionally confirm unsubscription requests originating with email.

Just as it is easy to maliciously subscribe someone else through a web form, it is also easy to maliciously unsubscribe them through a web form. Such unsubscribe requests should be confirmed. Additionally, some lists provide a "click-through" or "one click" unsubscribe method by including a link in each email to unsubscribe. These are also dangerous because they are accidentally forwarded when the email is forwarded can then be clicked by the recipient. These requests should also be confirmed. Email unsubscription requests may be confirmed if desired, or may be acted on immediately.     (mlp002)

Best Practice 7
Acknowledge all subscription administration actions.

Whenever someone subscribes or unsubscribes (or takes any other administrative action on their subscription), send an acknowledgement.     (mmc5)

Best Practice 8
Disclose the origination information for all administrative requests.

When you send subscription and unsubscription confirmations and acknowledgements (as well as confirmations and acknowledgements for other administrative actions) include as much information as is practical regarding the origin of the request (e.g., the originating IP number and the timestamp details).     (mlp003)

Best Practice 9
Provide a simple method for subscribers to terminate their subscriptions.

Make it easy to unsubscribe. Very simple.     (maps2, mlp002, mmc2)

Best Practice 10
Provide alternative procedures for terminating subscriptions.

Sometimes even the simplest procedures don't work. In addition to the standard unsubscribe procedure, provide alternates, such as alternate email addresses, phone and fax numbers. When a subscriber wants to unsubscribe, do whatever it takes to help them.     (maps3)

Best Practice 11
Include comprehensive unsubscription information in each mailing.

Include in each mailing all the information a subscriber would require to unsubscribe. Include both the standard procedure information as well as information about alternative procedures.     (mlp002)

Best Practice 12
Remove undeliverable addresses from future mailings.

While it is not necessary to unsubscribe an address for only one bounce, repeated bounces, and particularly serial bounces, should automatically unsubscribe an address. Purging a list of bad email addresses reduces the impact on others' networks and hosts. While of minimal concern for small lists, this is particularly important for large lists.     (maps4)

Best Practice 13
ensure that lists are not used for abusive purposes.

Mailing lists can be used to abuse and harass. For example, individuals can be subscribed to the list without their permission. Even if you require confirmation, the simple but repeated mailing of confirmation requests can abusive. One approach is to implement a "suppression list" which permits people to have subscription requests ignored. This list could also be used by domain administrators to prohibit subscriptions by anyone at their domain.     (maps6)

Best Practice 14
Fully disclose terms and conditions of the use of addresses.

Tell your subscribers up-front how you intend to use their information ... in detail. A subscriber should not ever be surprised by the use of their personal information.     (maps7)

Best Practice 15
Fully disclose the nature and frequency of mailings.

Tell subscribers what the mailings will be about and how frequently you will send them. Whenever possible provide an archive of prior issues (at least a sample of issues) so potential subscribers can review them before subscribing.     (maps9)

Best Practice 16
Don't acquire lists for email.

Don't purchase. Don't trade. Don't borrow. It is virtually impossible to establish that purchased lists truly contain the addresses of customers who want to receive such emails. Don't bother to try.     (maps8. mmc1)

Best Practice 17
One subscription, one list.

Never never add someone to a second list, just because they subscribed to one list.     (maps10)

Best Practice 18
Develop, display and reference a Privacy Policy identifying all Personal Identifying Information (PII) collected by and for the ezine and guaranteeing privacy, confidentiality and limited use of all such information.

Maintain a detailed Privacy Policy. Keep it in an easily found place on the website and reference it in all emails. Identify all Personal Identifying Information (PII) collected by and for the ezine, either as part of the subscription process or as part of the publishing process. Guarantee that the email addresses and other Personal Identifying Information (PII) of subscribers will never be used for any other purpose than the one for which the subscriber knowingly and willingly subscribed. Guarantee that the information will never be sold, given, rented or in any way exchanged or traded with any other party. (The possible exception would be where the information is sold as an integral component of the ezine business as a going concern).     (mlp004, mmc4)

Best Practice 19
Protect email addresses of individuals disclosed in the publication.

If you want to permit "off-list" feedback to contributors or other individuals named in the publication, implement a time-limited email redirection service (e.g., through an alias), so that "off-list" feedback can occur without disclosing the email address of the individual.     (mlp005)

Best Practice 20
Protect emails against "harvesting".

Take reasonable steps to ensure that email addresses (particularly those which do not belong to the site owners) do not appear on websites in a manner susceptible to automated harvesting.     (wmd001)

Best Practice 21
ensure "open rate" and "click-through" tracking is not associated with Personal Identifying Information (PII).

General quantitative measurement of "open rates" and "click-through" is permissible. 7 But do not implement "web-bugs" (or any other form of tracking device) which permit association of Personal Identifying Information (PII) with the data. The system employed may not identify which specific subscribers have opened the mail nor which specific subscribers have "clicked-through".     (mlp006)

Best Practice 22
ensure advertisers are not spammers, do not violate Terms of Service and promote legitimate products or services.

For all paid advertisements within a publication, conduct "due diligence" on all intending advertisers to ensure: (a) The advertiser does not have a known history of spamming or other forms of net abuse; (b) The advertiser is not in violation of any applicable Terms of Service (e.g., their own, the publications, their service providers, etc); (c) The advertiser is promoting a legitimate product or service (e.g., it has a history of delivering the product and it is not of a type which may reasonably be suspected of falling within a category listed by the US Federal Trade Commission as a "Top Ten Dot Con").     (mlp007)

Best Practice 23
Follow laws, regulations and Terms of Service.

ensure that, in addition to abiding by with these Best Practices, you comply with all applicable Federal, State and local anti-spam and privacy laws & statutes.     (mlp008)

Best Practice 24
Maintain complete, accurate records.

Maintain accurate subscription records, including the origination information (e.g., IP Address, date and time information, confirmation, etc). 8 This information will be useful when you or your ISP receives a spam complaint. This information can also be echoed to subscribers to repeatedly confirm that they have, in fact, subscribed to your ezine.     (mmc6)

Best Practice 25
Reconfirm old lists.

If your list goes inactive for an extended period, request subscribers to reconfirm their subscription.     (mmc7)

Best Practice 26
Disclose subscriber information in each email body.

Subscribers may own multiple email addresses or aliases all forwarding to the same POP mailbox. Include the subscriber email address within the body of the email.

Best Practice 27
Disclose subscriber information in each email header.

Subscribers may own multiple email addresses or aliases all forwarding to the same POP mailbox. Include the subscriber email address in an X-Field (e.g., X-Subscriber or X-Recipient) in the email header.

To see how I do this in my email headers, click here.

Best Practice 28
Include individual subscription details in the body of the ezine.

Include a reminder in your mailings that the subscriber has subscribed, as well as relevant details of their subscription (e.g., the requesting IP address and date/time).     (mmc8) 

Best Practice 29
Provide your physical/mailing address and phone number.

Disclose your physical/mailing address and your phone number in your mailings. (N.B.: the new US CAN-SPAM act requires disclosure of the physical mailing address in commercial e-mail messages.)     (mmc10)

Best Practice 30
Respond promptly to inquiries and spam complaints.

If you receive an inquiry or a spam complaint, respond to it as soon as possible. For spam complaints, include that person's subscription information with your response.     (mmc12)

Best Practice 31
Provide whitelist info for your subscribers.

Provide information to your subscribers including (a) what addresses they should whitelist to ensure they receive your publication and (b) how they can whitelist your address. Provide this information (or links to this information) on initial subscription and in each email.

Best Practice 32
Individually address each email.

Subscribers may own multiple email addresses or aliases all forwarding to the same POP mailbox. Show the show the subscriber email address (and name, if appropriate) in the "To" field. Do not "hide" the subscriber information. For example, do not use a generic "To" field and hide subscriber information in the "CC" field.

Best Practice 33
Disclose US CAN-SPAM info in each email header.

Use X-Fields in the email header to disclose information required by the new US CAN-SPAM act. This includes (a) that the email is a solicitation or advertisement, (b) that unsubscription can be effected by following the information in the email and (c) the physical/mailing address of the publisher.

To see how I do this in my email headers, click here.

Best Practice 34
Disclose US CAN-SPAM info in each email body.

Prominently disclose information required by the US CAN-SPAM act in the email body. This includes (a) that the email is a solicitation or advertisement, (b) that unsubscription can be effected by following the information in the email and (c) the physical/mailing address of the publisher.

Best Practice 35
Limit the number of confirmation requests and fully disclose this number.

Individuals requesting subscriptions may sometimes not receive a confirmation email. Additionally, they may attempt a confirmation but have that confirmation fail, either because the reply email is not received or because their email client distorts the confirmation code or Subscription Confirmation Code. It is permissible to send a limited number of duplicate confirmation requests provided (a) that this is fully disclosed on the subscription page and in each confirmation email, (b) that the subscriber has a way to turn them off, (c) that the subscriber has a way to inhibit malicious subscription requests from third parties and (d) that the number is small (e.g., an original and three duplicates).

Best Practice 36
Provide an easy way to terminate confirmation requests.

After initially requesting a subscription, a subscriber may change their mind. If you deliver only one confirmation request this is not a problem However, if you deliver multiple confirmation requests, provide the subscriber with an easy way to terminate the subscription confirmation process.

Best Practice 37
Use a consistent subject line tag.

Begin ezine subject lines with a consistent "tag" or text (e.g., "[ezine-name]") which easily identifies the mailing as related to the ezine and facilitates both filtering and sorting of the email based on the subject line.

Best Practice 38
Use consistent "from" addresses.

Create and use consistent addresses as the "from" addresses for email related to the ezine. You may use multiple addresses (e.g., one for ezine delivery and another for ezine administration), but be consistent in their use.

Best Practice 39
Disclose all addresses used.

Disclose all the email addresses you use for emailing your subscribers. These may include addresses used for ezine delivery, for administrative emails and even your own personal email address, if you use that.

Best Practice 40
Disclose system function information.

Provide sufficient information to your subscribers to enable them to understand how the subscription and unsubscription system works. For example, if a subscriber may confirm a subscription from any address, disclose this to them.

Best Practice 41
Implement the list information address specified in RFC 2142.

RFC 2142 specifies that an address of "list-request@" should be implemented for the ezine, where "list" is the name of the ezine. For example, for Snippets, my first ezine, the address is Snippets-Request@JamesSHuggins.com. Email to this address should, at a minimum, return information on how to administer subscriptions.

Best Practice 42
Implement the abuse address specified in RFC 2142.

RFC 2142 specifies that an address of "abuse@" should be implemented so that individuals can easily send abuse information to a domain holder. Ezine subscribers may wish to use this address to complain about spam.

Best Practice 43
Implement the various miscellaneous addresses specified in RFC 2142.

RFC 2142 specifies that a variety of additional addresses (in addition to list-request@ and abuse@) should be created for domains. These include: ftp@, hostmaster@, info@, marketing@, news@, noc@, postmaster@, sales@, support@, security@, usenet@, uucp@,  and www@. Implement these as appropriate within your domain.

Best Practice 44
Implement the standard headers specified in RFC 2369.

RFC 2369 specifies that emails from ezines and other email lists should include six (6) standard header fields. These are: List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner and List-Archive. Implement these header fields to provide list administration information to subscribers.

To see how I do this in my email headers, click here.

Best Practice 45
Implement the List-Id standard header specified in RFC 2919.

RFC 2919 specifies that emails from ezines and other email lists should include the standard header field List-Id. This header field clearly identifies that the email is from a "list" and also uniquely identifies the list being used.

To see how I do this in my email headers, click here.


Key to References Above

cmo CluelessMailers.org
 
maps MAPS - Basic Mailing List Management Principles for Preventing Abuse;
the numbers reference the bullets listed under "Guidelines"; there are 10 guidelines referenced by maps1 through maps10
 
mlp BestPrac.org - Principles of Best Practice - e-zine & Mailing List Publishers;
the numbers reference the practice number shown on the referenced page
 
mmc MailerMailer.com - 12 Tips and Best Practices for Successful e-mail Newsletters and Campaigns
the numbers reference the practice number shown on the referenced page
 
wmd BestPrac.org - Principles of Best Practice - Web Masters / Web Designers
the numbers reference the practice number shown on the referenced page
   

List Management Information

List Email HeadersList Email Headers: An explanation of the RFC standard headers which should be used on emails for lists and ezines. Also identifies the supplementary user-defined fields I use on my ezines, as well as RFC standard email addresses ezine publishers should implement.

CAN-SPAM Is StupidCAN-SPAM Is Stupid: A personal rant about the U. S. federal law known as known as CAN-SPAM. While it is supposedly designed to help eliminate email spam, I think the law is stupid. The article also provides links to CAN-SPAM resources.


external Sources

MailerMailer.com: 12 Tips and Best Practices for Successful E-mail Newsletters and CampaignsMailerMailer.com: 12 Tips and Best Practices for Successful e-mail Newsletters and Campaigns: This simple list seemed focused more on "success" than "principles", but offering a few unique items.

Best-Prac.orgBest-Prac.org: An Australian based, globally focused anti-spam organization, founded in January 2001. The site does not appear particularly "active", but there is much good information here.

Clueless Mailers Spamdemic Research Center: Best Practices for Mailing List ManagementClueless Mailers Spamdemic Research Center: Best Practices for Mailing List Management: Apparently no longer "active", this is a fun site. The discussion of a "unique, unguessable token" is valuable. And, the site has some great graphics as well as an affiliated CafeShop store.

Clueless Mailers Spamdemic Research Center: GlossaryClueless Mailers Spamdemic Research Center: Glossary: Includes definition/discussion of "unique token".

MAPSMAPS: Originally founded in late 1996 as a not-for-profit organization, MAPS is now a for-profit company.

Guidelines for Proper Mailing List ManagementGuidelines for Proper Mailing List Management: MAPS' current statement of List Management Guidelines.

Guidelines for Proper Mailing List Management (PDF)Guidelines for Proper Mailing List Management (PDF): MAPS' current statement of List Management Guidelines as a PDF.

Basic Mailing List Management Principles for Preventing AbuseBasic Mailing List Management Principles for Preventing Abuse: An archive copy of a prior version of the MAPS information.

RFC 2142RFC 2142: Defines standard mailbox names for common services, roles and functions. These include abuse@, ftp@, hostmaster@, info@, marketing@, news@, noc@, postmaster@, sales@, support@, security@, usenet@, uucp@, www@ and list-request@.

RFC 2369RFC 2369: Defines structured header fields to be added to messages sent by email distribution lists. The three primary fields are List-Help, List-Subscribe, and List-Unsubscribe. The three supplementary fields are List-Post, List-Owner and List-Archive.

RFC 2919RFC 2919: Defines the List-Id header field to identify message which belong to a list and identify the specific list.

RFC-Ignorant.orgRFC-Ignorant.org: A clearinghouse for sites which think that the rules of the internet don't apply to them, maintaining a number of lists containing domains or IP networks which choose not to obey the RFCs --- the building block "rules" of the net.


My Newsletter

All About Snippets, My EzineAll About Snippets, My Free Ezine: This page tells about my free ezine (newsletter), where it came from, how to subscribe . . . the whole banana.

Previous Issues of SnippetsPrevious Issues of Snippets: This page links to the archive of Snippets issues.

History of Changes to SnippetsHistory of Changes to Snippets: Describes the history of Snippets, with emphasis on the technical changes I've made since starting it, including moving to  Gammadyne, adding double-opt-in and complying with CAN-SPAM.

Snippets Privacy PolicySnippets Privacy Policy: The short version of my privacy policy for my Snippets ezine. It explains that I do not spam. Period. And, I do not sell, lend or release your subscription information to anyone for any reason. 


My Use of Gammadyne Mailer

I began using the Gammadyne Mailer to manage and broadcast my ezines in late 2002. It is possible to use it very simply, almost out of the box. But it also features a very complete internal programming language to let you do just about anything you want. And, it keeps all the information on my PC in an Access database, where I know the information is secure and under my control.

It is screaming software. I strongly recommend Gammadyne Mailer.

PS: You can test drive my implementation of the Gammadyne Mailer just to see how it works. I created an ezine named TestZine to let me test my programming. You can test it too. Subscribe and receive a "sample issue". You can even try out some of the tests I perform, like submitting a subscription request twice in a row, or subscribing when I'm already subscribed or unsubscribing when I'm not subscribed, just to see how it handles these "special conditions". Just go to my TestZine page.

Disclosure: I participate in the Gammadyne affiliate program. Click here to link without crediting my referral account.


Notes

1. This additional "private" ezine provides ongoing information supplementing an internet marketing presentation I recently did at a conference for professional speakers. My presentation provided an introduction to the topic. Through the private ezine, continue to provide the attendees with ongoing information to help them with the internet marketing components of their professional speaking.

2. Founded in late 1996, MAPS originally operated as a not-for-profit organization. In 2000, it began charging for services and has now changed to a for-profit company. As a for-profit company it does not "speak for" the internet community in the same way a not-for-profit organization might. But I still appreciate it's contribution to these Best Practices. 

3. This document is no longer on the MAPS site. This link is to an archive of the original document. A revision (mostly in structure) may be found here

4. For more discussion of the different types of opt-in see www.spamhaus.org/mailinglists.html. For a humorous discussion of what to call these things, see
www.pan-am.ca/spammyths/rants/27jul2002.html

5. This process is generally implemented by sending the requester an email containing a unique, unguessable code or Subscription Conformation Code (SCC). The subscriber can respond either by sending an email reply (to send back a confirmation code) or clicking on a link in the email (to send the confirmation code as a URL parameter). For my ezines hosted with Gammadyne Mailer, I rely on the "email reply method".

6. Individuals can use ezine and list subscriptions as a means of harassment and abuse by subscribing someone without their knowledge or permission. The confirmation process attempts to prevent this from happening.

7. "Open rates" measure the how many of your emails are actually opened and read, as opposed to being deleted. "Click-through" measurement, measures which links generate clicks. Both of these metrics can be misused by not only tracking aggregate information but by linking the information to Personal Identifying Information (PII) so to identify which subscribers have opened the email and which subscribers have clicked. This linkage to individual subscribers is inappropriate and a violation of subscriber privacy. For more information on the issue of ezine privacy see ezinePrivacy.org.

8. I disclose above the full set of information which I keep for the subscriptions I maintain using my Gammadyne Mailer system.

The extra text menu links (previously here) are being removed in the site redesign.
Browser and search engine improvements have eliminated the motivation/necessity for them.

This page created:
Sun, 19.Oct.2003

Last updated:
16:14, Sat, 10.May.2014

. . .

NOTICE --- SITE  UNDERGOING REWRITE - SEE LINK BELOW FOR DETAILS

 Explanation of the rewrite: New Page Layout.
 Check out my blog: My Ephemerae
 Yes ... I want you to link to my site Please link to me
 Want to email me? I'd love to hear from you.
 I have begun tutoring in the South Houston, Texas area.

. . .
best practices for ezine newsletter publishing and list management; qwerty . . . best practices for ezine newsletter publishing and list management; qwerty