On this page:
GNU Mailman is a package for managing electronic mailing lists. Mailman's chief distinction from other programs on the internet is its easy-to-use Web interface for list administration.
Other options available at MIT include:
- moira: a homegrown list service that is tied into other parts of the system, e.g., web.mit.edu access controls.
- LISTSERV: Runs on MITVMA and is no longer recommended for new users
- Announcement only email: no discussion, select authorized poster, spam filtering
- Very large lists: instant list moderation is available
- Lists that need simple archiving: (Drawbacks: searching private archives is not supported, Google will search public archives, and removing mis-sent mail isn't easy.)
- High-traffic lists: It has a digest mode
- Converting older spam-polluted lists: e.g., older lists that are published on the web and lists with common English names.
- Lists without continuing traffic: e.g., lists that have weekly postings
- Lists that also need to control permissions for AFS Lockers
- To function as a simple alias, e.g., email@example.com:firstname.lastname@example.org
- List owners that want low maintenance: Mailman requires a fair amount of moderation configuration.
To create a Mailman list, fill out and submit this form.
After your list is created, you can view it by going to https://mailman.mit.edu:444/mailman/admin/listname (where "listname" is the name of the list you just created). Anyone can enter this URL to get general information about any Mailman list, e.g., owner.
Also, anyone can check to see which Mailman lists they are members of by going to https://mailman.mit.edu:email@example.com?othersubs=List+my+other+subscriptions
NOTE: You need to know your password in order to log in.
A number of aliases are also created: listname-request, listname-admin, listname-owner, listname-bounces.
A corresponding Moira list is automatically created so users can send email to firstname.lastname@example.org rather than email@example.com
Non-members of a list, by default, can send email to the list, but the messages are automatically moderated. The list administrator can configure the list to either allow all non-members to send, or ban all non-members to send.
Members of lists can be configured to have their messages moderated or not moderated. Moderated means that they have to be approved by the list administrator before going to the list.
Non-members of a list can send messages but they are automatically moderated.
- Membership lists
- Privacy options
- Moderate postings
- Managing non-members posts to a moderated list
- Bcc'ing to a list (email messages with listnames that are not seen in the email header by Mailman are automatically moderated)
- Managing number of recipients for postings
- Managing message size
- Managing spam filtering
- Managing newsgroup moderation: this does not work at MIT because we don't have a Mail to Newsgroup gateway. If a list administrator turns this on, it will cause all messages to be moderated.
- If messages are being held for moderation, this could frustrate senders.
- Time-sensitive information shouldn't be held for moderation.
- You can have a primary list and sublists under it.
- Tree lists can be problematic: Moderation decisions can snowball down the tree with some unexpected consequences.
- If you try to run the tree list as a discussion list to which only members can post, it gets confused about who can post.
- Mailman has small categories, e.g., moderators are one list; members who can post are another list.
- Password reminders can be problematic, especially for sublists.
- Mailman likes sending auto-replies for actions, e.g., holding for approval, subscribing
- Occasionally, Mailman ends up on the Spam blocklists due to some of its behavior.
- Mailman has certificate support to enter the web interface (for Athena addresses only).
- You can write webscrapers to work with Mailman UI (i.e., essentially writing your own code to retrieve Mailman fields/values and avoid using a web browser.) Sometimes makes it easier to navigate than using a web browser.
- The mmblanche command will let you get a complete list of members
- All members of a mailman list are given a password; non-Athena users must use this password to update their list settings, since they cannot use certificates.
- Spam filtering
- Bounce processing: when an address is marked as bouncing, you get an email.
- Digest mode
- Topics feature: users can subscribe to topics within a list.
- My mailman list hasn't delivered mail:
The outgoing queue for Mailman stops because of a malformed message. If mail goes to archives, but not to users, this is why.
- I'm not receiving mail from my Mailman list:
The server has gone down. This means it won't be in the archives or in the moderator queue.
- Mailman is slow:
:Mailman delivers in chunks. The chunks process in parallel, but each list in a chunk runs address by address. Also mail coming from outside MIT must go to MIT spam filters twice.
- My confidential info ends up in archive that is publicly accessible and searchable by Google:
Make archives private. Edit list archives (This can be difficult and involves work on the part of the IS&T Network team.)
- Addresses have just been removed from my Mailman list:
Athena account deactivation occurred and now Mailman is noticing it.
- Someone removed a sublist:
A password reminder went to the sublist. Anyone can use the password to unsubscribe.
- Mailman is supported by the Accounts staff.
- They can do anything a Mailman list administrator can do.
- Some problems need to be handed off to Network support.
- If there's a ticket in the queue, you can send email with the ticket number to Accounts and they will look into it.
- More information: slide presentation