Mailman 3 February 2003 - Mailman-Developers

HTML in digests
by Haxial Feb. 11, 2003

Feb. 11, 2003

Hello Fantastic work on Mailman, love it! But I think I found a bug. When Mailman collects emails to put them into a digest, it doesn't properly handle multipart MIME emails that contain both HTML and plain text. This means that when someone uses MS Outlook or another email program that sends multipart HTML + plain text, all the HTML crap is included in the digest email, which makes reading the digest a real chore. When forming the digest, Mailman should strip out any HTML parts, and leave only the plain text parts. Here are the relevant lines from an example of an email that had multipart HTML and plain text: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2D148.1EA670B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

1 0

Solved! (Selective no archive message option)
by Jon Earle Feb. 10, 2003

Feb. 10, 2003

I've fixed my own problem. I noticed a syntax error in Handlers/Approve.py. I figured it was the msg.get syntax, so I copied the format from a few lines above. No luck. After seriously scratching my head for a while, I noticed that the indentation in python blocks was done with spaces. I'd used tabs. Changed tabs to spaces and voila! I now have a working feature! You can grab the patch if you like from: http://kronos.honk.org/~jearle/files/mailman-noarchive.patch It's built for v2.1, but applies (with a few offset hunks) against 2.1.1). What this does is allow you to approve a message that has been held for moderation (msg exceeds size limit for example) so it can be delivered, but preventing it from being archived if the noarchive checkbox is checked, thus saving disk space. Cheers! Jon --- Jon Earle SAVE FARSCAPE http://www.savefarscape.com/

2 1

Mailman 2.1.1 bugs
by J. Alden Gillespy Feb. 10, 2003

Feb. 10, 2003

My provider, Hostmatix.com, claims "The mailman version 2.1.1 is having some bugs as our admin has confirmed it. We are waiting for the developers to provide us with the debugged version.". Any idea as to 1) what this problem is, and 2) if and when it will be fixed? I am in need of the "ban list" feature in MM 2.1.1, but these bugs that Hostmatix is having are hindering my list's functionality. J. Alden Gillespy (aka Dogga) Microsoft Beta Tester: - Office 11 - Content Management Server (CMS) 2002 - Systems Management Server (SMS) 2003

1 0

by Marilyn Davis Feb. 10, 2003

Feb. 10, 2003

nomail on asdfjkl;

2 2

Puzzled; Selective no-archive patch.
by Jon Earle Feb. 9, 2003

Feb. 9, 2003

Working on a patch to MM 2.1 (easily patches 2.1.1 too), that will selectively not archive messages but am having trouble getting them to not go into the archive. Link to patch is here: http://kronos.honk.org/~jearle/files/noarchive.patch Essentially, I run a list where the members like to email pics and other funnies to each other. This is fine with me, but I'd rather they not go into the archive for obvious reasons. I made a change to the moderation screen to add a checkbox to not archive the particular message, or in the message list screen, to not archive all of them. Obviously, the approval of the moderator would be required to make the noarchive option work. I think I've got the various pieces in place in the admin screen, and I have the message metadata including a 'noarchive' entry. I then theorized that my next step would be to fiddle with Handlers/ToArchive.py (part of the qrunner?). I thought that by adding a check for the 'noarchive' entry in msgdata nr the top of the process method would do the trick, but no. Did a slight mod to Approve.py and still no luck. Not sure what do now and would appreciate any advice given. I've worked with C for a few years, learned Perl last Nov and this is my first foray into Python. Cheers! Jon --- Jon Earle SAVE FARSCAPE http://www.savefarscape.com/

1 0

RELEASED Mailman 2.1.1
by barry＠python.org Feb. 9, 2003

Feb. 9, 2003

I've released Mailman 2.1.1 which includes many bug fixes and language updates. This release includes a fix for the cross-site scripting vulnerability, a fix for the cookie problem, any many other bugs. I recommend that all Mailman 2.1 users upgrade to this release. As usual, I've made both a full source tarball and a patch file available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=97760 Note that applying the patch does /not/ completely update the language support. If you go the patch route, you will want to cd into the messages directory and run "make catalogs" before installing. This will only work if your OS has the necessary language tools installed. You don't need to do this if your lists are all English-only. If you have a problem, please download and install the full release. It is safe to install this over version 2.1. You can simply run configure the way you did for 2.1, then do a make install. Be sure you restart your mailman daemon by doing a "mailmanctl restart" after installing. See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.1 (08-Feb-2003) Lots of bug fixes and language updates. Also: - Closed a cross-site scripting vulnerability in the user options page. - Restore the ability to control which headers show up in messages included in plaintext and MIME digests. See the variables PLAIN_DIGEST_KEEP_HEADERS and MIME_DIGEST_KEEP_HEADERS in Defaults.py. - Messages included in the plaintext digests are now sent through the scrubber to remove (and archive) attachments. Otherwise, attachments would screw up plaintext digests. MIME digests include the attachments inline.

3 4

error at make install
by Giorgos Sakalis Feb. 8, 2003

Feb. 8, 2003

I am trying to instal mailman 2.1 on an SGI O2. When I execute make install i get this error Creating language directory /usr/local/mailman/sv mkdir /usr/local/mailman/sv Cannot create directory "/usr/local/mailman/messages/de": File exists Cannot create /usr/local/mailman/messages/de/#inst.170827# - Not a directory *** Error code 2 (bu21) *** Error code 1 (bu21) Any ideas?

1 0

Re: [Mailman-Developers] Patching question
by Richard Barrett Feb. 8, 2003

Feb. 8, 2003

At 18:21 07/02/2003, Marilyn Davis wrote: >Hi Mailmen and Mailwomen, > >If I fix up a patch for 2.1 so that eVote works with it, some >administrators will want it and some won't. > >What happens when new Mailman patches come along for 2.1+? Will >I have to make a new patch for each patch? > >Please forgive my ignorance. > >Marilyn I have some enhancement patches for MM that have yet to be adopted for inclusion in the main development line; may never be. If it will help I'll describe how I've been doing things although the real Mailman developers may have a different take on things Thus far I have maintained my patches as follows: 1. When a new numbered or beta release of MM comes out I try applying my patches for the previous numbered release. 2. If it applies without complaint and tests out as working I just add a comment to the sourceforge page for the patch telling people that patch file name abc works with MM version x.y.z 3, If the patch will not apply without complaint or it fails my testing I fix things and generate a new version of the patch. I then upload the revised patch + a comment to the sourceforge page for the patch. Fixing things can include creating a whole new precursor patch if it is to correct a bug in the Mailman numbered release code that I've just tripped over rather than a defect in the code my patch adds. I normally generate the patches by doing a recursive diff between a directory structure of either the vanilla MM release or that + any necessary precursor patches applied, and the directory structure of the MM release plus my changes. I guess I could use RCS/CVS branches for some of this but thus far I haven't got my head round solving the problem that way. My current worst case is a patch #444884 which requires three precursor patches. #444879 which is an enhancement patch and #668685, which fixes a new bug that appeared in MM 2.1. Patch #44879 in turn depends on patch #661138 which fixes different issues that also appeared in MM 2.1 final. The patch generation sequence goes like this: diff -r -u -P mailman-2.1/ mailman-2.1-driver/ > driver-2.1-0.1.patch diff -r -u -P mailman-2.1/ mailman-2.1-tfix/ > templates-2.1-0.1.patch diff -r -u -P mailman-2.1-tfix/ mailman-2.1-index/ > indexing-2.1-0.1.patch diff -r -u -P mailman-2.1-index/ mailman-2.1-htdig/ > htdig-2.1-0.3.patch and the patch application sequence goes like this: zcat distributions/mailman-2.1.tgz | tar xf - mv mailman-2.1 mailman-2.1-run cd mailman-2.1-run/ patch -p1 < ../patches/current/driver-2.1-0.1.patch patch -p1 < ../patches/current/templates-2.1-0.1.patch patch -p1 < ../patches/current/indexing-2.1-0.1.patch patch -p1 < ../patches/current/htdig-2.1-0.3.patch The reason I've done things this way is I want to separate patches that add discrete chunks of enhancement from fixes to generic problems I've identified in baseline MM while developing the enhancements. This way I'm in with a shout of persuading Barry Warsaw to add the bug fixes to the Mailman CVS at some point, even if he won't accept the enhancements so readily. Hopefully, and over time, my patches to fix MM bugs go away even if I'm left with the maintenance of the enhancement patch(es). That's better than polluting my enhancement patches with general bug fix stuff and then having to rip that out if its fixed in a new numbered release. In the case of the example, I split my original work into a fairly generic patch #444879 and a more specialised one #444884. Again this was with the hope that the more generic patch had a better chance of making it into the CVS ahead of the more specialised stuff. I do not even attempt to publish patches for MM CVS; its too much like trying to shoot skeet with a rifle. As far as I'm concerned the sort of adventurous people that run from the CVS have to make do with patches for the most recent numbered (or beta) release and do their own manual fixing of rejected patch elements After fumbling around at the start, I adopted a patch file naming convention (see example) where the first number group is the version of Mailman the patch applies to and the second number group is the evolution/version number of the patch applicable to that MM version; adrift in sourceforge's repository is htdig-2.0.8-0.1.patch and htdig-2.0.13-0.4.patch, as well as the most recent htdig-2.1-0.3.patch. Its a bit of a chore maintaining patches for MM across new releases but I do it because I need the changes for my own use and the discipline of having to keep up to date and publish for other users is good for my soul. In practice it means I can build my MM server systems from cold almost automatically to the patch state I want them to run at (the patch application lines above come out of the script that does this). I've been trying to get out revised patches after just a few days of a new numbered or beta release hitting the stree, but not always with success. I do not know of any way of avoiding conflicts with other patches that people might want to apply to same version of MM as my patches. I make it clear if my patches have necessary precursors and aim for no problems/warnings when running the patch command. I take the view that if people are mixing and matching a lot of different patches and this leads to patch command warnings or errors, then the person concerned has to contribute to their own salvation; although I'm willing to advise or help. How big a problem this is depends on how pervasive your changes are; so far I seem to have been fairly lucky on this score. Sorry to rattle on at such length when you probably have all of this scoped out. Still, if its saves you some work along the way ... I had put your post to mailman-users to one side as a reminder to investigate eVote further. If the MM 2.1 version is likely to be available in the near future, it will suit me better than having to regress my test system to MM 2.0.13 in order to try out eVote. Best of luck.

1 0

[Mailman-Developers] qmail-to-mailman.py broken when using --with-var-prefix
by Matthias Juchem Feb. 7, 2003

Feb. 7, 2003

Hi. I have just added a tested patch (against 2.1.0) to the SF Mailman project. Problem: When using --with-var-prefix with configure, contrib/qmail-to-mailman.py gets broken because it does not know about the concept of a second directory. Fix: Instroduce new variable for var-prefix directory. There are 2 attachment. The older one is wrong, but I couldn't delete it. Regards, Matthias

1 0

Messages going through as attachments
by David Gibbs Feb. 7, 2003

Feb. 7, 2003

I recently updated to the latest CVS (based on Tokio Kikuchi's advice) to fix some digest issues ... most things are working fine, but some messages are coming through as attachments instead of plain text. Any ideas why this would be? Thanks! david

1 0