Mailman, the GNU Mailing List Manager
I'm constantly inundated with e-mail from friends, colleagues, users, developers, strangers, band-mates and spammers. Sometimes it's hard to tell them apart. A closer look at the nearly 2500 messages sitting in my inbox tells me most of these messages are from some mailing list or other. All in all, I like these mailing lists, perhaps because through them I communicate with my co-workers and I get feedback from the community on the open-source projects I maintain. The problem is, of course, that I get too much e-mail to keep up with. I'm not alone in this either, and the reasons are clear: e-mail mailing lists are great ways to meet and converse with people who share common interests.
There are probably a half dozen or more list-management systems that folks are using to deposit e-mail messages into my inbox. On python.org, we currently run about 60 mailing lists, most of them technical SIGs (special interest groups) centered around various Python topics. For a long time we used Majordomo, which was the standard in free list-management systems. A few years ago we started switching our lists over to Mailman, a GPL list manager originally written by John Viega, and in 1999, we were finally able to move all our mailing lists over to Mailman. In this article, I'd like to talk about what Mailman is and focus on what the future of Mailman might look like.
Mailman does all the common things you'd expect from a list manager. It has built-in archiving, supports RFC934 and MIME digest delivery, mail/Usenet gateways, e-mail-based administrative commands, integrated bounce handling, spam detection, flexible SMTP delivery, support for virtual domains, list moderation and more. Mailman runs on almost any Linux or UNIX-type operating system, and packages are available for most Linux distributions. You probably don't care, but Mailman currently doesn't run on Windows.
The most striking thing about Mailman is that it's highly integrated with the Web. Every mailing list has its own web page, and almost all interaction with the system for both users and list administrators can be done through the Web. This makes it easy to use for both computer novices and experts. In fact, I run many decidedly non-techy mailing lists, and most members can easily follow the web pages to subscribe, unsubscribe and modify simple parameters of their list subscriptions.
While list administrators are usually much more experienced computer users, they too can have an easy time configuring and managing their lists through the Web. Mailman's web administration interface allows them to approve or deny closed-list subscription requests, dispose of “held” postings (those that look suspiciously like spam or are posted to a moderated list) and configure the various operating parameters of their list.
Mailman's architecture is actually flexible enough to provide several ways into the system. The web interface is augmented by e-mail-based commands in the tradition of Majordomo. For list administrators who have access to the command line on the Mailman system, a large number of scripts are available for doing more complex tasks. About the only thing a list administrator can't do from the Web or e-mail is create and delete mailing lists, and we hope to improve this in future versions.
Mailman is written primarily in Python, with a few C modules for improved security. The core functionality of Mailman is implemented as a set of Python classes in a Python package. This makes it easy to interact with Mailman in two novel ways (for the hacker at heart). You can easily craft new scripts that use the Python classes, and you can interact with a live Mailman installation through the Python interactive interpreter. There's even a convenience script provided by Mailman, called bin/withlist, which does most of the boiler plate of using a mailing list interactively. You can invoke it like this from the command line in the directory where Mailman is installed:
python -i bin/withlist -l mylist
This executes the withlist script, opening and locking (-l) the “mylist” mailing list. Afterwards, you're left at the standard Python prompt with your open list object bound to the name m. You can then interactively inspect (or change) the object from the Python interpreter—a neat and very powerful feature.
As I mentioned, Mailman was originally written by John Viega who released the code under the GPL, so it has been officially adopted by the GNU project. You can find more information on Mailman at www.gnu.org/software/mailman/mailman.html, which is mirrored at http://www.list.org/.
Building Mailman from the source requires GNU make, an ANSI C compiler (gcc is, of course, fine) and Python 1.5 or better, although I recommend at least Python 1.5.2. All of these tools either come by default on your Linux distribution or are readily downloadable and installable, e.g., by RPM. To run Mailman you'll also need a web server, such as Apache, and an SMTP daemon, such as Postfix, Exim, Qmail or Sendmail. Building Mailman from the source in the gzipped tar file should be straightforward for anyone who is familiar with GNU configure. Be sure to read the various READMEs for specific configuration instructions related to the MTA (mail transfer agent), web browser and OS you happen to be using.
Mailman is officially at release 1.1, but the latest snapshot is available via anonymous CVS. See the above URLs for details. There have been some major architectural improvements in the CVS tree (probably to be called version 1.2) and more coming soon. I'd like to spend the rest of this article talking about some of those changes.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
3 hours 58 min ago
- BASH script to log IPs on public web server
8 hours 25 min ago
12 hours 1 min ago
- Reply to comment | Linux Journal
12 hours 33 min ago
- All the articles you talked
14 hours 56 min ago
- All the articles you talked
15 hours 6 sec ago
- All the articles you talked
15 hours 1 min ago
19 hours 26 min ago
- Keeping track of IP address
21 hours 17 min ago
- Roll your own dynamic dns
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?