Mailman 3 December 2001 - Mailman-Developers

"stable" release / 2.1 release status
by Matthias Klose 01 Jan '02

01 Jan '02

Reading the web pages: MM21/index.html: Version (2.1a2, released on 11-Jul-2001) is the current stable GNU release. download.html: Version (2.0.6, released on Jul 25 2001) is the current GNU release. Correct to name 2.1a2 a stable release? Somewhere on the lists Barry Warsaw didn't give a garanty for a smooth upgrade path between the alpha releases. Or is 2.1 on the horizon, so that it's more work to change the web page ;-) Matthias

3 2

[Fwd: Bug in Bounce.py]
by Dan Mick 31 Dec '01

31 Dec '01

Sent this to Barry late last night, but haven't seen a fix or a note here, so: in case anyone else is having the same problem:

2 1

decoding bug of non-ascii MIME encoded subject
by Reed Lai 30 Dec '01

30 Dec '01

Pipermail 0.05 (Mailman edition) does not seem to decode non-ascii MIME subject correctly under some conditions, even the "Prefix for subject line of list postings" has been emptied. Attached ma1 files are captured before ma2 files. The messages sent by Reed Lai are subjected with iso-8859-1 encoding for big5 characters. The messages sent by SunnyCat are subjected with big5 encoding for big5 characters. The decoding seems to be determined by last message. -- Reed Lai (key #1) <reed(a)icpdas.com> http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. <service(a)icpdas.com> http://www.icpdas.com/

1 0

[<amaya@amaya.homeip.net>] Bug#125858: mailman: newlist command line
by Tollef Fog Heen 29 Dec '01

29 Dec '01

What do people think? Just adding a comma or something between the email addresses does not seem to work (because of ValidateEmail). Or is this fixed in a better way in 2.1? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.

1 0

Re: [Mailman-Developers] ADMINDB_PAGE_TEXT_LIMIT = -1 does not work
by Dan Mick 28 Dec '01

28 Dec '01

> putting ADMINDB_PAGE_TEXT_LIMIT = -1 in mm_cfg.py to view all the > message to be approved, seems to not work properly. ...in 2.1 CVS. Yup, seems to be the case. I've filed a bug with a fix that works for me (to be made much more elegant by Barry :)

2 1

http://www.list.org/MM21/install-final.html
by donal.hunt2＠mail.dcu.ie 27 Dec '01

27 Dec '01

Just though i'ld point out that the info on http://www.list.org/MM21/install-final.html is outdated and needs to be changed so that it's inline with the INSTALL file from the tar.gz distribution. ie a mailman list needs to be created instead of the method used in Mailman 2.0.x and before... Regards Donal

1 0

Illegal command: mailcmd
by Roberto Bagnara 26 Dec '01

26 Dec '01

Hi there, we are experimenting with Mailman 2.1 (we absolutely need the Italian version) and we have problems with email confirmation of subscriptions. Here is the kind of message people trying to confirm receive in response: > Date: Wed, 12 Dec 2001 13:19:44 +0100 > From: Mail Delivery Subsystem <MAILER-DAEMON(a)studenti.cs.unipr.it> > To: pescetti(a)math.unipr.it > Subject: Returned mail: see transcript for details > > The original message was received at Wed, 12 Dec 2001 13:19:44 +0100 > from prmat.math.unipr.it [160.78.64.1] > > ----- The following addresses had permanent fatal errors ----- > "|/home/mailman/mail/wrapper mailcmd comunicazioni-ufficiali" > (reason: 6) > (expanded from: <comunicazioni-ufficiali-request(a)studenti.cs.unipr.it>) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Does this mean that "mailcmd" should be added to the array initializer starting at line 35 in src/mail-wrapper.c, now reading const char *VALID_COMMANDS[] = { "bounces", "join", "leave", "post", "owner", "request", NULL /* Sentinel, don't remove */ }; Or "mailcmd" is indeed an illegal command and the culprit is somewhere else? Thanks a lot, and keep up the great work. Roberto -- Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 1

Getting Mailman and Postfix to play nice in virtual domains
by barry＠zope.com 26 Dec '01

26 Dec '01

I've been playing around with support for virtual domains in Mailman, trying to make them play nice with Postfix. For the record, I'm using Postfix 20010228-pl08 on a RH6.1-ish Linux box. I'm using the latest Mailman 2.1 alpha cvs snapshots. I'm not sure I understand how Postfix expands addresses in virtual tables, so let me explain how things are currently set up. Let's say I have two domains that I want my Postfix to answer to dom1.ain and dom2.ain. I am going to have mailing lists and plain users in both domains. In my main.cf file I have myhostname = mail.dom1.ain mydomain = dom1.ain myorigin = $myhostname alias_maps = ..., hash:/usr/local/mailman/data/aliases virtual_maps = ..., hash:/usr/local/etc/postfix/virtual-dom1, hash:/usr/local/etc/postfix/virtual-dom2, hash:/usr/local/mailman/data/virtual-mailman In virtual-dom1 I have dom1.ain IGNORE @dom1.ain @mail.dom1.ain and in virtual-dom2 I have dom2.ain IGNORE # lots of addresses which are only visible in dom2.ain... Note that the two files /usr/local/mailman/data/* are written by Mailman when a mailing list is created or deleted, and they must be set up a priori with the proper permissions (i.e. must be owned by `mailman') so that the mail programs they refer to will get executed with the proper uid. In /usr/local/mailman/data/aliases{,.db} I'll have entries such as: list1: "|/usr/local/mailman/mail/mailman post list1" list1-admin: "|/usr/local/mailman/mail/mailman bounces list1 list1-bounces: "|/usr/local/mailman/mail/mailman bounces list1" list1-join: "|/usr/local/mailman/mail/mailman join list1" list1-leave: "|/usr/local/mailman/mail/mailman leave list1" list1-owner: "|/usr/local/mailman/mail/mailman owner list1" list1-request: "|/usr/local/mailman/mail/mailman request list1" list2: "|/usr/local/mailman/mail/mailman post list2" list2-admin: "|/usr/local/mailman/mail/mailman bounces list2 list2-bounces: "|/usr/local/mailman/mail/mailman bounces list2" list2-join: "|/usr/local/mailman/mail/mailman join list2" list2-leave: "|/usr/local/mailman/mail/mailman leave list2" list2-owner: "|/usr/local/mailman/mail/mailman owner list2" list2-request: "|/usr/local/mailman/mail/mailman request list2" and in /usr/local/mailman/data/virtual-mailman{,.db} I'll have entries such as list1(a)dom1.ain list1 list1-admin(a)dom1.ain list1-admin list1-bounces(a)dom1.ain list1-bounces list1-join(a)dom1.ain list1-join list1-leave(a)dom1.ain list1-leave list1-owner(a)dom1.ain list1-owner list1-request(a)dom1.ain list1-request list2(a)dom2.ain list2 list2-admin(a)dom2.ain list2-admin list2-bounces(a)dom2.ain list2-bounces list2-join(a)dom2.ain list2-join list2-leave(a)dom2.ain list2-leave list2-owner(a)dom2.ain list2-owner list2-request(a)dom2.ain list2-request That is, list1 should only be visible in dom1.ain and list2 should only be visible in dom2.ain. Note that these are all Postfix-style virtual domains. With the current setup, I must set myorigin to mail.dom1.ain and not dom1.ain, otherwise mail to list1(a)dom1.ain will bounce with an "unknown user". I believe the reason for this is because unqualified bare names on the right-hand side of a virtual map entry will get $myorigin appended to them. Further, I believe that Postfix's recursive expansion rules state that if the right hand side is the same as the left hand side, expansion stops. So, when a message is received for list1(a)dom1.ain, this gets expanded to list1+$myorigin, and if $myorigin is dom1.ain, then Postfix stops and tries to deliver to list1(a)dom1.ain. Postfix ignores the @dom1.ain -> @mail.dom1.ain mapping in the virtual-dom1 file because (I believe) this is a more general mapping and the more specific mapping trumps. So Postfix doesn't know where to deliver list1(a)dom1.ain and so it bounces it. However, if $myorigin is mail.dom1.ain, then list1(a)dom1.ain expands to list1(a)mail.dom1.ain, and because this is the default $mydestination, Postfix stops, consults its local aliases table, and successfully delivers the message to the intended program. Delivery to list2 works for by $myorigin = dom1.ain and $myorigin = mail.dom1.ain, and breaks down like so. When $myorigin = dom1.ain, mail comes in addressed to list2(a)dom2.ain, which expands to list2(a)dom1.ain. Postfix continues expansion of this address, sees the mapping from dom1.ain -> mail.dom1.ain in virtual-dom1, and expands this to list2(a)mail.dom1.ain. Then it sees the default $mydestination after the @y, looks this up in the alias table, and delivers it to the intended program. When $myorigin = mail.dom1.ain, it also works, simply shortcircuiting one level of expansion. I.e. list2(a)dom2.ain -> list2(a)mail.dom1.ain directly. To sum up, here are my questions: 1. When a "bare" address appears on the right hand side of a virtual table entry, is it true that $myorigin gets appended during the address expansion phase? 2. If not, how does Postfix actually deal with a bare address on the right hand side of a virtual table entry? 3. Is it correct that if list1(a)dom1.ain expands to list1+$myorigin in a virtual map, and $myorigin = dom1.ain, expansion will stop here without seeing the mapping of dom1.ain -> mail.dom1.ain in the virtual-dom1 map? And thus delivery will fail? Apologies for such a long ramble, but I really want Mailman and Postfix to play nicely w.r.t. virtual domains. It would be more difficult to hack Mailman to include the fully qualified expansion on the right hand side of its virtual table, e.g. list2(a)dom2.ain list2(a)mail.dom1.ain but I may have to do this. I'd like to better understand exactly what Postfix is doing though before I propose a solution for Mailman, so part of the purpose of this email is as a sanity check. Aside: all this is further complicated by the fact that to use hash: tables, the version of BerkeleyDB that Postfix is linked against must match the version that Python is linked against, otherwise Mailman may write hash tables that Postfix can't read. It doesn't help that I think BerkeleyDB support in Python 2.2 is broken. :( All this is starting to feel too complicated and error prone so I might have to punt and try a different approach. Thanks, -Barry

1 0

Re: [Mailman-Developers] ~mailman/bin/mailmanctl -s start
by J C Lawrence 26 Dec '01

26 Dec '01

On Wed, 26 Dec 2001 10:51:11 +0100 fil <fil(a)rezo.net> wrote: >> a 'grep pid' in the source directory gives: misc/mailman:# >> pidfile: /home/mailman/data/qrunner.pid misc/mailman.in:# >> pidfile: @prefix@/data/qrunner.pid so how does mailman know to >> put its pidfile into /var/run/ ?? > Unfortunately it seems there is no option in 'configure' to send > the pidfile to /var/run/ ?? IIRC Debian accomplishes by patching the sources (or via handy sym-link). Unfortunately I can't check right now. -- 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

Re: [Mailman-Developers] ~mailman/bin/mailmanctl -s start
by J C Lawrence 26 Dec '01

26 Dec '01

On Mon, 24 Dec 2001 12:30:34 +0100 fil <fil(a)rezo.net> wrote: > What happens when the computer crashes then starts again? If the > pidfile stays there, mailctl start will fail. Then your system init scripts are broken. pidfiles go in /var/run -- which should be cleaned out by the system on initial boot, thus preventing the problem. -- 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 3