|
|
|||
|
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
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
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:
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 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 Returning confirmation to both addresses helps to reduce the probability of malicious subscriptions.
Best Practice 5
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
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
Whenever someone subscribes or unsubscribes (or takes any other administrative action on their subscription), send an acknowledgement. (mmc5)
Best Practice 8 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
Make it easy to unsubscribe. Very simple. (maps2, mlp002, mmc2)
Best Practice 10 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 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 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
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 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 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 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 Never never add someone to a second list, just because they subscribed to one list. (maps10)
Best Practice 18 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 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 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 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 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 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 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 If your list goes inactive for an extended period, request subscribers to reconfirm their subscription. (mmc7)
Best Practice 26 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
List Management Information
External Sources
My Newsletter
I Use Gammadyne Mailer I began using the Gammadyne Mailer 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.
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 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. |
List Email Headers
MailerMailer.com: 12 Tips and Best Practices for Successful E-mail Newsletters and Campaigns
|
This page created: Sun, 19.Oct.2003
Last updated: |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|