Mailman 3 January 2006 - Mailman-Developers

PHP Wrappers?
by Adrian Wells 17 Mar '06

17 Mar '06

Hello. How might one configure Mailman (version 2.1.6) list settings using PHP scripts? The goal is to configure Mailman list settings such as domain name of list, non-digest footer, set welcome/goodbye messages, etc. An approach that comes to mind is to use bin/config_list. This would require writing/reading files and using bin/config_list to process them. Is there another recommended or preferred way to accomplish this? There was a post about "PHP Wrappers" which suggested, "...just use a setuid mailman wrapper script that does caller-checking to see if it's called correctly, by the right user, and with 'safe' values" <http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>. This was recommended over simply adding the www user to the mailman group. I do not completely understand how one creates a setuid mailman wrapper script. Is this a matter of creating something similar to mail-wrapper.c? If someone has written a wrapper script or has some good resources further explaining this to share and is willing to do so, I would appreciate it. Thank you, -Adrian

16 64

XMLRPC Patch
by Joshua Ginsberg 13 Feb '06

13 Feb '06

I'm developing a patch to add an XMLRPC-based management interface to Mailman. Would this be something that you would be interested in trying to incorporate in the 2.1.x branch? Thanks! -jag -- Joshua Ginsberg <jag(a)fsf.org> Free Software Foundation - Senior Systems Administrator

5 14

Re: [Mailman-Developers] [Mailman-Users] any info on this reported exploit?
by Tokio Kikuchi 03 Feb '06

03 Feb '06

Tokio Kikuchi wrote: >> http://www.securityfocus.com/bid/16248/discuss >> GNU Mailman Large Date Data Denial Of Service Vulnerability >> GNU Mailman is prone to a denial of service attack. This issue affects >> the >> email date parsing functionality of Mailman. (snip) >> 06.3.18 CVE: CVE-2005-4153 (snip) > > Mailman-2.1.7 is not vulnerable to this issue. > We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe). https://sourceforge.net/tracker/?func=add&group_id=103&atid=300103 Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

3 10

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change toHandlers/SpamDetect.pyisincomplete
by Mark Sapiro 29 Jan '06

29 Jan '06

Dan Astoorian wrote: > >Personally, I'm of the opinion that it's wrong ever to use a reject rule >for spam filtering in the first place, since so much spam has forged >sender information anyway, but debating that is well beyond the scope of >how this bug should be fixed. I think we all agree that 'spam' should be discarded or maybe held for examination by a human, but never rejected. The problem I see is that while header_filter_rules are in the Spam filters section of the admin interface and enforced by a module named SpamDetect, they can actually be used in other ways to reject messages which are not 'spam' per se. >However, I agree with Mark that discarding instead of rejecting feels >wrong. > >Would checking the x-beenthere: headers to avoid the loop not be a far >cleaner solution, or is there some reason I've overlooked why that >wouldn't work? X-Been-There: won't work because it's never added in messages to -owner. Perhaps we could test if msg.get_sender() == mlist.GetOwnerEmail(), and discard in that case only, but I'd want a somewhat different test in case the sender's domain were not identical - something like if msg.get_sender().split('@')[0] == \ mlist.GetOwnerEmail().split('@')[0]: -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 2

Put admin_member_chunksize in GUI
by Mark Sapiro 29 Jan '06

29 Jan '06

Is there any reason to not put admin_member_chunksize in the GUI? It doesn't do the job requested in <http://sourceforge.net/tracker/index.php?func=detail&aid=782436&group_id=10…>, but it helps. Is there a fear that some unsuspecting list owner will set it too big? -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 2

Scrubber mungs quoted-printable revisited.
by Mark Sapiro 29 Jan '06

29 Jan '06

To refresh, see <http://mail.python.org/pipermail/mailman-developers/2005-November/018395.ht…> and <http://mail.python.org/pipermail/mailman-developers/2005-December/018449.ht…>. The problem with set_payload() creating a message for which a subsequent get_payload did 'too much' decoding was fixed by having Scrubber.py add a 'X-Mailman-Scrubbed: Yes' header upon doing a set_payload(), and then in various places where there are subsequent get_payload() calls, setting the decode flag according to the presence or absence of the header. I actually like the header as an explanation of content change along the lines of X-Content-Filtered-By:, but I've been uneasy about setting the get_payload() decode flag based on the presence or absence of 'X-Mailman-Scrubbed: Yes', although it seems to work in all cases we've tried. Recently, I looked in more detail at the actual set_payload() method in the email library and I have at least a vague understanding of the problem. The problem and my understanding are reported at <http://sourceforge.net/tracker/?func=detail&aid=1409455&group_id=5470&atid=…>. I have suggested a patch there which I call a 'Hint at possible fix'. This patch could be applied in Scrubber.py. The patch to Scrubber.py would add to the end of the def replace_payload_by_text(msg, text, charset): definition making the whole definition def replace_payload_by_text(msg, text, charset): # TK: This is a common function in replacing the attachment and the main # message by a text (scrubbing). Also, add a flag indicating it has been # scrubbed. del msg['content-type'] del msg['content-transfer-encoding'] msg.set_payload(text, charset) msg['X-Mailman-Scrubbed'] = 'Yes' if msg.get('content-transfer-encoding') == 'quoted-printable': cset = msg.get_charset() if cset: msg._payload = cset.body_encode(msg._payload) msg._charset = None The advantage to doing this in Scrubber.py and unconditionally setting the decode flag for subsequent get_payload() calls is it makes the whole process insensitive to whether or not or when Python email bug # 1409455 is fixed. If the bug is fixed, the payload will be encoded and msg.get_charset() above will return None so the payload won't be encoded a second time. The additional code above can be removed at some point after we're sure the email library used by Mailman is fixed. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change to Handlers/SpamDetect.py isincomplete
by Mark Sapiro 28 Jan '06

28 Jan '06

Dan Astoorian wrote: >On Fri, 27 Jan 2006 12:52:17 PST, Mark Sapiro writes: >> >> Definitely the message received by the user in this case is misleading, >> but the held message if approved will go to the owners/moderators >> only. I think Dan knows this. > >Actually, I didn't. I'm a co-moderator of a mailing list that I didn't >initially set up, so my experience with Mailman is fairly limited. I've >never previously encountered a held message that was to any mail path >other than the list itself, and had never had cause to find out whether >other types of mail ever got held up for approval. In my declaration >that "it is not clear to the end user...", I was the end user in >question :-) OK >(Perhaps the moderation queue web interface should indicate which queue >the held message is in? Currently the moderator has to infer this >information from the message headers.) Actually, as you implicitly point out, this isn't necessary since only list posts should be in the moderation queue in the first place. The only other messages that currently get held are messages to the owner that get caught by a Spam filter 'hold' rule, and these shouldn't be held. At least that's how it seems pending other input. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 5

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change to Handlers/SpamDetect.py isincomplete
by Mark Sapiro 27 Jan '06

27 Jan '06

Dan Astoorian posted to the bug tracker: >Specifically: it is (IMHO) probably incorrect to apply >the "Hold" action to messages which were not submitted >to the list address. For example, a message sent to >"listname-owner" and matched by a "Hold" >header_filter_rule should not be held for approval >(irrespective of whether the message was administrivia >or not). Good point. >(It is not clear to the end user whether approving such >a held message would cause the message to be delivered >to the original "listname-owner" address, or whether it >would be sent to the list itself.) Definitely the message received by the user in this case is misleading, but the held message if approved will go to the owners/moderators only. I think Dan knows this. >I suspect (but have not verified) that similar issues >may exist for other mail paths (e.g., -request, -admin, >-(un)subscribe). Unless you are seeing something I'm not, this is not the case. The issue is that SpamDetect.py is in both the GLOBAL_PIPELINE and the OWNER_PIPELINE, but messages to -request|join|leave|subscribe|unsubscribe|admin|bounces|confirm are not processed through SpamDetect.py and are never held for any reason. >Probably the most sensible thing to do with messages >that match a "Hold" rule would be to hold the message >only if the "tolist" key is set; otherwise, do one of >the following: >a) continue on to the next rule, as though the "Hold" >rule failed to match the message; >b) accept the message; or >c) discard the message. > >It's not clear to me which of these options makes the >most sense. Discarding the message is probably unwise, >as a "hold" rule in the first place suggests that the >administrator does not consider all mail that matches >the rule to be expendable. I think b) accept the message is the correct action since the 'hold rule' implies the owner/moderator wants to see the message and accepting the message sends it to the owners/moderators. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Sitewide headers/footers & XHTML Compliant Web UI
by Bryan Carbonnell 27 Jan '06

27 Jan '06

I have just uploaded a patch to Sourforge that allows you to set sitewide headers and footers for the Mailman 2.1.7 web UI, [ 1415956 ] Sitewide headers/footers & XHTML Compliant Web UI This patch was borne out of a request I received to make the Mailman UI fit the look of the web site. This patch allows you to set a site wide header and footer. This allows you to pretty much make the MM UI look like any other site. While I was at it I also made the web UI XHTML compliant. Once you patch your source and install it, all you need to do is edit the html files in the templates/en directory. Most of the pages will get the header and footers from the site-header.html and site-footer.html files, but some of the HTML files already contain theor own header/footer so you will need ot edit some of these files as well. Since this also adds XHTML compliance, this superceeds patch #116035 You can dowload it (and a separate version that works with the ht://dig integration patches) from: https://sourceforge.net/tracker/index.php?func=detail&aid=1415956&group_id=… You can see in use at http://databaseadvisors.com/mailman/listinfo -- Bryan Carbonnell - carbonnb(a)gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"

1 0

Re: [Mailman-Developers] Feature Request: message_id as replaceable token for footers etc.
by J C Lawrence 18 Jan '06

18 Jan '06

On Wed, 18 Jan 2006 17:00:52 +0100 Brad Knowles <brad(a)stop.mail-abuse.org> wrote: > At 12:01 AM -0800 2006-01-17, J C Lawrence wrote: >> Long time no talk. Whaddya think of adding message_id as a >> replaceable token for footers and the like? This would allow footers >> to be constructed which direct URL-reference their own post in an >> NNTP archive. > I like the concept, but the only problem is that message-ids are not > guaranteed unique. I'd like to see a guaranteed unique id be > generated on the system, and then have that used as the new > message-id, displayable in the footers, used as the index reference in > the mailing list archives, etc.... While true (the non-guarantee), in working across a quarter million messages in the archives of my various lists I've hit less than a score of duplicate or missing Message-IDs. That's a small enough problem that I'm willing to just eat the conflicts. -- J C Lawrence They said, "You have a blue guitar, ---------(*) You do not play things as they are." claw(a)kanga.nu The man replied, "Things as they are http://www.kanga.nu/~claw/ Are changed upon the blue guitar."

1 0