Sysadmin notes: post-only mailing lists with GNU Mailman

Need for notification mailing lists

I found several people looking for a way to implement post-only mailing lists with GNU Mailman. However, I couldn’t find solutions that are described in sufficient detail.

In particular, this type of list is useful for notification mailing lists. In Bootlin’scase, whenever someone pushes commits to our public git trees, a notification e-mail is sent. Sometimes, internal discussions can follow, but we do not wish to make them public. This is why we do not want the list e-mail address to be shown in the messages that are sent. If the list address doesn’t appear in the To, CC or in Reply-To headers, members who are authorized to post messages without moderation won’t post replies to the list by mistake by using the “Reply to all” functionality of their e-mail client.

The problem is that the current version of GNU Mailman doesn’t support this type of list yet, at least with the parameters in the list administration interface. You can turn on the “Full personalization” option, which will send messages to each member individually, so that the list address doesn’t appear in the To header. You can also customize the Reply-To header, to an address that is different from the list address. However, the CC header will still hard-code the list address.

A possibility is to hack the /usr/lib/mailman/Mailman/Handlers/CookHeaders.py file, but this solution would apply to all the lists at once, and the changes you could make may interfere with Mailman updates. A much nice solution is to extend Mailman, to modify its behavior for specific mailing lists.

A working solution

This solution is based on explanations given on the Mailman wiki, and was implemented on Ubuntu 12.04.

First, create a list-test mailing list. Some of the commands below will assume that you named your new list this way. Now, go to its administration interface and enable “Full Personalization” in “Non-digest” options. In “General options”, in the “Reply-To: header munging” section, specify a reply-to address.

If you send a test message to your new list, you will see that the list address is still in the CC header of the message that you receive.

Now, create a RemoveCC.py file in the Handlers directory (/usr/lib/mailman/Mailman/Handlers/RemoveCC.py on Ubuntu 12.04):

# Your comments here

"""Remove CC header in post-only mailing lists

This is to avoid unmoderated members to reply to messages,
making their replies public. Replies should instead go to a private list.
"""

def process(mlist, msg, msgdata):
    del msg['Cc']

This will be yet another filter the list messages will go through. Now compile this file in the directory where you put it:

pycompile RemoveCC.py

The next thing to do is to modify the default filter pipeline for your new list. You can do it by creating a /var/lib/mailman/lists/list-test/extend.py file with the below contents:

import copy
from Mailman import mm_cfg
def extend(mlist):
    mlist.pipeline = copy.copy(mm_cfg.GLOBAL_PIPELINE)
    # The next line inserts MyHandler after CookHeaders.
    mlist.pipeline.insert(mlist.pipeline.index('CookHeaders') + 1, 'RemoveCC')

This will add your new filter right after the CookHeaders one. To enable this, you have to run:

/usr/sbin/config_list -i /var/lib/mailman/lists/list-test/extend.py list-test

You can now send a new test message, and you will see that the CC header is now gone.

Notes

• Of course, you can reuse the same extend.py file for multiple mailing lists. However, the solution doesn’t work if you don’t put the file inside /var/lib/mailman/lists/list-name (distributions other than Ubuntu 12.04 may have different paths).
• I didn’t manage to undo this change. The Mailman wiki gives a solution based on creating a file containing del mlist.pipeline and running /usr/sbin/config_list -i this-file list-name, but it didn’t work for me. Please post a comment below if you find a way to implement this, and return to “factory” settings.
• Don’t hesitate to share other ways of implementing this kind of functionality!