[Mailman-Users] Changes to CookHeaders.py stop working forSOMElists!?

Mark Sapiro mark at msapiro.net
Tue Dec 6 21:47:32 CET 2011


Drew Tenenholz wrote:

>At 7:36 PM -0800 12/5/11, Mark Sapiro wrote:
>>Is either include_rfc2369_headers or include_list_post_header set to No
>>for the affected lists (those that don't apply the header)?
>
>Yes, include_rfc2369_headers=No on the affected lists and not on the others.


So your change to CookHeaders is in the section following the lines

    if msgdata.get('_nolist') or not mlist.include_rfc2369_headers:
        return

If you don't want it conditional on this setting, put it ahead of those
lines.


Oddly enough, I remember doing this, because I was getting complaints
about users with mobile devices like Blackberries complaining that the
actual email ends up hidden below the headers and they have to do a
lot of scrolling to get to the message.  I moved all of the same
information to the footer, so we are sort of compliant to the RFC
while making the message more easily read.  (Also, the MTA on another
server is running a tumbleweed spam/virus filter that tacks on an
ocean of its own headers as well; I have no control over this....)
>
>Knowing this, however, may give me something I've wanted for a while; a way to include the custom header on the 'public' lists that send messages to the broad subscriber base and not include them on 'internal' messages that are only sent between a small group of folks putting together the final content for the public list.


Or maybe you like this 'conditional' feature :)


>Mark Sapiro wrote:
>>yum probably 'upgraded' Mailman.
>
>Maybe that's possible with a Linux (Red Hat Enterprise Linux) update run by some other sysadmin.  The version number displayed on the Mailman admin pages still says 2.1.9, is there a simple way to get the full release number or 'upgrade' date?  (I was previously told the version was 2.1.9 release 6.el5.)


That's the latest latest RHEL/Centos 5 Mailman RPM, aks 2.1.9-6.el5_6.1.

yum list mailman

will give this info.

Try

grep mailman /var/log/yum.log*

to see when Mailman was last updated by yum.


>Mark Sapiro wrote:
>>Do you mean /usr/lib/mailman/bin/mailmanctl restart?
>
>Yes, that's what I get for typing from memory...
>
>So, the /bin/mailmanctl restart only restarts the qrunners, but that is enough to enact any changes to CookHeaders.py, correct?


When you make a change to CookHeaders.py, that change is effective for
anything that imports that module from then forward. The issue is
IncomingRunner and VirginRunner already imported that module the first
time they handled a message, and they won't reload it and get the
updated module unless you restart them. Since mailmanctl and the
qrunners are the only persistent Mailman processes, and since
mailmanctl is not involved in processing messages, it is generally
only necessary to restart the qrunners after making code changes that
affect message processing.

There are a couple of mm_cfg.py settings such as those that affect
qrunner slicing, the Mailman user and group and paths to the Mailman
installation and Python interpreter that would require actually
stopping and starting Mailman, but outside of that, changes require at
most a restart to be effective.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan



More information about the Mailman-Users mailing list