Authors: Richard Clayton (Thus plc) and Rodney Tillotson (UKERNA).
Many others, within the LINX UBM Subcommittee and elsewhere, contributed through discussion of the issues and indeed by careful proof-reading. Thanks are due to everyone who helped.
- Joining mailing lists
- Leaving mailing lists
- Filtering email sent to lists
- Use of mailing list addresses
- Identifying mailing list email
- Format of outgoing messages
- Policies and procedures
- User responsibilities
- References and Resources
A mailing list is a system by which a single email message can be distributed to many different people at different email addresses. For some lists only particular people may generate traffic, others are open and allow many people to contribute. Mailing lists are used to distribute information for many different purposes, ranging from the discussions that help develop the Internet, through groups of individuals discussing their special interests, to businesses advertising products and services.
Mailing lists can be viewed as amplifiers of email messages. Just as with amplifiers of sounds, there is a responsibility on the operator to preserve the peace and to avoid damaging feedback.
This document deals with the running of mailing lists of all types. It explains what policies and procedures are Best Current Practice. Widespread adoption of the Best Current Practice outlined in this document will lead towards fewer complaints about the operation of mailing lists and hence to greater trust in email as a communications medium.
The primary audience of this document is those who operate mailing lists. It will also be of significant interest to the writers of mailing list software and to ISPs, and their abuse teams, who wish to discuss community standards with their customers. It is also intended to demonstrate to the public, to the media, to regulators and to other authorities that the industry is acting responsibly in this area.
This document should not be read or understood to constitute legal advice. It is simply indicating what "Best Practice" might be.
This document does not go into much detail on the uses to which mailing lists might be put, but concentrates upon describing "Best Practice" in operating them.
Draft versions of this document may contain factual errors or unendorsed opinions.
The LINX is a membership organisation formed to provide efficient Internet connectivity within the UK. Whilst individual members will undoubtedly endorse this document, it does not reflect an official position of the LINX itself.
There are some basic principles underlying the proper running of mailing lists:
- Everyone on a mailing list is content to be a member
- Mailing lists joined by personal request can be left at any time
- Mailing list addresses cannot be used for any other purpose
- Mailing list policies and procedures should be documented and accessible
- Email should be identifiable as coming from the list
- Users should be careful to keep inappropriate messages off the list
Best Practice can be seen, at its heart, as being the methods by which everyone ensures that these principles are upheld.
The first and most basic principle is that everyone on a mailing list is content to be a member. Mailing lists should always be operated on an "opt-in" basis with people choosing to add their names. They must never be operated as "opt-out", where people are joined up without their permission and then invited to leave if they are unhappy with the list.
Where email addresses are captured through a web page (or indeed through any other data capture mechanism) then it should always be entirely clear what purpose the addresses are to be used for. Getting "informed consent" in this way is not only Best Practice for the operation of mailing lists, but also avoids the risk of committing an offence under Data Protection legislation.
Email addresses are often captured for other purposes, such as sending information about an order for a particular product, or just for general correspondence. Data Protection legislation makes it improper to use the data gathered for one purpose for another, so having the address already can never be a valid reason to add it to a mailing list.
To make it simple to join lists it is common to offer an option to join by means of a checkbox on the same web page that captured an email address for another purpose. This is perfectly acceptable, but it is Best Practice for this checkbox to require an explicit action to add the address to the mailing list rather than having joining as the default setting, which might be overlooked.
Some mailing lists exist within companies or organisations to distribute information to people because of their job function. In such cases, where there are special relationships between the parties, it would be acceptable to add them to a mailing list without their overt consent. It is never appropriate to add members of the general public to mailing lists on such a basis.
Sometimes people attempt to harass others by forging requests to join lists. In order to reduce the inconvenience this causes it is Best Practice to get a confirmation of any request before adding the new email address. This is most easily achieved by sending a special email to the requesting address and then making it a joining requirement that this special email is responded to. In order to prevent a forger anticipating the special email, it is usual to provide a random (or otherwise impossible to guess) piece of text within the special email that must be quoted for a response to be valid.
Since confirmation requests could, of themselves, be used as a method of harassment, systems should be configured so that they are incapable of generating large numbers of such requests in a short period without human judgement being applied to ensure that valid traffic is passing.
It is Best Practice to keep copies of every request to join mailing lists and also of all confirming responses. The sending IP address and exact time of arrival should also be recorded. This information may be needed to investigate forgeries or just to demonstrate the bona fides of the list operator. It is regrettably common for people to forget that they have joined a list and then to complain about the incoming email that they have requested. If suitable records have been kept then the list owner will be able to demonstrate that they have acted honourably throughout.
The recorded copies of the request should be complete, including all email headers. The companion LINX BCP document on "traceability" discusses how these headers can be used to track down the originator of forged requests.
It is a basic principle that people can leave a mailing list at any time.
Most mailing list software provides an automated system for unsubscribing from a list. Where automatic unsubscribe is unavailable, the list owner should ensure that requests to leave the list are processed in a timely manner; ideally before the next email is transmitted to the list members.
Some software takes a pedantic view of the exact form of an automatic request and this can cause trouble, especially when requests are submitted from slightly different machines or systems than the automatic system expects. Therefore it is Best Practice to ensure that even where automated mechanisms are available there is still a manual system that can be accessed to ensure prompt departure from a mailing list.
It is Best Practice to provide leaving information when a mailing list is first joined. It is also Best Practice to repeat this information on a regular basis. Depending upon the nature and volume of the list, this reminder might only be sent as seldom as annually or it might be as regular as adding it to the end of every email transmitted through the list.
Some mailing lists are moderated; in that messages do not appear until the list owner has approved them. On the other hand, many lists are "open" and all email sent to the submission address will be relayed to the list as a whole.
For an open list, it is increasingly wise to consider passing email through "virus detection" software and perhaps through systems that attempt to identify bulk-posted material. These systems are not yet robust enough to be relied upon and so the list owner will need to inspect any rejections to ensure that valid mail is not being blocked.
Many lists will insist that email is sent from "members" and this can be useful in preventing the arrival of unsolicited mail that has been sent in an indiscriminate manner. Most senders of such undesirable material will not take the trouble to subscribe to the list before sending their message.
However, problems can arise in identifying whether email is indeed from a "member". People may use several different systems at different locations for posting and may not have complete control over identifying information placed on their email. This can cause "genuine" email to be rejected.
Because of the problems with identifying "members", list owners will need to make their own decision as to their list submission policy. It is not possible to recommend any particular strategy as Best Practice.
If submissions from non-members are rejected, care should be taken when constructing the "bounce" message. For example, a null return path should be used to ensure that mail loops cannot occur.
Mailing list programs may offer other useful filtering of messages. It is helpful to attempt to discard "auto-responder" messages reporting that a list member is on vacation and to redirect "administrative" messages (such as unsubscribe) away from the list itself to the "control" address.
The email addresses supplied for mailing lists should not be used for purposes that are unconnected with the list. People who are able to use multiple email addresses often use special addresses for lists and make special arrangements to sort their email, and so they will be inconvenienced if these addresses are used elsewhere.
The list owner will clearly be aware of the membership email addresses. If this information is to be shared with others, perhaps the list membership themselves, then Data Protection legislation means that permission must have been obtained for this and the processing of the data must be "fair".
Many list management systems offer the ability to provide a report of all the people who have joined a mailing list. It is Best Practice to disable such features and to ensure that it is not normally possible to obtain such reports in an automated manner. There is an obvious danger that such lists will be used by the unscrupulous for the sending of bulk unsolicited email. Allowing list members to see the membership lists but preventing outsiders from doing so may be sufficient to prevent abuse, but may necessitate the provision of two classes of membership if some people wish their membership to remain hidden. It is always Best Practice to make the membership list disclosure policy clear.
Email sent through a mailing list should be identifiable as such. It is common to use the "Sender" header line to indicate the email list that is sending the message. The use of trivial systems such as just "bcc"ing the messages should be avoided because it will not be possible for the receiver to know that it is mailing list email.
Mailing list software should have features for spotting "loops" whereby email that has already passed through the list cannot be re-injected. Typical systems will add special headers for tracing purposes or will keep records of the "fingerprints" of email that have passed through the list.
A commonly implemented scheme is to add the header "X-List-Info: " where the URL points at information about the list and, in particular, at information about how to leave the list.
Messages and message transfers must comply with all relevant standards, and in particular with the basic email RFCs (821 & 822, updated by 1123) as well as with email extensions such as MIME (RFC 2045-2049).
Within the email sending protocol (SMTP), the HELO command must not be misleading and the MAIL FROM address should be an administrative address associated with the list such as firstname.lastname@example.org. This address must accept incoming email. When the delivery of an individual copy of the message fails, this is the address to which a correctly configured mailer will return a report.
Whenever the list expander sends the message to a single mail system for more than one recipient, the RCPT TO: command that gives the destination address will normally be repeated, so as to improve efficiency. The number of recipient addresses at a single mail system for any one message should be limited to about twenty; although correctly designed mail systems should not object to any value below 100.
Some lists will customise the MAIL FROM addresses on an individual basis. This means that it is not possible to get the efficiency gains of sending only one copy of an email to each remote site. However, it can be extremely useful in identifying which email addresses have delivery problems. This is especially true where remote expanders or email rewrite mechanisms mean that the addresses in the delivery report received by the list owner bears little resemblance to any address subscribed to the list.
It is Best Practice to ensure that email sent through a mailing list has particular headers removed. In particular, "Return-Receipt-To" and "Disposition-Notification-To" should be suppressed since they will potentially cause the sender of an email to receive messages from every list member. Other header lines should be set as follows:
This is normally left as the email address of the person who sent the message for distribution. As discussed in Section 6, some lists will insist that this address is that of a list member, to prevent abuse.
This is often set to the list address so that replies are distributed to the whole list, however this is sometimes seen as undesirable. It is never necessary to provide a "Reply-To" address that is the same as the "From" address.
This should be set to the same address as specified by MAIL FROM: in order to identify the list. The Sender: header is not required if this would be the same as the "From" address.
It can be very useful for the expanding system to provide a new message-ID to replace the one in the original email. This assists in loop detection and in ensuring that message-IDs are unique. Email should never be transmitted without a message-ID.
The Received lines that recorded the transfers by which the message reached the expander system should always be retained.
Should be copied from the message before it was expanded.
Should be copied from the message before it was expanded.
Should never be present.
It is usual to set a relatively low limit on the size of any message that is automatically distributed. The list owner can always override this if it is desirable to do so for a particular message.
MIME attachments and alternative parts should normally be discouraged in messages sent to a mailing list. If they are to be accepted then care should be taken by the expansion system to ensure that the correct headers accompany the body. Further care will be needed if the list messages can also be supplied in a concatenated "digest" form or made available for reading via a web interface.
It is Best Practice to ensure that potential and current subscribers to a mailing list are aware of the list's policies and procedures. This is most usefully provided on a web page, so that a single URL can be provided to those who need to consult the information.
Mailing lists should have a specific person, or persons, who "own" the list and are responsible for its operation. It should be possible to contact the owner by email at an "administrative" address without using the list itself.
Although most of this document has concentrated on Best Practice for operating mailing lists, this is not just a matter for the list owner. Users have their part to play.
Users should join lists that are of interest to them, but unsubscribe - using the mechanisms provided - when they are no longer interested.
It can be an efficient use of resources to subscribe to a local expander that allows a mailing list to send a single email that is locally distributed to interested people. Users should ensure they make the list owner aware of this mechanism in any administrative correspondence, because this may be at the root of some types of distribution difficulty.
Lists typically have a submission address (for messages intended to be copied to all list members) and a separate control address (for messages intended for the list administrator). Administrative matters, for example requests to leave the list, should never be sent to the submission address.
Users should suspend their membership of a list during holidays. It is never acceptable to have "vacation" auto-responders send reports of their absence to the submission address.
Email should never be "cross-posted" between lists. This invariably causes problems for list owners and subscribers alike. Where the material is on-topic for more than one list then it should be sent individually to each list.
LINX Best Current Practice for combating Unsolicited Bulk Email
LINX Best Current Practice - Traceability
All published RFCs are available from:
Majordomo (a well-known email list management package)
LISTSERV (another well-known mailing list manager)
Mailman (the GNU mailing list manager)