From tfheen at err.no Thu Sep 1 10:03:31 2005 From: tfheen at err.no (Tollef Fog Heen) Date: Thu, 01 Sep 2005 10:03:31 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <1125501118.23907.21.camel@geddy.wooz.org> (Barry Warsaw's message of "Wed, 31 Aug 2005 11:11:59 -0400") References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> Message-ID: <87zmqx1agc.fsf@thosu.err.no> * Barry Warsaw | At the very least, we must drop Python 2.1 and 2.2. Neither of those | versions are being supported any longer and I will definitely not claim | to have tested the current code base on either version in a very long | time. If we must continue to support Python 2.3, so be it, but I'd like | to leapfrog even that version. There are several Python 2.4 constructs | and modules that I'd dearly love to be able to take advantage of. The default python version in Debian is still 2.3, so I would really like 2.3 to be supported for MM2.2. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From iane at sussex.ac.uk Thu Sep 1 15:18:14 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 01 Sep 2005 14:18:14 +0100 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <87zmqx1agc.fsf@thosu.err.no> References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> Message-ID: <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> --On 1 September 2005 10:03:31 +0200 Tollef Fog Heen wrote: > * Barry Warsaw > >| At the very least, we must drop Python 2.1 and 2.2. Neither of those >| versions are being supported any longer and I will definitely not claim >| to have tested the current code base on either version in a very long >| time. If we must continue to support Python 2.3, so be it, but I'd like >| to leapfrog even that version. There are several Python 2.4 constructs >| and modules that I'd dearly love to be able to take advantage of. > > The default python version in Debian is still 2.3, so I would really > like 2.3 to be supported for MM2.2. So, here we see that the version of Python in Debian stable ('sarge') is python (2.3.5-2), as it is in Debian testing ('etch') release, and in Debian unstable ('sid')! Mailman releases are mailman (2.1.5-8) through (2.1.5.9). I reckon that Mailman 2.2 isn't likely to get into any of these releases, whether it requires 2.3 or 2.4. My view is that Debian should not be allowed to hold up anyone's development cycles. As far as I know, it still ships with exim 3 as the default mailer, over three years after exim 4 was released. I think that even 'sid' ships with exim 3 as the default mailer. -- Ian Eiloart Servers Team Sussex University ITS From brad at stop.mail-abuse.org Thu Sep 1 15:32:52 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 1 Sep 2005 15:32:52 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> Message-ID: At 2:18 PM +0100 2005-09-01, Ian Eiloart wrote: > My view is that Debian should not be allowed to hold up anyone's > development cycles. As far as I know, it still ships with exim 3 as the > default mailer, over three years after exim 4 was released. I think that > even 'sid' ships with exim 3 as the default mailer. The problem is that a majority of the people who run python.org are also heavily involved in Debian, so we're pretty much guaranteed to be shackled by whatever the Debian people want to do. I couldn't even get them to agree to run ntpd instead of ntpdate on the python.org machines, because that's not what was provided in the Debian packages. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Thu Sep 1 15:42:53 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 1 Sep 2005 15:42:53 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> Message-ID: At 3:32 PM +0200 2005-09-01, Brad Knowles wrote: > I couldn't > even get them to agree to run ntpd instead of ntpdate on the > python.org machines, because that's not what was provided in the > Debian packages. Sorry, it's not just a matter of what is provided in the Debian packages. It's also a matter that they feel that good timesync is not important for us, and therefore they don't want to run ntpd. All arguments from Thomas Akin's book "Hardening Cisco Routers" (see ), or , , , or even the Linux Administrators Guide at , were not enough to convince them that good time sync is important. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tfheen at err.no Thu Sep 1 15:59:32 2005 From: tfheen at err.no (Tollef Fog Heen) Date: Thu, 01 Sep 2005 15:59:32 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> (Ian Eiloart's message of "Thu, 01 Sep 2005 14:18:14 +0100") References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> Message-ID: <87wtm0zy63.fsf@thosu.err.no> * Ian Eiloart | --On 1 September 2005 10:03:31 +0200 Tollef Fog Heen wrote: | | > The default python version in Debian is still 2.3, so I would really | > like 2.3 to be supported for MM2.2. | | So, here we see that the | version of Python in Debian stable ('sarge') is python (2.3.5-2), as it is | in Debian testing ('etch') release, and in Debian unstable ('sid')! | | Mailman releases are mailman (2.1.5-8) through (2.1.5.9). | | I reckon that Mailman 2.2 isn't likely to get into any of these releases, | whether it requires 2.3 or 2.4. I'm certainly hoping that Mailman 2.2 will go into the next stable, which is what's currently ?testing?. (Sid is ?unstable? and will always be that, etch will be replaced with a new testing once it's stable.) Of course, this is dependent on whether Mailman 2.2 or etch releases first. | My view is that Debian should not be allowed to hold up anyone's | development cycles. As far as I know, it still ships with exim 3 as the | default mailer, over three years after exim 4 was released. I think that | even 'sid' ships with exim 3 as the default mailer. This is wrong; exim4 was changed to be default for the current stable release, released this summer. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From tfheen at err.no Thu Sep 1 16:00:58 2005 From: tfheen at err.no (Tollef Fog Heen) Date: Thu, 01 Sep 2005 16:00:58 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: (Brad Knowles's message of "Thu, 1 Sep 2005 15:32:52 +0200") References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> Message-ID: <87slwozy3p.fsf@thosu.err.no> * Brad Knowles | At 2:18 PM +0100 2005-09-01, Ian Eiloart wrote: | | > My view is that Debian should not be allowed to hold up anyone's | > development cycles. As far as I know, it still ships with exim 3 as the | > default mailer, over three years after exim 4 was released. I think that | > even 'sid' ships with exim 3 as the default mailer. | | The problem is that a majority of the people who run python.org | are also heavily involved in Debian, so we're pretty much guaranteed | to be shackled by whatever the Debian people want to do. I couldn't | even get them to agree to run ntpd instead of ntpdate on the | python.org machines, because that's not what was provided in the | Debian packages. They might want to look at the ?ntp-simple? Debian package, then. ntpd is in that package. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From barry at python.org Thu Sep 1 16:28:57 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 01 Sep 2005 10:28:57 -0400 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <87zmqx1agc.fsf@thosu.err.no> References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> Message-ID: <1125584937.22618.21.camel@geddy.wooz.org> On Thu, 2005-09-01 at 04:03, Tollef Fog Heen wrote: > The default python version in Debian is still 2.3, so I would really > like 2.3 to be supported for MM2.2. I'm a Gentoo users myself, so I'm not really up on Debian's processes and schedules. However I did check a few other OSes that I had laying around. Tiger (Mac OS X 10.4) is Python 2.3.5 Gentoo's stable is 2.3.5 RHEL4 is 2.3.4 So it looks like we'll have an uphill battle here, at least in the short term. Of course installing Python from source isn't really that hard; OTOH, every hurdle we put up probably peels off 50% of our users. I definitely want the new email package, so let's see if it's feasible to target Python 2.3 and email 3.0 as a separate package, but leave open the door to Python 2.4 if there's a really compelling additional reason, or the OS landscape changes. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050901/5fc51e3f/attachment.pgp From stephen at xemacs.org Thu Sep 1 17:36:47 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 02 Sep 2005 00:36:47 +0900 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: (Brad Knowles's message of "Thu, 1 Sep 2005 15:32:52 +0200") References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> Message-ID: <87d5nsn6k0.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Brad" == Brad Knowles writes: Brad> The problem is that a majority of the people who run Brad> python.org are also heavily involved in Debian, so we're Brad> pretty much guaranteed to be shackled by whatever the Debian Brad> people want to do. Maybe so, but I see little hope that Debian is going to turn into the Energizer Bunny any time soon. They've been getting slower and slower on everything (except putting out bilyuns and bilyuns of new -0.1 packages of _0.2 upstream releases) for years, and this summer they couldn't even get security releases out the door in a timely fashion. I really hope Mailman can avoid getting tied to Debian's release cycle. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From asmodai at in-nomine.org Thu Sep 1 18:00:32 2005 From: asmodai at in-nomine.org (Jeroen Ruigrok/asmodai) Date: Thu, 1 Sep 2005 18:00:32 +0200 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <87d5nsn6k0.fsf@tleepslib.sk.tsukuba.ac.jp> References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <7B71F18BC4EFDFD942117A60@lewes.staff.uscs.susx.ac.uk> <87d5nsn6k0.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <20050901160032.GX42414@nexus.ninth-circle.org> -On [20050901 17:39], Stephen J. Turnbull (stephen at xemacs.org) wrote: >I really hope Mailman can avoid getting tied to Debian's release cycle. Seconded. And I can reasonably speak from the BSD side of things here. FreeBSD ports and pkgsrc (originally NetBSD's) have everything in place for 2.4, sure, older versions are also usable, but the push is/has been made for 2.4 as the standard/default. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono Free Tibet! http://www.savetibet.org/ | http://www.andf.info/ http://www.tendra.org/ | http://www.in-nomine.org/ Tattva, achintya bheda abheda tattva... From bob at nleaudio.com Thu Sep 1 20:10:46 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu, 01 Sep 2005 14:10:46 -0400 Subject: [Mailman-Developers] Mailman 2.X CVS MAIN is back In-Reply-To: <1125584937.22618.21.camel@geddy.wooz.org> References: <43129F49.2000502@is.kochi-u.ac.jp> <1125501118.23907.21.camel@geddy.wooz.org> <87zmqx1agc.fsf@thosu.err.no> <1125584937.22618.21.camel@geddy.wooz.org> Message-ID: <43174426.8060906@nleaudio.com> To add to the list, Mandrake Corporate Server 3.0 (supported for the next 4.5 years) is at Python 2.3.3 (2/9/05). I've got this on most of my production servers, and now that its paid for.... well, you know! :-) Bob Barry Warsaw wrote: > On Thu, 2005-09-01 at 04:03, Tollef Fog Heen wrote: > > >>The default python version in Debian is still 2.3, so I would really >>like 2.3 to be supported for MM2.2. > > > I'm a Gentoo users myself, so I'm not really up on Debian's processes > and schedules. However I did check a few other OSes that I had laying > around. > > Tiger (Mac OS X 10.4) is Python 2.3.5 > Gentoo's stable is 2.3.5 > RHEL4 is 2.3.4 > > So it looks like we'll have an uphill battle here, at least in the short > term. Of course installing Python from source isn't really that hard; > OTOH, every hurdle we put up probably peels off 50% of our users. > > I definitely want the new email package, so let's see if it's feasible > to target Python 2.3 and email 3.0 as a separate package, but leave open > the door to Python 2.4 if there's a really compelling additional reason, > or the OS landscape changes. > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp From msapiro at value.net Fri Sep 2 21:22:33 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri, 2 Sep 2005 12:22:33 -0700 Subject: [Mailman-Developers] Public archives In-Reply-To: <43160B4D.6030706@nleaudio.com> Message-ID: Bob Puff wrote: > >I've got one mailing list for a customer who wants public archives. The box hosts many sites, and >he wants his domain in the URL for the archives. This isn't a problem for private archives, but >there doesn't seem to be a way to set the URL for public archives. > >I recall we hashed this one over a while ago, but was there ever a solution? I don't understand the problem. If there is a correct entry in the VIRTUAL_HOSTS dictionary with his web domain as the key and the value of his list's host_name attribute as the value, the Archiver.Archiver.GetBaseArchiveURL() method should return a URL with his web domain as the host name. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From patrice.albaret at gmail.com Fri Sep 2 22:08:55 2005 From: patrice.albaret at gmail.com (Patrice Albaret) Date: Fri, 2 Sep 2005 16:08:55 -0400 Subject: [Mailman-Developers] LDAP-based list Message-ID: <31b6c67605090213085eccd7eb@mail.gmail.com> Hi, I m currently using the LDAP-connector developped by Martin : http://webserver.offal.homelinux.org/LDAPMemberAdaptor/V3.0/LDAPMemberAdaptor/ I've modified it for being usable with very large LDAP directories (rebuilding an adress instead of making an ldap request for each member). That's not the point. My problem : the member list seems just right through the web interface or even the bin/list_members script at all time (updating when the ldap group is updated etc...). But in fact, the changes in the delivery list are effectives only after a restart of the mailman processes ... The list seems cached... maybe in the config.pck file ... Any hint to solve this problem ? Regards P From msapiro at value.net Sun Sep 4 19:51:41 2005 From: msapiro at value.net (Mark Sapiro) Date: Sun, 4 Sep 2005 10:51:41 -0700 Subject: [Mailman-Developers] LDAP-based list In-Reply-To: <31b6c67605090213085eccd7eb@mail.gmail.com> Message-ID: Patrice Albaret wrote: > >I m currently using the LDAP-connector developped by Martin : >http://webserver.offal.homelinux.org/LDAPMemberAdaptor/V3.0/LDAPMemberAdaptor/ > >I've modified it for being usable with very large LDAP directories >(rebuilding an adress instead of making an ldap request for each >member). >That's not the point. Maybe that is the point. See below. >My problem : the member list seems just right through the web >interface or even the bin/list_members script at all time (updating >when the ldap group is updated etc...). >But in fact, the changes in the delivery list are effectives only >after a restart of the mailman processes ... > >The list seems cached... maybe in the config.pck file ... The list probably is cached, but not in config.pck. The web interface and command line tools are a new process each time a web wrapper or command line tool is invoked, but the qrunners which do the work of handling and delivering posts are processes that keep running between restarts. Thus the various python modules get cached, and presumably in this case information from the LDAP directories (or pieces thereof) gets cached in variables within the LDAP Member Adaptor. You have to insure that calls to getMembers(), getRegularMemberKeys(), etc. go to the LDAP directory each time and don't rely on previously retrieved information. Either that or perhaps set up a cron to do 'bin/mailmanctl restart' periodically to resync. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Mon Sep 5 19:06:06 2005 From: barry at python.org (Barry Warsaw) Date: Mon, 05 Sep 2005 13:06:06 -0400 Subject: [Mailman-Developers] LDAP-based list In-Reply-To: References: Message-ID: <1125939966.10955.46.camel@geddy.wooz.org> On Sun, 2005-09-04 at 13:51, Mark Sapiro wrote: > You have to insure that calls to getMembers(), getRegularMemberKeys(), > etc. go to the LDAP directory each time and don't rely on previously > retrieved information. > > Either that or perhaps set up a cron to do 'bin/mailmanctl restart' > periodically to resync. Or better yet, hook into the MailList instance by overloading the Load() method to resync with LDAP. You'll need to use the extend.py extension mechanism to do this. Read the code for MailList.__init__() for details. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050905/34de7b93/attachment.pgp From joe at skyrush.com Sat Sep 10 21:03:29 2005 From: joe at skyrush.com (Joe Peterson) Date: Sat, 10 Sep 2005 13:03:29 -0600 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM Message-ID: <43232E01.1010505@skyrush.com> I've recently been testing DomainKeys (http://antispam.yahoo.com/domainkeys) and DKIM (which is supposedly a merging of DomainKeys with Cisco's scheme. I am using dk-milter and dkim-milter with sendmail. What this does is add two header lines to outgoing email that allow the receiver to determine the authenticity of the sender... Anyway, since I run a Mailman system too, I figured this might be a problem. Indeed it is, since the header lines get passed through, and when the check is done, it indicates a failure. DomainKeys recommends mail lists regenerate the keys rather than pass them through. What I tried was pretty simple: Mailman doesn't have to deal with these things itself, but if it strips the old keys from the header, the keys will be regenerated on the way out by the MTA, thereby making the whole process clean. So the receiver of the email can at least verify that the mail came from the host hosting Mailman. I suppose Mailman could also check email on the way in for valid keys if it wanted, but that's another subject... I patched Handlers/Cleanse.py as follows: 49a50,55 > # JGP: Remove all "DomainKeys" type header lines, since we want these > # to be regenerated by the MTA when this message is sent out. We need > # to let new such keys be generated because Mailman alters the message, > # and the old keys would be seen as invalid by the receiver. > del msg['domainkey-signature'] > del msg['dkim-signature'] I wanted to pass this by the developers here and see if: 1) This is a reasonable thing to do (or maybe have an option, or even a way to strip selected headers in the config?) 2) If this is the right place to do it. -Thanks, Joe From barry at python.org Sun Sep 11 04:23:19 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 10 Sep 2005 22:23:19 -0400 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: <43232E01.1010505@skyrush.com> References: <43232E01.1010505@skyrush.com> Message-ID: <1126405399.10340.14.camel@geddy.wooz.org> On Sat, 2005-09-10 at 15:03, Joe Peterson wrote: > Anyway, since I run a Mailman system too, I figured this might be a > problem. Indeed it is, since the header lines get passed through, and > when the check is done, it indicates a failure. DomainKeys recommends > mail lists regenerate the keys rather than pass them through. > > What I tried was pretty simple: Mailman doesn't have to deal with these > things itself, but if it strips the old keys from the header, the keys > will be regenerated on the way out by the MTA, thereby making the whole > process clean. > 1) This is a reasonable thing to do (or maybe have an option, or even a > way to strip selected headers in the config?) > > 2) If this is the right place to do it. Cleanse.py is the right place to add this. I'd rather add it unconditionally than add Yet Another Configuration Option to control it though. Is there any reason why you would /not/ want to remove these headers? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050910/42160bec/attachment.pgp From joe at skyrush.com Sun Sep 11 09:11:46 2005 From: joe at skyrush.com (Joe Peterson) Date: Sun, 11 Sep 2005 01:11:46 -0600 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: <1126405399.10340.14.camel@geddy.wooz.org> References: <43232E01.1010505@skyrush.com> <1126405399.10340.14.camel@geddy.wooz.org> Message-ID: <4323D8B2.4050404@skyrush.com> Barry, I agree. I don't see any reason these headers should be kept, since the alterations Mailman makes to the header and body make the header lines useless and misleading. I made a unified diff from the CVS tree and sibmitted a patch through Sourceforge. I put "2.1" as the version, as I was not sure if this applied to 2.1 or 2.2 alpha. -Thanks, Joe Barry Warsaw wrote: > On Sat, 2005-09-10 at 15:03, Joe Peterson wrote: > > >>Anyway, since I run a Mailman system too, I figured this might be a >>problem. Indeed it is, since the header lines get passed through, and >>when the check is done, it indicates a failure. DomainKeys recommends >>mail lists regenerate the keys rather than pass them through. >> >>What I tried was pretty simple: Mailman doesn't have to deal with these >>things itself, but if it strips the old keys from the header, the keys >>will be regenerated on the way out by the MTA, thereby making the whole >>process clean. > > >>1) This is a reasonable thing to do (or maybe have an option, or even a >>way to strip selected headers in the config?) >> >>2) If this is the right place to do it. > > > Cleanse.py is the right place to add this. I'd rather add it > unconditionally than add Yet Another Configuration Option to control it > though. Is there any reason why you would /not/ want to remove these > headers? > > -Barry > From iane at sussex.ac.uk Mon Sep 12 11:41:48 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 12 Sep 2005 10:41:48 +0100 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: <43232E01.1010505@skyrush.com> References: <43232E01.1010505@skyrush.com> Message-ID: --On 10 September 2005 13:03:29 -0600 Joe Peterson wrote: ... > > What I tried was pretty simple: Mailman doesn't have to deal with these > things itself, but if it strips the old keys from the header, the keys > will be regenerated on the way out by the MTA, thereby making the whole > process clean. So the receiver of the email can at least verify that > the mail came from the host hosting Mailman. I suppose Mailman could > also check email on the way in for valid keys if it wanted, but that's > another subject... > No, the MTA should check the keys. That is; if you ever want to reject mail on the basis of them. Mailman can't reject mail without generating collateral SPAM. What would be nice would be a way that Mailman *could* refuse to accept mail from the MTA. You could also configure your MTA to remove the keys. I presume it will want to do that when forwarding mail for any reason. -- Ian Eiloart Servers Team Sussex University ITS From joe at skyrush.com Mon Sep 12 16:11:22 2005 From: joe at skyrush.com (Joe Peterson) Date: Mon, 12 Sep 2005 08:11:22 -0600 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: References: <43232E01.1010505@skyrush.com> Message-ID: <43258C8A.5030606@skyrush.com> Ian Eiloart wrote: > No, the MTA should check the keys. That is; if you ever want to reject mail > on the basis of them. Mailman can't reject mail without generating > collateral SPAM. What would be nice would be a way that Mailman *could* > refuse to accept mail from the MTA. Yes, the MTA does check the keys when receiving mail. It then puts additional header lines in that tell the result of the check, so Mailman, if it wanted to do a spam check, could check those. But right, Mailman would not want to check the keys directly. > You could also configure your MTA to remove the keys. I presume it will > want to do that when forwarding mail for any reason. Well, with regular (not mail list) forwarding, the keys just get passed through anyway, and this works for DomainKeys (unlike SPF). For mail list resending (like Mailman does), the keys become invalid due to changes in the header/body, and the milter used by the MTA does not add new keys if it sees keys already there (it thinks the keys can be used to validate the message). Since only Mailman knows it did the mods, it needs to remove the old keys; the message is now really a "new message" to be re distributed. The milter/MTA will then will add new keys before it's sent. -Joe From iane at sussex.ac.uk Mon Sep 12 16:24:12 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 12 Sep 2005 15:24:12 +0100 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: <43258C8A.5030606@skyrush.com> References: <43232E01.1010505@skyrush.com> <43258C8A.5030606@skyrush.com> Message-ID: --On 12 September 2005 08:11:22 -0600 Joe Peterson wrote: > Ian Eiloart wrote: >> No, the MTA should check the keys. That is; if you ever want to reject >> mail on the basis of them. Mailman can't reject mail without generating >> collateral SPAM. What would be nice would be a way that Mailman *could* >> refuse to accept mail from the MTA. > > Yes, the MTA does check the keys when receiving mail. It then puts > additional header lines in that tell the result of the check, so > Mailman, if it wanted to do a spam check, could check those. But right, > Mailman would not want to check the keys directly. > >> You could also configure your MTA to remove the keys. I presume it will >> want to do that when forwarding mail for any reason. > > Well, with regular (not mail list) forwarding, the keys just get passed > through anyway, and this works for DomainKeys (unlike SPF). > > For mail list resending (like Mailman does), the keys become invalid due > to changes in the header/body, and the milter used by the MTA does not > add new keys if it sees keys already there (it thinks the keys can be > used to validate the message). Since only Mailman knows it did the > mods, it needs to remove the old keys; the message is now really a "new > message" to be re distributed. The milter/MTA will then will add new > keys before it's sent. > > -Joe Ah, so you're thinking of Sendmail, or something similar. I'm thinking of Exim, which can easily remove the specific headers for an email that it's delivering to Mailman. So, Exim doesn't know that Mailman is going to change the headers, but it can be told! -- Ian Eiloart Servers Team Sussex University ITS From joe at skyrush.com Mon Sep 12 16:48:45 2005 From: joe at skyrush.com (Joe Peterson) Date: Mon, 12 Sep 2005 08:48:45 -0600 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: References: <43232E01.1010505@skyrush.com> <43258C8A.5030606@skyrush.com> Message-ID: <4325954D.9070602@skyrush.com> Yep, sendmail. I'm curous, though: how does Exim know that the mail it is about to deliver is going to Mailman? Does it key off of the fact that it's about to deliver to the mailman program? Well, in any case, if it's done in Cleanse.py in Mailman, the mailer doesn't have to be tweaked, and there's no reason, as Barry said, for Mailman to preserve DomainKeys type headers... -Joe Ian Eiloart wrote: > Ah, so you're thinking of Sendmail, or something similar. I'm thinking of > Exim, which can easily remove the specific headers for an email that it's > delivering to Mailman. So, Exim doesn't know that Mailman is going to > change the headers, but it can be told! From iane at sussex.ac.uk Mon Sep 12 16:54:24 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 12 Sep 2005 15:54:24 +0100 Subject: [Mailman-Developers] Dealing with DomainKeys and DKIM In-Reply-To: <4325954D.9070602@skyrush.com> References: <43232E01.1010505@skyrush.com> <43258C8A.5030606@skyrush.com> <4325954D.9070602@skyrush.com> Message-ID: <5E64F5790FD32CFC6A73550E@lewes.staff.uscs.susx.ac.uk> --On 12 September 2005 08:48:45 -0600 Joe Peterson wrote: > Yep, sendmail. I'm curous, though: how does Exim know that the mail it > is about to deliver is going to Mailman? Does it key off of the fact > that it's about to deliver to the mailman program? Yes, that's exactly it. In fact, it checks the presence of the list configuration file. > Well, in any case, > if it's done in Cleanse.py in Mailman, the mailer doesn't have to be > tweaked, and there's no reason, as Barry said, for Mailman to preserve > DomainKeys type headers... No, that's fair enough. > -Joe > > > Ian Eiloart wrote: >> Ah, so you're thinking of Sendmail, or something similar. I'm thinking >> of Exim, which can easily remove the specific headers for an email that >> it's delivering to Mailman. So, Exim doesn't know that Mailman is going >> to change the headers, but it can be told! -- Ian Eiloart Servers Team Sussex University ITS From msapiro at value.net Sat Sep 17 03:03:20 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri, 16 Sep 2005 18:03:20 -0700 Subject: [Mailman-Developers] Mal Formed MIME post leaked through to list Message-ID: I just had a problem on a Mailman 2.1.5 list although I think it's the Python email library - Python is 2.3.3. A mal formed MIME message was posted to a list. The message was much larger than max_message_size yet it wasn't held, and several parts came through that weren't in pass_mime_types. The basic post was multipart/mixed with a multipart/alternative sub part, a message/rfc822 sub part and the final text/plain msg_footer. The message/rfc822 sub part was multipart/mixed with 3 subparts of type multipart/alternative, application/pdf and multipart/appledouble. The problem with the MIME structure is that the boundary for the multipart/alternative and multipart/appledouble sub parts of the multipart/mixed message/rfc822 was identical to the boundary of the multipart/mixed part. I suspect the original message/rfc822 attached message was malformed, but it could have been broken in the attaching process. The original attached message was created by User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.6 and the post was sent by Yahoo mail. I suspect what happened is that the Python email library saw the end of part boundary for the second multipart/alternative part and treated it as the end of the message/rfc822 part since the boundary was the same. Thus the big parts didn't get counted in the message size nor did they get filtered by content filtering. Is this analysis correct? Is it fixed in later versions of the email library? Here is an annotated copy of the received post with all content and non-relevant headers removed. Received: from [63.201.34.79] by web81402.mail.yahoo.com via HTTP; Fri, 16 Sep 2005 16:32:37 PDT MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-95218806-1126913557=:91474" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: gpc-talk at grizz.org X-Mailman-Version: 2.1.5 -------------------above from the headers of the received post --0-95218806-1126913557=:91474 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit ------------------above are first part headers - I think this was originally multipart/alternative and a text/html part was stripped --0-95218806-1126913557=:91474 Content-Type: message/rfc822 ------------------part headers from the attached message/rfc822 part User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.6 Mime-version: 1.0 Content-type: multipart/mixed; boundary="MS_Mac_OE_3209732028_3749601_MIME_Part" Content-Length: 175299 ------------------from the headers of the attached message --MS_Mac_OE_3209732028_3749601_MIME_Part Content-type: multipart/alternative; boundary="MS_Mac_OE_3209732028_3749601_MIME_Part" ---------------------part headers for multipart/alternative sub part of attached message. Note that the boundary is the same as that of the containing multipart/mixed part. --MS_Mac_OE_3209732028_3749601_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit -------------------------part headers for text/plain alternative --MS_Mac_OE_3209732028_3749601_MIME_Part-- -----------------------end of multipart/alternative part but also looks like end of multipart/mixed part. I think a text/html part may have been stripped, but the multipart/alternative part isn't collapsed. --MS_Mac_OE_3209732028_3749601_MIME_Part Content-type: application/pdf; name="Recruitment.pdf"; x-mac-creator="4341524F"; x-mac-type="50444620" Content-disposition: attachment Content-transfer-encoding: base64 -----------------------------------another sub part of multipart/mixed - should have been filtered --MS_Mac_OE_3209732028_3749601_MIME_Part Content-type: multipart/appledouble; boundary="MS_Mac_OE_3209732024_3737509_MIME_Part" -----------------------------------another sub part of multipart/mixed - should have been filtered. Still same boundary --MS_Mac_OE_3209732024_3737509_MIME_Part Content-type: application/applefile; name="High Sierra Trip 2003 Me" Content-transfer-encoding: base64 Content-disposition: attachment ----------------------sub part of multipart/appledouble should have been filtered --MS_Mac_OE_3209732024_3737509_MIME_Part Content-type: image/jpeg; name="High Sierra Trip 2003 Me"; x-mac-creator="6F676C65"; x-mac-type="4A504547" Content-disposition: attachment Content-transfer-encoding: base64 ----------------------sub part of multipart/appledouble should have been filtered --MS_Mac_OE_3209732024_3737509_MIME_Part-- ----------------------- end of multipart/appledouble --MS_Mac_OE_3209732028_3749601_MIME_Part-- ------------------------ end of multipart/mixed --0-95218806-1126913557=:91474 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------ part headers for list footer --0-95218806-1126913557=:91474-- ------------------------ end of outermost message -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at stop.mail-abuse.org Sat Sep 17 16:43:41 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 17 Sep 2005 16:43:41 +0200 Subject: [Mailman-Developers] Mal Formed MIME post leaked through to list In-Reply-To: References: Message-ID: At 6:03 PM -0700 2005-09-16, Mark Sapiro wrote: > I just had a problem on a Mailman 2.1.5 list although I think it's the > Python email library - Python is 2.3.3. The e-mail related library routines are known to have been updated for Python 2.4, and there's been discussion of whether or not to require Python 2.4 for the next major release of Mailman (not sure if that's going to be 2.2 or 3.0). I would be very interested to know how that would have dealt with the problem you've had. Unfortunately, I don't have the skills or knowledge to help you answer that question. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sat Sep 17 18:12:36 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat, 17 Sep 2005 09:12:36 -0700 Subject: [Mailman-Developers] Mal Formed MIME post leakedthrough to list In-Reply-To: Message-ID: Brad Knowles wrote: > > The e-mail related library routines are known to have been >updated for Python 2.4, and there's been discussion of whether or not >to require Python 2.4 for the next major release of Mailman (not sure >if that's going to be 2.2 or 3.0). > > I would be very interested to know how that would have dealt with >the problem you've had. Unfortunately, I don't have the skills or >knowledge to help you answer that question. I've done a bit more research and I intend to continue looking into this, but I posted in the hope that Barry or someone else on the list might already have the answer. ans save me some trouble. Additional things I've found are: I confirmed that the post e-mail was clearly wrong. RFC2046 states "The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line." That notwithstanding, I think the parser and Mailman should protect against this kind of error. I looked a bit at the documentation of the email library and based on that, I think what may have happened is when the parser saw the first "end of subpart boundary" which looked the same as the outer "end of part boundary", it took it as the end of the outer part and treated the rest as an epilogue. Hold.py does the following to compute message size: if mlist.max_message_size > 0: bodylen = 0 for line in email.Iterators.body_line_iterator(msg): bodylen += len(line) but the body_line_iterator() method may skip the epilogue. Also, I think MimeDel.py will leave the epilogue in the message. Interestingly, both Thunderbird 1.5b1 and MS Outlook Express 6 seem to parse the message as intended, but Mutt 1.4.1i sees it more like Mailman does. If there's no answer on the list, I intend to keep at it, but not for the next week as I will be away. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Sun Sep 18 23:34:21 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 19 Sep 2005 06:34:21 +0900 Subject: [Mailman-Developers] Mal Formed MIME post leakedthrough to list In-Reply-To: References: Message-ID: <432DDD5D.8040404@is.kochi-u.ac.jp> Hi, Mark Sapiro wrote: > I looked a bit at the documentation of the email library and based on > that, I think what may have happened is when the parser saw the first > "end of subpart boundary" which looked the same as the outer "end of > part boundary", it took it as the end of the outer part and treated > the rest as an epilogue. Hold.py does the following to compute message > size: > > if mlist.max_message_size > 0: > bodylen = 0 > for line in email.Iterators.body_line_iterator(msg): > bodylen += len(line) > > but the body_line_iterator() method may skip the epilogue. > I think we can write more intuitive and robust code like this: if mlist.max_message_size > 0: bodylen = len(msg.as_string().split('\n\n',1)[1]) > Also, I think MimeDel.py will leave the epilogue in the message. I will look at it closer. > > Interestingly, both Thunderbird 1.5b1 and MS Outlook Express 6 seem to > parse the message as intended, but Mutt 1.4.1i sees it more like > Mailman does. > > If there's no answer on the list, I intend to keep at it, but not for > the next week as I will be away. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Mon Sep 19 05:21:47 2005 From: barry at python.org (Barry Warsaw) Date: Sun, 18 Sep 2005 23:21:47 -0400 Subject: [Mailman-Developers] Mal Formed MIME post leakedthrough to list In-Reply-To: References: Message-ID: <1127100107.10807.29.camel@geddy.wooz.org> On Sat, 2005-09-17 at 12:12, Mark Sapiro wrote: > I confirmed that the post e-mail was clearly wrong. RFC2046 states "The > boundary delimiter MUST NOT appear inside any of the encapsulated > parts, on a line by itself or as the prefix of any line." That > notwithstanding, I think the parser and Mailman should protect against > this kind of error. The email 3.0 parser will be much more robust against these types of problems, but the best you can hope for is to take the defects into account when deciding what to do with the message. For example, I don't think it's unreasonable for Mailman to discard (or at least hold) messages with defects. IME, 99.99% of malformed messages are malware. > I looked a bit at the documentation of the email library and based on > that, I think what may have happened is when the parser saw the first > "end of subpart boundary" which looked the same as the outer "end of > part boundary", it took it as the end of the outer part and treated > the rest as an epilogue. Hold.py does the following to compute message > size: > > if mlist.max_message_size > 0: > bodylen = 0 > for line in email.Iterators.body_line_iterator(msg): > bodylen += len(line) > > but the body_line_iterator() method may skip the epilogue. Yep. In private email, Mark pointed us to a patch for Hold.py which takes preambles and epilogues into account when calculating messages sizes. This has been applied to the 2.1 maintenance branch and the 2.2 trunk. > Also, I think MimeDel.py will leave the epilogue in the message. I think that's generally appropriate (though I'm open to opinions while we're still on email 2.5). If we start discarding malformed messages, it probably makes sense to keep them, since it won't be possible to hide content there. > Interestingly, both Thunderbird 1.5b1 and MS Outlook Express 6 seem to > parse the message as intended, but Mutt 1.4.1i sees it more like > Mailman does. Really, ultimately, it's up to the semantics of Python's email library. Changing that is not easy. ;) Thanks! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050918/34c4cde6/attachment.pgp From barry at python.org Mon Sep 19 05:26:13 2005 From: barry at python.org (Barry Warsaw) Date: Sun, 18 Sep 2005 23:26:13 -0400 Subject: [Mailman-Developers] Mal Formed MIME post leakedthrough to list In-Reply-To: <432DDD5D.8040404@is.kochi-u.ac.jp> References: <432DDD5D.8040404@is.kochi-u.ac.jp> Message-ID: <1127100373.10802.33.camel@geddy.wooz.org> On Sun, 2005-09-18 at 17:34, Tokio Kikuchi wrote: > I think we can write more intuitive and robust code like this: > > if mlist.max_message_size > 0: > bodylen = len(msg.as_string().split('\n\n',1)[1]) The only problem with that is that it's not very efficient to turn the message back into a flattened string in order to calculate its size. Here's an idea: Python's FeedParser (or a subclass of that in Mailman) should keep a running count of the size of data fed to it, and it should add that to the message as an attribute. Even cooler would be if each subpart could have an accurate .size attribute added to it as it was being parsed. Anybody care to work up a patch for that? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050918/74ea5429/attachment.pgp From jdennis at redhat.com Thu Sep 22 00:07:49 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 Sep 2005 18:07:49 -0400 Subject: [Mailman-Developers] structural problem with MemberAdapter Message-ID: <1127340469.1827.97.camel@finch.boston.redhat.com> Good news, bad news: good news is I've implemented a LDAP based membership adapter that implements the complete MemberAdapter interface (the previous LDAP adapter was incomplete and limited in application). In stand alone testing my adapter seems to work quite nicely. Skip to the last paragraph if you don't need or want the details. Now the bad news, I'm having trouble integrating it because of either structural problems with adapters or a lack of understanding of how adapters are supposed to work. I'm looking for guidance or insight. Here are the issues I've run into: * Adapters are discovered by the presence of extend.py in the list's directory. How does extend.py get into the list directory? The only way I could figure was manual copying after list creation, this isn't a viable mechanism for a running site. Also, while I can see the value of per list adapters that seems like a niche case, a more common scenario would be every list resident at a site would use the same adapter module. To solve this problem I added code in the MailList constructor to look for a mm_cfg variable defining a global adapter module. But list creation/instantiation is a two step process, MailList object construction in __init__, followed by MailList.Create(). The adapter is not loaded in __init__ unless a name is provided, which is only done after Create() has been called. Most importantly an adapter cannot correctly initialize itself until the work of Create() is complete. This is very important, but more on this later. This sequence in TestBase.py leaves the adapter unloaded and uninitialized, it does not work. mlist = MailList.MailList() mlist.Create('_xtest', 'test at dom.ain', 'xxxxx') This idiom below which is found in most of the code does work because the list has already been created, but now we're back to the chicken and egg problem of when does extend.py get into the list directory. mlist = MailList.MailList(listname, lock=0) This is a good moment to go back to the issue of per list adapter initialization (or rather the lack of it). After the mlist is instantiated as above it might very well call an adapter method, for example mlist.addNewMember(). But the adapter has never been called as part of list creation. If the adapter must create entities in a backend database to service the list data it has never been given that opportunity. Thus the adapter is dependent on asking the question "does this list exist in my database, if not create it" every time the adapter object is instantiated, this is not only a big performance problem but it completely fails with the calling sequence in TestBase.py. If you've followed along so far pat yourself on the back :-) here's the payoff :-) Summary: -------- Unless I'm out to lunch with a horrible misunderstanding I propose 3 changes: 1) Provide a site wide variable that specifies an adapter for every list which is overridden by the presence of extend.py in the list directory. If the site wide adapter is used then MailList.__init__() loads it and calls an initialization function in the module (extend()??, __init__()??) 2) At the end of MailList.Create() it should test for the existence of an adapter and if so it should attempt to call the adapters Create() method. 3) Just as the adapter is not informed of list creation is is not informed of list destruction either, calls need to be added to invoke Remove() as well. I'm happy to provide patches for all this, I'm not interested in suggesting anyone else do more work, I'm mostly interested in knowing if I'm on the right track or if I have a misunderstanding. PostScript (or a few more questions): ------------------------------------- Now after having fully implemented the adapter interface I have to admit I don't really understand what its buying you over the existing OldMemberAdapter. My initial thought was to capitalize on existing user information at a site, but given the way mailman data is structured (a set of lists, each list may contain both local and unknown foreign users, and user properties are per list) then there seems to be little value in intermingling site user data and mailman list data. Also, it was not clear how an adapter might implement just a subset of the methods via inheritance, I suppose it would copy the function pointers from the mlist._memberadapter into its own methods before resetting mlist._memberadapter to itself. yes/no? -- John Dennis From tkikuchi at is.kochi-u.ac.jp Thu Sep 22 07:41:59 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 22 Sep 2005 14:41:59 +0900 Subject: [Mailman-Developers] Patch: Select language(s) when install Message-ID: <43324427.5080600@is.kochi-u.ac.jp> Hi Developers, I've uploaded a patch to select languages when installing mailman. Here is a excerpt from SF tracker: ------------------------------------------------------- Subject: [ mailman-Patches-1298355 ] Select language(s) when install Date: Wed, 21 Sep 2005 22:35:37 -0700 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1298355&group_id=103 Initial Comment: While the number of translated languages is growing, most users are using only a few languages. With this patch, the site admin can select his/her required languages by an option to the configure script by `--with-languages' and can considerably reduce the install size. This patch is for 2.2.0a0 (most recent CVS as of writing) but also applicable to 2.1.6 except that you may have to regenerate configure script by invoing autoconf command. Patch usage: % cd mailman (src directory) % patch -p0 < /path/to/install_selected_language.patch.txt Configure usage: % ./configure --with-languages="ja fr" ... en+ja+fr % ./configure --with-languages="" ... all available languages % ./configure .... all available languages % ./configure --with-languages="none" ... English only Japanese and Korean codecs are no longer installed by `make install' but availability is checked during the configure run and urge to install if they are absent when CJK languages are included in the language list. I hope skilled developers can review this patch before I check in to the CVS. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Sun Sep 25 00:50:36 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 24 Sep 2005 18:50:36 -0400 Subject: [Mailman-Developers] structural problem with MemberAdapter In-Reply-To: <1127340469.1827.97.camel@finch.boston.redhat.com> References: <1127340469.1827.97.camel@finch.boston.redhat.com> Message-ID: <1127602236.14497.31.camel@geddy.wooz.org> On Wed, 2005-09-21 at 18:07, John Dennis wrote: > Good news, bad news: good news is I've implemented a LDAP based > membership adapter that implements the complete MemberAdapter interface > (the previous LDAP adapter was incomplete and limited in application). > In stand alone testing my adapter seems to work quite nicely. > > Skip to the last paragraph if you don't need or want the details. > > Now the bad news, I'm having trouble integrating it because of either > structural problems with adapters or a lack of understanding of how > adapters are supposed to work. I'm looking for guidance or insight. Here > are the issues I've run into: John, I think you understand the current state of affairs exactly right. At the time I designed the extend.py stuff, it wasn't a requirement to support site-wide list specialization. > * Adapters are discovered by the presence of extend.py in the list's > directory. How does extend.py get into the list directory? The only way > I could figure was manual copying after list creation, this isn't a > viable mechanism for a running site. Right. I was thinking you might be able to hook into the create() and remove() methods in the MTA modules, but that doesn't work for several reasons. First, you've have to implement the same code for each module, and second, the call to those functions doesn't really happen at the right time. > 1) Provide a site wide variable that specifies an adapter for every list > which is overridden by the presence of extend.py in the list directory. > If the site wide adapter is used then MailList.__init__() loads it and > calls an initialization function in the module (extend()??, > __init__()??) > > 2) At the end of MailList.Create() it should test for the existence of > an adapter and if so it should attempt to call the adapters Create() > method. > > 3) Just as the adapter is not informed of list creation is is not > informed of list destruction either, calls need to be added to invoke > Remove() as well. You might consider instead creating these functions in the Mailman/Site.py module. The intention of that module is to implement site-wide customizations (or at least, provide the hooks for that). Right now, there's nothing in there that hooks into the list creation and instantiation process, but it definitely could. You could add these functions: * list_create(): called when a new mailing list is first created. * list_open(): called when an existing mailing list is opened (i.e. its __init__() is called). The above each take the MailList instance and can stuff new methods into the instance to override any behavior you want. I don't think you'll need to hook into MailList.Load() or MailList.Save() because those you'll do in your site-wide adapter. Also, hooking into list deletion is trickier because as you can see in bin/rmlist and Mailman/Cgi/rmlist.py, they don't actually call anything on the MailList instance before the low-level removal procedure is performed (i.e. unlinking and such). That's a flaw that would take more work to fix, because what you'd really want to do is move the bulk of that code into the MailList class, and have those two other files call something like MailList.Delete(). The latter would then be hooked by a Site.py list_delete() function. > I'm happy to provide patches for all this, I'm not interested in > suggesting anyone else do more work, I'm mostly interested in knowing if > I'm on the right track or if I have a misunderstanding. I think you're on the right track. Hopefully the above is helpful. > PostScript (or a few more questions): > ------------------------------------- > > Now after having fully implemented the adapter interface I have to admit > I don't really understand what its buying you over the existing > OldMemberAdapter. My initial thought was to capitalize on existing user > information at a site, but given the way mailman data is structured (a > set of lists, each list may contain both local and unknown foreign > users, and user properties are per list) then there seems to be little > value in intermingling site user data and mailman list data. > > Also, it was not clear how an adapter might implement just a subset of > the methods via inheritance, I suppose it would copy the function > pointers from the mlist._memberadapter into its own methods before > resetting mlist._memberadapter to itself. yes/no? I'm not sure I understand exactly what you're trying to do here. The intention was that using a different adapter was an all-or-nothing proposition. I.e. if you were going to use an LDAP or MySQL adapter, then you wouldn't use any of the config.pck based OldMemberAdapter. I have my doubts that Mailman would be able to intermix the two. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050924/684698bc/attachment.pgp From bjorn at sourcelabs.com Fri Sep 23 22:10:55 2005 From: bjorn at sourcelabs.com (Bjorn-Erik Townsend) Date: Fri, 23 Sep 2005 13:10:55 -0700 Subject: [Mailman-Developers] Patch submitted Message-ID: <4334614F.3020403@sourcelabs.com> Hello all, I submitted a small patch just now for Bug 1212066 (lack of date header in new list notification emails), a cosmetic issue which was annoying me (and setting off my spam filters). The website suggests sending an email to this list to let the developers know when a patch is submitted, so I thought I'd send this along. Here's a link to the patch info on Sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=1301983&group_id=103&atid=300103 I have it running in production on a site running Mailman 2.1.6+Courier-MTA and it works as expected. Thanks for a fine list manager! -- Bjorn Townsend | bjorn at sourcelabs.com From barry at python.org Sun Sep 25 19:44:40 2005 From: barry at python.org (Barry Warsaw) Date: Sun, 25 Sep 2005 13:44:40 -0400 Subject: [Mailman-Developers] Patch submitted In-Reply-To: <4334614F.3020403@sourcelabs.com> References: <4334614F.3020403@sourcelabs.com> Message-ID: <1127670280.1249.8.camel@presto.wooz.org> On Fri, 2005-09-23 at 16:10, Bjorn-Erik Townsend wrote: > I submitted a small patch just now for Bug 1212066 (lack of date header > in new list notification emails), a cosmetic issue which was annoying me > (and setting off my spam filters). The website suggests sending an > email to this list to let the developers know when a patch is submitted, > so I thought I'd send this along. > > Here's a link to the patch info on Sourceforge: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1301983&group_id=103&atid=300103 I think Tokio already applied this to the 2.2 (CVS trunk), though it should also probably be applied to the 2.1 maintenance branch. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050925/2a83aef0/attachment.pgp