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:
The changes made to Mailman by this patch to support the desired style of list operation are as follows:
response" is defined to accepts posts to the
listname-responsealias which inserts posts into:
qfiles/response- which is used to accept messages sent to
ResponseRunner- is used to process incoming message inserted into the
qfiles/responsequeue: see (7) below for more explanation of its operation.
listname-responsealias of the list. This is so that any subsequent response to the posting by a list subscriber will be directed back to the
listname-responsealias. To retain information about who the original poster was, the headers are actually rewritten to a VERP'ed
listname-responseaddress with the original poster's e-mail address in the VERP information.
listname-responsealias and thence into the
ResponseRunnerintroduced in (4) above processes incoming messages sent to the
listname-responsealias as follows:
Cc:headers do not include the list's main alias itself then a copy of the response is injected into the list's
Incomingqueue 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-responsealias and the other to the listname alias to which the original post was sent.
IncomingRunnerwhich 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.infile and the
mailmandelivery wrapper modified to know of the additional incoming mail script called "
listname-responsealias. If existing lists are to be configured via the web admin GUI to be closed subscription support lists as described above then
bin/genaliaseswill need to be run to generate the extra
-responsealias for all lists.
-responsealias 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
-responsealias 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.
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
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-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:
-responseaddresses 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
-responsealias 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.
The following patch must first be applied:
This patch makes the changes to Mailman described above.
Apply the patch from within the Mailman build directory using the command:
patch -p1 < path-to-patch-file
|Click to e-mail comments or complaints||Last updated: 09/07/2009 13:24|