[ OpenInfo Home ] [ UP ]

Mailman Patch #1442025: List Specialisation for Support Groups


Many companies want to use a single mail address as the contact point for customers needing access to support or sales staff within their company. A typical scenario is:

When a member of the support team responds to the customer posting to the list the response comes from them unless they can persuade their MUA otherwise. This can raise a number of problems:

Granted, the problems being described might be handled better if the company deployed a specialist Helpdesk system but these are often commercial products and relatively expensive to license. This patch provides a partial solution for the more frugally minded.

The conclusion I reached in discussing this with support staff was that the communication between customer and support team needed to be more list-centric:

Technical Solution

The changes made to Mailman by this patch to support the desired style of list operation are as follows:

  1. An additional mail alias is associated with each list: the listname-response alias.
  2. An additional delivery script called "response" is defined to accepts posts to the listname-response alias which inserts posts into:
  3. An additional message queue - qfiles/response - which is used to accept messages sent to listname-response alias.
  4. An additional queue runner - the ResponseRunner - is used to process incoming message inserted into the qfiles/response queue: see (7) below for more explanation of its operation.
  5. A modified handler pipeline is used for processing messages sent to the primary listname alias. By comparison with the standard default pipeline, there is an additional element in the pipeline immediately prior to the one which distributes outgoing messages to the list subscribers. The handler rewrites those message headers defining the origin of incoming message so that the message as seen by the subscribers will appear to come from the listname-response alias of the list. This is so that any subsequent response to the posting by a list subscriber will be directed back to the listname-response alias. To retain information about who the original poster was, the headers are actually rewritten to a VERP'ed listname-response address with the original poster's e-mail address in the VERP information.
  6. When a list subscriber responds to a message distributed by the list, typically by using the "Reply" option on his MUA's GUI, it will be directed by the MUA to the list's VERP'ed listname-response alias and thence into the qfiles/response queue.
  7. The ResponseRunner introduced in (4) above processes incoming messages sent to the listname-response alias as follows:
  8. Other consequential changes include adding a radio-button selector to choose between "regular" and "support" style of list to the web admin GUI (on the General Options page) which controls a list attribute which tells the IncomingRunner which pipeline to use to handle messages to the list's main alias: the normal one or the one with the additional element described in (5) above. Some default configuration variables and modifications are made to the Default.py.in file and the mailman delivery wrapper modified to know of the additional incoming mail script called "response".
  9. The per list alias generator is modified so that all list created will have the extra listname-response alias. If existing lists are to be configured via the web admin GUI to be closed subscription support lists as described above then bin/genaliases will need to be run to generate the extra -response alias for all lists.
  10. The information in the VERP'ed addresses to the -response alias of a list contain some check digits in addition to the original poster's e-mail address. This allows a degree of validation that messages to the -response alias are legitimate. The "realname" component in these addresses tries to incorporate the "realname" from the original poster's address while being clear that the message has been handled by the list along the way. The original values of the headers rewritten as described in (5) above are incorporated into the headers of the message distributed by the list by headers such as "X-Was-From:". This should mean that, in extremis, the list subscribers can read who the incoming message was from by looking at the headers.

Caveats and Restrictions

The use of VERP'ing as described above means that only one e-mail address can be associated with the message distributed when it receives a posting. This address is determined by using the get_sender() function in the Mailman/Message.py file, which is called without any change to its defaults. The function description is:

        """Return the address considered to be the author of the e-mail.

        This can return either the From: header, the Sender: header or the
        envelope header (a.k.a. the unixfrom header).  The first non-empty
        header value found is returned.  However the search order is
        determined by the following:

        - If mm_cfg.USE_ENVELOPE_SENDER is true, then the search order is
          Sender:, From:, unixfrom

        - Otherwise, the search order is From:, Sender:, unixfrom

        The optional argument use_envelope, if given overrides the
        mm_cfg.USE_ENVELOPE_SENDER setting.  It should be set to either 0 or 1
        (don't use None since that indicates no-override).

        unixfrom should never be empty.  The return address is always
        lowercased, unless preserve_case is true.

        This method differs from get_senders() in that it returns one and only
        one address, and uses a different search order.

In the case of most normal messages a single address in the From: header will be the one used. If the From: header contains multiple addresses, which is legal but not that normal with most messages, the first of those listed will be used.

The "hacking" of the original posted message's headers to form the distributed-to-subscriber message also strips out all the original From:, Reply-To:, To:, Cc: and Bcc: headers, some of which are changed in any event by normal Mailman operation. The values stripped out are preserved in as series of X-Was-To:, X-Was-Cc: etc headers inserted into the distributed-to-subscriber message and are thus not entirely lost if needed for some reason.

In the distributed message only the list's primary address is in the To: header and the VERP'ed list -response address in the From: header. This is done for two reasons:

  1. To focus all subsequent messages from both inside and outside the support group on the list address.
  2. To avoid exposing the VERP'ed -response addresses to people outside the list subscribers group, who may well be confused by them. That is why the Cc: and such are removed as it avoids the response from the list subscriber going direct to other addresses as well as the list -response alias if an MUA's "Reply All" GUI option is used.

If you disagree with this approach then you would have to change the file Mailman/Handlers/SupporListHack.py added by the patch.


This patch addresses the issues described above.


Versions of this patch are avaliable for Mailman version 2.1.6 and later.

Necessary Precursors

The following patch must first be applied:

  1. Mailman Patch #644797

Changes Made

This patch makes the changes to Mailman described above.

Applying the patch

Apply the patch from within the Mailman build directory using the command:

    patch -p1 < path-to-patch-file

Download Patch File

MM Version Download
2.1.12 Download
2.1.11 Download
2.1.10 Download
2.1.9 Download
2.1.8 Download
Uses the same patch as MM 2.1.7
2.1.7 Download
2.1.6 Download

Click to e-mail comments or complaints Last updated: 09/07/2009 13:24

[ OpenInfo Home ] [ UP ]