Mailman Patch #1442025: List Specialisation for Support Groups

Background

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:

• A company provides support to its customers.
• The company publishes an e-mail address - support@company.tld - and tells its customers to send support requests to that address.
• support@company.tld is in fact a Mailman mailing list and the staff in the company support team are the list's subscribers.
• When a customer needs support, they send a message to the list and this is distributed to the subscribers who have a protocol for deciding who will respond to the customer.

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:

• In the case of a simple reply, any continuing "conversation" between the poster and the company all to easily becomes a dialogue between the customer and a particular support engineer. This may be OK if the support team members all individually work 24/7 but potentially leads to poor response to customer follow-up messages. If support staff go on vacation, take sick leave, work part-time, quit their jobs, etc then delays in responding to customer follow-up requests are common.
• Customers are made aware of the identities of support staff members. This may be acceptable if the support team is composed of long term employees but is less so where temporary or part time staff are being employed.
• When a support team member responds to a customer posting they have to remember to send a copy of the message to the support list. If they fail to do so their colleagues may be unable to easily continue the "conversation" with the customer if the support person who fielded the initial customer posting is unavailable.

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:

• The customer should see the response from posting to the list as coming from the list.
• Any subsequent reply by the customer to a message from the list should go back to the list.
• Replies to customers by support staff should automatically be distributed to the the list.
• This should all happen by use of the basic features of typical MUAs by both list subscribers (support staff) and customers; the "Reply" button on the MUA GUI should do all that is necessary.
• Using the list in the way descibed should require no or minimal training for support staff and absolutely no explanation to customers.
• The e-mail addresses of support staff should remain hidden behind the list address.

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:
   • It first extracts the original poster's e-mail address from the VERP information in the incoming message's headers.
   • A copy of the incoming message - the response to the original post - is sent to to the poster's e-mail address with message's headers modified so that the message comes from the list's main alias with the list's -bounces alias as the sender. This is so that any subsequent reply from the original poster to this response will be directed to the list, not the list subscriber who responded.
   • If the To: and Cc: headers do not include the list's main alias itself then a copy of the response is injected into the list's Incoming queue so that all list subscribers get to see it and a copy can be archived if the list has archiving turned on. This should be the normal course of action but if a subscriber responds using the "Reply All" option on his MUA's GUI Mailman will receive two copies of the response: one addressed to the listname-response alias and the other to the listname alias to which the original post was sent.
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.

Description

This patch addresses the issues described above.

Applicability

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
2.1.11
2.1.10
2.1.9
2.1.8	Uses the same patch as MM 2.1.7
2.1.7
2.1.6