From brad.knowles at skynet.be Wed Jun 2 09:32:07 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed Jun 2 09:32:32 2004 Subject: [Mailman-Developers] FAQ 1.9. What does "message has implicit destination" mean? Message-ID: Folks, I've been trying to debug a problem we've seen recently on one of our mailing lists, and ran across this FAQ entry (at ) which seems to have a relevant paragraph: The reason this happens is that mail being distributed by a mail list retains the name of the mail list in the To: header and the name of the original sender in the From: header. So, when the mail gets to the sub-list, it is still marked as being To the umbrella list. By entering the name of the umbrella list as a valid alias, you tell your sub-list that it's OK to accept mail which was originally sent to the umbrella list. In particular, the problem I've been trying to debug was a message I had sent to a particular person which was cc'ed to the mailing list. By the time the mailing list recipients got the message, the mailing list address had moved from the "Cc:" header to the "To:" header, and the original contents of the "To:" header had gotten destroyed. I rooted around in the raw message archives, and the message was actually received with the correct addresses, so it must have been Mailman that did some header scrubbing of some sort. I've looked through CookHeaders.py and SMTPDirect.py, and other files under the mailman/Mailman directory tree, and I haven't found where this behaviour is taking place. Can someone help me understand why the original contents of the "To:" header would be destroyed and replaced with the mailing list address, as opposed to having the contents of the "To:" header placed on the "Cc:" header and then the mailing list address placed in the "To:" header after this data was moved to a safe location? Can someone help me understand where this modification is actually taking place, so that I can fix this bug in our copy of the code? Once I understand better what is going on, why, and where, I can file a bug report with SourceForge, along with a suitable suggested patch. Thanks! -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From bscott at pps.k12.or.us Thu Jun 3 17:01:54 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Thu Jun 3 17:03:14 2004 Subject: [Mailman-Developers] Mailman Screens Message-ID: Hello, We would like to modify the menu options for Mailman. We would like to remove the Language Options Link and a few more. Can this be done? What file should be modify? Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4827 bscott@pps.k12.or.us From andrew.smith at tbwaworld.com Fri Jun 4 03:49:08 2004 From: andrew.smith at tbwaworld.com (Andrew Smith) Date: Fri Jun 4 03:50:00 2004 Subject: [Mailman-Developers] Mailman Screens In-Reply-To: References: Message-ID: <40C02974.6060506@tbwaworld.com> I think general.py Bev Scott wrote: >Hello, > >We would like to modify the menu options for Mailman. We would like to >remove the Language Options Link and a few more. > >Can this be done? >What file should be modify? > >Bev > >Bev Scott >Web Database >Portland Public Schools >503-916-2000 4827 >bscott@pps.k12.or.us > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers >Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/andrew.smith%40tbwaworld.com > > ________________________________________________________________________ IMPORTANT NOTICE: Information contained in this e-mail is intended for the use of the addressee only, is confidential and may be legally privileged. Any dissemination, distribution, copying or use of this communication without prior permission of the sender is strictly prohibited. While this email has been scanned for viruses, the contents of any attachments to this email may contain software viruses which could damage your own computer system. Whilst every reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment. From foobar at eh.net Fri Jun 4 08:39:03 2004 From: foobar at eh.net (foobar@eh.net) Date: Fri Jun 4 08:34:31 2004 Subject: [Mailman-Developers] Running scripts when subscriptions recieved Message-ID: I run the mailing lists for a mid-sized academic site (http://eh.net). We recently switched over from a legacy Listproc installation which was highly customized and was falling apart. We deal with a lot of spam at the site, however, and we're looking into setting up TMDA (Tagged Message Delivery Agent), a blacklist/whitelist system. One of the things we'd like to whitelist on a site-wide basis (not just for the list email, but for the administrators' addresses as well) is a list of current and past subscribers. Now, the issue arises of how to keep such a system *current*. What's the best place in the Python code to hook into so that I can get a script to run whenever a subscriber joins a list? Optimally, this should also be able to call the script with the address of the subscriber as an argument, so that a sitewide resync is not necessary per address. From encolpe at colpi.info Sun Jun 6 05:47:04 2004 From: encolpe at colpi.info (Encolpe DEGOUTE) Date: Sun Jun 6 05:47:13 2004 Subject: [Mailman-Developers] [PATCH] antispam policy in the mail body Message-ID: <20040606114704.7d620d0c@gosseyn> Hi, this patch is made for 2.0.11, but it will be easy to put it on 2.1.5. The goal is to parse the email body to substitute all email address using a random choice of dot and at strings. Regards, -- Encolpe DEGOUTE http://colpi.info Logiciels libres, hockey sur glace et autres activit?s c?r?brales -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman-2.0.11-antispam.patch Type: application/octet-stream Size: 1468 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040606/bf57e02a/mailman-2.0.11-antispam.obj From encolpe at colpi.info Sun Jun 6 08:38:48 2004 From: encolpe at colpi.info (Encolpe DEGOUTE) Date: Sun Jun 6 08:38:53 2004 Subject: [Mailman-Developers] [PATCH] antispam policy in the mail body In-Reply-To: <20040606114704.7d620d0c@gosseyn> References: <20040606114704.7d620d0c@gosseyn> Message-ID: <20040606143848.626a215e@gosseyn> Encolpe DEGOUTE ?crivit: > Hi, > this patch is made for 2.0.11, but it will be easy to put it on 2.1.5. > The goal is to parse the email body to substitute all email address > using a random choice of dot and at strings. After a test it doesn't work with Python 1.5. Python 2.1 is required. -- Encolpe DEGOUTE http://colpi.info Logiciels libres, hockey sur glace et autres activit?s c?r?brales From Nigel.Metheringham at dev.intechnology.co.uk Mon Jun 7 08:25:42 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon Jun 7 08:25:48 2004 Subject: [Mailman-Developers] Mailman 2.1 & Exim 4 HOWTO Message-ID: <1086611142.7909.6.camel@angua.localnet> I've been revising this HOWTO and now have it in final draft state. I'd appreciate any constructive comments on it. The main HOWTO is at:- http://www.exim.org/test/mailman21.html A much shorter subset thats intended to go into the Mailman distribution package as README.EXIM is at:- http://www.exim.org/test/readme.exim.html with the text form which would actually be shipped at:- http://www.exim.org/test/readme.exim.txt I have got almost all the code fragments running in my test setup at home - however if any idiocies in the code have slipped through I'd really like to know... I'm sending this message (separately) to both exim-users and mailman-developers. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jae+python at jerhard.org Mon Jun 7 23:39:35 2004 From: jae+python at jerhard.org (=?ISO-8859-1?Q?J=FCrgen?= A. Erhard) Date: Mon Jun 7 23:39:41 2004 Subject: [Mailman-Developers] What about bug #880073? Message-ID: Hi all. Haven't seen mention of this in 2.1.5, so I thought I'd give a yell. The longer it takes to fix that (which it doesn't, Bernhard does have a fix, even if probably not the most elegant), the even longer we have to live with it. Bye, J PS: This bug is *extremely* annoying, since suddenly all the 2.1.4 using lists end up in my main folder, instead of the folders they belong to. And just when xiph.org have seen the light and made the switch to Mailman... -- J?rgen A. Erhard My WebHome: http://jerhard.org George Herrimann's Krazy Kat (http://www.krazy.com) "MCSE: Minesweeper Champion and Solitare Expert" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040608/943facd1/attachment.bin From ssekora at literati.com Tue Jun 8 13:39:08 2004 From: ssekora at literati.com (Sean Sekora) Date: Tue Jun 8 13:29:53 2004 Subject: [Mailman-Developers] add member without having a moderator accept Message-ID: <003c01c44d7f$81888650$38faa8c0@web02> I'm trying to add members automatically, without a moderator having to accept the member. From dallas at dreamhost.com Tue Jun 8 21:59:11 2004 From: dallas at dreamhost.com (Dallas Bethune) Date: Tue Jun 8 21:59:16 2004 Subject: [Mailman-Developers] senddigests problem Message-ID: <99EDB3CC-B9B8-11D8-8FC1-000A95AA76E0@dreamhost.com> My senddigests cron stopped working a couple of days ago. It runs through about 1/3 of the domains and then spits out this error: Traceback (most recent call last): File "/home/mailman/cron/senddigests", line 95, in ? main() File "/home/mailman/cron/senddigests", line 87, in main mlist.send_digest_now() File "/home/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests msg = scrubber(mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 227, in process url = save_attachment(mlist, part, dir, filter_html=False) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 359, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/home/mailman/pythonlib/email/Message.py", line 708, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/home/mailman/pythonlib/email/Message.py", line 591, in get_param for k, v in self._get_params_preserve(failobj, header): File "/home/mailman/pythonlib/email/Message.py", line 538, in _get_params_preserve params = Utils.decode_params(params) File "/home/mailman/pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/home/mailman/pythonlib/email/Utils.py", line 284, in decode_rfc2231 charset, language, s = parts ValueError: unpack list of wrong size I made it print out the lists as it went through them and I was able to figure out which digest file was causing the problem and after moving it out of the way the senddigests script finished. Any ideas? I have the goofy digest file if that helps. Dallas From bscott at pps.k12.or.us Mon Jun 14 17:49:23 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Mon Jun 14 17:50:02 2004 Subject: [Mailman-Developers] Mailman menu items Message-ID: Hello, I asked this question last week. Someone said that it might be in the General.py file. I could not find it there. I was able to remove the right most column of menu items by changing some code in the admin.py Does anyone have any ideas on how I could remove some menu items in the first two columns. We would like to modify the menu options for Mailman. We would like to remove the Language Options Link and a few more. Can this be done? What file should be modify? Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us From maczilla at maczilla.org Mon Jun 14 18:50:37 2004 From: maczilla at maczilla.org (Jeff Barger) Date: Mon Jun 14 18:50:41 2004 Subject: [Mailman-Developers] Mailman menu items In-Reply-To: References: Message-ID: <40E0DDCE-BE55-11D8-BCEF-000A959666F6@maczilla.org> On Jun 14, 2004, at 5:49 PM, Bev Scott wrote: > We would like to modify the menu options for Mailman. We would like > to > remove the Language Options Link and a few more. > > Can this be done? > What file should be modify? Copy the 'ADMIN_CATEGORIES' variable from Defaults.py into your mm_cfg.py file and make the changes there. -Jeff From bscott at pps.k12.or.us Tue Jun 15 15:02:50 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Tue Jun 15 15:07:19 2004 Subject: [Mailman-Developers] Mailman menu items Message-ID: Hello, I figured out how to remove items from the Membership Management menu. That can be found in the Membership.py file. Now when the user select the Membership Management link, I would like to display the Mass subscription screen instead of the Membership List screen. Do you know where I can do that? Thanks for your help that worked. I have another question. Where do you remove sub menu items like Membership List under Membership Management. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us >>> Jeff Barger 6/14/2004 3:50:37 PM >>> On Jun 14, 2004, at 5:49 PM, Bev Scott wrote: > We would like to modify the menu options for Mailman. We would like > to > remove the Language Options Link and a few more. > > Can this be done? > What file should be modify? Copy the 'ADMIN_CATEGORIES' variable from Defaults.py into your mm_cfg.py file and make the changes there. -Jeff _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bscott%40pps.k12.or.us From bscott at pps.k12.or.us Tue Jun 15 12:07:48 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Tue Jun 15 16:33:13 2004 Subject: [Mailman-Developers] Mailman menu items Message-ID: Hello, Thanks for your help that worked. I have another question. Where do you remove sub menu items like Membership List under Membership Management. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us >>> Jeff Barger 6/14/2004 3:50:37 PM >>> On Jun 14, 2004, at 5:49 PM, Bev Scott wrote: > We would like to modify the menu options for Mailman. We would like > to > remove the Language Options Link and a few more. > > Can this be done? > What file should be modify? Copy the 'ADMIN_CATEGORIES' variable from Defaults.py into your mm_cfg.py file and make the changes there. -Jeff _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bscott%40pps.k12.or.us From maczilla at maczilla.org Tue Jun 15 12:18:21 2004 From: maczilla at maczilla.org (Jeff Barger) Date: Tue Jun 15 16:36:19 2004 Subject: [Mailman-Developers] Mailman menu items In-Reply-To: References: Message-ID: <9ED8E622-BEE7-11D8-A66B-000A959666F6@maczilla.org> On Jun 15, 2004, at 12:07 PM, Bev Scott wrote: > I have another question. Where do you remove sub menu items like > Membership List under Membership Management. I suppose you'd have to remove them directly from the files that make up the interface. You'd need to change the files every time you upgrade Mailman, so keep lots of notes on what you do to those files (and keep backups of the unaltered files, of course). But why on earth would you want to remove the Membership List screen? -Jeff From bscott at pps.k12.or.us Wed Jun 16 12:05:13 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Thu Jun 17 12:57:02 2004 Subject: [Mailman-Developers] Mailman menu items Message-ID: Hi, The adminstrators will add and remove people from the list. The system administrators will do the rest. I have given all of these argruments to my supervisors. They still want it their way. If it is possible how do I do it. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us >>> Jeff Barger 6/16/2004 8:57:53 AM >>> On Jun 16, 2004, at 11:50 AM, Bev Scott wrote: > Hi Jeff, > > We will have a separted set of tools for the systems administrators. > It is the list Adminstators that we don't want to see the membership > list screen. Then what will the list administrators even do? > Is it possible? Yes, of course it's possible. You'll have to keep track of all these changes yourself though, and carry them on to future versions. More than I would want to do. -Jeff From gsstark at mit.edu Thu Jun 17 14:36:39 2004 From: gsstark at mit.edu (Greg Stark) Date: Thu Jun 17 14:37:17 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values Message-ID: <87n03258w8.fsf@stark.xeocode.com> So the problem I described last January and again mentioned last September is still happening to me, and now to a lot more people. It will only become more and more prevalent as viruses become more common and sites that filter them become more common. Perhaps I should restate the problem more simply. Mailman is committing the basic sin of network security -- receiving data from the network and trusting it for purposes other than as opaque data. It is using messages posted to the list -- the content and format of which it does not control -- to detect bouncing email addresses. Because of this it cannot tell if the bounces it's receiving are caused by a broken email address or caused by some particularity of the posted message. Virus scans are only one type of bounce that could cause someone to be unsubscribed spuriously. For example, most mail servers have a maximum message size for example. Consider the security implications: all I have to do to mass unsubscribe many people--even everyone--on a list is send a message over 50k. Everyone using old versions of sendmail will be unsubscribed. A larger message will unsubscribe anyone using most modern MTAs. Nor do the tests that require multiple bounces protect anything; I just have to send my attack a few times quickly. Really Mailman should simply not trust outside data for any purpose. It should treat the bounces received from mailing list messages purely as hints. It should then send its *own* message with content not subject to any control from outside to the user. Only if that known inoffensive message bounces should it consider removing the user. This is really a DOS security issue, though the worst case attack is unsubscribing many users of a list. That it gets triggered normally even when not specifically under attack only makes the problem apparent. -------------- next part -------------- An embedded message was scrubbed... From: Greg Stark Subject: Re: Bounce removal parameters default values Date: 24 Sep 2003 11:57:39 -0400 Size: 3910 Url: http://mail.python.org/pipermail/mailman-developers/attachments/20040617/f32188f9/attachment.mht -------------- next part -------------- -- greg From barry at python.org Thu Jun 17 16:19:25 2004 From: barry at python.org (Barry Warsaw) Date: Thu Jun 17 17:07:15 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <87n03258w8.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> Message-ID: <1087503565.11378.73.camel@localhost> On Thu, 2004-06-17 at 14:36, Greg Stark wrote: > It is using messages posted to the list -- the content and format of which it > does not control -- to detect bouncing email addresses. Because of this it > cannot tell if the bounces it's receiving are caused by a broken email address > or caused by some particularity of the posted message. > Really Mailman should simply not trust outside data for any purpose. It should > treat the bounces received from mailing list messages purely as hints. It > should then send its *own* message with content not subject to any control > from outside to the user. Only if that known inoffensive message bounces > should it consider removing the user. Upgrade to Mailman 2.1.5, which sends out probe messages after the bounce threshold is reached. Members will only get disabled if the probe message bounces, it should be computationally infeasible to forge a probe bounce, and bogus probes bounces are simply ignored. When a probe is sent, the member's bounce score is reset to zero, since it's impossible to tell whether the probe actually reached its destination -- all you know is that it hasn't bounced... yet. -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/20040617/8bf89f02/attachment.bin From gsstark at mit.edu Thu Jun 17 17:28:37 2004 From: gsstark at mit.edu (Greg Stark) Date: Sun Jun 20 23:30:45 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: References: <87n03258w8.fsf@stark.xeocode.com> Message-ID: <87brjh6fi2.fsf@stark.xeocode.com> Brad Knowles writes: > At 2:36 PM -0400 2004-06-17, Greg Stark wrote: > > > Virus scans are only one type of bounce that could cause someone to be > > unsubscribed spuriously. For example, most mail servers have a maximum > > message > > size for example. Consider the security implications: all I have to do to > > mass > > unsubscribe many people--even everyone--on a list is send a message over 50k. > > Everyone using old versions of sendmail will be unsubscribed. A larger > > message > > will unsubscribe anyone using most modern MTAs. Nor do the tests that require > > multiple bounces protect anything; I just have to send my attack a few times > > quickly. That's one whacky line-wrap algorithm your MUA uses. > 50k?!? Where are you getting this number? Maximum message size on > most MTAs is usually a default of something like 1-10MB, or even unlimited. In > more than ten years of specializing in running mail systems, I don't think I > have *once* seen an MTA that was default configured to a maximum message size > of just 50k. Well I said what I meant, "old version of sendmail". 50k was indeed the standard maximum size for sendmail installs prior to MIME attachments and html-mail and all these new-fangled gadgets. I'm subscribed to plenty of mailing lists where attachments and html mail are severely discouraged so even today it wouldn't be out of place to refuse mail from these lists over 50k. > This is basically what Mailman is now doing. From the > Mailman-2.1.5/NEWS file: > > - The bounce processor has been redesigned so that now when an address's > bounce score reaches the threshold, that address will be sent a probe > message. Only if the probe bounces will the address be disabled. The > score is reset to zero when the probe is sent. Also, bounce events are > now kept in an event file instead of in memory. This should help > contain the bloat of the BounceRunner. Hum. Well, then, uh, great! :) Thanks. Now I just have to figure out why I'm still being dropped. I guess some of these mailing lists are old versions of mailman. This is version skew issue is going to be a big issue going forward. Users of mailing lists and ultimately any network service are at the mercy of the admins of every list they're on to upgrade. -- greg From kiko at async.com.br Fri Jun 18 19:38:42 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Sun Jun 20 23:36:43 2004 Subject: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html Message-ID: <20040618233842.GD5628@async.com.br> Hi there, Just a heads-up for bug 930819, which has a patch (two now) that adds onload form focus to the password entry in admlogin.html, a usability improvement for people using graphical browsers and maintaining many lists. https://sourceforge.net/tracker/?func=detail&atid=100103&aid=930819&group_id=103 The patch is small and quite low-impact. Would anybody be interested in reviewing it for inclusion in the mainline? You can see the changes live at: http://www.async.com.br/mailman/admin/kiwi Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From brad.knowles at skynet.be Thu Jun 17 16:37:21 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jun 20 23:54:30 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <87n03258w8.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> Message-ID: At 2:36 PM -0400 2004-06-17, Greg Stark wrote: > Virus scans are only one type of bounce that could cause someone to be > unsubscribed spuriously. For example, most mail servers have a >maximum message > size for example. Consider the security implications: all I have to >do to mass > unsubscribe many people--even everyone--on a list is send a message over 50k. > Everyone using old versions of sendmail will be unsubscribed. A >larger message > will unsubscribe anyone using most modern MTAs. Nor do the tests that require > multiple bounces protect anything; I just have to send my attack a few times > quickly. 50k?!? Where are you getting this number? Maximum message size on most MTAs is usually a default of something like 1-10MB, or even unlimited. In more than ten years of specializing in running mail systems, I don't think I have *once* seen an MTA that was default configured to a maximum message size of just 50k. > Really Mailman should simply not trust outside data for any >purpose. It should > treat the bounces received from mailing list messages purely as hints. It > should then send its *own* message with content not subject to any control > from outside to the user. Only if that known inoffensive message bounces > should it consider removing the user. > > This is really a DOS security issue, though the worst case attack is > unsubscribing many users of a list. That it gets triggered normally even when > not specifically under attack only makes the problem apparent. This is basically what Mailman is now doing. From the Mailman-2.1.5/NEWS file: - The bounce processor has been redesigned so that now when an address's bounce score reaches the threshold, that address will be sent a probe message. Only if the probe bounces will the address be disabled. The score is reset to zero when the probe is sent. Also, bounce events are now kept in an event file instead of in memory. This should help contain the bloat of the BounceRunner. New supporting variables in Defaults.py: VERP_PROBE_FORMAT, VERP_PROBE_REGEXP REGISTER_BOUNCES_EVERY is promoted to a Defaults.py variable. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brad.knowles at skynet.be Thu Jun 17 18:06:04 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jun 20 23:58:12 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <87brjh6fi2.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> <87brjh6fi2.fsf@stark.xeocode.com> Message-ID: At 5:28 PM -0400 2004-06-17, Greg Stark wrote: > Well I said what I meant, "old version of sendmail". 50k was indeed the > standard maximum size for sendmail installs prior to MIME attachments and > html-mail and all these new-fangled gadgets. Just how old are we talking here? Going back to the very early 90's (before version 8), there was no default maximum message size. I'd have to check, but I'm not even sure that there was an option to set the maximum message size at that time -- I don't think there were enough single-letter options left. > I'm subscribed to plenty of mailing lists where attachments and html mail are > severely discouraged so even today it wouldn't be out of place to refuse mail > from these lists over 50k. Ahh, now that's a different matter. That's the setting on the mailing list, and most likely not all mailing lists on that server have the same setting. Most likely, the MTA is not set to the same value as the mailing list, and if it was then you'd be able to get in and back out cleanly. Once out, you'd only have problems if your message size was below the maximum set by the list but above the maximum allowed by most recipients, which is highly unlikely. > Now I just have to figure out why I'm still being dropped. > I guess some of these mailing lists are old versions of mailman. Could be. What's in the logs? > This is version skew issue is going to be a big issue going forward. Users of > mailing lists and ultimately any network service are at the mercy of the > admins of every list they're on to upgrade. Yup. Not much we can do about that. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From jwt at onjapan.net Sat Jun 19 01:50:24 2004 From: jwt at onjapan.net (Jim Tittsler) Date: Mon Jun 21 00:15:14 2004 Subject: [Mailman-Developers] Mailman menu items In-Reply-To: References: Message-ID: <8F2FDE8F-C1B4-11D8-A67E-0003936A9B5C@onjapan.net> On Jun 17, 2004, at 01:05, Bev Scott wrote: > The adminstrators will add and remove people from the list. > The system administrators will do the rest. If you want all of your lists to behave this way, you could: - comment out the 'list' entry in Mailman/Gui/Membership.py - change Mailman/Cgi/admin.py so that if the category is 'members' the subcategory must be either 'add' or 'remove' (and defaults to 'add') - remove (or change) Mailman/Commands/cmd_who.py to prevent mail access (And then be sure to register your changes in your favorite version control system so that you can easily redo them with each Mailman update.) To do it on a list-by-list basis, you can do the first two things in an extend.py module in the list's directory... but I'm not sure how to intercept the mail command there. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From claw at kanga.nu Sat Jun 19 10:20:35 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jun 21 00:36:02 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: Message from Greg Stark of "17 Jun 2004 14:36:39 EDT." <87n03258w8.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> Message-ID: <12904.1087654835@kanga.nu> On 17 Jun 2004 14:36:39 -0400 Greg Stark wrote: > Really Mailman should simply not trust outside data for any > purpose. It should treat the bounces received from mailing list > messages purely as hints. It should then send its *own* message with > content not subject to any control from outside to the user. Only if > that known inoffensive message bounces should it consider removing the > user. In the absence of VERP this is far more difficult than it at first seems. The simple question becomes, even in the presence of a customised test message, how do you recognise a bounce for that particular message vs others? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Sat Jun 19 10:22:59 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jun 21 00:36:16 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: Message from Barry Warsaw of "Thu, 17 Jun 2004 16:19:25 EDT." <1087503565.11378.73.camel@localhost> References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> Message-ID: <13096.1087654979@kanga.nu> On Thu, 17 Jun 2004 16:19:25 -0400 Barry Warsaw wrote: > Upgrade to Mailman 2.1.5, which sends out probe messages after the > bounce threshold is reached. Members will only get disabled if the > probe message bounces, it should be computationally infeasible to > forge a probe bounce, and bogus probes bounces are simply ignored. > When a probe is sent, the member's bounce score is reset to zero, > since it's impossible to tell whether the probe actually reached its > destination -- all you know is that it hasn't bounced... yet. Does 2.1.5 formally require plus addressing support in the MTA? I thought that was still optional if you didn't use any of the VERPish supports. Without plus addressing properly catching the bounce as unique is the same tarbaby. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From gsstark at mit.edu Sun Jun 20 20:56:39 2004 From: gsstark at mit.edu (Greg Stark) Date: Mon Jun 21 01:16:36 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <12904.1087654835@kanga.nu> References: <87n03258w8.fsf@stark.xeocode.com> <12904.1087654835@kanga.nu> Message-ID: <87isdl3f08.fsf@stark.xeocode.com> J C Lawrence writes: > On 17 Jun 2004 14:36:39 -0400 > Greg Stark wrote: > > In the absence of VERP this is far more difficult than it at first > seems. The simple question becomes, even in the presence of a > customised test message, how do you recognise a bounce for that > particular message vs others? Well of course that's what VERP was invented for after all. -- greg From claw at kanga.nu Sun Jun 20 23:03:41 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jun 21 01:22:12 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: Message from Greg Stark of "20 Jun 2004 20:56:39 EDT." <87isdl3f08.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> <12904.1087654835@kanga.nu> <87isdl3f08.fsf@stark.xeocode.com> Message-ID: <5614.1087787021@kanga.nu> On 20 Jun 2004 20:56:39 -0400 Greg Stark wrote: > J C Lawrence writes: >> On 17 Jun 2004 14:36:39 -0400 Greg Stark wrote: >> In the absence of VERP this is far more difficult than it at first >> seems. The simple question becomes, even in the presence of a >> customised test message, how do you recognise a bounce for that >> particular message vs others? > Well of course that's what VERP was invented for after all. The problem there is that many ISPs and colocation facilities don't and won't support VERP. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From Nigel.Metheringham at dev.intechnology.co.uk Mon Jun 21 04:20:41 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon Jun 21 04:24:09 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <1087503565.11378.73.camel@localhost> References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> Message-ID: <1087806040.3192.4.camel@angua.localnet> On Thu, 2004-06-17 at 21:19, Barry Warsaw wrote: > Upgrade to Mailman 2.1.5, which sends out probe messages after the > bounce threshold is reached. Members will only get disabled if the > probe message bounces, it should be computationally infeasible to forge > a probe bounce, and bogus probes bounces are simply ignored. When a > probe is sent, the member's bounce score is reset to zero, since it's > impossible to tell whether the probe actually reached its destination -- > all you know is that it hasn't bounced... yet. It will be interesting to see how this works in practice against one pathological bouncer I have on the exim list... Approximately one message in 10 (by volume - I can't match the bounces to any particular message) generates a bounce which has no useful information in it at all. The exim.org box is still running Mailman 2.0.x (very old box - about to be replaced with something with a better than clockwork CPU) so I can't do generic VERP , but VERP probes have failed to establish the link to the original address on the list... I am now wondering if someone is just sending me random bounces for the hell of it.... Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry at python.org Tue Jun 22 14:27:32 2004 From: barry at python.org (Barry Warsaw) Date: Tue Jun 22 14:27:36 2004 Subject: [Mailman-Developers] Re: [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <87brjh6fi2.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> <87brjh6fi2.fsf@stark.xeocode.com> Message-ID: <40D87A14.50107@python.org> Greg Stark wrote: > This is version skew issue is going to be a big issue going forward. Users of > mailing lists and ultimately any network service are at the mercy of the > admins of every list they're on to upgrade. Short of some elaborate Microsoft/Semantic-scale auto-upgrade machinery, I don't know how to solve that particular problem. ;) -Barry From barry at python.org Tue Jun 22 14:29:59 2004 From: barry at python.org (Barry Warsaw) Date: Tue Jun 22 14:30:15 2004 Subject: [Mailman-Developers] Re: [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <87brjh6fi2.fsf@stark.xeocode.com> References: <87n03258w8.fsf@stark.xeocode.com> <87brjh6fi2.fsf@stark.xeocode.com> Message-ID: Greg Stark wrote: > This is version skew issue is going to be a big issue going forward. Users of > mailing lists and ultimately any network service are at the mercy of the > admins of every list they're on to upgrade. Short of some elaborate Microsoft/Semantic-scale auto-upgrade machinery, I have no idea how to solve that particular problem. ;) -Barry From barry at python.org Tue Jun 22 14:34:17 2004 From: barry at python.org (Barry Warsaw) Date: Tue Jun 22 14:41:52 2004 Subject: [Mailman-Developers] Re: senddigests problem In-Reply-To: <99EDB3CC-B9B8-11D8-8FC1-000A95AA76E0@dreamhost.com> References: <99EDB3CC-B9B8-11D8-8FC1-000A95AA76E0@dreamhost.com> Message-ID: Dallas Bethune wrote: > I made it print out the lists as it went through them and I was able to > figure out which digest file was causing the problem and after moving it > out of the way the senddigests script finished. > > Any ideas? I have the goofy digest file if that helps. This is going to be caused by a bug in the email package most likely. See if you can narrow it down to the particular message in the digest that's causing the problem, and then submit a bug report to the Python project: https://sourceforge.net/tracker/?group_id=5470&atid=105470 -Barry From barry at python.org Tue Jun 22 14:49:28 2004 From: barry at python.org (Barry Warsaw) Date: Tue Jun 22 14:49:57 2004 Subject: [Mailman-Developers] Re: What about bug #880073? In-Reply-To: References: Message-ID: J?rgen A. Erhard wrote: > > PS: This bug is *extremely* annoying, since suddenly all the 2.1.4 > using lists end up in my main folder, instead of the folders they > belong to. And just when xiph.org have seen the light and made the > switch to Mailman... The patch (sans the line length change) seems simple enough, so it will likely make it into 2.1.6. -Barry From brad.knowles at skynet.be Wed Jun 23 18:46:09 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed Jun 23 18:46:44 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <13096.1087654979@kanga.nu> References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> <13096.1087654979@kanga.nu> Message-ID: At 10:22 AM -0400 2004-06-19, J C Lawrence wrote: > Does 2.1.5 formally require plus addressing support in the MTA? That's only required if you let the MTA generate the VERP. > I > thought that was still optional if you didn't use any of the VERPish > supports. If the client generates the VERP, the MTA should pass that through unchanged. At that point, a string-up-to-@ should be a string-up-to-@. I've used this on installations I've done, and I have not done anything special with the MTAs to configure them for VERP support. What they provided out-of-the-box has worked just fine. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From claw at kanga.nu Wed Jun 23 20:21:14 2004 From: claw at kanga.nu (J C Lawrence) Date: Wed Jun 23 20:21:19 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: Message from Brad Knowles of "Thu, 24 Jun 2004 00:46:09 +0200." References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> <13096.1087654979@kanga.nu> Message-ID: <3177.1088036474@kanga.nu> On Thu, 24 Jun 2004 00:46:09 +0200 Brad Knowles wrote: > At 10:22 AM -0400 2004-06-19, J C Lawrence wrote: >> Does 2.1.5 formally require plus addressing support in the MTA? > That's only required if you let the MTA generate the VERP. Not quite. It minimally requires plus addressing to be enabled in the MTA (assuming it supports it). >> I thought that was still optional if you didn't use any of the >> VERPish supports. > If the client generates the VERP, the MTA should pass that through > unchanged. At that point, a string-up-to-@ should be a > string-up-to-@. Right, modulo the plus address extension removal. > I've used this on installations I've done, and I have not done > anything special with the MTAs to configure them for VERP > support. What they provided out-of-the-box has worked just fine. I'm not familiar with the various common MTAs current OTB configuration. When last I checked (year+ ago) most didn't enable plus addressing support by default. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brad.knowles at skynet.be Thu Jun 24 06:00:07 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jun 24 06:31:36 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <5614.1087787021@kanga.nu> References: <87n03258w8.fsf@stark.xeocode.com> <12904.1087654835@kanga.nu> <87isdl3f08.fsf@stark.xeocode.com> <5614.1087787021@kanga.nu> Message-ID: At 11:03 PM -0400 2004-06-20, J C Lawrence wrote: >> Well of course that's what VERP was invented for after all. > > The problem there is that many ISPs and colocation facilities don't and > won't support VERP. If you're a transit MTA, then whether or not VERP was used to create the envelope sender address should not matter -- you should just pass the string you were given. If you're the target MTA, you don't need to worry about VERP because it's only used on the sender address, not the recipient -- so plus detail is not there. The VERP stuff only comes into play if there is a bounce that is generated, and then the only MTA that needs to do anything with it is the original sending system. Even then, the MTA doesn't actually do anything with it, it just passes everything to Mailman. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brad.knowles at skynet.be Thu Jun 24 06:10:29 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jun 24 06:32:11 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <3177.1088036474@kanga.nu> References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> <13096.1087654979@kanga.nu> <3177.1088036474@kanga.nu> Message-ID: At 8:21 PM -0400 2004-06-23, J C Lawrence wrote: > Not quite. It minimally requires plus addressing to be enabled in the > MTA (assuming it supports it). Only if the MTA in question is receiving a VERPed recipient address. Mailman will never generate that kind of address (although users could subscribe with addresses of that form, but this is a separate matter), and will handle the generation of the VERPed envelope sender address itself. The only time the VERPed address comes into play is if there is a bounce generated to the envelope sender address that is created by Mailman, and even then it's just a matter of having the MTA pass everything it gets to mailman. > I'm not familiar with the various common MTAs current OTB configuration. > When last I checked (year+ ago) most didn't enable plus addressing > support by default. You might want to check again. I haven't seen any such problems on the Mailman lists I've been managing for a couple of years. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From somuchfun at atlantismail.com Thu Jun 24 06:44:32 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Thu Jun 24 06:44:40 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <1087806040.3192.4.camel@angua.localnet> Message-ID: <000b01c459d8$3ec67ce0$cb00a8c0@internal.westbay.net> This new VERP probe is ridiculous. One of my customer on a cpanel system had thousands of unsubscribes because of it. Why? Cpanel does not support in its current default exim setting VERP and there was no need for it because it is not on by default in mailman. Now out of the blue it is used even though VERP is turned off in mm_mfg.py And since this mailman VERP probe is unforgiving it unsubscribes right away! Not a good thing at all and the complaints from customers are coming in big time........ > -----Original Message----- > From: Nigel Metheringham > [mailto:Nigel.Metheringham@dev.intechnology.co.uk] > Sent: Monday, June 21, 2004 1:21 AM > To: Barry Warsaw > Cc: mailman-developers > Subject: Re: [Mailman-Developers] [Greg Stark > ] Re: Bounceremoval parameters default values > > > On Thu, 2004-06-17 at 21:19, Barry Warsaw wrote: > > Upgrade to Mailman 2.1.5, which sends out probe messages after the > > bounce threshold is reached. Members will only get disabled if the > > probe message bounces, it should be computationally infeasible to > > forge a probe bounce, and bogus probes bounces are simply ignored. > > When a probe is sent, the member's bounce score is reset to zero, > > since it's impossible to tell whether the probe actually > reached its > > destination -- all you know is that it hasn't bounced... yet. > > It will be interesting to see how this works in practice > against one pathological bouncer I have on the exim list... > Approximately one message in 10 (by volume - I can't match > the bounces to any particular message) generates a bounce > which has no useful information in it at all. The exim.org > box is still running Mailman 2.0.x (very old box - about to > be replaced with something with a better than clockwork CPU) > so I can't do generic VERP , but VERP probes have failed to > establish the link to the original address on the list... I > am now wondering if someone is just sending me random bounces > for the hell of it.... > > Nigel. > -- > [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] > [ - Comments in this message are my own and not ITO opinion/policy - ] > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailma> n-developers > > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/somu chfun%40atlantismail.com From claw at kanga.nu Thu Jun 24 08:45:05 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jun 24 08:45:11 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: Message from Brad Knowles of "Thu, 24 Jun 2004 12:10:29 +0200." References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> <13096.1087654979@kanga.nu> <3177.1088036474@kanga.nu> Message-ID: <25826.1088081105@kanga.nu> On Thu, 24 Jun 2004 12:10:29 +0200 Brad Knowles wrote: > At 8:21 PM -0400 2004-06-23, J C Lawrence wrote: > The only time the VERPed address comes into play is if there is a > bounce generated to the envelope sender address that is created by > Mailman, and even then it's just a matter of having the MTA pass > everything it gets to mailman. Almost. The delivery MTA in question has to recognise that list-bounces+claw=kanga.nu@kanga.nu is really the same as: list-bounces@kanga.nu and hand off appropriately. To do this the target MTA requires plus addressing support. Heck, that generic ability to distinguish and do that mapping is the definition of "plus addressing support in an MTA". -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Thu Jun 24 08:56:09 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jun 24 08:56:15 2004 Subject: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html In-Reply-To: Message from Christian Robottom Reis of "Fri, 18 Jun 2004 20:38:42 -0300." <20040618233842.GD5628@async.com.br> References: <20040618233842.GD5628@async.com.br> Message-ID: <26726.1088081769@kanga.nu> On Fri, 18 Jun 2004 20:38:42 -0300 Christian Robottom Reis wrote: > Just a heads-up for bug 930819, which has a patch (two now) that adds > onload form focus to the password entry in admlogin.html, a usability > improvement for people using graphical browsers and maintaining many > lists. +1 -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From tfheen at raw.no Thu Jun 24 10:56:18 2004 From: tfheen at raw.no (Tollef Fog Heen) Date: Thu Jun 24 10:57:33 2004 Subject: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html In-Reply-To: <20040618233842.GD5628@async.com.br> References: <20040618233842.GD5628@async.com.br> Message-ID: <20040624145618.GF17341@yiwaz.raw.no> * Christian Robottom Reis | The patch is small and quite low-impact. Would anybody be interested in | reviewing it for inclusion in the mainline? FWIW, it's already part of the Debian unstable package and will be in the next stable release. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From foobar at eh.net Thu Jun 24 16:17:38 2004 From: foobar at eh.net (foobar@eh.net) Date: Thu Jun 24 16:12:58 2004 Subject: [Mailman-Developers] Mailman throwing lost-datafile errors with every message Message-ID: Jun 24 15:49:39 2004 (353) lost data files for filebase: 1088100914.7161551+9a9200d2cba7be877a02453e1f812069b0c78761 Mailman 2.1.2 (I'll upgrade if you INSIST...) Python 2.2 SunOS eh.net 5.7 Generic_106541-24 sun4u sparc SUNW,Ultra-5_10 I've been getting this line thrown in my error logfile frequently. Additionally, mailman has about 1200 files open when the (aging) computer locks up after taking quite a bit of abuse (it tends to end up with the CPU at 100% iowait, out of swap, with more processes running than is healthy. (The machine only has 256 megabytes of RAM-- and the replacement server was initially due to arrive over a month ago, but Hewlett-Packard has delayed that date to about a month from now). I've seen this question asked before somewhere in the archives ( http://www.mail-archive.com/mailman-developers@python.org/msg06528.html ) but the (very limited) answer does not seem to have helped. From carson at taltos.org Thu Jun 24 16:41:38 2004 From: carson at taltos.org (Carson Gaspar) Date: Thu Jun 24 16:41:47 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounce removal parameters default values In-Reply-To: <3177.1088036474@kanga.nu> References: <87n03258w8.fsf@stark.xeocode.com> <1087503565.11378.73.camel@localhost> <13096.1087654979@kanga.nu> <3177.1088036474@kanga.nu> Message-ID: <38AB958CF06754A445B2A3D5@taltos.ny.ficc.gs.com> --On Wednesday, June 23, 2004 20:21:14 -0400 J C Lawrence wrote: > On Thu, 24 Jun 2004 00:46:09 +0200 > Brad Knowles wrote: >> At 10:22 AM -0400 2004-06-19, J C Lawrence wrote: >> If the client generates the VERP, the MTA should pass that through >> unchanged. At that point, a string-up-to-@ should be a >> string-up-to-@. > > Right, modulo the plus address extension removal. Nope. Not if you configure the MTA to use Berkeley DB for aliases, and you maintain the VERP aliases in the DB. It _is_ possible. It's more work than standard MTA supported VERP, but it is doable. -- Carson From claw at kanga.nu Thu Jun 24 22:12:46 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jun 24 22:15:30 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: Message from "Somuchfun" of "Thu, 24 Jun 2004 03:44:32 PDT." <000b01c459d8$3ec67ce0$cb00a8c0@internal.westbay.net> References: <000b01c459d8$3ec67ce0$cb00a8c0@internal.westbay.net> Message-ID: <26167.1088129566@kanga.nu> On Thu, 24 Jun 2004 03:44:32 -0700 somuchfun wrote: > This new VERP probe is ridiculous. One of my customer on a cpanel > system had thousands of unsubscribes because of it. Why? Cpanel does > not support in its current default exim setting VERP and there was no > need for it because it is not on by default in mailman. Now out of the > blue it is used even though VERP is turned off in mm_mfg.py And since > this mailman VERP probe is unforgiving it unsubscribes right away! > Not a good thing at all and the complaints from customers are coming > in big time........ So you deployed a new software into production without first making there were no negative impacts? Nice QC there. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From somuchfun at atlantismail.com Fri Jun 25 04:14:24 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Fri Jun 25 04:14:32 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <26167.1088129566@kanga.nu> Message-ID: <003101c45a8c$70121110$cb00a8c0@internal.westbay.net> Oh, we did test it for a while but this is the kind of problem that you do not encounter lightly in a test environment. And on top it would have helped if the mailman dev team would have published this major change in bounce processing! > -----Original Message----- > From: J C Lawrence [mailto:claw@kanga.nu] > Sent: Thursday, June 24, 2004 7:13 PM > To: Somuchfun > Cc: mailman-developers@python.org; 'Nigel Metheringham' > Subject: Re: [Mailman-Developers] [Greg Stark > ] Re: Bounceremoval parameters default values > > > On Thu, 24 Jun 2004 03:44:32 -0700 > somuchfun wrote: > > > This new VERP probe is ridiculous. One of my customer on a cpanel > > system had thousands of unsubscribes because of it. Why? > Cpanel does > > not support in its current default exim setting VERP and > there was no > > need for it because it is not on by default in mailman. Now > out of the > > blue it is used even though VERP is turned off in mm_mfg.py > And since > > this mailman VERP probe is unforgiving it unsubscribes > right away! Not > > a good thing at all and the complaints from customers are coming in > > big time........ > > So you deployed a new software into production without first > making there were no negative impacts? Nice QC there. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > claw@kanga.nu He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > From brad.knowles at skynet.be Fri Jun 25 04:30:18 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Jun 25 05:26:08 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <000b01c459d8$3ec67ce0$cb00a8c0@internal.westbay.net> References: <000b01c459d8$3ec67ce0$cb00a8c0@internal.westbay.net> Message-ID: At 3:44 AM -0700 2004-06-24, Somuchfun wrote: > This new VERP probe is ridiculous. [ ... deletia ... ] > Not a good thing at all and the complaints from customers are coming in > big time........ As JC correctly said (mea culpa), it does require support from the MTA. If your MTA doesn't support plus detail, then that would be a problem. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brad.knowles at skynet.be Fri Jun 25 04:42:31 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Jun 25 05:26:12 2004 Subject: [Mailman-Developers] Mailman throwing lost-datafile errors with every message In-Reply-To: References: Message-ID: At 4:17 PM -0400 2004-06-24, foobar@eh.net wrote: > Jun 24 15:49:39 2004 (353) lost data files for filebase: > 1088100914.7161551+9a9200d2cba7be877a02453e1f812069b0c78761 > > Mailman 2.1.2 (I'll upgrade if you INSIST...) > Python 2.2 > SunOS eh.net 5.7 Generic_106541-24 sun4u sparc SUNW,Ultra-5_10 Upgrading to 2.1.5 may help solve this problem. Certainly, this is one of the issues that Barry mentioned in his message at . However, before you do that, you might want to try Barry's other suggestion in this message, namely to enable SYNC_AFTER_WRITE. It may (or may not) kill your performance, but it may help you avoid these errors. Out of curiosity, have you added the "logging" option to your filesystem mount where you process mail? My experience is that this helps improve the performance of systems running Solaris 7 and above, and will greatly reduce/eliminate your time to run fsck when you're booting the system. Of course, replacing the filesystem with Veritas VxFS would be a bigger performance improvement, as would replacing the disk subsystem with an external high-performance RAID array, but these are not likely to be options you can take advantage of. > I've been getting this line thrown in my error logfile frequently. > Additionally, mailman has about 1200 files open when the (aging) computer > locks up after taking quite a bit of abuse (it tends to end up with the > CPU at 100% iowait, out of swap, with more processes running than is > healthy. (The machine only has 256 megabytes of RAM-- and the replacement > server was initially due to arrive over a month ago, but Hewlett-Packard > has delayed that date to about a month from now). If possible, you should increase the amount of swap on the system. You probably can't make any hardware upgrades in your current condition, but I'd be surprised if you can't add more swap space, even if the new swap space is not contiguous with the old. That might at least help you survive the problems a bit better. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brad.knowles at skynet.be Fri Jun 25 05:30:28 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Jun 25 05:32:31 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <003101c45a8c$70121110$cb00a8c0@internal.westbay.net> References: <003101c45a8c$70121110$cb00a8c0@internal.westbay.net> Message-ID: At 1:14 AM -0700 2004-06-25, Somuchfun wrote: > Oh, we did test it for a while but this is the kind of problem that you > do not encounter lightly in a test environment. And on top it would have > helped if the mailman dev team would have published this major change in > bounce processing! They did. Close to the top of the file mailman-2.1.5/NEWS is the following section: - The bounce processor has been redesigned so that now when an address's bounce score reaches the threshold, that address will be sent a probe message. Only if the probe bounces will the address be disabled. The score is reset to zero when the probe is sent. Also, bounce events are now kept in an event file instead of in memory. This should help contain the bloat of the BounceRunner. New supporting variables in Defaults.py: VERP_PROBE_FORMAT, VERP_PROBE_REGEXP REGISTER_BOUNCES_EVERY is promoted to a Defaults.py variable. If your MTA doesn't support VERP, then this should have been pretty obvious to you. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From S.W.Lay at ucles-red.cam.ac.uk Fri Jun 25 08:26:03 2004 From: S.W.Lay at ucles-red.cam.ac.uk (Steve Lay) Date: Fri Jun 25 08:26:50 2004 Subject: [Mailman-Developers] multipart/alternatives and Archive Scrubber behaviour Message-ID: MM 2.1.5 After complaints from some list members about the text of their messages going missing when viewed in the archives I've noticed some slightly undesirable behaviour in the scrubber module. The problem concerns people who regularly send multipart/alternative messages containing text/plain and text/html parts. The scrubbing policy for the site is correctly implemented for these people until the user decides to send an attachment. At that point the message becomes a multipart/mixed message containing two a multipart/alternative and some other attachment, typically application/msword or some such. The scrubber uses the "walk" method of an email message to find and scrub those hard-to-shift HTML stains but when the archiver page is generated in the second pass the scrubber uses the get_payload method instead. As a result, the scrubber never descends into the nested multipart/alternative part and doesn't display either the text of the message or a link to the HTML attachment (your results will vary depending on your site policy for the archiver). Is this a bug or is there a real reason why get_payload is used for the second stage of the scrubber process? Steve Lay From tkikuchi at is.kochi-u.ac.jp Fri Jun 25 09:33:44 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Jun 25 09:33:55 2004 Subject: [Mailman-Developers] multipart/alternatives and Archive Scrubber behaviour In-Reply-To: References: Message-ID: <40DC29B8.7010006@is.kochi-u.ac.jp> Hi, > The scrubber uses the "walk" method of an email message to find and scrub > those hard-to-shift HTML stains but when the archiver page is generated in > the second pass the scrubber uses the get_payload method instead. As a > result, the scrubber never descends into the nested multipart/alternative > part and doesn't display either the text of the message or a link to the > HTML attachment (your results will vary depending on your site policy for > the archiver). You are perfectly right. The fix has long been on the patch trackers: http://sourceforge.net/tracker/?func=detail&aid=891491&group_id=103&atid=300103 > Is this a bug or is there a real reason why get_payload is used for the > second stage of the scrubber process? Because Barry is too busy to review the accumulated patch. ;-) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From jbebel at ncsu.edu Mon Jun 28 16:55:33 2004 From: jbebel at ncsu.edu (Joel Ebel) Date: Mon Jun 28 16:55:45 2004 Subject: [Mailman-Developers] Transferring lists Message-ID: <40E085C5.70006@ncsu.edu> I'm in the process of transferring lists to a new server. The old server runs mailman 2.1.4, and the new one runs 2.1.5. I copied over the lists directory and the archives directory, and I ran update -f to update the lists. It seems to be working except for the fact that now the lists don't show up on the main listinfo page. Before they were listed publicly. How can I get this back? And is there anything else I'm missing in this process of moving lists? Thanks, Joel Ebel From bscott at pps.k12.or.us Mon Jun 28 17:37:37 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Mon Jun 28 17:38:04 2004 Subject: [Mailman-Developers] Jira text field Message-ID: Does anyone know how to make a text field in Jira read only or how to just display the information in the field. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us From bscott at pps.k12.or.us Mon Jun 28 17:55:03 2004 From: bscott at pps.k12.or.us (Bev Scott) Date: Mon Jun 28 17:55:31 2004 Subject: [Mailman-Developers] Jira text field Message-ID: Does anyone know how to make a text field in mailman read only or how to just display the information in the field. Bev Bev Scott Web Database Portland Public Schools 503-916-2000 4966 bscott@pps.k12.or.us _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bscott%40pps.k12.or.us From somuchfun at atlantismail.com Wed Jun 30 12:04:14 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Wed Jun 30 12:04:31 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: Message-ID: The issue is not whether it was obvious or not, the issue is that this new feature cannot even be turned off, just changed to a different format. Since there are many configurations out there that might not work with VERP I find introducing a feature that is on by default and that cannot be turned off causing more harm than doing good. ---------------------------------------- MANA TANGATA > -----Original Message----- > From: Brad Knowles [mailto:brad.knowles@skynet.be] > Sent: Friday, June 25, 2004 2:30 AM > To: Somuchfun > Cc: mailman-developers@python.org > Subject: RE: [Mailman-Developers] [Greg Stark > ] Re: Bounceremoval parameters default values > > At 1:14 AM -0700 2004-06-25, Somuchfun wrote: > > > Oh, we did test it for a while but this is the kind of > problem that you > > do not encounter lightly in a test environment. And on top > it would have > > helped if the mailman dev team would have published this > major change in > > bounce processing! > > They did. Close to the top of the file > mailman-2.1.5/NEWS is the > following section: > > - The bounce processor has been redesigned so that now > when an address's > bounce score reaches the threshold, that address will > be sent a probe > message. Only if the probe bounces will the address > be disabled. The > score is reset to zero when the probe is sent. Also, > bounce events are > now kept in an event file instead of in memory. This > should help > contain the bloat of the BounceRunner. > > New supporting variables in Defaults.py: VERP_PROBE_FORMAT, > VERP_PROBE_REGEXP > > REGISTER_BOUNCES_EVERY is promoted to a Defaults.py variable. > > > > If your MTA doesn't support VERP, then this should have been > pretty obvious to you. > > -- > Brad Knowles, > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > SAGE member since 1995. See for more info. > From claw at kanga.nu Wed Jun 30 19:18:31 2004 From: claw at kanga.nu (J C Lawrence) Date: Wed Jun 30 19:18:42 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: Message from "Somuchfun" of "Wed, 30 Jun 2004 09:04:14 PDT." Message-ID: <7012.1088637511@kanga.nu> On Wed, 30 Jun 2004 09:04:14 -0700 somuchfun wrote: > The issue is not whether it was obvious or not, the issue is that this > new feature cannot even be turned off, just changed to a different > format. Since there are many configurations out there that might not > work with VERP I find introducing a feature that is on by default and > that cannot be turned off causing more harm than doing good. Without disagreeing with your point: At some point Mailman ends up in the position of pushing technical standard adoption (such as the RFC 2369 List-* headers). No matter when the adoption decision is made someone will be unhappy. Plus addressing is not even close to new. I'm aware of no production MTAs that don't support plus-addressing. At what point should Mailman simply assume technical capability on the part of installation sites? Mailman already currently assumes a number of non-default things about the execution space, why not plus-addressing as well? When is the right time? Remember: You don't have to upgrade. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.