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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org