Securing Electronic Mailing Lists

Number: TR08-003
Date: 17 October 2008

Purpose

The purpose of this technical report is to highlight common configuration options found in mailing list management software that may help alleviate the threats against electronic mailing lists.

Table of contents

Overview
Design considerations
Operational considerations
Other relevant Resources
Appendix A - Configuration examples for Majordomo
Appendix B - Configuration examples for LISTSERV
Appendix C - Configuration examples for Mailman
Note to Readers

Overview

Electronic mailing lists (EML) are an effective way of sharing information with a large audience. They have been in use for many years in the Internet. A typical EML is linked to a single e-mail address used as a reflector. Any message sent to that e-mail address will be sent to each e-mail address subscribed to the mailing list.

The operation of an EML brings a number of security issues that need to be considered. An improperly setup EML may be abused in various ways, such as to send SPAM messages, harvest e-mail addresses, send malicious or offensive content, or create security breaches. The end result has a direct impact on an organization's security architecture and reputation. This document discusses some configuration options commonly found in mailing list management (MLM) software that may help alleviate the threats against EMLs.

Notice

Although EMLs heavily rely on the e-mail system, this document does not include security considerations related to the e-mail system or securing the underlying operating system. For recommendations on e-mail systems and operating systems, system administrators can refer to the NIST document "SP 800-45 Version 2, Guidelines on Electronic Mail Security" .

This document contains configuration examples for three commonly used MLMs: LISTSERV, Majordomo and Mailman. These MLMs were selected due to their popularity and the availability of their documentation and, therefore, should not be considered as an official endorsement by CCIRC.

Design considerations

There are several ways of setting up an EML, many of which will have an impact on the overall security of the service. A well thought out design plan will greatly facilitate the selection of the software and hardening of the service.

Defining a mailing list charter

An EML should be supported by a charter that will identify:

• The administrative roles and individuals assigned to it
• Subscription policies (who can subscribe, who can authorize subscriptions)
• Content related policies (who can post, who can send messages, who reviews them)

Defining administrative roles

EML management is usually broken down into several administrative roles. Each role can be delegated to an individual or to a group. Some of the most common roles are:

List maintainer
The list maintainer, or list owner, is responsible for the operation of the mailing list itself and has the power to approve subscriptions.

Moderator/editor
A list moderator/editor is responsible for the content of the list's messages and approves and/or edits messages sent to the list before they are mailed to the subscribers.

System administrators
The system administrators are responsible for the operation of the MLM software, the server hosting the MLM and the e-mail server.

Choosing the right mailing list manager (MLM)

EMLs are typically provided using specialized software called mailing list managers (MLM). There are several MLMs to choose from such as LISTSERV, Majordomo and Mailman. Each application has a different set of features and various levels of security. A well-defined policy and project charter will greatly help the selection of the right MLM.

Outsourcing the service

When using an EML service provider, organizations should ensure the service is able to provide the security features and functionalities described in this document.

Choosing the right operating mode for the intended purpose

Most MLMs have several operating modes such as "Announce Only," "Newsletter," "Private Discussion," "Moderated Private Discussion" and "Public Discussion." However, all EMLs are derived from two principal behaviours:

Announcement
This type of mailing list only operates in one direction. It is used by organizations to send information to a large audience. Only moderators/editors of the mailing list can send messages.

Discussion forum
This type of mailing list is bi-directional. It allows large groups of individuals to exchange information using a single e-mail address. Every messages sent to the mailing list will be sent to all the subscribed members.

The operating mode will define how messages are received and how they are delivered. Selecting the wrong operating mode will lead to management issues.

Linking MLMs with existing services

An MLM may interact with existing services such as mail, web and SQL databases. Each link with external services can create new security issues affecting both the MLM and the service. Therefore, each link must be carefully scrutinized prior to its activation and security architecture of all components must be analyzed as a whole instead of individually. Links to existing services should always be done using credentials dedicated to a single task with limited privileges.

Operational considerations

Although they can be used as a one way distribution mechanism, EMLs are much more complex to set up than a typical e-mail distribution list. The following section describes some operational considerations system administrators need to take into account:

Check regularly for software updates

An MLM is software and as such, it is bound to have vulnerabilities. Even though this recommendation seems obvious, this type of specialized service is easy to forget about as it usually runs by itself requiring very little attention from system administrators. This software should be included in your organizational patch management process and checked regularly for new versions and updates. This service should be monitored regularly just like all services that are accessible from the Internet.

Current known versions are:

Majordomo 1.94.5 (released on 5 February 2000)
http://www.greatcircle.com/majordomo/

LISTSERV 15.5 (Free and commercial versions released on 27 November 2007)
Free: http://www.lsoft.com/download/listservfree.asp
Commercial: http://www.lsoft.com/download/listserv.asp

Mailman 2.1.11 (released on 30 June 2008)
http://www.gnu.org/software/mailman/

Use a specific user ID to run the MLM

Most MLM applications do not need administrative privileges in order to perform their duties. They can, and should, be run under a specific user account with limited privileges to reduce the impact of security breaches through the MLM.

Member subscription and removal

The MLM usually has an automated subscription management features that handles subscriptions to and removal from the mailing list. In order to prevent abuse of the subscription management feature, mailing list administrators should consider the following recommendations:

E-mail validation using "Closed-loop Authentication"

Whenever someone sends a subscription or removal request, this mechanism will send an e-mail with a challenge token. If a reply containing the challenge token is not sent within a short amount of time, the requested action will fail. This mechanism prevents un-authorized subscription and removal of members.

Approved subscriptions

For private mailing lists, all subscription requests should be approved by the mailing list maintainer or owner in order to prevent unwanted subscriptions.

Sending messages to a mailing list

All messages handled by the MLM are sent using the hosting organization domain name. As such, every hosting organization is responsible for the message content. When the subscriber list contains e-mail addresses external to the organization, all messages should be reviewed and inappropriate content removed before being sent to the subscribers. The following recommendations should be considered:

• Attachments should not be permitted or should be restricted to specific types.
• All messages should be scanned by an antivirus software before being accepted by the MLM.
• Avoid HTML content or remove any active content such as Javascript, Java and Embedded objects (Flash, ActiveX).
• All messages sent to the mailing list should be moderated .

Remote list administration

Many MLMs permit remote list administration via e-mails. When using this feature, administrators should make sure a unique administration password is set for each list.

In addition to administrative tasks, many MLMs can accept commands from subscribers via e-mail. Although this feature is mostly used by subscribers to add their e-mail addresses to or remove it from the mailing list, some additional commands will let them retrieve archived messages, mailing list properties or even the full list of subscribers. It is highly recommended that system administrators review all features of the mailing list in order to disable any commands that are not needed. Additionally, private mailing lists should be marked confidential so they do not appear in the global list.

Other relevant Resources

NIST SP 800-45 Version 2, Guidelines on Electronic Mail Security, http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-45v2.pdf

The following article offers good information on creating a mailing list. See table 2.1 at URL: http://www.ddj.com/architect/184413005.

Appendix A - Configuration examples for Majordomo

This is a subset of configuration choices that can be made in Majordomo. Configuration changes are made in the "majordomo.cf" file and EML-specific files. Administrative roles are setup using e-mail aliases in the Mail Transfer Agent (MTA).

Administrative roles

The following e-mail aliases must be used to setup administrative roles:
owner-majordomo           Majordomo Administrator
owner-<list-name>          Mailing List Administrator (Gets the Bounces)
<list-name>-request         the e-mail addresses of individuals who answer administrative requests
<list-name>-approval      the e-mail addresses of individuals who approve messages to the list

Mailing list configuration file (<list-name>.config)

The following list is a subset of the available configuration options for a mailing list and their recommended settings for added security:

Setup the passwords
admin_passwd =          admin.password
approve_passwd =       approve.password

Subscription policies
subscribe_policy =        closed+confirm             (for Private Mailing Lists) or
open+confirm               (for Public Mailing Lists)

unsubscribe_policy =    open+confirm

Message moderation
moderate =                   yes
moderator =                 (leave undefined and use "<list-name>-approval" alias instead)

Restrict archive access to members
get_access =                list
index_access =             list
info_access =               list
intro_access =              list

Disable access to the subscribers list
who_access =              closed

Appendix B - Configuration examples for LISTSERV

This is a subset of configuration choices that can be made in LISTSERV. Configuration changes are made in the configuration file "site.cfg" in Windows or "go.user" in Unix. Additionally, a web interface can be used for administration. By default, the administrative interface does not use SSL. When enabling SSL for the web interface , relative URLs should be changed to fully qualified URLs. For instance:

WWW_ARCHIVE_CGI="/cgi-bin/wa"

becomes

WWW_ARCHIVE_CGI=" https://servername.domain.name/cgi-bin/wa"

Administrative roles

LISTSERV has only two administrative roles:

Mailing list owner
The mailing list owner manages the mailing list options and approves subscriptions.

Mailing list moderators
The moderators approve messages that are sent through the mailing list.

They are defined using the following keywords:

Owner =    owner1@hostname.domain owner2@hostname.domain
Editor =      moderator1@hostname.domain moderator2@hostname.domain

Mailing list configuration

The following list is a subset of the available configuration options for a mailing list and their recommended settings for added security:

Subscription =     by_owner,confirm      (for private mailing lists) or
open,confirm             (for public mailing lists)
Review =             Owner                       (Only list owners can review the member list)
Send =                Editor                        (All messages must be moderated)
Attachment =       No                            (No attachments allowed)
Confidential =      Yes                           (List name will not show in the global list)
Validate =           Yes,Confirm              (Restrict list commands)

A full list of keywords is available at the following location:
http://www.lsoft.com/manuals/15.5/listkeyw.html

Appendix C - Configuration examples for Mailman

This is a subset of configuration choices that can be made in Mailman. Configuration changes are made using the web interface.

Administrative roles

Mailman has only two administrative roles:

Mailing list owner
The mailing list owner manages the mailing list options and approves subscriptions.

Mailing list moderators
The moderators approve messages that are sent through the mailing list.

Assigning these roles to individual e-mail addresses is done in the "General list personality" under the "General Options" category and passwords for these roles are set using the "mmsitepass" utility and may be changed in the "Passwords" category.

Mailing list configuration

The following list is a subset of the available configuration options for a mailing list and their recommended settings for added security:

Privacy Options:
Under "Subscription rules" subcategory:
advertised =                 No
subscribe_policy =        Confirm and approve    (for private mailing lists) or
Confirm                        (for public mailing lists)
unsubscribe_policy =    Yes
private_roster =            List admin only

Archiving Options:
archive_private =          private

Content filtering:
filter_content =                         Yes
convert_html_to_plaintext =      Yes (default is Yes)

Note to Readers

The Canadian Cyber Incident Response Centre (CCIRC) operates within Public Safety Canada, and works with partners inside and outside Canada to mitigate cyber threats to vital networks outside the federal government. These include systems that keep Canada's critical infrastructure functioning properly, such as the electrical grid and financial networks, or contain valuable commercial information that underpins our economic prosperity. CCIRC supports the owners and operators of systems of national importance, including critical infrastructure, and is responsible for coordinating the national response to any serious cyber security incident.

For general information, please contact Public Safety Canada's Public Affairs division at:

Telephone: 613-944-4875 or 1-800-830-3118
Fax: 613-998-9589
E-mail: communications@ps-sp.gc.ca