Mailman 3 July 2002 - Mailman-Developers

Some issues with the CVS head
by Ross Boylan 30 Jul '02

30 Jul '02

I just got the latest Mailman sources from CVS, and noticed a couple of things. 1) Required Python Version Some of the modules (e.g., DNS.py) require Python 2.2 (e.g., reference to email modules). Yet the readme says Python 2.1.3 or greater is required. The wiki http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage says Python 2.0 will be required. This is of particular concern for me because I'm thinking of borrowing some parts for a Zope product, and Zope 2.5 uses Python 2.1 and reportedly will not work with 2.2. This is, of course, not a good reason for Mailman to stay on Python 2.1. I'm aware of the ZMailman project and sent a message to their list. However, what I'm doing probably goes in a different direction (I really just want the Bounce handling). 2) Code Inconsistencies Bouncer uses getBounceInfo. MemberAdaptor implements this (as well as OldMemberAdaptor), but MailingList doesn't inherit from it. So it looks as if everything is not quite hooked up yet. 3) A Stylistic Comment I also find it a little weird to see base classes making calls to methods that they don't define or inherit from, on the assumption that they will be mixed into something that does define them. It seems to me if this could be avoided, or at least if the classes could inherit from the classes with the relevant protocols, it would be cleaner. A lower tech approach would be to note the dependencies in class comments. But I think the inheritance might make the dependencies explicit while still preserving the ability to factor out chunks of functionality. 4) A Little Python Question Could anyone explain to me what this is doing? (e.g. from DNS.py) return filter(None, addrs) There are several uses of this filter(None,..) idiom in the code. The 2.0 code even says return filter(None, addrs) or None The docs for filter say the first argument should be a function, which None is not. When I try it, it seems to be a noop (i.e., filter(None, foo) == foo). And or'ing with None (false) also seems pointless.

2 1

Re: [Mailman-Developers] Cute TMDA use
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 16:48:30 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On 7/29/02 4:31 PM, "Barry A. Warsaw" <barry(a)python.org> wrote: >> I guess if the default moderation bit is set, then we wouldn't send >> out the confirmation message, and non-member postings would have to >> be approved just like they are today. > I would set things up so that they don't go into the moderation queue > until they're confirmed, and then moderated as normal. The moderator > stuff doesn't change, except that the moderator doesn't see them until > the user confirms them. That closes the hole of the moderator having > to deal with spam to the posting address. So basically, you put TMDA > in front of the moderator, not replace the moderator in that case. The > list is still moderated, just whitelisted THEN moderated. Precisely. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Make clobber_date default and configurable
by Krischan Jodies 30 Jul '02

30 Jul '02

The default for clobber_date is "set time in archive to time of the date header of e-mail". I think the better default is to set the time to the resent time. At least this default should be configurable in mm_conf.py. Thanks, Krischan -- Service Network GmbH, mailto:kjodies@SerNet.DE, http://www.SerNet.DE phone: +49-551-370000-0, fax: +49-551-370000-9

2 1

[ mailman-Patches-564747 ] Makes "powered by" icons into links
by noreply＠sourceforge.net 30 Jul '02

30 Jul '02

Patches item #564747, was opened at 2002-06-05 03:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=564747&group_i… Category: Web UI Group: Mailman 2.0.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: W Isaac Carroll (zaak) Assigned to: Nobody/Anonymous (nobody) >Summary: Makes "powered by" icons into links Initial Comment: This makes the Mailman, Python, and GNU icons at the bottom of the web UI pages into links to their respective web sites. There are already links if mm_cfg.IMAGE_LOGOS is false. This patch simply makes the graphical version have the links as well. Patch against version 2.0.9 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 18:29 Message: Logged In: YES user_id=12800 I'm rejecting this patch (actually without looking at the details -- sorry), because we've had too many complaints about these logos being hyperlinked. I'm actually disabling the links altogether. The problem is that the GNU, Python, and Mailman folks get way too many unrelated requests for unsubscription or other membership issues, just because frustrated people will click on anything to get their issue resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=564747&group_i…

1 0

[ mailman-Bugs-588222 ] Downgrade detected on 2.0.13 "upgrade"?
by noreply＠sourceforge.net 29 Jul '02

29 Jul '02

Bugs item #588222, was opened at 2002-07-29 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_i… Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) >Summary: Downgrade detected on 2.0.13 "upgrade"? Initial Comment: I am running Red Hat 7.3, Python 1.5.2, and Mailman 2.1b2. When I try to install Mailman 2.0.13 the ./configure works, however on the make install it begins working then errors out: Downgrade detected, from version 0x20100b2 to version 0x2000df0 This is probably not safe. Exiting. Now that it has done this I am unable to start Mailman up. Another person working on the system may have upgraded to Python 2.2 however, according to Barry Warsaw, newer versions of python should work just fine. Thanks for the help. Paul Marshall ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 16:52 Message: Logged In: YES user_id=12800 Um, Mailman 2.1b2 is "newer" than Mailman 2.0.13 so this is indeed a downgrade. The patch has no relevance to Mailman 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_i…

1 0

[ mailman-Bugs-588222 ] Downgrade detected on 2.0.13 "upgrade"?
by noreply＠sourceforge.net 29 Jul '02

29 Jul '02

Bugs item #588222, was opened at 2002-07-29 14:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: Downgrade detected on 2.0.13 "upgrade"? Initial Comment: I am running Red Hat 7.3, Python 1.5.2, and Mailman 2.1b2. When I try to install Mailman 2.0.13 the ./configure works, however on the make install it begins working then errors out: Downgrade detected, from version 0x20100b2 to version 0x2000df0 This is probably not safe. Exiting. Now that it has done this I am unable to start Mailman up. Another person working on the system may have upgraded to Python 2.2 however, according to Barry Warsaw, newer versions of python should work just fine. Thanks for the help. Paul Marshall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_i…

1 0

Re: [Mailman-Developers] Re: Cute TMDA use
by J C Lawrence 29 Jul '02

29 Jul '02

<<tmda-users added to distribution list as this is probably of more interest/topicality there>> On Mon, 29 Jul 2002 10:51:46 -0600 Jason R Mastaler <Jason> wrote: > J C Lawrence <claw(a)kanga.nu> writes: >> There are cases where I don't want this however, and its proving >> rather a bitch to make a non-shared whitelist hang off a shared >> configuration (in my case a shared procmail RC). > I haven't found this to be the case at all, but I'm also driving my > setup with dot-qmail files which makes this sort of thing trivial. I can't comment well in reaction to QMail as I don't and haven't used it. However I suspect that it doesn't solve the problem I'm referencing, as its not MTa based or specific. I have the MTA (currently Exim and Postfix) configured to deliver all Mailman-related messages sent to the system (-owner, -admin, -request, and list posts) to a singe procmail filter (obviously, shared among all lists and aliases). I'm using procmail as I'm also doing MIME filtering and other pre-processing of messages before handing them to TMDA or the MLM. To goal is arrive at a configuration where no maintenance or extra/unusual actions are required; of alias files, dot files, TMDA configs, TMDA filters, etc as lists are added and removed from the system, or for the normal running and operation of a list. On the TMDA side what I'd like to arrive at a configuration where: -- blacklists are shared -- each list has an auto-whitelist which is private to that list -- each list authenticates messages sent to it against the appropriate Mailman config.db. -- In validating a message for a given list no files or sources other than the shared blacklist, the private whitelist, and the list-specific roster are checked. Essentially this means a fully private TMDA filter setup for each list (modulo the blacklist, but I'm willing to compromise on that). Choice of TMDA incoming filter can be selected at runtime (argument to tmda-incoming) but I can't compute the contents of the incoming filter at runtime in any regard. Filter rules are single qualifier only. Filter files don't have internal variable replacement logic so that they can rewrite themselves depending on the Sender or similar (thus effectively providing multiple qualifier logic). The base result of these configuration constraints is that I have to write a custom incoming filter for each list, pointing at the appropriate private auto-whitelist, Mailman config etc, each filter identical to every other except for the internal list name references. I'd rather have a single self-adapting incoming filter. What I'd really like is to be able to conditionally nest TMDA filters ala: # Generic access controls from-file ~list/.tmda/lists/blacklist bounce from-file ~list/.tmda/lists/whitelist ok # Custom list specific filters (includes file if exists) #include-if "~list/.tmda/filters/${LISTNAME}" # Generic list-specific filters from-file ~list/.tmda/lists/whitelist.${LISTNAME}.auto ok from-mailman -attr=members ~list/lists/${LISTNAME} ok from-mailman -attr=digest_members ~list/lists/${LISTNAME} ok from ${LISTNAME}-admin(a)kanga.nu ok from ${LISTNAME}-owner(a)kanga.nu ok That way if I should want to add extra constraints, authentication sources, behaviours etc to a given list I can, just by dropping a file in the filters directory. Currently I'm hacking my way around this by having a wrapper shell script which assembles a PID-specific incoming filter in /tmp, calls tmda-filter against it, and then deletes it afterward in cleanup. Ugly, expensive, hackish, but works. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

RELEASED Mailman 2.0.13
by barry＠zope.com 29 Jul '02

29 Jul '02

I've released Mailman 2.0.13 which fixes some incompatibilties with Python 1.5.2 that crept into Mailman 2.0.12. This also fixes a minor configure incompatibility on Solaris platforms (and possibly others). If you're using Python 1.5.2 with Mailman 2.0.12 you should definitely upgrade. The upgrade is safe if you're using newer Python versions too. See the NEWS file excerpt below. As usual, I've made both full source tarballs and patches available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarball. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=97760 See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.0.13 (29-Jul-2002) - Fixed some Python 1.5.2 compatibility problems that crept into Mailman 2.0.12. - Fixed some configure script incompatibilities on certain platforms.

1 0

TypeError: list objects are unhashable
by Romek Krisztián 29 Jul '02

29 Jul '02

Hello! I use Python 2.2 and Mailman 2.0.12. I was using my copy of Mailman when I've experienced the following error: Jul 29 18:49:01 2002 qrunner(3629): Traceback (most recent call last): Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/Archiver.py", line 221, in ArchiveMail Jul 29 18:49:01 2002 qrunner(3629): h.processUnixMailbox(f, HyperArch.Article) Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/pipermail.py", line 528, in processUnixMailbox Jul 29 18:49:01 2002 qrunner(3629): self.add_article(a) Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/HyperArch.py", line 917, in add_article Jul 29 18:49:01 2002 qrunner(3629): self._charsets[cs] = self._charsets.get(cs, 0) + 1 Jul 29 18:49:01 2002 qrunner(3629): TypeError: list objects are unhashable Jul 29 18:49:01 2002 (3629) CORRUPT ARCHIVE FOR LIST: listname This was when I sent my message to the list. After that I searched on Google about this problem. Somebody told to delete the pipermail.pck file in the archives directory. Okey, deleted. Next: my message was sent to everybody subscribed to the list, but I didn't find it in the archive list but one html file with numbers in the filename. Can you tell me something about what i am doing wrong and how can i fix this error? Krisztian Romek

1 0

[ mailman-Patches-585643 ] Mailman 2.0.13 candidate patch
by noreply＠sourceforge.net 29 Jul '02

29 Jul '02

Patches item #585643, was opened at 2002-07-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_i… Category: None Group: Mailman 2.0.x >Status: Closed >Resolution: Accepted Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman 2.0.13 candidate patch Initial Comment: Mailman 2.0.12 had compatibility problems with Python 1.5.2. This patch fixes these AFAICT, and a few other small bugs that have cropped up. Note that this is a candidate patch. The actual MM2.0.13 patch may be different. However I would really appreciate folks using Mailman 2.0.12 (especially if you're using Python 1.5.2) to give this patch a try and see if it fixes your problems. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 12:17 Message: Logged In: YES user_id=12800 I'm releasing MM2.0.13 today. It will be slightly different than this patch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-25 12:00 Message: Logged In: NO This fixed the problems I'd been having on my Solaris 8 box running Mailman 2.0.12 and Python 1.52. Thanks much. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_i…

1 0