From marc_news@vasoftware.com Fri Mar 1 00:38:47 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 28 Feb 2002 16:38:47 -0800 Subject: [Mailman-Developers] mailman can't bounce messages or send notifications from sender filter In-Reply-To: <20020228220254.GU5066@merlins.org> References: <20020227213649.GQ5066@merlins.org> <15485.43894.935399.774981@anthem.wooz.org> <20020228220254.GU5066@merlins.org> Message-ID: <20020301003847.GC5066@merlins.org> On Thu, Feb 28, 2002 at 02:02:54PM -0800, Marc MERLIN wrote: > On Wed, Feb 27, 2002 at 11:00:54PM -0500, Barry A. Warsaw wrote: > > MM> I've changed GUI/GUIBase.py with the hopes to output a better > > MM> error: try: val = self._getValidValue(mlist, property, wtype, > > MM> val) except ValueError: doc.addError(_("Invalid value > > MM> '"+val+"' for variable: %(property)s"), tag=_('Error: ')) > > > > MM> Any ideas what's going on? > > > > Yup, it's a bug. Fixed in CVS. > > Sure enough, works much better now :-) > > In the meantime, I have more info on auto discard and auto reject > > auto discard / don't mail admin => works > auto discard / mail admin => doesn't work > reject / mail admin => doesn't work > reject / don't mail admin => doesn't work > > Basically, anything that triggers an Email, bombs with: Actually I missed the email-1.1 upgrade. I just installed that, and I seem to be getting errors in similar caes, but the error is now: ==> ../logs/error <== Feb 28 16:34:03 2002 (4404) Uncaught runner exception: Message main Content-Type: must be "multipart" or missing Feb 28 16:34:03 2002 (4404) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 114, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 162, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/IncomingRunner.py", line 113, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/var/local/mailman/Mailman/Queue/IncomingRunner.py", line 151, in _dopipeline mlist.BounceMessage(msg, msgdata, e) File "/var/local/mailman/Mailman/Bouncer.py", line 233, in BounceMessage bmsg.add_payload(MIMEMessage(msg)) File "/var/local/mailman/pythonlib/email/Message.py", line 115, in add_payload raise Errors.MultipartConversionError( MultipartConversionError: Message main Content-Type: must be "multipart" or missing The message, saved in shunt shows nothing weird: ---------------------------------------------------------------------------- Date: Thu, 28 Feb 2002 16:33:58 -0800 From: Marc MERLIN To: test@svlug.org Subject: test 3 Message-ID: <20020301003358.GA5066@merlins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i ---------------------------------------------------------------------------- Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Fri Mar 1 00:45:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 19:45:11 -0500 Subject: [Mailman-Developers] mailman can't bounce messages or send notifications from sender filter References: <20020227213649.GQ5066@merlins.org> <15485.43894.935399.774981@anthem.wooz.org> <20020228220254.GU5066@merlins.org> <20020301003847.GC5066@merlins.org> Message-ID: <15486.53015.147352.128773@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Actually I missed the email-1.1 upgrade. I just installed MM> that, and I seem to be getting errors in similar caes I just fixed this in Mailman's cvs. I'm pretty much done with the last batch of checkins I had sitting around. -Barry From barry@zope.com Fri Mar 1 00:56:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 19:56:03 -0500 Subject: [Mailman-Developers] problem with VERP stuffing all the messages in one connection Message-ID: <15486.53667.511858.730038@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> When VERP is enabled, mailman apparently sends all the Emails MM> over one SMTP connection. Actually, I don't think it has anything to do with VERP. Won't normal delivery do the same thing? (I'm assuming you're not doing threaded delivery.) Looking at SMTPDirect.py it just creates the connection, spits all the chunks down the connection and then quits the connection. Are you really only seeing this for VERP deliveries? MM> Mailman needs a MAX_RCPT_PER_SMTP setting and close the SMTP MM> connection after sending that many messages, and open up a new MM> one. It probably ought to be something like SMTP_MAX_SESSIONS_PER_CONNECTION. -Barry From marc_news@vasoftware.com Fri Mar 1 03:21:41 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 28 Feb 2002 19:21:41 -0800 Subject: [Mailman-Developers] problem with VERP stuffing all the messages in one connection In-Reply-To: <15486.53667.511858.730038@anthem.wooz.org> References: <15486.53667.511858.730038@anthem.wooz.org> Message-ID: <20020301032141.GI18610@merlins.org> On Thu, Feb 28, 2002 at 07:56:03PM -0500, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN writes: > > MM> When VERP is enabled, mailman apparently sends all the Emails > MM> over one SMTP connection. > > Actually, I don't think it has anything to do with VERP. Won't normal > delivery do the same thing? (I'm assuming you're not doing threaded Nope, there are two things: 1) how many receipients in one Email (i.e. how many rcpt tos you sent per mail from). That's already an option in mailman 2) how many mail from/rcpt to/data you shove through one SMTP connection. That hasn't been an option so far, but since most configs are set to send at least 10 to 100 RCPT TOs per MAIL FROM, you typically end up sending less than 100 DATAs (at least that's apparently been my case so far). With VERP, I'm now hitting #2. A 500 user list generates a huge SMTP connection with 500 mail from/rcpt to/data. For exim, the default for smtp_accept_queue_per_connection is 10 (100 on my server), so after 10 batches in one connection (10 users with VERP or 1000 users with normal delivery and a batch size of 100), exim spools messages and leaves them to be picked up by the next qrunner, which may be run 15mn later. I'll definitely contribute exim documentation on how to tune the exim side (along with the updated directors and the exim 4 version of the directors), but I think we'd also kind of need: > It probably ought to be something like > SMTP_MAX_SESSIONS_PER_CONNECTION. Yep. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Fri Mar 1 03:52:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 22:52:12 -0500 Subject: [Mailman-Developers] Error: Invalid value '' for variable: accept_these_nonmembers References: <20020227213649.GQ5066@merlins.org> <15485.43894.935399.774981@anthem.wooz.org> <20020228220254.GU5066@merlins.org> Message-ID: <15486.64236.852385.74106@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Sure enough, works much better now :-) MM> In the meantime, I have more info on auto discard and auto MM> reject | auto discard / don't mail admin => works | auto discard / mail admin => doesn't work | reject / mail admin => doesn't work | reject / don't mail admin => doesn't work MM> Basically, anything that triggers an Email, bombs with: Okay, I think I've got these fixed now. Thanks. -Barry From barry@zope.com Fri Mar 1 03:59:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 22:59:01 -0500 Subject: [Mailman-Developers] wildcards in poster-without-approval References: <20020228000703.GA9317@jonas.server0.de> <15485.43978.621556.875458@anthem.wooz.org> <20020228114745.GA1204@jonas.server0.de> <20020228212643.GS5066@merlins.org> Message-ID: <15486.64645.928272.285883@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I'd rather Barry concentrate his time on 2.1. Me too! MM2.0.x is such stale code (in my brain) that it's basically got to be a showstopper or security bug to get fixed at this point. CVR> Agreed. Features go into new releases. They have to be very CVR> persuasively important to the universe to sidetrack 2.1 CVR> development. Security flaws? Patch. Serious bugs? Probably CVR> patch. New features? That's why we have new releases... With CVR> 2.1 well down the road, stopping and doing 2.0.9 is the wrong CVR> decision. All IMHO, of course. I'm just about ready to put a fork in MM2.1. The next release will be beta1 (maybe tomorrow). MM2.1's been over a year in the works at some point you've got to stop adding new features and kick it out the door or it'll never get done. Some folks favorite feature requests will just have to wait until 2.2 (or 3.0?). -Barry From barry@zope.com Fri Mar 1 04:01:09 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 23:01:09 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15484.11049.568205.119009@anthem.wooz.org> <20020228075259.70301.qmail@web14806.mail.yahoo.com> Message-ID: <15486.64773.930374.340688@anthem.wooz.org> >>>>> "PS" == Paul Schreiber writes: PS> Yes,, but you can encode the "mailto:" as well, like so: href="mailto:joe@aol.com">me PS> I would guess most spambots are pretty dumb, probably using a PS> silly regex like . This /is/ kind of interesting. Anybody want to write a patch? -Barry From barry@zope.com Fri Mar 1 04:25:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 23:25:24 -0500 Subject: [Mailman-Developers] gate_news still broken in 2.1b.. References: <200202252248.g1PMmUh18292@babylon5.cc.vt.edu> <5.1.0.14.2.20020226132320.03db2920@lennier.cc.vt.edu> <5.1.0.14.2.20020226160356.045700c0@lennier.cc.vt.edu> Message-ID: <15487.692.570286.891054@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Oh, BTW, simple typo in the admin pages. In the RJ> VARHELP=topics/topics_enabled, the sentence: "The body of the RJ> message can also be optionally scanned for Subject: and RJ> Keyword: headers" Keyword: should be "Keywords:", which bit me RJ> for a while, because, of course, *that* was the occurrence of RJ> the word (which is right two other places in the paragraph) RJ> that I focused on. RJ> Although, I'm thinking, either Keyword: or Keywords: out to to RJ> work. Especically since it'll usually be one keyword... Naw, Keywords: is standard and I don't think we need to support them both. I've fixed the typo. Thanks, -Barry From dm-temp-310102@nyc.rr.com Fri Mar 1 06:19:30 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Fri, 1 Mar 2002 01:19:30 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15486.64773.930374.340688@anthem.wooz.org> Message-ID: <001c01c1c0e9$0cb7a740$56296c42@damien> Hmm, Ill have a bash at it. Its better than no protection at all, and its easy enough to do. A function that resolves entities isnt hard to write though, heres one: rentity = re.compile(r"&(\w+);") rhashentity = re.compile(r"&#(\d+);") from htmlentitydefs import entitydefs #escapes entities of the form 'ϧ' and '&aaa;' into ascii strings def unentity(s): s = rentity.sub(lambda m: entitydefs.get(m.group(1), m.group()), s) s = rhashentity.sub(lambda m: chr(int(m.group(1))), s) It's a shame you cant define your own entities in html. > -----Original Message----- > From: Barry A. Warsaw [mailto:barry@zope.com] > Sent: Thursday, 28 February 2002 23:01 > To: Paul Schreiber > Cc: Damien Morton; mailman-developers@python.org > Subject: RE: [Mailman-Developers] Protecting email addresses > from spam harvesters > > > > >>>>> "PS" == Paul Schreiber writes: > > PS> Yes,, but you can encode the "mailto:" as well, like so: PS> > href="mailto:jo > 1;@aol.com">me > > PS> I would guess most spambots are pretty dumb, probably using a > PS> silly regex like . > > This /is/ kind of interesting. Anybody want to write a patch? > > -Barry > From Nigel.Metheringham@dev.InTechnology.co.uk Fri Mar 1 09:34:41 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 01 Mar 2002 09:34:41 +0000 Subject: [Mailman-Developers] problem with VERP stuffing all the messages in one connection In-Reply-To: <20020301032141.GI18610@merlins.org> References: <15486.53667.511858.730038@anthem.wooz.org> <20020301032141.GI18610@merlins.org> Message-ID: <1014975281.17392.10.camel@gaspode.localnet> [Copied to exim-users - really for Philip's comments. Cross-posted replies will probably end up irritating the moderators :-) ] On Fri, 2002-03-01 at 03:21, Marc MERLIN wrote: > Nope, there are two things: > 1) how many receipients in one Email (i.e. how many rcpt tos you sent per > mail from). That's already an option in mailman > 2) how many mail from/rcpt to/data you shove through one SMTP connection. > That hasn't been an option so far, but since most configs are set to send > at least 10 to 100 RCPT TOs per MAIL FROM, you typically end up sending > less than 100 DATAs (at least that's apparently been my case so far). > > With VERP, I'm now hitting #2. A 500 user list generates a huge SMTP > connection with 500 mail from/rcpt to/data. > For exim, the default for smtp_accept_queue_per_connection is 10 (100 on my > server), so after 10 batches in one connection (10 users with VERP or 1000 > users with normal delivery and a batch size of 100), exim spools messages > and leaves them to be picked up by the next qrunner, which may be run 15mn > later. Its a hard case here... you do really want that limit on exim for most stuff - otherwise you end up getting load averages that go sky high... Maybe the answer at present is to stop using that limit on exim but tune the load average limits so that if your box is thrashing you move to queue only (need to check *when* exim checks the load average). The ideal would be to add the "queue only after n message transactions" to be some form of acl so that you could apply a different policy for localhost as to the rest of the world. > I'll definitely contribute exim documentation on how to tune the exim side > (along with the updated directors and the exim 4 version of the directors), > but I think we'd also kind of need: > > > It probably ought to be something like > > SMTP_MAX_SESSIONS_PER_CONNECTION. which is probably the easiest route to solve... I'm undecided as to the theoretical "best" solution - all of this is compromises :-) Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry@zope.com Fri Mar 1 19:06:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 1 Mar 2002 14:06:31 -0500 Subject: [Mailman-Developers] Working on memory leaks Message-ID: <15487.53559.651311.809439@anthem.wooz.org> I've got some good leads on the memory leak problem in the qrunners in MM2.1. I'm seeing some very strange behavior. I'm going to try to hang out on the irc channel[1] in case anybody else is interested. -Barry irc.openprojects.net #mailman From dmick@utopia.West.Sun.COM Sat Mar 2 20:45:36 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Sat, 02 Mar 2002 12:45:36 -0800 Subject: [Mailman-Developers] Missing footers with latest CVS Message-ID: <3C8139F0.E810581A@utopia.west.sun.com> Installed latest CVS yesterday, and notice now that some posters are not getting footers added to their messages. I suspect the footer-add-based- on-language code is at fault, but I haven't had time to isolate a pattern yet. Anyway, consider this Distant Early Warning that that code isn't working for some otherwise-untroubled list members. From che@debian.org Sun Mar 3 02:03:34 2002 From: che@debian.org (Ben Gertzfield) Date: Sun, 03 Mar 2002 11:03:34 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <3C8139F0.E810581A@utopia.west.sun.com> (Dan Mick's message of "Sat, 02 Mar 2002 12:45:36 -0800") References: <3C8139F0.E810581A@utopia.west.sun.com> Message-ID: <87henyv24p.fsf@nausicaa.interq.or.jp> >>>>> "Dan" == Dan Mick writes: Dan> Installed latest CVS yesterday, and notice now that some Dan> posters are not getting footers added to their messages. I Dan> suspect the footer-add-based- on-language code is at fault, Dan> but I haven't had time to isolate a pattern yet. Anyway, Dan> consider this Distant Early Warning that that code isn't Dan> working for some otherwise-untroubled list members. Maybe it's working as intended? ;) Are they posting messages with a charset that is not the same as the mailing list's charset? The default charset is us-ascii; I will hazard a guess that they are posting messages flagged as UTF-8 or ISO-8859-1 but that are really us-ascii. We can add a work around for this, but it will be hard. Ben -- Brought to you by the letters V and Z and the number 18. "You have my pills!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From colin@mackinlay.demon.co.uk Sun Mar 3 12:50:13 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Sun, 3 Mar 2002 12:50:13 +0000 (GMT) Subject: [Mailman-Developers] Bug in email confirmation of subscription? Message-ID: This message is in MIME format. If you are reading this text, then your mail package doesn't fully support MIME - there may be a newer release available from your supplier. Created using the !Marcel mail package from ANT Ltd --570995-1574915967-1015159814=:1025186760 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII When new members subscribe to mailing lists on my CVS mailman installation they receive the usual message requiring confirmation. When replying to this message they are correctly added to the list of pending subscriptions for moderator approval but receive an error message which makes it look like a failure. I have attached the three relevant messages: plsconfirm (from mailman after a webpage subscription request) reply (sent by me) error (the message sent back from mailman) You can try this for yourself, the webpage is http://mackinlay.demon.co.uk/mailman/listinfo/test -- Colin Mackinlay --570995-1574915967-1015159814=:1025186760 Content-Type: TEXT/Plain; NAME=error Content-Transfer-Encoding: QUOTED-PRINTABLE Date: Sun, 03 Mar 2002 12:40:07 +0000 From: test-request@mackinlay.demon.co.uk Subject: Mailman results for Test To: colin@mackinlay.demon.co.uk This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address test-request@mackinlay.demon.co.uk. To obtain instructions on valid Mailman email commands, send email to test-request@mackinlay.demon.co.uk with the word "help" in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to test-admin@mackinlay.demon.co.uk. The following is a detailed description of the problems. ***** confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 Your request has been forwarded to the list moderator for approval. Command? On Sun 03 Mar, test-request@mackinlay.demon.co.uk wrote: Command? > Command? > Mailing list subscription confirmation notice for mailin... Command? > Command? > We have received a request from 192.168.0.2 for subscrip... >>>>>=20 >>>>> Too many errors encountered; the rest of the message is ignored: > > email address, "david@mackinlay.demon.co.uk", to the > > test@mackinlay.demon.co.uk mailing list. To confirm that you want to > > be added to this mailing list, simply reply to this message, keeping > > the Subject: header intact. Or visit this web page: > >=20 > > http://mackinlay.demon.co.uk/mailman/confirm/test/cbd699d455efb2d25= e579de92dfe34aa > > 5f5bb981 > >=20 > >=20 > > Or include the following line -- and only the following line -- in a > > message to test-request@mackinlay.demon.co.uk: > >=20 > > confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 > >=20 > > Note that simply sending a `reply' to this message should work from > > most mail readers, since that usually leaves the Subject: line in the > > right form (additional "Re:" text in the Subject: is okay). > >=20 > > If you do not wish to be subscribed from this list, please simply > > disregard this message. If you think you are being maliciously > > subscribed to the list, or have any other questions, send them to > > test-admin@mackinlay.demon.co.uk. > >=20 >=20 > --=20 > Colin Mackinlay >=20 --570995-1574915967-1015159814=:1025186760 Content-Type: TEXT/Plain; NAME=plsconfirm Content-Transfer-Encoding: QUOTED-PRINTABLE Date: Sun, 03 Mar 2002 12:38:53 +0000 From: test-request@mackinlay.demon.co.uk Subject: confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 To: david@mackinlay.demon.co.uk Mailing list subscription confirmation notice for mailing list Test We have received a request from 192.168.0.2 for subscription of your email address, "david@mackinlay.demon.co.uk", to the test@mackinlay.demon.co.uk mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://mackinlay.demon.co.uk/mailman/confirm/test/cbd699d455efb2d25e579= de92dfe34aa5f5bb981 Or include the following line -- and only the following line -- in a message to test-request@mackinlay.demon.co.uk: confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed from this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to test-admin@mackinlay.demon.co.uk. --570995-1574915967-1015159814=:1025186760 Content-Type: TEXT/Plain; NAME=reply Content-Transfer-Encoding: QUOTED-PRINTABLE Date: Sun, 3 Mar 2002 12:36:37 +0000 (GMT) From: Colin Mackinlay Subject: Re: confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 To: test-request@mackinlay.demon.co.uk On Sun 03 Mar, test-request@mackinlay.demon.co.uk wrote: >=20 > Mailing list subscription confirmation notice for mailing list Test >=20 > We have received a request from 192.168.0.2 for subscription of your > email address, "david@mackinlay.demon.co.uk", to the > test@mackinlay.demon.co.uk mailing list. To confirm that you want to > be added to this mailing list, simply reply to this message, keeping > the Subject: header intact. Or visit this web page: >=20 > http://mackinlay.demon.co.uk/mailman/confirm/test/cbd699d455efb2d25e5= 79de92dfe34aa > 5f5bb981 >=20 >=20 > Or include the following line -- and only the following line -- in a > message to test-request@mackinlay.demon.co.uk: >=20 > confirm cbd699d455efb2d25e579de92dfe34aa5f5bb981 >=20 > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). >=20 > If you do not wish to be subscribed from this list, please simply > disregard this message. If you think you are being maliciously > subscribed to the list, or have any other questions, send them to > test-admin@mackinlay.demon.co.uk. >=20 --=20 Colin Mackinlay --570995-1574915967-1015159814=:1025186760-- From jarrell@vt.edu Sun Mar 3 14:42:27 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 3 Mar 2002 09:42:27 -0500 (EST) Subject: [Mailman-Developers] password reminders on umbrella lists Message-ID: <200203031442.g23EgRL09101@babylon5.cc.vt.edu> On my test server I've got an umbrella list, which is set for "password reminders to owner" and "owner suffix is -owner". The only thing subscribed to is is a list that gates into a local newsgroup. Today (because the qrunner was stopped for the last couple of days) the newsgroup got a message posted to it - it was the note from the umbrella list, which, despite the umbrella settings, was sent to the member lists, not the list-owners, and which contained the password, which I rapidly changed after cancelling the article... Lucky it's a test list. This seems, oh, bad, to me... From marc_news@vasoftware.com Mon Mar 4 09:19:25 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 01:19:25 -0800 Subject: [Mailman-Developers] Do we need the password in the HTML of the confirm page? Message-ID: <20020304091924.GB9799@merlins.org> When I went to: http://gandalf-lists.merlins.org/lists/confirm/test2/372ff4ab4ca390f3c3bfabd47cd78e92489a0b5d (don't bother trying, it's localhost on my laptop :-D) I get an HTML page to confirm my subscription. I haven't looked at the code in details, but does mailman need to put the list password in cleartext in the HTML? (if the answer is "yes", then never mind) It's not the end of the world, but if someone puts my Email by mistake (one letter typo or something in a company), I can get his mailman password, and with a little luck that password could work in other places too (not that the person is supposed to use the same password, but...) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Mon Mar 4 10:25:09 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 02:25:09 -0800 Subject: [Mailman-Developers] Updated dupe removal patch Message-ID: <20020304102508.GF9799@merlins.org> --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It took all of my sunday, but I just finished porting Ben Gertzfield's excellent dupe removal patch to mailman cvs (I also had to learn some python in the process. I'm starting to believe that Mailman is a conspiracy to get people to learn python :-p) In a nutshell, the patch does two things: 1) it does not send you your list copy if - your subscribed Email address is already in the headers - you already received the message through another list (Cc accross two lists or more on the same site) 2) The new "nodupes" setting is really something you probably want as a default on all lists. I also had lists were people wanted notmetoo as a default too. Ben's fix for that is to have a bitfield per list that you can set and that states which options newly added users get. As Ben said, this breaks the one patch one functionality rule, but when I ported his work to mailman-cvs, I realized that it didn't make sense to take them apart. However, Barry, if that would stop you from merging #1 in CVS, I could remove it, but I'm not sure why one would want to. I've done reasonable tests to make sure I didn't break all of mailman in the process, and the core logic hasn't changed, so the basic functionality is the same that Ben had written and that has been used for 6-9mo? on the debian lists now. In other words, it should work (it does for me, and I'm already running it on my production mailman-cvs list server), but there is always the chance that there might be a corner case buglet left somewhere. Considering this was a pain to port, and how this puts to rest many of the reply-to munging discussions (the only real argument for reply-to munging is that it "solves" the duplicate mails you other receive when people use reply to all), I'm hoping that this could make it in (wink, wink :-D) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mailman.nodupes.diff" diff -urN mailman-cvs/Mailman/Cgi/admin.py mailman-cvs-nodupes/Mailman/Cgi/admin.py --- mailman-cvs/Mailman/Cgi/admin.py Sun Mar 3 14:29:16 2002 +++ mailman-cvs-nodupes/Mailman/Cgi/admin.py Sun Mar 3 17:09:38 2002 @@ -843,7 +843,7 @@ usertable.AddRow([Center(Italic(_('%(allcnt)s members total')))]) usertable.AddCellInfo(usertable.GetCurrentRowIndex(), usertable.GetCurrentCellIndex(), - colspan=10, + colspan=11, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) # Add the alphabetical links if bucket: @@ -861,17 +861,18 @@ usertable.AddRow([Center(joiner.join(cells))]) usertable.AddCellInfo(usertable.GetCurrentRowIndex(), usertable.GetCurrentCellIndex(), - colspan=10, + colspan=11, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) usertable.AddRow([Center(h) for h in (_('unsub'), _('member address
member name'), _('mod'), _('hide'), _('nomail
[reason]'), _('ack'), _('not metoo'), + _('nodupes'), _('digest'), _('plain'), _('language'))]) rowindex = usertable.GetCurrentRowIndex() - for i in range(10): + for i in range(11): usertable.AddCellInfo(rowindex, i, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) # Find the longest name in the list longest = 0 @@ -907,7 +908,7 @@ checked = 0 box = CheckBox('%s_mod' % addr, value, checked) cells.append(Center(box).Format()) - for opt in ('hide', 'nomail', 'ack', 'notmetoo'): + for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes'): extra = '' if opt == 'nomail': status = mlist.getDeliveryStatus(addr) @@ -984,6 +985,9 @@ _('''not metoo -- Does the member avoid copies of their own posts?''')) legend.AddItem( + _('''nodupes -- Does the member avoid duplicates of the same + message?''')) + legend.AddItem( _('''digest -- Does the member get messages in digests? (otherwise, individual messages)''')) legend.AddItem( @@ -1328,7 +1332,7 @@ mlist.setDeliveryStatus(user, MemberAdaptor.BYADMIN) else: mlist.setDeliveryStatus(user, MemberAdaptor.ENABLED) - for opt in ('hide', 'ack', 'notmetoo', 'plain'): + for opt in ('hide', 'ack', 'notmetoo', 'nodupes', 'plain'): opt_code = option_info[opt] if cgidata.has_key('%s_%s' % (user, opt)): mlist.setMemberOption(user, opt_code, 1) diff -urN mailman-cvs/Mailman/Cgi/options.py mailman-cvs-nodupes/Mailman/Cgi/options.py --- mailman-cvs/Mailman/Cgi/options.py Sun Mar 3 14:29:16 2002 +++ mailman-cvs-nodupes/Mailman/Cgi/options.py Sun Mar 3 17:50:46 2002 @@ -424,6 +424,7 @@ ('conceal', mm_cfg.ConcealSubscription), ('remind', mm_cfg.SuppressPasswordReminder), ('rcvtopic', mm_cfg.ReceiveNonmatchingTopics), + ('nodupes', mm_cfg.DontReceiveDuplicates), ): try: newval = int(cgidata.getvalue(item)) @@ -514,9 +515,18 @@ global_remind = newval break - if global_enable is not None or global_remind is not None: + global_nodupes = None + if cgidata.getvalue('nodupes-globally'): + for flag, newval in newvals: + if flag == mm_cfg.DontReceiveDuplicates: + global_nodupes = newval + break + + if (global_enable is not None or global_remind is not None + or global_nodupes is not None): for gmlist in lists_of_member(mlist, user): - global_options(gmlist, user, global_enable, global_remind) + global_options(gmlist, user, global_enable, global_remind, + global_nodupes) # Now print the results if cantdigest: @@ -591,6 +601,10 @@ mlist.FormatOptionButton(mm_cfg.ConcealSubscription, 0, user)) replacements[''] = mlist.FormatOptionButton( mm_cfg.ConcealSubscription, 1, user) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user)) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user)) replacements[''] = ( mlist.FormatButton('unsub', _('Unsubscribe')) + '
' + CheckBox('unsubconfirm', 1, checked=0).Format() + @@ -620,6 +634,8 @@ CheckBox('deliver-globally', 1, checked=0).Format()) replacements[''] = ( CheckBox('remind-globally', 1, checked=0).Format()) + replacements[''] = ( + CheckBox('nodupes-globally', 1, checked=0).Format()) days = int(mm_cfg.PENDING_REQUEST_LIFE / mm_cfg.days(1)) if days > 1: @@ -806,7 +822,7 @@ -def global_options(mlist, user, global_enable, global_remind): +def global_options(mlist, user, global_enable, global_remind, global_nodupes): def sigterm_handler(signum, frame, mlist=mlist): # Make sure the list gets unlocked... mlist.Unlock() @@ -827,6 +843,10 @@ if global_remind is not None: mlist.setMemberOption(user, mm_cfg.SuppressPasswordReminder, global_remind) + + if global_nodupes is not None: + mlist.setMemberOption(user, mm_cfg.DontReceiveDuplicates, + global_nodupes) mlist.Save() finally: diff -urN mailman-cvs/Mailman/Defaults.py.in mailman-cvs-nodupes/Mailman/Defaults.py.in --- mailman-cvs/Mailman/Defaults.py.in Sun Mar 3 14:42:08 2002 +++ mailman-cvs-nodupes/Mailman/Defaults.py.in Sun Mar 3 17:08:19 2002 @@ -399,6 +399,7 @@ 'Hold', 'Tagger', 'CalcRecips', + 'AvoidDuplicates', 'Cleanse', 'CookHeaders', # And now we send the message to the digest mbox file, and to the arch and @@ -658,6 +659,11 @@ 'privacy', 'bounce', 'archive', 'gateway', 'autoreply', 'topics', ] +# See "Bitfield for user options" below; make this a sum of those +# options, to make all new members of lists start with those options +# flagged. +# We assume by default that people don't want to receive two copies of posts +DEFAULT_LIST_OPTIONS = 256 ##### @@ -979,6 +985,7 @@ TEXTFIELDWIDTH = 40 # Bitfield for user options +# See DEFAULT_LIST_OPTIONS above to set defaults for all new lists Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() DontReceiveOwnPosts = 2 # Non-digesters only @@ -987,7 +994,8 @@ ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 -Moderate = 128 +Moderate = 128 +DontReceiveDuplicates = 256 # Authentication contexts. # diff -urN mailman-cvs/Mailman/Gui/GUIBase.py mailman-cvs-nodupes/Mailman/Gui/GUIBase.py --- mailman-cvs/Mailman/Gui/GUIBase.py Wed Feb 27 20:00:42 2002 +++ mailman-cvs-nodupes/Mailman/Gui/GUIBase.py Mon Mar 4 00:55:04 2002 @@ -22,6 +22,7 @@ from Mailman import mm_cfg from Mailman import Utils from Mailman import Errors +from Mailman import MailCommandHandler from Mailman.i18n import _ NL = '\n' @@ -117,36 +118,48 @@ continue # Unpack the gui item description property, wtype, args, deps, desc = item[0:5] - # BAW: I know this code is a little crufty but I wanted to - # reproduce the semantics of the original code in admin.py as - # closely as possible, for now. We can clean it up later. - # - # The property may be uploadable... - uploadprop = property + '_upload' - if cgidata.has_key(uploadprop) and cgidata[uploadprop].value: - val = cgidata[uploadprop].value - elif not cgidata.has_key(property): - return - elif isinstance(cgidata[property], ListType): - val = [x.value for x in cgidata[property]] - else: - val = cgidata[property].value - # Coerce the value to the expected type, raising exceptions if the - # value is invalid - try: - val = self._getValidValue(mlist, property, wtype, val) - except ValueError: - doc.addError(_('Invalid value for variable: %(property)s'), - tag=_('Error: ')) - return - # This is the parent of MMBadEmailError and MMHostileAddress - except Errors.EmailAddressError: - doc.addError( - _('Bad email address for option %(property)s: %(val)s'), - tag=_('Error: ')) - return - # Set the attribute, which will normally delegate to the mlist - self._setValue(mlist, property, val, doc) + + if property == 'default_options': + checked_defaults = cgidata.getvalue("default_options") + i = 0 + new_defaults = 0 + for opt in ("hide", "ack", "notmetoo", "plain", "nodupes"): + opt_code = MailCommandHandler.option_info[opt] + if `i` in checked_defaults: + new_defaults = new_defaults | opt_code + i = i + 1 + mlist.default_options = new_defaults + else: + # BAW: I know this code is a little crufty but I wanted to + # reproduce the semantics of the original code in admin.py as + # closely as possible, for now. We can clean it up later. + # + # The property may be uploadable... + uploadprop = property + '_upload' + if cgidata.has_key(uploadprop) and cgidata[uploadprop].value: + val = cgidata[uploadprop].value + elif not cgidata.has_key(property): + return + elif isinstance(cgidata[property], ListType): + val = [x.value for x in cgidata[property]] + else: + val = cgidata[property].value + # Coerce the value to the expected type, raising exceptions + # if the value is invalid + try: + val = self._getValidValue(mlist, property, wtype, val) + except ValueError: + doc.addError(_('Invalid value for variable: %(property)s'), + tag=_('Error: ')) + return + # This is the parent of MMBadEmailError and MMHostileAddress + except Errors.EmailAddressError: + doc.addError( + _('Bad email address for option %(property)s: %(val)s'), + tag=_('Error: ')) + return + # Set the attribute, which will normally delegate to the mlist + self._setValue(mlist, property, val, doc) # Convenience method for handling $-string attributes def _convertString(self, mlist, property, alloweds, val, doc): diff -urN mailman-cvs/Mailman/Gui/General.py mailman-cvs-nodupes/Mailman/Gui/General.py --- mailman-cvs/Mailman/Gui/General.py Sun Mar 3 14:29:17 2002 +++ mailman-cvs-nodupes/Mailman/Gui/General.py Sun Mar 3 20:01:15 2002 @@ -33,6 +33,22 @@ return None WIDTH = mm_cfg.TEXTFIELDWIDTH + # These are for the default_options checkboxes below. + # this should be set in a module somewhere.. + option_info = {'hide' : mm_cfg.ConcealSubscription, + 'ack' : mm_cfg.AcknowledgePosts, + 'notmetoo' : mm_cfg.DontReceiveOwnPosts, + 'plain' : mm_cfg.DisableMime, + 'nodupes' : mm_cfg.DontReceiveDuplicates + } + + options = ['hide', 'ack', 'notmetoo', 'plain', 'nodupes'] + option_values = [] + + for o in options: + option_values.append(mlist.default_options & option_info[o]) + + rtn = [ _('''Fundamental list characteristics, including descriptive info and basic behaviors.'''), @@ -237,6 +253,12 @@ _('''Turn this on if you want password reminders to be sent once per month to your members. Note that members may disable their own individual password reminders.''')), + + ('default_options', mm_cfg.Checkbox, (options, option_values, 1), + 0, _('''Default options for all members that join this list.'''), + + _('''This value is a bitfield that lets you set default options + for list subscribers.''')), ('welcome_msg', mm_cfg.Text, (4, WIDTH), 0, _('''List-specific text prepended to new-subscriber welcome diff -urN mailman-cvs/Mailman/HTMLFormatter.py mailman-cvs-nodupes/Mailman/HTMLFormatter.py --- mailman-cvs/Mailman/HTMLFormatter.py Wed Feb 20 21:51:57 2002 +++ mailman-cvs-nodupes/Mailman/HTMLFormatter.py Sun Mar 3 17:55:45 2002 @@ -116,6 +116,7 @@ mm_cfg.ConcealSubscription : 'conceal', mm_cfg.SuppressPasswordReminder : 'remind', mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic', + mm_cfg.DontReceiveDuplicates : 'nodupes', }[option] return '' % ( name, value, checked) diff -urN mailman-cvs/Mailman/Handlers/AvoidDuplicates.py mailman-cvs-nodupes/Mailman/Handlers/AvoidDuplicates.py --- mailman-cvs/Mailman/Handlers/AvoidDuplicates.py Wed Dec 31 16:00:00 1969 +++ mailman-cvs-nodupes/Mailman/Handlers/AvoidDuplicates.py Sun Mar 3 22:31:02 2002 @@ -0,0 +1,115 @@ +# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +"""If the user wishes it, do not send duplicates of the same message. + +This module keeps an in-memory dictionary of Message-ID and recipient +pairs. If a message with an identical Message-ID is about to be sent +to someone who has already received a copy, we either drop the message, +add a duplicate warning header, or pass it through, depending on the +user's preferences. +""" + +import string + +from Mailman import mm_cfg +from Mailman import Utils +from Mailman import Message +from Mailman import Errors +from Mailman.i18n import _ +from email.Utils import getaddresses + + + +class DuplicateDetected(Errors.DiscardMessage): + """The message would have been sent multiple times to a user who + prefers not to receive duplicates.""" + +# A dictionary of dictionaries, used to store which recipients have received +# which message IDs. +recip_msgids = {} + + + +def process(mlist, msg, msgdata): + + recips = msgdata['recips'] + msgid = msg.get('message-id') + + if not recips or not msgid: + return + + # This dictionary will hold recips who want their mail to have + # the X-Mailman-Duplicate: yes header. + if not msgdata.has_key('add-dupe-header'): + msgdata['add-dupe-header'] = {} + + external_recips = [] + for header in ('to', 'cc', 'resent-to', 'resent-cc'): + external_recips.extend(getaddresses(msg.get_all(header, []))) + + # Anyone mentioned in the to/cc/resent-to/resent-cc headers should + # not get a duplicate of the message. + for (name, email) in external_recips: + + # If getaddresses fails, email could be null. Skip those. + if not email: + continue + + # Initialize the external recipient's msgid hash if this is the + # first email they've received with this message-id. + if not recip_msgids.has_key(email): + recip_msgids[email] = {} + + # We don't do anything except record that that address has + # gotten or will get a copy of this email externally. + recip_msgids[email][msgid] = 1 + + newrecips = [] + + for r in recips: + if not recip_msgids.has_key(r): + recip_msgids[r] = {} + + # If they have received a message with this message-id already, + # see if they don't want duplicates. + if recip_msgids[r].has_key(msgid): + send_duplicate = 1 + + # If the member wants to receive duplicates, or if the recipient + # is not a member at all, just flag the X-Mailman-Duplicate: yes + # header. + try: + if mlist.getMemberOption(r, mm_cfg.DontReceiveDuplicates): + send_duplicate = 0 + except Errors.NotAMemberError: + pass + + # We'll send a duplicate unless the user doesn't wish it. + # If personalization is enabled, the add-dupe-header flag will + # add a X-Mailman-Duplicate: yes header for this user's message. + if send_duplicate: + msgdata['add-dupe-header'][r] = 1 + newrecips.append(r) + + else: + # Otherwise, this is the first time they've been in the recips + # list. Add them to the newrecips list and flag them as having + # received this message. + recip_msgids[r][msgid] = 1 + newrecips.append(r) + + msgdata['recips'] = newrecips diff -urN mailman-cvs/Mailman/Handlers/Personalize.py mailman-cvs-nodupes/Mailman/Handlers/Personalize.py --- mailman-cvs/Mailman/Handlers/Personalize.py Tue Nov 20 08:39:38 2001 +++ mailman-cvs-nodupes/Mailman/Handlers/Personalize.py Sun Mar 3 17:07:42 2002 @@ -45,6 +45,13 @@ msg['To'] = '%s (%s)' % (member, name) else: msg['To'] = member + # We can flag the mail as a duplicate for each member, if + # they've already received that message. (See AvoidDuplicates.py) + if msgdata['add-dupe-header'].has_key(member): + msg['X-Mailman-Duplicate'] = 'yes' + elif msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] + # See if we're taking the opportunity to VERP for more reliable bounce # processing. metadatacopy['verp'] = mm_cfg.VERP_PERSONALIZED_DELIVERIES @@ -52,6 +59,10 @@ # Restore the original To: line del msg['To'] msg['To'] = originalto + + # The original message is not a duplicate. + if msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] # Don't let the normal ToOutgoing processing actually send the original # copy, otherwise we'll get duplicates. del msgdata['recips'] diff -urN mailman-cvs/Mailman/MailCommandHandler.py mailman-cvs-nodupes/Mailman/MailCommandHandler.py --- mailman-cvs/Mailman/MailCommandHandler.py Sun Mar 3 14:29:16 2002 +++ mailman-cvs-nodupes/Mailman/MailCommandHandler.py Sun Mar 3 16:28:01 2002 @@ -80,12 +80,20 @@ you get digests in MIME format, which are much better if you have a mail reader that supports MIME.""") -option_desc = {'hide' : HIDE, - 'nomail' : NOMAIL, - 'ack' : ACK, - 'notmetoo': NOTMETOO, - 'digest' : DIGEST, - 'plain' : PLAIN, +NODUPES = _("""When turned on, you do *not* receive duplicate mails if mail is +sent to multiple lists that you belong to. This option will let you avoid +duplicate mails; if you turn it on, you will never receive multiple copies +of the same message. Also, if you *and* the list are mentioned explicitly +in the To: or Cc: headers of a message, you will not receive duplicates if +this is turned on.""") + +option_desc = {'hide' : HIDE, + 'nomail' : NOMAIL, + 'ack' : ACK, + 'notmetoo' : NOTMETOO, + 'digest' : DIGEST, + 'plain' : PLAIN, + 'nodupes' : NODUPES, } # jcrey: and then the real one @@ -97,10 +105,11 @@ 'notmetoo': mm_cfg.DontReceiveOwnPosts, 'digest' : 0, 'plain' : mm_cfg.DisableMime, + 'nodupes' : mm_cfg.DontReceiveDuplicates } # ordered list -options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain') +options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes') # strip just the outer layer of quotes quotecre = re.compile(r'["\'`](?P.*)["\'`]') diff -urN mailman-cvs/Mailman/MailList.py mailman-cvs-nodupes/Mailman/MailList.py --- mailman-cvs/Mailman/MailList.py Sun Mar 3 14:29:16 2002 +++ mailman-cvs-nodupes/Mailman/MailList.py Sun Mar 3 17:08:03 2002 @@ -257,6 +257,7 @@ self.language = {} self.usernames = {} self.passwords = {} + self.default_options = mm_cfg.DEFAULT_LIST_OPTIONS # This stuff is configurable self.respond_to_post_requests = 1 diff -urN mailman-cvs/Mailman/OldStyleMemberships.py mailman-cvs-nodupes/Mailman/OldStyleMemberships.py --- mailman-cvs/Mailman/OldStyleMemberships.py Wed Feb 20 21:51:58 2002 +++ mailman-cvs-nodupes/Mailman/OldStyleMemberships.py Mon Mar 4 01:09:18 2002 @@ -207,6 +207,8 @@ self.setMemberLanguage(member, language) if realname: self.setMemberName(member, realname) + if self.__mlist.default_options: + self.__mlist.user_options[member] = self.__mlist.default_options def removeMember(self, member): assert self.__mlist.Locked() diff -urN mailman-cvs/Mailman/Version.py mailman-cvs-nodupes/Mailman/Version.py --- mailman-cvs/Mailman/Version.py Fri Jan 25 13:38:42 2002 +++ mailman-cvs-nodupes/Mailman/Version.py Sun Mar 3 16:44:50 2002 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.1a4+" +VERSION = "2.1a4+-nodupes" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.pck schema version number -DATA_FILE_VERSION = 54 +DATA_FILE_VERSION = 55 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 3 diff -urN mailman-cvs/Mailman/versions.py mailman-cvs-nodupes/Mailman/versions.py --- mailman-cvs/Mailman/versions.py Fri Jan 25 13:38:42 2002 +++ mailman-cvs-nodupes/Mailman/versions.py Sun Mar 3 17:07:53 2002 @@ -286,6 +286,7 @@ add_only_if_missing('one_last_digest', {}) add_only_if_missing('usernames', {}) add_only_if_missing('personalize', 0) + add_only_if_missing('default_options', mm_cfg.DEFAULT_LIST_OPTIONS) add_only_if_missing('first_strip_reply_to', mm_cfg.DEFAULT_FIRST_STRIP_REPLY_TO) add_only_if_missing('unsubscribe_policy', diff -urN mailman-cvs/templates/en/help.txt mailman-cvs-nodupes/templates/en/help.txt --- mailman-cvs/templates/en/help.txt Fri May 18 14:28:54 2001 +++ mailman-cvs-nodupes/templates/en/help.txt Sun Mar 3 16:46:25 2002 @@ -79,6 +79,11 @@ Conceals your address when people look at who is on this list. + nodupes: + Turn this on if you do not want to receive duplicate mail + from the list, in case you are explicitly in the To: or Cc: + fields already or are included in multiple lists in one message. + options Show the current values of your list options. diff -urN mailman-cvs/templates/en/options.html mailman-cvs-nodupes/templates/en/options.html --- mailman-cvs/templates/en/options.html Sun Mar 3 14:29:21 2002 +++ mailman-cvs-nodupes/templates/en/options.html Sun Mar 3 17:53:01 2002 @@ -280,6 +280,26 @@ Yes + + Avoid duplicate copies of messages?

+ + When you are listed explicitly in the To: or Cc: headers + of a list message, or a message is sent to multiple lists + that you are a member of, you can opt to not receive another + copy from the mailing list. Select Yes to avoid + receiving duplicate copies from the mailing list; select + No to receive duplicate copies. + +

If the list has per-message personalization + enabled, every duplicate mail will have a + X-Mailman-Duplicate: yes header added to it. + + + No
+ Yes

+ Set globally + +

--pf9I7BMVVzbSWLtt-- From che@debian.org Mon Mar 4 10:38:02 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 04 Mar 2002 19:38:02 +0900 Subject: [Mailman-Developers] Re: Updated dupe removal patch In-Reply-To: <20020304102508.GF9799@merlins.org> (Marc MERLIN's message of "Mon, 4 Mar 2002 02:25:09 -0800") References: <20020304102508.GF9799@merlins.org> Message-ID: <87u1rwpqid.fsf@nausicaa.interq.or.jp> >>>>> "Marc" == Marc MERLIN writes: Marc> It took all of my sunday, but I just finished porting Ben Marc> Gertzfield's excellent dupe removal patch to mailman cvs (I Marc> also had to learn some python in the process. I'm starting Marc> to believe that Mailman is a conspiracy to get people to Marc> learn python :-p) Fantastic, Marc! Sorry I've been lazy and haven't been able to port it. I'll install this patch on our test server at work and let you know if I have any problems tomorrow. Ben -- Brought to you by the letters O and T and the number 11. "You forgot Uranus." "Goooooooooodnight everybody!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From chuqui@plaidworks.com Mon Mar 4 18:09:24 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 04 Mar 2002 10:09:24 -0800 Subject: [Mailman-Developers] A thought on SMTPHOST Message-ID: Just wanted to bluesky this a bit, and make a suggestion to Barry. I'm starting to see volume stress on my E250, mostly due to high volume (14 million pieces of email last month, more or less) and disk I/O issues (only 2 SCSI drives in the beast). I've pretty much maxed out capacity on that thing unless I wanted to stuff in more drives, and the cost of a good, fast hard drive for a Sun box and the cost (to me) for a good, fast MacOS X box aren't much different... And for some reason, my bosses like the idea of MacOS X boxes. So I'm getting ready to start what's known as my "smurf army" in my design documents: a farm of small, inexpensive, fast machines set up specifically to deliver mail as quickly as possible. (the first three are ultra-5's, mostly because another project went away and we got them for free....) And I've been looking at the best way to interface all of these with the delivery boxes. With Mailman, that means SMTPHOST. The way SMTPHOST is set up, to implement a smurf army would require setting up a round robin DNS of the various hosts. That'll work, but... If one of the boxes goes down for some reason, some percentage of Mailman deliveries would fail when it hits that part of the round robin, unless I tweak the round robin constantly, which would require setting up a DNS box among the smurf to delegate the round robin to instead of the corporate DNS, which is not a good idea on any number of levels for us... Which got me thinking. You could put the smurf army behind a load balancing box (mac.com's SMTP is that way), but... I don't want to spend the money on that, administer that, or do it that way. I looked at what it'd take to hack multiple SMTP host support into Mailman. Not a huge deal, actually, but then unless Barry buys the hack back, I'm forked. I'd rather not, although it'd be a nice setup for larger installations. So... I suddenly realized we have a process to handle this. MX records. What if Mailman were made MX aware? You could then set up SMTPHOST to point to a DNS name. If that DNS name has an MX definition for it, Mailman would use it instead of the IP. That would make this backwards compatible, since under almost all circumstances, the MX record will be pointing to the machine if it exists (if it points elsewhere, but you're using as an SMTP host, what in the heck are you doing? I can only think of one scenario where that makes sense (dedicated incoming SMTP beastie) and if you're that large -- you probably want this hack) This would allow you to define your "smurf army" any way you want, as big as you want, and it's self-healing to failures. Imagine the following scenario A record: smtp-out.lists.apple.com MX 5 smurf1.lists.apple.com MX 5 smurf2.lists.apple.com MX 5 smurf3.lists.apple.com MX 5 smurf4.lists.apple.com MX 20 lists.apple.com MX 30 applenews.lists.apple.com As a forinstance. When qrunner starts up, it grabs the MX data and stores it. Every time it has to delivery something, it picks one of the MX of 5 and delivers to it. If that delivery fails, it grabs another 5. If all 4 fail, it backs off to the 20, then the 30. Only if all six boxes fail does qrunner drop out and retry later. This allows each smurf to load-balance itself. If it gets busy, it stops accepting mail and lets someone else handle it. You could hack this kind of configuration into mailman itself, but one advantage of the MX setup is if you run multiple servers feeding into that farm, configuration is in one place for the farm. It doesn't seem supporting MX (perhaps as a configurable option?) would be difficult, but I haven't looked into the python library code yet. Barry, what do you think about this? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From Dan Mick Mon Mar 4 18:13:23 2002 From: Dan Mick (Dan Mick) Date: Mon, 4 Mar 2002 10:13:23 -0800 (PST) Subject: [Mailman-Developers] Missing footers with latest CVS Message-ID: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> > >>>>> "Dan" == Dan Mick writes: > > Dan> Installed latest CVS yesterday, and notice now that some > Dan> posters are not getting footers added to their messages. I > Dan> suspect the footer-add-based- on-language code is at fault, > Dan> but I haven't had time to isolate a pattern yet. Anyway, > Dan> consider this Distant Early Warning that that code isn't > Dan> working for some otherwise-untroubled list members. > > Maybe it's working as intended? ;) well, then, how it's intended has a bug. :) > Are they posting messages with a charset that is not the same as the > mailing list's charset? The default charset is us-ascii; I will > hazard a guess that they are posting messages flagged as UTF-8 or > ISO-8859-1 but that are really us-ascii. Well, so, one of them has no charset expressed at all that I can see. > We can add a work around for this, but it will be hard. Not really, if appropriate workaround is "ignore the incoming charset and add this footer unconditionally please". From djc@members.evolt.org Mon Mar 4 18:25:57 2002 From: djc@members.evolt.org (Daniel J. Cody) Date: Mon, 4 Mar 2002 12:25:57 -0600 (CST) Subject: [Mailman-Developers] A thought on SMTPHOST In-Reply-To: Message-ID: On Mon, 4 Mar 2002, Chuq Von Rospach wrote: > > So I'm getting ready to start what's known as my "smurf army" in my design > documents: a farm of small, inexpensive, fast machines set up specifically > to deliver mail as quickly as possible. (the first three are ultra-5's, > mostly because another project went away and we got them for free....) > > And I've been looking at the best way to interface all of these with the > delivery boxes. With Mailman, that means SMTPHOST. > > The way SMTPHOST is set up, to implement a smurf army would require setting > up a round robin DNS of the various hosts. That'll work, but... If one of > the boxes goes down for some reason, some percentage of Mailman deliveries > would fail when it hits that part of the round robin, unless I tweak the > round robin constantly, which would require setting up a DNS box among the > smurf to delegate the round robin to instead of the corporate DNS, which is > not a good idea on any number of levels for us... [snip] fwiw, i only have about 10% of the traffic you do Chuq, but I've been using this method with success on 2 low end pentiums with linux, and a sparc5 with openbsd all running postfix for a bit over a year now.. the round robin method has worked well for me, but making Mailman MX aware sounds like an improvement. just some thoughts :) .djc. From colin@mackinlay.demon.co.uk Mon Mar 4 19:15:07 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Mon, 4 Mar 2002 19:15:07 +0000 (GMT) Subject: [Mailman-Developers] Handling bounces correctly? Message-ID: My cvs installation is sending me bounces rather than processing them. Looking at the aliases automatically added to postfix there are two duplicates: test-admin /usr/local/mailman/mail/mailman bounces test test-bounces /usr/local/mailman/mail/mailman bounces test This seems to be true for all lists. Am I missing something obvious?! -- Colin Mackinlay From Dan Mick Mon Mar 4 19:43:07 2002 From: Dan Mick (Dan Mick) Date: Mon, 4 Mar 2002 11:43:07 -0800 (PST) Subject: [Mailman-Developers] Handling bounces correctly? Message-ID: <200203041944.g24Ji2cW003886@utopia.West.Sun.COM> > My cvs installation is sending me bounces rather than processing them. > > Looking at the aliases automatically added to postfix there are two > duplicates: > > test-admin /usr/local/mailman/mail/mailman bounces test > test-bounces /usr/local/mailman/mail/mailman bounces test > > This seems to be true for all lists. Am I missing something obvious?! That's the way the aliases are supposed to be set up. "Sending me...rather than processing"... does that mean they're coming addressed to you specifically, or to the 'owner' set up for the 'test' list, or some other path? Note: those literal aliases above are not correct; they need a '|' character, and should probably have quotes around the entire RHS. From barry@zope.com Mon Mar 4 20:09:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 4 Mar 2002 15:09:25 -0500 Subject: [Mailman-Developers] Do we need the password in the HTML of the confirm page? References: <20020304091924.GB9799@merlins.org> Message-ID: <15491.54389.484418.440161@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> When I went to: MM> http://gandalf-lists.merlins.org/lists/confirm/test2/372ff4ab4ca390f3c3bfabd47cd78e92489a0b5d MM> (don't bother trying, it's localhost on my laptop :-D) I get MM> an HTML page to confirm my subscription. MM> I haven't looked at the code in details, but does mailman need MM> to put the list password in cleartext in the HTML? (if the MM> answer is "yes", then never mind) MM> It's not the end of the world, but if someone puts my Email by MM> mistake (one letter typo or something in a company), I can get MM> his mailman password, and with a little luck that password MM> could work in other places too (not that the person is MM> supposed to use the same password, but...) I don't think Mailman needs to put the password on this page. I've disabled it, and included a note that the password can be changed once the user is subscribed. -Barry From colin@mackinlay.demon.co.uk Mon Mar 4 20:26:14 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Mon, 4 Mar 2002 20:26:14 +0000 (GMT) Subject: [Mailman-Developers] Handling bounces correctly? In-Reply-To: <200203041944.g24Ji2cW003886@utopia.West.Sun.COM> Message-ID: On Mon 04 Mar, Dan Mick wrote: > > > > My cvs installation is sending me bounces rather than processing them. > > > > Looking at the aliases automatically added to postfix there are two > > duplicates: > > > > test-admin /usr/local/mailman/mail/mailman bounces test > > test-bounces /usr/local/mailman/mail/mailman bounces test > > > > This seems to be true for all lists. Am I missing something obvious?! > > That's the way the aliases are supposed to be set up. > "Sending me...rather than processing"... does that mean > they're coming addressed to you specifically, or to the > 'owner' set up for the 'test' list, or some other path? they are coming addressed to test-bounces@mackinlay.demon.co.uk but are being deposited into my mailbox whixh is the default for root and anything else not addressed to a user with a postbox. > > Note: those literal aliases above are not correct; they need a > '|' character, and should probably have quotes around the entire > RHS. Correct - this is what they look like |test-bounces "/usr/local/mailman/mail/mailman bounces test" -- Colin Mackinlay From colin@mackinlay.demon.co.uk Mon Mar 4 20:42:13 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Mon, 4 Mar 2002 20:42:13 +0000 (GMT) Subject: [Mailman-Developers] Handling bounces correctly? In-Reply-To: <200203041944.g24Ji2cW003886@utopia.West.Sun.COM> Message-ID: In on Mon 04 Mar, Dan Mick wrote: > > > My cvs installation is sending me bounces rather than processing them. > > > > Looking at the aliases automatically added to postfix there are two > > duplicates: > > > > test-admin /usr/local/mailman/mail/mailman bounces test > > test-bounces /usr/local/mailman/mail/mailman bounces test > > > > This seems to be true for all lists. Am I missing something obvious?! > > That's the way the aliases are supposed to be set up. > "Sending me...rather than processing"... does that mean > they're coming addressed to you specifically, or to the > 'owner' set up for the 'test' list, or some other path? Having looked at the mailman bounces log I find that quite a few bounces have been received correctly and dealt with, both before and after the ones that are redirecting to me. The offending email address is clearly identified in the bounced message so it should be picked up. If not, I thought the default was to discard it. Interim solution is just to manually remove this address but the purist in me wants to know why its not happening automatically! -- Colin Mackinlay From barry@zope.com Mon Mar 4 20:58:59 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 4 Mar 2002 15:58:59 -0500 Subject: [Mailman-Developers] Updated dupe removal patch References: <20020304102508.GF9799@merlins.org> Message-ID: <15491.57363.77648.125310@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Considering this was a pain to port, and how this puts to rest MM> many of the reply-to munging discussions (the only real MM> argument for reply-to munging is that it "solves" the MM> duplicate mails you other receive when people use reply to MM> all), I'm hoping that this could make it in (wink, wink :-D) I'm looking at the patches now, and will have some feedback shortly (which might be in the form of checkin messages :). -Barry From marc_news@vasoftware.com Mon Mar 4 21:16:20 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 13:16:20 -0800 Subject: [Mailman-Developers] how to mass-set user options? In-Reply-To: <20020304102508.GF9799@merlins.org> References: <20020304102508.GF9799@merlins.org> Message-ID: <20020304211619.GU15098@merlins.org> On Mon, Mar 04, 2002 at 02:25:09AM -0800, Marc MERLIN wrote: > 2) The new "nodupes" setting is really something you probably want as a > default on all lists. I also had lists were people wanted notmetoo as a > default too. > Ben's fix for that is to have a bitfield per list that you can set and > that states which options newly added users get. Now comes the question: how do I retroactively reset user options for a given list of users without clicking on a web form? The idea would be to enable nodupes for a batch of users, although I've also had the need to set a batch of users to notmetoo I seemed to remember reading something about this, but I can't find the message. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Mar 4 22:16:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 4 Mar 2002 17:16:21 -0500 Subject: [Mailman-Developers] Updated dupe removal patch References: <20020304102508.GF9799@merlins.org> Message-ID: <15491.62005.87805.726109@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> It took all of my sunday, but I just finished porting Ben MM> Gertzfield's excellent dupe removal patch to mailman cvs (I MM> also had to learn some python in the process. I'm starting to MM> believe that Mailman is a conspiracy to get people to learn MM> python :-p) Well, of course it is! :) Okay, I've looked over all the code. Except for some stylistic issues, which I'll just correct as I go, my biggest concern is the database used in AvoidDuplicates.py. It looks like you're keeping an in-memory dictionary mapping addresses to a set of Message-ID:'s. You use this to decide if the recipient address has already received a message of the given Message-ID: Let's ignore the duplicate or missing Message-ID: issue for now. The biggest problem I see is that 1) you lose all the mappings if you restart your IncomingRunner, and 2) your process will grow without bounds until you do restart your IncomingRunner. I'm not sure about the best thing to do. Sticking this data structure in the list, or otherwise making it persistent, could take too much resources for not much gain. The second issue is more important, especially given that all our runners are now long running processes, and I think most of the unbounded memory growth issues are taken care of. Probably the best thing to do is to evict any entry in the dictionary that's older than a day or two. Then again, this whole data structure seems intended to avoid duplicates when lists are crossposted. It shouldn't be necessary if we just want to filter out duplicates to explicitly named recipients. Maybe we don't need both features, as the former seems to be much less requested than the latter? I think what I'll do for now is code up and test the original approach. I'm on irc now so please join me if you want to talk about it. now-if-i-can-just-get-OPN-to-stop-kicking-me-off!-ly y'rs, -Barry From Dan Mick Mon Mar 4 22:31:29 2002 From: Dan Mick (Dan Mick) Date: Mon, 4 Mar 2002 14:31:29 -0800 (PST) Subject: [Mailman-Developers] Handling bounces correctly? Message-ID: <200203042232.g24MWOcW012736@utopia.West.Sun.COM> Well, OK. I guess that's how it's designed: # Otherwise, we should just forward this message to the list # owner, because there's nothing we can do with it. Be sure to # point the envelope sender at the site owner for any bounces to # list owners. (from Mailman/Queue/BounceRunner.py) Seems like making that behavior configurable might be useful. But the real issue is that the bounce message is *so* nonstandard. It didn't match *any* of the stuff in Mailman/Bouncers, and there are a lot of tests there. I'd complain to the postmaster at that site and tell him to please configure DSNs like all good mailhosts should be doing. I've sidestepped this issue by using VERP on all my outgoing mail, so bounces are always caught before they even get to Bouncers/*... but that's because I can have Postfix do it for me relatively-efficiently, and because I don't have that bad a bandwidth restriction; I know it's not an option for everyone. I suppose the other thing to do is fix up/add a Bouncers/* module to catch these messages; I have hacked SimpleMatch.py before for just this purpose (the hotpop stanza is mine). > On Mon 04 Mar, Dan Mick wrote: > > I'm confused. Can you forward me one, sanitized if you wish, > > in toto (i.e. with all its headers, so don't use an MUA to > > forward it, but capture it to a file and send it)? > > > Attached - the actual list is called modular-it as you can see but in > all other respects the aliases etc are identical to the test ones I have > been describing. > > > > > -- > Colin Mackinlay From marc_news@vasoftware.com Mon Mar 4 23:12:40 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 15:12:40 -0800 Subject: [Mailman-Developers] Updated dupe removal patch In-Reply-To: <15491.62005.87805.726109@anthem.wooz.org> References: <20020304102508.GF9799@merlins.org> <15491.62005.87805.726109@anthem.wooz.org> Message-ID: <20020304231240.GW15098@merlins.org> On Mon, Mar 04, 2002 at 05:16:21PM -0500, Barry A. Warsaw wrote: > Okay, I've looked over all the code. Except for some stylistic > issues, which I'll just correct as I go, my biggest concern is the > database used in AvoidDuplicates.py. Yeah, I looked at that too, but being tired, I didn't get as critical as you did. I figured it somehow worked ok for Ben for his lists (bad Marc, no cookie) Now that I think of it, Ben wrote initially wrote this for qrunner from cron, and didn't think about this issue when he ported it to mailman-cvs-sept-2001 > It looks like you're keeping an in-memory dictionary mapping > addresses to a set of Message-ID:'s. You use this to decide if the > recipient address has already received a message of the given > Message-ID: That was my understanding of the code too. > Let's ignore the duplicate or missing Message-ID: issue for now. The > biggest problem I see is that 1) you lose all the mappings if you > restart your IncomingRunner, and That's probably not a problem because 1) it would only affect a message being processed at the time you kill and restart IncomingRunner, not very likely, and worst case, you do get a second copy. 2) You don't restart IncomingRunner often if at all 3) When you do restart qrunner, there can be other qwirks, like a message being delivered twice (I've seen this with VERP enabled, I probably killed it while it was delivering a batch to exim, so it didn't complete and did it all over again after the restart) > 2) your process will grow without bounds until you do restart your > IncomingRunner. I think you're right. You'd have to have a lot of traffic before it catches up with you, but it will eventually if you never restart qrunner. > I'm not sure about the best thing to do. Sticking this data structure > in the list, or otherwise making it persistent, could take too much > resources for not much gain. The second issue is more important, > especially given that all our runners are now long running processes, > and I think most of the unbounded memory growth issues are taken care > of. Probably the best thing to do is to evict any entry in the > dictionary that's older than a day or two. That sounds like a reasonable plan. > Then again, this whole data structure seems intended to avoid > duplicates when lists are crossposted. It shouldn't be necessary if > we just want to filter out duplicates to explicitly named recipients. > Maybe we don't need both features, as the former seems to be much less > requested than the latter? That's true. The later is nice for instance when you have threads Cced accross mailman-devel and mailman-users, but having the former by itself would be good already. If this is a time issue wrt fixing the code, the duplicate message-ID code could be left behind a global option that is disabled by default and a comment saying that you should be ready to restart your qrunner weekly or daily if you enable it That said, adding a timestamp to them, and deleting everything that's more than 1H old is a better solution. > I think what I'll do for now is code up and test the original > approach. I'm on irc now so please join me if you want to talk about > it. > > now-if-i-can-just-get-OPN-to-stop-kicking-me-off!-ly y'rs, <-- barry has quit (Read error: 110 (Connection timed out)) :-) I was saying there: about OPN, I don't know the details (and there were also politics), but the sf.net guys moved their channels to slashnet.org. Seems to work better there Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From colin@mackinlay.demon.co.uk Mon Mar 4 23:16:13 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Mon, 4 Mar 2002 23:16:13 +0000 (GMT) Subject: [Mailman-Developers] Handling bounces correctly? In-Reply-To: <200203042232.g24MWOcW012736@utopia.West.Sun.COM> Message-ID: On Mon 04 Mar, Dan Mick wrote: > > > Well, OK. > > I guess that's how it's designed: > > # Otherwise, we should just forward this message to the list > # owner, because there's nothing we can do with it. Be sure to > # point the envelope sender at the site owner for any bounces to > # list owners. > > (from Mailman/Queue/BounceRunner.py) > > Seems like making that behavior configurable might be useful. > > But the real issue is that the bounce message is *so* nonstandard. > It didn't match *any* of the stuff in Mailman/Bouncers, and there > are a lot of tests there. I'd complain to the postmaster at that > site and tell him to please configure DSNs like all good mailhosts > should be doing. > Thanks for that. I'll follow it up and have a good look deeper inside mailman to satisfy my own curiosity. -- Colin Mackinlay From che@debian.org Tue Mar 5 01:44:58 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 05 Mar 2002 10:44:58 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> (Dan Mick's message of "Mon, 4 Mar 2002 10:13:23 -0800 (PST)") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> Message-ID: <87k7srpz39.fsf@nausicaa.interq.or.jp> >>>>> "Dan" == Dan Mick writes: Dan> Well, so, one of them has no charset expressed at all that I Dan> can see. That means their charset is us-ascii. Is the list set to some other language? Could you please post the configuration of the list, and an example message without footer that was sent to the list? Basically, we need to deal with the case where a list is configured for something like iso-8859-2, but a user sends a message in iso-8859-1, or utf-8, etc. In these cases, we can't just tack the footer on -- we'll get a garbage message! We have to avoid adding a footer if the charsets mismatch; no other way about it. Dan> Not really, if appropriate workaround is "ignore the incoming Dan> charset and add this footer unconditionally please". But this is the worst thing you can do. What happens when I post a message in UTF-8 and then a Japanese ISO-2022-JP footer gets tacked on? Not good. Ben -- Brought to you by the letters X and G and the number 15. "Tahiti is not in Europe." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Tue Mar 5 01:49:13 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 05 Mar 2002 10:49:13 +0900 Subject: [Mailman-Developers] Updated dupe removal patch In-Reply-To: <20020304231240.GW15098@merlins.org> (Marc MERLIN's message of "Mon, 4 Mar 2002 15:12:40 -0800") References: <20020304102508.GF9799@merlins.org> <15491.62005.87805.726109@anthem.wooz.org> <20020304231240.GW15098@merlins.org> Message-ID: <87g03fpyw6.fsf@nausicaa.interq.or.jp> >>>>> "Marc" == Marc MERLIN writes: Barry> Let's ignore the duplicate or missing Message-ID: issue for Barry> now. The biggest problem I see is that 1) you lose all the Barry> mappings if you restart your IncomingRunner ... Marc> That's probably not a problem because 1) it would only Marc> affect a message being processed at the time you kill and Marc> restart IncomingRunner, not very likely, and worst case, you Marc> do get a second copy. 2) You don't restart IncomingRunner Marc> often if at all 3) When you do restart qrunner, there can be Marc> other qwirks, like a message being delivered twice (I've Marc> seen this with VERP enabled, I probably killed it while it Marc> was delivering a batch to exim, so it didn't complete and Marc> did it all over again after the restart) Marc has summed up all my comments here -- the worst thing that can happen if IncomingRunner is restarted is that a duplicate is sent, which is what we do now without the patch. Barry> 2) your process will grow without bounds until you do Barry> restart your IncomingRunner. Marc> I think you're right. You'd have to have a lot of traffic Marc> before it catches up with you, but it will eventually if you Marc> never restart qrunner. Yeah.. I knew about this, but I think my setup had a cron job to restart the runner daily. Not at all an optimal solution, just a hack to re-implement the /etc/aliases style list functionality where a user belonging to multiple umbrella lists only receives one copy of any given mail. Barry> I'm not sure about the best thing to do. Sticking this Barry> data structure in the list, or otherwise making it Barry> persistent, could take too much resources for not much Barry> gain. The second issue is more important, especially given Barry> that all our runners are now long running processes, and I Barry> think most of the unbounded memory growth issues are taken Barry> care of. Probably the best thing to do is to evict any Barry> entry in the dictionary that's older than a day or two. Marc> That sounds like a reasonable plan. So, is there functionality in the *Runners to run something on a regular schedule? Say, if we clean out the structure once an hour or so, it should work pretty well. Barry> Then again, this whole data structure seems intended to Barry> avoid duplicates when lists are crossposted. It shouldn't Barry> be necessary if we just want to filter out duplicates to Barry> explicitly named recipients. Maybe we don't need both Barry> features, as the former seems to be much less requested Barry> than the latter? Marc> That's true. The later is nice for instance when you have Marc> threads Cced accross mailman-devel and mailman-users, but Marc> having the former by itself would be good already. I agree, and from what I understand on IRC, this is what ended up happening. I will work on making a separate, proper patch for the in-memory Message-ID cache that has a time to live associated with each entry. Ben -- Brought to you by the letters H and X and the number 19. "It is sad. *Campers* cannot *dance*. Not even a *party*." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From Dan Mick Tue Mar 5 02:01:42 2002 From: Dan Mick (Dan Mick) Date: Mon, 4 Mar 2002 18:01:42 -0800 (PST) Subject: [Mailman-Developers] Missing footers with latest CVS Message-ID: <200203050202.g2522bcW021852@utopia.West.Sun.COM> > >>>>> "Dan" == Dan Mick writes: > > Dan> Well, so, one of them has no charset expressed at all that I > Dan> can see. > > That means their charset is us-ascii. Is the list set to some other > language? Could you please post the configuration of the list, and > an example message without footer that was sent to the list? > > Basically, we need to deal with the case where a list is configured > for something like iso-8859-2, but a user sends a message in > iso-8859-1, or utf-8, etc. In these cases, we can't just tack the > footer on -- we'll get a garbage message! We have to avoid adding > a footer if the charsets mismatch; no other way about it. Why a garbage message? Why not just a (potentially) garbage footer? > Dan> Not really, if appropriate workaround is "ignore the incoming > Dan> charset and add this footer unconditionally please". > > But this is the worst thing you can do. What happens when I post a > message in UTF-8 and then a Japanese ISO-2022-JP footer gets tacked > on? Not good. I'd be more concerned about what happened to the message, since it's apparently sent in a language that can't be understood by its audience. There's something about the fullness of charset processing that I don't grok. I think it has to do with design. Are there design notes somewhere? From tkikuchi@is.kochi-u.ac.jp Tue Mar 5 02:03:11 2002 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 05 Mar 2002 11:03:11 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> Message-ID: <3C84275F.6020703@is.kochi-u.ac.jp> Hi, Ben Gertzfield wrote: >>>>>>"Dan" == Dan Mick writes: >>>>>> > > Dan> Well, so, one of them has no charset expressed at all that I > Dan> can see. > > That means their charset is us-ascii. Well, people around in Japan still use older MUAs and don't add charset for Japanese messages. So, the meaning of no charset should depend on the mm_cfg.DEFAULT_SERVER_LANGUAGE, I suppose. > Dan> Not really, if appropriate workaround is "ignore the incoming > Dan> charset and add this footer unconditionally please". > > But this is the worst thing you can do. What happens when I post a > message in UTF-8 and then a Japanese ISO-2022-JP footer gets tacked > on? Not good. That's why you need to 'normalize' the charsets of incoming mail (into Unicode). -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From che@debian.org Tue Mar 5 02:22:27 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 05 Mar 2002 11:22:27 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <3C84275F.6020703@is.kochi-u.ac.jp> (Tokio Kikuchi's message of "Tue, 05 Mar 2002 11:03:11 +0900") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> Message-ID: <87bse3pxcs.fsf@nausicaa.interq.or.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Dan> Well, so, one of them has no charset expressed at all that I Dan> can see. Ben> That means their charset is us-ascii. Tokio> Well, people around in Japan still use older MUAs and don't Tokio> add charset for Japanese messages. Tokio> So, the meaning of no charset should depend on the Tokio> mm_cfg.DEFAULT_SERVER_LANGUAGE, I suppose. This would violate RFC 1522: "5.2. Content-Type Defaults Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as: Content-type: text/plain; charset=us-ascii" Are we sure we really want to do that? Dan> Not really, if appropriate workaround is "ignore the incoming Dan> charset and add this footer unconditionally please". Ben> But this is the worst thing you can do. What happens when I Ben> post a message in UTF-8 and then a Japanese ISO-2022-JP Ben> footer gets tacked on? Not good. Tokio> That's why you need to 'normalize' the charsets of incoming Tokio> mail (into Unicode). That would work in the best of all possible worlds (i.e. NOT the real world :) but I think there is still information lost when converting some charsets into Unicode, like Big5 and EUC-TW. Also, who knows if we would corrupt PGP signatures by doing something like this? I would like to have Mailman move to this model eventually, when all mail readers support UTF-8 natively. Ben -- Brought to you by the letters N and R and the number 15. "Tahiti is not in Europe." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Tue Mar 5 02:30:06 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 05 Mar 2002 11:30:06 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <200203050202.g2522bcW021852@utopia.West.Sun.COM> (Dan Mick's message of "Mon, 4 Mar 2002 18:01:42 -0800 (PST)") References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> Message-ID: <877korpx01.fsf@nausicaa.interq.or.jp> >>>>> "Dan" == Dan Mick writes: Ben> Basically, we need to deal with the case where a list is Ben> configured for something like iso-8859-2, but a user sends a Ben> message in iso-8859-1, or utf-8, etc. In these cases, we Ben> can't just tack the footer on -- we'll get a garbage message! Ben> We have to avoid adding a footer if the charsets mismatch; no Ben> other way about it. Dan> Why a garbage message? Why not just a (potentially) garbage Dan> footer? Here's an example. My Japanese terminal accepts EUC-JP and ISO-2022-JP only. If I displayed a Japanese ISO-2022-JP message with an illegal ISO-8859-1 footer on it, not only would it be a garbage footer, but any further output to the terminal AFTER the footer would be complete garbage, because the illegal 8-bit characters would "shift" my terminal into a special Japanese-only mode. Basically, illegal footers can be worse than just illegal -- they can render the reader's terminal completely useless, requiring a total restart. This is not acceptable. Dan> I'd be more concerned about what happened to the message, Dan> since it's apparently sent in a language that can't be Dan> understood by its audience. Why? You can set a list's default charset to Japanese, but often get messages in English, Chinese, or Korean. Adding a Japanese footer to these unconditionally without making the whole thing a MIME message with separate parts with their own charsets would break everyone's terminals. Dan> There's something about the fullness of charset processing Dan> that I don't grok. I think it has to do with design. Are Dan> there design notes somewhere? I'm not exactly sure what you mean about fullness, but here's a little explanation from (gasp) Microsoft that covers 7-bit ASCII, 8-bit IBM PC-DOS characters, double-byte character sets like Japanese and Chinese, and Unicode: http://www.microsoft.com/typography/unicode/cs.htm Ben -- Brought to you by the letters G and X and the number 8. "You have my pills!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From stephen@xemacs.org Tue Mar 5 03:58:11 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 05 Mar 2002 12:58:11 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <87bse3pxcs.fsf@nausicaa.interq.or.jp> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> Message-ID: <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Ben" == Ben Gertzfield writes: Ben> This would violate RFC 1522: That's right. People with broken mailers have broken mailers. Make sure that things are robust for those with decent software, and then do what we can for the former poor souls. Anyway, even my boss---who used to send mail in NEC JIS---has finally converted to a MIME-capable mailer (and uses it to send me Word attachments :-( ). Ben> That would work in the best of all possible worlds (i.e. NOT Ben> the real world :) but I think there is still information lost Ben> when converting some charsets into Unicode, like Big5 and Ben> EUC-TW. Big5, AFAIK, not. CNS yes (I don't know about EUC-TW). But you could handle this by converting to multipart/alternative. (Of course that leaves the people with obsolete mailers out in the cold.) Ben> Also, who knows if we would corrupt PGP signatures by doing Ben> something like this? You do, now. It's corrupted. What you'd have to do is convert to multipart/alternative, you couldn't just transcode. This would also have broader semantic implications because people would not necessarily know in that case that the "real" message was signed--- they'd have to go look. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From stephen@xemacs.org Tue Mar 5 04:14:16 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 05 Mar 2002 13:14:16 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <200203050202.g2522bcW021852@utopia.West.Sun.COM> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> Message-ID: <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Dan" == Dan Mick writes: Dan> Why a garbage message? Why not just a (potentially) garbage Dan> footer? Well, if it garbles HTML, it's going to hose our web interface. This is very possible with the Asian double-byte 7-bit encodings which are rife with random usage of octets like <, ", etc. Also, some MUAs (think Emacs RMail, but also Outhouse Abcess) autodetect the encoding of the message buffer, usually based on the first 3000-4000 characters. Very long messages would be OK, but typical messages would have the confusing footer within that space. I really can't predict what Abcess would do with that (although it's quite good at generating that kind of stuff itself, Microsoft Unicode BOM followed by ASCII HTML markup intermixed with Unicode P?CDATA, for one egregious example of a beta version ;-). Recently things have gotten better but when I first got to Japan I got to the point where I could read my boss's name and the name of the department in both base64 and raw bytes. Alphanumerics are easy; the double byte versions are #1, #2, ..., #A, .... ;-) So bogus encodings are no joke on this side of the big blue puddle. For more information, Jukka Korpela's page is quite good, there must be an intro or seven there, and you don't even need to read Finnish! http://www.cs.tut.fi/~jkorpela/ -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From jb@cascade-sys.com Tue Mar 5 04:52:57 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Mon, 04 Mar 2002 20:52:57 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <3C844F29.6998B3C2@cascade-sys.com> [... I'm a man of wealth and taste...] I recently started running a relatively small mailing list using Mailman and am quite happy with it. I am a proficient Python developer and the fact that Mailman is Python-based was one reason I chose it with entheusiasm. I hope that in my spare time I'll be able to make some useful contributions. Here are some of the areas I was thinking of working in. I throw them out in case someone else has already started or has ideas: 1. I would like to implement self.filter_prog, which I expect would be a filter on each incoming messages. There are some special things I can think of I'd like to do with my list. E.g., automatic tallying of poll results. 2. Along those lines, I would like users to be able to elect to filter out HTML from their regular mail, in addition to digests. Seems this should be easy. 3. Longer term, I would like the option of adding some info fields to the user database. E.g., I would like to store real names, addresses and phone numbers on one of my lists. 4. It would be nice to reuse the existing list security as an umbrealla to cover other arbitrary, list-members-only web pages. E.g., some listers hate large graphics attachments (and they are problematic generally). I'd like to remove the image from the incoming message, publish it on a secure, lister-only web page and forward the mail with an URL substituted for the image attachment. Having barely glanced at the code and Mailman architecture generally, these items seem eminently doable and generally useful. BUt maybe I'm crazy. Don't hesitate to be frank, as I usually don't. Looking forward to working with you folks. REgards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From marc_news@vasoftware.com Tue Mar 5 07:10:25 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 23:10:25 -0800 Subject: [Mailman-Developers] updated patch: remove member from all the lists Message-ID: <20020305071024.GA27363@merlins.org> This version of the patch add --fromall which lets you remove a specified Email from all your lists (replaces my _alllists_ special hack) --- ../../src/mailman-cvs/bin/remove_members Fri Sep 7 16:18:47 2001 +++ remove_members Mon Mar 4 23:02:17 2002 @@ -19,7 +19,7 @@ """Remove members from a list. Usage: - remove_members [options] listname [addr1 ...] + remove_members [options] ([-a] listname|--fromall) [addr1 ...] Options: @@ -31,6 +31,12 @@ --all -a Remove all members of the mailing list. + (mutually exclusive with --fromall) + + --fromall + Removes the given addresses from all the lists on this system + regardless of virtual domains if you have any. + (mutually exclusive with -a/--all) --help -h @@ -47,6 +53,7 @@ import paths from Mailman import MailList +from Mailman import Utils from Mailman import Errors from Mailman.i18n import _ @@ -77,17 +84,16 @@ def main(): try: opts, args = getopt.getopt( - sys.argv[1:], 'af:h', ['all', 'file=', 'help']) + sys.argv[1:], 'af:h', ['all', 'fromall', 'file=', 'help']) except getopt.error, msg: usage(1, msg) if len(args) < 1: usage(1) - listname = args[0].lower().strip() - addresses = args[1:] filename = None all = 0 + alllists = 0 for opt, arg in opts: if opt in ('-h', '--help'): @@ -96,33 +102,55 @@ filename = arg elif opt in ('-a', '--all'): all = 1 - + elif opt == '--fromall': + alllists = 1 + + # You probably don't want to delete all the users of all the lists -- Marc + if all == 1 and alllists == 1: + usage(1) + + if alllists: + addresses = args + else: + listname = args[0].lower().strip() + addresses = args[1:] + + if alllists: + listnames = Utils.list_names() + else: + listnames = [ listname ] + if filename: try: addresses = addresses + ReadFile(filename) except IOError: print _('Could not open file for reading: %(filename)s.') - try: - # open locked - mlist = MailList.MailList(listname) - except Errors.MMListError, e: - print _('No such list: %(listname)s') - sys.exit(1) - - if all: - addresses = mlist.getMembers() - - try: - for addr in addresses: - try: - mlist.ApprovedDeleteMember(addr) - except Errors.MMNoSuchUserError: - print _("User `%(addr)s' not found.") - finally: - # Hmm, should it be all or nothing? - mlist.Save() - mlist.Unlock() + for listname in listnames: + try: + # open locked + mlist = MailList.MailList(listname) + except Errors.MMListError: + print _('Error opening list %(listname)s... skipping.') + continue + + if all: + addresses = mlist.getMembers() + + try: + for addr in addresses: + try: + mlist.ApprovedDeleteMember(addr) + except Errors.MMNoSuchUserError: + if not alllists: + print _("User `%(addr)s' not found.") + else: + if alllists: + print _("User `%(addr)s' removed from list '%(listname)s'.") + finally: + # Hmm, should it be all or nothing? + mlist.Save() + mlist.Unlock() -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Tue Mar 5 07:19:55 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 23:19:55 -0800 Subject: [Mailman-Developers] buglet, changing options on an already deleted member Message-ID: <20020305071955.GB27363@merlins.org> I bring up an admin page, from the shell, I remove a user I change the user options in the web form, and click submit Traceback (most recent call last): File "/var/local/mailman/scripts/driver", line 82, in run_main main() File "/var/local/mailman/Mailman/Cgi/admin.py", line 166, in main change_options(mlist, category, subcat, cgidata, doc) File "/var/local/mailman/Mailman/Cgi/admin.py", line 1318, in change_options mlist.setMemberName(user, newname) File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 315, in setMemberName self.__assertIsMember(member) File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member NotAMemberError: marc@merlins.org The error is correct, but mailman should probably return a simple error in the web page instead of a traceback. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Tue Mar 5 07:29:26 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 4 Mar 2002 23:29:26 -0800 Subject: [Mailman-Developers] list_members doesn't return the whole membership list Message-ID: <20020305072925.GC27363@merlins.org> root@gandalf:/var/local/mailman/bin# ./dumpdb ../lists/test3/config.pck | grep user_options 'user_options': {'marc@merlins.org': 266}, root@gandalf:/var/local/mailman/bin# ./list_members test3 root@gandalf:/var/local/mailman/bin# On bigger lists, list_members returns some of the list membership. It's not just the digest or non digest members, it looks kinda random. I need to get some sleep, so I'll leave this for someone else to debug and fix Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From carson@taltos.org Tue Mar 5 08:42:04 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 03:42:04 -0500 Subject: [Mailman-Developers] Python-2.2 disaster Message-ID: <513533140.1015299724@[192.168.0.1]> What !@#$% idiot did the python 2.2 build system!? It bombs out trying to compile the extensions, because _someone_ got "clever" and decided to write the build system in Python. And got it wrong. So it doesn't compile or link properly. And after chasing through _8_ levels of indirection without figuring out where it tries adding library arguments, I just give up! For those who care, it's going insane trying to build _socket, and _curses, and probably something else. _socket is trying to link against openssl, but my openssl libraries aren't where it expects them to be, and if I hand-edit setup.py (yes, hand-edit - ARRRRGH!) to put the correct paths in, it still doesn't work, I suspect because it's not using -R or setting LD_RUN_PATH. I haven't even looked at the other errors yet. So, just how "recommended" is python 2.2? Can I just use my python 2.0 installation until someone else makes this nightmare go away? -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From carson@taltos.org Tue Mar 5 09:00:59 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 04:00:59 -0500 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <513533140.1015299724@[192.168.0.1]> References: <513533140.1015299724@[192.168.0.1]> Message-ID: <514667500.1015300858@[192.168.0.1]> OK, I "fixed" the _socket problem by hacking setup.py to change how it found ssl_incs and ssl_libs, and by adding 'runtime_library_dirs = ssl_libs' to the exts.append clause. Can one of the Python gurus here tell me if I just missed an obvious "correct" way to fix this, or if this is really a broken build process? Now to try and fix audioop and fpectl... -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From carson@taltos.org Tue Mar 5 09:11:54 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 04:11:54 -0500 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <513533140.1015299724@[192.168.0.1]> References: <513533140.1015299724@[192.168.0.1]> Message-ID: <515323171.1015301514@[192.168.0.1]> The other module problems: audioop needed a "libraries = ['m']" fpectl needed a "libraries = ['sunmath', 'm']" These are probably Solaris-specific, and it looks like sunmath is Forte (nee SunPRO) specific. But it makes it compile on my SPARC SunOS 5.8 box with Forte 6.x. *sigh* The problems with running such a low market share platform like Solaris/SPARC *snort* Again, can someone who knows how the Python team works please feed back this info? I have no burning desire to get involved in Python core development. -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From jb@cascade-sys.com Tue Mar 5 10:07:15 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Tue, 05 Mar 2002 02:07:15 -0800 Subject: [Mailman-Developers] Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> Message-ID: <3C8498D3.F4770480@cascade-sys.com> Carson Gaspar wrote: > Can one of the Python gurus here tell me if I just missed an obvious > "correct" way to fix this, or if this is really a broken build process? Dunno. [Real helpful, I know.] But FWIW I'm running 2.0.8 and despite the documentation I couldn't get things to install or run properly except with Python 1.5. Doc says 1.5 or better so I figured 2.1 was fair game but couldn't get it to work. I figured doc was wrong and was ... satisfied ... when it worked with 1.5. FWIW, I think 1.5 Python and 2.0.8 Mailman are standard in 7.2 Linux. Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From carson@taltos.org Tue Mar 5 10:26:44 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 05:26:44 -0500 Subject: [Mailman-Developers] Current CVS update error Message-ID: <519813609.1015306004@[192.168.0.1]> It looks like the install / update procedure does not create qfiles/in, so I get the following when I run bin/update: updating old qfiles Traceback (most recent call last): File "/tools/mailman-cvs-20020304/bin/update", line 533, in ? errors = main() File "/tools/mailman-cvs-20020304/bin/update", line 464, in main update_qfiles() File "/tools/mailman-cvs-20020304/bin/update", line 380, in update_qfiles os.rename(oldmsgfile, newmsgfile) OSError: [Errno 2] No such file or directory After I manually create qfiles/in, it runs correctly. Also, check_perms does _not_ complain about qfiles/in being missing. -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From carson@taltos.org Tue Mar 5 10:37:39 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 05:37:39 -0500 Subject: [Mailman-Developers] Problem with Postfix virtual support in current CVS Message-ID: <520468171.1015306659@[192.168.0.1]> I _think_ I set this up properly, but please tell me if I got something wrong: $ bin/dumpdb /var/mailman/lists/bluefeather/config.db | grep host_name\' 'host_name': 'bluefeather.org', >From mm_cfg.py: MTA = 'Postfix' POSTFIX_STYLE_VIRTUAL_DOMAINS = ['bluefeather.org', 'boardstiffny.org'] Yet after running genaliases, my /var/mailman/data/virtual-mailman is zero-length. -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From dgc@uchicago.edu Tue Mar 5 15:30:21 2002 From: dgc@uchicago.edu (David Champion) Date: Tue, 5 Mar 2002 09:30:21 -0600 Subject: [Mailman-Developers] Re: Python-2.2 disaster In-Reply-To: <514667500.1015300858@[192.168.0.1]> References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> Message-ID: <20020305153021.GW20284@dust.uchicago.edu> On 2002.03.05, in <514667500.1015300858@[192.168.0.1]>, "Carson Gaspar" wrote: > OK, I "fixed" the _socket problem by hacking setup.py to change how it > found ssl_incs and ssl_libs, and by adding 'runtime_library_dirs = > ssl_libs' to the exts.append clause. > > Can one of the Python gurus here tell me if I just missed an obvious > "correct" way to fix this, or if this is really a broken build process? > > Now to try and fix audioop and fpectl... I managed to get it to compile by ditching all my preferences and letting it do whatever it wants to. (I should have learned by now that my computer always knows better than I do.) It made me ornery, too, but it got me a python build. In particular, I couldn't figure out how to make it compile without fpectl, so I now have a dependency on libsunmath.so (which is a licensed product, and ergo not installed on all my systems, so my python won't work on all my systems). And I had to settle for Solaris's curses, rather than using my ncurses installation. Dommage! I'm hopping back to 2.0.8 next time, and hoping 2.2+ is a little friendlier when finally I'm compelled to submit to the force of "progress", rather than just assuming the latest is the greatest. -- -D. dgc@uchicago.edu NSIT University of Chicago From dan@ssc.com Tue Mar 5 16:17:21 2002 From: dan@ssc.com (Dan Wilder) Date: Tue, 5 Mar 2002 08:17:21 -0800 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <3C8498D3.F4770480@cascade-sys.com> References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> <3C8498D3.F4770480@cascade-sys.com> Message-ID: <20020305081720.B11094@ssc.com> On Tue, Mar 05, 2002 at 02:07:15AM -0800, James J. Besemer wrote: > > Carson Gaspar wrote: > > > Can one of the Python gurus here tell me if I just missed an obvious > > "correct" way to fix this, or if this is really a broken build process? > > Dunno. [Real helpful, I know.] > > But FWIW I'm running 2.0.8 and despite the documentation I couldn't get > things to install or run properly except with Python 1.5. Doc says 1.5 or > better so I figured 2.1 was fair game but couldn't get it to work. > > I figured doc was wrong and was ... satisfied ... when it worked with 1.5. > > FWIW, I think 1.5 Python and 2.0.8 Mailman are standard in 7.2 Linux. > Debian 3.0 gives you an option. Or you can install both versions of python under different names. >From this I get the feeling that many things which worked under Python 1.5 do not work under 2.1 or 2.2. -- ----------------------------------------------------------------- Dan Wilder Technical Manager & Editor SSC, Inc. P.O. Box 55549 Phone: 206-782-8808 Seattle, WA 98155-0549 URL http://embedded.linuxjournal.com/ ----------------------------------------------------------------- From barry@zope.com Tue Mar 5 16:35:07 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 11:35:07 -0500 Subject: [Mailman-Developers] Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> Message-ID: <15492.62395.581774.588700@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> What !@#$% idiot did the python 2.2 build system!? It CG> bombs out trying to compile the extensions, because _someone_ CG> got "clever" and decided to write the build system in CG> Python. And got it wrong. So it doesn't compile or link CG> properly. And after chasing through _8_ levels of indirection CG> without figuring out where it tries adding library arguments, CG> I just give up! For those who care, it's going insane trying CG> to build _socket, and _curses, and probably something CG> else. _socket is trying to link against openssl, but my CG> openssl libraries aren't where it expects them to be, and if I CG> hand-edit setup.py (yes, hand-edit - ARRRRGH!) to put the CG> correct paths in, it still doesn't work, I suspect because CG> it's not using -R or setting LD_RUN_PATH. I haven't even CG> looked at the other errors yet. CG> So, just how "recommended" is python 2.2? Can I just use my CG> python 2.0 installation until someone else makes this CG> nightmare go away? I, and lots of people, are using Python 2.2 today. I do all my primary testing on Python 2.2, so I feel confident in recommending it. Note that Mailman 2.1 will work on Python 2.1.x or 2.2.x, but I recently had to drop support for Python 2.0.x. Since you tell us nothing about what platform you're trying to build from, there's no way anyone can help you. I regularly build on various Linux distros with no problem. -Barry From barry@zope.com Tue Mar 5 16:35:52 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 11:35:52 -0500 Subject: [Mailman-Developers] Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> Message-ID: <15492.62440.31122.862532@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> Now to try and fix audioop and fpectl... You won't need these modules for Mailman, so if that's the only app you care about, I wouldn't bother. -Barry From barry@zope.com Tue Mar 5 16:50:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 11:50:19 -0500 Subject: [Mailman-Developers] Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> <515323171.1015301514@[192.168.0.1]> Message-ID: <15492.63307.268804.596015@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> *sigh* The problems with running such a low market share CG> platform like Solaris/SPARC *snort* Ah, okay. Well, I tried to get into the Solaris machines on the SF compile farm, but I couldn't seem to scp up a Python 2.2. tarball. I really don't have much time to muck with that, and I've got no other Solaris box at my disposal. Sigh. -Barry From barry@zope.com Tue Mar 5 16:52:26 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 11:52:26 -0500 Subject: [Mailman-Developers] Re: Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> <20020305153021.GW20284@dust.uchicago.edu> Message-ID: <15492.63434.156744.347314@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> I couldn't figure out how to make it compile without fpectl, DC> so I now have a dependency on libsunmath.so (which is a DC> licensed product, and ergo not installed on all my systems, so DC> my python won't work on all my systems). And I had to settle DC> for Solaris's curses, rather than using my ncurses DC> installation. Dommage! As those are both dynamic libraries, those dependencies are only linked to the .so's not to the Python executable itself. Mailman doesn't use either module so for this application, it shouldn't make a difference. -Barry From barry@zope.com Tue Mar 5 16:54:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 11:54:31 -0500 Subject: [Mailman-Developers] Python-2.2 disaster References: <513533140.1015299724@[192.168.0.1]> <514667500.1015300858@[192.168.0.1]> <3C8498D3.F4770480@cascade-sys.com> <20020305081720.B11094@ssc.com> Message-ID: <15492.63559.891839.2401@anthem.wooz.org> >>>>> "DW" == Dan Wilder writes: DW> From this I get the feeling that many things which worked DW> under Python 1.5 do not work under 2.1 or 2.2. If you mean Python 1.5 instead of 1.5.2 then you might be right. While both are extremely old, the latter was the gold standard for about 2 years. Most stuff that worked under 1.5.2 should work under 2.1 or 2.2. You may get some deprecation warnings, but MM2.0.8 should be compatible with any of those, although it has been an admittedly long time since I ran anything under Python 1.5.2. -Barry From carson@taltos.org Tue Mar 5 17:10:43 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 12:10:43 -0500 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <15492.62395.581774.588700@anthem.wooz.org> References: <15492.62395.581774.588700@anthem.wooz.org> Message-ID: <3562312.1015330242@[172.25.113.221]> --On Tuesday, March 05, 2002 11:35 AM -0500 "Barry A. Warsaw" wrote: > I, and lots of people, are using Python 2.2 today. I do all my > primary testing on Python 2.2, so I feel confident in recommending > it. FYI, 2.2 is completely DOA on Solaris 8/SPARC. After I got it to compile (and gained more grey hair), it ends up hanging on SMTPlib.connect(), somewhere in the bowels of hostname resolution. Either something is broken in the IPv6 support in Python, or Sun has a library bug. I wouldn't take a bet about whose fault it is ;-) > Since you tell us nothing about what platform you're trying to build > from, there's no way anyone can help you. I regularly build on > various Linux distros with no problem. I apologize for the less-than-thorough bug report. There's a reason I wrapped it in . I'm trying Python 2.1.2 now - it compiled cleanly, and as it's _socket module doesn't have IPv6 support, I hope I won't run into whatever bug is making 2.2 hang. -- Carson From howanitz@nindo.com Tue Mar 5 17:28:06 2002 From: howanitz@nindo.com (Keith Howanitz) Date: Tue, 5 Mar 2002 11:28:06 -0600 (CST) Subject: [Mailman-Developers] stopping spam harvesting In-Reply-To: <3562312.1015330242@[172.25.113.221]> Message-ID: Here is an interesting approach to stopping email address harvesting. http://www.linuxjournal.com//article.php?sid=5861 From barry@zope.com Tue Mar 5 17:30:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 12:30:18 -0500 Subject: [Mailman-Developers] Problem with Postfix virtual support in current CVS References: <520468171.1015306659@[192.168.0.1]> Message-ID: <15493.170.874858.336325@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> I _think_ I set this up properly, but please tell me if I got CG> something wrong: CG> $ bin/dumpdb /var/mailman/lists/bluefeather/config.db | grep CG> host_name\' 'host_name': 'bluefeather.org', >> From mm_cfg.py: CG> MTA = 'Postfix' POSTFIX_STYLE_VIRTUAL_DOMAINS = CG> ['bluefeather.org', 'boardstiffny.org'] CG> Yet after running genaliases, my CG> /var/mailman/data/virtual-mailman is zero-length. That's a bug. Fixed in CVS now. Thanks, -Barry From chuqui@plaidworks.com Tue Mar 5 17:30:31 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 05 Mar 2002 09:30:31 -0800 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <15492.63307.268804.596015@anthem.wooz.org> Message-ID: On 3/5/02 8:50 AM, "Barry A. Warsaw" wrote: > CG> *sigh* The problems with running such a low market share > CG> platform like Solaris/SPARC *snort* > > Ah, okay. Well, I tried to get into the Solaris machines on the SF > compile farm, but I couldn't seem to scp up a Python 2.2. tarball. (raises hand). Python 2.2 on Solaris isn't that tough. I think it took me three tries, and the glitches were mostly due to whether or not stuff was built in shared libraries and locations of those libraries. Here's my /lib: lrwxrwxrwx 1 root other 27 Sep 12 16:28 libgdbm.so.2 -> /usr/local/lib/libgdbm.so.2* lrwxrwxrwx 1 root other 30 Feb 1 00:05 libncurses.so.5 -> /usr/local/lib/libncurses.so.5 lrwxrwxrwx 1 root other 28 Feb 1 00:19 libpanel.so.5 -> /usr/local/lib/libpanel.so.5 lrwxrwxrwx 1 root other 24 Feb 1 00:20 libz.so.1 -> /usr/local/lib/libz.so.1* lrwxrwxrwx 1 root other 22 Feb 1 00:42 libz.so -> /usr/local/lib/libz.so* You can see the packages I've installed, which got installed in /usr/local/lib. The solaris ld.so seems to really, really want the shared library part available out of /lib. That was the only piece that caused me a bit of a teeth-grit. Everything else was pretty straightforward tracking-down-and-killing missing stuff. And yes, Solaris has a huge installed base in corporations -- but most of the open source developers are developing on Linux and BSD. Since none of us are PAYING them to develop, you shouldn't complain that it doesn't work on your machine. You should dig in and make it work and submit the patches back... (and I would have, except I didn't see anything in Python that WAS really broken. It was mostly a case of "my site doesn't look like you thought it would" stuff) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From barry@zope.com Tue Mar 5 17:32:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 12:32:27 -0500 Subject: [Mailman-Developers] Python-2.2 disaster References: <15492.62395.581774.588700@anthem.wooz.org> <3562312.1015330242@[172.25.113.221]> Message-ID: <15493.299.523747.87430@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> FYI, 2.2 is completely DOA on Solaris 8/SPARC. After I got it CG> to compile (and gained more grey hair), it ends up hanging on CG> SMTPlib.connect(), somewhere in the bowels of hostname CG> resolution. Either something is broken in the IPv6 support in CG> Python, or Sun has a library bug. I wouldn't take a bet about CG> whose fault it is ;-) :) The best bet at this point, if you want to pursue this further, is to submit a bug report to SF. There are definitely folks with access to Solaris who read those bug reports. Please include any output from compilation or configure, etc. I haven't had a Solaris system in going on 2 years now, and the last rev I think I used was 2.6 <5.6 wink>. -Barry From barry@zope.com Tue Mar 5 17:46:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 12:46:55 -0500 Subject: [Mailman-Developers] Current CVS update error References: <519813609.1015306004@[192.168.0.1]> Message-ID: <15493.1167.380659.963290@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> It looks like the install / update procedure does not create CG> qfiles/in, so I get the following when I run bin/update: The subdirs in qfiles get created as necessary, but you'd definitely hit a bug in bin/update regardless. I have a patch but it'll take me a few minutes to test upgrading from mm2.0.x -> mm2.1. Watch the checkins. -Barry From chuqui@plaidworks.com Tue Mar 5 17:47:33 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 05 Mar 2002 09:47:33 -0800 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: Message-ID: On 3/5/02 9:30 AM, "Chuq Von Rospach" wrote: > Python 2.2 on Solaris isn't that tough. I should note: my boxes are solaris 2.5 through Solaris 7. I haven't really started on 8 yet. YMMV. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From barry@zope.com Tue Mar 5 18:37:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 13:37:30 -0500 Subject: [Mailman-Developers] Current CVS update error References: <519813609.1015306004@[192.168.0.1]> <15493.1167.380659.963290@anthem.wooz.org> Message-ID: <15493.4202.613708.381394@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> The subdirs in qfiles get created as necessary, but you'd BAW> definitely hit a bug in bin/update regardless. I have a BAW> patch but it'll take me a few minutes to test upgrading from BAW> mm2.0.x -> mm2.1. Watch the checkins. Should be fixed now. -B From carson@taltos.org Tue Mar 5 21:23:58 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 16:23:58 -0500 Subject: [Mailman-Developers] How do I turn off line wrapping on template files? Message-ID: <18757782.1015345438@[172.25.113.221]> (Yesterday's CVS, Python 2.1.2, Solaris 8 SPARC) I'm trying to customize the e-mail messages that go out in response to a subscription (verify.txt and subscribeack.txt). Out-of-the-box, they get mangled by Util.wrap(), causing havoc with our attempts at formatting. For example, we can't have: Please contact one of the following people for more information: bozo@hotmail.com jesus@yahoo.com god@heaven.com It all appears on one line. Looking at the code, it looks like my choices are to wrap or not wrap - there's no magic code for "No, I really want a CRLF here!" That being the case, I tried adding raw=1 to the maketext calls for verify.txt (in MailList.py) and for subscribeack.txt (in Deliverer.py). It worked for verify.txt (huzzah!), but is still wrapping subscribeack.txt (wah!). So, am I missing some cool feature of wrap? If not, is there some reason adding raw=1 isn't working? -- Carson From Dan Mick Tue Mar 5 21:33:07 2002 From: Dan Mick (Dan Mick) Date: Tue, 5 Mar 2002 13:33:07 -0800 (PST) Subject: [Mailman-Developers] Python-2.2 disaster Message-ID: <200203052133.g25LX6cW023150@utopia.West.Sun.COM> > FYI, 2.2 is completely DOA on Solaris 8/SPARC. I'm using 2.2 daily on Solaris 8/SPARC. From barry@zope.com Tue Mar 5 21:38:37 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 16:38:37 -0500 Subject: [Mailman-Developers] How do I turn off line wrapping on template files? References: <18757782.1015345438@[172.25.113.221]> Message-ID: <15493.15069.122238.370544@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> So, am I missing some cool feature of wrap? Yup, any line started with whitespace will not be wrapped, so just indent those lines, say 4 spaces. -Barry From carson@taltos.org Tue Mar 5 21:48:04 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 16:48:04 -0500 Subject: [Mailman-Developers] How do I turn off line wrapping on template files? In-Reply-To: <18757782.1015345438@[172.25.113.221]> References: <18757782.1015345438@[172.25.113.221]> Message-ID: <20203300.1015346884@[172.25.113.221]> I just added a feature to wrap, that lets you specify line breaks. If the last 2 characters on a line are \n, those characters are removed, and that line is not filled. --- Utils.py.DIST Tue Mar 5 13:42:25 2002 +++ Utils.py Tue Mar 5 13:42:31 2002 @@ -107,6 +107,9 @@ continue if honor_leading_ws and line[0] in whitespace: fillthis = 0 + elif line[-2] == '\\' and line[-1] == 'n': + fillthis = 0 + line = line[0:-2] else: fillthis = 1 if fillprev and fillthis: From carson@taltos.org Tue Mar 5 21:49:27 2002 From: carson@taltos.org (Carson Gaspar) Date: Tue, 05 Mar 2002 16:49:27 -0500 Subject: [Mailman-Developers] How do I turn off line wrapping on template files? In-Reply-To: <15493.15069.122238.370544@anthem.wooz.org> References: <15493.15069.122238.370544@anthem.wooz.org> Message-ID: <20285899.1015346966@[172.25.113.221]> --On Tuesday, March 05, 2002 4:38 PM -0500 "Barry A. Warsaw" wrote: > >>>>>> "CG" == Carson Gaspar writes: > > CG> So, am I missing some cool feature of wrap? > > Yup, any line started with whitespace will not be wrapped, so just > indent those lines, say 4 spaces. I really don't want some lines to begin with whitespace, but I don't want them filled, either. See my previous message for a trivial patch. -- Carson From Dan Mick Tue Mar 5 21:58:08 2002 From: Dan Mick (Dan Mick) Date: Tue, 5 Mar 2002 13:58:08 -0800 (PST) Subject: [Mailman-Developers] list_members doesn't return the whole membership list Message-ID: <200203052158.g25Lw8cW025113@utopia.West.Sun.COM> Just sent this to Barry early Monday morning: Date: Mon, 4 Mar 2002 09:58:20 -0800 (PST) From: Dan Mick Subject: bug: list_members has a backwards test To: barry@wooz.org The ambiguously-named 'statusp' returns 'true' if the address should be filtered, so the tests are backwards: Index: list_members =================================================================== RCS file: /cvsroot/mailman/mailman/bin/list_members,v retrieving revision 2.4 diff -u -r2.4 list_members --- list_members 23 Feb 2002 06:40:44 -0000 2.4 +++ list_members 4 Mar 2002 17:58:09 -0000 @@ -179,14 +179,14 @@ rmembers.sort() for addr in rmembers: # Filter out nomails - if not statusp(mlist, addr, why): + if statusp(mlist, addr, why): continue print >> fp, addr if digest: dmembers.sort() for addr in dmembers: # Filter out nomails - if not statusp(mlist, addr, why): + if statusp(mlist, addr, why): continue # Filter out digest kinds if mlist.getMemberOption(addr, mm_cfg.DisableMime): > root@gandalf:/var/local/mailman/bin# ./dumpdb ../lists/test3/config.pck | grep user_options > 'user_options': {'marc@merlins.org': 266}, > root@gandalf:/var/local/mailman/bin# ./list_members test3 > root@gandalf:/var/local/mailman/bin# > > On bigger lists, list_members returns some of the list membership. It's not just > the digest or non digest members, it looks kinda random. > > I need to get some sleep, so I'll leave this for someone else to debug and > fix From barry@zope.com Wed Mar 6 04:22:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 5 Mar 2002 23:22:55 -0500 Subject: [Mailman-Developers] list_members doesn't return the whole membership list References: <20020305072925.GC27363@merlins.org> Message-ID: <15493.39327.662787.936726@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> root@gandalf:/var/local/mailman/bin# ./dumpdb MM> ../lists/test3/config.pck | grep user_options 'user_options': MM> {'marc@merlins.org': 266}, MM> root@gandalf:/var/local/mailman/bin# ./list_members test3 MM> root@gandalf:/var/local/mailman/bin# That's a bug, fixed now in cvs. MM> On bigger lists, list_members returns some of the list MM> membership. It's not just the digest or non digest members, it MM> looks kinda random. Hmm, do a cvs update and try again. How's it look now? -Barry From barry@zope.com Wed Mar 6 13:22:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 6 Mar 2002 08:22:32 -0500 Subject: [Mailman-Developers] How do I turn off line wrapping on template files? References: <18757782.1015345438@[172.25.113.221]> <20203300.1015346884@[172.25.113.221]> Message-ID: <15494.6168.451673.29924@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: CG> I just added a feature to wrap, that lets you specify line CG> breaks. If the last 2 characters on a line are \n, those CG> characters are removed, and that line is not filled. I'm not sure I want to add more rules to wrap(), so I'm going to punt on this for now. -Barry From barry@zope.com Wed Mar 6 13:48:46 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 6 Mar 2002 08:48:46 -0500 Subject: [Mailman-Developers] buglet, changing options on an already deleted member References: <20020305071955.GB27363@merlins.org> Message-ID: <15494.7742.597591.660397@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I bring up an admin page, MM> from the shell, I remove a user MM> I change the user options in the web form, and click submit MM> The error is correct, but mailman should probably return a MM> simple error in the web page instead of a traceback. Fixed, thanks. -Barry From barry@zope.com Wed Mar 6 15:18:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 6 Mar 2002 10:18:57 -0500 Subject: [Mailman-Developers] Re: updated patch: remove member from all the lists References: <20020305071024.GA27363@merlins.org> Message-ID: <15494.13153.347613.625321@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> This version of the patch add --fromall which lets you remove MM> a specified Email from all your lists (replaces my _alllists_ MM> special hack) Applied, thanks. -Barry From barry@zope.com Wed Mar 6 15:33:40 2002 From: barry@zope.com (barry@zope.com) Date: Wed, 6 Mar 2002 10:33:40 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> Message-ID: <15494.14036.373582.981056@anthem.wooz.org> >>>>> "JJB" == James J Besemer writes: JJB> I recently started running a relatively small mailing list JJB> using Mailman and am quite happy with it. I am a proficient JJB> Python developer and the fact that Mailman is Python-based JJB> was one reason I chose it with entheusiasm. I hope that in JJB> my spare time I'll be able to make some useful contributions. Cool! Since I'm strapped for time right now, I'm just going to comment briefly. JJB> Here are some of the areas I was thinking of working in. I JJB> throw them out in case someone else has already started or JJB> has ideas: Be sure you're working with MM2.1, and preferrably the cvs tree. Very soon now, MM2.1 will go into beta so that'll mean a feature freeze. JJB> 1. I would like to implement self.filter_prog, which I expect JJB> would be a filter on each incoming messages. There are some JJB> special things I can think of I'd like to do with my list. JJB> E.g., automatic tallying of poll results. The old filter_prog stuff is gone. A much better way to do this in MM2.1 is to write a handler module. See the Mailman/Handlers directory for examples. JJB> 2. Along those lines, I would like users to be able to elect JJB> to filter out HTML from their regular mail, in addition to JJB> digests. Seems this should be easy. You'd think! I've had a couple of patches contributed that filter out HTML, but I've not been able to whip them into shape for inclusion. I've basically given up hope for MM2.1, but will look at it again for the next release. The problem is that the naive approach isn't difficult, but for it to be robust is much more difficult. JJB> 3. Longer term, I would like the option of adding some info JJB> fields to the user database. E.g., I would like to store JJB> real names, addresses and phone numbers on one of my lists. Not hard to do in MM2.1, but I doubt I'll accept much extension in this area. The whole backend user database will be rewritten in a future version and IMO, such extra information ought to be kept in an external database like LDAP or some such. Then those databases ought to be easily integrated into Mailman's rosters. JJB> 4. It would be nice to reuse the existing list security as an JJB> umbrealla to cover other arbitrary, list-members-only web JJB> pages. E.g., some listers hate large graphics attachments JJB> (and they are problematic generally). I'd like to remove the JJB> image from the incoming message, publish it on a secure, JJB> lister-only web page and forward the mail with an URL JJB> substituted for the image attachment. Again, not hard to do. The MemberAdaptor API can help you here, and also take a look at the SecurityManager.py. Note also that MM2.1's Pipermail has some code to strip out attachments and store them separately in url space. Cheers, -Barry From mss@mawhrin.net Wed Mar 6 17:47:05 2002 From: mss@mawhrin.net (Mikhail Sobolev) Date: Wed, 6 Mar 2002 17:47:05 +0000 Subject: [Mailman-Developers] Small patch Message-ID: <20020306174705.GA19686@mawhrin.net> There are two same questions, but in one place there is a space at the end, while in the other there is not. I propose to remove the space in the first case. -- Misha Index: admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 2.60 diff -u -b -r2.60 admin.py --- admin.py 5 Mar 2002 04:57:51 -0000 2.60 +++ admin.py 6 Mar 2002 17:45:50 -0000 @@ -1053,7 +1053,7 @@ ]) table.AddRow([ # td 1 - Label(_('Send notifications to the list owner? ')), + Label(_('Send notifications to the list owner?')), # td 2 RadioButton('send_notifications_to_list_owner', 0, not mlist.admin_notify_mchanges).Format() From jb@cascade-sys.com Wed Mar 6 19:01:51 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Wed, 06 Mar 2002 11:01:51 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> Message-ID: <3C86679F.59B57394@cascade-sys.com> mac@wooz.org wrote: > Cool! Since I'm strapped for time right now, I'm just going to > comment briefly. Thanks for the various pointers. Dunno how long before I'll be productive (read Dangerous ;o). > You'd think! I've had a couple of patches contributed that filter out > HTML, but I've not been able to whip them into shape for inclusion. > I've basically given up hope for MM2.1, but will look at it again for > the next release. The problem is that the naive approach isn't > difficult, but for it to be robust is much more difficult. When you find more time I'd appreciate some more background on this. Wanting to filter out HTML (nb. from AOL accounts) is the #1 gripe from my users. The Python library has an HTML parser that I've used before and it works pretty well. I used it to translate HTML to HTML, inserting data in various named fields. But removal of the HTML is the default action of the code. Of course you don't really want simply to remove it. E.g., you'd want to include HREF's somehow, substitute the description for images, etc. In thinking about this since my first post, it occurrs to me that one difficulty would be having two versions of one incoming post being parceled out to a single list. Now, I presume, you have a single file in the queue. I've been wrong before but this doesn't seem like brain surgery. > such extra information ought to be kept in an > external database like LDAP or some such. Then those databases ought > to be easily integrated into Mailman's rosters. That makes perfect sense. Thanks again for the other pointers. [Now back to the paying customers.... ;o| Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From les@2pi.org Wed Mar 6 19:22:17 2002 From: les@2pi.org (Les Niles) Date: Wed, 6 Mar 2002 11:22:17 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C86679F.59B57394@cascade-sys.com> (jb@cascade-sys.com) References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> Message-ID: <200203061922.LAA28720@mutiny.2pi.org> On Wed, 06 Mar 2002 11:01:51 -0800 "James J. Besemer" wrote: > >mac@wooz.org wrote: >> You'd think! I've had a couple of patches contributed that filter out >> HTML, but I've not been able to whip them into shape for inclusion. >> I've basically given up hope for MM2.1, but will look at it again for >> the next release. The problem is that the naive approach isn't >> difficult, but for it to be robust is much more difficult. > >When you find more time I'd appreciate some more background on this. > >Wanting to filter out HTML (nb. from AOL accounts) is the #1 gripe from my >users. > >The Python library has an HTML parser that I've used before and it works >pretty well. I used it to translate HTML to HTML, inserting data in >various named fields. But removal of the HTML is the default action of >the code. Of course you don't really want simply to remove it. E.g., >you'd want to include HREF's somehow, substitute the description for >images, etc. Most of the time you really can just strip out the HTML. AOL, Outhouse, and most of the other clients that like to generate HTML put out multipart/alternative messages that include a text/plain section, so picking out the latter and dropping the other alternatives works pretty well. Almost all of the pure-HTML traffic I see is spam. I've been using one of the patches Barry referred to on some medium-sized lists for the past 1.5 years with no complaints and very few instances of message bodies disappearing entirely. (It was the release of AOL 6.0, which doesn't allow turning off HTML, that prompted me.) -les From jb@cascade-sys.com Wed Mar 6 19:40:11 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Wed, 06 Mar 2002 11:40:11 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> Message-ID: <3C86709B.C5F55E31@cascade-sys.com> Les Niles wrote: > (It was the release of AOL 6.0, which doesn't allow > turning off HTML, that prompted me.) Exactly. While, OTOH I agree these more robust formats are the future, it's insane to force them on users and not allow them to turn them off. --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From jwblist@olympus.net Wed Mar 6 21:29:50 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 6 Mar 2002 13:29:50 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <200203061922.LAA28720@mutiny.2pi.org> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> Message-ID: At 11:22 -0800 3/6/2002, Les Niles wrote: >Most of the time you really can just strip out the HTML. AOL, >Outhouse, and most of the other clients that like to generate HTML >put out multipart/alternative messages that include a text/plain >section, so picking out the latter and dropping the other >alternatives works pretty well. Eudora allows selection among plain text only, HTML only, plain and HTML (or cancel) when sending "styled" messages. (Mine is set up to ask each time, with plain text being the default.) I suspect that sending a few blank messages to a list and being chastised for it would be sufficient training for some. Apple's mail.app (the default mail program in Mac OS X) sends RTF, not HTML. (OK, so 128 point was extreme.) And unfortunately, out of the box it defaults to "Rich". I don't know what the list's processing will do to this sample. Date: Wed, 6 Mar 2002 13:26:26 -0800 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: multipart/alternative; boundary=Apple-Mail-1-635564387 Subject: This is a style test From: John Baxter To: jwblist@olympus.net Message-Id: X-Mailer: Apple Mail (2.481) X-olympus-virus-scan: Encoding found - scanned Testing style (or misuse thereof) -- John W. Baxter Port Ludlow, WA, USA The primary cause of problems is solutions. -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From marc_news@vasoftware.com Wed Mar 6 21:36:52 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 6 Mar 2002 13:36:52 -0800 Subject: [Mailman-Developers] list_members doesn't return the whole membership list In-Reply-To: <15493.39327.662787.936726@anthem.wooz.org> References: <20020305072925.GC27363@merlins.org> <15493.39327.662787.936726@anthem.wooz.org> Message-ID: <20020306213651.GC28464@merlins.org> On Tue, Mar 05, 2002 at 11:22:55PM -0500, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN writes: > > MM> root@gandalf:/var/local/mailman/bin# ./dumpdb > MM> ../lists/test3/config.pck | grep user_options 'user_options': > MM> {'marc@merlins.org': 266}, > MM> root@gandalf:/var/local/mailman/bin# ./list_members test3 > MM> root@gandalf:/var/local/mailman/bin# > > That's a bug, fixed now in cvs. Yeah, I saw the commit a few hours later :-) > MM> On bigger lists, list_members returns some of the list > MM> membership. It's not just the digest or non digest members, it > MM> looks kinda random. > > Hmm, do a cvs update and try again. How's it look now? I subscribed to mailman-checkins, it's easier, I just waited to see the commit :-) BTW, here's a small patch on top of that: --- list_members.mm Wed Mar 6 13:12:19 2002 +++ list_members Wed Mar 6 13:26:33 2002 @@ -103,11 +103,12 @@ kind = None args = sys.argv[1:] - if not args: - usage(0) while 1: - opt = args.pop(0) + try: + opt = args.pop(0) + except IndexError: + usage(1) if opt in ('-h', '--help'): usage(0) elif opt in ('-p', '--preserve'): It solves this: moremagic.m.o:/var/local/mailman/bin# ./list_members.mm -n Traceback (most recent call last): File "./list_members.mm", line 204, in ? main() File "./list_members.mm", line 110, in main opt = args.pop(0) IndexError: pop from empty list Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jb@cascade-sys.com Thu Mar 7 00:14:16 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Wed, 06 Mar 2002 16:14:16 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> Message-ID: <3C86B0D8.202BD41F@cascade-sys.com> John W Baxter wrote: > I suspect that sending a few blank messages to a list and being chastised > for it would be sufficient training for some. Yes, for some. ;o) I think my situation is that there is a very vocal minority who hate HTML and there is a similarly sized minority who can't figure out how to turn it off. Evidently the new version of AOL is for the most part HTML-only. Another faction doesn't object to HTML per se except that the text in such messages (for them) appear in too small a font and they can't figure out how to change it. The majority don't give a rip but a noticeable amount of list traffic is devoted to this tiresome topic. As the host, I'd like to solve the problem if I can. Someday... --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From jarrell@vt.edu Wed Mar 6 23:47:20 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 06 Mar 2002 18:47:20 -0500 Subject: [Mailman-Developers] Python-2.2 disaster In-Reply-To: <15492.63307.268804.596015@anthem.wooz.org> References: <513533140.1015299724@[192.168.0.1]> <515323171.1015301514@[192.168.0.1]> Message-ID: <5.1.0.14.2.20020306184426.065c30a0@lennier.cc.vt.edu> At 11:50 AM 3/5/02 -0500, Barry A. Warsaw wrote: >>>>>> "CG" == Carson Gaspar writes: > > CG> *sigh* The problems with running such a low market share > CG> platform like Solaris/SPARC *snort* > >Ah, okay. Well, I tried to get into the Solaris machines on the SF >compile farm, but I couldn't seem to scp up a Python 2.2. tarball. I >really don't have much time to muck with that, and I've got no other >Solaris box at my disposal. That last python build I was grinching about was 2.2 on a pair of solaris boxes. One 7, one 8. Once I clubbed bsddb to death, and got zlib working right, life was good. (need to install zlib kit on 7, and just uncomment the zlibmodule line. zlib comes with solaris 8, but required severe editing of the zlibmodule line to delete all the -I's and -L's (which might only have been an issue on my machine)). Other than that, things compiled just ducky, and 2.0.5 runs on it just fine. From chuqui@plaidworks.com Thu Mar 7 01:05:20 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 06 Mar 2002 17:05:20 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C86B0D8.202BD41F@cascade-sys.com> Message-ID: On 3/6/02 4:14 PM, "James J. Besemer" wrote: > As the host, I'd like to solve the problem if I can. Someday... First step is -- "I run this list, this is how I plan on running it, and if you insist on yelling about this stuff on the list, I'll kick YOU off first." There comes a point where you have to tell the inmates who runs the asylum. Otherwise, all you get is chaos. And some won't like the decision, and some will likely leave no matter which way you decide -- but you're probably losing people to the argument, for god's sake... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From jb@cascade-sys.com Thu Mar 7 01:18:49 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Wed, 06 Mar 2002 17:18:49 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: Message-ID: <3C86BFF9.A54EF746@cascade-sys.com> Chuq Von Rospach wrote: > First step is -- "I run this list, this is how I plan on running it, and if > you insist on yelling about this stuff on the list, I'll kick YOU off > first." I don't agree, certainly not with this issue. More generally -- the list IS the members -- not the admin or tools used. Anyway, the feature to strip HTML is my idea, not any of the member's. --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From jra@baylink.com Thu Mar 7 01:43:02 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 6 Mar 2002 20:43:02 -0500 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <87bse3pxcs.fsf@nausicaa.interq.or.jp>; from Ben Gertzfield on Tue, Mar 05, 2002 at 11:22:27AM +0900 References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> Message-ID: <20020306204302.00613@scfn.thpl.lib.fl.us> On Tue, Mar 05, 2002 at 11:22:27AM +0900, Ben Gertzfield wrote: > That would work in the best of all possible worlds (i.e. NOT the real > world :) but I think there is still information lost when converting > some charsets into Unicode, like Big5 and EUC-TW. Also, who knows if > we would corrupt PGP signatures by doing something like this? I'm pretty sure that the answers there are a) I do and b) we would. PGP almost certainly won't tolerate rewriting of the body, in much the same way that IPsec won't tolerate NAT rewrites on the channel. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jwblist@olympus.net Thu Mar 7 02:03:47 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 6 Mar 2002 18:03:47 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C86B0D8.202BD41F@cascade-sys.com> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86B0D8.202BD41F@cascade-sys.com> Message-ID: At 16:14 -0800 3/6/2002, James J. Besemer wrote: >Another faction doesn't object to HTML per se except that the text in such >messages (for them) >appear in too small a font and they can't figure out how to change it. Happens to me a lot since I read mail on my Macs, and a sensible size on a Windows machine (particularly in Times) is unreadably small here. (96 bit vs 72 bit issues). It happens on Web pages as well, where it's easy to change the size but I often don't bother. My solution is simple for mailing lists: if a message is hard to read, I don't read it (unless it seems to answer a question I posed, in which case I try). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From chuqui@plaidworks.com Thu Mar 7 04:29:52 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 06 Mar 2002 20:29:52 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3098291393_4131083 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 3/6/02 6:03 PM, "John W Baxter" wrote: > My solution is simple for mailing lists: if a message is hard to read, I > don't read it (unless it seems to answer a question I posed, in which case > I try). I agree with John. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. --B_3098291393_4131083 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Mailman-Developers] Please Allow Me To Introduce Myself...</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Verdana">On 3/6/02 6:03 PM, "John W Baxter" <jwbli= st@olympus.net> wrote:<BR> <BR> <FONT COLOR=3D"#000098"><BR> > My solution is simple for mailing lists:  if a message is hard to= read, I<BR> > don't read it (unless it seems to answer a question I posed, in which = case<BR> > I try).<BR> <BR> </FONT><FONT COLOR=3D"#FF0000"><FONT SIZE=3D"7">I agree with John.<BR> </FONT></FONT><FONT COLOR=3D"#000098"><BR> </FONT><BR> -- <BR> Chuq Von Rospach, Architech<BR> chuqui@plaidworks.com -- http://www.chuqui.com/<BR> <BR> Stress is when you wake up screaming and you realize you haven't fallen asl= eep yet.<BR> </FONT> </BODY> </HTML> --B_3098291393_4131083-- From barry@zope.com Thu Mar 7 05:20:26 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 7 Mar 2002 00:20:26 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> Message-ID: <15494.63642.131234.587632@anthem.wooz.org> >>>>> "JJB" == James J Besemer <jb@cascade-sys.com> writes: >> You'd think! I've had a couple of patches contributed that >> filter out HTML, but I've not been able to whip them into shape >> for inclusion. I've basically given up hope for MM2.1, but >> will look at it again for the next release. The problem is >> that the naive approach isn't difficult, but for it to be >> robust is much more difficult. JJB> When you find more time I'd appreciate some more background JJB> on this. I really owe Les feedback on his patch; it's the one I've done the most work on. It's on my laptop and if I can sync it up to cvs, I'll try to reboot my efforts tomorrow. JJB> Wanting to filter out HTML (nb. from AOL accounts) is the #1 JJB> gripe from my users. JJB> The Python library has an HTML parser that I've used before JJB> and it works pretty well. I used it to translate HTML to JJB> HTML, inserting data in various named fields. But removal of JJB> the HTML is the default action of the code. Of course you JJB> don't really want simply to remove it. E.g., you'd want to JJB> include HREF's somehow, substitute the description for JJB> images, etc. Here's the basic problem: there are lots of different use cases that fall under the rubric "filtering HTML". Some people want it stripped, some want it transformed, do we preserve links, etc, etc. It's hard to support everything everyone wants to do with HTML messages, /and/ do it in a way that's intuitive and easy to configure through the web. I'm not saying it's impossible, but it's a lot of work, and MM2.1 has to get to beta RSN. Plus, I think there are viable options (for the short term) without having this functionality in Mailman proper. E.g. demime. But I'll give it another look, and maybe something simple can satisfy 80% of the people out there. -Barry From barry@zope.com Thu Mar 7 05:38:33 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 7 Mar 2002 00:38:33 -0500 Subject: [Mailman-Developers] Missing footers with latest CVS References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <15494.64729.535773.898549@anthem.wooz.org> >>>>> "SJT" == Stephen J Turnbull <stephen@xemacs.org> writes: >>>>> "Ben" == Ben Gertzfield <che@debian.org> writes: Ben> This would violate RFC 1522: SJT> That's right. People with broken mailers have broken SJT> mailers. Make sure that things are robust for those with SJT> decent software, and then do what we can for the former poor SJT> souls. Totally agreed. I mean, look at me, a "dinosaur" who uses a MIME-aware MUA in a system that was never originally designed to support the stuff you get in email these days. And it's mostly bug free <wink>. (Aside to Stephen: do you know if Kyle still handles VM bug reports these days? ;). The only hope we have of interoperating is to support the standards, or at least not willfully break them <Hippocratic oath wink>. Which means if the charsets don't match, we can't simply tack on headers and footers. So we either don't add them or we add some multipart/mixed chrome and do it in a MIME-compliant way. I really don't want to think about PGP right now. Mailcrypt w/GnuPG seems to only sign or encrypt the body, and in a non-MIME way, so if we wanted to add headers and footers it seems like we'd be safe by wrapping the original body in multipart/mixed chrome. Of course you'd have to unpack the parts to verify (read) the signed (encrypted) part. Oh well, there's not really much more you /can/ do. -Barry From barry@zope.com Thu Mar 7 05:53:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 7 Mar 2002 00:53:48 -0500 Subject: [Mailman-Developers] list_members doesn't return the whole membership list References: <20020305072925.GC27363@merlins.org> <15493.39327.662787.936726@anthem.wooz.org> <20020306213651.GC28464@merlins.org> Message-ID: <15495.108.914922.220422@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: >> Hmm, do a cvs update and try again. How's it look now? MM> I subscribed to mailman-checkins, it's easier, I just waited MM> to see the commit :-) MM> BTW, here's a small patch on top of that: I also added a catch of a potential IndexError in the -o option. Thanks, -Barry From jb@cascade-sys.com Thu Mar 7 06:32:32 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Wed, 06 Mar 2002 22:32:32 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> Message-ID: <3C870980.76E9B2D@cascade-sys.com> "Barry A. Warsaw" wrote: > Here's the basic problem: there are lots of different use cases that > fall under the rubric "filtering HTML". Some people want it stripped, > some want it transformed, do we preserve links, etc, etc. It's hard > to support everything everyone wants to do with HTML messages, /and/ > do it in a way that's intuitive and easy to configure through the web. I see. I rather thought you meant there was some problem hooking up a filter or adding a switch to control it. > I'm not saying it's impossible, but it's a lot of work, and MM2.1 has > to get to beta RSN. Plus, I think there are viable options (for the > short term) without having this functionality in Mailman proper. I wasn't suggesting any change of plans for your release. I'm even offering to DO some or all of the work at some unspecified time in the future, when I'm more up to speed on the system.. Though if a miracle happened and it made it in the next relase, that'd be great. > E.g. demime. If I'm following all this -- you're going to fix some web page links and then we can look at the latest version of Demime and Stripmime. What's the URL? > But I'll give it another look, and maybe something simple can satisfy > 80% of the people out there. A perfectly adequate solution in my mind would simply be for the existing "plain" switch to apply to regular posts in addition to digests. Then, post process regular posts with whatever you now do with digests. The only thing the user needs is to turn the whole thing on or off. Within that, cavet emptor. Like Les said, simply removing all the formatting and leaving the original text would make almost everybody happy. In my tiny corner of the world, 98% of the cases are where a naive user entered some regular text, only it got posted as HTML, so it shows up as purple 6 point text or some crap. After a quick review of my HTML pocket ref, I'd say for extra credit I would handle the following cases specially: <A> -- echo the HREF <IMG> -- echo the ALT text <P> -- extra blank line And that would about cover it. The PhD version would format tables. If it's a totally gunked-up graphics page, the result might still look like hell but that's OK! An important concept from in the Analog world: Distortion is a perfectly acceptable response to certain inputs. It's probably spam anyway, so WTF? More later.... --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From che@debian.org Thu Mar 7 06:45:03 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 07 Mar 2002 15:45:03 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <15494.64729.535773.898549@anthem.wooz.org> (barry@zope.com's message of "Thu, 7 Mar 2002 00:38:33 -0500") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> Message-ID: <874rjsnafk.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: >>>>> "SJT" == Stephen J Turnbull <stephen@xemacs.org> writes: >>>>> "Ben" == Ben Gertzfield <che@debian.org> writes: Ben> This would violate RFC 1522: SJT> That's right. People with broken mailers have broken SJT> mailers. Make sure that things are robust for those with SJT> decent software, and then do what we can for the former poor SJT> souls. BAW> The only hope we have of interoperating is to support the BAW> standards, or at least not willfully break them <Hippocratic BAW> oath wink>. Which means if the charsets don't match, we BAW> can't simply tack on headers and footers. So we either don't BAW> add them or we add some multipart/mixed chrome and do it in a BAW> MIME-compliant way. Can we safely assume that all charsets folks will use with Mailman will have us-ascii as a subset? It seems to be the case so far. If so, I think the code I wrote can be loosened up a bit -- us-ascii headers/footers can *always* be added to a message, so if the list's language is US English, adding headers and footers should be fine no matter what the charset. If the list's language is not US English, though, we just simply cannot add a header/footer blindly unless the message explicitly says it's the same charset as the header/footer will be. Any other way lyes madness. :) BAW> I really don't want to think about PGP right now. Mailcrypt BAW> w/GnuPG seems to only sign or encrypt the body, and in a BAW> non-MIME way, so if we wanted to add headers and footers it BAW> seems like we'd be safe by wrapping the original body in BAW> multipart/mixed chrome. Of course you'd have to unpack the BAW> parts to verify (read) the signed (encrypted) part. Oh well, BAW> there's not really much more you /can/ do. Well, remember that old-style PGP bodies will have the whole: ===BEGIN PGP SIGNED MESSAGE=== blah blah ===BEGIN PGP SIGNATURE=== abcdef123456 ===END PGP SIGNED MESSAGE=== thing going, so we can safely add headers/footers to these kinds of messages, as they will be outside these ===VERY LOUD AREAS===. I don't know how it works for S/MIME, frankly. Ben -- Brought to you by the letters T and G and the number 17. "Ooh, don't touch him, HE'S got the wall sconses." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From stephen@xemacs.org Thu Mar 7 07:50:39 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 07 Mar 2002 16:50:39 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <15494.64729.535773.898549@anthem.wooz.org> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> Message-ID: <87n0xkvmsw.fsf@xemacs.org> Thread-relevant<wink>, so answered here. >>>>> "BAW" =3D=3D Barry A Warsaw <barry@zope.com> writes: BAW> (Aside to Stephen: do you know if Kyle still handles VM bug BAW> reports these days? ;). That depends. If you suggest providing support for correspondence with non-RFC-compliant MUAs, you get Belch.au as the bounce message. Otherwise, you get an answer, usually a fix.<wink> <OT> Tit-for-tat: what's the favored Pythonic wiki (software) these days? Preferably with full support for Japanese, if not, I'll add it. :-=FE </OT> --=20 Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac= .jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JA= PAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From stephen@xemacs.org Thu Mar 7 07:52:50 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 07 Mar 2002 16:52:50 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <874rjsnafk.fsf@nausicaa.interq.or.jp> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <874rjsnafk.fsf@nausicaa.interq.or.jp> Message-ID: <87it88vmp9.fsf@xemacs.org> >>>>> "Ben" == Ben Gertzfield <che@debian.org> writes: Ben> Can we safely assume that all charsets folks will use with Ben> Mailman will have us-ascii as a subset? It seems to be the Ben> case so far. Depends on how you define "subset". UTF-16 is what I have in mind. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From che@debian.org Thu Mar 7 08:03:01 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 07 Mar 2002 17:03:01 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <87it88vmp9.fsf@xemacs.org> ("Stephen J. Turnbull"'s message of "07 Mar 2002 16:52:50 +0900") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <874rjsnafk.fsf@nausicaa.interq.or.jp> <87it88vmp9.fsf@xemacs.org> Message-ID: <87u1rsls96.fsf@nausicaa.interq.or.jp> >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes: >>>>> "Ben" == Ben Gertzfield <che@debian.org> writes: Ben> Can we safely assume that all charsets folks will use with Ben> Mailman will have us-ascii as a subset? It seems to be the Ben> case so far. Stephen> Depends on how you define "subset". UTF-16 is what I Stephen> have in mind. Mein Gott. If people start sending mail in UTF-16.. wow. You gotta love the idea of architecture-dependant email. Ben -- Brought to you by the letters V and K and the number 9. "Ha ha! I have evaded you with the aid of these pasty white mints!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From stephen@xemacs.org Thu Mar 7 09:06:33 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 07 Mar 2002 18:06:33 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <87u1rsls96.fsf@nausicaa.interq.or.jp> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <874rjsnafk.fsf@nausicaa.interq.or.jp> <87it88vmp9.fsf@xemacs.org> <87u1rsls96.fsf@nausicaa.interq.or.jp> Message-ID: <87vgc8rbl2.fsf@xemacs.org> >>>>> "Ben" == Ben Gertzfield <che@debian.org> writes: Ben> Mein Gott. If people start sending mail in UTF-16.. wow. Outhouse Abcess. <wink, wink, nudge, nudge> Say no more, eh? And yes, I have gotten such. (A _very_ broken beta of Outhouse for Lose2k beta was responsible: the HTML tags were in ASCII ... surely I repeat myself? or aren't you reading TLUG these days, once-and-future listmaster, sir?) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From bramk@gx.nl Thu Mar 7 14:23:44 2002 From: bramk@gx.nl (Bram de Kruijff) Date: Thu, 7 Mar 2002 15:23:44 +0100 Subject: [Mailman-Developers] Thread not shown allthough In-Reply-To present Message-ID: <6C9EC88CAD726B49A43EE2E2B2AD6E534EB6DB@maul.gx.nl> Hi all, allthough I found a lot of questions about why mailman/pipermail doesn't show threads when mail is transferred by outlook/exchange in the archives, but unfortuanatly no answer that solves the problem ;( I read in one of the posts that threading is done based on; - Message-ID - References - In-Reply-To But then why doesn't it work? According to the mbox of my archive messages sent by outlook/exchange users don't contain a References header but DO contain Message-ID and In-Reply-To headers. In the same archive messages sent with mutt do contain a References header and are shown threaded Does pipermail realy check the In-Reply-To? Is something wrong with the format used? eg; In-Reply-To: <6C9EC88CAD726B49A43EE2E2B2AD6E5383E93C@maul.gx.nl> any ideas? thanks in advance! Bram _____________________________________________________________ Bram de Kruijff___________ <GX> creative online development _______________________ http://www.gx.nl | mailto:bramk@gx.nl From rob@web.ca Thu Mar 7 17:12:14 2002 From: rob@web.ca (Rob Ellis) Date: Thu, 7 Mar 2002 12:12:14 -0500 Subject: [Mailman-Developers] 2.0.8 - qrunner on solaris Message-ID: <20020307121214.L38424@web.ca> I'm not sure if this is appropriate here, so apologies in advance if it isn't... We're using Mailman 2.0.8 on a sun ultra with solaris 8, and we were running into two problems with qrunner... The first was a race condition where this code in qrunner - # If the .db file has no corresponding .msg file, we might as well - # remove the .db file, since there's little we can do about it. - if not os.path.exists(root+'.msg'): - syslog('qrunner', 'Unlinking orphaned .db file: %s.db' % root) - os.unlink(root+'.db') was unlinking .db files before their corresponding .msg files were created. We just removed those lines and it seems to be ok -- no orphaned .db files and no more orphaned .msg files. The second problem was that qrunner was crashing on some kinds of bounce messages (?), causing messages to pile up in the queue occasionally. It was generating errors like this: > Traceback (most recent call last): > File "/usr/local/mailman/cron/qrunner", line 277, in ? > kids = main(lock) > File "/usr/local/mailman/cron/qrunner", line 247, in main > keepqueued = dispose_message(mlist, msg, msgdata) > File "/usr/local/mailman/cron/qrunner", line 121, in dispose_message > if BouncerAPI.ScanMessages(mlist, mimemsg): > File "/usr/local/mailman/Mailman/Bouncers/BouncerAPI.py", line 59, in ScanMessages > addrs = func(msg) > File "/usr/local/mailman/Mailman/Bouncers/DSN.py", line 46, in process > if string.lower(msg.gettype()) <> 'multipart/report' or \ > File "/usr/local/lib/python2.1/string.py", line 51, in lower > return s.lower() > AttributeError : 'None' object has no attribute 'lower' The patch below seems to fix the problem (?)... we're now seeing some errors like this: bounce loop detected from: mailer-daemon@web.net but at least qrunner keeps running and the queue is getting cleared. - Rob -- Rob Ellis <rob@web.ca> System Administrator, Web Networks * --- Mailman/Bouncers/DSN.py 14 Nov 2001 15:57:09 -0000 1.1.1.2 +++ Mailman/Bouncers/DSN.py 7 Mar 2002 16:29:02 -0000 1.2 @@ -43,7 +43,7 @@ def process(msg): - ctype = msg.gettype() + ctype = msg.gettype() or '' param = msg.getparam('report-type') or '' if string.lower(ctype) <> 'multipart/report' or \ string.lower(param) <> 'delivery-status': From rodolfo@pilas.net Thu Mar 7 21:16:31 2002 From: rodolfo@pilas.net (Rodolfo Pilas) Date: 07 Mar 2002 18:16:31 -0300 Subject: [Mailman-Developers] Attachments Message-ID: <1015535801.3539.106.camel@julieta> I had MM 2.1a4+ from CVS downloaded February 07,2002. Today I upload to the latest version of CVS and I have just seen the following problems: SUBJECT: Subject line that said [Test] label now say =A1Test=BF=20 (I used MM with Spanish language) ATTACHMENT I do not receive attachments, MM brokes attachment: This is a source of last part of the header an complete message (without text, only with attachment) that I receive: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=3D"=3D-VDRv7n6c29BFJBk4/S1O"; charset=3D"es" Content-Transfer-Encoding: 8bit X-Evolution-Source: imap://rodolfo.pilas@mydomain.com/ --=3D-VDRv7n6c29BFJBk4/S1O-- That's all! As soon as I re-install the CVS version of Feb.07 all return to the normal way. --=20 Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@pilas.net Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=3D# Apocalipsis Now % Cuarteto de Nos #=3D- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint =3D DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Thu Mar 7 23:14:02 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 7 Mar 2002 18:14:02 -0500 Subject: [Mailman-Developers] forwarded message from Lisa M. Opus Goldstein Message-ID: <15495.62522.11772.833283@anthem.wooz.org> --3/tf6c9+MU Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here's a great way to help with Mailman even if you don't fancy yourself a hacker. Documentation, as always, lags far behind. I'd be happy to work with someone (or perhaps a group of someones), on the technical side, but a good technical writer I'm not. -Barry --3/tf6c9+MU Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Return-Path: <gnu-prog-admin@gnu.org> Delivered-To: barry@mail.wooz.org Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by mail.wooz.org (Postfix) with ESMTP id 71AB4D35F2 for <barry@wooz.org>; Thu, 7 Mar 2002 17:59:49 -0500 (EST) Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16j6os-00076p-00; Thu, 07 Mar 2002 17:57:06 -0500 Received: from opus by fencepost.gnu.org with local (Exim 3.33 #1 (Debian)) id 16j6OU-0004ML-00; Thu, 07 Mar 2002 17:29:50 -0500 Message-ID: <20020307222950.GH21338@gnu.org> User-Agent: Mutt/1.3.25i Errors-To: gnu-prog-admin@gnu.org Precedence: bulk List-Help: <mailto:gnu-prog-request@gnu.org?subject=help> List-Post: <mailto:gnu-prog@gnu.org> List-Subscribe: <http://mail.gnu.org/mailman/listinfo/gnu-prog>, <mailto:gnu-prog-request@gnu.org?subject=subscribe> List-Id: GNU Maintainers Announcement List <gnu-prog.gnu.org> List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/gnu-prog>, <mailto:gnu-prog-request@gnu.org?subject=unsubscribe> List-Archive: <http://mail.gnu.org/mailman/private/gnu-prog/> From: "Lisa M. Opus Goldstein" <opus@gnu.org> Sender: gnu-prog-admin@gnu.org To: gnu-prog@gnu.org Subject: Publishing GNU Documentation Date: Thu, 7 Mar 2002 17:29:50 -0500 X-BeenThere: gnu-prog@gnu.org X-Mailman-Version: 2.0.5 X-Followup-Discussion-To: gnu-prog-discuss@gnu.org Dear Maintainers, I am looking for maintainers to work with me to develop their program's documentation for publication by the Free Software Foundation's publishing department, the GNU Press. As most of you probably know, the Free Software Foundation publishes physical documentation for a few major programs; we have been doing this since we were founded in 1985. Sales of these books are an important source of income for the FSF. It helps pay for our machines, our staff, and by extension helps keep the entire GNU Project going. Accordingly, I was hired to increase the number of titles that the FSF prints and to increase their distribution range. I have created the publishing name "GNU Press", a logo, and redesigned the general appearance of the manual covers. Newer versions of Texinfo now allow inclusion of images, charts, and pictures, so I am hoping to beef up future documentation with such visuals. I am now looking for documentation to publish, and am very interested in actively working with maintainers to develop their documentation for publication by us. Smaller programs' documentation can be bundled with related programs into one book; I would also be very interested in working with some maintainers to help me develop these collections. Additionally, I would like to increase the percentage of documentation that are tutorials rather than simply reference manuals. I believe that teaching people how to use free software is very important, and want to emphasize this through which books I select for publication. If you are interested in participating in any of these projects, or if you have any ideas or suggestions, please contact me. I look forward to hearing from people. Best Regards, Lisa M. Goldstein opus@gnu.org Business Manager Tel 617-542-5942 Ext. 15 Free Software Foundation Fax 617-542-2652 _______________________________________________ GNU Maintainers Announcement List gnu-prog@gnu.org http://mail.gnu.org/mailman/listinfo/gnu-prog --3/tf6c9+MU-- From barry@zope.com Thu Mar 7 23:17:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 7 Mar 2002 18:17:39 -0500 Subject: [Mailman-Developers] forwarded message from Hye-Shik Chang Message-ID: <15495.62739.799026.983300@anthem.wooz.org> --V5YPYL6fTy Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Do we have anybody who could do a Korean translation for Mailman? -Barry --V5YPYL6fTy Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Return-Path: <i18n-sig-admin@python.org> Delivered-To: barry@mail.wooz.org Received: from digicool.com (unknown [63.100.190.15]) by mail.wooz.org (Postfix) with ESMTP id 6C350D35F2 for <barry@wooz.org>; Thu, 7 Mar 2002 18:01:14 -0500 (EST) Received: from <i18n-sig-admin@python.org> by digicool.com (CommuniGate Pro RULES 3.4) with RULES id 3683883; Thu, 07 Mar 2002 18:01:16 -0500 Received: from smtp.zope.com ([63.100.190.95] verified) by digicool.com (CommuniGate Pro SMTP 3.4) with ESMTP id 3683878; Thu, 07 Mar 2002 18:01:16 -0500 Received: from mail.python.org (mail.python.org [63.102.49.29]) by smtp.zope.com (8.11.6/8.11.2) with ESMTP id g27N0vf03126; Thu, 7 Mar 2002 18:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 3.35 #2) id 16j6rt-0004Gi-00; Thu, 07 Mar 2002 18:00:13 -0500 Received: from [211.216.53.129] (helo=kornet.hanirc.org ident=root) by mail.python.org with esmtp (Exim 3.35 #2) id 16j6rP-0004FC-00 for i18n-sig@python.org; Thu, 07 Mar 2002 17:59:43 -0500 Received: (from perky@localhost) by kornet.hanirc.org (8.11.6/8.11.5) id g27Mxb130392 for i18n-sig@python.org; Fri, 8 Mar 2002 07:59:37 +0900 (KST) (envelope-from perky) Message-ID: <20020308075937.A24873@fallin.lv> User-Agent: Mutt/1.2.5.1i Organization: Yonsei University Precedence: bulk List-Help: <mailto:i18n-sig-request@python.org?subject=help> List-Post: <mailto:i18n-sig@python.org> List-Subscribe: <http://mail.python.org/mailman/listinfo/i18n-sig>, <mailto:i18n-sig-request@python.org?subject=subscribe> List-Id: Python internationalization and localization <i18n-sig.python.org> List-Unsubscribe: <http://mail.python.org/mailman/listinfo/i18n-sig>, <mailto:i18n-sig-request@python.org?subject=unsubscribe> List-Archive: <http://mail.python.org/pipermail/i18n-sig/> From: Hye-Shik Chang <perky@fallin.lv> Sender: i18n-sig-admin@python.org To: i18n-sig@python.org Subject: [I18n-sig] KoreanCodecs 2.0 released Date: Fri, 8 Mar 2002 07:59:37 +0900 X-Autogenerated: Mirror X-Mirrored-by: <i18n-sig-admin@python.org> X-BeenThere: i18n-sig@python.org X-Mailman-Version: 2.0.8 (101270) X-MailScanner: Found to be clean Hello! I've released KoreanCodecs 2.0. It is reimplemented based on JapaneseCodecs 1.4. Supported Charsets: euc-kr (aliases: ksc5601, ksx1001) cp949 (aliases: uhc, ms949) iso-2022-kr johab unijohab qwerty2bul (aliases: 2bul) Additional Utility: korean.hangul : Korean character analyzer Some of those charsets doesn't have StreamWriter/Reader yet. And, it has only pure python implementation now. (Sorry (: I'll add C impl. soon.) http://sourceforge.net/projects/koco If you use FreeBSD, just do # cd /usr/ports/korean/pycodec # make install clean Ciao. -- Hye-Shik Chang <perky@fallin.lv> Yonsei University, Seoul _______________________________________________ I18n-sig mailing list I18n-sig@python.org http://mail.python.org/mailman/listinfo/i18n-sig --V5YPYL6fTy-- From Dan Mick <dmick@utopia.West.Sun.COM> Fri Mar 8 02:28:19 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Thu, 7 Mar 2002 18:28:19 -0800 (PST) Subject: [Mailman-Developers] Bug in latest CVS: confirm.py Message-ID: <200203080228.g282SKcW001887@utopia.West.Sun.COM> Bug in latest confirm.py: passwords not completely stamped out. Breaks Web subscription confirmations. Index: confirm.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/confirm.py,v retrieving revision 2.14 diff -u -r2.14 confirm.py --- confirm.py 4 Mar 2002 20:17:50 -0000 2.14 +++ confirm.py 8 Mar 2002 02:27:15 -0000 @@ -302,7 +302,7 @@ else: digest = None userdesc = UserDesc(fullname=cgidata.getvalue('realname', None), - password=pw, digest=digest, lang=lang) + digest=digest, lang=lang) op, addr, pw, digest, lang = mlist.ProcessConfirmation( cookie, userdesc) except Errors.MMNeedApproval: @@ -329,14 +329,14 @@ optionsurl = mlist.GetOptionsURL(addr, absolute=1) doc.SetTitle(title) doc.AddItem(Header(3, Bold(FontAttr(title, size='+2')))) - if not setformpasswd: - doc.AddItem(_("""\ - The passwords you entered in the confirmation screen did not - match, so your original subscription password will be used - instead. Your password will have been generated by Mailman if - you left the password fields blank. In any event, your - membership password will be sent to you in a separate - acknowledgement email.<p>""")) +## if not setformpasswd: +## doc.AddItem(_("""\ +## The passwords you entered in the confirmation screen did not +## match, so your original subscription password will be used +## instead. Your password will have been generated by Mailman if +## you left the password fields blank. In any event, your +## membership password will be sent to you in a separate +## acknowledgement email.<p>""")) doc.AddItem(_('''\ You have successfully confirmed your subscription request for "%(addr)s" to the %(listname)s mailing list. A separate From James.Madill@duke.edu Fri Mar 8 02:43:38 2002 From: James.Madill@duke.edu (James Madill) Date: Thu, 7 Mar 2002 21:43:38 -0500 Subject: [Mailman-Developers] Can you set a list's password via the command line? Message-ID: <OF58C7F85E.CA4DC9EA-ON85256B76.000E9934@mc.duke.edu> This is a multipart message in MIME format. --=_alternative 000ECE1985256B76_= Content-Type: text/plain; charset="us-ascii" In moving the 175 mailing lists from one machine (version 2.0.1) to another (version 2.0.8), all of the list passwords are no longer working. Is there a way to set a list's password via the command line? I'd hate to have to manually set each one & send it to the list admin(s). -- James o o o o o o o . . . _______________________ _______=======_T___ o _____ |James Madill | |Duke Univ Med Ctr| >.][__n_n_| D[ ====|____ |james.madill@duke.edu| | (919) 286-6384 | (________|__|_[____/____]_|_____________________|_|_________________| _/oo O-O-O ` oo oo 'o^o^o o^o^o` 'o^o o^o` -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- <http://www.duke.edu/~madil001/> --=_alternative 000ECE1985256B76_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">In moving the 175 mailing lists from one machine (version 2.0.1)  to another (version 2.0.8), all of the list passwords are no longer working.</font> <br> <br><font size=2 face="sans-serif">Is there a way to set a list's password via the command line?  I'd hate to have to manually set each one & send it to the list admin(s).<br> </font><font size=3><tt><br> -- James<br> <br>      </tt></font><font size=3 color=#b0b0b0><tt>o o o o o o o . . .</tt></font><font size=3><tt>   </tt></font><font size=3 color=blue><tt>_______________________</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>_______=======_</tt></font><font size=3><tt>T</tt></font><font size=3 color=red><tt>___</tt></font><font size=3><tt><br>    </tt></font><font size=3 color=#b0b0b0><tt>o</tt></font><font size=3><tt>      _____            </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>James Madill         </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt>Duke Univ Med Ctr</tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br> </tt></font><font size=3 color=#f0c02c><tt>></tt></font><font size=3><tt>.][__n_n_| D[  ====|____  </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>james.madill@duke.edu</tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt> (919) 286-6384  </tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br>  (________|__|_[____/____]_</tt></font><font size=3 color=blue><tt>|_____________________|</tt></font><font size=3><tt>_</tt></font><font size=3 color=red><tt>|_________________|</tt></font><font size=3><tt><br> _/oo  O-O-O  `  oo     oo  'o^o^o           o^o^o` 'o^o           o^o`<br> </tt></font><font size=3 color=#b0802c><tt>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-</tt></font><font size=3><tt><br> <http://www.duke.edu/~madil001/></tt></font> --=_alternative 000ECE1985256B76_=-- From che@debian.org Fri Mar 8 03:02:33 2002 From: che@debian.org (Ben Gertzfield) Date: Fri, 08 Mar 2002 12:02:33 +0900 Subject: [Mailman-Developers] [BUG] Users are created as moderated in CVS mailman Message-ID: <87it87kbhy.fsf@nausicaa.interq.or.jp> I'm not at all sure why this is, but on a completely fresh install of CVS mailman, even though DEFAULT_NEW_MEMBER_OPTIONS = 256, all my new list members are created with the 'moderated' flag on. The only custom options I have in Mailman/mm_cfg.py are: DEFAULT_SERVER_LANGUAGE = 'ja' DEFAULT_URL_PATTERN = 'http://%s/cgi-mailman/' [ben@nausicaa:/usr/local/mailman]% sudo python -i bin/withlist test-us-ascii Loading list test-us-ascii (unlocked) >>> m.members {'che@debian.org': 0, 'ben@gmo.jp': 0} >>> m.new_member_options 256 >>> m.user_options {'che@debian.org': 392, 'ben@gmo.jp': 392} # Bitfield for user options. See DEFAULT_LIST_OPTIONS above to set defaults # for all new lists. Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() DontReceiveOwnPosts = 2 # Non-digesters only AcknowledgePosts = 4 DisableMime = 8 # Digesters only ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 392 is 256 + 128 + 8. How is this getting set? Ben -- Brought to you by the letters P and A and the number 19. "A squib is a firecracker." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Fri Mar 8 03:39:00 2002 From: che@debian.org (Ben Gertzfield) Date: Fri, 08 Mar 2002 12:39:00 +0900 Subject: [Mailman-Developers] [PATCH] Always add footer for us-ascii lists Message-ID: <87vgc7iv8r.fsf@nausicaa.interq.or.jp> This patch solves Dan Mick's problem where people posting with the charset iso-8859-1 or utf-8 were not having the footer added to the list, which was set to use us-ascii. Since all the charsets we support are strictly supersets of us-ascii, I think it's always safe to add the footer to plain text messages of any charset when the list's charset is us-ascii. (No, UTF-16 will not be supported with this change. But it wouldn't have been supported with the old system anyway..) Tested patch follows, against Mailman CVS. -- Brought to you by the letters P and I and the number 11. "You have my pills!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ Index: Decorate.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Decorate.py,v retrieving revision 2.10 diff -u -r2.10 Decorate.py --- Decorate.py 23 Feb 2002 06:46:16 -0000 2.10 +++ Decorate.py 8 Mar 2002 01:44:35 -0000 @@ -61,12 +61,18 @@ # matches the charset of the list's preferred language. This is a # suboptimal solution, and should be solved by allowing a list to have # multiple headers/footers, for each language the list supports. + # + # Also, if the list's preferred charset is us-ascii, we can always + # safely add the header/footer to a plain text message since all + # charsets Mailman supports are strict supersets of us-ascii -- + # no, UTF-16 emails are not supported yet. mcset = msg.get_param('charset', 'us-ascii') lcset = Utils.GetCharSet(mlist.preferred_language) msgtype = msg.get_type('text/plain') # BAW: If the charsets don't match, should we add the header and footer by # MIME multipart chroming the message? - if not msg.is_multipart() and msgtype == 'text/plain' and mcset == lcset: + if (not msg.is_multipart() and msgtype == 'text/plain' and + (lcset == 'us-ascii' or mcset == lcset)): payload = header + msg.get_payload() + footer msg.set_payload(payload) elif msg.get_type() == 'multipart/mixed': From les@2pi.org Fri Mar 8 06:08:54 2002 From: les@2pi.org (Les Niles) Date: Thu, 7 Mar 2002 22:08:54 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <15494.63642.131234.587632@anthem.wooz.org> (barry@zope.com) References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> Message-ID: <200203080608.WAA03141@mutiny.2pi.org> On Thu, 7 Mar 2002 00:20:26 -0500 barry@zope.com (Barry A. Warsaw) wrote: >Here's the basic problem: there are lots of different use cases that >fall under the rubric "filtering HTML". Some people want it stripped, >some want it transformed, do we preserve links, etc, etc. It's hard >to support everything everyone wants to do with HTML messages, /and/ >do it in a way that's intuitive and easy to configure through the web. >I'm not saying it's impossible, but it's a lot of work, and MM2.1 has >to get to beta RSN. Plus, I think there are viable options (for the >short term) without having this functionality in Mailman proper. >E.g. demime. Translation systems, whether speech recognition, natural language translation, or reformatting the content of email, are fundamentally imperfect. That's why worrying about making an HTML filter intuitive and easily configurable is important -- those attributes are exactly what make a translation system usable and useful. I think the various types of "filtering HTML" fit into a couple of broad categories. One is translation: converting HTML content into some other format in which most or all of the semantic content is maintained. The other is stripping: removing HTML sections entirely. The former is harder, more error-prone, and open to incompatible interpretations of what constitutes the "right" translation. Stripping, OTOH, is simpler, more predictable, and can usefully be applied to other MIME types that a list admin might deem verbotten, but not nearly as powerful. I'm suggesting that both types of filtering are useful in MM's processing, but can and probably should be presented as separate functions in the configuration UI since their roles and characteristics are rather different. -les From jb@cascade-sys.com Fri Mar 8 06:46:16 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Thu, 07 Mar 2002 22:46:16 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> <200203080608.WAA03141@mutiny.2pi.org> Message-ID: <3C885E38.4A1695CF@cascade-sys.com> Les Niles wrote: > Translation systems, whether speech recognition, natural language > translation, or reformatting the content of email, are > fundamentally imperfect. That's why worrying about making an HTML > filter intuitive and easily configurable is important -- those > attributes are exactly what make a translation system usable and > useful. > > I think the various types of "filtering HTML" fit into a couple of > broad categories. One is translation: converting HTML content into > some other format in which most or all of the semantic content is > maintained. The other is stripping: removing HTML sections > entirely. The former is harder, more error-prone, and open to > incompatible interpretations of what constitutes the "right" > translation. Stripping, OTOH, is simpler, more predictable, and > can usefully be applied to other MIME types that a list admin might > deem verbotten, but not nearly as powerful. I'm suggesting that > both types of filtering are useful in MM's processing, but can and > probably should be presented as separate functions in the > configuration UI since their roles and characteristics are rather > different. Very well put. --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From rommel@suse.de Fri Mar 8 14:16:36 2002 From: rommel@suse.de (Heiko Rommel) Date: Fri, 8 Mar 2002 15:16:36 +0100 (CET) Subject: [Mailman-Developers] migration from Majordomo to Mailman Message-ID: <Pine.LNX.4.43.0203081456510.8017-101000@Poincare.suse.de> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168463740-4823034-1015596996=:8017 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, just in case somebody finds it usefull I'm including a perl script that will largely easy the migration from Majordomo to Mailman 2.0 - especially if you have more than a few lists. The process of migration is only half-automatic since there are a bunch of params in Majordomo which have no exact counterpart in Mailman. On the other hand, there are some new params in Mailman which had to be set to a default value. The script is far from being perfect - but it worked from me and the 208 lists I had to migrate ;-) Heiko Rommel phone +49-911-740 53 696 SuSE GmbH fax +49-911-741 77 55 Deutschherrnstr. 15-19 mail rommel@suse.de 90429 Nuernberg www http://www.suse.de/ Germany --168463740-4823034-1015596996=:8017 Content-Type: APPLICATION/x-perl; name="majordomo2mailman.pl" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="majordomo2mailman.pl" IyEvdXNyL2Jpbi9wZXJsIC13CgojIG1ham9yZG9tbzJtYWlsbWFuLnBsIC0g TWlncmF0ZSBNYWpvcmRvbW8gbWFpbGluZyBsaXN0cyB0byBNYWlsbWFuIG1h aWxpbmcgbGlzdHMKIyAgICAgICAgICBDb3B5cmlnaHQgKEMpIDIwMDIgSGVp a28gUm9tbWVsIChyb21tZWxAc3VzZS5kZSkKCiMKIyBjb21tZW50cyBvbiBw b3NzaWJsZSBkZWJ1ZyBtZXNzYWdlcyBkdXJpbmcgdGhlIGNvbnZlcnNpb246 CiMKIyAibm90IGFuIHZhbGlkIGVtYWlsIGFkZHJlc3MiIDogdGhvc2UgYWRk cmVzc2VzIGFyZSByZWplY3RlZCwgaS5lLiBub3QgaW1wb3J0ZWQgaW50byB0 aGUgTWFpbG1hbiBsaXN0CiMgIm5vdCBhIG51bWVyaWMgdmFsdWUiIDogc3Vj aCBhIHZhbHVlIHdpbGwgYmUgY29udmVydGVkIHRvIDAgKHouQi4gbWF4bGVu Z3RoKQojICJhbHJlYWR5IHN1YnNjcmliZWQiIDogd2lsbCBvbmx5IG9uY2Ug YmUgc3Vic2NyaWJlZCBvbiB0aGUgTWFpbG1hbiBsaXN0CiMgIi4uLnVtYnJl bGxhLi4uIiBvciAiLi4udGFib28uLi4iIC0+IE1haWxtYW4tQWRtaW4tR3Vp ZGUKCnVzZSBzdHJpY3Q7CnVzZSBHZXRvcHQ6Okxvbmc7CnVzZSBGY250bDsK dXNlIFBPU0lYIHF3ICh0bXBuYW0pOwoKdXNlIHZhcnMgcXcgKAoJICAgICAk bWFqb3Jkb21vICRteWRvbWFpbiAkbXl1cmwKCSAgICAgJGFsaWFzaW4gJGxp c3RkaXIKCSAgICAgJGFsaWFzb3V0ICRtYWlsbWFuYmluCgkgICAgICR1bWJy ZWxsYV9tZW1iZXJfc3VmZml4ICRwcml2YXRlIAoJICAgICAkbmV3c3NlcnZl ciAkbmV3c3ByZWZpeAoJICAgICAkc3VzZWhhY2sgJHN1c2VhcmNodXNlcgoJ ICAgICAkaGVscCAkZGVidWcgJHVwZGF0ZSAkYWxsICR1c2FnZW1zZwoJICAg ICAqRkgKCSAgICAgJW1sYWxpYXNlcyAlbWxvd25lcnMgJW1sYXBwcm92ZXJz CgkgICAgICVkZWZhdWx0bWxjb25mICVtbGNvbmYKCSAgICAgJWRlZmF1bHRt bWNvbmYgJW1tY29uZgopOwoKIwojIGFkanVzdCB5b3VyIHNpdGUtc3BlY2lm aWMgc2V0dGluZ3MgaGVyZQojCgokbXlkb21haW4gICAgICAgICAgICAgICA9 ICJteS5kb21haW4iOwokbWFqb3Jkb21vICAgICAgICAgICAgICA9ICJtYWpv cmRvbW8iOyAjIHRoZSBtYXN0ZXIgTWFqb3Jkb21vIGFkZHJlc3MgZm9yIHlv dXIgc2l0ZQokYWxpYXNpbiAgICAgICAgICAgICAgICA9ICIvdmFyL2xpYi9t YWpvcmRvbW8vYWxpYXNlcyI7CiRsaXN0ZGlyICAgICAgICAgICAgICAgID0g Ii92YXIvbGliL21ham9yZG9tby9saXN0cyI7CiRhbGlhc291dCAgICAgICAg ICAgICAgID0gIi90bXAvYWxpYXNlcyI7CiRteXVybCAgICAgICAgICAgICAg ICAgID0gImh0dHA6Ly9teS5kb21haW4vbWFpbG1hbi8iOwokbWFpbG1hbmJp biAgICAgICAgICAgICA9ICIvdXNyL2xpYi9tYWlsbWFuL2JpbiI7CiR1bWJy ZWxsYV9tZW1iZXJfc3VmZml4ID0gIi1vd25lciI7CiRwcml2YXRlICAgICAg ICAgICAgICAgID0gInllcyI7ICMgaXMgdGhpcyBhIHByaXZhdGUvSW50cmFu ZXQgc2l0ZSA/CiRuZXdzc2VydmVyICAgICAgICAgICAgID0gIm5ld3MubXku ZG9tYWluIjsKJG5ld3NwcmVmaXggICAgICAgICAgICAgPSAiaW50ZXJuLiI7 Cgokc3VzZWhhY2sgPSAibm8iOwokc3VzZWFyY2h1c2VyID0gImFyY2hkdW1t eSI7CgojCiMgMCkKIyBwYXJzZSB0aGUgY29tbWFuZCBsaW5lIGFyZ3VtZW50 cwojCgokdXNhZ2Vtc2cgPSAidXNhZ2U6IG1ham9yZG9tbzJtYWlsbWFuIFst aHwtLWhlbHBdIFstZHwtLWRlYnVnXSBbLXV8LS11cGRhdGVdIDwgKC1hfC0t YWxsKSB8IGxpc3Qtb2YtbWFpbGluZ2xpc3RzID4iOwoKR2V0T3B0aW9ucygK ICAgICAgICAgICAiaHxoZWxwIiA9PiBcJGhlbHAsCgkgICAiZHxkZWJ1ZyIg PT4gXCRkZWJ1ZywKCSAgICJhfGFsbCIgPT4gXCRhbGwsCgkgICAidXx1cGRh dGUiID0+IFwkdXBkYXRlCikgb3IgZGllICIkdXNhZ2Vtc2dcbiI7CgppZiAo ZGVmaW5lZCgkaGVscCkpIHsgZGllICIkdXNhZ2Vtc2dcbiI7IH0KCmlmICgo bm90IGRlZmluZWQoJGFsbCkpIGFuZCAoQEFSR1Y8MSkpIHsgZGllICIkdXNh Z2Vtc2dcbiI7IH0KCmlmICgkPCkgeyBkaWUgInRoaXMgc2NyaXB0IG11c3Qg YmUgcnVuIGFzIHJvb3QhXG4iOyB9CgojCiMgMSkKIyBidWlsZCBhIGxpc3Qg b2YgYWxsIGFsaWFzZXMgYW5kIGV4dHJhY3QgdGhlIG5hbWUgb2YgbWFpbGlu ZyBsaXN0cyBwbHVzIHRoZWlyIG93bmVycwojCgolbWxhbGlhc2VzID0gJW1s b3duZXJzID0gJW1sYXBwcm92ZXJzID0gKCk7CgpvcGVuIChGSCwgIjwgJGFs aWFzaW4iKSBvciBkaWUgImNhbid0IG9wZW4gJGFsaWFzaW5cbiI7Cgp3aGls ZSAoPEZIPikgewogICMgZmlyc3QsIGJ1aWxkIGEgbGlzdCBvZiBhbGwgYWN0 aXZlIGFsaWFzZXMgYW5kIHRoZWlyIHJlc29sdXRpb24KICBpZiAoL14oW15c IzpdKylccyo6XHMqKC4qKSQvKSB7CiAgICAkbWxhbGlhc2VzeyQxfSA9ICQy OwogIH0KfQoKbXkgJG1sYWxpYXM7CmZvciAkbWxhbGlhcyAoa2V5cyAlbWxh bGlhc2VzKSB7CiAgIyBpZiB3ZSBlbmNvdW50ZXIgYW4gYWxpYXMgd2l0aCA6 aW5jbHVkZTogYXMgZXhwYW5zaW9uCiAgIyBpdCBpcyBzYXZlIHRvIGFzc3Vt ZSB0aGF0IHRoZSBhbGlhcyBoYXMgdGhlIGZvcm0KICAjIDxtYWlsaW5nbGlz dD4tb3V0Z29pbmcgLQogICMgdGhhdCB3YXkgd2UgZmluZCB0aGUgbmFtZXMg b2YgYWxsIGFjdGl2ZSBtYWlsaW5nIGxpc3RzCiAgaWYgKCRtbGFsaWFzZXN7 JG1sYWxpYXN9ID1+IC9cOmluY2x1ZGVcOi8pIHsKICAgIG15ICRtbDsKICAg ICgkbWwgPSAkbWxhbGlhcykgPX4gcy8tb3V0Z29pbmcvL2c7CiAgICAkbWxv d25lcnN7JG1sfSA9ICRtbGFsaWFzZXN7Im93bmVyLSRtbCJ9OwogICAgJG1s YXBwcm92ZXJzeyRtbH0gPSAkbWxhbGlhc2VzeyIkbWwtYXBwcm92YWwifTsK ICB9Cn0KCmNsb3NlIChGSCk7CgojCiMgMikKIyBmb3IgZWFjaCBsaXN0IHJl YWQgdGhlIE1ham9yZG9tbyBjb25maWd1cmF0aW9uIHBhcmFtcwojIGFuZCBj cmVhdGUgYSBNYWlsbWFuIGNsb25lCiMKCm15ICRtbDsKZm9yICRtbCAoKGRl ZmluZWQgKCRhbGwpKSA/IHNvcnQga2V5cyAlbWxvd25lcnMgOiBAQVJHVikg ewoKICBpbml0X2RlZmF1bHRtbGNvbmYoJG1sKTsKICAlbWxjb25mID0gJWRl ZmF1bHRtbGNvbmY7CgogIGluaXRfZGVmYXVsdG1tY29uZigkbWwpOwogICVt bWNvbmYgPSAlZGVmYXVsdG1tY29uZjsKCiAgbXkgQHByaXZpbGVnZWQ7ICMg YWRkcmVzc2VzIHRoYXQgYXJlIG1lbnRpb25lZCBpbiByZXN0cmljdF9wb3N0 CiAgbXkgQG1lbWJlcnM7CiAgbXkgKCRwcmltYXJ5b3duZXIsIEBzZWNvbmRh cnlvd25lcik7CiAgbXkgKCRwcmltYXJ5YXBwcm92ZXIsIEBzZWNvbmRhcnlh cHByb3Zlcik7CgogIG15ICgkc2tleSwgJHRlcm1pbmF0b3IpOwogIG15ICRm aWxlbmFtZTsKICBteSBAYXJnczsKCiAgIwogICMgYSkKICAjIHBhcnNlIHRo ZSBjb25maWd1cmF0aW9uIGZpbGUKICAjCgogIG9wZW4gKEZILCAiPCAkbGlz dGRpci8kbWwuY29uZmlnIikgb3IgZGllICJjYW4ndCBvcGVuICRsaXN0ZGly LyRtbC5jb25maWdcbiI7CgogIHdoaWxlICg8Rkg+KSB7CiAgICAjIGtleSA9 IHZhbHVlID8KICAgIGlmICgvXlxzKihbXj1cI1xzXSspXHMqPVxzKiguKilc cyokLykgewogICAgICAkbWxjb25meyQxfSA9ICQyOwogICAgfQogICAgIyBr ZXkgPDwgRU9GCiAgICAjIHZhbHVlCiAgICAjIEVPRiA/CiAgICBlbHNpZiAo L15ccyooW148XCNcc10rKVxzKjw8XHMqKC4qKVxzKiQvKSB7CiAgICAgICgk c2tleSwgJHRlcm1pbmF0b3IpID0gKCQxLCAkMik7CiAgICAgIHdoaWxlICg8 Rkg+KSB7CglsYXN0IGlmICgvXiR0ZXJtaW5hdG9yXHMqJC8pOwoJJG1sY29u Znskc2tleX0gLj0gJF87CiAgICAgIH0KICAgICAgY2hvbXAgJG1sY29uZnsk c2tleX07CiAgICB9CiAgfQoKICBjbG9zZSAoRkgpOwoKICAjCiAgIyBiKQog ICMgdGVzdCBpZiB0aGVyZSBhcmUgc28tY2FsbGVkIGZsYWcgZmlsZXMgKGNs dWUgdGhhdCB0aGlzIGlzIGFuIG9sZC1zdHlsZSBNYWpvcmRvbW8gbGlzdHMp CiAgIyBhbmQgb3ZlcndyaXRlIHByZXZpb3VzbHkgcGFyc2VkIHZhbHVlcwog ICMgKHN0b2xlbiBmcm9tIG1ham9yZG9tbzo6Y29uZmlnX3BhcnNlLnBsOiBo YW5kbGVfZmxhZ19maWxlcygpKQogICMKCiAgaWYgKCAtZSAiJGxpc3RkaXIv JG1sLnByaXZhdGUiKSB7CiAgICAkbWxjb25meyJnZXRfYWNjZXNzIn0gPSAi Y2xvc2VkIjsKICAgICRtbGNvbmZ7ImluZGV4X2FjY2VzcyJ9ID0gImNsb3Nl ZCI7CiAgICAkbWxjb25meyJ3aG9fYWNjZXNzIn0gPSAiY2xvc2VkIjsKICAg ICRtbGNvbmZ7IndoaWNoX2FjY2VzcyJ9ID0gImNsb3NlZCI7CiAgfQoKICAk bWxjb25meyJzdWJzY3JpYmVfcG9saWN5In0gPSAiY2xvc2VkIiBpZiAoIC1l ICIkbGlzdGRpci8kbWwuY2xvc2VkIik7CiAgJG1sY29uZnsidW5zdWJzY3Jp YmVfcG9saWN5In0gPSAiY2xvc2VkIiBpZiAoIC1lICIkbGlzdGRpci8kbWwu Y2xvc2VkIik7CgogIGlmICggLWUgIiRsaXN0ZGlyLyRtbC5hdXRvIiAmJiAt ZSAiJGxpc3RkaXIvJG1sLmNsb3NlZCIpIHsKICAgIHByaW50IFNUREVSUiAi c293b2hsICRtbC5hdXRvIGFscyBhdWNoICRtbC5jbG9zZWQgZXhpc3RpZXJl bi4gV+RobGUgJG1sLmNsb3NlZFxuIjsgCiAgfQogIGVsc2UgewogICAgJG1s Y29uZnsic3Vic2NyaWJlX3BvbGljeSJ9ID0gImF1dG8iIGlmICggLWUiJGxp c3RkaXIvJG1sLmF1dG8iKTsgCiAgICAkbWxjb25meyJ1bnN1YnNjcmliZV9w b2xpY3kifSA9ICJhdXRvIiBpZiAoIC1lIiRsaXN0ZGlyLyRtbC5hdXRvIik7 IAogIH0KCiAgJG1sY29uZnsic3RyaXAifSA9IDEgaWYgKCAtZSAiJGxpc3Rk aXIvJG1sLnN0cmlwIik7CiAgJG1sY29uZnsibm9hZHZlcnRpc2UifSA9ICIv LiovIiBpZiAoIC1lICIkbGlzdGRpci8kbWwuaGlkZGVuIik7CgogICMgYWRt aW5fcGFzc3dkOgogICRmaWxlbmFtZSA9ICIkbGlzdGRpci8iIC4gJG1sY29u ZnsiYWRtaW5fcGFzc3dkIn07CiAgaWYgKCAtZSAiJGxpc3RkaXIvJG1sLnBh c3N3ZCIgKSB7CiAgICAkbWxjb25meyJhZG1pbl9wYXNzd2QifSA9IHJlYWRf ZnJvbV9maWxlKCIkbGlzdGRpci8kbWwucGFzc3dkIik7CiAgfQogIGVsc2lm ICggLWUgIiRmaWxlbmFtZSIgKSB7CiAgICAkbWxjb25meyJhZG1pbl9wYXNz d2QifSA9IHJlYWRfZnJvbV9maWxlKCIkZmlsZW5hbWUiKTsKICB9CiAgIyBl bHNlIHRha2UgaXQgdmVyYmF0aW0KCiAgIyBhcHByb3ZlX3Bhc3N3ZDoKICAk ZmlsZW5hbWUgPSAiJGxpc3RkaXIvIiAuICRtbGNvbmZ7ImFwcHJvdmVfcGFz c3dkIn07CiAgaWYgKCAtZSAiJGxpc3RkaXIvJG1sLnBhc3N3ZCIgKSB7CiAg ICAkbWxjb25meyJhcHByb3ZlX3Bhc3N3ZCJ9ID0gcmVhZF9mcm9tX2ZpbGUo IiRsaXN0ZGlyLyRtbC5wYXNzd2QiKTsKICB9CiAgZWxzaWYgKCAtZSAiJGZp bGVuYW1lIiApIHsKICAgICRtbGNvbmZ7ImFwcHJvdmVfcGFzc3dkIn0gPSBy ZWFkX2Zyb21fZmlsZSgiJGZpbGVuYW1lIik7CiAgfQogICMgZWxzZSB0YWtl IGl0IHZlcmJhdGltCgogICMKICAjIGMpCiAgIyBhZGQgc29tZSBpbmZvcm1h dGlvbiBmcm9tIGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBmaWxlcwogICMK CiAgIyByZXN0cmljdF9wb3N0CiAgaWYgKGRlZmluZWQgKCRtbGNvbmZ7InJl c3RyaWN0X3Bvc3QifSkpIHsKICAgIEBwcml2aWxlZ2VkID0gKCk7CiAgICBm b3IgJGZpbGVuYW1lIChzcGxpdCAvXHMrLywgJG1sY29uZnsicmVzdHJpY3Rf cG9zdCJ9KSB7CiAgICAgIG9wZW4gKEZILCAiPCAkbGlzdGRpci8kZmlsZW5h bWUiKSBvciBkaWUgImNhbid0IG9wZW4gJGxpc3RkaXIvJGZpbGVuYW1lXG4i OwogICAgICBwdXNoIChAcHJpdmlsZWdlZCwgPEZIPik7CiAgICAgIGNob21w IEBwcml2aWxlZ2VkOwogICAgICBjbG9zZSAoRkgpOwogICAgfQogIH0KCiAg aWYgKCRzdXNlaGFjayA9fiBtL3llcy9pKSB7CiAgICBAcHJpdmlsZWdlZCA9 IGdyZXAoIS8kc3VzZWFyY2h1c2VyXEAkbXlkb21haW4vaSwgQHByaXZpbGVn ZWQpOwogIH0KCiAgJG1sY29uZnsicHJpdmlsZWdlZCJ9ID0gXEBwcml2aWxl Z2VkOwoKICAjIG1lbWJlcnMKICBAbWVtYmVycyA9ICgpOwogIG9wZW4gKEZI LCAiPCAkbGlzdGRpci8kbWwiKSBvciBkaWUgImNhbid0IG9wZW4gJGxpc3Rk aXIvJG1sXG4iOwogIHB1c2ggKEBtZW1iZXJzLCA8Rkg+KTsKICBjaG9tcCBA bWVtYmVyczsKICBjbG9zZSAoRkgpOwoKICAkbWxjb25meyJnYXRlZCJ9ID0g Im5vIjsKCiAgaWYgKCRzdXNlaGFjayA9fiBtL3llcy9pKSB7CiAgICBpZiAo Z3JlcCgvJHN1c2VhcmNodXNlclxAJG15ZG9tYWluL2ksIEBtZW1iZXJzKSkg ewogICAgICAkbWxjb25meyJnYXRlZCJ9ID0gInllcyI7CiAgICB9CiAgICBA bWVtYmVycyA9IGdyZXAoIS8kc3VzZWFyY2h1c2VyXEAkbXlkb21haW4vaSwg QG1lbWJlcnMpOwogIH0KCiAgJG1sY29uZnsibWVtYmVycyJ9ID0gXEBtZW1i ZXJzOwoKICAjIGludHJvIG1lc3NhZ2UKICBpZiAob3BlbiAoRkgsICI8ICRs aXN0ZGlyLyRtbC5pbnRybyIpKSB7CiAgICB7IGxvY2FsICQvOyAkbWxjb25m eyJpbnRybyJ9ID0gPEZIPjsgfQogIH0KICBlbHNlIHsgJG1sY29uZnsiaW50 cm8ifSA9ICIiOyB9CgogICMgaW5mbyBtZXNzYWdlCiAgaWYgKG9wZW4gKEZI LCAiPCAkbGlzdGRpci8kbWwuaW5mbyIpKSB7CiAgICB7IGxvY2FsICQvOyAk bWxjb25meyJpbmZvIn0gPSA8Rkg+OyB9CiAgfQogIGVsc2UgeyAkbWxjb25m eyJpbmZvIn0gPSAiIjsgfQogIAogICMKICAjIGQpCiAgIyB0YWtlIG92ZXIg c29tZSBvdGhlciBwYXJhbXMgaW50byB0aGUgY29uZmlndXJhdGlvbiB0YWJs ZQogICMKCiAgJG1sY29uZnsibmFtZSJ9ID0gIiRtbCI7CgogICgkcHJpbWFy eW93bmVyLCBAc2Vjb25kYXJ5b3duZXIpID0gCiAgICBleHBhbmRfYWxpYXMg KHNwbGl0ICgvXHMqLFxzKi8sIGFsaWFzc3ViKCRtbG93bmVyc3skbWx9KSkp OwoKICAoJHByaW1hcnlhcHByb3ZlciwgQHNlY29uZGFyeWFwcHJvdmVyKSA9 CiAgICBleHBhbmRfYWxpYXMgKHNwbGl0ICgvXHMqLFxzKi8sIGFsaWFzc3Vi KCRtbGFwcHJvdmVyc3skbWx9KSkpOwoKICAkbWxjb25meyJwcmltYXJ5b3du ZXIifSA9ICRwcmltYXJ5b3duZXI7CiAgJG1sY29uZnsic2Vjb25kYXJ5b3du ZXIifSA9IFxAc2Vjb25kYXJ5b3duZXI7CgogICRtbGNvbmZ7InByaW1hcnlh cHByb3ZlciJ9ID0gJHByaW1hcnlhcHByb3ZlcjsKICAkbWxjb25meyJzZWNv bmRhcnlhcHByb3ZlciJ9ID0gXEBzZWNvbmRhcnlhcHByb3ZlcjsKCiAgIwog ICMgZGVidWdnaW5nIG91dHB1dAogICMKCiAgaWYgKGRlZmluZWQgKCRkZWJ1 ZykpIHsKICAgIHByaW50ICIjIyMjIyMjIyMjIyMjIyMjIyMjIyMgJG1sICMj IyMjIyMjIyMjIyMjIyMjIyMjXG4iOwogICAgZm9yICRza2V5IChzb3J0IGtl eXMgJW1sY29uZikgewogICAgICBpZiAoZGVmaW5lZCAoJG1sY29uZnskc2tl eX0pKSB7IHByaW50ICIkc2tleSA9ICRtbGNvbmZ7JHNrZXl9XG4iOyB9CiAg ICAgIGVsc2UgeyBwcmludCAiJHNrZXkgPSAoPylcbiI7IH0KICAgIH0KICAg IG15ICRwcml2OwogICAgZm9yICRwcml2IChAcHJpdmlsZWdlZCkgewogICAg ICBwcmludCAiXHQkbWw6ICRwcml2XG4iOwogICAgfQogIH0KCiAgIwogICMg ZSkKICAjIHdpdGggdGhlIGhlbHAgb2YgTWFpbG1hbiBjb21tYW5kcyAtIGNy ZWF0ZSBhIG5ldyBsaXN0IGFuZCBzdWJzY3JpYmUgdGhlIG9sZCBzdGFmZgog ICMKCiAgaWYgKGRlZmluZWQoJHVwZGF0ZSkpIHsKICAgIHByaW50ICJ1cGRh dGluZyBjb25maWd1cmF0aW9uIG9mIFwiJG1sXCJcbiI7CiAgfQogIGVsc2Ug ewogICAgIyBNYWlsbWFuIGxpc3RzIGNhbiBpbml0aWFsbHkgYmUgb25seSBj cmVhdGVkIHdpdGggb25lIG93bmVyCiAgICBAYXJncyA9ICgiJG1haWxtYW5i aW4vbmV3bGlzdCIsICItcSIsICItbyIsICIkYWxpYXNvdXQiLCAiJG1sIiwg JG1sY29uZnsicHJpbWFyeW93bmVyIn0sICRtbGNvbmZ7ImFkbWluX3Bhc3N3 ZCJ9KTsKICAgIHN5c3RlbSAoQGFyZ3MpID09IDAgb3IgZGllICJzeXN0ZW0g QGFyZ3MgZmFpbGVkOiAkPyI7CiAgfQogICAKICAjIE1haWxtYW4gYWNjZXB0 cyBvbmx5IHN1YnNjcmliZXIgbGlzdHMgPiAwCiAgaWYgKEBtZW1iZXJzID4g MCkgewogICAgJGZpbGVuYW1lID0gdG1wbmFtKCk7CiAgICBvcGVuIChGSCwg Ij4gJGZpbGVuYW1lIikgb3IgZGllICJjYW4ndCBvcGVuICRmaWxlbmFtZVxu IjsKICAgIGZvciAkc2tleSAoQG1lbWJlcnMpIHsKICAgICAgcHJpbnQgRkgg IiRza2V5IiAuICJcbiI7CiAgICB9CiAgICBjbG9zZSAoRkgpOwogICAgQGFy Z3MgPSAoIiRtYWlsbWFuYmluL2FkZF9tZW1iZXJzIiwgIi1uIiwgIiRmaWxl bmFtZSIsICItLXdlbGNvbWUtbXNnPW4iLCAiJG1sIik7CiAgICBzeXN0ZW0g KEBhcmdzKSA9PSAwIG9yIGRpZSAic3lzdGVtIEBhcmdzIGZhaWxlZDogJD8i OwogIH0KCiAgIwogICMgZikKICAjICJ0cmFuc2xhdGUiIHRoZSBNYWpvcmRv bW8gbGlzdCBjb25maWd1cmF0aW9uCiAgIwoKICBtMm0oKTsKCiAgIyB3cml0 ZSB0aGUgTWFpbG1hbiBjb25maWcKCiAgJGZpbGVuYW1lID0gdG1wbmFtKCk7 CgogIG9wZW4gKEZILCAiPiAkZmlsZW5hbWUiKSBvciBkaWUgImNhbid0IG9w ZW4gJGZpbGVuYW1lXG4iOwogIGZvciAkc2tleSAoc29ydCBrZXlzICVtbWNv bmYpIHsKICAgIHByaW50IEZIICIkc2tleSA9ICIgLiAkbW1jb25meyRza2V5 fSAuICJcbiI7CiAgfQogIGNsb3NlIChGSCk7CgogIEBhcmdzID0gKCIkbWFp bG1hbmJpbi9jb25maWdfbGlzdCIsICItaSIsICIkZmlsZW5hbWUiLCAiJG1s Iik7CiAgc3lzdGVtIChAYXJncykgPT0gMCBvciBkaWUgInN5c3RlbSBAYXJn cyBmYWlsZWQ6ICQ/IjsKCiAgdW5saW5rKCRmaWxlbmFtZSkgb3IgcHJpbnQg U1RERVJSICJ1bmFibGUgdG8gdW5saW5rIFwiJGZpbGVuYW1lXCIhXG4iOwoK fQoKZXhpdCAwOwoKIyMjIyMjIyMjIyMjIwojIHN1YnMKIyMjIyMjIyMjIyMj IwoKIwojIEkgZG9uJ3Qga25vdyBob3cgdG8gd3JpdGUgUGVybCBjb2RlCiMg dGhlcmVmb3IgSSBuZWVkIHRoaXMgc3R1cGlkIHByb2NlZHVyZSB0byBjbGVh bmx5IHJlYWQgYSB2YWx1ZSBmcm9tIGZpbGUKIwoKc3ViIHJlYWRfZnJvbV9m aWxlIHsKICBteSAkdmFsdWU7CiAgbG9jYWwgKkZIOwoKICBvcGVuIChGSCwg IjwgJF9bMF0iKSBvciBkaWUgImNhbid0IG9wZW4gJF9bMF1cbiI7CiAgJHZh bHVlID0gPEZIPjsKICBjaG9tcCAkdmFsdWU7CiAgY2xvc2UgKEZIKTsKCiAg cmV0dXJuICR2YWx1ZTsKfQoKCiMKIyBhZGQgIkAkbXlkb21haW4iIHRvIGVh Y2ggZWxlbWVudCB0aGF0IGRvZXMgbm90IGNvbnRhaW4gYSAiQCIKIwoKc3Vi IGV4cGFuZF9hbGlhcyB7CiAgcmV0dXJuIG1hcCAgeyAobm90ICRfID1+IC9A LykgPyAkXyAuPSAiXEAkbXlkb21haW4iIDogJF8gfSBAXzsKfQoKIwojIHJl cGxhY2UgdGhlIHR5cGljYWwgb3duZXItbWFqb3Jkb21vIGFsaWFzZXMKIwoK c3ViIGFsaWFzc3ViIHsKICBteSAkc3RyaW5nID0gJF9bMF07CgogICRzdHJp bmcgPX4gcy8ob3duZXItJG1ham9yZG9tb3wkbWFqb3Jkb21vLW93bmVyKS9t YWlsbWFuLW93bmVyL2dpOwoKICByZXR1cm4gJHN0cmluZzsKfQoKIwojIGRl ZmF1bHQgdmFsdWVzIG9mIE1ham9yZG9tbyBtYWlsaW5nIGxpc3RzCiMgKHN0 b2xlbiBmcm9tIG1ham9yZG9tbzo6Y29uZmlnX3BhcnNlLnBsOiAla25vd25f a2V5cykKIwoKc3ViIGluaXRfZGVmYXVsdG1sY29uZiB7CiAgbXkgJG1sID0g JF9bMF07CgogICVkZWZhdWx0bWxjb25mPSggIAoJCSAgICAgJ3dlbGNvbWUn LAkieWVzIiwKCQkgICAgICdhbm5vdW5jZW1lbnRzJywJInllcyIsCgkJICAg ICAnZ2V0X2FjY2VzcycsCSJvcGVuIiwKCQkgICAgICdpbmRleF9hY2Nlc3Mn LAkib3BlbiIsCgkJICAgICAnd2hvX2FjY2VzcycsCSJvcGVuIiwKCQkgICAg ICd3aGljaF9hY2Nlc3MnLAkib3BlbiIsCgkJICAgICAnaW5mb19hY2Nlc3Mn LAkib3BlbiIsCgkJICAgICAnaW50cm9fYWNjZXNzJywJIm9wZW4iLAoJCSAg ICAgJ2FkdmVydGlzZScsCSIiLAoJCSAgICAgJ25vYWR2ZXJ0aXNlJywJIiIs CgkJICAgICAnZGVzY3JpcHRpb24nLAkiIiwKCQkgICAgICdzdWJzY3JpYmVf cG9saWN5JywJIm9wZW4iLAoJCSAgICAgJ3Vuc3Vic2NyaWJlX3BvbGljeScs CSJvcGVuIiwKCQkgICAgICdtdW5nZWRvbWFpbicsCSJubyIsCgkJICAgICAn YWRtaW5fcGFzc3dkJywJIiRtbC5hZG1pbiIsCgkJICAgICAnc3RyaXAnLAkJ InllcyIsCgkJICAgICAnZGF0ZV9pbmZvJywJInllcyIsCgkJICAgICAnZGF0 ZV9pbnRybycsCSJ5ZXMiLAoJCSAgICAgJ2FyY2hpdmVfZGlyJywJIiIsCgkJ ICAgICAnbW9kZXJhdGUnLAkibm8iLAoJCSAgICAgJ21vZGVyYXRvcicsCSIi LAoJCSAgICAgJ2FwcHJvdmVfcGFzc3dkJywgIiRtbC5wYXNzIiwKCQkgICAg ICdzZW5kZXInLCAJIm93bmVyLSRtbCIsCgkJICAgICAnbWF4bGVuZ3RoJywg CSI0MDAwMCIsCgkJICAgICAncHJlY2VkZW5jZScsIAkiYnVsayIsCgkJICAg ICAncmVwbHlfdG8nLCAJIiIsCgkJICAgICAncmVzdHJpY3RfcG9zdCcsCSIi LAoJCSAgICAgJ3B1cmdlX3JlY2VpdmVkJywgIm5vIiwKCQkgICAgICdhZG1p bmlzdHJpdmlhJywgCSJ5ZXMiLAoJCSAgICAgJ3Jlc2VuZF9ob3N0JywgCSIi LAoJCSAgICAgJ2RlYnVnJywgCQkibm8iLAoJCSAgICAgJ21lc3NhZ2VfZnJv bnRlcicsICIiLAoJCSAgICAgJ21lc3NhZ2VfZm9vdGVyJywgICIiLAoJCSAg ICAgJ21lc3NhZ2VfaGVhZGVycycsICIiLAoJCSAgICAgJ3N1YmplY3RfcHJl Zml4JywJIiIsCgkJICAgICAndGFib29faGVhZGVycycsCSIiLAoJCSAgICAg J3RhYm9vX2JvZHknLAkiIiwKCQkgICAgICdkaWdlc3Rfdm9sdW1lJywJIjEi LAoJCSAgICAgJ2RpZ2VzdF9pc3N1ZScsCSIxIiwKCQkgICAgICdkaWdlc3Rf d29ya19kaXInLCAiIiwKCQkgICAgICdkaWdlc3RfbmFtZScsCSIkbWwiLAoJ CSAgICAgJ2RpZ2VzdF9hcmNoaXZlJywJIiIsCgkJICAgICAnZGlnZXN0X3Jt X2Zvb3RlcicsICAgICIiLAoJCSAgICAgJ2RpZ2VzdF9ybV9mcm9udGVyJywg ICAiIiwgIAoJCSAgICAgJ2RpZ2VzdF9tYXhsaW5lcycsICIiLAoJCSAgICAg J2RpZ2VzdF9tYXhkYXlzJywJIiIsCgkJICAgICAnY29tbWVudHMnLAkiIgoJ CSAgICApOwp9CgoKIwojIE1haWxtYW4gbWFpbGluZyBsaXN0IHBhcmFtcyB0 aGF0IGFyZSBub3QgZGVyaXZlZCBmcm9tIE1ham9yZG9tbyBtYWlsaW5nIGxp c3RzIHBhcmFtcwojIChlLmcuIGJvdW5jZV9tYXRjaGluZ19oZWFkZXJzK2Zv cmJiaWRlbl9wb3N0ZXJzIHZzLiB0YWJvb19oZWFkZXJzK3RhYm9vX2JvZHkp CiMgSWYgeW91IG5lZWQgb25lIG9mIHRoaXMgcGFyYW1zIHRvIGJlIHZhcmlh YmxlIHJlbW92ZSBpdCBoZXJlIGFuZCBhZGQgc29tZSBjb2RlIHRvIHRoZSAK IyBtYWluIHByb2NlZHVyZTsgYWRkaXRpb25hbGx5LCB5b3Ugc2hvdWxkIGNv bXBhcmUgaXQgd2l0aCB3aGF0IHlvdSBoYXZlIGluCiMgL3Vzci9saWIvbWFp bG1hbi9NYWlsbWFuL21tX2NmZy5weQojCgpzdWIgaW5pdF9kZWZhdWx0bW1j b25mIHsKCiAgJWRlZmF1bHRtbWNvbmY9KCAgCgkJICAnZ29vZGJ5ZV9tc2cn LCAiXCdcJyIsCgkJICAndW1icmVsbGFfbGlzdCcsICIwIiwKCQkgICd1bWJy ZWxsYV9tZW1iZXJfc3VmZml4JywgIlwnJHVtYnJlbGxhX21lbWJlcl9zdWZm aXhcJyIsCgkJICAnc2VuZF9yZW1pbmRlcnMnLCAiMCIsCgkJICAnYWRtaW5f aW1tZWRfbm90aWZ5JywgIjEiLAoJCSAgJ2FkbWluX25vdGlmeV9tY2hhbmdl cycsICIwIiwKCQkgICdkb250X3Jlc3BvbmRfdG9fcG9zdF9yZXF1ZXN0cycs ICIwIiwKCQkgICdvYnNjdXJlX2FkZHJlc3NlcycsICIxIiwKCQkgICdyZXF1 aXJlX2V4cGxpY2l0X2Rlc3RpbmF0aW9uJywgIjEiLAoJCSAgJ2FjY2VwdGFi bGVfYWxpYXNlcycsICJcIlwiXCJcblwiXCJcIlxuIiwKCQkgICdtYXhfbnVt X3JlY2lwaWVudHMnLCAiMTAiLAoJCSAgJ2ZvcmJpZGRlbl9wb3N0ZXJzJywg IltdIiwKCQkgICdib3VuY2VfbWF0Y2hpbmdfaGVhZGVycycsICAiXCJcIlwi XG5cIlwiXCJcbiIsCgkJICAnYW5vbnltb3VzX2xpc3QnLCAiMCIsCgkJICAn bm9uZGlnZXN0YWJsZScsICIxIiwKCQkgICdkaWdlc3RhYmxlJywgIjEiLAoJ CSAgJ2RpZ2VzdF9pc19kZWZhdWx0JywgIjAiLAoJCSAgJ21pbWVfaXNfZGVm YXVsdF9kaWdlc3QnLCAiMCIsCgkJICAnZGlnZXN0X3NpemVfdGhyZXNoaG9s ZCcsICI0MCIsCgkJICAnZGlnZXN0X3NlbmRfcGVyaW9kaWMnLCAiMSIsCgkJ ICAnZGlnZXN0X2hlYWRlcicsICJcJ1wnIiwKCQkgICdib3VuY2VfcHJvY2Vz c2luZycsICIxIiwKCQkgICdtaW5pbXVtX3JlbW92YWxfZGF0ZScsICI0IiwK CQkgICdtaW5pbXVtX3Bvc3RfY291bnRfYmVmb3JlX2JvdW5jZV9hY3Rpb24n LCAiMyIsCgkJICAnbWF4X3Bvc3RzX2JldHdlZW5fYm91bmNlcycsICI1IiwK CQkgICdhdXRvbWF0aWNfYm91bmNlX2FjdGlvbicsICIzIiwKCQkgICdhcmNo aXZlX3ByaXZhdGUnLCAiMCIsCgkJICAnY2xvYmJlcl9kYXRlJywgIjEiLAoJ CSAgJ2FyY2hpdmVfdm9sdW1lX2ZyZXF1ZW5jeScsICIxIiwKCQkgICdhdXRv cmVzcG9uZF9wb3N0aW5ncycsICIwIiwKCQkgICdhdXRvcmVzcG9uc2VfcG9z dGluZ3NfdGV4dCcsICJcJ1wnIiwKCQkgICdhdXRvcmVzcG9uZF9hZG1pbics ICIwIiwKCQkgICdhdXRvcmVzcG9uc2VfYWRtaW5fdGV4dCcsICJcJ1wnIiwK CQkgICdhdXRvcmVzcG9uZF9yZXF1ZXN0cycsICIwIiwKCQkgICdhdXRvcmVz cG9uc2VfcmVxdWVzdF90ZXh0JywgIlwnXCciLAoJCSAgJ2F1dG9yZXNwb25z ZV9ncmFjZXBlcmlvZCcsICI5MCIKCQkgKTsKfQoKIwojIGNvbnZlcnQgYSBN YWpvcmRvbW8gbWFpbGluZyBsaXN0IGNvbmZpZ3VyYXRpb24gKCVtbGNvbmYp IGludG8gYSAKIyBNYWlsbWFuIG1haWxpbmcgbGlzdCBjb25maWd1cmF0aW9u ICglbW1jb25mKQojIG9ubHkgdGhvc2UgcGFyYW1zIGFyZSBhZmZlY3RlZCB3 aGljaCBjYW4gYmUgZGVyaXZlZCBmcm9tIE1ham9yZG9tbyAKIyBtYWlsaW5n IGxpc3QgY29uZmlndXJhdGlvbnMKIwoKc3ViIG0ybSB7CgogIG15ICRlbGVt OwogIG15ICRhZG1pbjsKCiAgJG1tY29uZnsicmVhbF9uYW1lIn0gPSAiXCci IC4gJG1sY29uZnsibmFtZSJ9IC4gIlwnIjsKCiAgIyBNYWlsbWFuIGRvZXMg bm90IGtub3cgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBvd25lciBhbmQgYXBw cm92ZXIKICBmb3IgJGFkbWluICgoJG1sY29uZnsicHJpbWFyeW93bmVyIn0s IEB7JG1sY29uZnsic2Vjb25kYXJ5b3duZXIifX0sCgkgICAgICAgJG1sY29u ZnsicHJpbWFyeWFwcHJvdmVyIn0sIEB7JG1sY29uZnsic2Vjb25kYXJhcHBy b3ZlciJ9fSkpIHsKICAgICMgbWVyZ2luZyBvd25lcnMgYW5kIGFwcHJvdmVy cyBtYXkgcmVzdWx0IGluIGEgbG9vcDoKICAgIGlmIChsYygkYWRtaW4pIG5l IGxjKCJvd25lci0iIC4gJG1sY29uZnsibmFtZSJ9IC4gIlxAIiAuICRteWRv bWFpbikpIHsKICAgICAgJG1tY29uZnsib3duZXIifSAuPSAiLFwnIiAuICIk YWRtaW4iIC4gIlwnIjsKICAgIH0KICB9CiAgJG1tY29uZnsib3duZXIifSA9 fiBzL14sLy9nOwogICRtbWNvbmZ7Im93bmVyIn0gPSAiXFsiIC4gJG1tY29u Znsib3duZXIifSAuICJcXSI7CgogICMgcmVtb3ZlIGNoYXJhY3RlcnMgdGhh dCB3aWxsIGJyZWFrIFB5dGhvbgogICgkbW1jb25meyJkZXNjcmlwdGlvbiJ9 ID0gJG1sY29uZnsiZGVzY3JpcHRpb24ifSkgPX4gcy9cJy9cXFwnL2c7CiAg JG1tY29uZnsiZGVzY3JpcHRpb24ifSA9ICJcJyIgLiAkbW1jb25meyJkZXNj cmlwdGlvbiJ9IC4gIlwnIjsKCiAgJG1tY29uZnsiaW5mbyJ9ID0gIlwiXCJc IlxuIiAuICRtbGNvbmZ7ImluZm8ifSAuICJcIlwiXCJcbiI7CgogICRtbWNv bmZ7InN1YmplY3RfcHJlZml4In0gPSAiXCciIC4gJG1sY29uZnsic3ViamVj dF9wcmVmaXgifSAuICJcJyI7CgogICRtbWNvbmZ7IndlbGNvbWVfbXNnIn0g PSAiXCJcIlwiXG4iIC4gJG1sY29uZnsiaW50cm8ifSAuICJcIlwiXCJcbiI7 CgogICMgSSBkb24ndCBrbm93IGhvdyB0byBoYW5kbGUgdGhpcyBiZWNhdXNl IHRoZSByZXBseV90byBwYXJhbSBpbiB0aGUgbGlzdHMKICAjIEkgaGFkIHdl cmUgbm90IGNvbmZpZ3VyZWQgY29uc2lzdGVudGx5CiAgaWYgKCRtbGNvbmZ7 InJlcGx5X3RvIn0gPX4gL1xTKy8pIHsKICAgIGlmICgkbWxjb25meyJuYW1l In0gLiAiXEAiID1+IG0vJG1sY29uZnsicmVwbHlfdG8ifS9pKSB7CiAgICAg ICRtbWNvbmZ7InJlcGx5X2dvZXNfdG9fbGlzdCJ9ID0gIjEiOwogICAgICAk bW1jb25meyJyZXBseV90b19hZGRyZXNzIn0gPSAiXCdcJyI7CiAgICB9CiAg ICBlbHNlIHsKICAgICAgJG1tY29uZnsicmVwbHlfZ29lc190b19saXN0In0g PSAiMiI7CiAgICAgICRtbWNvbmZ7InJlcGx5X3RvX2FkZHJlc3MifSA9ICJc JyIgLiAkbWxjb25meyJyZXBseV90byJ9IC4gIlwnIjsKICAgIH0KICB9CiAg ZWxzZSB7CiAgICAkbW1jb25meyJyZXBseV9nb2VzX3RvX2xpc3QifSA9ICIw IjsKICAgICRtbWNvbmZ7InJlcGx5X3RvX2FkZHJlc3MifSA9ICJcJ1wnIjsK ICB9CgogICRtbWNvbmZ7ImFkbWluaXN0cml2aWEifSA9ICgkbWxjb25meyJh ZG1pbmlzdHJpdmlhIn0gPX4gbS95ZXMvaSkgPyAiMSIgOiAiMCI7CiAgJG1t Y29uZnsic2VuZF93ZWxjb21lX21zZyJ9ID0gKCRtbGNvbmZ7IndlbGNvbWUi fSA9fiBtL3llcy9pKSA/ICIxIiA6ICIwIjsKCiAgJG1tY29uZnsibWF4X21l c3NhZ2Vfc2l6ZSJ9ID0gaW50ICgkbWxjb25meyJtYXhsZW5ndGgifSAvIDEw MDApOwoKICAkbW1jb25meyJob3N0X25hbWUifSA9ICgkbWxjb25meyJyZXNl bmRfaG9zdCJ9ID1+IC9cUysvKSA/IAogICAgJG1sY29uZnsicmVzZW5kX2hv c3QifSA6ICJcJyIgLiAkbXlkb21haW4gLiAiXCciOwoKICAkbW1jb25meyJ3 ZWJfcGFnZV91cmwifSA9ICJcJyIgLiAkbXl1cmwgLiAiXCciOwoKICAjIHBy b2JsZW1hdGljIHNpbmNlIE1haWxtYW4gZG9lcyBub3Qga25vdyBhY2Nlc3Mg cGF0dGVybnMKICAjIEkgYXNzdW1lLCB0aGF0IGlmIHRoZXJlIHdhcyBnaXZl biBhIG5vYWR2ZXJ0aXNlIHBhdHRlcm4sIHRoZQogICMgbGlzdCBzaG91bGRu J3QgYmUgdmlzaWJsZSBhdCBhbGwKICAkbW1jb25meyJhZHZlcnRpc2VkIn0g PSAoJG1sY29uZnsibm9hZHZlcnRpc2UifSA9fiAvXC5cKi8pID8gIjAiIDog IjEiOwoKICAjIGNvbmZpcm0rYXBwcm92YWwgaXMgbXVjaCB0byBsb25nIHdp bmRlZCBmb3IgcHJpdmF0ZSBzaXRlcwogICRtbWNvbmZ7InN1YnNjcmliZV9w b2xpY3kifSA9IAogICAgKCRtbGNvbmZ7InN1YnNjcmliZV9wb2xpY3kifSA9 fiBtLyhvcGVufGF1dG8pL2kpID8gIjEiIDogCiAgICAgICgkcHJpdmF0ZSA9 fiBtL3llcy9pKSA/ICIyIiA6ICIzIjsKCiAgIyBpbiBjYXNlIHRoaXMgaXMg YSBwcml2YXRlIHNpdGUgYWxsb3cgbGlzdCB2aXNpYmxpdHkgYXQgbW9zdAog ICRtbWNvbmZ7InByaXZhdGVfcm9zdGVyIn0gPQogICAgKCRtbGNvbmZ7Indo b19hY2Nlc3MifSA9fiBtL29wZW4vaSBhbmQgbm90ICRwcml2YXRlID1+IG0v eWVzL2kpID8gIjAiIDoKICAgICAgKCRtbGNvbmZ7Indob19hY2Nlc3MifSA9 fiBtL29wZW58bGlzdC9pKSA/ICIxIiA6ICIyIjsKCiAgJG1tY29uZnsibW9k ZXJhdGVkIn0gPSAoJG1sY29uZnsibW9kZXJhdGUifSA9fiBtL3llcy9pKSA/ ICIxIiA6ICIwIjsKICAjIHRoZXJlIGlzIG5vIHdheSB0byBhIHNldCBhIHNl cGFyYXRlIG1vZGVyYXRvciBpbiBNYWlsbWFuCgogICMgZXh0ZXJuYWwsIHNp bmNlIGxlbmd0aHkKICBtbV9wb3N0ZXJzKCk7CgogIGlmICgkbWxjb25meyJt ZXNzYWdlX2Zyb250ZXIifSA9fiAvXFMrLykgewogICAgJG1tY29uZnsibXNn X2hlYWRlciJ9ID0gIlwiXCJcIlxuIiAuICRtbGNvbmZ7Im1lc3NhZ2VfZnJv bnRlciJ9IC4gIlwiXCJcIlxuIjsKICB9CiAgZWxzZSB7CiAgICAkbW1jb25m eyJtc2dfaGVhZGVyIn0gPSAiXCdcJyI7CiAgfQoKICBpZiAoJG1sY29uZnsi bWVzc2FnZV9mb290ZXIifSA9fiAvXFMrLykgewogICAgJG1tY29uZnsibXNn X2Zvb3RlciJ9ID0gIlwiXCJcIlxuIiAuICRtbGNvbmZ7Im1lc3NhZ2VfZm9v dGVyIn0gLiAiXCJcIlwiXG4iOwogIH0KICBlbHNlIHsKICAgICRtbWNvbmZ7 Im1zZ19mb290ZXIifSA9ICJcJ1wnIjsKICB9CgogICMgZ2F0ZXdheSB0byBu ZXdzCiAgJG1tY29uZnsibm50cF9ob3N0In0gPSAiXCciIC4gJG5ld3NzZXJ2 ZXIgLiAiXCciOwogICRtbWNvbmZ7ImxpbmtlZF9uZXdzZ3JvdXAifSA9ICJc JyIgLiAkbmV3c3ByZWZpeCAuICRtbGNvbmZ7Im5hbWUifSAuICJcJyI7Cgog IGlmICgkbWxjb25meyJnYXRlZCJ9ID1+IG0veWVzL2kpIHsKICAgICRtbWNv bmZ7ImdhdGV3YXlfdG9fbmV3cyJ9ID0gIjEiOwogICAgJG1tY29uZnsiZ2F0 ZXdheV90b19tYWlsIn0gPSAiMSI7CiAgICAkbW1jb25meyJhcmNoaXZlIn0g PSAiMSI7CiAgfQogIGVsc2UgewogICAgJG1tY29uZnsiZ2F0ZXdheV90b19u ZXdzIn0gPSAiMCI7CiAgICAkbW1jb25meyJnYXRld2F5X3RvX21haWwifSA9 ICIwIjsKICAgICRtbWNvbmZ7ImFyY2hpdmUifSA9ICIwIjsKICB9CgogICMg cHJpbnQgd2FybmluZ3MgaWYgdGhpcyBzZWVtcyB0byBiZSBhbiB1bWJyZWxs YSBsaXN0CiAgZm9yICRlbGVtIChAeyRtbGNvbmZ7InByaXZpbGVnZWQifX0s IEB7JG1sY29uZnsibWVtYmVycyJ9fSkgewogICAgJGVsZW0gPX4gcy9cQCRt eWRvbWFpbi8vZ2k7CiAgICBpZiAoZGVmaW5lZCgkbWxhbGlhc2VzeyRlbGVt IC4gJHVtYnJlbGxhX21lbWJlcl9zdWZmaXh9KSkgewogICAgICBwcmludCBT VERFUlIgIlwiIiAuICRtbGNvbmZ7Im5hbWUifSAuCgkgIlwiIHBvc3NpYmx5 IGZvcm1zIHBhcnQgb2ZmL2lzIGFuIHVtYnJlbGxhIGxpc3QsIHNpbmNlIFwi JGVsZW1cIiBpcyBhIGxvY2FsIG1haWxpbmcgbGlzdCBhbGlhc1xuIjsgICAK ICAgIH0KICB9CgogICMgcHJpbnQgd2FybmluZ3MgaWYgd2UgZW5jb3VudGVy ZWQgYSBUYWJvby1IZWFkZXIgb3IgVGFib28tQm9keQogIGlmICgkbWxjb25m eyJ0YWJvb19oZWFkZXJzIn0gPX4gL1xTKy8gb3IgJG1sY29uZnsidGFib29f Ym9keSJ9ID1+IC9cUysvKSB7CiAgICBwcmludCBTVERFUlIgIlwiIiAuICRt bGNvbmZ7Im5hbWUifSAuICJcIiB0YWJvb19oZWFkZXJzIG9yIHRhYm9vX2Jv ZHkgc2VlbSB0byBiZSBzZXQgLSBwbGVhc2UgY2hlY2sgbWFudWFsbHkuXG4i OwogIH0KfQoKIwojIHdpdGggc29tZSBzZXQgdGhlb3J5IG9uIHRoZSBtZW1i ZXIgYW5kIHByaXZpbGlnZWQgbGlzdCB0cnkgdG8gZGV0ZXJtaW5lIHRoZSBw YXJhbXMKIyAkbW1jb25meyJtZW1iZXJfcG9zdGluZ19vbmx5In0gYW5kICRt bWNvbmZ7InBvc3RlcnMifQojCgpzdWIgbW1fcG9zdGVycyB7CiAgaWYgKCRt bGNvbmZ7InJlc3RyaWN0X3Bvc3QifSA9fiAvXFMrLykgewogICAgbXkgJXBy aXZpbGVnZWQgPSAoKTsKICAgIG15ICVtZW1iZXJzID0gKCk7CiAgICBteSAk a2V5OwoKICAgIGZvcmVhY2ggJGtleSAoQHskbWxjb25meyJwcml2aWxlZ2Vk In19KSB7ICRwcml2aWxlZ2VkeyRrZXl9ID0gIk9LIjsgfQogICAgZm9yZWFj aCAka2V5IChAeyRtbGNvbmZ7Im1lbWJlcnMifX0pIHsgJG1lbWJlcnN7JGtl eX0gPSAiT0siOyB9CgogICAgIyBhcmUgYWxsIG1lbWJlcnMgcHJpdmlsZWdl ZCwgdG9vID8KICAgIG15ICRpbmNsdWRlZCA9IDE7CiAgICBmb3JlYWNoICRr ZXkgKGtleXMgJW1lbWJlcnMpIHsKICAgICAgaWYgKG5vdCBleGlzdHMgJHBy aXZpbGVnZWR7JGtleX0pIHsKCSRpbmNsdWRlZCA9IDA7CglsYXN0OwogICAg ICB9CiAgICB9CiAgICBpZiAoJGluY2x1ZGVkKSB7CiAgICAgICRtbWNvbmZ7 Im1lbWJlcl9wb3N0aW5nX29ubHkifSA9ICIxIjsKCiAgICAgICMgcG9zdGVy cyA9IHByaXZpbGVnZWQgLSBtZW1iZXJzOgogICAgICBteSAlZGlmZiA9ICVw cml2aWxlZ2VkOwogICAgICBmb3JlYWNoICRrZXkgKGtleXMgJW1lbWJlcnMp IHsKCWRlbGV0ZSAkZGlmZnska2V5fSBpZiBleGlzdHMgJG1lbWJlcnN7JGtl eX07CiAgICAgIH0KCiAgICAgICRtbWNvbmZ7InBvc3RlcnMifSA9ICIiOwog ICAgICBmb3IgJGtleSAoc29ydCBrZXlzICVkaWZmKSB7CgkkbW1jb25meyJw b3N0ZXJzIn0gLj0gIixcJyIgLiAka2V5IC4gIlwnIjsKICAgICAgfQogICAg ICAkbW1jb25meyJwb3N0ZXJzIn0gPX4gcy9eLC8vZzsKICAgICAgJG1tY29u ZnsicG9zdGVycyJ9ID0gIlsiIC4gJG1tY29uZnsicG9zdGVycyJ9IC4gIl0i OwogICAgfQogICAgZWxzZSB7CiAgICAgICRtbWNvbmZ7Im1lbWJlcl9wb3N0 aW5nX29ubHkifSA9ICIwIjsKCiAgICAgICMgcG9zdGVycyA9IHByaXZpbGVn ZWQ6CiAgICAgICRtbWNvbmZ7InBvc3RlcnMifSA9ICIiOwogICAgICBmb3Ig JGtleSAoc29ydCBrZXlzICVwcml2aWxlZ2VkKSB7CgkkbW1jb25meyJwb3N0 ZXJzIn0gLj0gIixcJyIgLiAka2V5IC4gIlwnIjsKICAgICAgfQogICAgICAk bW1jb25meyJwb3N0ZXJzIn0gPX4gcy9eLC8vZzsKICAgICAgJG1tY29uZnsi cG9zdGVycyJ9ID0gIlsiIC4gJG1tY29uZnsicG9zdGVycyJ9IC4gIl0iOwog ICAgfQogIH0KICBlbHNlIHsKICAgICRtbWNvbmZ7Im1lbWJlcl9wb3N0aW5n X29ubHkifSA9ICIwIjsKICAgICRtbWNvbmZ7InBvc3RlcnMifSA9ICJbXSI7 CiAgfQp9Cgo= --168463740-4823034-1015596996=:8017-- From fil@rezo.net Fri Mar 8 14:44:30 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 15:44:30 +0100 Subject: [Mailman-Developers] Macintosh files when uploading "mass subscription " lists Message-ID: <20020308144430.GD12523@rezo.net> Hello, two bugs : 1) when I send a Macintosh file for "mass subscription" via the web, Mailman does not understand the Mac's linefeeds as separators for addresses, and sees just one (wrong) address. 2) When users reply to a confirmation cookie, they usually send their cookie followed by several lines of whatever (signature). Mailman sends them the "your message in error" reply, instead of "welcome !" -- Fil From barry@zope.com Fri Mar 8 15:55:52 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 10:55:52 -0500 Subject: [Mailman-Developers] migration from Majordomo to Mailman References: <Pine.LNX.4.43.0203081456510.8017-101000@Poincare.suse.de> Message-ID: <15496.57096.108897.879156@anthem.wooz.org> >>>>> "HR" == Heiko Rommel <rommel@suse.de> writes: HR> just in case somebody finds it usefull I'm including a perl HR> script that will largely easy the migration from Majordomo to HR> Mailman 2.0 - especially if you have more than a few lists. Cool. Have you tried it with MM2.1? HR> The process of migration is only half-automatic since there HR> are a bunch of params in Majordomo which have no exact HR> counterpart in Mailman. On the other hand, there are some new HR> params in Mailman which had to be set to a default value. HR> The script is far from being perfect - but it worked from me HR> and the 208 lists I had to migrate ;-) It's written in that /other/ P-language, but I guess since you're migrating we can forgive you :). May I add this to the contrib subdirectory? Would you mind re-releasing it with a GPL license? -Barry From rommel@suse.de Fri Mar 8 16:10:25 2002 From: rommel@suse.de (Heiko Rommel) Date: Fri, 8 Mar 2002 17:10:25 +0100 (CET) Subject: [Mailman-Developers] migration from Majordomo to Mailman In-Reply-To: <15496.57096.108897.879156@anthem.wooz.org> Message-ID: <Pine.LNX.4.43.0203081706310.2310-100000@Poincare.suse.de> On Fri, 8 Mar 2002, Barry A. Warsaw wrote: > > >>>>> "HR" == Heiko Rommel <rommel@suse.de> writes: > > HR> just in case somebody finds it usefull I'm including a perl > HR> script that will largely easy the migration from Majordomo to > HR> Mailman 2.0 - especially if you have more than a few lists. > > Cool. Have you tried it with MM2.1? No, I didn't. > > HR> The process of migration is only half-automatic since there > HR> are a bunch of params in Majordomo which have no exact > HR> counterpart in Mailman. On the other hand, there are some new > HR> params in Mailman which had to be set to a default value. > > HR> The script is far from being perfect - but it worked from me > HR> and the 208 lists I had to migrate ;-) > > It's written in that /other/ P-language, but I guess since you're > migrating we can forgive you :). > I really hoped that - especially 'cause I'm learning the more recent P-language now ;-) > May I add this to the contrib subdirectory? Would you mind > re-releasing it with a GPL license? > Please go ahead. GPL is just fine. > -Barry > Remember to have fun, Heiko Rommel phone +49-911-740 53 696 SuSE GmbH fax +49-911-741 77 55 Deutschherrnstr. 15-19 mail rommel@suse.de 90429 Nuernberg www http://www.suse.de/ Germany From les@2pi.org Fri Mar 8 16:24:04 2002 From: les@2pi.org (Les Niles) Date: Fri, 8 Mar 2002 08:24:04 -0800 Subject: [Mailman-Developers] [Bug] Digest volume increments daily Message-ID: <200203081624.IAA05155@mutiny.2pi.org> In 2.1a4, and AFAICT the current cvs tree, the digest volume number gets incremented daily regardless of the configured rate. This is because the test for the frequency of update is combined with the test for whether to actually update, causing the default branch -- update daily -- to be executed most of the time. Here's a patch that fixes this. -les --------------------------------------------------------------------- *** Mailman/Handlers/ToDigest.py.orig Sun Jan 6 23:04:03 2002 --- Mailman/Handlers/ToDigest.py Thu Mar 7 06:27:09 2002 *************** *** 97,111 **** timetup = time.localtime(mlist.digest_last_sent_at) now = time.localtime(time.time()) freq = mlist.digest_volume_frequency ! if freq == 0 and timetup[0] < now[0]: ! bump = 1 # Yearly ! elif freq == 1 and timetup[1] <> now[1]: # Monthly, but we take a cheap way to calculate this. We assume # that the clock isn't going to be reset backwards. ! bump = 1 ! elif freq == 2 and (timetup[1] % 4 <> now[1] % 4): # Quarterly, same caveat ! bump = 1 elif freq == 3: # Once again, take a cheap way of calculating this weeknum_last = int(time.strftime('%W', timetup)) --- 97,114 ---- timetup = time.localtime(mlist.digest_last_sent_at) now = time.localtime(time.time()) freq = mlist.digest_volume_frequency ! if freq == 0: ! if timetup[0] < now[0]: ! bump = 1 # Yearly ! elif freq == 1: # Monthly, but we take a cheap way to calculate this. We assume # that the clock isn't going to be reset backwards. ! if timetup[1] <> now[1]: ! bump = 1 ! elif freq == 2: # Quarterly, same caveat ! if (timetup[1] % 4 <> now[1] % 4): ! bump = 1 elif freq == 3: # Once again, take a cheap way of calculating this weeknum_last = int(time.strftime('%W', timetup)) From fil@rezo.net Fri Mar 8 16:24:58 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 17:24:58 +0100 Subject: [Mailman-Developers] big list Message-ID: <20020308162458.GE27629@rezo.net> I've tried and installed 50,000 subscribers in one list, to send them VERP messages (this is weird, but they are boucners from some other mailing list, managed with sympa). It seems to take forever to send a message : 'top' gives me PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 617 mailman 18 0 49860 44M 2576 R 85.5 4.3 41:05 qrunner /home/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s That's 41 minutes and not one message has gone out yet. Is that normal ? (almost current cvs) -- Fil From fil@rezo.net Fri Mar 8 16:33:02 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 17:33:02 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020308162458.GE27629@rezo.net> References: <20020308162458.GE27629@rezo.net> Message-ID: <20020308163302.GG27629@rezo.net> > It seems to take forever to send a message : 'top' gives me > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND > 617 mailman 18 0 49860 44M 2576 R 85.5 4.3 41:05 qrunner > /home/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s > > That's 41 minutes and not one message has gone out yet. Well! Now it has eaten up all my memory (1 Gb), and it's swapping like crazy : 182 processes: 175 sleeping, 3 running, 4 zombie, 0 stopped CPU0 states: 5.4% user, 93.3% system, 0.0% nice, 0.5% idle CPU1 states: 10.0% user, 84.4% system, 0.0% nice, 5.1% idle Mem: 1029592K av, 1015496K used, 14096K free, 0K shrd, 21468K buff Swap: 128484K av, 128484K used, 0K free 371260K cached -- Fil From barry@zope.com Fri Mar 8 16:36:37 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 11:36:37 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> Message-ID: <15496.59541.751235.142837@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> That's 41 minutes and not one message has gone out yet. F> Is that normal ? (almost current cvs) Probably not <wink>. -Barry From barry@zope.com Fri Mar 8 16:40:15 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 11:40:15 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> Message-ID: <15496.59759.624694.875487@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Well! Now it has eaten up all my memory (1 Gb), and it's F> swapping like crazy : This is just a guess (and I'll try to look at it in more detail later today), that the act of turning a message into 50k VERP-able copies is the problem. I.e. the loop in Personalize.py. Or it might be IncomingRunner trying to dequeue 50k messages (although that should only happen one at a time). Do you see anything in qfiles/in? I'll try to create a bunch of dummy addrs and send a personalized message through the system. -Barry From fil@rezo.net Fri Mar 8 16:42:57 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 17:42:57 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15496.59759.624694.875487@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> Message-ID: <20020308164257.GA1668@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > Do you see anything in qfiles/in? Indeed: 1015601891.96+b81bcd9e6a652f432f5fe592826e5b04161c9675.pck 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.db 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.pck 1015601891.96+b821bcd0fd18a1a290e592c08f269006f04eb573.db 1015601891.96+b821bcd0fd18a1a290e592c08f269006f04eb573.pck 1015601891.96+b82367106668726b6598101227c9215d58b87f37.db 1015601891.96+b82367106668726b6598101227c9215d58b87f37.pck 1015601891.96+b827213177f651f88b5a37adaf86bcc62e26658c.db 1015601891.96+b827213177f651f88b5a37adaf86bcc62e26658c.pck 1015601891.96+b827ed7dad14baa38a54536829349efb1c9ad15e.db 1015601891.96+b827ed7dad14baa38a54536829349efb1c9ad15e.pck 1015601891.96+b8286e4aecc0c39bae39f488d004893c09d63b38.db 1015601891.96+b8286e4aecc0c39bae39f488d004893c09d63b38.pck 1015601891.96+b82c5c5e0c9c893d651b07f9bba3347239f33e50.db 1015601891.96+b82c5c5e0c9c893d651b07f9bba3347239f33e50.pck thousands... will I also run out of disk space ? -- Fil From fil@rezo.net Fri Mar 8 16:44:52 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 17:44:52 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020308163302.GG27629@rezo.net> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> Message-ID: <20020308164451.GB1668@rezo.net> @ Fil <fil@rezo.net> : > Well! Now it has eaten up all my memory (1 Gb), and it's swapping like crazy : OK, out of disk space now: /dev/sda6 1.8G 1.8G 0 100% /home -- Fil From barry@zope.com Fri Mar 8 16:49:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 11:49:39 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> Message-ID: <15496.60323.371912.238703@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: >> Do you see anything in qfiles/in? F> Indeed: | 1015601891.96+b81bcd9e6a652f432f5fe592826e5b04161c9675.pck | 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.db | 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.pck | 1015601891.96+b821bcd0fd18a1a290e592c08f269006f04eb573.db | 1015601891.96+b821bcd0fd18a1a290e592c08f269006f04eb573.pck | 1015601891.96+b82367106668726b6598101227c9215d58b87f37.db | 1015601891.96+b82367106668726b6598101227c9215d58b87f37.pck | 1015601891.96+b827213177f651f88b5a37adaf86bcc62e26658c.db | 1015601891.96+b827213177f651f88b5a37adaf86bcc62e26658c.pck | 1015601891.96+b827ed7dad14baa38a54536829349efb1c9ad15e.db | 1015601891.96+b827ed7dad14baa38a54536829349efb1c9ad15e.pck | 1015601891.96+b8286e4aecc0c39bae39f488d004893c09d63b38.db | 1015601891.96+b8286e4aecc0c39bae39f488d004893c09d63b38.pck | 1015601891.96+b82c5c5e0c9c893d651b07f9bba3347239f33e50.db | 1015601891.96+b82c5c5e0c9c893d651b07f9bba3347239f33e50.pck F> thousands... will I also run out of disk space ? When you turn on VERPing Mailman makes a unique copy of each message for each recipient, so do the math. :) There might be a way to defer this until SMTP delivery time, in which case we'd only create the copies in memory when talking to the smtpd. These copies would get gc'd after delivery, but we'd still have to play the game that I think Marc brought up about not blasting too many messages down the same socket connection. I'll think on this. -Barry From fil@rezo.net Fri Mar 8 16:52:03 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 17:52:03 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15496.60323.371912.238703@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> Message-ID: <20020308165203.GA3268@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > F> thousands... will I also run out of disk space ? Now I have run out of disk space (wrong partition!) -- Fil From carson@taltos.org Fri Mar 8 16:58:21 2002 From: carson@taltos.org (Carson Gaspar) Date: Fri, 08 Mar 2002 11:58:21 -0500 Subject: [Mailman-Developers] big list In-Reply-To: <15496.60323.371912.238703@anthem.wooz.org> References: <15496.60323.371912.238703@anthem.wooz.org> Message-ID: <8474605.1015588700@[172.25.85.74]> --On Friday, March 08, 2002 11:49 AM -0500 "Barry A. Warsaw" <barry@zope.com> wrote: > There might be a way to defer this until SMTP delivery time, in which > case we'd only create the copies in memory when talking to the smtpd. Please! Exploding onto slow disk is bad... Also, why create a copy at all? Why not just do the substitution in real-time during the SMTP conversation? i.e., instead of buffer->filter->buffer->tcp, just do buffer->filter->tcp. No GC needed. -- Carson From fil@rezo.net Fri Mar 8 17:03:50 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 18:03:50 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15496.60323.371912.238703@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> Message-ID: <20020308170350.GA4980@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > >> Do you see anything in qfiles/in? I have freed some disk space, 'stopped' Mailman with mailmanctl, and swapping has receded. Now I have: $ ls qfiles/in/ -1 | wc 100199 100199 5861674 And the only Mailman process doing alot of work is 619 mailman 12 0 29052 8500 1740 S 6.7 0.8 9:14 qrunner /home/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s -- Fil From Nigel.Metheringham@dev.InTechnology.co.uk Fri Mar 8 17:04:58 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 08 Mar 2002 17:04:58 +0000 Subject: [Mailman-Developers] big list In-Reply-To: <15496.60323.371912.238703@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> Message-ID: <1015607103.14990.8.camel@gaspode.localnet> On Fri, 2002-03-08 at 16:49, Barry A. Warsaw wrote: > When you turn on VERPing Mailman makes a unique copy of each message > for each recipient, so do the math. :) Ugh... > There might be a way to defer this until SMTP delivery time, in which > case we'd only create the copies in memory when talking to the smtpd. Ideally you would make a copy in memory, ship it down the delivery pipeline, then work on the next copy... really only need a few copies actually in python memory at once (pretty much just the number of outgoing delivery streams). > These copies would get gc'd after delivery, but we'd still have to > play the game that I think Marc brought up about not blasting too many > messages down the same socket connection. Fun :-) Of course as the MTA catches these its going to make a queue file on disk for each one unless you can do this funky passing the VERP stuff down the pipeline stuff thats been mentioned on the list before. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry@zope.com Fri Mar 8 17:08:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 12:08:43 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <20020308170350.GA4980@rezo.net> Message-ID: <15496.61467.661275.648908@anthem.wooz.org> Not surprising. Stop Mailman, wax those files, and I'll work out something better. -Barry From fil@rezo.net Fri Mar 8 17:15:59 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 18:15:59 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <1015607103.14990.8.camel@gaspode.localnet> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> Message-ID: <20020308171559.GA6605@rezo.net> @ Nigel Metheringham <Nigel.Metheringham@dev.InTechnology.co.uk> : > Of course as the MTA catches these its going to make a queue file on > disk for each one unless you can do this funky passing the VERP stuff > down the pipeline stuff thats been mentioned on the list before. Yes, but: my MTA's spool disk is rather large, but I had not anticipated that for Mailman's spool, which is on a smaller partition... -- Fil From barry@zope.com Fri Mar 8 17:15:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 12:15:32 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> Message-ID: <15496.61876.621999.288572@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> <Nigel.Metheringham@dev.InTechnology.co.uk> writes: NM> Ideally you would make a copy in memory, ship it down the NM> delivery pipeline, then work on the next copy... really only NM> need a few copies actually in python memory at once (pretty NM> much just the number of outgoing delivery streams). That's what I have in mind. NM> Of course as the MTA catches these its going to make a queue NM> file on disk for each one unless you can do this funky passing NM> the VERP stuff down the pipeline stuff thats been mentioned on NM> the list before. It would be really cool if we could get a bunch of MTA authors together (I only care about the open source ones <wink>) to define a protocol for letting the MTA doing the stitching. I think Postfix, and probably Exim support a way to do this for the envelope sender, but the really interesting bits happen when the body of the message can be personalized. The outgoing MTA's the most efficient place to do this, but you have to get it the information it needs to chew on. I know there's been some talk about subsuming the outgoing functionality into MM, but I see such a bulk mailer/stitcher as a separate project, that could be integrated into MM through a new DELIVERY_MODULE. I don't expect to have time to work on that myself, so there's an opportunity for someone who wants to contribute. -Barry From Nigel.Metheringham@dev.InTechnology.co.uk Fri Mar 8 17:21:26 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 08 Mar 2002 17:21:26 +0000 Subject: [Mailman-Developers] Big archives Message-ID: <1015608091.14990.15.camel@gaspode.localnet> The exim list has been running since 1996, migrated to mailman in 99, and has all the arhives online at http://www.exim.org/pipermail/exim-users/ I've had comments from people that this page is now too slow to load - since I roll the archives weekly (high traffic list) there are around 300 lines of basic archive index in the html table. I don't like the idea of migrating chunks out, but maybe some means of handling large archive chunks would be useful. It is of course an archiver rather than a mailman issue, so a new wonderfully enhanced pipermail is the answer :-) Nigel -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jb@cascade-sys.com Fri Mar 8 17:29:48 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Fri, 08 Mar 2002 09:29:48 -0800 Subject: [Mailman-Developers] Big archives References: <1015608091.14990.15.camel@gaspode.localnet> Message-ID: <3C88F50C.AF33EA99@cascade-sys.com> Would it make sense to simply cache a static copy of the page (instead of generating live CGI on each reference)? Have a chron job update it daily or whatever. People would not have access to the very latest posts, but usually that's not the point in looking up an archive. Just thinking out loud... Regards --jb Nigel Metheringham wrote: > The exim list has been running since 1996, migrated to mailman in 99, > and has all the arhives online at > http://www.exim.org/pipermail/exim-users/ > > I've had comments from people that this page is now too slow to load - > since I roll the archives weekly (high traffic list) there are around > 300 lines of basic archive index in the html table. > > I don't like the idea of migrating chunks out, but maybe some means of > handling large archive chunks would be useful. It is of course an > archiver rather than a mailman issue, so a new wonderfully enhanced > pipermail is the answer :-) > > 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/mailman-developers -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From jra@baylink.com Fri Mar 8 17:31:35 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 8 Mar 2002 12:31:35 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <15494.14036.373582.981056@anthem.wooz.org>; from barry@zope.com on Wed, Mar 06, 2002 at 10:33:40AM -0500 References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.14036.373582.981056@anthem.wooz.org> Message-ID: <20020308123135.10923@scfn.thpl.lib.fl.us> On Wed, Mar 06, 2002 at 10:33:40AM -0500, barry@zope.com wrote: > Not hard to do in MM2.1, but I doubt I'll accept much extension in > this area. The whole backend user database will be rewritten in a > future version and IMO, such extra information ought to be kept in an > external database like LDAP or some such. Then those databases ought > to be easily integrated into Mailman's rosters. <nit pedantic_level="high"> "...in an external database, possibly with an LDAP interface..." </nit> This is much akin to XML, which everyone commonly (and incorrectly) conflates with application architectures which utilize it... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From fil@rezo.net Fri Mar 8 17:33:07 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 18:33:07 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15496.61467.661275.648908@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <20020308170350.GA4980@rezo.net> <15496.61467.661275.648908@anthem.wooz.org> Message-ID: <20020308173307.GA9264@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > Not surprising. Stop Mailman, wax those files, and I'll work out > something better. If it can be of interest : I had to 'kill -9' the qrunner that was running in circles, then just restarted the whole thing, and my personalized messages are going out at full speed now. -- Fil From jra@baylink.com Fri Mar 8 17:33:57 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 8 Mar 2002 12:33:57 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C86709B.C5F55E31@cascade-sys.com>; from "James J. Besemer" <jb@cascade-sys.com> on Wed, Mar 06, 2002 at 11:40:11AM -0800 References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> Message-ID: <20020308123357.59329@scfn.thpl.lib.fl.us> On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote: > Les Niles wrote: > > (It was the release of AOL 6.0, which doesn't allow > > turning off HTML, that prompted me.) > > Exactly. > > While, OTOH I agree these more robust formats are the future, it's > insane to force them on users and not allow them to turn them off. As someone who reads half of my mail in Mutt in a vt screen, and the other half on my Minstral equipped Palm III, I disagree wildly with your characterisation of non-ASCII email as "more robust". 15 years of varied experience with email administration causes me to characterise such email as "more frangible". Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Fri Mar 8 17:36:12 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 8 Mar 2002 12:36:12 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C86BFF9.A54EF746@cascade-sys.com>; from "James J. Besemer" <jb@cascade-sys.com> on Wed, Mar 06, 2002 at 05:18:49PM -0800 References: <B8ABFCD0.1A401%chuqui@plaidworks.com> <3C86BFF9.A54EF746@cascade-sys.com> Message-ID: <20020308123612.45935@scfn.thpl.lib.fl.us> On Wed, Mar 06, 2002 at 05:18:49PM -0800, James J. Besemer wrote: > Chuq Von Rospach wrote: > > > First step is -- "I run this list, this is how I plan on running it, and if > > you insist on yelling about this stuff on the list, I'll kick YOU off > > first." > > I don't agree, certainly not with this issue. > > More generally -- the list IS the members -- not the admin or tools used. Thriller from Manila, part 2. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Fri Mar 8 18:23:33 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 8 Mar 2002 13:23:33 -0500 Subject: [Mailman-Developers] big list In-Reply-To: <15496.60323.371912.238703@anthem.wooz.org>; from "Barry A. Warsaw" <barry@zope.com> on Fri, Mar 08, 2002 at 11:49:39AM -0500 References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> Message-ID: <20020308132333.03800@scfn.thpl.lib.fl.us> On Fri, Mar 08, 2002 at 11:49:39AM -0500, Barry A. Warsaw wrote: > When you turn on VERPing Mailman makes a unique copy of each message > for each recipient, so do the math. :) > > There might be a way to defer this until SMTP delivery time, in which > case we'd only create the copies in memory when talking to the smtpd. > These copies would get gc'd after delivery, but we'd still have to > play the game that I think Marc brought up about not blasting too many > messages down the same socket connection. This is the 'range' dilemma. We need an 'xrange' solution. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jwblist@olympus.net Fri Mar 8 21:46:11 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 8 Mar 2002 13:46:11 -0800 Subject: [Mailman-Developers] big list In-Reply-To: <15496.61876.621999.288572@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> Message-ID: <p05101500b8aede5b5c7b@[207.149.192.229]> At 12:15 -0500 3/8/2002, Barry A. Warsaw wrote: >It would be really cool if we could get a bunch of MTA authors >together (I only care about the open source ones <wink>) to define a >protocol for letting the MTA doing the stitching. I think Postfix, >and probably Exim support a way to do this for the envelope sender, >but the really interesting bits happen when the body of the message >can be personalized. The outgoing MTA's the most efficient place to >do this, but you have to get it the information it needs to chew on. > >I know there's been some talk about subsuming the outgoing >functionality into MM, but I see such a bulk mailer/stitcher as a >separate project, that could be integrated into MM through a new >DELIVERY_MODULE. I don't expect to have time to work on that myself, >so there's an opportunity for someone who wants to contribute. I suspect you'll get a lot of resistance from MTA authors to the idea of an MTA (mail transfer agent) messing with the bodies of the messages. That's MUA work. This is more for a purpose-built tool which knows how to send messages to the world's MTAs and how to prepare messages, but does not know anything about receiving messages from general local senders or from the world. In other words, a potentially useful different product. Aside: how far we've come from the old mainframe LISTSERV, the network of which carefully sent one copy along with a list to addresses to various neighbors "near" the addressees for further distribution. So quite likely, only one copy crossed the Atlantic...possibly one one went from Chicago to Florida, etc etc. As to VERPing a big list with the *current* tool: don't (if it hurts, don't do it, and I doubt whether throwing enough more hardware at the 50,000 address list is feasible). VERP a bunch of little lists roughly sequentially. The originator of the thread might try the first 1,000 and see whether 50 1000 member lists will work. *Particularly* when nearly 50,000 bounces are expected (the list is bouncers from other lists, per the initial message). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From fil@rezo.net Fri Mar 8 22:31:38 2002 From: fil@rezo.net (Fil) Date: Fri, 8 Mar 2002 23:31:38 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <p05101500b8aede5b5c7b@[207.149.192.229]> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> <p05101500b8aede5b5c7b@[207.149.192.229]> Message-ID: <20020308223138.GC7555@rezo.net> @ John W Baxter <jwblist@olympus.net> : > As to VERPing a big list with the *current* tool: don't (if it hurts, > don't do it, and I doubt whether throwing enough more hardware at the > 50,000 address list is feasible). Sometimes you want to try and stress things, just to give beta feedback to Barry. I've shown a problem with computing all VERPed messages before sending (as opposed to *while sending*), I'm quite happy with that being in a beta (or alpha) moment before the much awaited MM2.1. > VERP a bunch of little lists roughly sequentially. The originator of the > thread might try the first 1,000 and see whether 50 1000 member lists will > work. *Particularly* when nearly 50,000 bounces are expected (the list is > bouncers from other lists, per the initial message). What I'm witnessing now is also interesting: these personalized messages go out one after the other, almost 20 seconds between them. The IncomingRunner is taking up about 100% of one of the CPU. The BounceRunner taking 30% of the other. I guess both are trying, for each file, to rescan the database file? I can't understand why the IncomingRunner should check the database... In conclusion, it's going to take on loooong time expelling all these files... Too bad I'll have to stop that experiment (or spend several days with an eye on log files). -- Fil From jb@cascade-sys.com Fri Mar 8 23:01:10 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Fri, 08 Mar 2002 15:01:10 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> <20020308123357.59329@scfn.thpl.lib.fl.us> Message-ID: <3C8942B6.914ED2B7@cascade-sys.com> "Jay R. Ashworth" wrote: > On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote: > > While, OTOH I agree these more robust formats are the future, it's > > insane to force them on users and not allow them to turn them off. > > As someone who reads half of my mail in Mutt in a vt screen, and the > other half on my Minstral equipped Palm III, I disagree wildly with > your characterisation of non-ASCII email as "more robust". > > 15 years of varied experience with email administration causes me to > characterise such email as "more frangible". Ok. For argument's sake, strike "more robust". ;o) However you characterize them, don't you agree they "are the future" (which was the main point of my sentence)? For better or worse, I detect an inexorable trend. More importantly, it seems you would agree there should be a way to filter them out in list managers, which was my position in starting this overall thread. Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From jwblist@olympus.net Fri Mar 8 23:01:09 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 8 Mar 2002 15:01:09 -0800 Subject: [Mailman-Developers] big list In-Reply-To: <20020308223138.GC7555@rezo.net> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> <p05101500b8aede5b5c7b@[207.149.192.229]> <20020308223138.GC7555@rezo.net> Message-ID: <p05101506b8aef2c12460@[207.149.192.229]> At 23:31 +0100 3/8/2002, Fil wrote: >Sometimes you want to try and stress things, just to give beta feedback to >Barry. I've shown a problem with computing all VERPed messages before >sending (as opposed to *while sending*), I'm quite happy with that being in >a beta (or alpha) moment before the much awaited MM2.1. Indeed, and that part of the thing you did was excellent. (I find it interesting that a second try worked somewhat well, at least initially.) If you wanted quick results, the approach turned out not to be right...but it certainly stressed well. Cheers! -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From fil@rezo.net Fri Mar 8 23:07:25 2002 From: fil@rezo.net (Fil) Date: Sat, 9 Mar 2002 00:07:25 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <p05101506b8aef2c12460@[207.149.192.229]> References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> <p05101500b8aede5b5c7b@[207.149.192.229]> <20020308223138.GC7555@rezo.net> <p05101506b8aef2c12460@[207.149.192.229]> Message-ID: <20020308230725.GG7555@rezo.net> @ John W Baxter <jwblist@olympus.net> : > Indeed, and that part of the thing you did was excellent. (I find it > interesting that a second try worked somewhat well, at least initially.) No: I said "it's going out fast", but I was confused: messages from other lists were going out fast. Those messages were already very slow, one every 20 seconds... must be the time needed to lock + read the list.db + unlock. > If you wanted quick results, the approach turned out not to be right...but > it certainly stressed well. :-) -- Fil From jwblist@olympus.net Fri Mar 8 23:23:02 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 8 Mar 2002 15:23:02 -0800 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C8942B6.914ED2B7@cascade-sys.com> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> <20020308123357.59329@scfn.thpl.lib.fl.us> <3C8942B6.914ED2B7@cascade-sys.com> Message-ID: <p05101507b8aef7202a93@[207.149.192.229]> At 15:01 -0800 3/8/2002, James J. Besemer wrote: >However you characterize them, don't you agree they "are the future" >(which was >the main point of my sentence)? For better or worse, I detect an inexorable >trend. Trend, yes. Perhaps it's wishful thinking, but I don't think "inexorable." Counter trends: [US] ADA compliance wireless email appliances [Both would make XML mail sensible, but not tower-of-babel HTML.] None of which detracts from your point: Mailman needs more ability to deal with HTML mail. ---John (and besides, at age 62 now, I'll likely miss out on whatever happens...which if that is HTML email, is good) -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Dan Mick <dmick@utopia.West.Sun.COM> Fri Mar 8 23:29:19 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Fri, 8 Mar 2002 15:29:19 -0800 (PST) Subject: [Mailman-Developers] big list Message-ID: <200203082329.g28NTKcW004093@utopia.West.Sun.COM> > >>>>> "NM" == Nigel Metheringham > >>>>> <Nigel.Metheringham@dev.InTechnology.co.uk> writes: > > NM> Ideally you would make a copy in memory, ship it down the > NM> delivery pipeline, then work on the next copy... really only > NM> need a few copies actually in python memory at once (pretty > NM> much just the number of outgoing delivery streams). > > That's what I have in mind. > > NM> Of course as the MTA catches these its going to make a queue > NM> file on disk for each one unless you can do this funky passing > NM> the VERP stuff down the pipeline stuff thats been mentioned on > NM> the list before. > > It would be really cool if we could get a bunch of MTA authors > together (I only care about the open source ones <wink>) to define a > protocol for letting the MTA doing the stitching. I think Postfix, > and probably Exim support a way to do this for the envelope sender, > but the really interesting bits happen when the body of the message > can be personalized. The outgoing MTA's the most efficient place to > do this, but you have to get it the information it needs to chew on. BTW, I'm doing this for the From VERPing with Postfix, and it's working out really well for me. The changes are really small and well-contained, and my bounce processing is *really* working better now (I never ever have a missed bounce): Index: Mailman/Handlers/SMTPDirect.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/SMTPDirect.py,v retrieving revision 2.11 diff -u -r2.11 SMTPDirect.py --- Mailman/Handlers/SMTPDirect.py 16 Dec 2001 06:23:14 -0000 2.11 +++ Mailman/Handlers/SMTPDirect.py 8 Mar 2002 23:28:20 -0000 @@ -75,6 +75,9 @@ # do that here?) del msg['sender'] del msg['errors-to'] + # DJM - do this unconditionally since we're VERPing as below + del msg['sender'] + del msg['errors-to'] # Get the flat, plain text of the message msgtext = msg.as_string(unixfrom=0) # Time to split up the recipient list. If we're VERPing then each chunk @@ -270,7 +273,9 @@ if not getattr(conn, 'sock', 0): conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) # Send the message - refused = conn.sendmail(envsender, recips, msgtext) + # DJM - do Postfix VERPing + refused = conn.sendmail(envsender, recips, msgtext,\ + mail_options=["XVERP"]) except smtplib.SMTPRecipientsRefused, e: refused = e.recipients # MTA not responding, or other socket problems, or any other kind of Index: Mailman/Queue/BounceRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/BounceRunner.py,v retrieving revision 2.8 diff -u -r2.8 BounceRunner.py --- Mailman/Queue/BounceRunner.py 7 Mar 2002 16:54:39 -0000 2.8 +++ Mailman/Queue/BounceRunner.py 8 Mar 2002 23:28:21 -0000 @@ -111,6 +111,8 @@ continue # not a bounce to our list # All is good addr = '%s@%s' % mo.group('mailbox', 'host') + syslog('bounce', 'VERP bounce from %s header for addr %s', + header, addr) except IndexError: syslog('error', "VERP_REGEXP doesn't yield the right match groups: %s", From barry@zope.com Fri Mar 8 23:41:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 18:41:31 -0500 Subject: [Mailman-Developers] big list References: <200203082329.g28NTKcW004093@utopia.West.Sun.COM> Message-ID: <15497.19499.773270.882060@anthem.wooz.org> Heh, you're gonna hate me then, because I'm doing some significant surgery on SMTPDirect.py. I'm probably going to throw out the threading stuff because I can't keep it all straight in my head, but I'm up for resurrecting it in an SMTPThreaded.py module if there's sufficient interest. I haven't looked at your patch but I will if/when <wink> I get this new version working. -Barry From barry@zope.com Sat Mar 9 01:34:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 20:34:44 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> Message-ID: <15497.26292.681882.2706@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I've tried and installed 50,000 subscribers in one list, to F> send them VERP messages The good news: thanks for stressing this part of Mailman. I /think/ cvs now should perform much better. Please try it out. Mailman now defers the final knitting of the message together with its header and footer until SMTP delivery time. That means that personalization and VERPing are added to an in-memory copy. I expect this to have two benefits: Mailman itself should be much less hungry for disk I/O when doing VERP, and it should be nice for memory footprint as well, as I expect the in-memory message copies to be sufficently garbage collected away. Please let me know what you observe. No promises that there aren't bugs lurking. Bad new: I won't release a beta1 today. I'd like for this code to air out a bit, plus I didn't get to the last few non-related mods I was planning to get to. I'm headed off-line for a few hours now, but I'll check back in tonight and over the weekend, time permitting. More bad news: threaded delivery is gone. Was anybody using this, really? Oh well, it was always labeled experimental anyway <wink>. breaking-warsaw's-second-law-ly y'rs, -Barry From barry@zope.com Sat Mar 9 01:39:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 20:39:23 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> <p05101500b8aede5b5c7b@[207.149.192.229]> <20020308223138.GC7555@rezo.net> Message-ID: <15497.26571.422035.1958@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> What I'm witnessing now is also interesting: these personalized F> messages go out one after the other, almost 20 seconds between F> them. The IncomingRunner is taking up about 100% of one of the F> CPU. The BounceRunner taking 30% of the other. I guess both are F> trying, for each file, to rescan the database file? I can't F> understand why the IncomingRunner should check the database... This part /should/ perform better too. OutgoingRunner usually[1] doesn't need to lock the list so there's much less contention on the list lock. IncomingRunner is doing much less work now too. -Barry [1] It only locks it occasionally if it got failures when talking to the MTA. It collects these failures and periodically cleans them out, doing a bounce registration for each. "Periodically" is defined in DEAL_WITH_PERMFAILURES_EVERY in OutgoingRunner.py <1 wink>. From mailman@howlingfrog.com Sat Mar 9 01:50:55 2002 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Fri, 8 Mar 2002 17:50:55 -0800 Subject: [Mailman-Developers] big list In-Reply-To: <20020308230725.GG7555@rezo.net> References: <20020308162458.GE27629@rezo.net> <p05101506b8aef2c12460@[207.149.192.229]> <20020308230725.GG7555@rezo.net> Message-ID: <200203090151.g291p0CE002161@mail.howlingfrog.com> On Friday 08 March 2002 15:07, you wrote: > No: I said "it's going out fast", but I was confused: messages from > other lists were going out fast. Those messages were already very slow, > one every 20 seconds... must be the time needed to lock + read the > list.db + unlock. I'd expect that this is likely the problem. I manage a list for a customer who has ~180k addresses in Mailman, and after solving MTA problems we found that the next biggest bottleneck was the Mailman data store. It generally took 8-10 seconds on a Dual-Athlon-1600Mhz machine to process a single bounce message, just about all of which was chewed up in doing locking and IO (ok, probably just IO). The actual size of the "config.db" file was close to 12MB when we started having major problems with it, never mind that when slurped in QRunner generally ate up 50-70MB of RAM while processing the queue. With the CPU pegged at 95+% usage from QRunner, I'd totally expect that most of our CPU time was just spent spinning while slurping in and spitting out the list after each and every update was made to the list. For our particular case, we found that by splitting out the larger list into a series of smaller lists (e.g. one for each letter of the alphabet), we were able to _substantially_ reduce the overhead involved and got processing back down to 5-6msgs/sec again. I wouldn't necessarily say that what we've done is the "be all and end all" answer to this, though, it just pushed the problem back to a later date for us, giving us enough time to look at other things before it rears its ugly head again as some lists grow faster than others ("s" is always a big list). For point of reference, we're running this on Mailman-2.0.8, using Postfix-1.1.3 as the MTA. We used to have it running on Sendmail-8.12, which worked quite well and handled the load without any problems, but had a tendency to create MUCH more IO than Postfix does. Being that I haven't yet gotten my dream IO system for this machine, the shift to Postfix was necessary to get msgs flying out the door faster. There are still other bottlenecks in the system, but after our updates Mailman wasn't one of the major ones on the list any more. I'll also note that our install has a number of the Bounce handlers removed, to make the processing chain shorter. We ran many megs of debug logs spitting out information about which Bounce handler processed a given msg, and disabled all of those that were at the bottom of the list. I think all we've got left in there right now is 'Postfix', 'DSN', and 'Catchall', which catches more than 90% of the bounces we get sent back through the system. Isn't perfect for catching and processing all of the bounces, but the reduction in pipeline length for the bounce processing made a noticable difference in performance. This, however, I expect is related to the performance not of Mailman itself, but of Python in general, in the context of the regexes and the MIME libraries that Mailman is using. -- Graham TerMarsch Howling Frog Internet Development, Inc. http://www.howlingfrog.com From barry@zope.com Sat Mar 9 03:14:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 8 Mar 2002 22:14:30 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <p05101506b8aef2c12460@[207.149.192.229]> <20020308230725.GG7555@rezo.net> <200203090151.g291p0CE002161@mail.howlingfrog.com> Message-ID: <15497.32278.227739.144369@anthem.wooz.org> >>>>> "GT" == Graham TerMarsch <mailman@howlingfrog.com> writes: GT> The actual size of the "config.db" file was close to 12MB when GT> we started having major problems with it, never mind that when GT> slurped in QRunner generally ate up 50-70MB of RAM while GT> processing the queue. With the CPU pegged at 95+% usage from GT> QRunner, I'd totally expect that most of our CPU time was just GT> spent spinning while slurping in and spitting out the list GT> after each and every update was made to the list. I suspect that MM2.1 will perform better here for several reasons. First, the OutgoingRunner almost never needs to acquire the lock to get the message out the door. If all your addresses are non-local and you're not doing synchronous delivery, then you'll never get failures during the SMTP dialog, so it'll never acquire the list lock. Second, you can tune your BounceRunner to only process bounces "once in a while". If you really don't need to process them as soon as they come in, just crank up the sleep interval between sweeps of the bounce queue. Third, if you decide to go the VERP route, you'll almost never need to run through the bounce pipeline, since the bouncing address can be unambiguously culled from the envelope sender. MM2.1 inherits MM2.0's data store. That's not going to change until MM3.0, but I agree that something more efficient is sorely needed to avoid list lock contention. I personally think ZODB is a great way to go, and may be the default, but the system /will/ be architected so that you could use something else underneath if you want. GT> I'll also note that our install has a number of the Bounce GT> handlers removed, to make the processing chain shorter. [...] GT> This, however, I expect is related to the performance not of GT> Mailman itself, but of Python in general, in the context of GT> the regexes and the MIME libraries that Mailman is using. I'll bet most of that is simply spent importing all the bounce pipeline modules. Try strace'ing Python sometime and doing some imports. Fear the number of stats going on. :) Again, MM2.1 will be much better because we've switched to a long-running daemon design. The bounce qrunner will warm up after the initial set of imports, so if that /is/ the culprit, you'll see better performance there as well. Cheers, -Barry From terri@zone12.com Sat Mar 9 04:29:38 2002 From: terri@zone12.com (Terri Oda) Date: Fri, 08 Mar 2002 23:29:38 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C844F29.6998B3C2@cascade-sys.com> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <5.1.0.14.0.20020308230957.03b6acb0@pop.ncf.carleton.ca> At 08:52 PM 04/03/02 -0800, James J. Besemer wrote: >4. It would be nice to reuse the existing list security as an umbrealla to >cover >other arbitrary, list-members-only web pages. E.g., some listers hate large >graphics attachments (and they are problematic generally). I'd like to >remove the >image from the incoming message, publish it on a secure, lister-only web >page and >forward the mail with an URL substituted for the image attachment. Since no one else has commented on this yet, I thought I should do so lest it be forgotten. :) I think it'd be very cool if I could set up one of my list servers to do grab images and do this automatically, perhaps after confirmation from the admin interface (so if it were *really* huge I could refuse to store it, or if I had it grabbing anything that was larger than the limit, I'd probably want to check to make sure it wasn't another copy of SirCam before posting :P ). I'm not too sure it'd be useful to the world as a whole, but I do this manually now for one server's worth of lists, so maybe implementing it for myself would be worth it. It's funny that you should mention it, because I got a handful of images sent to one of my smaller lists this week and I was actually thinking about this just before you posted. It's good to know that using list security is easy, too. Ages ago, we contemplated using mailman passwords to allow access to a linuxchix wiki (It seems sorta wrong to limit access to a wiki, but linuxchix is a likely target for trolls... although thankfully we haven't had many on the mailing lists), and although I figured it could be done, it's neat to know where to start if I ever have a similar idea brought up. :) From jra@baylink.com Sat Mar 9 05:25:52 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 9 Mar 2002 00:25:52 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <3C8942B6.914ED2B7@cascade-sys.com>; from "James J. Besemer" <jb@cascade-sys.com> on Fri, Mar 08, 2002 at 03:01:10PM -0800 References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> <20020308123357.59329@scfn.thpl.lib.fl.us> <3C8942B6.914ED2B7@cascade-sys.com> Message-ID: <20020309002552.06681@scfn.thpl.lib.fl.us> On Fri, Mar 08, 2002 at 03:01:10PM -0800, James J. Besemer wrote: > "Jay R. Ashworth" wrote: > > On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote: > > > While, OTOH I agree these more robust formats are the future, it's > > > insane to force them on users and not allow them to turn them off. > > > > As someone who reads half of my mail in Mutt in a vt screen, and the > > other half on my Minstral equipped Palm III, I disagree wildly with > > your characterisation of non-ASCII email as "more robust". > > > > 15 years of varied experience with email administration causes me to > > characterise such email as "more frangible". > > Ok. For argument's sake, strike "more robust". ;o) > > However you characterize them, don't you agree they "are the future" > (which was the main point of my sentence)? For better or worse, I > detect an inexorable trend. I concur with the other guy who noted that trends needn't be inexorable. > More importantly, it seems you would agree there should be a way to > filter them out in list managers, which was my position in starting > this overall thread. If everyone seems to want to filter them out of mailing lists, perhaps there's some moral in that. I don't think, no, that HTML email is at all good. MIME, yeah, no problem; there are *standards* there. There is *no* standardized way to wrap an HTML email so that you can do anything intelligent with it, which is inherent, I think, in the (lack of) design thereof. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From stephen@xemacs.org Sat Mar 9 05:43:11 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 09 Mar 2002 14:43:11 +0900 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <20020309002552.06681@scfn.thpl.lib.fl.us> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> <20020308123357.59329@scfn.thpl.lib.fl.us> <3C8942B6.914ED2B7@cascade-sys.com> <20020309002552.06681@scfn.thpl.lib.fl.us> Message-ID: <878z92e1ow.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Jay" == Jay R Ashworth <jra@baylink.com> writes re HTML email: Jay> which is inherent, I think, in the (lack of) design thereof. What lack of design? It's a near-perfect implementation of "form over substance." -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From jarrell@vt.edu Sat Mar 9 07:52:53 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sat, 09 Mar 2002 02:52:53 -0500 Subject: [Mailman-Developers] big list In-Reply-To: <p05101500b8aede5b5c7b@[207.149.192.229]> References: <15496.61876.621999.288572@anthem.wooz.org> <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020309025146.04556210@lennier.cc.vt.edu> At 01:46 PM 3/8/02 -0800, John W Baxter wrote: >Aside: how far we've come from the old mainframe LISTSERV, the network of >which carefully sent one copy along with a list to addresses to various >neighbors "near" the addressees for further distribution. So quite likely, >only one copy crossed the Atlantic...possibly one one went from Chicago to >Florida, etc etc. Still does, to some extent. Listserv passes jobs to other listservs when it can figure out that's useful. Also, part of the license fee for running listserv is access to be able to distribute big jobs to lsofts large server, and let them deal with delivering it for you. From fil@rezo.net Sat Mar 9 12:40:33 2002 From: fil@rezo.net (Fil) Date: Sat, 9 Mar 2002 13:40:33 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15497.26292.681882.2706@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> Message-ID: <20020309124033.GA31620@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > The good news: thanks for stressing this part of Mailman. I /think/ > cvs now should perform much better. Please try it out. Mailman now I'm trying it now: it's emptying the queue a bit faster, haven't tried to send a new message yet (I'll have to clear the queue intelligently in order to make sure no message intended for other lists are deleted). I'll keep you posted. However the update gives me this bug on http://listes.rezo.net/mailman/listinfo/ (if you click it when you wake up, and it's gone, it means I've found out...) Traceback (most recent call last): File "/home/mailman/scripts/driver", line 82, in run_main main() File "/home/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/home/mailman/Mailman/Cgi/listinfo.py", line 85, in listinfo_overview mlist = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 102, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 541, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 558, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 148, in Lock self.Load() File "/home/mailman/Mailman/MailList.py", line 541, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 561, in CheckVersion Update(self, stored_state) File "/home/mailman/Mailman/versions.py", line 53, in Update CanonicalizeUserOptions(l) File "/home/mailman/Mailman/versions.py", line 349, in CanonicalizeUserOptions if l.getMemberOption(k, mm_cfg.DisableDelivery): File "/home/mailman/Mailman/OldStyleMemberships.py", line 120, in getMemberOption self.__assertIsMember(member) File "/home/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member NotAMemberError: xxxxx@xxxxx (a real address, of course --Fil) -- Fil From fil@rezo.net Sat Mar 9 14:47:36 2002 From: fil@rezo.net (Fil) Date: Sat, 9 Mar 2002 15:47:36 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020309124033.GA31620@rezo.net> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> Message-ID: <20020309144735.GB12353@rezo.net> @ Fil <fil@rezo.net> : > @ Barry A. Warsaw <barry@zope.com> : > > The good news: thanks for stressing this part of Mailman. I /think/ > > cvs now should perform much better. Please try it out. Mailman now I've tried to send again my 'big list' as personalized messages. The messages went out fast, but *First problem:* Although they are personalized (To: address ofg recipient), the messages sent were not VERPed (from the mail.log I saw only "from <listname-bounces@server>", not "from <listname-bounces+XXXX=XX>"). So I did /etc/init.d/mailman stop, in order to be able to read the list config: I checked that "personalize" was still On. It was. And mm_cfg.py contains: VERP_PERSONALIZED_DELIVERIES = 1 VERP_DELIVERY_INTERVAL = 10 OWNERS_CAN_ENABLE_PERSONALIZATION = 1 *Second problem:* Then I did /etc/init.d/mailman start, but the sending of this message did not resume. The message is in qfiles/shunt, but the addresses not yet delivered to are nowhere to be seen. It seems to mean that, if the computer shuts down while Mailman is sending a batch of mails, a portion of the recipients will not receive their copy? I think the right way to do it would be, alongside the xxx.db and xxx.pck files in qfiles/shunt/ , to have a file xxx.dest containing all addresses not yet delived-to (in whatever format), that could be written one every x seconds to disk, in order to be able to resume sending if the computer has crashed, the power failed, or some dumb administrator tried to restart mailman at that moment. *Third problem:* The "a message awaits your approval" mail is empty (the Mailman site is configured as French, maybe that's a source of trouble: I see this strange header : Content-Type: multipart/mixed; charset="fr"; boundary="===============73517001808033933==" ) -- Fil From barry@zope.com Sat Mar 9 17:30:58 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 9 Mar 2002 12:30:58 -0500 Subject: [Mailman-Developers] Database version updates drop nomail settings References: <200202100658.WAA14442@mutiny.2pi.org> Message-ID: <15498.18130.371388.237190@anthem.wooz.org> >>>>> "LN" == Les Niles <les@2pi.org> writes: LN> There's a small bug in 2.1alpha4 in updating a list's database LN> to the DATA_FILE_VERSION, causing "nomail" settings to not be LN> propagated forward: LN> MailList.CheckVersion() reloads the database, taking care to LN> make sure that the reload doesn't trigger a recursive call to LN> CheckVersion(). But if the list wasn't locked, CheckVersion() LN> then calls Lock(), and Lock() calls Load() again, this time LN> generating a recursive call to CheckVersion(). This recursion LN> is only one deep because now the list is locked, but even that LN> is too much for versions.CanonicalizeUserOptions() since it LN> clears the old-style "nomail" flag after setting the delivery LN> status in the new database. I need more help with this one because I cannot reproduce the problem. I've tried taking a MM2.0.8 list, with some members delivery disabled, and done upgrades to cvs. I've tried loading the list in its locked and unlocked state. In every case I see the disabled flag propagate to the updated list. Of course, the member management page shows the reason for disabled as [?] which is correct. I have a tentative patch to versions.py that at least stops CanonicalizeUserOptions() from running more than once. But I can't judge the correctness of Les's patch unless I have a reproducible bug. So if you have some explicit steps to trigger the bug, please send them on, otherwise, I can't do much about this. If it's a real bug, I'm sure it will come up during beta testing, but that might be too late (i.e. it might bite badly for people who are, er, more enthusiastic about upgrading. ;). -Barry From barry@zope.com Sat Mar 9 17:34:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 9 Mar 2002 12:34:05 -0500 Subject: [Mailman-Developers] Problem while upgrade to mailman 2.1 alpha References: <Pine.LNX.4.33.0201021731560.29329-100000@poli.feld.cvut.cz> Message-ID: <15498.18317.38810.183796@anthem.wooz.org> >>>>> "DO" == Dan Ohnesorg <dan@ohnesorg.cz> writes: DO> I am also triing to upgrade to never version and I have this DO> troubles: DO> Mailman.Errors.NotAMemberError: fickman@atlas.cz DO> and it is alo true, that this user is listed only in section | 'user_options': { '3zsmost@schoolnet.cz': 8, | 'fickman@atlas.cz': 8, DO> of dump_db. DO> Sure, the database is corrupt, but it is not fatal, i think DO> the upgrage should run OK. I don't remember why, but I think it is possible in MM2.0.something for an address to get stuck in user_options but not be in members or digest_members. Here's a patch that I think I'm going to check in that does two things: - it puts a membership check for the keys in usr_options and if that fails, it removes the key from user_options. - it sets a `fence' in the list's attributes so that once CanonicalizeUserOptions() has been run on a list, it won't be run again. Comments are welcome, -Barry Index: versions.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/versions.py,v retrieving revision 2.21 diff -u -r2.21 versions.py --- versions.py 7 Mar 2002 22:24:03 -0000 2.21 +++ versions.py 9 Mar 2002 17:32:42 -0000 @@ -329,6 +329,10 @@ def CanonicalizeUserOptions(l): """Fix up the user options.""" + # I want to put a flag in the list database which tells this routine to + # never try to canonicalize the user options again. + if getattr(l, 'useropts_version', 0) > 0: + return # pre 1.0rc2 to 1.0rc3. For all keys in l.user_options to be lowercase, # but merge options for both cases options = {} @@ -346,10 +350,15 @@ # get/setDeilveryStatus(). This must be done after the addresses are # canonicalized. for k, v in l.user_options.items(): + if not l.isMember(k): + # There's a key in user_options that isn't associated with a real + # member address. This is likely caused by an earlier bug. + del l.user_options[k] if l.getMemberOption(k, mm_cfg.DisableDelivery): # Convert this flag into a legacy disable l.setDeliveryStatus(k, UNKNOWN) l.setMemberOption(k, mm_cfg.DisableDelivery, 0) + l.useropts_version = 1 From barry@zope.com Sat Mar 9 17:53:00 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 9 Mar 2002 12:53:00 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> Message-ID: <15498.19452.486537.764090@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> *First problem:* Although they are personalized (To: address F> ofg recipient), the messages sent were not VERPed (from the F> mail.log I saw only "from <listname-bounces@server>", not "from F> <listname-bounces+XXXX=XX>"). Fixed in cvs. F> *Second problem:* Then I did /etc/init.d/mailman start, but the F> sending of this message did not resume. F> The message is in qfiles/shunt, but the addresses not yet F> delivered to are nowhere to be seen. It seems to mean that, if F> the computer shuts down while Mailman is sending a batch of F> mails, a portion of the recipients will not receive their copy? F> I think the right way to do it would be, alongside the xxx.db F> and xxx.pck files in qfiles/shunt/ , to have a file xxx.dest F> containing all addresses not yet delived-to (in whatever F> format), that could be written one every x seconds to disk, in F> order to be able to resume sending if the computer has crashed, F> the power failed, or some dumb administrator tried to restart F> mailman at that moment. Think of shunt as a safety net. If Mailman has a bug that causes an uncaught exception to occur while handling the message, it gets shuffled off to shunt, so that once the bug is fixed, you ought to be able to move the message back to qfiles/in and have it delivered again. I may do two additional things with shunt: first, I should probably include a key in the metadata to indicate which queue the shunted file came from, and second, I want to add a bin/unshunt command which will re-queue shunted messages safely and correctly. As to your other problem, I'm going to have to think about that. I agree that it's not good that if Mailman is shut down that messages are delivered either twice or not at all. A solution will likely require some disk i/o, but the question is, how to do things robustly without hammering the disk. F> *Third problem:* The "a message awaits your approval" mail is F> empty (the Mailman site is configured as French, maybe that's a F> source of trouble: I see this strange header : Content-Type: F> multipart/mixed; charset="fr"; F> boundary="===============73517001808033933==" ) I'll look into that one too. -Barry From les@2pi.org Sat Mar 9 21:06:51 2002 From: les@2pi.org (Les Niles) Date: Sat, 9 Mar 2002 13:06:51 -0800 Subject: [Mailman-Developers] Database version updates drop nomail settings In-Reply-To: <15498.18130.371388.237190@anthem.wooz.org> (barry@zope.com) References: <200202100658.WAA14442@mutiny.2pi.org> <15498.18130.371388.237190@anthem.wooz.org> Message-ID: <200203092106.NAA10748@mutiny.2pi.org> On Sat, 9 Mar 2002 12:30:58 -0500 barry@zope.com (Barry A. Warsaw) wrote: > >>>>>> "LN" == Les Niles <les@2pi.org> writes: > > LN> There's a small bug in 2.1alpha4 in updating a list's database > LN> to the DATA_FILE_VERSION, causing "nomail" settings to not be > LN> propagated forward: >... > >I need more help with this one because I cannot reproduce the >problem. I've tried taking a MM2.0.8 list, with some members delivery >disabled, and done upgrades to cvs. I've tried loading the list in >its locked and unlocked state. In every case I see the disabled flag >propagate to the updated list. Of course, the member management page >shows the reason for disabled as [?] which is correct. > >I have a tentative patch to versions.py that at least stops >CanonicalizeUserOptions() from running more than once. But I can't >judge the correctness of Les's patch unless I have a reproducible >bug. So if you have some explicit steps to trigger the bug, please >send them on, otherwise, I can't do much about this. It looks like you've already fixed it in CVS. I just confirmed that I could reproduce the original bug after backing out my patch. (Actually I brain-farted and first tried to reproduce it without backing out the patch....) But when I hacked versions.py to initialize delivery_status with add_only_if_missing() as is done in the current CVS version -- in 2.1alpha4 delivery_status was just set to {} -- the problem disappeared. (I left the add_only_if_missing() in my code, since that seems like a much better fix than mucking around with MailList.Lock().) BTW, the way I produced the problem was just by copying a lists/<listname> directory -- for a list with some disabled-delivery subscribers -- from 2.0beta6 to 2.1alpha4. >If it's a real bug, I'm sure it will come up during beta testing, but >that might be too late (i.e. it might bite badly for people who are, >er, more enthusiastic about upgrading. ;). Yeah, it tended to cause unrest when folks had set up disabled- delivery subscriptions to be able to post from alternate addresses and all of a sudden started getting multiple copies of every message. ;) -les From colin@mackinlay.demon.co.uk Sat Mar 9 22:28:18 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Sat, 9 Mar 2002 22:28:18 +0000 (GMT) Subject: [Mailman-Developers] Headers and footers not appearing Message-ID: <Marcel-1.53-0309222818-480hxQ&@demon.co.uk> Hi, I seem to have lost the ability to add a customised footer and header to messages. The FAQ says it was a problem in 2.0 and fixed in 2.1. -- Colin Mackinlay From fil@rezo.net Sun Mar 10 00:22:27 2002 From: fil@rezo.net (Fil) Date: Sun, 10 Mar 2002 01:22:27 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15498.19452.486537.764090@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> Message-ID: <20020310002227.GA9790@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > F> *Third problem:* The "a message awaits your approval" mail is > F> empty (the Mailman site is configured as French, maybe that's a > F> source of trouble: I see this strange header : Content-Type: > F> multipart/mixed; charset="fr"; > F> boundary="===============73517001808033933==" ) > > I'll look into that one too. I think I've got it: the French translation of "This is a multi-part message in MIME format. " lacks the trailing linefeeds. Hence mutt (at least mutt) does not detect the part of the multipart message and shows an empty mail. -- Fil From fil@rezo.net Sun Mar 10 00:27:41 2002 From: fil@rezo.net (Fil) Date: Sun, 10 Mar 2002 01:27:41 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020310002227.GA9790@rezo.net> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> Message-ID: <20020310002741.GA10317@rezo.net> @ Fil <fil@rezo.net> : > @ Barry A. Warsaw <barry@zope.com> : > > F> *Third problem:* The "a message awaits your approval" mail is > > F> empty (the Mailman site is configured as French, maybe that's a > > F> source of trouble: I see this strange header : Content-Type: > > F> multipart/mixed; charset="fr"; > > F> boundary="===============73517001808033933==" ) > > > > I'll look into that one too. > > I think I've got it: the French translation of Not sure now: I've tried to get the mail through SquirrelMail (a nice php webmail), and it says: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Body retrieval error. The reason for this is most probably that the message is malformed. Please help us making future versions better by submitting this message to the developers knowledgebase! Submit message Response: OK Message: FETCH completed FETCH line: * OK [PARSE] Ignoring nested encoding of multipart contents --------------- Return-Path: <spip-bounces@rezo.net> Received: from miel.brainstorm.fr (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with ESMTP id 072E51C1AE; Sun, 10 Mar 2002 01:03:55 +0100 (CET) Received: from miel.brainstorm.fr (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with ESMTP id B1A9E1C1AE for <spip-owner@rezo.net>; Sun, 10 Mar 2002 01:03:53 +0100 (CET) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: =?iso-8859-1?q?Une_soumission_sur_la_li?= =?iso-8859-1?q?ste_spip_=E0_partir_de_mou?= =?iso-8859-1?q?stapha=2Ecom=40parisfree=2Ecom?= =?iso-8859-1?q?_requiert_une_approbation?= From: spip-owner@rezo.net To: spip-owner@rezo.net Message-ID: <mailman.4.1015718632.14118.spip@rezo.net> Date: Sun, 10 Mar 2002 01:03:52 +0100 X-BeenThere: spip@rezo.net X-Mailman-Version: 2.1a4+ Precedence: bulk List-Help: <mailto:spip-request@rezo.net?subject=help> List-Post: <mailto:spip@rezo.net> List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip>, <mailto:spip-request@rezo.net?subject=subscribe> List-Id: SPIP : questions/reponses <spip.rezo.net> List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip>, <mailto:spip-request@rezo.net?subject=unsubscribe> List-Archive: http://listes.rezo.net/archives/spip/ Content-Type: multipart/mixed; charset="fr"; boundary="===============021006692614097044==" Sender: spip-bounces@rezo.net Errors-To: spip-bounces@rezo.net Content-Length: 3819 Lines: 128 --===============021006692614097044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit --===============021006692614097044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit --===============021006692614097044== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit En tant qu'administrateur de liste, votre autorisation est n=E9cessaire pour l'envoi du message suivant vers la liste: -- Fil From njs+mailman@scifi.squawk.com Sun Mar 10 00:21:43 2002 From: njs+mailman@scifi.squawk.com (Nick Simicich) Date: Sat, 09 Mar 2002 19:21:43 -0500 Subject: [Mailman-Developers] big list In-Reply-To: <5.1.0.14.2.20020309025146.04556210@lennier.cc.vt.edu> References: <p05101500b8aede5b5c7b@[207.149.192.229]> <15496.61876.621999.288572@anthem.wooz.org> <20020308162458.GE27629@rezo.net> <20020308163302.GG27629@rezo.net> <15496.59759.624694.875487@anthem.wooz.org> <20020308164257.GA1668@rezo.net> <15496.60323.371912.238703@anthem.wooz.org> <1015607103.14990.8.camel@gaspode.localnet> <15496.61876.621999.288572@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020309184422.0570be98@127.0.0.1> At 02:52 AM 2002-03-09 -0500, Ron Jarrell wrote: >At 01:46 PM 3/8/02 -0800, John W Baxter wrote: > >Aside: how far we've come from the old mainframe LISTSERV, the network of > >which carefully sent one copy along with a list to addresses to various > >neighbors "near" the addressees for further distribution. So quite likely, > >only one copy crossed the Atlantic...possibly one one went from Chicago to > >Florida, etc etc. > >Still does, to some extent. Listserv passes jobs to other listservs when it >can figure out that's useful. Also, part of the license fee for running >listserv >is access to be able to distribute big jobs to lsofts large server, and >let them >deal with delivering it for you. Actually, the recent releases say things in their control file like "This server has been down since 1999 and it does not look like it will ever be brought up again." And Listserv has gone "open source". I have decided to migrate away from my hand tuned Majordomo 1, and I have been investigating various mailing list programs. (Mailman is one of them -- and I am still unsure what version I should install --- since this is a new attempt at installation, should I install the beta, or should I stick with the stable version? -- I really want custom footers...) I got a copy of the open source listserv, and I have compiled it, but so far as I can tell, the distribution is missing essential text files that do not come except with a licensed prepared binary copy - it is about to get deleted from my system, even though it seems to have a bunch of nice features, and I have a kind of nostalgic desire to run it. The folding of network topology knowledge into the mail distribution manager made sense when networks were simpler - and when they typically were store and forward. Remember that the network this was made for was an "NJE" or "RSCS" store and forward network - the unit of transmission was not the packet, it was an e-mail (actually, file, an e-mail was just a file with a special name)...the e-mail was not sent directly to a destination, in fact, there was no way to get to the destination "directly" unless it was local. The e-mail was sent to a node that was closer to the destination. And that node figured out a route and sent it on forward. It *could* take days for a message to cross the Atlantic if the links were saturated. And it was not unheard for a bunch of messages to be spun off to tape, and for that tape to be Fedexed or DHL'd to a node much closer to the destination, so as to get around an overloaded link. (We used a bitnet like network in IBM --- and sometimes there was only a small pathway between countries, with files that could take a day in transit tying it up. Early versions of the protocol could send one thing at a time across a link, and short files were preferred, but once a long file started, it monopolized the link until it finished. Later versions could subdivide a link and multiplex.) The point was that the machines like Listserv, or the thing called Toolsrun that we used inside of IBM, could "understand" the network topology and could shed subscriptions to closer servers. As well as holding archives closer to the end user.... But these days, frankly, teaching your mailing list server about network topology seems counter-productive. The knowledge of network topology belongs, if anywhere, in the MTA and the database that describes that, in our case, the DNS. For example, the concept of "Florida" is more or less meaningless. My system is in Florida, the one that I am typing this note on. The packets that leave this system go to a router that, I am told, has a "Florida" name when I reverse translate it, but which is actually in Chicago somewhere. They actually traverse the link on something that is probably ATM, with virtual circuits set up so that it is actually a small piece of a bigger pipe -- but the next time that this is surfaced into a router that looks at the IP layer is across the country. So for me to look for an IRC server that is in Chicago is sort of silly. Those packets at least go across the country once, and then they might come back to Florida - even if they come back on XO's net, they cross the country twice. Putting this sort of "layer violation" in Listserv was probably essential at the time. A link of 4800 BPS or slower was not uncommon at the time that the Bitnet protocols were designed. 1200 was the limit for dial-ups, and a lot of mail was moved by store and forwards such as bitnet, or even uucpnet. For a long time, RSCS nodes would not burst - that is, you could not drop a piece of mail into the RSCS or NJE networks with multiple destinations and have it manage the shipment of copies to end nodes. Every destination had to have its own copy traversing those slow links. But had that existed from day one, the listserv and toolsrun shedding of subscriptions to "closer" nodes might never have existed. From my listserv control file: ># NOTE: as of May 1999 the global server is down, and it may never be ># re-established. So for now the following two items should remain ># commented out. - Harold > ># Define the global query server for all lists worldwide. If you ># don't want your server to forward requests for unknown lists, ># comment out this line. Otherwise, you should leave it as-is. ># >#global-query-server listproc@listproc.listproc.net listproc.listproc.net 372 > ># Define the master server for collecting global list information, and ># the time to send a list of published lists daily. Comment this out ># if you don't want your server to notify the global server about your ># published lists. Otherwise, this should be left as-is. ># >#global-update-server global-update-server@listproc.listproc.net 04:00 -- War is an ugly thing, but it is not the ugliest of things. The decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight, nothing he cares about more than his own personal safety, is a miserable creature who has no chance of being free, unless made so by the exertions of better men than himself. -- John Stuart Mill Nick Simicich - njs@scifi.squawk.com From njs+mailman@scifi.squawk.com Sun Mar 10 00:36:08 2002 From: njs+mailman@scifi.squawk.com (Nick Simicich) Date: Sat, 09 Mar 2002 19:36:08 -0500 Subject: [Mailman-Developers] Please Allow Me To Introduce Myself... In-Reply-To: <20020309002552.06681@scfn.thpl.lib.fl.us> References: <3C8942B6.914ED2B7@cascade-sys.com> <jb@cascade-sys.com> <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <200203061922.LAA28720@mutiny.2pi.org> <3C86709B.C5F55E31@cascade-sys.com> <20020308123357.59329@scfn.thpl.lib.fl.us> <3C8942B6.914ED2B7@cascade-sys.com> Message-ID: <5.1.0.14.2.20020309192212.03005970@127.0.0.1> At 12:25 AM 2002-03-09 -0500, Jay R. Ashworth wrote: >If everyone seems to want to filter them out of mailing lists, perhaps >there's some moral in that. I wrote a program called "demime" that lives in a pipe ahead of all my lists. It strips out mime, leaving plain text, removing attachments, alternate sections and the like. It also will remove advertising footers that people like yahoo and Juno don't pay me to redistribute or to store in my archives (and my own footers that people can't be persuaded to snip). :-) There are a number of people running it - if you are interested, I suggest you check http://scifi.squawk.com/demime.html, and join the mailing list. >I don't think, no, that HTML email is at all good. MIME, yeah, no >problem; there are *standards* there. There is *no* standardized way >to wrap an HTML email so that you can do anything intelligent with it, >which is inherent, I think, in the (lack of) design thereof. I agree. Now add that to my urge not to allow people to distribute viruses and worms via my lists and many people's inability to do anything but sending plain text (what do you mean I didn't send plain text? This is plain text, it just has some different colors and fonts and stuff. Don't be silly.) or to tell plain text from mime, and it is essential, in my opinion, to have some tool that can convert the user's text back to plain text. It is written in Perl, by the way, sorry about that. I know Perl better than I know Python. There are people who have been using demime for years. I have been using it for years. It should *not* be used on the address that catches bounces, but it can be used in front of your command alias and your mailing list submission alias. -- War is an ugly thing, but it is not the ugliest of things. The decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight, nothing he cares about more than his own personal safety, is a miserable creature who has no chance of being free, unless made so by the exertions of better men than himself. -- John Stuart Mill Nick Simicich - njs@scifi.squawk.com From che@debian.org Sun Mar 10 00:38:12 2002 From: che@debian.org (Ben Gertzfield) Date: Sun, 10 Mar 2002 09:38:12 +0900 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <Marcel-1.53-0309222818-480hxQ&@demon.co.uk> (Colin Mackinlay's message of "Sat, 9 Mar 2002 22:28:18 +0000 (GMT)") References: <Marcel-1.53-0309222818-480hxQ&@demon.co.uk> Message-ID: <87d6ydgsuj.fsf@nausicaa.interq.or.jp> >>>>> "Colin" == Colin Mackinlay <colin@mackinlay.demon.co.uk> writes: Colin> Hi, I seem to have lost the ability to add a customised Colin> footer and header to messages. The FAQ says it was a Colin> problem in 2.0 and fixed in 2.1. Read the list archives -- you're probably posting messages in iso-8859-1 or utf-8 to a list set to English (us-ascii). Mailman CVS does not add footers if the charsets of the message and footers do not match. I posted a patch to loosen these rules, always adding footers if the list is us-ascii, but it hasn't been checked in yet. Ben -- Brought to you by the letters M and J and the number 19. "Killer refresh rate! It's even got a PCI bus!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From marc_news@vasoftware.com Sun Mar 10 04:30:03 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 9 Mar 2002 20:30:03 -0800 Subject: [Mailman-Developers] [BUG] Users are created as moderated in CVS mailman In-Reply-To: <87it87kbhy.fsf@nausicaa.interq.or.jp>; from che@debian.org on Fri, Mar 08, 2002 at 12:02:33PM +0900 References: <87it87kbhy.fsf@nausicaa.interq.or.jp> Message-ID: <20020309203003.E16205@merlins.org> On Fri, Mar 08, 2002 at 12:02:33PM +0900, Ben Gertzfield wrote: > I'm not at all sure why this is, but on a completely fresh install of > CVS mailman, even though DEFAULT_NEW_MEMBER_OPTIONS = 256, all my new > list members are created with the 'moderated' flag on. Look for this in Defaults.py: # Should list members, by default, have their posts be moderated? DEFAULT_DEFAULT_MEMBER_MODERATION = 1 (introduced recently and not linked to what I fed to Barry) However, I just realized that when I prepared my updated patch that I fed to Barry last week, I forgot this: --- mailman-wp/Mailman/versions.py Fri Aug 17 14:40:28 2001 +++ mailman/Mailman/versions.py Thu Sep 6 12:55:00 2001 @@ -211,7 +211,7 @@ add_only_if_missing('one_last_digest', {}) add_only_if_missing('usernames', {}) add_only_if_missing('personalize', 0) - + add_only_if_missing('default_options', mm_cfg.DEFAULT_LIST_OPTIONS) Without this, people who upgrade their lists do not get the default value set to what's in mm_cfg.py, but of course newly created lists should work just fine. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From colin@mackinlay.demon.co.uk Sun Mar 10 10:59:19 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Sun, 10 Mar 2002 10:59:19 +0000 (GMT) Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <87d6ydgsuj.fsf@nausicaa.interq.or.jp> Message-ID: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> In <URL:news:local.mailman-d> on Sun 10 Mar, Ben Gertzfield wrote: > >>>>> "Colin" == Colin Mackinlay <colin@mackinlay.demon.co.uk> writes: > > Colin> Hi, I seem to have lost the ability to add a customised > Colin> footer and header to messages. The FAQ says it was a > Colin> problem in 2.0 and fixed in 2.1. > > Read the list archives -- you're probably posting messages in > iso-8859-1 or utf-8 to a list set to English (us-ascii). Mailman CVS > does not add footers if the charsets of the message and footers do not > match. That's strange then, I only use plain text and the same format has had a footer added to it by this list :-) Thanks for the tip, I'll look into it. -- Colin Mackinlay From che@debian.org Sun Mar 10 14:17:39 2002 From: che@debian.org (Ben Gertzfield) Date: Sun, 10 Mar 2002 23:17:39 +0900 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> (Colin Mackinlay's message of "Sun, 10 Mar 2002 10:59:19 +0000 (GMT)") References: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> Message-ID: <878z90h5h8.fsf@nausicaa.interq.or.jp> >>>>> "Colin" == Colin Mackinlay <colin@mackinlay.demon.co.uk> writes: Colin> That's strange then, I only use plain text and the same Colin> format has had a footer added to it by this list :-) Sure. "plain text" messages can have Content-Type: headers specifying any charset, so make sure you look at those. Ben -- Brought to you by the letters T and L and the number 11. "A squib is a firecracker." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From colin@mackinlay.demon.co.uk Sun Mar 10 16:29:48 2002 From: colin@mackinlay.demon.co.uk (Colin Mackinlay) Date: Sun, 10 Mar 2002 16:29:48 +0000 (GMT) Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <878z90h5h8.fsf@nausicaa.interq.or.jp> Message-ID: <Marcel-1.53-0310162948-84fhxQ&@demon.co.uk> On Sun 10 Mar, Ben Gertzfield wrote: > > >>>>> "Colin" == Colin Mackinlay <colin@mackinlay.demon.co.uk> writes: > > Colin> That's strange then, I only use plain text and the same > Colin> format has had a footer added to it by this list :-) > > Sure. "plain text" messages can have Content-Type: headers > specifying any charset, so make sure you look at those. Yes and mine say US-ASCII, have a look! -- Colin Mackinlay From jwblist@olympus.net Sun Mar 10 18:03:54 2002 From: jwblist@olympus.net (John W Baxter) Date: Sun, 10 Mar 2002 10:03:54 -0800 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> References: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> Message-ID: <p05101500b8b15039f30f@[207.149.192.229]> At 10:59 +0000 3/10/2002, Colin Mackinlay wrote: >In <URL:news:local.mailman-d> on Sun 10 Mar, Ben Gertzfield wrote: >> >>>>> "Colin" == Colin Mackinlay <colin@mackinlay.demon.co.uk> writes: >> >> Colin> Hi, I seem to have lost the ability to add a customised >> Colin> footer and header to messages. The FAQ says it was a >> Colin> problem in 2.0 and fixed in 2.1. >> >> Read the list archives -- you're probably posting messages in >> iso-8859-1 or utf-8 to a list set to English (us-ascii). Mailman CVS >> does not add footers if the charsets of the message and footers do not >> match. > >That's strange then, I only use plain text and the same format has had >a footer added to it by this list :-) You're posting as Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Question for the gurus: could the upper case content type description be causing problems here? --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From fil@rezo.net Sun Mar 10 20:35:24 2002 From: fil@rezo.net (Fil) Date: Sun, 10 Mar 2002 21:35:24 +0100 Subject: [Mailman-Developers] BounceRunner eating up alot of memory Message-ID: <20020310203524.GC2198@rezo.net> Hi, after a few more tests, I am confronted to a problem: the BounceRunner seems to load the list in its memory when it receives a bounce (in order to process that bounce). But it does this: 1- regardless of whether it's going to need the list or not 2- without releasing the memory afterwards I can live with 1-, but 2- can be a problem if you have several big lists. On my installation currently the BounceRunner has 92Mb of RAM. I don't mind it taking whatever it needs, but it should release it if I don't want to spend too much time swapping memory to disk. All in all, I'm really starting to wonder why the list settings' data and the list members' data are mixed in one single pck file, and not in two (or more) separate files. When you need only to check the list settings, it would be so much faster to load a 1k file than to process a 77Mb file? In many situations it seems that would make Mailman much faster and have a smaller mem footprint! -- Fil From barry@zope.com Sun Mar 10 22:50:06 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 10 Mar 2002 17:50:06 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> Message-ID: <15499.58142.434820.798285@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: BAW> Think of shunt as a safety net. If Mailman has a bug that BAW> causes an uncaught exception to occur while handling the BAW> message, it gets shuffled off to shunt, so that once the bug BAW> is fixed, you ought to be able to move the message back to BAW> qfiles/in and have it delivered again. BAW> I may do two additional things with shunt: first, I should BAW> probably include a key in the metadata to indicate which BAW> queue the shunted file came from, and second, I want to add a BAW> bin/unshunt command which will re-queue shunted messages BAW> safely and correctly. This is now done. BAW> As to your other problem, I'm going to have to think about BAW> that. I agree that it's not good that if Mailman is shut BAW> down that messages are delivered either twice or not at all. BAW> A solution will likely require some disk i/o, but the BAW> question is, how to do things robustly without hammering the BAW> disk. This should be solved too. First, Mailman already attempts to cleanly shut down the qrunner loops on receipt of SIGHUP or SIGTERM. Second, should an error occur, the message's metadata dictionary (i.e. its .db file) will containe a list of as-yet-undelivered recipients. So upon restart or unshunting, it should continue where it's left off. To reduce the impact on the disk, it will only maintain undelivered addresses per `chunk', which can be SMTP_MAX_RCPTS, or per-address if VERPing. I think this is a fine tradeoff (some small number of folks /might/ get duplicates, but no one should miss a message). -Barry From barry@zope.com Sun Mar 10 22:51:37 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 10 Mar 2002 17:51:37 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> Message-ID: <15499.58233.558446.909705@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I think I've got it: the French translation of F> "This is a multi-part message in MIME format. F> " F> lacks the trailing linefeeds. Hence mutt (at least mutt) does F> not detect the part of the multipart message and shows an empty F> mail. Ousmane does a very good job of keeping the French translation up-to-date. Hopefully he will look into this and fix whatever might be necessary. -Barry From wilane@yahoo.com Mon Mar 11 01:49:12 2002 From: wilane@yahoo.com (Ousmane Wilane) Date: Mon, 11 Mar 2002 01:49:12 +0000 Subject: [Mailman-Developers] big list In-Reply-To: <15499.58233.558446.909705@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> Message-ID: <15500.3352.980046.610866@localhost.localdomain> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: >>>>> "F" == Fil <fil@rezo.net> writes: F> I think I've got it: the French translation of "This is a F> multi-part message in MIME format." I didn't find the offending string anywhere in the current Mailman source tree. Perhaps I'm overlooking something. Fil can you help me find it and fix it please! BTW IIRC, I use to run msghack/msgfmt on the catalog to make sure that everything is ok. F> lacks the trailing linefeeds. Hence mutt (at least mutt) does not F> detect the part of the multipart message and shows an empty mail. BAW> Ousmane does a very good job of keeping the French translation BAW> up-to-date. Hopefully he will look into this and fix whatever BAW> might be necessary. Thanks! I'm trying to do my best but as noted by Fil in one of his messages, French is not my mother tongue, so there are many imperfections laying around and I'm eager to get more involvement for proofreading and alike. Cheers -- Ousmane Wilane From che@debian.org Mon Mar 11 02:30:20 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 11 Mar 2002 11:30:20 +0900 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <p05101500b8b15039f30f@[207.149.192.229]> (John W Baxter's message of "Sun, 10 Mar 2002 10:03:54 -0800") References: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <p05101500b8b15039f30f@[207.149.192.229]> Message-ID: <87vgc3g7k3.fsf@nausicaa.interq.or.jp> >>>>> "John" == John W Baxter <John> writes: John> You're posting as John> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John> Question for the gurus: could the upper case content type John> description be causing problems here? It very well could be. The problem is that *some* headers are case-sensitive (like Subject) and others are not (like Content-Type). I haven't been putting in random .lower() calls on every string, so we'll probably run into some of these issues. Barry, do you think the email module should just deal with this somehow? Ben -- Brought to you by the letters L and H and the number 3. "Frungy! Frungy! Frungy!!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Mon Mar 11 04:30:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 10 Mar 2002 23:30:23 -0500 Subject: [Mailman-Developers] Headers and footers not appearing References: <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <p05101500b8b15039f30f@[207.149.192.229]> <87vgc3g7k3.fsf@nausicaa.interq.or.jp> Message-ID: <15500.13023.997616.478835@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: >>>>> "John" == John W Baxter <John> writes: John> You're posting as John> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John> Question for the gurus: could the upper case content type John> description be causing problems here? BG> It very well could be. The problem is that *some* headers BG> are case-sensitive (like Subject) and others are not BG> (like Content-Type). I haven't been putting in random BG> .lower() calls on every string, so we'll probably run BG> into some of these issues. BG> Barry, do you think the email module should just deal with BG> this somehow? There are a number of RFC-ish things I think email should eventually do (probably not for 1.1). E.g. it should enforce the RFC specified max and min on numbers of headers (e.g. RFC 2822 says From: must appear once and only once). We could do some more enforcement of case sensitivity, but I also think Mailman ought to be more robust. I suspect that we're not doing case folding on parameters retrieved with email.Message.Message.get_param(). Note that get_type() already folds to lowercase, since it's obvious that MIME types are case insensitive. get_param() /matches/ case insensitively, but returns the case preserved version of the parameter. I'm going to try to dig up Ben's patch and I'll double check that the parameters are being compared case insensitively. -Barry From barry@zope.com Mon Mar 11 04:55:34 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 10 Mar 2002 23:55:34 -0500 Subject: [Mailman-Developers] BounceRunner eating up alot of memory References: <20020310203524.GC2198@rezo.net> Message-ID: <15500.14534.533083.330631@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> after a few more tests, I am confronted to a problem: the F> BounceRunner seems to load the list in its memory when it F> receives a bounce (in order to process that bounce). But it F> does this: 1- regardless of whether it's going to need the list F> or not 2- without releasing the memory afterwards F> I can live with 1-, but 2- can be a problem if you have several F> big lists. For 1) It's pretty much going to need the list object, but perhaps you mean the list lock? I'm not going to worry about that. For 2) That's a valid point. Please try the following patch (untested). I'll try to test it and if it looks good, I'll commit this change tomorrow. F> All in all, I'm really starting to wonder why the list F> settings' data and the list members' data are mixed in one F> single pck file, and not in two (or more) separate files. When F> you need only to check the list settings, it would be so much F> faster to load a 1k file than to process a 77Mb file? In many F> situations it seems that would make Mailman much faster and F> have a smaller mem footprint! I know it's bad, but at least the situation isn't any worse than it was for MM2.0. Fixing this is off the table for MM2.1, because it's long overdue and a change like this would be too disruptive. Fixing this is (a large part of) what MM3.0 is all about. -Barry Index: BounceRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/BounceRunner.py,v retrieving revision 2.9 diff -u -r2.9 BounceRunner.py --- BounceRunner.py 7 Mar 2002 22:30:04 -0000 2.9 +++ BounceRunner.py 11 Mar 2002 04:51:36 -0000 @@ -31,6 +31,7 @@ class BounceRunner(Runner): QDIR = mm_cfg.BOUNCEQUEUE_DIR + CACHELISTS = 0 def _dispose(self, mlist, msg, msgdata): outq = get_switchboard(mm_cfg.OUTQUEUE_DIR) Index: Runner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/Runner.py,v retrieving revision 2.17 diff -u -r2.17 Runner.py --- Runner.py 11 Mar 2002 04:21:33 -0000 2.17 +++ Runner.py 11 Mar 2002 04:51:37 -0000 @@ -34,9 +34,11 @@ class Runner: - def __init__(self, slice=None, numslices=1, cachelists=1): + CACHELISTS = 1 + + def __init__(self, slice=None, numslices=1): self._kids = {} - self._cachelists = cachelists + self._cachelists = self.CACHELISTS # Create our own switchboard. Don't use the switchboard cache because # we want to provide slice and numslice arguments. self._switchboard = Switchboard(self.QDIR, slice, numslices) From marc_news@vasoftware.com Mon Mar 11 04:59:01 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 10 Mar 2002 20:59:01 -0800 Subject: [Mailman-Developers] [BUG] Users are created as moderated in CVS mailman In-Reply-To: <20020309203003.E16205@merlins.org>; from marc_news@vasoftware.com on Sat, Mar 09, 2002 at 08:30:03PM -0800 References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <20020309203003.E16205@merlins.org> Message-ID: <20020310205901.G16205@merlins.org> On Sat, Mar 09, 2002 at 08:30:03PM -0800, Marc MERLIN wrote: > However, I just realized that when I prepared my updated patch that I fed to > Barry last week, I forgot this: > > --- mailman-wp/Mailman/versions.py Fri Aug 17 14:40:28 2001 > +++ mailman/Mailman/versions.py Thu Sep 6 12:55:00 2001 > @@ -211,7 +211,7 @@ > add_only_if_missing('one_last_digest', {}) > add_only_if_missing('usernames', {}) > add_only_if_missing('personalize', 0) > - > + add_only_if_missing('default_options', mm_cfg.DEFAULT_LIST_OPTIONS) Never mind, long days of snowboarding, not enough sleep :-) Barry did include this in mailman-cvs already. I simply missed it initially because he changed the option name to a more explicit name. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Mar 11 05:32:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 00:32:25 -0500 Subject: [Mailman-Developers] a problem in upgrading with moderated lists References: <20011228011526.F2576@orwell.bok.net> Message-ID: <15500.16746.517004.32738@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Hi, F> when you upgrade Mailman to 2.1a3 from 2.0, moderated lists F> correctly take on the attributes | generic_nonmember_action = Hold | default_member_moderation = Yes F> However the latter is valid only for NEW F> subscribers. Subscribers already registered have their F> moderation bit set to 0 (not moderated) whereas it should be F> set to 1 (moderated) to conform to the previous settings. Good point, fixed. F> And, by the way, these settings are not given through F> config_list -o Fixed too. :) Thanks, -Barry From marc_news@vasoftware.com Mon Mar 11 05:34:30 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 10 Mar 2002 21:34:30 -0800 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? Message-ID: <20020310213430.J16205@merlins.org> On my test list, which doesn't have reply-to munging enabled, if I send a test post with a reply-to header, it doesn't make it to the list (or to ToOutgoing for that matter) Before I look into this deeper, is this just me? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@wooz.org Mon Mar 11 05:41:18 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Mon, 11 Mar 2002 00:41:18 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <87it87kbhy.fsf@nausicaa.interq.or.jp> Message-ID: <15500.17278.993364.826959@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> I'm not at all sure why this is, but on a completely fresh BG> install of CVS mailman, even though DEFAULT_NEW_MEMBER_OPTIONS BG> = 256, all my new list members are created with the BG> 'moderated' flag on. For new members, the moderation bit flag is controlled by the list configuration attribute default_member_moderation. See the Privacy/Sender Filters for the list config and DEFAULT_DEFAULT_MEMBER_MODERATION for the initial value of this attribute. I want to keep these separate because I want default_member_moderation to be config'd in the Privacy category. I'll add a note to the DEFAULT_NEW_MEMBER_OPTIONS comment in Defaults.py.in. -Barry From barry@zope.com Mon Mar 11 05:49:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 00:49:05 -0500 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? References: <20020310213430.J16205@merlins.org> Message-ID: <15500.17745.830490.33730@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> On my test list, which doesn't have reply-to munging enabled, MM> if I send a test post with a reply-to header, it doesn't make MM> it to the list (or to ToOutgoing for that matter) MM> Before I look into this deeper, is this just me? Look for first_strip_reply_to under the General category. :) -Barry From barry@zope.com Mon Mar 11 05:56:06 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 00:56:06 -0500 Subject: [Mailman-Developers] BounceRunner eating up alot of memory References: <20020310203524.GC2198@rezo.net> <15500.14534.533083.330631@anthem.wooz.org> Message-ID: <15500.18166.423899.863801@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: BAW> For 2) That's a valid point. Please try the following patch BAW> (untested). I'll try to test it and if it looks good, I'll BAW> commit this change tomorrow. If you apply the patch, you'll also have to fix the __init__() method of the OutgoingRunner. Remove the cachelists argument. -Barry From marc_news@vasoftware.com Mon Mar 11 06:01:36 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 10 Mar 2002 22:01:36 -0800 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? In-Reply-To: <15500.17745.830490.33730@anthem.wooz.org> References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> Message-ID: <20020311060135.GC2972@merlins.org> On Mon, Mar 11, 2002 at 12:49:05AM -0500, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: > > MM> On my test list, which doesn't have reply-to munging enabled, > MM> if I send a test post with a reply-to header, it doesn't make > MM> it to the list (or to ToOutgoing for that matter) > > MM> Before I look into this deeper, is this just me? > > Look for first_strip_reply_to under the General category. :) I did, but: ('first_strip_reply_to', mm_cfg.Radio, (_('No'), _('Yes')), 0, _('''Before adding a list-specific <tt>Reply-To:</tt> header, should any existing <tt>Reply-To:</tt> field be stripped from the message?''')), This implies (and I just checked in Cookheaders) that stripping should only occur if I have reply-to munging turned on, which in my case, is not something very likely :-) Basically, I'm saying that if I post to a list without reply-to munging, if I set (as a poster) a reply-to, it doesn't make it to the list. (I just checked on 2 other machines where I have mailman-cvs installed) Marc PS: As a pointer, if the message gets automatically rejected and sent back to the sender, the Reply-To is still there -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che@debian.org Mon Mar 11 07:05:25 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 11 Mar 2002 16:05:25 +0900 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15500.17278.993364.826959@anthem.wooz.org> (barry@wooz.org's message of "Mon, 11 Mar 2002 00:41:18 -0500") References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> Message-ID: <87elirfutm.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes: >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> I'm not at all sure why this is, but on a completely fresh BG> install of CVS mailman, even though DEFAULT_NEW_MEMBER_OPTIONS BG> = 256, all my new list members are created with the BG> 'moderated' flag on. BAW> For new members, the moderation bit flag is controlled by the BAW> list configuration attribute default_member_moderation. See BAW> the Privacy/Sender Filters for the list config and BAW> DEFAULT_DEFAULT_MEMBER_MODERATION for the initial value of BAW> this attribute. Okay, but this means that new list members will not be able to post to lists until the admin sets them to be un-moderated, right, by default? What exactly do we gain from this? This was a *completely fresh* install of CVS mailman, and I had to go in and turn the 'moderated' flag off for all users I added to any lists. Ben -- Brought to you by the letters U and Z and the number 14. "Sculch is junk." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From fil@rezo.net Mon Mar 11 07:53:25 2002 From: fil@rezo.net (Fil) Date: Mon, 11 Mar 2002 08:53:25 +0100 Subject: [Mailman-Developers] BounceRunner eating up alot of memory In-Reply-To: <15500.14534.533083.330631@anthem.wooz.org> References: <20020310203524.GC2198@rezo.net> <15500.14534.533083.330631@anthem.wooz.org> Message-ID: <20020311075325.GF29396@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > For 2) That's a valid point. Please try the following patch > (untested). I'll try to test it and if it looks good, I'll commit > this change tomorrow. There must be something missing: Traceback (most recent call last): File "/home/mailman/bin/qrunner", line 265, in ? main() File "/home/mailman/bin/qrunner", line 212, in main qrunner = make_qrunner(*runners[0]) File "/home/mailman/bin/qrunner", line 118, in make_qrunner qrunner = qrclass(slice, range) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 42, in __init__ Runner.__init__(self, slice, numslices) File "/home/mailman/Mailman/Queue/Runner.py", line 43, in __init__ self._cachelists = CACHELISTS NameError: global name 'CACHELISTS' is not defined -- Fil From fil@rezo.net Mon Mar 11 08:14:20 2002 From: fil@rezo.net (Fil) Date: Mon, 11 Mar 2002 09:14:20 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15500.3352.980046.610866@localhost.localdomain> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> Message-ID: <20020311081420.GG29396@rezo.net> @ Ousmane Wilane <wilane@yahoo.com> : > >>>>> "F" == Fil <fil@rezo.net> writes: > F> I think I've got it: the French translation of "This is a > F> multi-part message in MIME format." I was wrong, sorry Ousmane. It's something in the way the multi-part message is formed, but I can't find what (I don't know enough about MIME). However I could "bounce" the problematic messages to Barry if he wanted. In short, it's every notice from mailman, and even some messages (at least one) that go through. -- Fil From marc_news@vasoftware.com Mon Mar 11 09:18:54 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 11 Mar 2002 01:18:54 -0800 Subject: [Mailman-Developers] New option for mailman-cvs: reply-to munging per user Message-ID: <20020311011854.L16205@merlins.org> --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, so my plan was to make listwide reply-to munging go away (well, it would still be there, but hopefully not needed in most cases/installations). Two things were needed for that: - no dupe patch written by Ben and already in mailman cvs thanks to Barry - for really whiney users who just don't want to use reply to all to reply to a list post and who are not going to leave you alone (kind of defies logic, but this is a topic where logic does not apply), I spent the last evenings writing a new setting: reply-to munging per user and per list Per Barry's recommendation, I wrote this by adding a flag for each user and duping each list message (munged and non munged version) and sending the right version to each user. Since this adds some processing, I added an optimization to bypass this code if no one on the list requests munging. Munging per user is both a setting that is system wide, and if it's allowed, it can be allowed listwide (system wide defaults to yes, list wide to no). I've also made normal listwide reply-to munging a system wide option that can be turned off. Note that this code is functional, but still has a couple of rough edges 1) I didn't give is as much testing as I would have liked (I just finished it and I need to get a little sleep before I go to work :-D) 2) It is missing the code to disable split munge/no munge processing if the last munge user goes back to nomunge Actually, I just thought about doing this by setting mixed_reply_to_munging_users back to 0 if after scanning the list at sending time, we find out that one of the two posts isn't being sent to anyone. (And I'll also have to deal with the pathological case where all the list users set themselves to munging) 3) It still has some debugging code in there I'm simply posting this right now because I'd like to get feedback from you and Barry on the implementation and python details before I send a polished patch to Barry for his consideration. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="replyto.diff" Binary files mailman-cvs.freeze/Mailman/Cgi/.options.py.swp and mailman-cvs.freeze.replyto/Mailman/Cgi/.options.py.swp differ diff -urN mailman-cvs.freeze/Mailman/Cgi/admin.py mailman-cvs.freeze.replyto/Mailman/Cgi/admin.py --- mailman-cvs.freeze/Mailman/Cgi/admin.py Mon Mar 11 00:37:03 2002 +++ mailman-cvs.freeze.replyto/Mailman/Cgi/admin.py Mon Mar 11 00:04:21 2002 @@ -47,7 +47,7 @@ i18n.set_language(mm_cfg.DEFAULT_SERVER_LANGUAGE) NL = '\n' -OPTCOLUMNS = 11 +OPTCOLUMNS = 12 @@ -869,7 +869,7 @@ _('mod'), _('hide'), _('nomail<br>[reason]'), _('ack'), _('not metoo'), - _('nodupes'), + _('nodupes'), _('replyto'), _('digest'), _('plain'), _('language'))]) rowindex = usertable.GetCurrentRowIndex() @@ -909,7 +909,7 @@ checked = 0 box = CheckBox('%s_mod' % addr, value, checked) cells.append(Center(box).Format()) - for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes'): + for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes', 'replyto'): extra = '' if opt == 'nomail': status = mlist.getDeliveryStatus(addr) @@ -989,6 +989,8 @@ _('''<b>nodupes</b> -- Does the member want to avoid duplicates of the same message?''')) legend.AddItem( + _('''<b>replyto</b> -- Does the member want to have reply-to munged to the list address? (note that it will not be active until per_user_reply_to_allowed is enabled)''')) + legend.AddItem( _('''<b>digest</b> -- Does the member get messages in digests? (otherwise, individual messages)''')) legend.AddItem( @@ -1337,7 +1339,8 @@ mlist.setDeliveryStatus(user, MemberAdaptor.BYADMIN) else: mlist.setDeliveryStatus(user, MemberAdaptor.ENABLED) - for opt in ('hide', 'ack', 'notmetoo', 'nodupes', 'plain'): + for opt in ('hide', 'ack', 'notmetoo', 'nodupes', 'replyto', + 'plain'): opt_code = option_info[opt] if cgidata.has_key('%s_%s' % (user, opt)): mlist.setMemberOption(user, opt_code, 1) diff -urN mailman-cvs.freeze/Mailman/Cgi/options.py mailman-cvs.freeze.replyto/Mailman/Cgi/options.py --- mailman-cvs.freeze/Mailman/Cgi/options.py Tue Mar 5 22:24:49 2002 +++ mailman-cvs.freeze.replyto/Mailman/Cgi/options.py Mon Mar 11 00:22:11 2002 @@ -425,6 +425,7 @@ ('remind', mm_cfg.SuppressPasswordReminder), ('rcvtopic', mm_cfg.ReceiveNonmatchingTopics), ('nodupes', mm_cfg.DontReceiveDuplicates), + ('replyto', mm_cfg.AddListReplyTo), ): try: newval = int(cgidata.getvalue(item)) @@ -497,8 +498,7 @@ finally: mlist.Unlock() - # The enable/disable option and the password remind option may have - # their global flags sets. + # Several options support having their global flags sets. global_enable = None if cgidata.getvalue('deliver-globally'): # Yes, this is inefficient, but the list is so small it shouldn't @@ -605,6 +605,18 @@ mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user)) replacements['<mm-receive-duplicates-button>'] = ( mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user)) + # Let's not tempt the user with an option we're not giving him :) + # (yes, this a _very_ sleazy hack, I know :-D) -- Marc + if mlist.per_user_reply_to_allowed: + replacements['<mm-munge-replyto-hide1>'] = ( '' ) + replacements['<mm-munge-replyto-hide2>'] = ( '' ) + else: + replacements['<mm-munge-replyto-hide1>'] = ( '<!---' ) + replacements['<mm-munge-replyto-hide2>'] = ( '--->' ) + replacements['<mm-munge-replyto-button>'] = ( + mlist.FormatOptionButton(mm_cfg.AddListReplyTo, 1, user)) + replacements['<mm-dont-munge-replyto-button>'] = ( + mlist.FormatOptionButton(mm_cfg.AddListReplyTo, 0, user)) replacements['<mm-unsubscribe-button>'] = ( mlist.FormatButton('unsub', _('Unsubscribe')) + '<br>' + CheckBox('unsubconfirm', 1, checked=0).Format() + diff -urN mailman-cvs.freeze/Mailman/Defaults.py.in mailman-cvs.freeze.replyto/Mailman/Defaults.py.in --- mailman-cvs.freeze/Mailman/Defaults.py.in Fri Mar 8 21:05:23 2002 +++ mailman-cvs.freeze.replyto/Mailman/Defaults.py.in Sun Mar 10 18:47:30 2002 @@ -754,6 +754,33 @@ from: .*@uplinkpro.com """ + +# Reply-To munging should really not exist. Each user can tell mailman not +# to send them list copies when people group reply (nodupes feature), but the +# other reason is that some users really insist on not using reply to all, and +# absolutely want to use their reply function to reply to the list. +# If teaching them to use their mail client properly with the aid of a baseball +# bat is not an option, instead of forcing reply-to munging on the whole list +# (DEFAULT_REPLY_GOES_TO_LIST), and screwing all the users who don't want it, +# you can allow a per user reply-to setting. +# As soon as a list member selects this, it will cause each message to be +# duplicated in your spool (one copy with reply-to, and one copy without), and +# it will also force a scan of the list userlist to see which user gets which +# message. You may notice a slowdown on lists with several thousand users. +# List admins will be allowed to turn this on and off on a per list basis, +# but this variable takes precedence over the listmaster(s) setting +# Set to 1 to enable +SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING = 1 + +# Now, you can choose the default value for new lists (should remain '0' unless +# you have to accomodate users who beg for the misfeature, and list server can +# accomodate the additional load) +DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING = 0 + +# You can turn off the various Reply-To munging mistfeatures on a sitewide basis +# here (the above two options should allow everyone to live without them) +SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING = 1 + # Mailman can be configured to "munge" Reply-To: headers for any passing # messages. One the one hand, there are a lot of good reasons not to munge # Reply-To: but on the other, people really seem to want this feature. See @@ -767,7 +794,7 @@ # Before munging Reply-To: Mailman can be configured to strip any existing # Reply-To: header first, or simply extend any existing Reply-To: with one # based on the above setting. This is a boolean variable. -DEFAULT_FIRST_STRIP_REPLY_TO = 1 +DEFAULT_FIRST_STRIP_REPLY_TO = 0 # SUBSCRIBE POLICY # 0 - open list (only when ALLOW_OPEN_SUBSCRIBE is set to 1) ** @@ -1005,6 +1032,7 @@ ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 +AddListReplyTo = 512 # Authentication contexts. # Binary files mailman-cvs.freeze/Mailman/Gui/.General.py.swp and mailman-cvs.freeze.replyto/Mailman/Gui/.General.py.swp differ diff -urN mailman-cvs.freeze/Mailman/Gui/General.py mailman-cvs.freeze.replyto/Mailman/Gui/General.py --- mailman-cvs.freeze/Mailman/Gui/General.py Tue Mar 5 22:24:49 2002 +++ mailman-cvs.freeze.replyto/Mailman/Gui/General.py Sun Mar 10 22:40:07 2002 @@ -57,7 +57,8 @@ optvals = [mlist.new_member_options & bitfields[o] for o in OPTIONS] opttext = [bitdescrs[o] for o in OPTIONS] - rtn = [ + rtn = [ ] + rtn.extend ( ( _('''Fundamental list characteristics, including descriptive info and basic behaviors.'''), @@ -147,9 +148,38 @@ posted to the list, to distinguish mailing list messages in in mailbox summaries. Brevity is premium here, it's ok to shorten long mailing list names to something more concise, as long as it - still identifies the mailing list.""")), + still identifies the mailing list.""")) + ) ) - _('''<tt>Reply-To:</tt> header munging'''), + if (mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING or + mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING ): + rtn.append ( _('''<tt>Reply-To:</tt> header munging''') ) + + + if (mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING ): + rtn.append ( + + ('per_user_reply_to_allowed', mm_cfg.Radio, (_('No'), _('Yes')), 0, + _('''Allow users to individually set a Reply-To to the list?<BR> + Note: this will create additional load, read details.'''), + _("""This option allows individual users to ask the list to + munge posts just for them.<BR> + As soon as a list member selects this, it will cause each message + to be duplicated in your spool (one copy with reply-to, and one + copy without), and it will also force a scan of the list userlist + to see which user gets which message. You may notice a slowdown on + lists with several thousand users and in this case it may be + inadvisable to allow this<BR> + You may also want all your users to learn to use reply to all for + list replies and force this setting off as a result. On the + flipside, it is better to enable this setting and allow a few + users to munge their posts than to turn on reply-to munging for + the whole list and prevent all the users from doing simple replies + to sender""")) + ) + + if (mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING ): + rtn.extend ( ( ('first_strip_reply_to', mm_cfg.Radio, (_('No'), _('Yes')), 0, _('''Before adding a list-specific <tt>Reply-To:</tt> header, @@ -225,7 +255,9 @@ <p>Note that if the original message contains a <tt>Reply-To:</tt> header, it will not be changed.""")), + ) ) + rtn.extend ( ( _('Umbrella list settings'), ('umbrella_list', mm_cfg.Radio, (_('No'), _('Yes')), 0, @@ -350,8 +382,7 @@ the mail host's exchanger address, if any. This setting can be useful for selecting among alternative names of a host that has multiple addresses.""")), - - ] + ) ) if mm_cfg.ALLOW_RFC2369_OVERRIDES: rtn.append( diff -urN mailman-cvs.freeze/Mailman/HTMLFormatter.py mailman-cvs.freeze.replyto/Mailman/HTMLFormatter.py --- mailman-cvs.freeze/Mailman/HTMLFormatter.py Tue Mar 5 22:24:46 2002 +++ mailman-cvs.freeze.replyto/Mailman/HTMLFormatter.py Sun Mar 10 18:27:27 2002 @@ -117,6 +117,7 @@ mm_cfg.SuppressPasswordReminder : 'remind', mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic', mm_cfg.DontReceiveDuplicates : 'nodupes', + mm_cfg.AddListReplyTo : 'replyto', }[option] return '<input type=radio name="%s" value="%d"%s>' % ( name, value, checked) diff -urN mailman-cvs.freeze/Mailman/Handlers/CookHeaders.py mailman-cvs.freeze.replyto/Mailman/Handlers/CookHeaders.py --- mailman-cvs.freeze/Mailman/Handlers/CookHeaders.py Fri Mar 8 21:05:25 2002 +++ mailman-cvs.freeze.replyto/Mailman/Handlers/CookHeaders.py Mon Mar 11 00:27:35 2002 @@ -87,7 +87,10 @@ # augment it. RFC 2822 allows max one Reply-To: header so collapse them # if we're adding a value, otherwise don't touch it. (Should we collapse # in all cases?) - if not fasttrack: + # Turning off Reply-To munging on a sitewide basis doesn't reset the list + # option (it just makes it go away from the interface), so we need to + # disable the behavior here -- Marc + if not fasttrack and mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING: # Set Reply-To: header to point back to this list replyto = [] if mlist.reply_goes_to_list == 1: diff -urN mailman-cvs.freeze/Mailman/Handlers/SMTPDirect.py mailman-cvs.freeze.replyto/Mailman/Handlers/SMTPDirect.py --- mailman-cvs.freeze/Mailman/Handlers/SMTPDirect.py Fri Mar 8 21:05:28 2002 +++ mailman-cvs.freeze.replyto/Mailman/Handlers/SMTPDirect.py Mon Mar 11 00:31:06 2002 @@ -81,6 +81,28 @@ if not recips: # Nobody to deliver to! return + + # If the list has a reply-to/non reply-to split, the message gets queued + # twice, once with a Reply-To and once without. We need to weed out the + # members that don't match the current post configuration + # Let's only do this if we have to, if it's currently allowed by the list + # owner, and if it's allowed sitewide -- Marc + #print "Split rp status is: "+`mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING`+"/"+`mlist.per_user_reply_to_allowed`+"/"+`mlist.mixed_reply_to_munging_users` + if mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING and \ + mlist.per_user_reply_to_allowed and mlist.mixed_reply_to_munging_users: + mungedpost=msgdata.get('replytoadded') + #print "Dealing with post with reply-to status "+`mungedpost` + for r in recips[:]: + #print "testing member "+r + if (mungedpost and \ + not mlist.getMemberOption(r, mm_cfg.AddListReplyTo)) \ + or \ + (not mungedpost and \ + mlist.getMemberOption(r, mm_cfg.AddListReplyTo)): + #print "Removing member "+r+" for post status "+`mungedpost` + recips.remove(r) + #print "New receipient list is "+`recips` + # Calculate the non-VERP envelope sender. if mlist: envsender = mlist.getListAddress('bounces') diff -urN mailman-cvs.freeze/Mailman/Handlers/ToOutgoing.py mailman-cvs.freeze.replyto/Mailman/Handlers/ToOutgoing.py --- mailman-cvs.freeze/Mailman/Handlers/ToOutgoing.py Sat Mar 9 19:25:01 2002 +++ mailman-cvs.freeze.replyto/Mailman/Handlers/ToOutgoing.py Mon Mar 11 01:04:43 2002 @@ -24,6 +24,7 @@ from Mailman import mm_cfg from Mailman.Queue.sbcache import get_switchboard +COMMASPACE = ', ' def process(mlist, msg, msgdata): @@ -45,6 +46,29 @@ else: # VERP every `inteval' number of times msgdata['verp'] = not int(mlist.post_id) % interval + # And now drop the message in qfiles/out outq = get_switchboard(mm_cfg.OUTQUEUE_DIR) + msgdata['replytoadded']=0 + #print "\n\nB: "+`msg` + #print "B: "+`msgdata` + # FIXME: Original message reply-to doesn't make it up to here -- Marc outq.enqueue(msg, msgdata, listname=mlist.internal_name()) + + if mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING and \ + mlist.per_user_reply_to_allowed and mlist.mixed_reply_to_munging_users: + msgdata['replytoadded']=1 + # RFC 2822 allows Reply-To to be a list of addresses. Should a mail + # client not be happy with that, the user then has the option of not + # doing header munging in the first place and learning how to use the + # proper reply function of his mailer :-) -- Marc + replyto = [] + replyto.append(mlist.GetListEmail()) + if msg['reply-to']: + replyto.append(msg['reply-to']) + del msg['reply-to'] + msg['Reply-To']=COMMASPACE.join(replyto) + + #print "\n\nA: "+`msg` + #print "A: "+`msgdata` + outq.enqueue(msg, msgdata, listname=mlist.internal_name()) diff -urN mailman-cvs.freeze/Mailman/MailCommandHandler.py mailman-cvs.freeze.replyto/Mailman/MailCommandHandler.py --- mailman-cvs.freeze/Mailman/MailCommandHandler.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.freeze.replyto/Mailman/MailCommandHandler.py Mon Mar 11 00:28:37 2002 @@ -84,6 +84,24 @@ which have you as an explicit recipient (i.e. if you're both a member of the list and in either the To: or Cc: headers).""") +REPLYTO = _(""" +While there are few good reasons to do this, you can ask to have list posts +contain a reply-to pointing back to the list. It's mainly here if you really +can't break the habit to use the reply to sender function of your mail client +to reply to list posts. You should use the reply to all/reply to list function +of your mail client to answer list posts (mailman is smart enough not to send +duplicates if you reply to the list and the poster), and you can use your normal +reply to sender function to reply just to the original post author. + +If this option is allowed by the list and the site owners, turning it on will +cause list posts to contain a Reply-To: header pointing back to the list so that +you can answer list posts with the reply function of your mail client. +Please make note that you will then be unable to reply to the author of a +message without typing his Email address and that many lists will not allow you +to have a Reply-To the list, so you may be better off not changing the meaning +of the reply function and getting used to using reply to all for lists posts +""") + option_desc = {'hide' : HIDE, 'nomail' : NOMAIL, 'ack' : ACK, @@ -91,6 +109,7 @@ 'digest' : DIGEST, 'plain' : PLAIN, 'nodupes' : NODUPES, + 'replyto' : REPLYTO, } # jcrey: and then the real one @@ -102,11 +121,20 @@ 'notmetoo': mm_cfg.DontReceiveOwnPosts, 'digest' : 0, 'plain' : mm_cfg.DisableMime, - 'nodupes' : mm_cfg.DontReceiveDuplicates + 'nodupes' : mm_cfg.DontReceiveDuplicates, + 'replyto' : mm_cfg.AddListReplyTo, } # ordered list -options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes') +options = ['hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes'] + +# We don't know which list the user may be on or is trying to get on, so +# we can't check for mlist.per_user_reply_to_allowed, but we can definitely +# check for mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING +# The idea is not to potentially tempt the user with a feature that may not +# be available :) -- Marc +if mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING: + options.append('replyto') # strip just the outer layer of quotes quotecre = re.compile(r'["\'`](?P<cmd>.*)["\'`]') diff -urN mailman-cvs.freeze/Mailman/MailList.py mailman-cvs.freeze.replyto/Mailman/MailList.py --- mailman-cvs.freeze/Mailman/MailList.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.freeze.replyto/Mailman/MailList.py Sun Mar 10 16:41:56 2002 @@ -259,6 +259,13 @@ self.usernames = {} self.passwords = {} self.new_member_options = mm_cfg.DEFAULT_NEW_MEMBER_OPTIONS + # if you have a least one user who wants personalized munging, each + # message gets dropped twice in the queue, once munged, once not. + # Because this requires resources, and scanning the userlist to see + # who gets each message requires resources too, we don't do this unless + # we have to (we keep track of whether we have mixed users on the list) + # -- Marc + self.mixed_reply_to_munging_users = 0 # This stuff is configurable self.respond_to_post_requests = 1 @@ -270,6 +277,8 @@ % mm_cfg.DEFAULT_URL_HOST self.owner = [admin] self.moderator = [] + self.per_user_reply_to_allowed = \ + mm_cfg.DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.reply_to_address = '' self.first_strip_reply_to = mm_cfg.DEFAULT_FIRST_STRIP_REPLY_TO diff -urN mailman-cvs.freeze/Mailman/OldStyleMemberships.py mailman-cvs.freeze.replyto/Mailman/OldStyleMemberships.py --- mailman-cvs.freeze/Mailman/OldStyleMemberships.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.freeze.replyto/Mailman/OldStyleMemberships.py Mon Mar 11 00:09:20 2002 @@ -300,6 +300,19 @@ # We don't need to touch user_options because the digest state # isn't kept as a bitfield flag. return + + # We need to do special processing on reply-to in case the switch + # causes the first munging user to appear or the last to go away + # -- Marc + if flag == mm_cfg.AddListReplyTo: + if value: + self.__mlist.mixed_reply_to_munging_users=1 + else: + # FIXME, scan list membership and see if all reply-to people + # are gone (this should probably be in a function) -- Marc + #self.__mlist.mixed_reply_to_munging_users=0 + pass + # This is a bit kludgey because the semantics are that if the user has # no options set (i.e. the value would be 0), then they have no entry # in the user_options dict. We use setdefault() here, and then del diff -urN mailman-cvs.freeze/Mailman/Version.py mailman-cvs.freeze.replyto/Mailman/Version.py --- mailman-cvs.freeze/Mailman/Version.py Thu Mar 7 20:32:39 2002 +++ mailman-cvs.freeze.replyto/Mailman/Version.py Sun Mar 10 16:41:56 2002 @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.pck schema version number -DATA_FILE_VERSION = 64 +DATA_FILE_VERSION = 65 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 3 diff -urN mailman-cvs.freeze/Mailman/versions.py mailman-cvs.freeze.replyto/Mailman/versions.py --- mailman-cvs.freeze/Mailman/versions.py Sat Mar 9 19:25:00 2002 +++ mailman-cvs.freeze.replyto/Mailman/versions.py Sun Mar 10 17:08:25 2002 @@ -286,6 +286,8 @@ add_only_if_missing('one_last_digest', {}) add_only_if_missing('usernames', {}) add_only_if_missing('personalize', 0) + add_only_if_missing('per_user_reply_to_allowed', \ + mm_cfg.DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING) add_only_if_missing('first_strip_reply_to', mm_cfg.DEFAULT_FIRST_STRIP_REPLY_TO) add_only_if_missing('unsubscribe_policy', diff -urN mailman-cvs.freeze/templates/en/help.txt mailman-cvs.freeze.replyto/templates/en/help.txt --- mailman-cvs.freeze/templates/en/help.txt Tue Mar 5 22:24:56 2002 +++ mailman-cvs.freeze.replyto/templates/en/help.txt Sun Mar 10 16:41:56 2002 @@ -85,6 +85,20 @@ Cc: fields already or are included in multiple lists in one message. + replyto: + There are few good reasons to do this. It's mainly here if you + really can't break the habit to use the reply to sender function of + your mail client to reply to list posts. You should use the reply + to all/reply to list function of your mail client (mailman is smart + enough not to send duplicates if you reply to the list and the + poster) to answer list posts, and reply to sender should be to + reply just to the original post author. + When turned on however (if allowed by the list and the site owners), + you can ask to have list posts contain a reply-to pointing back to + the list so that you can answer list posts with the reply function + of your mail client. + Please make note that this is a bad habit and that many lists will + not allow you to reply to the list without replying to all options Show the current values of your list options. diff -urN mailman-cvs.freeze/templates/en/options.html mailman-cvs.freeze.replyto/templates/en/options.html --- mailman-cvs.freeze/templates/en/options.html Tue Mar 5 22:24:56 2002 +++ mailman-cvs.freeze.replyto/templates/en/options.html Sun Mar 10 18:18:41 2002 @@ -300,6 +300,36 @@ <mm-global-nodupes-button><i>Set globally</i> </td></tr> + <mm-munge-replyto-hide1> + <tr><td bgcolor="#cccccc"> + <strong>Set Reply-To back to the list?</strong><p> + + There are few good reasons to do this. It's mainly here if + you really can't break the habit to use the reply to sender + function of your mail client to reply to list posts. You + should use the reply to all/reply to list function of your + mail client to answer list posts (mailman is smart enough not to + send duplicates if you reply to the list and the poster), and + you can use your normal reply to sender function to reply just + to the original post author.<P> + + If this option is allowed by the list and the site + owners, turning it on will cause list posts to contain a + <tt>Reply-To:</tt> header pointing back to the list so that + you can answer list posts with the reply function of your mail + client.<BR> + Please make note that you will then be unable to reply to the + author of a message without typing his Email address and that + many lists will not allow you to have a Reply-To the list, so + you may be better off not changing the meaning of the reply + function and getting used to using reply to all for lists posts + + </td><td bgcolor="#cccccc"> + <mm-dont-munge-replyto-button>No + <mm-munge-replyto-button>Yes + </td></tr> + <mm-munge-replyto-hide2> + <tr><TD colspan="2"> <center><MM-options-Submit-button></center> </td></tr> --Y7xTucakfITjPcLV-- From dale@newfield.org Mon Mar 11 10:56:36 2002 From: dale@newfield.org (Dale Newfield) Date: Mon, 11 Mar 2002 05:56:36 -0500 (EST) Subject: [Mailman-Developers] New option for mailman-cvs: reply-to munging per user In-Reply-To: <20020311011854.L16205@merlins.org> Message-ID: <Pine.OSX.4.44.0203110549071.23394-100000@core.newfield.org> On Mon, 11 Mar 2002, Marc MERLIN wrote: > - no dupe patch written by Ben and already in mailman cvs thanks to Barry Just wanted to note that one big piece of this (which is currently left out) still causes other problems. The crossposted message is still recieved multiple times, and even if some data managing system to track deliveries and get it right is built into mailman, that system probably wouldn't work with the smurf army scalability solution. Are there any other elements hiding anywhere that similarly cause the army problems? -Dale From marc_news@vasoftware.com Mon Mar 11 17:18:14 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 11 Mar 2002 09:18:14 -0800 Subject: [Mailman-Developers] nodupes feature In-Reply-To: <Pine.OSX.4.44.0203110549071.23394-100000@core.newfield.org> References: <20020311011854.L16205@merlins.org> <Pine.OSX.4.44.0203110549071.23394-100000@core.newfield.org> Message-ID: <20020311171814.GB24440@merlins.org> On Mon, Mar 11, 2002 at 05:56:36AM -0500, Dale Newfield wrote: > On Mon, 11 Mar 2002, Marc MERLIN wrote: > > - no dupe patch written by Ben and already in mailman cvs thanks to Barry > > Just wanted to note that one big piece of this (which is currently left > out) still causes other problems. The crossposted message is still > recieved multiple times, and even if some data managing system to track Yes, that's known. The piece of code that did that had a tendency to keep using memory until you killed the qrunner. Barry did not include it as a result (Ben is working on rewriting that piece of code in a way that doesn't keep eating memory) It is however possible to add the code back from the original updated patch I posted and restart qrunner nightly to free up the memory. > deliveries and get it right is built into mailman, that system probably > wouldn't work with the smurf army scalability solution. Are there any > other elements hiding anywhere that similarly cause the army problems? nodupes is a per end user feature (enabled by default for new users). It is true that if you forge a Cc in an Email before you send it to the MLM, it will cause that end user to not receive a list ocpy. 1) There isn't much that can be done about that. 2) It will not be an issue in most cases 3) end users worried by this can definitely turn nodupes off (and do deduping with procmail or some such) nodupes was a feature already present in a few advanced MLMs and at least Ben and I saw it as a much needed feature for mailman Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Mar 11 18:46:33 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 13:46:33 -0500 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> Message-ID: <15500.64393.3701.430306@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> Basically, I'm saying that if I post to a list without MM> reply-to munging, if I set (as a poster) a reply-to, it MM> doesn't make it to the list. (I just checked on 2 other MM> machines where I have mailman-cvs installed) I think it's a documentation bug in the description of first_strip_reply_to. The intent is to give the list owner a knob they can use to always strip an existing Reply-To: header, regardless of whether Mailman adds one back or not. -Barry From marc_news@vasoftware.com Mon Mar 11 19:10:05 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 11 Mar 2002 11:10:05 -0800 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? In-Reply-To: <15500.64393.3701.430306@anthem.wooz.org> References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> <15500.64393.3701.430306@anthem.wooz.org> Message-ID: <20020311191005.GA23754@merlins.org> On Mon, Mar 11, 2002 at 01:46:33PM -0500, Barry A. Warsaw wrote: > MM> Basically, I'm saying that if I post to a list without > MM> reply-to munging, if I set (as a poster) a reply-to, it > MM> doesn't make it to the list. (I just checked on 2 other > MM> machines where I have mailman-cvs installed) > > I think it's a documentation bug in the description of > first_strip_reply_to. The intent is to give the list owner a knob > they can use to always strip an existing Reply-To: header, regardless > of whether Mailman adds one back or not. Mmmh, I'm really not sure why one would want that. Replacing a user's Reply-To with the list munged Reply-to can make sense (and it's yet another reason why listwide reply-to munging is bad, since you lose the reply address of the poster if he/she set a reply-to to a different account). However, having mailman unconditionally remove poster set reply-tos (to a different account or a different list), doesn't seem to be an option that makes too much sense. But yes, re-reading Handlers/CookHeaders.py I now see why this is happening. It seems that the code doesn't do what the option was meant to do, per the documentation, the comment in Defaults.py, and the fact that it's in the reply-to munging section.` # Before munging Reply-To: Mailman can be configured to strip any existing # Reply-To: header first, or simply extend any existing Reply-To: with one # based on the above setting. This is a boolean variable. DEFAULT_FIRST_STRIP_REPLY_TO = 1 Would you agree that this setting was really meant to select whether, only in the case where you do listwide reply-to munging, you replace the reply-to with the list reply-to or you add the list reply-to to the sender's set reply-to? In this case, would you also agree that since RFC 2822 does allow two addresses or more in the Reply-to header, DEFAULT_FIRST_STRIP_REPLY_TO should really default to 0, because your code that extends the existing reply-to allows for the reply to go to both the list and the reply-to address the sender specified? (my patch on per-user reply-to munging doesn't have this switch, because should the end user have an MUA that barfs on multiple Emails in Reply-To, and I have yet to meet one, (s)he always has the option of not doing munging. Leaving this, as a disabled option by default, for listwide munging can't hurt though) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Mar 11 19:20:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 14:20:05 -0500 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> <15500.64393.3701.430306@anthem.wooz.org> <20020311191005.GA23754@merlins.org> Message-ID: <15501.869.162663.145248@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> Mmmh, I'm really not sure why one would want that. I think the idea is that a list admin might want to force reply-to-alls to go back to the whole list. MM> Would you agree that this setting was really meant to select MM> whether, only in the case where you do listwide reply-to MM> munging, you replace the reply-to with the list reply-to or MM> you add the list reply-to to the sender's set reply-to? I don't remember, but thinking about it now, I think there's little harm in allowing the list admin to strip reply-to even if they're not going to munge it. I'm not saying it's a good idea, but then we all know where that leads to. ;) MM> In this case, would you also agree that since RFC 2822 does MM> allow two addresses or more in the Reply-to header, MM> DEFAULT_FIRST_STRIP_REPLY_TO should really default to 0, MM> because your code that extends the existing reply-to allows MM> for the reply to go to both the list and the reply-to address MM> the sender specified? Yes, it should default to 0. I'll make that change. -Barry From marc_news@vasoftware.com Mon Mar 11 19:34:19 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 11 Mar 2002 11:34:19 -0800 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? In-Reply-To: <15501.869.162663.145248@anthem.wooz.org> References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> <15500.64393.3701.430306@anthem.wooz.org> <20020311191005.GA23754@merlins.org> <15501.869.162663.145248@anthem.wooz.org> Message-ID: <20020311193418.GC23754@merlins.org> On Mon, Mar 11, 2002 at 02:20:05PM -0500, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: > > MM> Mmmh, I'm really not sure why one would want that. > > I think the idea is that a list admin might want to force > reply-to-alls to go back to the whole list. Reply to all will reply to the Reply-To + To + Cc list in the MUAs I looked at. In other words, a poster can't stop a reply to all from going to the list by setting a weird value in the Reply-To header. So, if I post this: From: <add1@domain.tld> To: <add2@domain.tld> Cc: add3@domain.tld Reply-To: add4@domain.tld Reply to all will send mail to: To: add4@domain.tld Cc: add2@domain.tld, add3@domain.tld > MM> Would you agree that this setting was really meant to select > MM> whether, only in the case where you do listwide reply-to > MM> munging, you replace the reply-to with the list reply-to or > MM> you add the list reply-to to the sender's set reply-to? > > I don't remember, but thinking about it now, I think there's little > harm in allowing the list admin to strip reply-to even if they're not > going to munge it. I'm not saying it's a good idea, but then we all > know where that leads to. ;) Sure, if you want to do that.. Make sure you also update the comment in Defaults.py then > MM> DEFAULT_FIRST_STRIP_REPLY_TO should really default to 0, > > Yes, it should default to 0. I'll make that change. Thanks. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From mailman-users@python.org Mon Mar 11 20:41:27 2002 From: mailman-users@python.org (Marc MERLIN) Date: Mon, 11 Mar 2002 12:41:27 -0800 Subject: [Mailman-Developers] Feedback needed: nodupes patch and reply-to munging per user Message-ID: <20020311204127.GE23754@merlins.org> [I'm Ccing mailman-developers in case a few people there aren't on mailman-users, but please reply on mailman-users] Ben Gertzfield wrote a patch which Barry recently included in mailman-cvs which allows you to not receive the list copy of a message in you were Cced in the headers (nodupes patch). The idea is to reproduce the (imo sole useful) feature of reply-to munging where people don't get two copies of replies to posts. After porting his patch to mailman-cvs, I've written another patch that extends this functionality by making reply-to munging a per user option. The idea is that I tried to provide an alternative to listwide reply-to munging because I truly belive that is bad for many reasons that I won't list here again, but if you're curious, have a look at: http://marc.merlins.org/netrants/listreplyto.html http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1 (please note, this is _not_ meant to start a thread on whether munging is good or bad) The idea was to settle this issue for good by offering, in place of listwide reply-to munging (which would still be an option in mailman, just not one that most people would need anymore): - optional non sending of list posts if you are Cced so that you don't get two copies (nodupes patch, already in CVS) - per user reply-to munging, if you have list users who just will not accept to use reply to all to reply to list posts Since there have always been endless arguments on whether the listwide setting should be on or off, I'm hoping that moving this to a per user option will make most if not all of these arguments go away. The idea is that reply-to munging would stay off, users have the option (enabled by default) to not receive two copies of replies, and people who really want to use reply to sender to reply to list posts get a separate copy of list posts with a Reply-To header in there. I've written the per user munging part, and announced it to mailman-developers last night: http://mail.python.org/pipermail/mailman-developers/2002-March/011068.html Barry is wondering if this is going to be useful to other people or not and would like feedback. So, could you let us know here (mailman-users) if you would have use for my patch or if you have questions/comments about it. If you think the patch is stupid and shouldn't be in mailman, you can tell us that too :-) (note that the feature has to be enabled by the site and list owners, since it does cause additional processing on your list server) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From bob@nleaudio.com Mon Mar 11 21:01:42 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Mon, 11 Mar 2002 16:01:42 -0500 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> <15500.64393.3701.430306@anthem.wooz.org> <20020311191005.GA23754@merlins.org> <15501.869.162663.145248@anthem.wooz.org> <20020311193418.GC23754@merlins.org> Message-ID: <3C8D1B36.F8699588@nleaudio.com> > Reply to all will reply to the Reply-To + To + Cc list in the MUAs I looked > at. Not true for all. I haven't checked recently, but the Netscape Mail I used to use would send to the reply-to address exclusively, if it was defined, and not include anything else. Bob From marc_news@vasoftware.com Mon Mar 11 22:20:10 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 11 Mar 2002 14:20:10 -0800 Subject: [Mailman-Developers] Does mailman-cvs remove reply-to? In-Reply-To: <3C8D1B36.F8699588@nleaudio.com> References: <20020310213430.J16205@merlins.org> <15500.17745.830490.33730@anthem.wooz.org> <20020311060135.GC2972@merlins.org> <15500.64393.3701.430306@anthem.wooz.org> <20020311191005.GA23754@merlins.org> <15501.869.162663.145248@anthem.wooz.org> <20020311193418.GC23754@merlins.org> <3C8D1B36.F8699588@nleaudio.com> Message-ID: <20020311222009.GG23754@merlins.org> On Mon, Mar 11, 2002 at 04:01:42PM -0500, Bob Puff@NLE wrote: > > Reply to all will reply to the Reply-To + To + Cc list in the MUAs I looked > > at. > > Not true for all. I guess I'm not too surprised. I'm not too sure the behavior in this case is well defined. I just know that when I Cc lists and set a reply-to to redirect answers, it's only indicative and Iv'e seen many MUAs reply to both lists when the user did a reply to all. > I haven't checked recently, but the Netscape Mail I used to use would send > to the reply-to address exclusively, if it was defined, and not include > anything else. I just tried again with netscape 6/mozilla, and reply to all replies to all 3 addresses (To, Cc, and Reply-To), just like mutt did. All that said, I agree with you that the behavior is most likely undefined, and that the only thing you can rely on is that setting a reply-to will not redirect reply to all off the To and Cc headers for many if not most MUAs Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Tue Mar 12 04:17:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Mar 2002 23:17:42 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> Message-ID: <15501.33126.725011.122075@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I was wrong, sorry Ousmane. F> It's something in the way the multi-part message is formed, but F> I can't find what (I don't know enough about MIME). However I F> could "bounce" the problematic messages to Barry if he F> wanted. In short, it's every notice from mailman, and even some F> messages (at least one) that go through. I believe this is fixed now in cvs, but it required some changes to the email package (now embodied in version 1.2). Please do a cvs update and see if the problem is fixed for you. I could reproduce the bug in the English version and it looks fixed now. -Barry From barry@wooz.org Tue Mar 12 06:24:03 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 12 Mar 2002 01:24:03 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> Message-ID: <15501.40707.412796.594457@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> Okay, but this means that new list members will not be able to BG> post to lists until the admin sets them to be un-moderated, BG> right, by default? Their postings will be held for approval, correct. BG> What exactly do we gain from this? I seem to remember some discussion on this topic a week or so ago. It seemed to me that the consensus was to quarantine new list members by default. I might be mistaken (about the consensus), but it seems like as reasonable a default as not quarantining them. -Barry From barry@zope.com Tue Mar 12 06:28:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 01:28:27 -0500 Subject: [Mailman-Developers] Database version updates drop nomail settings References: <200202100658.WAA14442@mutiny.2pi.org> <15498.18130.371388.237190@anthem.wooz.org> <200203092106.NAA10748@mutiny.2pi.org> Message-ID: <15501.40972.3201.452983@anthem.wooz.org> >>>>> "LN" == Les Niles <les@2pi.org> writes: LN> BTW, the way I produced the problem was just by copying a LN> lists/<listname> directory -- for a list with some LN> disabled-delivery subscribers -- from 2.0beta6 to 2.1alpha4. Cool. I'm much more confident that the bug is now squashed in cvs. I've done this several times (actually copied a list from 2.0.8 to 2.1cvs) and with different combinations of nomail settings, and all the upgrades seem to work. >> If it's a real bug, I'm sure it will come up during beta >> testing, but that might be too late (i.e. it might bite badly >> for people who are, er, more enthusiastic about upgrading. ;). LN> Yeah, it tended to cause unrest when folks had set up LN> disabled- delivery subscriptions to be able to post from LN> alternate addresses and all of a sudden started getting LN> multiple copies of every message. ;) Yeah, that would suck. :) Thanks, -Barry From barry@zope.com Tue Mar 12 06:45:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 01:45:24 -0500 Subject: [Mailman-Developers] Macintosh files when uploading "mass subscription " lists References: <20020308144430.GD12523@rezo.net> Message-ID: <15501.41988.502097.407139@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> 1) when I send a Macintosh file for "mass subscription" via the F> web, Mailman does not understand the Mac's linefeeds as F> separators for addresses, and sees just one (wrong) address. This should be fixed now in cvs. F> 2) When users reply to a confirmation cookie, they usually send F> their cookie followed by several lines of whatever F> (signature). Mailman sends them the "your message in error" F> reply, instead of "welcome !" Fixing this requires a rewrite of the mail command handler, something I've decided to put off until after MM2.1. For now, it's a minor inconvenience (they still confirm their action). -Barry From barry@wooz.org Tue Mar 12 06:54:13 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 12 Mar 2002 01:54:13 -0500 Subject: [Mailman-Developers] Re: Bug in latest CVS: confirm.py References: <200203080228.g282SKcW001887@utopia.West.Sun.COM> Message-ID: <15501.42517.983985.487467@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> Bug in latest confirm.py: passwords not completely stamped DM> out. Breaks Web subscription confirmations. Fixed, thanks! -Barry From chuqui@plaidworks.com Tue Mar 12 06:59:01 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 11 Mar 2002 22:59:01 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15501.40707.412796.594457@anthem.wooz.org> Message-ID: <B8B2E735.1BA77%chuqui@plaidworks.com> On 3/11/02 10:24 PM, "Barry A. Warsaw" <barry@wooz.org> wrote: > Their postings will be held for approval, correct. > > BG> What exactly do we gain from this? A couple of things. First, it stops the "subscribe and spam", which is a growing problem. It's not an issue with the big spammers (except on major list sites like yahoogroups, where it IS increasingly a hassle), but the small guys, especially if you have a list that their products target. Second, you stop the rolling troll fights. You get a jerk on the list. You kick the jerk off the list. The jerk decides to make your life miserable, so you start this rolling fight over trying to keep one step ahead of his latest free account that he subscribes with to continue his troll. Third, some admins want new users to watch the list for a while before posting, or at the least, prevent new users from doing stupid things. So this gives them a chance to enforce that request. For heavily focussed lists that are serious about signal instead of noise, it can be useful. I also know some admins that want to see two or three postings from a person before they "trust" them with open access to the list. ON some lists, I can understand that desire, too. Basically, it gives admins another tool to try to cut the noise. Some admins really want this. Some will consider it an abomination. It's all in your admin style. I'd want it for the first two. I might use the last two tactically on SOME lists, or in some circumstances, but not generally. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From chuqui@plaidworks.com Tue Mar 12 07:01:11 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 11 Mar 2002 23:01:11 -0800 Subject: [Mailman-Developers] Macintosh files when uploading "mass subscription " lists In-Reply-To: <15501.41988.502097.407139@anthem.wooz.org> Message-ID: <B8B2E7B7.1BA78%chuqui@plaidworks.com> On 3/11/02 10:45 PM, "Barry A. Warsaw" <barry@zope.com> wrote: > F> 2) When users reply to a confirmation cookie, they usually send > F> their cookie followed by several lines of whatever > F> (signature). Mailman sends them the "your message in error" > F> reply, instead of "welcome !" > > Fixing this requires a rewrite of the mail command handler, something > I've decided to put off until after MM2.1. For now, it's a minor > inconvenience (they still confirm their action). What about just stopping processing of a message once you see the confirm? Is that reasonable? What are the chances of there being multiple confirms or commands in a single message? Is it reasonable to restrict it to one command per e-mail in this case, so you can exit before sending an error? Could you keep state, and if you've seen a confirm and acted, exit without the error? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From barry@zope.com Tue Mar 12 07:14:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 02:14:01 -0500 Subject: [Mailman-Developers] Macintosh files when uploading "mass subscription " lists References: <15501.41988.502097.407139@anthem.wooz.org> <B8B2E7B7.1BA78%chuqui@plaidworks.com> Message-ID: <15501.43705.302099.766990@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: CVR> What about just stopping processing of a message once you see CVR> the confirm? Is that reasonable? It's entirely reasonable... unless you've looked at the code. ;) The mail command processor is one of the last things (not counting pipermail) that I've wanted to rip out and rewrite, because it's hard to do things exactly like this. I may have a lapse of sanity, or an insomniatic attack, and actually do it before MM2.1, or I might get a bright idea on how to wedge this in painlessly. We'll see. -Barry From chuqui@plaidworks.com Tue Mar 12 07:23:50 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 11 Mar 2002 23:23:50 -0800 Subject: [Mailman-Developers] Macintosh files when uploading "mass subscription " lists In-Reply-To: <15501.43705.302099.766990@anthem.wooz.org> Message-ID: <B8B2ED06.1BA89%chuqui@plaidworks.com> On 3/11/02 11:14 PM, "Barry A. Warsaw" <barry@zope.com> wrote: > The mail command processor is one of the last things (not counting > pipermail) that I've wanted to rip out and rewrite, because it's hard > to do things exactly like this. Fair enough. Just thought I'd ask. > I may have a lapse of sanity, or an insomniatic attack, and actually > do it before MM2.1, or I might get a bright idea on how to wedge this > in painlessly. We'll see. If this is the worst mis-feature in MM 2.1, we owe you a beer or five. I wouldn't bother, unless it's trivial. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From che@debian.org Tue Mar 12 07:33:45 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 12 Mar 2002 16:33:45 +0900 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15501.40707.412796.594457@anthem.wooz.org> (barry@wooz.org's message of "Tue, 12 Mar 2002 01:24:03 -0500") References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> <15501.40707.412796.594457@anthem.wooz.org> Message-ID: <871yeqdyue.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes: >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> Okay, but this means that new list members will not be able to BG> post to lists until the admin sets them to be un-moderated, BG> right, by default? BAW> Their postings will be held for approval, correct. BG> What exactly do we gain from this? BAW> I seem to remember some discussion on this topic a week or so BAW> ago. It seemed to me that the consensus was to quarantine BAW> new list members by default. I might be mistaken (about the BAW> consensus), but it seems like as reasonable a default as not BAW> quarantining them. This is VERY VERY VERY bad, Barry. Just changing the default from underneath admins who upgrade a minor release (heh) from 2.0 to 2.1 will confuse the hell out of everyone. Whenever a new list is created, the admin will have to BY HAND modify it to let new users post; no admin I know is going to want to spend the time to do this, since there's no constant whining reminder to let new users post. Users will sign up, not be able to post, and complain vociferously that Mailman is broken. Please reconsider this behavior, as it's completely different from Mailman's prior behavior -- but let it be enabled for admins who want it that way. Ben -- Brought to you by the letters O and D and the number 4. "Wuzzle means to mix." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Tue Mar 12 07:36:02 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 12 Mar 2002 16:36:02 +0900 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <B8B2E735.1BA77%chuqui@plaidworks.com> (Chuq Von Rospach's message of "Mon, 11 Mar 2002 22:59:01 -0800") References: <B8B2E735.1BA77%chuqui@plaidworks.com> Message-ID: <87wuwick65.fsf@nausicaa.interq.or.jp> >>>>> "Chuq" == Chuq Von Rospach <chuqui@plaidworks.com> writes: BG> What exactly do we gain from this? Chuq> A couple of things. Chuq> First, it stops the "subscribe and spam", which is a growing Chuq> problem. It's not an issue with the big spammers (except on Chuq> major list sites like yahoogroups, where it IS increasingly Chuq> a hassle), but the small guys, especially if you have a list Chuq> that their products target. Yes, but why should this be default? For lists that have problems with "subscribe and spam" spammers, let them turn on this attribute, but confusing all the other admins who suddenly have a ton of new moderated users after they upgrade is not worth it. Chuq> Basically, it gives admins another tool to try to cut the Chuq> noise. Some admins really want this. Some will consider it Chuq> an abomination. It's all in your admin style. I'd want it Chuq> for the first two. I might use the last two tactically on Chuq> SOME lists, or in some circumstances, but not generally. I absolutely agree that we need to give admins this tool. But I disagree vehemently about it being the default; please think about the amount of flaming Mailman will get for increasing the load on list admins silently by tenfold every time a new user joins the list. Ben -- Brought to you by the letters Q and C and the number 4. "More testicles means more iron." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From chuqui@plaidworks.com Tue Mar 12 08:07:51 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 12 Mar 2002 00:07:51 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <87wuwick65.fsf@nausicaa.interq.or.jp> Message-ID: <B8B2F757.1BAA6%chuqui@plaidworks.com> On 3/11/02 11:36 PM, "Ben Gertzfield" <che@debian.org> wrote: > Yes, but why should this be default? I'm not arguing that it should be. I'm actually with you on that. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From chuqui@plaidworks.com Tue Mar 12 08:10:15 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 12 Mar 2002 00:10:15 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <871yeqdyue.fsf@nausicaa.interq.or.jp> Message-ID: <B8B2F7E7.1BAAB%chuqui@plaidworks.com> On 3/11/02 11:33 PM, "Ben Gertzfield" <che@debian.org> wrote: > Just changing the default from underneath admins who upgrade a minor > release (heh) from 2.0 to 2.1 will confuse the hell out of everyone. If that's what you think, you should have been yelling to have this named Mailman 3.0 long ago. I think it's unfair to try to play this at this point in development, over this feature. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From marc_news@vasoftware.com Tue Mar 12 08:49:40 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 12 Mar 2002 00:49:40 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <B8B2F7E7.1BAAB%chuqui@plaidworks.com> References: <871yeqdyue.fsf@nausicaa.interq.or.jp> <B8B2F7E7.1BAAB%chuqui@plaidworks.com> Message-ID: <20020312084940.GJ2972@merlins.org> On Tue, Mar 12, 2002 at 12:10:15AM -0800, Chuq Von Rospach wrote: > On 3/11/02 11:33 PM, "Ben Gertzfield" <che@debian.org> wrote: > > > Just changing the default from underneath admins who upgrade a minor > > release (heh) from 2.0 to 2.1 will confuse the hell out of everyone. > > If that's what you think, you should have been yelling to have this named > Mailman 3.0 long ago. I think it's unfair to try to play this at this point > in development, over this feature. There may yet be another option: What if it defaults to moderate for new installs and non moderate for upgrades? After all, Defaults.py is generated from configure already, so... Marc (who doesn't really care either way on that setting) -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From fil@rezo.net Tue Mar 12 09:18:34 2002 From: fil@rezo.net (Fil) Date: Tue, 12 Mar 2002 10:18:34 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15501.33126.725011.122075@anthem.wooz.org> References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> Message-ID: <20020312091834.GA5891@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > F> I can't find what (I don't know enough about MIME). However I > > I believe this is fixed now in cvs, but it required some changes to > the email package (now embodied in version 1.2). Please do a cvs > update and see if the problem is fixed for you. I could reproduce the > bug in the English version and it looks fixed now. Yes, it's working again. Thank you! However the other bug came back: did you not commit the correction? Traceback (most recent call last): File "/home/mailman/scripts/driver", line 82, in run_main main() File "/home/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/home/mailman/Mailman/Cgi/listinfo.py", line 85, in listinfo_overview mlist = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 102, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 541, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 558, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 148, in Lock self.Load() File "/home/mailman/Mailman/MailList.py", line 541, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 561, in CheckVersion Update(self, stored_state) File "/home/mailman/Mailman/versions.py", line 53, in Update CanonicalizeUserOptions(l) File "/home/mailman/Mailman/versions.py", line 367, in CanonicalizeUserOptions if l.getMemberOption(k, mm_cfg.DisableDelivery): File "/home/mailman/Mailman/OldStyleMemberships.py", line 120, in getMemberOption self.__assertIsMember(member) File "/home/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member -- Fil From fil@rezo.net Tue Mar 12 09:31:12 2002 From: fil@rezo.net (Fil) Date: Tue, 12 Mar 2002 10:31:12 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020312091834.GA5891@rezo.net> References: <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> Message-ID: <20020312093111.GA7691@rezo.net> @ Fil <fil@rezo.net> : > However the other bug came back: did you not commit the correction? > File "/home/mailman/Mailman/OldStyleMemberships.py", line 120, in > getMemberOption > self.__assertIsMember(member) > File "/home/mailman/Mailman/OldStyleMemberships.py", line 113, in > __assertIsMember > raise Errors.NotAMemberError, member In the logs I now have this kind of things re: OldStyleMemberships ==> /home/mailman/logs/error <== Mar 12 10:28:37 2002 (5350) Bouncer exception while processing module DSN: Mar 12 10:28:37 2002 (5350) Traceback (most recent call last): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 77, in ScanMessages mlist.registerBounce(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 107, in registerBounce self.setBounceInfo(member, info) File "/home/mailman/Mailman/OldStyleMemberships.py", line 344, in setBounceInfo assert self.__mlist.Locked() AssertionError -- Fil From mhz@alt-linux.org Tue Mar 12 09:48:21 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Tue, 12 Mar 2002 12:48:21 +0300 Subject: [Mailman-Developers] Russian translation In-Reply-To: <87it8j4ini.fsf@nausicaa.interq.or.jp> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> <87it8j4ini.fsf@nausicaa.interq.or.jp> Message-ID: <20020312094821.GD2183@mhz.mikhail.zabaluev.name> Hello Ben, On Wed, Feb 27, 2002 at 02:07:29PM +0900, Ben Gertzfield wrote: > > >>>>> "Ron" == Ron Jarrell <jarrell@vt.edu> writes: > > Ron> Took me a while to realize it was happening, because, > Ron> screwing around, I selected Russian as my language of choice. > Ron> Which, BTW, displayed everything in English. Does that mean > Ron> I'm missing something in the install? When I switched to > Ron> English for real, I got the *old* web pages... And > Ron> immediately realized what was going on... > > You'll notice that some of the messages, not many, are actually > in Russian. (Like the language pull-down box). > > That means that the Russian translation has been started, but is > missing a lot of translated strings, so Mailman uses the English > defaults for those. Who does the translation? Depending on the message pack size, I could help and/or channel the work to folks over our Russian distro (ALT) posse. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ I live the way I type; fast, with a lot of mistakes. From fil@rezo.net Tue Mar 12 09:44:34 2002 From: fil@rezo.net (Fil) Date: Tue, 12 Mar 2002 10:44:34 +0100 Subject: [Mailman-Developers] Re: BounceRunner eating up alot of memory Message-ID: <20020312094434.GB7691@rezo.net> Barry, you commited the CACHELISTS changes to cvs, with the following comment: "Modified Files: BounceRunner.py OutgoingRunner.py Runner.py Log Message: __init__(): Remove cachelists from the constructor arguments. We can more conveniently use a class attribute to specify this. On the BounceRunner, turn off MailList object caching so that it'll be more friendly to long-term memory use." However the BounceRunner still grows to about 80Mb on my system, after processing bounces from several lists. Maybe this is related to the other error (mentioned below), which prevents your latest corrections from working? The error is : File "/home/mailman/Mailman/OldStyleMemberships.py", line 344, in setBounceInfo assert self.__mlist.Locked() AssertionError >From what I understand the list is not locked any more (thanks to recent corrections), so entering a bounce info breaks the BounceRunner? -- Fil From marc_news@vasoftware.com Tue Mar 12 10:04:35 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 12 Mar 2002 02:04:35 -0800 Subject: [Mailman-Developers] Released: New option for mailman-cvs: reply-to munging per user Message-ID: <20020312020435.O16205@merlins.org> --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 11, 2002 at 01:18:54AM -0800, Marc MERLIN wrote: > Per Barry's recommendation, I wrote this by adding a flag for each user and > duping each list message (munged and non munged version) and sending the > right version to each user. Just in case someone wonders why we went this way versus having a list of munged users like you have a list of digest users, is that it would require to change a lot more code to accomodate a third class of users. > Since this adds some processing, I added an optimization to bypass this code > if no one on the list requests munging. This was the missing piece in my patch yesterday, and implementing it right, and in an efficient way was tricky, but I'm pretty sure I nailed it now, and did it in a way that minimizes scans of the list membership. I think I've tested all the possible cases for this patch, and they worked correctly. I've also been encouraged by the positive feedback from the few people who responded on mailman-users on whether this patch would be useful to them too. If you get the chance, please install this on your mailman-cvs machine (my patch applies cleanly as of right now, can't make promises about tomorrow :D), and let me know if you find something I overlooked. Barry, if you have the time, let me know if you have questions about this or if you spot things that you'd have implemented differently. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="replyto.diff.cvs" diff -urN mailman-cvs/Mailman/Cgi/admin.py mailman-cvs.replyto/Mailman/Cgi/admin.py --- mailman-cvs/Mailman/Cgi/admin.py Tue Mar 12 01:48:43 2002 +++ mailman-cvs.replyto/Mailman/Cgi/admin.py Tue Mar 12 01:50:07 2002 @@ -47,7 +47,7 @@ i18n.set_language(mm_cfg.DEFAULT_SERVER_LANGUAGE) NL = '\n' -OPTCOLUMNS = 11 +OPTCOLUMNS = 12 @@ -869,7 +869,7 @@ _('mod'), _('hide'), _('nomail<br>[reason]'), _('ack'), _('not metoo'), - _('nodupes'), + _('nodupes'), _('replyto'), _('digest'), _('plain'), _('language'))]) rowindex = usertable.GetCurrentRowIndex() @@ -909,7 +909,7 @@ checked = 0 box = CheckBox('%s_mod' % addr, value, checked) cells.append(Center(box).Format()) - for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes'): + for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes', 'replyto'): extra = '' if opt == 'nomail': status = mlist.getDeliveryStatus(addr) @@ -989,6 +989,8 @@ _('''<b>nodupes</b> -- Does the member want to avoid duplicates of the same message?''')) legend.AddItem( + _('''<b>replyto</b> -- Does the member want to have reply-to munged to the list address? (note that it will not be active until per_user_reply_to_allowed is enabled)''')) + legend.AddItem( _('''<b>digest</b> -- Does the member get messages in digests? (otherwise, individual messages)''')) legend.AddItem( @@ -1334,7 +1336,8 @@ mlist.setDeliveryStatus(user, MemberAdaptor.BYADMIN) else: mlist.setDeliveryStatus(user, MemberAdaptor.ENABLED) - for opt in ('hide', 'ack', 'notmetoo', 'nodupes', 'plain'): + for opt in ('hide', 'ack', 'notmetoo', 'nodupes', 'replyto', + 'plain'): opt_code = option_info[opt] if cgidata.has_key('%s_%s' % (user, opt)): mlist.setMemberOption(user, opt_code, 1) diff -urN mailman-cvs/Mailman/Cgi/options.py mailman-cvs.replyto/Mailman/Cgi/options.py --- mailman-cvs/Mailman/Cgi/options.py Mon Mar 11 00:37:06 2002 +++ mailman-cvs.replyto/Mailman/Cgi/options.py Tue Mar 12 01:50:07 2002 @@ -425,6 +425,7 @@ ('remind', mm_cfg.SuppressPasswordReminder), ('rcvtopic', mm_cfg.ReceiveNonmatchingTopics), ('nodupes', mm_cfg.DontReceiveDuplicates), + ('replyto', mm_cfg.AddListReplyTo), ): try: newval = int(cgidata.getvalue(item)) @@ -504,8 +505,7 @@ finally: mlist.Unlock() - # The enable/disable option and the password remind option may have - # their global flags sets. + # Several options support having their global flags sets. global_enable = None if cgidata.getvalue('deliver-globally'): # Yes, this is inefficient, but the list is so small it shouldn't @@ -612,6 +612,18 @@ mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user)) replacements['<mm-receive-duplicates-button>'] = ( mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user)) + # Let's not tempt the user with an option we're not giving him :) + # (yes, this a _very_ sleazy hack, I know :-D) -- Marc + if mlist.per_user_reply_to_allowed: + replacements['<mm-munge-replyto-hide1>'] = ( '' ) + replacements['<mm-munge-replyto-hide2>'] = ( '' ) + else: + replacements['<mm-munge-replyto-hide1>'] = ( '<!---' ) + replacements['<mm-munge-replyto-hide2>'] = ( '--->' ) + replacements['<mm-munge-replyto-button>'] = ( + mlist.FormatOptionButton(mm_cfg.AddListReplyTo, 1, user)) + replacements['<mm-dont-munge-replyto-button>'] = ( + mlist.FormatOptionButton(mm_cfg.AddListReplyTo, 0, user)) replacements['<mm-unsubscribe-button>'] = ( mlist.FormatButton('unsub', _('Unsubscribe')) + '<br>' + CheckBox('unsubconfirm', 1, checked=0).Format() + diff -urN mailman-cvs/Mailman/Defaults.py mailman-cvs.replyto/Mailman/Defaults.py --- mailman-cvs/Mailman/Defaults.py Fri Mar 8 21:09:12 2002 +++ mailman-cvs.replyto/Mailman/Defaults.py Tue Mar 12 01:50:07 2002 @@ -754,6 +754,33 @@ from: .*@uplinkpro.com """ + +# Reply-To munging should really not exist. Each user can tell mailman not +# to send them list copies when people group reply (nodupes feature), but the +# other reason is that some users really insist on not using reply to all, and +# absolutely want to use their reply function to reply to the list. +# If teaching them to use their mail client properly with the aid of a baseball +# bat is not an option, instead of forcing reply-to munging on the whole list +# (DEFAULT_REPLY_GOES_TO_LIST), and screwing all the users who don't want it, +# you can allow a per user reply-to setting. +# As soon as a list member selects this, it will cause each message to be +# duplicated in your spool (one copy with reply-to, and one copy without), and +# it will also force a scan of the list userlist to see which user gets which +# message. You may notice a slowdown on lists with several thousand users. +# List admins will be allowed to turn this on and off on a per list basis, +# but this variable takes precedence over the listmaster(s) setting +# Set to 1 to enable +SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING = 1 + +# Now, you can choose the default value for new lists (should remain '0' unless +# you have to accomodate users who beg for the misfeature, and list server can +# accomodate the additional load) +DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING = 0 + +# You can turn off the various Reply-To munging mistfeatures on a sitewide basis +# here (the above two options should allow everyone to live without them) +SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING = 1 + # Mailman can be configured to "munge" Reply-To: headers for any passing # messages. One the one hand, there are a lot of good reasons not to munge # Reply-To: but on the other, people really seem to want this feature. See @@ -767,7 +794,7 @@ # Before munging Reply-To: Mailman can be configured to strip any existing # Reply-To: header first, or simply extend any existing Reply-To: with one # based on the above setting. This is a boolean variable. -DEFAULT_FIRST_STRIP_REPLY_TO = 1 +DEFAULT_FIRST_STRIP_REPLY_TO = 0 # SUBSCRIBE POLICY # 0 - open list (only when ALLOW_OPEN_SUBSCRIBE is set to 1) ** @@ -1005,6 +1032,7 @@ ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 +AddListReplyTo = 512 # Authentication contexts. # diff -urN mailman-cvs/Mailman/Defaults.py.in mailman-cvs.replyto/Mailman/Defaults.py.in --- mailman-cvs/Mailman/Defaults.py.in Tue Mar 12 01:48:43 2002 +++ mailman-cvs.replyto/Mailman/Defaults.py.in Tue Mar 12 01:50:07 2002 @@ -756,6 +756,33 @@ from: .*@uplinkpro.com """ + +# Reply-To munging should really not exist. Each user can tell mailman not +# to send them list copies when people group reply (nodupes feature), but the +# other reason is that some users really insist on not using reply to all, and +# absolutely want to use their reply function to reply to the list. +# If teaching them to use their mail client properly with the aid of a baseball +# bat is not an option, instead of forcing reply-to munging on the whole list +# (DEFAULT_REPLY_GOES_TO_LIST), and screwing all the users who don't want it, +# you can allow a per user reply-to setting. +# As soon as a list member selects this, it will cause each message to be +# duplicated in your spool (one copy with reply-to, and one copy without), and +# it will also force a scan of the list userlist to see which user gets which +# message. You may notice a slowdown on lists with several thousand users. +# List admins will be allowed to turn this on and off on a per list basis, +# but this variable takes precedence over the listmaster(s) setting +# Set to 1 to enable +SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING = 1 + +# Now, you can choose the default value for new lists (should remain '0' unless +# you have to accomodate users who beg for the misfeature, and list server can +# accomodate the additional load) +DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING = 0 + +# You can turn off the various Reply-To munging mistfeatures on a sitewide basis +# here (the above two options should allow everyone to live without them) +SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING = 1 + # Mailman can be configured to "munge" Reply-To: headers for any passing # messages. One the one hand, there are a lot of good reasons not to munge # Reply-To: but on the other, people really seem to want this feature. See @@ -1014,6 +1041,7 @@ ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 +AddListReplyTo = 512 # Authentication contexts. # diff -urN mailman-cvs/Mailman/Gui/General.py mailman-cvs.replyto/Mailman/Gui/General.py --- mailman-cvs/Mailman/Gui/General.py Mon Mar 11 21:07:00 2002 +++ mailman-cvs.replyto/Mailman/Gui/General.py Tue Mar 12 01:50:07 2002 @@ -58,7 +58,8 @@ optvals = [mlist.new_member_options & bitfields[o] for o in OPTIONS] opttext = [bitdescrs[o] for o in OPTIONS] - rtn = [ + rtn = [ ] + rtn.extend ( ( _('''Fundamental list characteristics, including descriptive info and basic behaviors.'''), @@ -148,9 +149,38 @@ posted to the list, to distinguish mailing list messages in in mailbox summaries. Brevity is premium here, it's ok to shorten long mailing list names to something more concise, as long as it - still identifies the mailing list.""")), + still identifies the mailing list.""")) + ) ) - _('''<tt>Reply-To:</tt> header munging'''), + if (mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING or + mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING ): + rtn.append ( _('''<tt>Reply-To:</tt> header munging''') ) + + + if (mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING ): + rtn.append ( + + ('per_user_reply_to_allowed', mm_cfg.Radio, (_('No'), _('Yes')), 0, + _('''Allow users to individually set a Reply-To to the list?<BR> + Note: this will create additional load, read details.'''), + _("""This option allows individual users to ask the list to + munge posts just for them.<BR> + As soon as a list member selects this, it will cause each message + to be duplicated in your spool (one copy with reply-to, and one + copy without), and it will also force a scan of the list userlist + to see which user gets which message. You may notice a slowdown on + lists with several thousand users and in this case it may be + inadvisable to allow this<BR> + You may also want all your users to learn to use reply to all for + list replies and force this setting off as a result. On the + flipside, it is better to enable this setting and allow a few + users to munge their posts than to turn on reply-to munging for + the whole list and prevent all the users from doing simple replies + to sender""")) + ) + + if (mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING ): + rtn.extend ( ( ('first_strip_reply_to', mm_cfg.Radio, (_('No'), _('Yes')), 0, _('''Should any existing <tt>Reply-To:</tt> header found in the @@ -227,7 +257,9 @@ <p>Note that if the original message contains a <tt>Reply-To:</tt> header, it will not be changed.""")), + ) ) + rtn.extend ( ( _('Umbrella list settings'), ('umbrella_list', mm_cfg.Radio, (_('No'), _('Yes')), 0, @@ -352,8 +384,7 @@ the mail host's exchanger address, if any. This setting can be useful for selecting among alternative names of a host that has multiple addresses.""")), - - ] + ) ) if mm_cfg.ALLOW_RFC2369_OVERRIDES: rtn.append( diff -urN mailman-cvs/Mailman/HTMLFormatter.py mailman-cvs.replyto/Mailman/HTMLFormatter.py --- mailman-cvs/Mailman/HTMLFormatter.py Tue Mar 5 22:24:46 2002 +++ mailman-cvs.replyto/Mailman/HTMLFormatter.py Tue Mar 12 01:50:07 2002 @@ -117,6 +117,7 @@ mm_cfg.SuppressPasswordReminder : 'remind', mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic', mm_cfg.DontReceiveDuplicates : 'nodupes', + mm_cfg.AddListReplyTo : 'replyto', }[option] return '<input type=radio name="%s" value="%d"%s>' % ( name, value, checked) diff -urN mailman-cvs/Mailman/Handlers/CookHeaders.py mailman-cvs.replyto/Mailman/Handlers/CookHeaders.py --- mailman-cvs/Mailman/Handlers/CookHeaders.py Mon Mar 11 21:07:00 2002 +++ mailman-cvs.replyto/Mailman/Handlers/CookHeaders.py Tue Mar 12 01:50:07 2002 @@ -87,7 +87,10 @@ # augment it. RFC 2822 allows max one Reply-To: header so collapse them # if we're adding a value, otherwise don't touch it. (Should we collapse # in all cases?) - if not fasttrack: + # Turning off Reply-To munging on a sitewide basis doesn't reset the list + # option (it just makes it go away from the interface), so we need to + # disable the behavior here -- Marc + if not fasttrack and mm_cfg.SITEWIDE_ALLOW_PER_LIST_REPLY_TO_MUNGING: # Set Reply-To: header to point back to this list replyto = [] if mlist.reply_goes_to_list == 1: diff -urN mailman-cvs/Mailman/Handlers/SMTPDirect.py mailman-cvs.replyto/Mailman/Handlers/SMTPDirect.py --- mailman-cvs/Mailman/Handlers/SMTPDirect.py Mon Mar 11 00:37:23 2002 +++ mailman-cvs.replyto/Mailman/Handlers/SMTPDirect.py Tue Mar 12 01:50:07 2002 @@ -81,6 +81,23 @@ if not recips: # Nobody to deliver to! return + + # If the list has a reply-to/non reply-to split, the message gets queued + # twice, once with a Reply-To and once without. We need to weed out the + # members that don't match the current post configuration + # Let's only do this if we have to, if it's currently allowed by the list + # owner, and if it's allowed sitewide -- Marc + if mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING and \ + mlist.per_user_reply_to_allowed and mlist.mixed_reply_to_munged_users: + mungedpost=msgdata.get('replytoadded') + for r in recips[:]: + if (mungedpost and \ + not mlist.getMemberOption(r, mm_cfg.AddListReplyTo)) \ + or \ + (not mungedpost and \ + mlist.getMemberOption(r, mm_cfg.AddListReplyTo)): + recips.remove(r) + # Calculate the non-VERP envelope sender. if mlist: envsender = mlist.getListAddress('bounces') diff -urN mailman-cvs/Mailman/Handlers/ToOutgoing.py mailman-cvs.replyto/Mailman/Handlers/ToOutgoing.py --- mailman-cvs/Mailman/Handlers/ToOutgoing.py Sat Mar 9 19:25:01 2002 +++ mailman-cvs.replyto/Mailman/Handlers/ToOutgoing.py Tue Mar 12 01:50:07 2002 @@ -24,6 +24,7 @@ from Mailman import mm_cfg from Mailman.Queue.sbcache import get_switchboard +COMMASPACE = ', ' def process(mlist, msg, msgdata): @@ -45,6 +46,29 @@ else: # VERP every `inteval' number of times msgdata['verp'] = not int(mlist.post_id) % interval + # And now drop the message in qfiles/out outq = get_switchboard(mm_cfg.OUTQUEUE_DIR) - outq.enqueue(msg, msgdata, listname=mlist.internal_name()) + msgdata['replytoadded']=0 + if (not mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING or + not mlist.per_user_reply_to_allowed or + not mlist.all_reply_to_munged_users): + outq.enqueue(msg, msgdata, listname=mlist.internal_name()) + + if (mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING and + mlist.per_user_reply_to_allowed and + (mlist.mixed_reply_to_munged_users or + mlist.all_reply_to_munged_users) ): + msgdata['replytoadded']=1 + # RFC 2822 allows Reply-To to be a list of addresses. Should a mail + # client not be happy with that, the user then has the option of not + # doing header munging in the first place and learning how to use the + # proper reply function of his mailer :-) -- Marc + replyto = [] + replyto.append(mlist.GetListEmail()) + if msg['reply-to']: + replyto.append(msg['reply-to']) + del msg['reply-to'] + msg['Reply-To']=COMMASPACE.join(replyto) + + outq.enqueue(msg, msgdata, listname=mlist.internal_name()) diff -urN mailman-cvs/Mailman/MailCommandHandler.py mailman-cvs.replyto/Mailman/MailCommandHandler.py --- mailman-cvs/Mailman/MailCommandHandler.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.replyto/Mailman/MailCommandHandler.py Tue Mar 12 01:50:07 2002 @@ -84,6 +84,24 @@ which have you as an explicit recipient (i.e. if you're both a member of the list and in either the To: or Cc: headers).""") +REPLYTO = _(""" +While there are few good reasons to do this, you can ask to have list posts +contain a reply-to pointing back to the list. It's mainly here if you really +can't break the habit to use the reply to sender function of your mail client +to reply to list posts. You should use the reply to all/reply to list function +of your mail client to answer list posts (mailman is smart enough not to send +duplicates if you reply to the list and the poster), and you can use your normal +reply to sender function to reply just to the original post author. + +If this option is allowed by the list and the site owners, turning it on will +cause list posts to contain a Reply-To: header pointing back to the list so that +you can answer list posts with the reply function of your mail client. +Please make note that you will then be unable to reply to the author of a +message without typing his Email address and that many lists will not allow you +to have a Reply-To the list, so you may be better off not changing the meaning +of the reply function and getting used to using reply to all for lists posts +""") + option_desc = {'hide' : HIDE, 'nomail' : NOMAIL, 'ack' : ACK, @@ -91,6 +109,7 @@ 'digest' : DIGEST, 'plain' : PLAIN, 'nodupes' : NODUPES, + 'replyto' : REPLYTO, } # jcrey: and then the real one @@ -102,11 +121,20 @@ 'notmetoo': mm_cfg.DontReceiveOwnPosts, 'digest' : 0, 'plain' : mm_cfg.DisableMime, - 'nodupes' : mm_cfg.DontReceiveDuplicates + 'nodupes' : mm_cfg.DontReceiveDuplicates, + 'replyto' : mm_cfg.AddListReplyTo, } # ordered list -options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes') +options = ['hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes'] + +# We don't know which list the user may be on or is trying to get on, so +# we can't check for mlist.per_user_reply_to_allowed, but we can definitely +# check for mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING +# The idea is not to potentially tempt the user with a feature that may not +# be available :) -- Marc +if mm_cfg.SITEWIDE_ALLOW_PER_USER_REPLYTO_MUNGING: + options.append('replyto') # strip just the outer layer of quotes quotecre = re.compile(r'["\'`](?P<cmd>.*)["\'`]') diff -urN mailman-cvs/Mailman/MailList.py mailman-cvs.replyto/Mailman/MailList.py --- mailman-cvs/Mailman/MailList.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.replyto/Mailman/MailList.py Tue Mar 12 01:50:07 2002 @@ -259,6 +259,16 @@ self.usernames = {} self.passwords = {} self.new_member_options = mm_cfg.DEFAULT_NEW_MEMBER_OPTIONS + # if you have a least one user who wants personalized munging, each + # message gets dropped twice in the queue, once munged, once not. + # Because this requires resources, and scanning the userlist to see + # who gets each message requires resources too, we don't do this unless + # we have to (we keep track of whether we have mixed users on the list) + # -- Marc + self.mixed_reply_to_munged_users = 0 + # Actually if all users are munged, then we go back to only dropping + # one copy of the mail in the spool (after munging) + self.all_reply_to_munged_users = 0 # This stuff is configurable self.respond_to_post_requests = 1 @@ -270,6 +280,8 @@ % mm_cfg.DEFAULT_URL_HOST self.owner = [admin] self.moderator = [] + self.per_user_reply_to_allowed = \ + mm_cfg.DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.reply_to_address = '' self.first_strip_reply_to = mm_cfg.DEFAULT_FIRST_STRIP_REPLY_TO diff -urN mailman-cvs/Mailman/OldStyleMemberships.py mailman-cvs.replyto/Mailman/OldStyleMemberships.py --- mailman-cvs/Mailman/OldStyleMemberships.py Tue Mar 5 22:24:48 2002 +++ mailman-cvs.replyto/Mailman/OldStyleMemberships.py Tue Mar 12 01:50:07 2002 @@ -264,6 +264,14 @@ assert self.__mlist.Locked() self.__assertIsMember(member) memberkey = member.lower() + + # To avoid unnecessary list rescans, let's see if the replyto or + # the digest status changed -- Marc + isregular=self.__mlist.members.has_key(memberkey) + isdigest=self.__mlist.digest_members.has_key(memberkey) + isreplyto=( self.__mlist.user_options[memberkey] & + mm_cfg.AddListReplyTo ) + # There's one extra gotcha we have to deal with. If the user is # toggling the Digests flag, then we need to move their entry from # mlist.members to mlist.digest_members or vice versa. Blarg. Do @@ -297,21 +305,50 @@ # things up so that the user receives one last digest, # otherwise they may lose some email self.__mlist.one_last_digest[memberkey] = cpuser - # We don't need to touch user_options because the digest state - # isn't kept as a bitfield flag. - return - # This is a bit kludgey because the semantics are that if the user has - # no options set (i.e. the value would be 0), then they have no entry - # in the user_options dict. We use setdefault() here, and then del - # the entry below just to make things (questionably) cleaner. - self.__mlist.user_options.setdefault(memberkey, 0) - if value: - self.__mlist.user_options[memberkey] |= flag - else: - self.__mlist.user_options[memberkey] &= ~flag - if not self.__mlist.user_options[memberkey]: - del self.__mlist.user_options[memberkey] + if flag != mm_cfg.Digests: + # This is a bit kludgey because the semantics are that if the + # user has no options set (i.e. the value would be 0), then they + # have no entry in the user_options dict. We use setdefault() + # here, and then del the entry below just to make things + # (questionably) cleaner. + self.__mlist.user_options.setdefault(memberkey, 0) + if value: + self.__mlist.user_options[memberkey] |= flag + else: + self.__mlist.user_options[memberkey] &= ~flag + if not self.__mlist.user_options[memberkey]: + del self.__mlist.user_options[memberkey] + + # We need to do special processing on reply-to in case the switch + # causes the first munging user to appear or the last to go away + # In order to make the code simpler, we're only going to count + # who has the replyto flag set, even if they are disabled. + # We might do split processing in a few cases where it's not needed, + # but in return, we don't have to trigger a membership scan every + # time a member's delivery status is changed. + # Let's only do a rescan if the replyto or digest status changed -- Marc + if ( isregular != self.__mlist.members.has_key(memberkey) or + isdigest != self.__mlist.digest_members.has_key(memberkey) or + isreplyto != ( self.__mlist.user_options[memberkey] & + mm_cfg.AddListReplyTo ) ) : + nomunge=0 + munge=0 + self.__mlist.mixed_reply_to_munged_users=0 + self.__mlist.all_reply_to_munged_users=0 + for member in self.__mlist.members.keys(): + if self.__mlist.user_options[member] & mm_cfg.AddListReplyTo: + munge=1 + else: + nomunge=1 + if munge and nomunge: + self.__mlist.mixed_reply_to_munged_users=1 + break + + if (nomunge == 0) and (munge == 1): + self.__mlist.all_reply_to_munged_users=1 + + def setMemberName(self, member, realname): assert self.__mlist.Locked() self.__assertIsMember(member) diff -urN mailman-cvs/Mailman/Version.py mailman-cvs.replyto/Mailman/Version.py --- mailman-cvs/Mailman/Version.py Tue Mar 12 01:48:43 2002 +++ mailman-cvs.replyto/Mailman/Version.py Tue Mar 12 01:50:07 2002 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.1a4+" +VERSION = "2.1a4+-replyto" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.pck schema version number -DATA_FILE_VERSION = 66 +DATA_FILE_VERSION = 67 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 3 diff -urN mailman-cvs/Mailman/versions.py mailman-cvs.replyto/Mailman/versions.py --- mailman-cvs/Mailman/versions.py Tue Mar 12 01:48:43 2002 +++ mailman-cvs.replyto/Mailman/versions.py Tue Mar 12 01:50:07 2002 @@ -322,6 +322,10 @@ add_only_if_missing('member_moderation_notice', '') add_only_if_missing('new_member_options', mm_cfg.DEFAULT_NEW_MEMBER_OPTIONS) + add_only_if_missing('mixed_reply_to_munged_users', 0) + add_only_if_missing('all_reply_to_munged_users', 0) + add_only_if_missing('per_user_reply_to_allowed', \ + mm_cfg.DEFAULT_ALLOW_PER_USER_REPLYTO_MUNGING) diff -urN mailman-cvs/templates/en/help.txt mailman-cvs.replyto/templates/en/help.txt --- mailman-cvs/templates/en/help.txt Tue Mar 5 22:24:56 2002 +++ mailman-cvs.replyto/templates/en/help.txt Tue Mar 12 01:50:07 2002 @@ -85,6 +85,20 @@ Cc: fields already or are included in multiple lists in one message. + replyto: + There are few good reasons to do this. It's mainly here if you + really can't break the habit to use the reply to sender function of + your mail client to reply to list posts. You should use the reply + to all/reply to list function of your mail client (mailman is smart + enough not to send duplicates if you reply to the list and the + poster) to answer list posts, and reply to sender should be to + reply just to the original post author. + When turned on however (if allowed by the list and the site owners), + you can ask to have list posts contain a reply-to pointing back to + the list so that you can answer list posts with the reply function + of your mail client. + Please make note that this is a bad habit and that many lists will + not allow you to reply to the list without replying to all options Show the current values of your list options. diff -urN mailman-cvs/templates/en/options.html mailman-cvs.replyto/templates/en/options.html --- mailman-cvs/templates/en/options.html Tue Mar 5 22:24:56 2002 +++ mailman-cvs.replyto/templates/en/options.html Tue Mar 12 01:50:07 2002 @@ -300,6 +300,36 @@ <mm-global-nodupes-button><i>Set globally</i> </td></tr> + <mm-munge-replyto-hide1> + <tr><td bgcolor="#cccccc"> + <strong>Set Reply-To back to the list?</strong><p> + + There are few good reasons to do this. It's mainly here if + you really can't break the habit to use the reply to sender + function of your mail client to reply to list posts. You + should use the reply to all/reply to list function of your + mail client to answer list posts (mailman is smart enough not to + send duplicates if you reply to the list and the poster), and + you can use your normal reply to sender function to reply just + to the original post author.<P> + + If this option is allowed by the list and the site + owners, turning it on will cause list posts to contain a + <tt>Reply-To:</tt> header pointing back to the list so that + you can answer list posts with the reply function of your mail + client.<BR> + Please make note that you will then be unable to reply to the + author of a message without typing his Email address and that + many lists will not allow you to have a Reply-To the list, so + you may be better off not changing the meaning of the reply + function and getting used to using reply to all for lists posts + + </td><td bgcolor="#cccccc"> + <mm-dont-munge-replyto-button>No + <mm-munge-replyto-button>Yes + </td></tr> + <mm-munge-replyto-hide2> + <tr><TD colspan="2"> <center><MM-options-Submit-button></center> </td></tr> --w7PDEPdKQumQfZlR-- From mhz@alt-linux.org Tue Mar 12 10:55:05 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Tue, 12 Mar 2002 13:55:05 +0300 Subject: [Mailman-Developers] Stripping HTML In-Reply-To: <3C870980.76E9B2D@cascade-sys.com> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> <3C870980.76E9B2D@cascade-sys.com> Message-ID: <20020312105505.GH2183@mhz.mikhail.zabaluev.name> Hello James, On Wed, Mar 06, 2002 at 10:32:32PM -0800, James J. Besemer wrote: > > Like Les said, simply removing all the formatting and leaving the original > text would make almost everybody happy. In my tiny corner of the world, > 98% of the cases are where a naive user entered some regular text, only it > got posted as HTML, so it shows up as purple 6 point text or some crap. > > After a quick review of my HTML pocket ref, I'd say for extra credit I > would handle the following cases specially: > > <A> -- echo the HREF > > <IMG> -- echo the ALT text > > <P> -- extra blank line > > And that would about cover it. The PhD version would format tables. Sorry to ruin your PhD, but will the "lynx -dump -assume-charset='$charset_from_header'" command serve fine? I happily use it to display HTML in the Mutt pager pane. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ To be trusted is a greater compliment than to be loved. From mhz@alt-linux.org Tue Mar 12 11:39:24 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Tue, 12 Mar 2002 14:39:24 +0300 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <15494.64729.535773.898549@anthem.wooz.org> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> Message-ID: <20020312113924.GI2183@mhz.mikhail.zabaluev.name> Hello Barry, Here's my RUR .02: On Thu, Mar 07, 2002 at 12:38:33AM -0500, Barry A. Warsaw wrote: > > Ben> This would violate RFC 1522: > > SJT> That's right. People with broken mailers have broken > SJT> mailers. Make sure that things are robust for those with > SJT> decent software, and then do what we can for the former poor > SJT> souls. > > Totally agreed. I mean, look at me, a "dinosaur" who uses a > MIME-aware MUA in a system that was never originally designed to > support the stuff you get in email these days. And it's mostly bug > free <wink>. (Aside to Stephen: do you know if Kyle still handles VM > bug reports these days? ;). > > The only hope we have of interoperating is to support the standards, > or at least not willfully break them <Hippocratic oath wink>. Which > means if the charsets don't match, we can't simply tack on headers and > footers. This steps on my pet peeve with Mailman: Does this matching regard Content-Transfer-Encoding as well? Tacking on text strings to a base64 text/plain body is a recipe for disaster, and such things happen, believe it or not. > So we either don't add them or we add some multipart/mixed > chrome and do it in a MIME-compliant way. Continuing the Hippocratic theme, I'd suggest a rule: don't meddle if it could hamper someone's reading capabilities. In this case, don't make multipart/mixed embellishments unless it IS multipart/mixed already. All other conversions would break some client's subtle neck or make things look uglier. God forbid messing with multipart/alternative or multipart/signed. It's only bulk informational add-ons, why shove it down everyone's throat? For the same reason, I would object things like recoding to and fro base64 to modify content. Above all, that would put an unnecessary load on the mail processor. > I really don't want to think about PGP right now. Mailcrypt w/GnuPG > seems to only sign or encrypt the body, and in a non-MIME way, so if > we wanted to add headers and footers it seems like we'd be safe by > wrapping the original body in multipart/mixed chrome. Of course you'd > have to unpack the parts to verify (read) the signed (encrypted) > part. Oh well, there's not really much more you /can/ do. I second the opinion that for the MUAs that use "magic" PGP tags in plain/text bodies, it would be safe to add text above and below. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ In the misfortune of our friends we find something that is not displeasing to us. -- La Rochefoucauld, "Maxims" From jarrell@vt.edu Tue Mar 12 12:14:41 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 12 Mar 2002 07:14:41 -0500 (EST) Subject: [Mailman-Developers] check_perms Message-ID: <200203121214.g2CCEf214998@babylon5.cc.vt.edu> Having just had the opportunity to run check_perms again (because one of my newly created lists failed to inhereit the right group. When the one before and after it did. I love computers sometimes), I noticed one picky little detail. If you run it without the -f, and it finds errors, it tells you to run it -f to fix them. That's fine. If you *do* run it -f, and it finds, and fixes, errors, it *still* tells you to rerun it -f to fix the errors... It probably shouldn't confuse people that way... From barry@wooz.org Tue Mar 12 14:16:52 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 12 Mar 2002 09:16:52 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> <15501.40707.412796.594457@anthem.wooz.org> <871yeqdyue.fsf@nausicaa.interq.or.jp> Message-ID: <15502.3540.289539.846916@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: >>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes: BAW> I seem to remember some discussion on this topic a week or so BAW> ago. It seemed to me that the consensus was to quarantine BAW> new list members by default. I might be mistaken (about the BAW> consensus), but it seems like as reasonable a default as not BAW> quarantining them. BG> This is VERY VERY VERY bad, Barry. BG> Just changing the default from underneath admins who upgrade a BG> minor release (heh) from 2.0 to 2.1 will confuse the hell out BG> of everyone. BG> Whenever a new list is created, the admin will have to BY HAND BG> modify it to let new users post; no admin I know is going to BG> want to spend the time to do this, since there's no constant BG> whining reminder to let new users post. Users will sign up, BG> not be able to post, and complain vociferously that Mailman is BG> broken. BG> Please reconsider this behavior, as it's completely different BG> from Mailman's prior behavior -- but let it be enabled for BG> admins who want it that way. Are we talking about new lists or upgraded lists? Certainly for upgraded lists, member moderation flags will only be turned on if the old list was moderated. So upgrading an existing list to 2.1 won't change its behavior. That indeed would be bad. For new lists, the default moderation bit value for new members is set by default_member_moderation, which itself takes its value from mm_cfg.DEFAULT_DEFAULT_MEMBER_MODERATION. This latter is set to 1 in Defaults.py. I think there's a high degree of latitude here for sites and lists to define their default behavior. In addition, in the admindb pages, when you dispose of a posting by a member, you are given the choice to clear that member's moderation flag. I think the process couldn't be easier. Is this enough? If not, just to be clear: are you arguing that DEFAULT_DEFAULT_MEMBER_MODERATION should be factory set to 0? Here's another idea/compromise: in the screen where you create new lists through the web, I could easily add another binary toggle, like "Should your new list quarantine new members?" which would set the default value for default_member_moderation. -Barry From barry@wooz.org Tue Mar 12 14:20:14 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 12 Mar 2002 09:20:14 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <871yeqdyue.fsf@nausicaa.interq.or.jp> <B8B2F7E7.1BAAB%chuqui@plaidworks.com> <20020312084940.GJ2972@merlins.org> Message-ID: <15502.3742.859045.550877@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> There may yet be another option: What if it defaults to MM> moderate for new installs and non moderate for upgrades? MM> After all, Defaults.py is generated from configure already, MM> so... Yes, let's not confuse upgraded lists with new lists. Specifically, if an upgraded list had the `moderated' value set to true, all members will get their moderate flag turned on (since `moderated' goes away in MM2.1, this is the only way to migrate the list's behavior). If the upgraded list had the `moderated' value set to false, members will not get their moderate flag turned on. I /think/ (hope ;) we're simply arguing about the default value for the moderate flag for new members to newly created (i.e. only existed under MM2.1) lists. -Barry From mss@mawhrin.net Tue Mar 12 15:01:52 2002 From: mss@mawhrin.net (Mikhail Sobolev) Date: Tue, 12 Mar 2002 15:01:52 +0000 Subject: [Mailman-Developers] Russian translation In-Reply-To: <20020312094821.GD2183@mhz.mikhail.zabaluev.name> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> <87it8j4ini.fsf@nausicaa.interq.or.jp> <20020312094821.GD2183@mhz.mikhail.zabaluev.name> Message-ID: <20020312150152.GA2396@mawhrin.net> I believe, mailman-i18n is a better forum for this question. :)) I'd say it's me who try to translate the mailman messages to Russian with help of others... I created a list mailman-ru@only.mawhrin.net, it's pretty quiet at the moment, but it's there for discussing the translation... -- Misha I seem to i the translation effor On Tue, Mar 12, 2002 at 12:48:21PM +0300, Mikhail Zabaluev wrote: > Hello Ben, > > On Wed, Feb 27, 2002 at 02:07:29PM +0900, Ben Gertzfield wrote: > > > > >>>>> "Ron" == Ron Jarrell <jarrell@vt.edu> writes: > > > > Ron> Took me a while to realize it was happening, because, > > Ron> screwing around, I selected Russian as my language of choice. > > Ron> Which, BTW, displayed everything in English. Does that mean > > Ron> I'm missing something in the install? When I switched to > > Ron> English for real, I got the *old* web pages... And > > Ron> immediately realized what was going on... > > > > You'll notice that some of the messages, not many, are actually > > in Russian. (Like the language pull-down box). > > > > That means that the Russian translation has been started, but is > > missing a lot of translated strings, so Mailman uses the English > > defaults for those. > > Who does the translation? Depending on the message pack size, I could > help and/or channel the work to folks over our Russian distro (ALT) > posse. > > -- > Stay tuned, > MhZ JID: mookid@jabber.org > ___________ > I live the way I type; fast, with a lot of mistakes. From marc_news@vasoftware.com Tue Mar 12 16:52:56 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 12 Mar 2002 08:52:56 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15502.3742.859045.550877@anthem.wooz.org> References: <871yeqdyue.fsf@nausicaa.interq.or.jp> <B8B2F7E7.1BAAB%chuqui@plaidworks.com> <20020312084940.GJ2972@merlins.org> <15502.3742.859045.550877@anthem.wooz.org> Message-ID: <20020312165256.GL2972@merlins.org> On Tue, Mar 12, 2002 at 09:20:14AM -0500, Barry A. Warsaw wrote: > Yes, let's not confuse upgraded lists with new lists. Specifically, > if an upgraded list had the `moderated' value set to true, all members > will get their moderate flag turned on (since `moderated' goes away in > MM2.1, this is the only way to migrate the list's behavior). If the > upgraded list had the `moderated' value set to false, members will not > get their moderate flag turned on. > > I /think/ (hope ;) we're simply arguing about the default value for > the moderate flag for new members to newly created (i.e. only existed > under MM2.1) lists. Again, I do not overly care what it gets set to, it's a default, and I can change it either way, but I was actually saying that the value in Defaults.py could be set to 0 if you are upgrading a mailman install, and it could be 1 otherwise. What this means is that when Ben upgrades his installs, the value in Defaults.py would be 0, whereas it would be 1 for new mailman installs. Just a possible suggestion. Feel free to ignore me :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Tue Mar 12 17:54:57 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 12 Mar 2002 09:54:57 -0800 Subject: [Mailman-Developers] Re: Released: New option for mailman-cvs: reply-to munging per user In-Reply-To: <20020312020435.O16205@merlins.org>; from marc_news@vasoftware.com on Tue, Mar 12, 2002 at 02:04:35AM -0800 References: <20020312020435.O16205@merlins.org> Message-ID: <20020312095457.Q16205@merlins.org> --veXX9dWIonWZEC6h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 12, 2002 at 02:04:35AM -0800, Marc MERLIN wrote: > > Since this adds some processing, I added an optimization to bypass this code > > if no one on the list requests munging. > > This was the missing piece in my patch yesterday, and implementing it right, > and in an efficient way was tricky, but I'm pretty sure I nailed it now, and > did it in a way that minimizes scans of the list membership. Well, actually I found a bug under my pillow last night (bad bug, no cookie): I did forget about other functions that can change member options or the balance between munged and non munged users (add, delete, and rename users) This small patch applies on top of the other one and takes care of that. You can also find the full patch here: http://marc.merlins.org/tmp/replyto.diff.cvs Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key --veXX9dWIonWZEC6h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="replyto.diff.cvs2" diff -urN mailman-cvs.replyto/Mailman/OldStyleMemberships.py mailman-cvs.replyto.newusers/Mailman/OldStyleMemberships.py --- mailman-cvs.replyto/Mailman/OldStyleMemberships.py Tue Mar 12 01:50:07 2002 +++ mailman-cvs.replyto.newusers/Mailman/OldStyleMemberships.py Tue Mar 12 09:41:29 2002 @@ -45,6 +45,31 @@ class OldStyleMemberships(MemberAdaptor.MemberAdaptor): def __init__(self, mlist): self.__mlist = mlist + + # We need to call this (I think only internally) when the membership + # list is changed in a way that can cause the first or last munged user + # to appear or go away. + # In other words, anything that writes user_options or adds/removes a + # user -- Marc + def __regenmungedflags(self): + nomunge=0 + munge=0 + self.__mlist.mixed_reply_to_munged_users=0 + self.__mlist.all_reply_to_munged_users=0 + for member in self.__mlist.members.keys(): + if (self.__mlist.user_options.has_key(member) and + self.__mlist.user_options[member] & mm_cfg.AddListReplyTo): + munge=1 + else: + nomunge=1 + if munge and nomunge: + self.__mlist.mixed_reply_to_munged_users=1 + break + + if (nomunge == 0) and (munge == 1): + self.__mlist.all_reply_to_munged_users=1 + + # # Read interface @@ -211,6 +236,7 @@ # Set the member's default set of options if self.__mlist.new_member_options: self.__mlist.user_options[member] = self.__mlist.new_member_options + self.__regenmungedflags() def removeMember(self, member): assert self.__mlist.Locked() @@ -226,6 +252,7 @@ dict = getattr(self.__mlist, attr) if dict.has_key(memberkey): del dict[memberkey] + self.__regenmungedflags() def changeMemberAddress(self, member, newaddress, nodelete=0): assert self.__mlist.Locked() @@ -249,6 +276,7 @@ # Delete the old memberkey if not nodelete: self.removeMember(memberkey) + self.__regenmungedflags() def setMemberPassword(self, memberkey, password): assert self.__mlist.Locked() @@ -330,25 +358,10 @@ # Let's only do a rescan if the replyto or digest status changed -- Marc if ( isregular != self.__mlist.members.has_key(memberkey) or isdigest != self.__mlist.digest_members.has_key(memberkey) or - isreplyto != ( self.__mlist.user_options[memberkey] & + isreplyto != ( self.__mlist.user_options[memberkey] & mm_cfg.AddListReplyTo ) ) : - nomunge=0 - munge=0 - self.__mlist.mixed_reply_to_munged_users=0 - self.__mlist.all_reply_to_munged_users=0 - for member in self.__mlist.members.keys(): - if self.__mlist.user_options[member] & mm_cfg.AddListReplyTo: - munge=1 - else: - nomunge=1 - if munge and nomunge: - self.__mlist.mixed_reply_to_munged_users=1 - break + self.__regenmungedflags() - if (nomunge == 0) and (munge == 1): - self.__mlist.all_reply_to_munged_users=1 - - def setMemberName(self, member, realname): assert self.__mlist.Locked() self.__assertIsMember(member) --veXX9dWIonWZEC6h-- From barry@zope.com Tue Mar 12 19:28:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 14:28:08 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> <15501.40707.412796.594457@anthem.wooz.org> <871yeqdyue.fsf@nausicaa.interq.or.jp> <15502.3540.289539.846916@anthem.wooz.org> Message-ID: <15502.22216.344495.123786@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes: BAW> Here's another idea/compromise: in the screen where you BAW> create new lists through the web, I could easily add another BAW> binary toggle, like "Should your new list quarantine new BAW> members?" which would set the default value for BAW> default_member_moderation. This is in cvs now. Hopefully this will put the issue to bed. -Barry From barry@zope.com Tue Mar 12 19:33:36 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 14:33:36 -0500 Subject: [Mailman-i18n] Re: [Mailman-Developers] Russian translation References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> <87it8j4ini.fsf@nausicaa.interq.or.jp> <20020312094821.GD2183@mhz.mikhail.zabaluev.name> <20020312150152.GA2396@mawhrin.net> Message-ID: <15502.22544.26401.709272@anthem.wooz.org> >>>>> "MS" == Mikhail Sobolev <mss@mawhrin.net> writes: MS> I believe, mailman-i18n is a better forum for this MS> question. :)) MS> I'd say it's me who try to translate the mailman messages to MS> Russian with help of others... MS> I created a list mailman-ru@only.mawhrin.net, it's pretty MS> quiet at the moment, but it's there for discussing the MS> translation... I've added this mailing list to the i18n page. -Barry From barry@zope.com Tue Mar 12 19:35:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 14:35:03 -0500 Subject: [Mailman-Developers] check_perms References: <200203121214.g2CCEf214998@babylon5.cc.vt.edu> Message-ID: <15502.22631.639169.853249@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> Having just had the opportunity to run check_perms again RJ> (because one of my newly created lists failed to inhereit the RJ> right group. When the one before and after it did. I love RJ> computers sometimes), I noticed one picky little detail. If RJ> you run it without the -f, and it finds errors, it tells you RJ> to run it -f to fix them. That's fine. If you *do* run it RJ> -f, and it finds, and fixes, errors, it *still* tells you to RJ> rerun it -f to fix the errors... You actually do want to run it twice, or at least until no more errors are reported. -Barry From chuqui@plaidworks.com Tue Mar 12 19:36:11 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 12 Mar 2002 11:36:11 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15502.22216.344495.123786@anthem.wooz.org> Message-ID: <B8B398AB.1BDEA%chuqui@plaidworks.com> On 3/12/02 11:28 AM, "Barry A. Warsaw" <barry@zope.com> wrote: > This is in cvs now. Hopefully this will put the issue to bed. If not, try some warm milk and a couple of Oreos. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From barry@zope.com Tue Mar 12 19:48:36 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 14:48:36 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <15502.22216.344495.123786@anthem.wooz.org> <B8B398AB.1BDEA%chuqui@plaidworks.com> Message-ID: <15502.23444.746931.395277@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: >> This is in cvs now. Hopefully this will put the issue to bed. CVR> If not, try some warm milk and a couple of Oreos. I'm lactose intolerant so I'll settle for a 2 liter bottle of decaffeinated Mountain Dew and a box of Blueberry Newtons. sleeping-like-a-baby-ly y'rs, -Barry From chuqui@plaidworks.com Tue Mar 12 19:53:21 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 12 Mar 2002 11:53:21 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15502.23444.746931.395277@anthem.wooz.org> Message-ID: <B8B39CB1.1BE0C%chuqui@plaidworks.com> On 3/12/02 11:48 AM, "Barry A. Warsaw" <barry@zope.com> wrote: > I'm lactose intolerant so I'll settle for a 2 liter bottle of > decaffeinated Mountain Dew and a box of Blueberry Newtons. Oh, man. I feel ill. Although yesterday, after being up until 1:30AM working on a server upgrade, being up at 7AM to finish it -- I rolled into work about 11:15 with a "Monday morning brunch": Starbucks and a Togos. Which, if you don't know Togos, is Subway with taste. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From jarrell@vt.edu Tue Mar 12 20:04:28 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 12 Mar 2002 15:04:28 -0500 Subject: [Mailman-Developers] moderation... Message-ID: <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> You know, it just occured to me, that under the new model, I can't figure out how to let my list admins do something they used to be able to do... I have a list that's normally unmoderated, posting by subscriber only. Every now and then things get too heated, and the list owner steps in and flips the moderate switch until people play nice again. Under the new rules, to do that, the only way I see for him to do that is to go in and click "moderate" next to each of 300 names... Or he has to call me and I try to whip up a little python proc to run under withlist to flip everyone's bits... Did I miss something? (Yes, I followed the discussions, but this particular regular even just didn't register at the time...) From barry@zope.com Tue Mar 12 20:22:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 15:22:23 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman References: <15502.23444.746931.395277@anthem.wooz.org> <B8B39CB1.1BE0C%chuqui@plaidworks.com> Message-ID: <15502.25471.138390.178264@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: CVR> Which, if you don't know Togos, is Subway with taste. Subway has taste, but its taste is paste. Blug. I'm glad I've eaten today already. -B From barry@zope.com Tue Mar 12 20:29:51 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 15:29:51 -0500 Subject: [Mailman-Developers] Missing footers with latest CVS References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> Message-ID: <15502.25919.386105.104505@anthem.wooz.org> >>>>> "MZ" == Mikhail Zabaluev <mhz@alt-linux.org> writes: MZ> This steps on my pet peeve with Mailman: Does this matching MZ> regard Content-Transfer-Encoding as well? Tacking on text MZ> strings to a base64 text/plain body is a recipe for disaster, MZ> and such things happen, believe it or not. It doesn't, but that's a good point, and I think, fairly easy to add (see attached). MZ> Continuing the Hippocratic theme, I'd suggest a rule: don't MZ> meddle if it could hamper someone's reading capabilities. In MZ> this case, don't make multipart/mixed embellishments unless it MZ> IS multipart/mixed already. This is the case, currently. It means that if the message doesn't meet the plain/text criteria (+charset, +cte), and it's not already a multipart/mixed, the header and footer are not added. -Barry -------------------- snip snip -------------------- Index: Decorate.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Decorate.py,v retrieving revision 2.13 diff -u -r2.13 Decorate.py --- Decorate.py 12 Mar 2002 00:49:40 -0000 2.13 +++ Decorate.py 12 Mar 2002 20:29:12 -0000 @@ -72,6 +72,7 @@ # BAW: If the charsets don't match, should we add the header and footer by # MIME multipart chroming the message? if not msg.is_multipart() and msgtype == 'text/plain' and \ + not msg.get('content-transfer-encoding').lower() == 'base64' and \ (lcset == 'us-ascii' or mcset == lcset): payload = header + msg.get_payload() + footer msg.set_payload(payload) From barry@zope.com Tue Mar 12 20:56:37 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Mar 2002 15:56:37 -0500 Subject: [Mailman-Developers] moderation... References: <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> Message-ID: <15502.27525.129740.684663@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> You know, it just occured to me, that under the new model, I RJ> can't figure out how to let my list admins do something they RJ> used to be able to do... RJ> I have a list that's normally unmoderated, posting by RJ> subscriber only. Every now and then things get too heated, RJ> and the list owner steps in and flips the moderate switch RJ> until people play nice again. Under the new rules, to do RJ> that, the only way I see for him to do that is to go in and RJ> click "moderate" next to each of 300 names... Or he has to RJ> call me and I try to whip up a little python proc to run under RJ> withlist to flip everyone's bits... Did I miss something? RJ> (Yes, I followed the discussions, but this particular regular RJ> even just didn't register at the time...) That's definitely not a use case that's come up yet <wink>, so no I don't think you've missed anything. Let's tease out what you really want... - Would you be happy with an emergency switch that applied to all postings, from members and non-members alike, even if the non-members are on the "accept these non-members" list? - Should anybody's postings be able to go through without being caught by the emergency switch? - Should there be a magic header that lets messages go through even though the switch is pulled? Urgent: headers? - Once the emergency switch is pulled, what should happen to postings? Should they just get held for approval? Would it make any sense to reject or discard them? Should that even be configurable? Once I understand what the use cases are I can decide how hard it would be to support this feature. -Barry From chuqui@plaidworks.com Tue Mar 12 21:40:02 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 12 Mar 2002 13:40:02 -0800 Subject: [Mailman-Developers] moderation... In-Reply-To: <15502.27525.129740.684663@anthem.wooz.org> Message-ID: <B8B3B5B2.1BE9F%chuqui@plaidworks.com> On 3/12/02 12:56 PM, "Barry A. Warsaw" <barry@zope.com> wrote: > Let's tease out what you really want... (oreos, thanks... And soy milk) > - Would you be happy with an emergency switch that applied to all > postings, from members and non-members alike, even if the > non-members are on the "accept these non-members" list? Yes. Sometimes, you need a "time out, let's settle down" switch. > - Should anybody's postings be able to go through without being caught > by the emergency switch? Only the list admins. > - Should there be a magic header that lets messages go through even > though the switch is pulled? Urgent: headers? Maybe configurable. IMHO, if you push the Big Red Button, only the admins are allowed in until the Halon is gone.... > - Once the emergency switch is pulled, what should happen to postings? > Should they just get held for approval? Would it make any sense to > reject or discard them? Should that even be configurable? I'm sure someone would want auto-reject, but IMHO, you're looking at short-term, emergency moderation, so they go into the approval queue, so if nothing else, the admin can review them and send back a personal note explaining why the person should chill... (grin) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From mhz@alt-linux.org Tue Mar 12 22:23:59 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Wed, 13 Mar 2002 01:23:59 +0300 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <15502.25919.386105.104505@anthem.wooz.org> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> Message-ID: <20020312222358.GE2120@mhz.mikhail.zabaluev.name> Hello Barry, On Tue, Mar 12, 2002 at 03:29:51PM -0500, Barry A. Warsaw wrote: > > Index: Decorate.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Decorate.py,v > retrieving revision 2.13 > diff -u -r2.13 Decorate.py > --- Decorate.py 12 Mar 2002 00:49:40 -0000 2.13 > +++ Decorate.py 12 Mar 2002 20:29:12 -0000 > @@ -72,6 +72,7 @@ > # BAW: If the charsets don't match, should we add the header and footer by > # MIME multipart chroming the message? > if not msg.is_multipart() and msgtype == 'text/plain' and \ > + not msg.get('content-transfer-encoding').lower() == 'base64' and \ > (lcset == 'us-ascii' or mcset == lcset): > payload = header + msg.get_payload() + footer > msg.set_payload(payload) That (lcset == 'us-ascii') alternative assumes that the body charset is always ASCII-friendly. Close, but not exactly true. Additionally, I would handle quoted-printable by encoding the header and the footer into it. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ To be great is to be misunderstood. -- Ralph Waldo Emerson From che@debian.org Tue Mar 12 22:47:02 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Mar 2002 07:47:02 +0900 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <15502.22216.344495.123786@anthem.wooz.org> (barry@zope.com's message of "Tue, 12 Mar 2002 14:28:08 -0500") References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> <15501.40707.412796.594457@anthem.wooz.org> <871yeqdyue.fsf@nausicaa.interq.or.jp> <15502.3540.289539.846916@anthem.wooz.org> <15502.22216.344495.123786@anthem.wooz.org> Message-ID: <87elipcsk9.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: >>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes: BAW> Here's another idea/compromise: in the screen where you BAW> create new lists through the web, I could easily add another BAW> binary toggle, like "Should your new list quarantine new BAW> members?" which would set the default value for BAW> default_member_moderation. BAW> This is in cvs now. Hopefully this will put the issue to BAW> bed. This is okay, but I would still much much prefer it if DEFAULT_DEFAULT_MEMBER_MODERATION were just set to 0, Barry. I love the feature, but I hate changing the default. Please trust me when I say you will get hundreds of flaming bug reports from people who do not use the web interface (only knowing 'newlist' as the way to create lists) then have to manually set each user's moderated flag by hand. It's still a huge change from Mailman 2.0. I still think DEFAULT_DEFAULT_MEMBER_MODERATION should be set to 0. The web interface choice, though, is nice. Ben -- Brought to you by the letters X and U and the number 2. "I wanna be Twist Barbie!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From Dan Mick <dmick@utopia.West.Sun.COM> Tue Mar 12 22:49:55 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Tue, 12 Mar 2002 14:49:55 -0800 (PST) Subject: [Mailman-Developers] Missing footers with latest CVS Message-ID: <200203122250.g2CMo0Wk011331@utopia.West.Sun.COM> > > Index: Decorate.py > > =================================================================== > > RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Decorate.py,v > > retrieving revision 2.13 > > diff -u -r2.13 Decorate.py > > --- Decorate.py 12 Mar 2002 00:49:40 -0000 2.13 > > +++ Decorate.py 12 Mar 2002 20:29:12 -0000 > > @@ -72,6 +72,7 @@ > > # BAW: If the charsets don't match, should we add the header and footer by > > # MIME multipart chroming the message? > > if not msg.is_multipart() and msgtype == 'text/plain' and \ > > + not msg.get('content-transfer-encoding').lower() == 'base64' and \ > > (lcset == 'us-ascii' or mcset == lcset): > > payload = header + msg.get_payload() + footer > > msg.set_payload(payload) > > That (lcset == 'us-ascii') alternative assumes that the body > charset is always ASCII-friendly. Close, but not exactly true. The assertion was made that *all* charsets we support have us-ascii as a strict and complete subset. Are you claiming that's not true, or claiming that the assertion isn't sufficient to allow that alternative? From che@debian.org Tue Mar 12 23:03:34 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Mar 2002 08:03:34 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <20020312222358.GE2120@mhz.mikhail.zabaluev.name> (Mikhail Zabaluev's message of "Wed, 13 Mar 2002 01:23:59 +0300") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> <20020312222358.GE2120@mhz.mikhail.zabaluev.name> Message-ID: <876641crsp.fsf@nausicaa.interq.or.jp> >>>>> "Mikhail" == Mikhail Zabaluev <mhz@alt-linux.org> writes: Mikhail> That (lcset == 'us-ascii') alternative assumes that the Mikhail> body charset is always ASCII-friendly. Close, but not Mikhail> exactly true. Additionally, I would handle Mikhail> quoted-printable by encoding the header and the footer Mikhail> into it. I brought this point up a week or so ago; can you come up with any examples of charsets besides UTF-16 that Mailman supports that are not strict supersets of 7-bit us-ascii? Ben -- Brought to you by the letters Q and G and the number 2. "Ha ha! I have evaded you with the aid of these pasty white mints!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From Dan Mick <dmick@utopia.West.Sun.COM> Tue Mar 12 23:09:04 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Tue, 12 Mar 2002 15:09:04 -0800 (PST) Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman Message-ID: <200203122309.g2CN99Wk012980@utopia.West.Sun.COM> > This is okay, but I would still much much prefer it if > DEFAULT_DEFAULT_MEMBER_MODERATION were just set to 0, Barry. Me too. I don't understand changing the default to "a certainly- surprising behavior", even if that behavior is really really attractive to some admins for some lists. From marc_news@vasoftware.com Tue Mar 12 23:13:47 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 12 Mar 2002 15:13:47 -0800 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <87elipcsk9.fsf@nausicaa.interq.or.jp> References: <87it87kbhy.fsf@nausicaa.interq.or.jp> <15500.17278.993364.826959@anthem.wooz.org> <87elirfutm.fsf@nausicaa.interq.or.jp> <15501.40707.412796.594457@anthem.wooz.org> <871yeqdyue.fsf@nausicaa.interq.or.jp> <15502.3540.289539.846916@anthem.wooz.org> <15502.22216.344495.123786@anthem.wooz.org> <87elipcsk9.fsf@nausicaa.interq.or.jp> Message-ID: <20020312231347.GW23754@merlins.org> On Wed, Mar 13, 2002 at 07:47:02AM +0900, Ben Gertzfield wrote: > I love the feature, but I hate changing the default. Please trust me > when I say you will get hundreds of flaming bug reports from people > who do not use the web interface (only knowing 'newlist' as the way to > create lists) then have to manually set each user's moderated flag by > hand. It's still a huge change from Mailman 2.0. You do not need to set each user's flag. The web interface has: "* Set everyone's moderation bit, including those members not currently visible" so you can switch everyone all at once if you have to after the fact. > I still think DEFAULT_DEFAULT_MEMBER_MODERATION should be set to 0. I pass Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From mhz@alt-linux.org Wed Mar 13 00:38:29 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Wed, 13 Mar 2002 03:38:29 +0300 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <876641crsp.fsf@nausicaa.interq.or.jp> References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> <20020312222358.GE2120@mhz.mikhail.zabaluev.name> <876641crsp.fsf@nausicaa.interq.or.jp> Message-ID: <20020313003829.GA9096@mhz.mikhail.zabaluev.name> Hello Ben, On Wed, Mar 13, 2002 at 08:03:34AM +0900, Ben Gertzfield wrote: > > >>>>> "Mikhail" == Mikhail Zabaluev <mhz@alt-linux.org> writes: > > Mikhail> That (lcset == 'us-ascii') alternative assumes that the > Mikhail> body charset is always ASCII-friendly. Close, but not > Mikhail> exactly true. Additionally, I would handle > Mikhail> quoted-printable by encoding the header and the footer > Mikhail> into it. > > I brought this point up a week or so ago; can you come up with any > examples of charsets besides UTF-16 that Mailman supports that are > not strict supersets of 7-bit us-ascii? Umm... UCS-4? :) Do you imply that these two could be left out as special cases? -- Stay tuned, MhZ JID: mookid@jabber.org ___________ manic-depressive, adj.: Easy glum, easy glow. From jb@cascade-sys.com Wed Mar 13 00:45:53 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Tue, 12 Mar 2002 16:45:53 -0800 Subject: [Mailman-Developers] Stripping HTML References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> <3C870980.76E9B2D@cascade-sys.com> <20020312105505.GH2183@mhz.mikhail.zabaluev.name> Message-ID: <3C8EA141.1DEF3230@cascade-sys.com> Mikhail Zabaluev wrote: > Sorry to ruin your PhD, but will the > "lynx -dump -assume-charset='$charset_from_header'" command serve fine? > I happily use it to display HTML in the Mutt pager pane. Nope. It's clearly no good, since *I* didn't invent it. :o) Seriously, it's a good suggestion. Thanks. Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From che@debian.org Wed Mar 13 03:33:35 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Mar 2002 12:33:35 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <20020313003829.GA9096@mhz.mikhail.zabaluev.name> (Mikhail Zabaluev's message of "Wed, 13 Mar 2002 03:38:29 +0300") References: <200203041814.g24IEHcW028389@utopia.West.Sun.COM> <87k7srpz39.fsf@nausicaa.interq.or.jp> <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> <20020312222358.GE2120@mhz.mikhail.zabaluev.name> <876641crsp.fsf@nausicaa.interq.or.jp> <20020313003829.GA9096@mhz.mikhail.zabaluev.name> Message-ID: <87sn75b0q8.fsf@nausicaa.interq.or.jp> >>>>> "Mikhail" == Mikhail Zabaluev <mhz@alt-linux.org> writes: Ben> I brought this point up a week or so ago; can you come up Ben> with any examples of charsets besides UTF-16 that Mailman Ben> supports that are not strict supersets of 7-bit us-ascii? Mikhail> Umm... UCS-4? :) Do you imply that these two could be Mikhail> left out as special cases? I think if people are sending architecture-specific email, we have bigger problems, so yes. :) Ben -- Brought to you by the letters O and Z and the number 11. "Bill Gates is a talented evil man." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From mhz@alt-linux.org Wed Mar 13 09:26:34 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Wed, 13 Mar 2002 12:26:34 +0300 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <87sn75b0q8.fsf@nausicaa.interq.or.jp> References: <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> <20020312222358.GE2120@mhz.mikhail.zabaluev.name> <876641crsp.fsf@nausicaa.interq.or.jp> <20020313003829.GA9096@mhz.mikhail.zabaluev.name> <87sn75b0q8.fsf@nausicaa.interq.or.jp> Message-ID: <20020313092634.GD1932@mhz.mikhail.zabaluev.name> Hello Ben, On Wed, Mar 13, 2002 at 12:33:35PM +0900, Ben Gertzfield wrote: > > >>>>> "Mikhail" == Mikhail Zabaluev <mhz@alt-linux.org> writes: > > Ben> I brought this point up a week or so ago; can you come up > Ben> with any examples of charsets besides UTF-16 that Mailman > Ben> supports that are not strict supersets of 7-bit us-ascii? > > Mikhail> Umm... UCS-4? :) Do you imply that these two could be > Mikhail> left out as special cases? > > I think if people are sending architecture-specific email, we have > bigger problems, so yes. :) UTF-16 architecture-specific? Whatever happened to BOM characters? -- Stay tuned, MhZ JID: mookid@jabber.org ___________ If you think the system is working, ask someone who's waiting for a prompt. From fil@rezo.net Wed Mar 13 09:37:22 2002 From: fil@rezo.net (Fil) Date: Wed, 13 Mar 2002 10:37:22 +0100 Subject: [Mailman-Developers] Stripping HTML In-Reply-To: <3C8EA141.1DEF3230@cascade-sys.com> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> <3C870980.76E9B2D@cascade-sys.com> <20020312105505.GH2183@mhz.mikhail.zabaluev.name> <3C8EA141.1DEF3230@cascade-sys.com> Message-ID: <20020313093722.GA23691@rezo.net> > Mikhail Zabaluev wrote: > > Sorry to ruin your PhD, but will the > > "lynx -dump -assume-charset='$charset_from_header'" command serve fine? > > I happily use it to display HTML in the Mutt pager pane. Did you manage to use it as a mail filter (ie without opening mutt in a console?) I've never been able to have something like /etc/aliases: listname: "|superfilter |/path/to/ml/manager" Where superfilter would demime as intelligently as possible, ie, use /etc/mailcap for all *2text programs it knows of. Inside mutt almost everything (richtext, html, images, PDFs, MSWord documents, etc.) is transformed into text. I would love to have that as a filter for some lists... -- Fil From mhz@alt-linux.org Wed Mar 13 10:04:20 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Wed, 13 Mar 2002 13:04:20 +0300 Subject: [Mailman-Developers] Stripping HTML In-Reply-To: <20020313093722.GA23691@rezo.net> References: <200203050202.g2522bcW021852@utopia.West.Sun.COM> <87adtn1wiv.fsf@tleepslib.sk.tsukuba.ac.jp> <3C844F29.6998B3C2@cascade-sys.com> <15494.13552.463922.647379@anthem.wooz.org> <3C86679F.59B57394@cascade-sys.com> <15494.63642.131234.587632@anthem.wooz.org> <3C870980.76E9B2D@cascade-sys.com> <20020312105505.GH2183@mhz.mikhail.zabaluev.name> <3C8EA141.1DEF3230@cascade-sys.com> <20020313093722.GA23691@rezo.net> Message-ID: <20020313100420.GA5145@mhz.mikhail.zabaluev.name> Hello Fil, On Wed, Mar 13, 2002 at 10:37:22AM +0100, Fil wrote: > > > Mikhail Zabaluev wrote: > > > Sorry to ruin your PhD, but will the > > > "lynx -dump -assume-charset='$charset_from_header'" command serve fine? > > > I happily use it to display HTML in the Mutt pager pane. > > Did you manage to use it as a mail filter (ie without opening mutt in a > console?) I've never been able to have something like > > /etc/aliases: > listname: "|superfilter |/path/to/ml/manager" > > Where superfilter would demime as intelligently as possible, ie, use > /etc/mailcap for all *2text programs it knows of. Inside mutt almost > everything (richtext, html, images, PDFs, MSWord documents, etc.) is > transformed into text. I'm unaware of such a filter. demime is used widely, but I doubt it uses /etc/mailcap. mailcap, as I know it, won't serve good for stream filters; essentially, only entries flagged as "copiousoutput" are useable for producing stream output. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ If you flaunt it, expect to have it trashed. From che@debian.org Wed Mar 13 15:01:53 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 14 Mar 2002 00:01:53 +0900 Subject: [Mailman-Developers] Missing footers with latest CVS In-Reply-To: <20020313092634.GD1932@mhz.mikhail.zabaluev.name> (Mikhail Zabaluev's message of "Wed, 13 Mar 2002 12:26:34 +0300") References: <3C84275F.6020703@is.kochi-u.ac.jp> <87bse3pxcs.fsf@nausicaa.interq.or.jp> <87eliz1x9o.fsf@tleepslib.sk.tsukuba.ac.jp> <15494.64729.535773.898549@anthem.wooz.org> <20020312113924.GI2183@mhz.mikhail.zabaluev.name> <15502.25919.386105.104505@anthem.wooz.org> <20020312222358.GE2120@mhz.mikhail.zabaluev.name> <876641crsp.fsf@nausicaa.interq.or.jp> <20020313003829.GA9096@mhz.mikhail.zabaluev.name> <87sn75b0q8.fsf@nausicaa.interq.or.jp> <20020313092634.GD1932@mhz.mikhail.zabaluev.name> Message-ID: <87eliobjfi.fsf@nausicaa.interq.or.jp> >>>>> "Mikhail" == Mikhail Zabaluev <mhz@alt-linux.org> writes: Mikhail> UTF-16 architecture-specific? Whatever happened to BOM Mikhail> characters? Yes, there is the BOM to flag which endianness you're using. I'm mostly being facetious, though, because I don't think MUAs aside from broken beta versions of Outlook Express would even dare to use UTF-16 in real email for the real world. If we run into any, then we can rethink adding the footer in us-ascii, but for now I think it's acceptable to keep people from saying "where have my footers gone?" Currently we're always adding the footer anyway, so this is a step in the right direction. Ben -- Brought to you by the letters N and Y and the number 1. "I choose YOU! Pikachu!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From jarrell@vt.edu Wed Mar 13 15:19:18 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Mar 2002 10:19:18 -0500 Subject: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman In-Reply-To: <200203122309.g2CN99Wk012980@utopia.West.Sun.COM> Message-ID: <5.1.0.14.2.20020313095827.03d6f920@lennier.cc.vt.edu> At 03:09 PM 3/12/02 -0800, Dan Mick wrote: >> This is okay, but I would still much much prefer it if >> DEFAULT_DEFAULT_MEMBER_MODERATION were just set to 0, Barry. > >Me too. I don't understand changing the default to "a certainly- >surprising behavior", even if that behavior is really really >attractive to some admins for some lists. I suppose I should my 2 cents that I didn't comment when the initial discussions came up, because the people for it were really for it, and while I was against it, it was a sort of lackluster "I really don't like that default changing, but I know enough to flip the darn bit in my own mm_cfg file immediately." I agree, in thinking about it, that it's a major change from the POV of the installed user base (and, for that matter, not entirely an expected thing from any MLM). If it's felt we really need to do this as a default, there needs to be a cycle of having the switch in there the old way, with loud warnings in various places that the default will change in a future release... From jarrell@vt.edu Wed Mar 13 14:56:56 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Mar 2002 09:56:56 -0500 Subject: [Mailman-Developers] moderation... In-Reply-To: <15502.27525.129740.684663@anthem.wooz.org> References: <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020313095246.03d6be00@lennier.cc.vt.edu> At 03:56 PM 3/12/02 -0500, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: > > RJ> You know, it just occured to me, that under the new model, I > RJ> can't figure out how to let my list admins do something they > RJ> used to be able to do... > > RJ> I have a list that's normally unmoderated, posting by > RJ> subscriber only. Every now and then things get too heated, > RJ> and the list owner steps in and flips the moderate switch > RJ> until people play nice again. Under the new rules, to do > RJ> that, the only way I see for him to do that is to go in and > RJ> click "moderate" next to each of 300 names... Or he has to > RJ> call me and I try to whip up a little python proc to run under > RJ> withlist to flip everyone's bits... Did I miss something? > RJ> (Yes, I followed the discussions, but this particular regular > RJ> even just didn't register at the time...) > >That's definitely not a use case that's come up yet <wink>, so no I >don't think you've missed anything. Oh good :-). >Let's tease out what you really want... Well, for the case of this list, and drawing on the experiences of another list I'm on, but don't host, that has done this more than once: >- Would you be happy with an emergency switch that applied to all > postings, from members and non-members alike, even if the > non-members are on the "accept these non-members" list? I think that would suffice - in these cases it's usually a flame war that's broken out, and the admin/moderator wants everything to just *stop* temporarily, but generally not be lost. >- Should anybody's postings be able to go through without being caught > by the emergency switch? Well, it'd probably be nice if the addresses listed as admins/moderators could still post. Bonus points I suppose for that to be configurable, but, jeez, if you can't trust the other moderators, your list is screwed. >- Should there be a magic header that lets messages go through even > though the switch is pulled? Urgent: headers? I don't think so; otherwise anyone who's sussed the trick defeats the purpose. >- Once the emergency switch is pulled, what should happen to postings? > Should they just get held for approval? Would it make any sense to > reject or discard them? Should that even be configurable? Base state would be "held for approval." Then the admin can either let them through later, or pick out eggregious ones to nuke before letting things go. Given the existing tools, it's simple enough to just reject or discard them all from the admindb page if so desired. From jra@baylink.com Wed Mar 13 18:51:02 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 13 Mar 2002 13:51:02 -0500 Subject: [Mailman-Developers] Feedback needed: nodupes patch and reply-to munging per user In-Reply-To: <20020311204127.GE23754@merlins.org>; from Marc MERLIN <marc_news@vasoftware.com> on Mon, Mar 11, 2002 at 12:41:27PM -0800 References: <20020311204127.GE23754@merlins.org> Message-ID: <20020313135102.08750@scfn.thpl.lib.fl.us> On Mon, Mar 11, 2002 at 12:41:27PM -0800, Marc MERLIN wrote: > Ben Gertzfield wrote a patch which Barry recently included in mailman-cvs > which allows you to not receive the list copy of a message in you were Cced > in the headers (nodupes patch). > The idea is to reproduce the (imo sole useful) feature of reply-to munging > where people don't get two copies of replies to posts. You know, perhaps it's me, but won't that mean that the headers on the messages that *cc'd* you will be *different* than the ones that didn't? That might be problematic in itself for some folks, mightn't it? > After porting his patch to mailman-cvs, I've written another patch that > extends this functionality by making reply-to munging a per user option. So, here, do you mean "the adding of a reply-to mung to the list", or do you mean "stripping any possible reply-to added by the writer"? I've read it twice now, and I still can't decide which I think you mean -- except that the list context was the latter. I'm on Rosenthal's side concerning the former... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Wed Mar 13 18:56:07 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 13 Mar 2002 13:56:07 -0500 Subject: [Mailman-Developers] moderation... In-Reply-To: <15502.27525.129740.684663@anthem.wooz.org>; from "Barry A. Warsaw" <barry@zope.com> on Tue, Mar 12, 2002 at 03:56:37PM -0500 References: <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> <15502.27525.129740.684663@anthem.wooz.org> Message-ID: <20020313135607.50458@scfn.thpl.lib.fl.us> On Tue, Mar 12, 2002 at 03:56:37PM -0500, Barry A. Warsaw wrote: > Let's tease out what you really want... > > - Would you be happy with an emergency switch that applied to all > postings, from members and non-members alike, even if the > non-members are on the "accept these non-members" list? A list level master-override switch to moderate everyone temporarily; yeah, that's what I think he's asking. > - Once the emergency switch is pulled, what should happen to postings? > Should they just get held for approval? Would it make any sense to > reject or discard them? Should that even be configurable? I'd assume he simply wants one more list-level "should postings be treated as moderated" flag that could be toggled in realtime, that would be checked right before (or after) the per-user one. In general, I think that's a good idea. It probably needs a Rude Solo Light, though. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jarrell@vt.edu Wed Mar 13 20:06:43 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Mar 2002 15:06:43 -0500 Subject: [Mailman-Developers] moderation... In-Reply-To: <20020313135607.50458@scfn.thpl.lib.fl.us> References: <"from Barry A. Warsaw" <barry@zope.com> <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> <15502.27525.129740.684663@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020313150540.05e18ec0@lennier.cc.vt.edu> At 01:56 PM 3/13/02 -0500, Jay R. Ashworth wrote: >It probably needs a Rude Solo Light, though. > >Cheers, >-- jra Bwahah... *I* actually get that :-) Now we divide the people who do sound engineering from the ones who don't... From James.Madill@duke.edu Wed Mar 13 21:40:02 2002 From: James.Madill@duke.edu (James Madill) Date: Wed, 13 Mar 2002 16:40:02 -0500 Subject: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? Message-ID: <OFBF423519.24F5C63E-ON85256B7B.00757A3F@mc.duke.edu> This is a multipart message in MIME format. --=_alternative 0076DBCC85256B7B_= Content-Type: text/plain; charset="us-ascii" Users of one of my mailing lists got a nasty surprise when a posted message was repeatedly sent to them. I traced the problem down to an instance of the standard End-Of-Message marker (a lone period on a line) in the middle of the posted message. The posted message contained extended ASCII characters encoded using the MIME Content-transfer-encoding: quoted-printable format. There was what appeared to be soft returns at column 72. This message happened to have a paragraph that ended on column 73, so the "soft return" resulted in the period alone on the next line. Sendmail accepted the encoded document for Mailman, but on sending out, Mailman encountered what it thought was an EOM marker and stopped the processing of the message at that point. Unfortunately, there was still plenty of message left to send, so it was not removed from the queue, and Mailman kept on sending the first portion. The smtp daemon is sendmail 8.12.1. Mailman is version 2.0.8 with DELIVERY_MODULE = 'SMTPDirect' in Defaults.py. Am I missing some Mailman switch to tell it to recognize messages with the Content-transfer-encoding: quoted-printable tag? -- James o o o o o o o . . . _______________________ _______=======_T___ o _____ |James Madill | |Duke Univ Med Ctr| >.][__n_n_| D[ ====|____ |james.madill@duke.edu| | (919) 286-6384 | (________|__|_[____/____]_|_____________________|_|_________________| _/oo O-O-O ` oo oo 'o^o^o o^o^o` 'o^o o^o` -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- <http://www.duke.edu/~madil001/> --=_alternative 0076DBCC85256B7B_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Users of one of my mailing lists got a nasty surprise when a posted message was repeatedly sent to them.</font> <br> <br><font size=2 face="sans-serif">I traced the problem down to an instance of the standard End-Of-Message marker (a lone period on a line) in the middle of the posted message.</font> <br> <br><font size=2 face="sans-serif">The posted message contained extended ASCII characters encoded using the MIME Content-transfer-encoding: quoted-printable format.  There was what appeared to be soft returns at column 72.  This message happened to have a paragraph that ended on column 73, so the "soft return" resulted in the period alone on the next line.</font> <br> <br><font size=2 face="sans-serif">Sendmail accepted the encoded document for Mailman, but on sending out, Mailman encountered what it thought was an EOM marker and stopped the processing of the message at that point.  Unfortunately, there was still plenty of message left to send, so it was not removed from the queue, and Mailman kept on sending the first portion.</font> <br> <br><font size=2 face="sans-serif">The smtp daemon is sendmail 8.12.1.  Mailman is version 2.0.8 with DELIVERY_MODULE = 'SMTPDirect' in Defaults.py.</font> <br> <br><font size=2 face="sans-serif">Am I missing some Mailman switch to tell it to recognize messages with the Content-transfer-encoding: quoted-printable tag?<br> </font><font size=3><tt><br> -- James<br> <br>      </tt></font><font size=3 color=#b0b0b0><tt>o o o o o o o . . .</tt></font><font size=3><tt>   </tt></font><font size=3 color=blue><tt>_______________________</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>_______=======_</tt></font><font size=3><tt>T</tt></font><font size=3 color=red><tt>___</tt></font><font size=3><tt><br>    </tt></font><font size=3 color=#b0b0b0><tt>o</tt></font><font size=3><tt>      _____            </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>James Madill         </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt>Duke Univ Med Ctr</tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br> </tt></font><font size=3 color=#f0c02c><tt>></tt></font><font size=3><tt>.][__n_n_| D[  ====|____  </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>james.madill@duke.edu</tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt> (919) 286-6384  </tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br>  (________|__|_[____/____]_</tt></font><font size=3 color=blue><tt>|_____________________|</tt></font><font size=3><tt>_</tt></font><font size=3 color=red><tt>|_________________|</tt></font><font size=3><tt><br> _/oo  O-O-O  `  oo     oo  'o^o^o           o^o^o` 'o^o           o^o`<br> </tt></font><font size=3 color=#b0802c><tt>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-</tt></font><font size=3><tt><br> <http://www.duke.edu/~madil001/></tt></font> --=_alternative 0076DBCC85256B7B_=-- From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 14 00:30:46 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Wed, 13 Mar 2002 16:30:46 -0800 (PST) Subject: [Mailman-Developers] bin/withlist: -i default, remove switch? Message-ID: <200203140030.g2E0UqWk019298@utopia.West.Sun.COM> It occurs to me that "bin/withlist <listname>" is pretty useless (what you almost-certainly want is "bin/withlist -i listname"). Would it be reasonable to make -i the default (and thus remove the switch)? From che@debian.org Thu Mar 14 01:03:35 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 14 Mar 2002 10:03:35 +0900 Subject: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? In-Reply-To: <OFBF423519.24F5C63E-ON85256B7B.00757A3F@mc.duke.edu> ("James Madill"'s message of "Wed, 13 Mar 2002 16:40:02 -0500") References: <OFBF423519.24F5C63E-ON85256B7B.00757A3F@mc.duke.edu> Message-ID: <87zo1c9d08.fsf@nausicaa.interq.or.jp> >>>>> "James" == James Madill <James.Madill@duke.edu> writes: James> Users of one of my mailing lists got a nasty surprise when James> a posted message was repeatedly sent to them. James> I traced the problem down to an instance of the standard James> End-Of-Message marker (a lone period on a line) in the James> middle of the posted message. James> The smtp daemon is sendmail 8.12.1. Mailman is version James> 2.0.8 with DELIVERY_MODULE = 'SMTPDirect' in Defaults.py. James> Am I missing some Mailman switch to tell it to recognize James> messages with the Content-transfer-encoding: James> quoted-printable tag? Mailman 2.0's handling of MIME messages in general was very sub-par. Mailman 2.1 has an entirely re-written infrastructure for MIME message handling, and likely has fixed this bug (the old quoted-printable module had some serious flaws and has been re-written). If you could send us a copy of the naughty message, we could test it with Mailman 2.1 from CVS and let you know if the bug has been fixed, but I'll bet that it has been fixed now. Ben -- Brought to you by the letters H and A and the number 16. "I wanna be Twist Barbie!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From mrbill@mrbill.net Thu Mar 14 01:14:17 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Wed, 13 Mar 2002 19:14:17 -0600 Subject: [Mailman-Developers] feature freeze / release timeline? Message-ID: <20020314011417.GI18679@mrbill.net> Any idea on a feature freeze /release timeline for 2.1? Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From marc_news@vasoftware.com Thu Mar 14 01:32:08 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 13 Mar 2002 17:32:08 -0800 Subject: [Mailman-Developers] feature freeze / release timeline? In-Reply-To: <20020314011417.GI18679@mrbill.net> References: <20020314011417.GI18679@mrbill.net> Message-ID: <20020314013207.GI23754@merlins.org> On Wed, Mar 13, 2002 at 07:14:17PM -0600, Bill Bradford wrote: > Any idea on a feature freeze /release timeline for 2.1? RSN :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 14 02:04:27 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Wed, 13 Mar 2002 18:04:27 -0800 (PST) Subject: [Mailman-Developers] Is there a stupid Python trick to save me? Message-ID: <200203140204.g2E24XWk026289@utopia.West.Sun.COM> I had an interesting thing happen today; a list started to get two footers added to it. Odd. Then I remembered why: I'd defined a pipeline for this list that had an extra module in it (my "BounceImplicit" module that just rejects Bccs; the custom list pipeline contained the old default + Bounce Implicit). But now, Decorate shouldn't be in the pipeline, since it's called by SMTPDirect directly with the latest changes to SMTPDirect. So my pipeline calls it once explicitly and once implicitly. Oops. It occurred to me that if there were some way to have a 'lazy evaluate' in a Python variable, I could maybe work around that, by saying "list.pipeline = mm_cfg.GLOBAL_PIPELINE + 'BounceImplicit' (or something like that) That way, if GLOBAL_PIPELINE changes, I still get the right effect. But I don't know how I might mechanize something like that without hacking the code. Am I smoking something, or is there some stupid Python trick that would allow "dynamic list composition from a value"? (Alternatively, would it be worth having something that allows "add to the pipeline at a defined location" declarations, so that people can add custom modules but still track changes to the source? I realize that as an alpha tester I'm in a bit of a unique situation, but..) From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 14 03:23:44 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Wed, 13 Mar 2002 19:23:44 -0800 (PST) Subject: [Mailman-Developers] Bug in Chinese language selections and options page? Message-ID: <200203140323.g2E3NoWk029732@utopia.West.Sun.COM> OK, I've got no idea how to browse Chinese; I'm using a Netscape and OS that have no support for the font. That might be the problem. However: if I use my personal subscription options page: http://host.dom.ain/mailman/options/listname/subscribe-addr to change language to "Traditional Chinese" or "Simplified Chinese", I get an expectedly-garbled page, but unfortunately it appears with no "Submit My Changes" button, so if I were unaware that I could use my browser's Back button, I just did something I can't recover from. Is that because my browser is just not capable? Even if so, does this seem bad? From barry@zope.com Thu Mar 14 03:40:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 13 Mar 2002 22:40:12 -0500 Subject: [Mailman-Developers] feature freeze / release timeline? References: <20020314011417.GI18679@mrbill.net> <20020314013207.GI23754@merlins.org> Message-ID: <15504.7068.281907.281333@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> On Wed, Mar 13, 2002 at 07:14:17PM -0600, Bill Bradford wrote: >> Any idea on a feature freeze /release timeline for 2.1? MM> RSN :-) Correction: RRRSN. :) I need to get beta1 out if only so I can stop adding little things while in long meetings. wait-for-it-ly y'rs, -Barry From barry@zope.com Thu Mar 14 03:54:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 13 Mar 2002 22:54:57 -0500 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? References: <200203140204.g2E24XWk026289@utopia.West.Sun.COM> Message-ID: <15504.7953.625708.166444@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> I had an interesting thing happen today; a list started to get DM> two footers added to it. Odd. There was a bug, now fixed in CVS which caused decorations to be added to stuff like messages to list-owner. I've added a block in Decorate.process(): if the metadata has a true 'nodecorate' key, it short-circuits the decoartions. Not directly related, but just FYI. DM> It occurred to me that if there were some way to have a 'lazy DM> evaluate' in a Python variable, I could maybe work around DM> that, by saying "list.pipeline = mm_cfg.GLOBAL_PIPELINE + DM> 'BounceImplicit' (or something like that) That way, if DM> GLOBAL_PIPELINE changes, I still get the right effect. DM> But I don't know how I might mechanize something like that DM> without hacking the code. DM> Am I smoking something, or is there some stupid Python trick DM> that would allow "dynamic list composition from a value"? There are a couple of things that might be possible, but I'm pulling both ideas out of my ass at the moment. Haven't tried either. In Python 2.2 you could possibly use descriptors on new-style classes to define this kind of lazy evaluation. Actually descriptors are a very cool idea that will probably be used extensively in MM3.0 to provide customizability in the database and web gui interchanging dimensions w/o sacrificing readability. If you wanted to take a large bite (or risk brain explosion), you might look into acquisition, which is a technique used in Zope for finding attributes based on containment heirarchy, as opposed to the traditional inheritence heirarchy. Very neat idea, except that implicit acquisition can be exceedingly frustrating when it goes wrong (explict acquisition might not be as bad). DM> (Alternatively, would it be worth having something that allows DM> "add to the pipeline at a defined location" declarations, so DM> that people can add custom modules but still track changes to DM> the source? I realize that as an alpha tester I'm in a bit of DM> a unique situation, but..) For the IncomingRunner, it should be easy. Create a subclass of IncomingRunner, and override the _get_pipeline() method. Then override the QRUNNERS variable in your mm_cfg.py to use your new subclass rather than IncomingRunner. Again, untested, but a bit easier to do, and much safer on the brain the above two half-baked ideas. -Barry From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 14 04:11:00 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Wed, 13 Mar 2002 20:11:00 -0800 (PST) Subject: [Mailman-Developers] Is there a stupid Python trick to save me? Message-ID: <200203140411.g2E4B7Wk001830@utopia.West.Sun.COM> > For the IncomingRunner, it should be easy. Create a subclass of > IncomingRunner, and override the _get_pipeline() method. Then > override the QRUNNERS variable in your mm_cfg.py to use your new > subclass rather than IncomingRunner. Again, untested, but a bit > easier to do, and much safer on the brain the above two half-baked > ideas. Well, if I wanted to hack the code, lots of things would be easy... but I was thinking of "some codified thing that lets an admin do customization things" rather than "unsupported code hacks". I was probing whether or not others thought there was a need; primarily you. If we're talking about custom pipeline modules, we're talking about Python coders, so that's not a horrible thing, but: since modules are already so separate, it would be useful, perhaps, to have some sort of "insert this into the pipeline" mechanism that is also separate and robust wrt changes like GLOBAL_PIPELINE changes. I suppose subclassing isn't so bad, but it's a bit heavier mechanism than I was thinking...but that may just be a function of me thinking like a procedural programmer. :) From barry@zope.com Thu Mar 14 04:30:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 13 Mar 2002 23:30:19 -0500 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? References: <200203140411.g2E4B7Wk001830@utopia.West.Sun.COM> Message-ID: <15504.10075.757285.31975@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> If we're talking about custom pipeline modules, we're talking DM> about Python coders, so that's not a horrible thing, but: DM> since modules are already so separate, it would be useful, DM> perhaps, to have some sort of "insert this into the pipeline" DM> mechanism that is also separate and robust wrt changes like DM> GLOBAL_PIPELINE changes. DM> I suppose subclassing isn't so bad, but it's a bit heavier DM> mechanism than I was thinking...but that may just be a DM> function of me thinking like a procedural programmer. :) :). Let's keep thinking about it. -Barry From chuqui@plaidworks.com Thu Mar 14 06:57:55 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 13 Mar 2002 22:57:55 -0800 Subject: [Mailman-Developers] feature freeze / release timeline? In-Reply-To: <15504.7068.281907.281333@anthem.wooz.org> Message-ID: <B8B589F3.1C759%chuqui@plaidworks.com> On 3/13/02 7:40 PM, "Barry A. Warsaw" <barry@zope.com> wrote: > Correction: RRRSN. :) As I remember it, Barry wants to ship 2.1 by February. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From marc_news@vasoftware.com Thu Mar 14 07:59:06 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 13 Mar 2002 23:59:06 -0800 Subject: [Mailman-Developers] feature freeze / release timeline? In-Reply-To: <B8B589F3.1C759%chuqui@plaidworks.com> References: <15504.7068.281907.281333@anthem.wooz.org> <B8B589F3.1C759%chuqui@plaidworks.com> Message-ID: <20020314075906.GM24440@merlins.org> On Wed, Mar 13, 2002 at 10:57:55PM -0800, Chuq Von Rospach wrote: > > Correction: RRRSN. :) > > As I remember it, Barry wants to ship 2.1 by February. Eh, I'm supposed to be the smartass around here :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From mjaw@ipartners.pl Thu Mar 14 08:51:33 2002 From: mjaw@ipartners.pl (Miroslaw Jaworski) Date: Thu, 14 Mar 2002 09:51:33 +0100 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? In-Reply-To: <200203140204.g2E24XWk026289@utopia.West.Sun.COM>; from dmick@utopia.West.Sun.COM on Wed, Mar 13, 2002 at 06:04:27PM -0800 References: <200203140204.g2E24XWk026289@utopia.West.Sun.COM> Message-ID: <20020314095133.C30234@quad.ikp.pl> * Dan Mick (dmick@utopia.West.Sun.COM) [020314 09:23] wrote: > I had an interesting thing happen today; a list started to get two > footers added to it. Odd. Hi We experienced the same case. In fact - initially we though there are two problems with strange similarity: - Problem with growing Re: Re: Re:[...] Some users keep sending Subject: encoded ( in our case it was base64 ) Mailman doesn't look into encoded string, doesn't find Re: to remove, just adds its own Re: to the beginning of the Subject: header. - Sometimes Mailman haven't removed it's own signature The same situation as previous, except whole mail content was encoded by the user, who had responded to the mail, and didn't removed list signature We use 2.0.8 Regards MJ. -- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager From che@debian.org Thu Mar 14 09:01:34 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 14 Mar 2002 18:01:34 +0900 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? In-Reply-To: <20020314095133.C30234@quad.ikp.pl> (Miroslaw Jaworski's message of "Thu, 14 Mar 2002 09:51:33 +0100") References: <200203140204.g2E24XWk026289@utopia.West.Sun.COM> <20020314095133.C30234@quad.ikp.pl> Message-ID: <87n0xba5g1.fsf@nausicaa.interq.or.jp> >>>>> "Miroslaw" == Miroslaw Jaworski <mjaw@ipartners.pl> writes: Miroslaw> We experienced the same case. In fact - initially we Miroslaw> though there are two problems with strange similarity: - Miroslaw> Problem with growing Re: Re: Re:[...] Miroslaw> Some users keep sending Subject: encoded ( in our case Miroslaw> it was base64 ) Mailman doesn't look into encoded Miroslaw> string, doesn't find Re: to remove, just adds its own Miroslaw> Re: to the beginning of the Subject: header. This is fixed in CVS. Mailman is now base64/quoted-printable aware for the Subject: line, and will not add the "[Listname] " prefix if the "Listname" string is already in the subject. Miroslaw> - Sometimes Mailman haven't removed it's own signature Miroslaw> The same situation as previous, except whole mail Miroslaw> content was encoded by the user, who had responded to Miroslaw> the mail, and didn't removed list signature In this case, Mailman will no longer add the signature to Base64 messages. If the user quotes the entire list signature and replies using Quoted-Printable, I'm not sure what will happen. Ben -- Brought to you by the letters W and U and the number 12. "A calpac is a large cap." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From mjaw@ipartners.pl Thu Mar 14 09:11:40 2002 From: mjaw@ipartners.pl (Miroslaw Jaworski) Date: Thu, 14 Mar 2002 10:11:40 +0100 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? In-Reply-To: <87n0xba5g1.fsf@nausicaa.interq.or.jp>; from che@debian.org on Thu, Mar 14, 2002 at 06:01:34PM +0900 References: <200203140204.g2E24XWk026289@utopia.West.Sun.COM> <20020314095133.C30234@quad.ikp.pl> <87n0xba5g1.fsf@nausicaa.interq.or.jp> Message-ID: <20020314101139.D30234@quad.ikp.pl> * Ben Gertzfield (che@debian.org) [020314 10:04] wrote: > >>>>> "Miroslaw" == Miroslaw Jaworski <mjaw@ipartners.pl> writes: > > Miroslaw> We experienced the same case. In fact - initially we > Miroslaw> though there are two problems with strange similarity: - > Miroslaw> Problem with growing Re: Re: Re:[...] > > Miroslaw> Some users keep sending Subject: encoded ( in our case > Miroslaw> it was base64 ) Mailman doesn't look into encoded > Miroslaw> string, doesn't find Re: to remove, just adds its own > Miroslaw> Re: to the beginning of the Subject: header. > > This is fixed in CVS. Mailman is now base64/quoted-printable aware > for the Subject: line, and will not add the "[Listname] " prefix > if the "Listname" string is already in the subject. > > Miroslaw> - Sometimes Mailman haven't removed it's own signature > > Miroslaw> The same situation as previous, except whole mail > Miroslaw> content was encoded by the user, who had responded to > Miroslaw> the mail, and didn't removed list signature > > In this case, Mailman will no longer add the signature to Base64 > messages. If the user quotes the entire list signature and replies > using Quoted-Printable, I'm not sure what will happen. I though so, although i didn't check it againts CVS :) MJ. -- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager From fil@rezo.net Thu Mar 14 10:51:38 2002 From: fil@rezo.net (Fil) Date: Thu, 14 Mar 2002 11:51:38 +0100 Subject: [Mailman-Developers] too much translation? Message-ID: <20020314105138.GA27967@rezo.net> Is it not a bit too much to translate the log files? Log analyzers would have to be more complex... ==> /home/mailman/logs/subscribe <== Mar 14 11:49:35 2002 (27832) menteur: deleted xxxxx@hotmail.com; Par la page des options des abonnés -- Fil From jarrell@vt.edu Thu Mar 14 15:17:04 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 14 Mar 2002 10:17:04 -0500 Subject: [Mailman-Developers] Is there a stupid Python trick to save me? In-Reply-To: <200203140411.g2E4B7Wk001830@utopia.West.Sun.COM> Message-ID: <5.1.0.14.2.20020314101613.03fb5aa0@lennier.cc.vt.edu> At 08:11 PM 3/13/02 -0800, Dan Mick wrote: >If we're talking about custom pipeline modules, we're talking about >Python coders, so that's not a horrible thing, but: since modules >are already so separate, it would be useful, perhaps, to have >some sort of "insert this into the pipeline" mechanism that is >also separate and robust wrt changes like GLOBAL_PIPELINE changes. Particular since one day we might have people writing cool custom pipeline modules that other people who really shouldn't be messing with code want to run... From barry@zope.com Thu Mar 14 17:23:35 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 12:23:35 -0500 Subject: [Mailman-Developers] Re: BounceRunner eating up alot of memory References: <20020312094434.GB7691@rezo.net> Message-ID: <15504.56471.867709.715156@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Barry, you commited the CACHELISTS changes to cvs, with the F> following comment: F> The error is : F>> File "/home/mailman/Mailman/OldStyleMemberships.py", line 344, in F>> setBounceInfo assert self.__mlist.Locked() F> AssertionError This bug, at least, should now be gone. -Barry From barry@zope.com Thu Mar 14 19:41:00 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 14:41:00 -0500 Subject: [Mailman-Developers] too much translation? References: <20020314105138.GA27967@rezo.net> Message-ID: <15504.64716.508175.405746@anthem.wooz.org> >>>>> "F" =3D=3D Fil <fil@rezo.net> writes: F> Is it not a bit too much to translate the log files? Log F> analyzers would have to be more complex... F> =3D=3D> /home/mailman/logs/subscribe <=3D=3D Mar 14 11:49:35 200= 2 F> (27832) menteur: deleted xxxxx@hotmail.com; Par la page des F> options des abonn=E9s No, log files are specifically /not/ translated, exactly for the reason you describe. I found one bogus i18n markup in a `whence' argument in options.py. Fixed in CVS. My very poor Latin-language to English translation tells me this was probably the one tripping you up. my-high-school-Spanish-teacher-would-be-so-proud-ly y'rs, -Barry From barry@zope.com Thu Mar 14 19:57:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 14:57:27 -0500 Subject: [Mailman-Developers] feature freeze / release timeline? References: <15504.7068.281907.281333@anthem.wooz.org> <B8B589F3.1C759%chuqui@plaidworks.com> Message-ID: <15505.167.579299.404200@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: CVR> As I remember it, Barry wants to ship 2.1 by February. I can guarantee that we'll meet that goal. Should be no problem getting it out by February. <wink> -Barry From db@bibsys.no Thu Mar 14 23:14:58 2002 From: db@bibsys.no (Daniel Buchmann) Date: Fri, 15 Mar 2002 00:14:58 +0100 Subject: [Mailman-Developers] too much translation? References: <20020314105138.GA27967@rezo.net> <15504.64716.508175.405746@anthem.wooz.org> Message-ID: <3C912EF2.E755E13D@bibsys.no> "Barry A. Warsaw" wrote: > > >>>>> "F" == Fil <fil@rezo.net> writes: > > F> ==> /home/mailman/logs/subscribe <== Mar 14 11:49:35 2002 > F> (27832) menteur: deleted xxxxx@hotmail.com; Par la page des > F> options des abonnés > > my-high-school-Spanish-teacher-would-be-so-proud-ly y'rs, > -Barry Hmm... why would he be proud, as "Par la page des options des abonnés" is French? :-D From barry@zope.com Thu Mar 14 23:14:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 18:14:55 -0500 Subject: [Mailman-Developers] too much translation? References: <20020314105138.GA27967@rezo.net> <15504.64716.508175.405746@anthem.wooz.org> <3C912EF2.E755E13D@bibsys.no> Message-ID: <15505.12015.868642.941303@anthem.wooz.org> >>>>> "DB" =3D=3D Daniel Buchmann <db@bibsys.no> writes: >> F> =3D=3D> /home/mailman/logs/subscribe <=3D=3D Mar 14 11:49:35 = 2002 F> >> (27832) menteur: deleted xxxxx@hotmail.com; Par la page des F> >> options des abonn=E9s >> my-high-school-Spanish-teacher-would-be-so-proud-ly y'rs, >> -Barry DB> Hmm... why would he be proud, as "Par la page des options des DB> abonn=E9s" is French? :-D They are close enough in /this/ case that I could figure out what this was a translation of. :) -Barry From barry@zope.com Thu Mar 14 23:25:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 18:25:03 -0500 Subject: [Mailman-Developers] Bug in Chinese language selections and options page? References: <200203140323.g2E3NoWk029732@utopia.West.Sun.COM> Message-ID: <15505.12623.171701.557645@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> OK, I've got no idea how to browse Chinese; I'm using a DM> Netscape and OS that have no support for the font. That might DM> be the problem. DM> However: if I use my personal subscription options page: DM> http://host.dom.ain/mailman/options/listname/subscribe-addr DM> to change language to "Traditional Chinese" or "Simplified DM> Chinese", I get an expectedly-garbled page, but unfortunately DM> it appears with no "Submit My Changes" button, so if I were DM> unaware that I could use my browser's Back button, I just did DM> something I can't recover from. DM> Is that because my browser is just not capable? Even if so, DM> does this seem bad? I'm using Mozilla and when I do this, I definitely see what look to me like Chinese characters. You're right that the submit button isn't there, but that's because the Chinese templates are woefully out of date. We'll have to make a determination nearer to final release time about which languages are suitable for release and which aren't. -Barry From barry@zope.com Thu Mar 14 23:30:02 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 18:30:02 -0500 Subject: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? References: <OFBF423519.24F5C63E-ON85256B7B.00757A3F@mc.duke.edu> Message-ID: <15505.12922.280551.767707@anthem.wooz.org> >>>>> "JM" == James Madill <James.Madill@duke.edu> writes: JM> Sendmail accepted the encoded document for Mailman, but on JM> sending out, Mailman encountered what it thought was an EOM JM> marker and stopped the processing of the message at that JM> point. Unfortunately, there was still plenty of message left JM> to send, so it was not removed from the queue, and Mailman JM> kept on sending the first portion. >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> Mailman 2.1 has an entirely re-written infrastructure for MIME BG> message handling, and likely has fixed this bug (the old BG> quoted-printable module had some serious flaws and has been BG> re-written). BG> If you could send us a copy of the naughty message, we could BG> test it with Mailman 2.1 from CVS and let you know if the bug BG> has been fixed, but I'll bet that it has been fixed now. I'd still be very surprised if this ends up being a Mailman problem. Python strings don't care at all about end-markers, NULs, etc. so you can't put something in a string that would cause Python to shorten it. And Mailman just uses the file object's read() method to suck the message in from disk, and that just reads the whole file. On writing, Mailman will hand the whole string over to the smtplib module, which itself just blasts the whole thing down the socket connection. I'm much more suspicious of the MTA or some other intermediary bolluxing something up. -Barry From barry@zope.com Thu Mar 14 23:41:26 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 18:41:26 -0500 Subject: [Mailman-Developers] bin/withlist: -i default, remove switch? References: <200203140030.g2E0UqWk019298@utopia.West.Sun.COM> Message-ID: <15505.13606.97376.139295@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> It occurs to me that "bin/withlist <listname>" is pretty DM> useless (what you almost-certainly want is "bin/withlist -i DM> listname"). Would it be reasonable to make -i the default DM> (and thus remove the switch)? That makes sense as long as -r isn't given. Good idea, I'll make that change. Thanks, -Barry From Dan Mick <dmick@utopia.West.Sun.COM> Fri Mar 15 02:35:23 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Thu, 14 Mar 2002 18:35:23 -0800 (PST) Subject: [Mailman-i18n] Re: [Mailman-Developers] Bug in Chinese language selections and options page? Message-ID: <200203150235.g2F2ZTWk023329@utopia.West.Sun.COM> > I am native Chinese speaker, and I have installed mailman-2.0.8 English > version successfully on my > computer, and I want to help building Chinese templates, what should I do > then? 2.1 is the release with multi-lingual support. To help out, subscribe to mailman-i18n@python.org (see http://mail.python.org/mailman/listinfo/mailman-i18n) and volunteer; I'm sure your help would be appreciated. From barry@zope.com Fri Mar 15 03:58:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 22:58:11 -0500 Subject: [Mailman-Developers] moderation... References: <"from Barry A. Warsaw" <barry@zope.com> <5.1.0.14.2.20020312150030.05c3ca70@lennier.cc.vt.edu> <15502.27525.129740.684663@anthem.wooz.org> <5.1.0.14.2.20020313150540.05e18ec0@lennier.cc.vt.edu> Message-ID: <15505.29011.82219.118161@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: >> It probably needs a Rude Solo Light, though. Cheers, -- jra RJ> Bwahah... *I* actually get that :-) Now we divide the people RJ> who do sound engineering from the ones who don't... Heh, I get it. One of the, er, perks of going wireless is that I get to double as the sound guy for the cheap gigs. :) -Barry From barry@zope.com Fri Mar 15 04:22:51 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 23:22:51 -0500 Subject: [Mailman-Developers] moderation... References: <15502.27525.129740.684663@anthem.wooz.org> <B8B3B5B2.1BE9F%chuqui@plaidworks.com> Message-ID: <15505.30491.456719.32132@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: >> - Would you be happy with an emergency switch that applied to >> all postings, from members and non-members alike, even if the >> non-members are on the "accept these non-members" list? CVR> Yes. Sometimes, you need a "time out, let's settle down" CVR> switch. This is in cvs now, complete with Rude Solo Light <wink>. For messages held while in emergency mode, no notifications are sent to the list owner or to the sender (I suspect both would be highly annoying, and no, I don't want to add yet another knob to control this). Messages get through if they have an Approved: header with the list owner or moderator password. That seems to be the only unspoofable token we can rely on. Enjoy, -Barry From barry@zope.com Fri Mar 15 04:31:35 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 14 Mar 2002 23:31:35 -0500 Subject: [Mailman-Developers] On irc tomorrow Message-ID: <15505.31015.890694.593658@anthem.wooz.org> I plan on getting the finishing touches on MM2.1b1 tomorrow, hopefully with a release toward the end of the day. I also plan on spending time on irc.openprojects.net #mailman tomorrow, so if you want to talk about the state of MM2.1, please feel free to join me there by around 10-11am EST. -Barry From jarrell@vt.edu Fri Mar 15 14:19:09 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 15 Mar 2002 09:19:09 -0500 Subject: [Mailman-Developers] moderation... In-Reply-To: <15505.30491.456719.32132@anthem.wooz.org> References: <15502.27525.129740.684663@anthem.wooz.org> <B8B3B5B2.1BE9F%chuqui@plaidworks.com> Message-ID: <5.1.0.14.2.20020315091824.009ffbd0@lennier.cc.vt.edu> At 11:22 PM 3/14/02 -0500, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes: > > >> - Would you be happy with an emergency switch that applied to > >> all postings, from members and non-members alike, even if the > >> non-members are on the "accept these non-members" list? > > CVR> Yes. Sometimes, you need a "time out, let's settle down" > CVR> switch. > >This is in cvs now, complete with Rude Solo Light <wink>. For >messages held while in emergency mode, no notifications are sent to >the list owner or to the sender (I suspect both would be highly >annoying, and no, I don't want to add yet another knob to control >this). > >Messages get through if they have an Approved: header with the list >owner or moderator password. That seems to be the only unspoofable >token we can rely on. Will they still go through if released with the usual mechanism of going to admindb and accepting it? From James.Madill@duke.edu Fri Mar 15 14:35:38 2002 From: James.Madill@duke.edu (James Madill) Date: Fri, 15 Mar 2002 09:35:38 -0500 Subject: [Mailman-Users] Re: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? Message-ID: <OF99F05572.2A0C4C1E-ON85256B7D.004D2990@mc.duke.edu> This is a multipart message in MIME format. --=_alternative 004FFE6E85256B7D_= Content-Type: text/plain; charset="us-ascii" Notes, the originating Mailer of the message in question is also ESMTP. My MTA, sendmail 8.12.1, is an ESMTP mailer, and able to correctly handle a lone period on a line in the middle of an E-mail message. What MTA does Mailman use when DELIVERY_MODULE is set to 'SMTPDirect'? Internal code? I think that what is happening is that the MTA that Mailman is talking to is not told that ESMTP should be used. In doing so, when Mailman writes out to the MTA, the MTA sees the EOM marker and stops accepting data for that message. -- James o o o o o o o . . . _______________________ _______=======_T___ o _____ |James Madill | |Duke Univ Med Ctr| >.][__n_n_| D[ ====|____ |james.madill@duke.edu| | (919) 286-6384 | (________|__|_[____/____]_|_____________________|_|_________________| _/oo O-O-O ` oo oo 'o^o^o o^o^o` 'o^o o^o` -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- <http://www.duke.edu/~madil001/> barry@zope.com (Barry A. Warsaw) Sent by: mailman-users-admin@python.org 03/14/02 18:30 To: "James Madill" <James.Madill@duke.edu> cc: mailman-developers@python.org, Mailman-Users@python.org Subject: [Mailman-Users] Re: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? >>>>> "JM" == James Madill <James.Madill@duke.edu> writes: JM> Sendmail accepted the encoded document for Mailman, but on JM> sending out, Mailman encountered what it thought was an EOM JM> marker and stopped the processing of the message at that JM> point. Unfortunately, there was still plenty of message left JM> to send, so it was not removed from the queue, and Mailman JM> kept on sending the first portion. >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: BG> Mailman 2.1 has an entirely re-written infrastructure for MIME BG> message handling, and likely has fixed this bug (the old BG> quoted-printable module had some serious flaws and has been BG> re-written). BG> If you could send us a copy of the naughty message, we could BG> test it with Mailman 2.1 from CVS and let you know if the bug BG> has been fixed, but I'll bet that it has been fixed now. I'd still be very surprised if this ends up being a Mailman problem. Python strings don't care at all about end-markers, NULs, etc. so you can't put something in a string that would cause Python to shorten it. And Mailman just uses the file object's read() method to suck the message in from disk, and that just reads the whole file. On writing, Mailman will hand the whole string over to the smtplib module, which itself just blasts the whole thing down the socket connection. I'm much more suspicious of the MTA or some other intermediary bolluxing something up. -Barry ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py --=_alternative 004FFE6E85256B7D_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">        Notes, the originating Mailer of the message in question is also ESMTP.  My MTA, sendmail 8.12.1, is an ESMTP mailer, and able to correctly handle a lone period on a line in the middle of an E-mail message.  What MTA does Mailman use when DELIVERY_MODULE is set to 'SMTPDirect'?  Internal code?</font> <br> <br><font size=2 face="sans-serif">        I think that what is happening is that the MTA that Mailman is talking to is not told that ESMTP should be used.  In doing so, when Mailman writes out to the MTA, the MTA sees the EOM marker and stops accepting data for that message.<br> </font><font size=3><tt><br> -- James<br> <br>      </tt></font><font size=3 color=#b0b0b0><tt>o o o o o o o . . .</tt></font><font size=3><tt>   </tt></font><font size=3 color=blue><tt>_______________________</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>_______=======_</tt></font><font size=3><tt>T</tt></font><font size=3 color=red><tt>___</tt></font><font size=3><tt><br>    </tt></font><font size=3 color=#b0b0b0><tt>o</tt></font><font size=3><tt>      _____            </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>James Madill         </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt>Duke Univ Med Ctr</tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br> </tt></font><font size=3 color=#f0c02c><tt>></tt></font><font size=3><tt>.][__n_n_| D[  ====|____  </tt></font><font size=3 color=blue><tt>|</tt></font><font size=3 color=#ff00ff><tt>james.madill@duke.edu</tt></font><font size=3 color=blue><tt>|</tt></font><font size=3><tt> </tt></font><font size=3 color=red><tt>|</tt></font><font size=3 color=#00aa00><tt> (919) 286-6384  </tt></font><font size=3 color=red><tt>|</tt></font><font size=3><tt><br>  (________|__|_[____/____]_</tt></font><font size=3 color=blue><tt>|_____________________|</tt></font><font size=3><tt>_</tt></font><font size=3 color=red><tt>|_________________|</tt></font><font size=3><tt><br> _/oo  O-O-O  `  oo     oo  'o^o^o           o^o^o` 'o^o           o^o`<br> </tt></font><font size=3 color=#b0802c><tt>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-</tt></font><font size=3><tt><br> <http://www.duke.edu/~madil001/></tt></font> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>barry@zope.com (Barry A. Warsaw)</b></font> <br><font size=1 face="sans-serif">Sent by: mailman-users-admin@python.org</font> <p><font size=1 face="sans-serif">03/14/02 18:30</font> <br> <td><font size=1 face="Arial">        </font> <br><font size=1 face="sans-serif">        To:        "James Madill" <James.Madill@duke.edu></font> <br><font size=1 face="sans-serif">        cc:        mailman-developers@python.org, Mailman-Users@python.org</font> <br><font size=1 face="sans-serif">        Subject:        [Mailman-Users] Re: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable?</font></table> <br> <br> <br><font size=2><tt><br> >>>>> "JM" == James Madill <James.Madill@duke.edu> writes:<br> <br>    JM> Sendmail accepted the encoded document for Mailman, but on<br>    JM> sending out, Mailman encountered what it thought was an EOM<br>    JM> marker and stopped the processing of the message at that<br>    JM> point.  Unfortunately, there was still plenty of message left<br>    JM> to send, so it was not removed from the queue, and Mailman<br>    JM> kept on sending the first portion.<br> <br> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes:<br> <br>    BG> Mailman 2.1 has an entirely re-written infrastructure for MIME<br>    BG> message handling, and likely has fixed this bug (the old<br>    BG> quoted-printable module had some serious flaws and has been<br>    BG> re-written).<br> <br>    BG> If you could send us a copy of the naughty message, we could<br>    BG> test it with Mailman 2.1 from CVS and let you know if the bug<br>    BG> has been fixed, but I'll bet that it has been fixed now.<br> <br> I'd still be very surprised if this ends up being a Mailman problem.<br> Python strings don't care at all about end-markers, NULs, etc. so you<br> can't put something in a string that would cause Python to shorten<br> it.  And Mailman just uses the file object's read() method to suck the<br> message in from disk, and that just reads the whole file.  On writing,<br> Mailman will hand the whole string over to the smtplib module, which<br> itself just blasts the whole thing down the socket connection.<br> <br> I'm much more suspicious of the MTA or some other intermediary<br> bolluxing something up.<br> <br> -Barry<br> <br> ------------------------------------------------------<br> Mailman-Users mailing list<br> Mailman-Users@python.org<br> http://mail.python.org/mailman/listinfo/mailman-users<br> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py<br> </tt></font> <br> <br> --=_alternative 004FFE6E85256B7D_=-- From fil@rezo.net Fri Mar 15 14:43:26 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 15:43:26 +0100 Subject: [Mailman-Developers] a bug in current cvs Message-ID: <20020315144326.GA2265@rezo.net> One of my lists is totally dead, and how much I try to revive it it does not come up alive (others are well). All mails sent to the list end up in the shunt/ directory. Web interface fails when sending mail (like 'subscribe' requests)... Here's the error : Mar 15 15:08:08 2002 (25919) Uncaught runner exception: sequence item 0: expect Mar 15 15:08:08 2002 (25919) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipelin sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 86, in process send_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 127, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 211, in send_i18n_dig addresses = getaddresses([msg['From']]) File "/home/mailman/pythonlib/email/Utils.py", line 83, in getaddresses all = COMMASPACE.join(fieldvalues) TypeError: sequence item 0: expected string, None found -- Fil From barry@zope.com Fri Mar 15 15:17:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 10:17:01 -0500 Subject: [Mailman-Developers] moderation... References: <15502.27525.129740.684663@anthem.wooz.org> <B8B3B5B2.1BE9F%chuqui@plaidworks.com> <5.1.0.14.2.20020315091824.009ffbd0@lennier.cc.vt.edu> Message-ID: <15506.4205.612112.746139@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> Will they still go through if released with the usual RJ> mechanism of going to admindb and accepting it? Of course! :) -Barry From barry@zope.com Fri Mar 15 15:23:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 10:23:25 -0500 Subject: [Mailman-Users] Re: [Mailman-Developers] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? References: <OF99F05572.2A0C4C1E-ON85256B7D.004D2990@mc.duke.edu> Message-ID: <15506.4589.231758.141936@anthem.wooz.org> >>>>> "JM" == James Madill <James.Madill@duke.edu> writes: JM> Notes, the originating Mailer of the message in JM> question is also ESMTP. My MTA, sendmail 8.12.1, is an ESMTP JM> mailer, and able to correctly handle a lone period on a line JM> in the middle of an E-mail message. What MTA does Mailman use JM> when DELIVERY_MODULE is set to 'SMTPDirect'? Internal code? It talks to whatever MTA is listening on port 25, localhost (by default). Mailman does not include MTA functionality; it's designed to hand the message off to a real MTA for final delivery. JM> I think that what is happening is that the MTA that JM> Mailman is talking to is not told that ESMTP should be used. JM> In doing so, when Mailman writes out to the MTA, the MTA sees JM> the EOM marker and stops accepting data for that message. Then it has to be your sendmail 8.12.1 MTA, because that's what Mailman is talking to. Note that Python's smtplib -- which is the module Mailman uses to talk to the MTA -- is designed to try EHLO first and fall back to HELO only if the former fails. Sounds like something's not kosher with your sendmail installation. -Barry From barry@zope.com Fri Mar 15 15:44:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 10:44:27 -0500 Subject: [Mailman-Developers] a bug in current cvs References: <20020315144326.GA2265@rezo.net> Message-ID: <15506.5851.102566.34170@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> One of my lists is totally dead, and how much I try to revive F> it it does not come up alive (others are well). All mails sent F> to the list end up in the shunt/ directory. Web interface fails F> when sending mail (like 'subscribe' requests)... F> TypeError: sequence item 0: expected string, None found The only way I can see this happening is if your messages have no From: header. That's anti-RFC and pretty broken, but here's a patch that should at least avoid the tracebacks in that situation. Give it a try. -Barry Index: ToDigest.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/ToDigest.py,v retrieving revision 2.15 diff -u -u -r2.15 ToDigest.py --- ToDigest.py 19 Dec 2001 07:03:22 -0000 2.15 +++ ToDigest.py 15 Mar 2002 15:44:22 -0000 @@ -208,7 +208,7 @@ subject, re.IGNORECASE) if mo: subject = subject[:mo.start(2)] + subject[mo.end(2):] - addresses = getaddresses([msg['From']]) + addresses = getaddresses([msg.get('From', '')]) username = '' # Take only the first author we find if type(addresses) is ListType and len(addresses) > 0: From fil@rezo.net Fri Mar 15 15:45:50 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 16:45:50 +0100 Subject: [Mailman-Developers] is it me? Message-ID: <20020315154550.GB13758@rezo.net> Am I the only stupid guy running mailman cvs on a server with many lists? ;-) Here's another bug Mar 15 16:42:21 2002 (6105) Unexpected Mailman error: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 272, in ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 720, in ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmation addr = userdesc.address AttributeError: address -- Fil From wheakory@isu.edu Fri Mar 15 15:46:34 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Fri, 15 Mar 2002 08:46:34 -0700 Subject: [Mailman-Developers] clean install of mailman-2.1a4 Message-ID: <3C92175A.6356703@isu.edu> I did a clean install of mailman-2.1a4 and the web interface is working fine, but I'm having problems with sending messages. I'm running Red Hat 7.2 with Python 2.2 and sendmail 8.11. My aliases for the list I created are correct. I changed the symbolic link in /etc/smrsh to point to mailman rather than wrapper. Here is the following error, I hope I can get some feedback on the solution to the problem. Mar 14 15:38:46 2002 (15583) Uncaught runner exception: please run connect() first Mar 14 15:38:46 2002 (15583) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 101, in process conn.quit() File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 671, in quit self.docmd("quit") File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 352, in docmd self.putcmd(cmd,args) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 308, in putcmd self.send(str) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 300, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first Mar 14 15:52:54 2002 (15583) Uncaught runner exception: please run connect() first Mar 14 15:52:54 2002 (15583) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 101, in process conn.quit() File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 671, in quit self.docmd("quit") File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 352, in docmd self.putcmd(cmd,args) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 308, in putcmd self.send(str) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 300, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From fil@rezo.net Fri Mar 15 16:31:23 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 17:31:23 +0100 Subject: [Mailman-Developers] and another assert error Message-ID: <20020315163123.GH17354@rezo.net> When posting to a moderateed list (current cvs) Mar 15 17:30:17 2002 (15303) Uncaught runner exception: Mar 15 17:30:17 2002 (15303) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 103, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 153, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Moderate.py", line 58, in process ModeratedMemberPost) File "/home/mailman/Mailman/Handlers/Hold.py", line 193, in hold_for_approval id = mlist.HoldMessage(msg, reason, msgdata) File "/home/mailman/Mailman/ListAdmin.py", line 199, in HoldMessage assert not self.__db.has_key(id) AssertionError -- Fil From fil@rezo.net Fri Mar 15 17:27:03 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 18:27:03 +0100 Subject: [Mailman-Developers] timeout error with mail processing?? Message-ID: <20020315172703.GH23021@rezo.net> I'm confident you should not raise a TimeOutError when processing email: it times out, just requeue the mail for processing another time... ==> logs/error <== Mar 15 18:24:59 2002 (29373) Unexpected Mailman error: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 272, in ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 720, in ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 968, in ProcessConfirmation data = Pending.confirm(cookie) File "/home/mailman/Mailman/Pending.py", line 94, in confirm lock.lock(timeout=30) File "/home/mailman/Mailman/LockFile.py", line 292, in lock raise TimeOutError TimeOutError -- Fil From barry@zope.com Fri Mar 15 17:37:09 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 12:37:09 -0500 Subject: [Mailman-Developers] timeout error with mail processing?? References: <20020315172703.GH23021@rezo.net> Message-ID: <15506.12613.531965.711445@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I'm confident you should not raise a TimeOutError when F> processing email: it times out, just requeue the mail for F> processing another time... -Barry Index: CommandRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/CommandRunner.py,v retrieving revision 2.11 diff -u -u -r2.11 CommandRunner.py --- CommandRunner.py 14 Mar 2002 05:02:30 -0000 2.11 +++ CommandRunner.py 15 Mar 2002 17:36:51 -0000 @@ -67,7 +67,12 @@ del msg['subject'] msg['Subject'] = 'leave' msg.set_payload('') - mlist.ParseMailCommands(msg, msgdata) + try: + mlist.ParseMailCommands(msg, msgdata) + except LockFile.TimeOutError: + # We probably could not get the lock on the pending + # database. That's okay, we'll just try again later. + return 1 elif msgdata.get('toconfirm'): mo = re.match(mm_cfg.VERP_CONFIRM_REGEXP, msg.get('to', '')) if mo: From fil@rezo.net Fri Mar 15 17:50:47 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 18:50:47 +0100 Subject: [Mailman-Developers] timeout error with mail processing?? In-Reply-To: <15506.12613.531965.711445@anthem.wooz.org> References: <20020315172703.GH23021@rezo.net> <15506.12613.531965.711445@anthem.wooz.org> Message-ID: <20020315175047.GA974@rezo.net> Shouldn't it rather be implemented inside ParseMailCommands()? > F> I'm confident you should not raise a TimeOutError when > F> processing email: it times out, just requeue the mail for > F> processing another time... > Index: CommandRunner.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Queue/CommandRunner.py,v > retrieving revision 2.11 > diff -u -u -r2.11 CommandRunner.py > --- CommandRunner.py 14 Mar 2002 05:02:30 -0000 2.11 > +++ CommandRunner.py 15 Mar 2002 17:36:51 -0000 > @@ -67,7 +67,12 @@ > del msg['subject'] > msg['Subject'] = 'leave' > msg.set_payload('') > - mlist.ParseMailCommands(msg, msgdata) > + try: > + mlist.ParseMailCommands(msg, msgdata) > + except LockFile.TimeOutError: > + # We probably could not get the lock on the pending > + # database. That's okay, we'll just try again later. > + return 1 > elif msgdata.get('toconfirm'): > mo = re.match(mm_cfg.VERP_CONFIRM_REGEXP, msg.get('to', '')) > if mo: -- Fil From barry@zope.com Fri Mar 15 17:53:10 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 12:53:10 -0500 Subject: [Mailman-Developers] timeout error with mail processing?? References: <20020315172703.GH23021@rezo.net> <15506.12613.531965.711445@anthem.wooz.org> <20020315175047.GA974@rezo.net> Message-ID: <15506.13574.971894.245231@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Shouldn't it rather be implemented inside ParseMailCommands()? Not really, since there's no way to get a return value out of ParseMailCommands() so that the runner knows to re-queue the message for another try later. -Barry From fil@rezo.net Fri Mar 15 17:54:23 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 18:54:23 +0100 Subject: [Mailman-Developers] timeout error with mail processing?? In-Reply-To: <15506.13574.971894.245231@anthem.wooz.org> References: <20020315172703.GH23021@rezo.net> <15506.12613.531965.711445@anthem.wooz.org> <20020315175047.GA974@rezo.net> <15506.13574.971894.245231@anthem.wooz.org> Message-ID: <20020315175422.GC974@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > F> Shouldn't it rather be implemented inside ParseMailCommands()? > > Not really, since there's no way to get a return value out of > ParseMailCommands() so that the runner knows to re-queue the message > for another try later. I meant: why do you add it only to the 'toleave' action? -- Fil From barry@zope.com Fri Mar 15 17:57:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 12:57:41 -0500 Subject: [Mailman-Developers] big list References: <20020308162458.GE27629@rezo.net> <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> Message-ID: <15506.13845.751655.436090@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Yes, it's working again. Thank you! F> However the other bug came back: did you not commit the F> correction? >> "/home/mailman/Mailman/OldStyleMemberships.py", line 120, in F> getMemberOption >> self.__assertIsMember(member) File >> "/home/mailman/Mailman/OldStyleMemberships.py", line 113, in | __assertIsMember | raise Errors.NotAMemberError, member Nope, this one is definitely in versions.py 2.25. In fact it was committed in revision 2.22 on 09-Mar-2002. -Barry ---------------------------- revision 2.22 date: 2002/03/09 19:11:27; author: bwarsaw; state: Exp; lines: +9 -0 CanonicalizeUserOptions(): Two changes. First, when migrating user_options, skip the key if its not a member. This can happen when upgrading legacy databases because I believe there were bugs long ago that caused some keys to appear in user_options but not in members or digest_members. Also, we now have a mini-version id for the user_options stuff so CanonicalizeUserOptions() won't try to run every time some other part of the schema changes. From barry@zope.com Fri Mar 15 17:58:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 12:58:42 -0500 Subject: [Mailman-Developers] big list References: <15497.26292.681882.2706@anthem.wooz.org> <20020309124033.GA31620@rezo.net> <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> <20020312093111.GA7691@rezo.net> Message-ID: <15506.13906.500062.189950@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> In the logs I now have this kind of things re: F> OldStyleMemberships Are you positive you're up-to-date in cvs? No sticky tags? -Barry From barry@zope.com Fri Mar 15 17:59:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 12:59:42 -0500 Subject: [Mailman-Developers] timeout error with mail processing?? References: <20020315172703.GH23021@rezo.net> <15506.12613.531965.711445@anthem.wooz.org> <20020315175047.GA974@rezo.net> <15506.13574.971894.245231@anthem.wooz.org> <20020315175422.GC974@rezo.net> Message-ID: <15506.13966.901975.106473@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I meant: why do you add it only to the 'toleave' action? Boink! Good catch. ;) From fil@rezo.net Fri Mar 15 18:11:55 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 19:11:55 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15506.13906.500062.189950@anthem.wooz.org> References: <20020309144735.GB12353@rezo.net> <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> <20020312093111.GA7691@rezo.net> <15506.13906.500062.189950@anthem.wooz.org> Message-ID: <20020315181155.GE974@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > Are you positive you're up-to-date in cvs? No sticky tags? Don't know for sure. I had three files in status "Need Patch". I'll checkout a brand new version, and keep you posted if some bug comes up again. -- Fil From wheakory@isu.edu Fri Mar 15 18:17:29 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Fri, 15 Mar 2002 11:17:29 -0700 Subject: [Mailman-Developers] clean install of mailman-2.1a4 Message-ID: <3C923AB9.762216C1@isu.edu> I did a clean install of mailman-2.1a4 and the web interface is working fine, but I'm having problems with sending messages. I'm running Red Hat 7.2 with Python 2.2 and sendmail 8.11. My aliases for the list I created are correct. I changed the symbolic link in /etc/smrsh to point to mailman rather than wrapper. Here is the following error, I hope I can get some feedback on the solution to the problem. Mar 14 15:38:46 2002 (15583) Uncaught runner exception: please run connect() first Mar 14 15:38:46 2002 (15583) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 101, in process conn.quit() File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 671, in quit self.docmd("quit") File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 352, in docmd self.putcmd(cmd,args) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 308, in putcmd self.send(str) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 300, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first Mar 14 15:52:54 2002 (15583) Uncaught runner exception: please run connect() first Mar 14 15:52:54 2002 (15583) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 101, in process conn.quit() File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 671, in quit self.docmd("quit") File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 352, in docmd self.putcmd(cmd,args) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 308, in putcmd self.send(str) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/smtplib.py", line 300, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From barry@zope.com Fri Mar 15 18:25:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 13:25:54 -0500 Subject: [Mailman-Developers] clean install of mailman-2.1a4 References: <3C923AB9.762216C1@isu.edu> Message-ID: <15506.15538.841930.838834@anthem.wooz.org> >>>>> "KW" == Kory Wheatley <wheakory@isu.edu> writes: KW> I did a clean install of mailman-2.1a4 and the web interface KW> is working fine, but I'm having problems with sending KW> messages. I'm running Red Hat 7.2 with Python 2.2 and sendmail KW> 8.11. My aliases for the list I created are correct. I changed KW> the symbolic link in /etc/smrsh to point to mailman rather KW> than wrapper. Try doing an install of MM2.1cvs, or wait a few hours for MM2.1beta1. Then see if you still have problems. -Barry From fil@rezo.net Fri Mar 15 18:42:35 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 19:42:35 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <20020315181155.GE974@rezo.net> References: <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> <20020312093111.GA7691@rezo.net> <15506.13906.500062.189950@anthem.wooz.org> <20020315181155.GE974@rezo.net> Message-ID: <20020315184235.GA16337@rezo.net> @ Fil <fil@rezo.net> : > Don't know for sure. I had three files in status "Need Patch". I'll checkout > a brand new version, and keep you posted if some bug comes up again. I am ashamed: "cvs update" did me no good; some scripts were up-to-date, others definitely not. Now everything's a clean install, I'll let the week-end go without a post to the -developpers list. -- Fil From barry@zope.com Fri Mar 15 19:25:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 14:25:12 -0500 Subject: [Mailman-Developers] big list References: <15498.19452.486537.764090@anthem.wooz.org> <20020310002227.GA9790@rezo.net> <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> <20020312093111.GA7691@rezo.net> <15506.13906.500062.189950@anthem.wooz.org> <20020315181155.GE974@rezo.net> <20020315184235.GA16337@rezo.net> Message-ID: <15506.19096.191205.554772@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I am ashamed: "cvs update" did me no good; some scripts were F> up-to-date, others definitely not. Now everything's a clean F> install, I'll let the week-end go without a post to the F> -developpers list. :) -Barry From rodolfo@pilas.net Thu Mar 7 17:37:17 2002 From: rodolfo@pilas.net (Rodolfo Pilas) Date: 07 Mar 2002 14:37:17 -0300 Subject: [Mailman-Developers] Unsubscribe through the web Message-ID: <1015522644.3541.41.camel@julieta> [I use 2.1a4+ updated today from CVS] It is not possible to unsubscribe through a listinfo page. When you try tu unsubscribe through the listinfo page with: #: Mailman/HTMLFormatter.py:253 msgid "Unsubscribe or edit options" You access to this form: (something I paste in English, from .po file to your guide, but I use MM in Spanish) <FORM Method=3DPOST ACTION=3D"../subscribe/test"> To unsubscribe from Test, get a password reminder, or change your subscription options %(either)senter your subscription email address: <p><center> <INPUT name=3D"email" type=3D"TEXT" value=3D"" size=3D"30"> <INPUT name=3D"UserOptions" type=3D"SUBMIT" value=3D"Anular su subscripc= i=F3n o editar sus preferencias" ><INPUT name=3D"language" type=3D"HIDDEN" value=3D"es"></center>Si dejas el campo en blanco, se te preguntar=E1 tu direcci=F3n de correo electr=F3nico </FORM> And receive the following message: #: Mailman/Cgi/subscribe.py:167 msgid "" "Your subscription request has been received, and will soon be acted upon.\n" "Depending on the configuration of this mailing list, your subscription " "request\n" "may have to be first confirmed by you via email, or approved by the list\n" "moderator. If confirmation is required, you will soon get a confirmation\n" "email which contains further instructions." I understand that there is a problem here: <FORM Method=3DPOST ACTION=3D"../subscribe/test"> perhaps it may be <FORM Method=3DPOST ACTION=3D"../unsubscribe/test"> --=20 Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@pilas.net Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=3D# Apocalipsis Now % Cuarteto de Nos #=3D- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint =3D DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From rodolfo.pilas@abitab.com.uy Thu Mar 7 17:46:56 2002 From: rodolfo.pilas@abitab.com.uy (Rodolfo Pilas) Date: 07 Mar 2002 14:46:56 -0300 Subject: [Mailman-Developers] Unsubscribe confirmation message Message-ID: <1015523216.3541.48.camel@julieta> [MM 2.1a4+ uptdated from CVS today] When I sent a message to test-leave@mydomain.com I receive a confirmation of unsubscription, but the message macros have not been replaced propertly. -----Mensaje reenviado----- From: test-request@mydomain.com To: rodolfo.pilas@mydomain.com Subject: confirm 7b48481651194c40f4c1488e7d8ad16499e45d0a Date: 07 Mar 2002 14:44:12 -0300 Mensaje de confirmaci=F3n para la anulaci=F3n de la subscripci=F3n a la lista de distribuci=F3n %(listname)s Se ha recibido una solicitud %(remote) para quitar su direcci=F3n de correo electr=F3nico "%(email)s" de la lista de distribuci=F3n %(listaddr)s. Para confirmar que quiere borrarse de esta lista de distribuci=F3n, solo tiene que responder este mensaje, manteniendo intacta la cabecera del asunto (Subject). O visite esta p=E1gina web: %(confirmurl)s O incluya la l=EDnea siguiente -- y solo la l=EDnea siguiente -- en un mensaje dirijido a %(requestaddr)s: confirm %(cookie)s Responder este mensaje deber=EDa funcionar con la mayor=EDa de los programas de correo electr=F3nico, porque normalmente dejan de una forma v=E1lida la l=EDnea del Asunto (el texto adicional Re: en el asunto es correcto) Si no desea borrarse de esta lista de distribuci=F3n, solo tiene que ignorar este mensaje. Si piensa que alguien quiere borrarle de la lista malintencionadamente o si tiene cualquier otra cuesti=F3n, m=E1ndelas al administrador de la lista a la direcci=F3n %(listadmin)s. From valites@geneseo.edu Fri Mar 8 02:59:48 2002 From: valites@geneseo.edu (Mark T. Valites) Date: Thu, 7 Mar 2002 21:59:48 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Can you set a list's password via the command line? In-Reply-To: <OF58C7F85E.CA4DC9EA-ON85256B76.000E9934@mc.duke.edu> Message-ID: <8D3B6E8D-3240-11D6-8B03-00039319DA20@geneseo.edu> --Apple-Mail-1-741966281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed I replied off the list last to to a similar post. When I moved my ~475=20= lists, I hit the same problem. What I ended up doing was: foreach list in lists do dumpdb $list/config.db | grep admin_password_line | some awk (to=20= rip out the password column) | some sed (to get rid of some funky=20 characters) > $listname_file done foreach list in lists do config_list -i $listname_file done This worked fairly well. 40 or so out of the ~475 at the time didn't=20 take & I had to manually fix the files, or just reset the passwords. It=20= wasn't that hard, and I just did it all from the shell prompt, but I=20 might be able to dig it up if you really need me to. I am of course, interested in a more *proper* way of doing this. On Thursday, March 7, 2002, at 09:43 PM, James Madill wrote: > > In moving the 175 mailing lists from one machine (version 2.0.1) =A0to=20= > another (version 2.0.8), all of the list passwords are no longer=20 > working. > > Is there a way to set a list's password via the command line? =A0I'd = hate=20 > to have to manually set each one & send it to the list admin(s). > > -- James > > =A0 =A0 =A0o o o o o o o . . . =A0 _______________________ = _______=3D=3D=3D=3D=3D=3D=3D_T___ > =A0 =A0o =A0 =A0 =A0_____ =A0 =A0 =A0 =A0 =A0 =A0|James Madill =A0 =A0 = =A0 =A0 | |Duke Univ Med Ctr| > >.][__n_n_| D[ =A0=3D=3D=3D=3D|____ =A0|james.madill@duke.edu| | (919) = 286-6384 =A0| > =A0(________|__|_[____/____]_|_____________________|_|_________________|= > _/oo =A0O-O-O =A0` =A0oo =A0 =A0 oo =A0'o^o^o =A0 =A0 =A0 =A0 =A0 = o^o^o` 'o^o =A0 =A0 =A0 =A0 =A0 o^o` > = -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > <http://www.duke.edu/~madil001/> >--))> >--))> Mark T. Valites Unix Systems Analyst 1 College Circle - 124b1 South Hall SUNY Geneseo Geneseo, NY 14454 585-245-5577 585-259-3471(Cell) --Apple-Mail-1-741966281 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 I replied off the list last to to a similar post. When I moved my ~475 lists, I hit the same problem. What I ended up doing was: foreach list in lists do=20 dumpdb $list/config.db | grep admin_password_line | some awk (to = rip out the password column) | some sed (to get rid of some funky characters) > $listname_file=20 done foreach list in lists do config_list -i $listname_file done This worked fairly well. 40 or so out of the ~475 at the time didn't take & I had to manually fix the files, or just reset the passwords.=20 It wasn't that hard, and I just did it all from the shell prompt, but I might be able to dig it up if you really need me to. I am of course, interested in a more *proper* way of doing this. On Thursday, March 7, 2002, at 09:43 PM, James Madill wrote: <excerpt> <smaller>In moving the 175 mailing lists from one machine (version 2.0.1) =A0to another (version 2.0.8), all of the list passwords are no longer working. Is there a way to set a list's password via the command line? =A0I'd hate to have to manually set each one & send it to the list admin(s). </smaller><fixed><bigger>-- James =A0 =A0 =A0<color><param>B0B0,B0B0,B0B0</param>o o o o o o o . . = .</color> =A0 <color><param>0000,0000,FFFF</param>_______________________</color> = <color><param>FFFF,0000,0000</param>_______=3D=3D=3D=3D=3D=3D=3D_</color>T= <color><param>FFFF,0000,0000</param>___ </color>=A0 =A0<color><param>B0B0,B0B0,B0B0</param>o</color> =A0 =A0 = =A0_____ =A0 =A0 =A0 =A0 =A0 = =A0<color><param>0000,0000,FFFF</param>|</color><color><param>FFFF,0000,FF= FF</param>James Madill =A0 =A0 =A0 =A0 = </color><color><param>0000,0000,FFFF</param>|</color> = <color><param>FFFF,0000,0000</param>|</color><color><param>0000,AAAA,0000<= /param>Duke Univ Med Ctr</color><color><param>FFFF,0000,0000</param>| </color><color><param>F0F0,C0C0,2C2C</param>></color>.][__n_n_| D[ =A0=3D=3D=3D=3D|____ = =A0<color><param>0000,0000,FFFF</param>|</color><color><param>FFFF,0000,FF= FF</param>james.madill@duke.edu</color><color><param>0000,0000,FFFF</param= >|</color> = <color><param>FFFF,0000,0000</param>|</color><color><param>0000,AAAA,0000<= /param> (919) 286-6384 =A0</color><color><param>FFFF,0000,0000</param>| = </color>=A0(________|__|_[____/____]_<color><param>0000,0000,FFFF</param>|= _____________________|</color>_<color><param>FFFF,0000,0000</param>|______= ___________| </color>_/oo =A0O-O-O =A0` =A0oo =A0 =A0 oo =A0'o^o^o =A0 =A0 =A0 =A0 =A0 = o^o^o` 'o^o =A0 =A0 =A0 =A0 =A0 o^o` = <color><param>B0B0,8080,2C2C</param>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- </color><<http://www.duke.edu/~madil001/> </bigger></fixed></excerpt>>--))> >--))> Mark T. Valites Unix Systems Analyst 1 College Circle - 124b1 South Hall SUNY Geneseo Geneseo, NY 14454 585-245-5577 585-259-3471(Cell)= --Apple-Mail-1-741966281-- From kall@cox-internet.com Sat Mar 9 21:17:21 2002 From: kall@cox-internet.com (Loren Kallwick) Date: Sat, 9 Mar 2002 15:17:21 -0600 Subject: [Mailman-Developers] mailman for windows xp Message-ID: <000801c1c7af$ce08c510$9bd5b4d0@leaddog> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1C77D.8253BD50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I looked around and could'nt find anyone working on making mailman work = on XP. Can you tell me if anyone has come up with something? Loren ------=_NextPart_000_0005_01C1C77D.8253BD50 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dwindows-1252"> <META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3D"Times New Roman" size=3D2>I looked around and = could'nt find=20 anyone working on making mailman work on XP.</FONT></DIV> <DIV>Can you tell me if anyone has come up with something?</DIV> <DIV>Loren</DIV></BODY></HTML> ------=_NextPart_000_0005_01C1C77D.8253BD50-- From njs@scifi.squawk.com Mon Mar 11 04:18:40 2002 From: njs@scifi.squawk.com (Nick Simicich) Date: Sun, 10 Mar 2002 23:18:40 -0500 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <87vgc3g7k3.fsf@nausicaa.interq.or.jp> References: <p05101500b8b15039f30f@[207.149.192.229]> <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <p05101500b8b15039f30f@[207.149.192.229]> Message-ID: <5.1.0.14.2.20020310223835.05439cc0@127.0.0.1> All headers should not be case sensitive, so far as I know. This is right out of RFC822: > 3.4.7. CASE INDEPENDENCE > > Except as noted, alphabetic strings may be represented in any > combination of upper and lower case. The only syntactic units > > August 13, 1982 - 14 - RFC #822 > > Standard for ARPA Internet Text Messages > > which requires preservation of case information are: > > - text > - qtext > - dtext > - ctext > - quoted-pair > - local-part, except "Postmaster" Unless I am mistaken, this does not define any fields or sub-field names as case dependent. Those comparisons should all be done independent of case. Now if you are noting that the subject field is case independent, then you are probably right, subject is defined as "text". At 11:30 AM 2002-03-11 +0900, Ben Gertzfield wrote: > >>>>> "John" == John W Baxter <John> writes: > > John> You're posting as > > John> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > > John> Question for the gurus: could the upper case content type > John> description be causing problems here? > >It very well could be. The problem is that *some* headers >are case-sensitive (like Subject) and others are not >(like Content-Type). I haven't been putting in random >.lower() calls on every string, so we'll probably run >into some of these issues. > >Barry, do you think the email module should just deal with >this somehow? > >Ben > >-- >Brought to you by the letters L and H and the number 3. >"Frungy! Frungy! Frungy!!" >Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers -- War is an ugly thing, but it is not the ugliest of things. The decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight, nothing he cares about more than his own personal safety, is a miserable creature who has no chance of being free, unless made so by the exertions of better men than himself. -- John Stuart Mill Nick Simicich - njs@scifi.squawk.com From wheakory@isu.edu Tue Mar 12 15:51:55 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 12 Mar 2002 08:51:55 -0700 Subject: [Mailman-Developers] Privacy roster setting Message-ID: <3C8E241B.C3677CC1@isu.edu> I want to know if there's a way to change all my lists that have the setting to "view subscribers (set to anyone)" and change it to (List admin only). I did make the change today in the mm_cfg.py file, but that's only for new lists. How do I change the settings to all the lists at the command line. Do I need to use "config_list" if so, how? -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From waller@osb1.wff.nasa.gov Thu Mar 14 12:29:22 2002 From: waller@osb1.wff.nasa.gov (Alan L. Waller) Date: Thu, 14 Mar 2002 07:29:22 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Mailman can't handle MIME: Content-transfer-encoding: quoted-printable? In-Reply-To: <OFBF423519.24F5C63E-ON85256B7B.00757A3F@mc.duke.edu> Message-ID: <5.1.0.14.2.20020314072532.00ac81d8@osb.wff.nasa.gov> That sounds very much like a problem I just corrected. The receiving end was behind a Cisco PIX firewall and a bug in the PIX causes this. Search Google groups for sendmail + multiple +pix for the complete story. Al At 04:40 PM 3/13/2002 -0500, James Madill wrote: >Users of one of my mailing lists got a nasty surprise when a posted >message was repeatedly sent to them. > >I traced the problem down to an instance of the standard End-Of-Message >marker (a lone period on a line) in the middle of the posted message. > >The posted message contained extended ASCII characters encoded using the >MIME Content-transfer-encoding: quoted-printable format. There was what >appeared to be soft returns at column 72. This message happened to have a >paragraph that ended on column 73, so the "soft return" resulted in the >period alone on the next line. > >Sendmail accepted the encoded document for Mailman, but on sending out, >Mailman encountered what it thought was an EOM marker and stopped the >processing of the message at that point. Unfortunately, there was still >plenty of message left to send, so it was not removed from the queue, and >Mailman kept on sending the first portion. > >The smtp daemon is sendmail 8.12.1. Mailman is version 2.0.8 with >DELIVERY_MODULE = 'SMTPDirect' in Defaults.py. > >Am I missing some Mailman switch to tell it to recognize messages with the >Content-transfer-encoding: quoted-printable tag? > >-- James > > o o o o o o o . . . _______________________ _______=======_T___ > o _____ |James Madill | |Duke Univ Med Ctr| > >.][__n_n_| D[ ====|____ |james.madill@duke.edu| | (919) 286-6384 | > (________|__|_[____/____]_|_____________________|_|_________________| >_/oo O-O-O ` oo oo 'o^o^o o^o^o` 'o^o o^o` >-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ><http://www.duke.edu/~madil001/> From wheakory@isu.edu Thu Mar 14 13:24:07 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Thu, 14 Mar 2002 08:24:07 -0500 Subject: [Mailman-Developers] Upgrading from mailman-2.0.8 to mailman-2.1a4 Message-ID: <3C90A477.2BF6552F@isu.edu> I recently tried to upgrade from mailman-2.0.8 to mailman-2.1a4 , ( I have python 2.2 installed on Red Hat 7.2 ) I received this error below. I'm not too efficient in debugging Python code yet. Can you recognize the problem? Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 58, in? from Mailman.SecurityManager import SecurityManager File "/home/mailman/Maillman/SecurityManager.py", line 62, in ? from Cookie import SimpleCookie as Cookie ImportError: cannot import name SimpleCookie make: *** [update] Error 1 Thanks for your help in advance. Kory Wheatley Computing & Communication Idaho State University From fil@rezo.net Thu Mar 14 18:25:50 2002 From: fil@rezo.net (Fil) Date: Thu, 14 Mar 2002 19:25:50 +0100 Subject: [Mailman-Developers] Re: BounceRunner eating up alot of memory In-Reply-To: <15504.56471.867709.715156@anthem.wooz.org> References: <20020312094434.GB7691@rezo.net> <15504.56471.867709.715156@anthem.wooz.org> Message-ID: <20020314182550.GA32435@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > This bug, at least, should now be gone. What about this one? Should I continue sending these reports as I stumble on them? Mar 14 19:05:28 2002 (25919) Uncaught runner exception: sequence item 0: expect Mar 14 19:05:28 2002 (25919) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipelin sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 86, in process send_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 127, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 211, in send_i18n_dig addresses = getaddresses([msg['From']]) File "/home/mailman/pythonlib/email/Utils.py", line 83, in getaddresses all = COMMASPACE.join(fieldvalues) TypeError: sequence item 0: expected string, None found -- Fil From max.yu@turbolinux.com.cn Fri Mar 15 02:14:37 2002 From: max.yu@turbolinux.com.cn (Max Yu) Date: Fri, 15 Mar 2002 10:14:37 +0800 Subject: [Mailman-i18n] Re: [Mailman-Developers] Bug in Chinese language selections and options page? References: <200203140323.g2E3NoWk029732@utopia.West.Sun.COM> <15505.12623.171701.557645@anthem.wooz.org> Message-ID: <3C91590D.3D756E47@turbolinux.com.cn> I am native Chinese speaker, and I have installed mailman-2.0.8 English version successfully on my computer, and I want to help building Chinese templates, what should I do then? Thanks for your attention. Best Regards Max Yu "Barry A. Warsaw" =D0=B4=B5=C0=A3=BA > >>>>> "DM" =3D=3D Dan Mick <dmick@utopia.West.Sun.COM> writes: > > DM> OK, I've got no idea how to browse Chinese; I'm using a > DM> Netscape and OS that have no support for the font. That might > DM> be the problem. > > DM> However: if I use my personal subscription options page: > > DM> http://host.dom.ain/mailman/options/listname/subscribe-addr > > DM> to change language to "Traditional Chinese" or "Simplified > DM> Chinese", I get an expectedly-garbled page, but unfortunately > DM> it appears with no "Submit My Changes" button, so if I were > DM> unaware that I could use my browser's Back button, I just did > DM> something I can't recover from. > > DM> Is that because my browser is just not capable? Even if so, > DM> does this seem bad? > > I'm using Mozilla and when I do this, I definitely see what look to me > like Chinese characters. You're right that the submit button isn't > there, but that's because the Chinese templates are woefully out of > date. > > We'll have to make a determination nearer to final release time about > which languages are suitable for release and which aren't. > > -Barry > > _______________________________________________ > Mailman-i18n mailing list > Mailman-i18n@python.org > http://mail.python.org/mailman/listinfo/mailman-i18n From fil@rezo.net Fri Mar 15 10:14:27 2002 From: fil@rezo.net (Fil) Date: Fri, 15 Mar 2002 11:14:27 +0100 Subject: [Mailman-Developers] another idea to limit disk usage Message-ID: <20020315101427.GA29079@rezo.net> Another idea to limit disk usage: shouldn't the "mail/mailman bounces listname" cut the messages it receives 10 lines or so after any "Errors-To: listname.*" line it encounters ? You wouldn't lose interesting data I guess... -- Fil From alex@phred.org Mon Mar 11 21:03:14 2002 From: alex@phred.org (alex wetmore) Date: Mon, 11 Mar 2002 13:03:14 -0800 (PST) Subject: [Mailman-Developers] Re: [Mailman-Users] Feedback needed: nodupes patch and reply-to munging per user In-Reply-To: <20020311204127.GE23754@merlins.org> Message-ID: <20020311130221.N53579-100000@phred.org> On Mon, 11 Mar 2002, Marc MERLIN wrote: > The idea was to settle this issue for good by offering, in place of listwide > reply-to munging (which would still be an option in mailman, just not one > that most people would need anymore): > - optional non sending of list posts if you are Cced so that you don't get > two copies (nodupes patch, already in CVS) I think that this is a great feature, and it is something which I would use on mailman. Can you provide information on the extra processing that it requires? It doesn't do anything crazy like send a message per recipient to the MTA, does it? alex From rodolfo@pilas.net Fri Mar 15 19:54:52 2002 From: rodolfo@pilas.net (Rodolfo Pilas) Date: 15 Mar 2002 16:54:52 -0300 Subject: [Mailman-Developers] is it me? In-Reply-To: <20020315154550.GB13758@rezo.net> References: <20020315154550.GB13758@rezo.net> Message-ID: <1016222101.2450.23.camel@julieta> El vie, 15-03-2002 a las 12:45, Fil escribi=F3: >=20 > Am I the only stupid guy running mailman cvs on a server with many lists? > ;-) Nooo, there are two guys! (I am the other) >=20 > Here's another bug=20 >=20 > Mar 15 16:42:21 2002 (6105) Unexpected Mailman error: > Traceback (most recent call last): > File "/home/mailman/Mailman/MailCommandHandler.py", line 272, in > ParseMailCommands > self.__dispatch[cmd](args, line, msg) > File "/home/mailman/Mailman/MailCommandHandler.py", line 720, in > ProcessConfirmCmd > results =3D self.ProcessConfirmation(args[0], msg) > File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmat= ion > addr =3D userdesc.address > AttributeError: address >=20 Here is my daily message: Traceback (most recent call last): File "/usr/lib/mailman/cron/checkdbs", line 104, in ? main() File "/usr/lib/mailman/cron/checkdbs", line 67, in main text =3D text + '\n' + pending_requests(mlist) File "/usr/lib/mailman/cron/checkdbs", line 82, in pending_requests when, addr, passwd, digest, lang =3D mlist.GetRecord(id) ValueError: unpack tuple of wrong size ..... well I am waiting the b1 now... ;) ;) --=20 Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@pilas.net Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=3D# Apocalipsis Now % Cuarteto de Nos #=3D- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint =3D DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Fri Mar 15 19:59:04 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 14:59:04 -0500 Subject: [Mailman-Developers] Unsubscribe through the web References: <1015522644.3541.41.camel@julieta> Message-ID: <15506.21128.781681.955044@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas <rodolfo@pilas.net> writes: RP> [I use 2.1a4+ updated today from CVS] Sorry, I just cleared out the admindb for this list. Is this still a problem? -Barry From barry@zope.com Fri Mar 15 20:12:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 15:12:21 -0500 Subject: [Mailman-Developers] Privacy roster setting References: <3C8E241B.C3677CC1@isu.edu> Message-ID: <15506.21925.74890.14574@anthem.wooz.org> >>>>> "KW" == Kory Wheatley <wheakory@isu.edu> writes: KW> I want to know if there's a way to change all my lists that KW> have the setting to "view subscribers (set to anyone)" and KW> change it to (List admin only). I did make the change today KW> in the mm_cfg.py file, but that's only for new lists. How do I KW> change the settings to all the lists KW> at the command line. Do I need to use "config_list" if so, KW> how? Write a little bin/withlist script. -Barry From barry@zope.com Fri Mar 15 20:13:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 15:13:03 -0500 Subject: [Mailman-Developers] mailman for windows xp References: <000801c1c7af$ce08c510$9bd5b4d0@leaddog> Message-ID: <15506.21967.571664.51250@anthem.wooz.org> >>>>> "LK" == Loren Kallwick <kall@cox-internet.com> writes: LK> I looked around and could'nt find anyone working on making LK> mailman work on XP. AFAIK, there's no one working on porting Mailman to any Windows platform. -Barry From barry@zope.com Fri Mar 15 20:57:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 15:57:39 -0500 Subject: [Mailman-Developers] is it me? References: <20020315154550.GB13758@rezo.net> <1016222101.2450.23.camel@julieta> Message-ID: <15506.24643.811790.962921@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas <rodolfo@pilas.net> writes: >> Am I the only stupid guy running mailman cvs on a server with >> many lists? ;-) RP> Nooo, there are two guys! (I am the other) I'm running it for my personal lists, although they are very low traffic. As soon as b1 is out, I'll likely move mailman-developers to it. Might as well eat my own dog food, as they say. :) -Barry From listmgr@perilpoint.com Fri Mar 15 22:46:34 2002 From: listmgr@perilpoint.com (Bradford Shaw) Date: Fri, 15 Mar 2002 16:46:34 -0600 Subject: [Mailman-Developers] locked - please help In-Reply-To: <E16ly5U-0004F2-00@mail.python.org> Message-ID: <4.2.0.58.20020315163713.00cb7550@perilpoint.com> Hello, We have addressed this issue with mailman-users but without an results so we are now asking you for help in solving this. We are having a problem with a large list (12,000) that has become locked while uploading members. One of our people were subscribing members using the web interface and the list locked with a bug error. We can't seem to get the list to work and would like to seek another method than removing the list and recreating it. Recreating it will only add confusion to the members who have already received welcome letters with passwords -- which would become obsolute. In looking into the locks directory, we see 82 files similiar to this: <site>.lock.loginname.perilpoint.com.54206 <site>.lock.loginname.perilpoint.com.55962 istname.lock.loginname.perilpoint.com.10275 listname.lock.loginname.perilpoint.com.16039 listname.lock.loginname.perilpoint.com.18389 We have two questions: (1) What do we do with these files? Delete them? ?? (2) How do we unlock the list so that it will operate again? Please help. Brad Shaw From dmick@utopia.West.Sun.COM Fri Mar 15 22:58:45 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Fri, 15 Mar 2002 14:58:45 -0800 Subject: [Mailman-Developers] locked - please help References: <4.2.0.58.20020315163713.00cb7550@perilpoint.com> Message-ID: <3C927CA5.9CBD72B1@utopia.west.sun.com> Stop Mailman and disable its cron jobs (if pre-2.1) momentarily, then make sure all the Mailman python jobs are stopped, then remove all the lockfiles and try restarting. Bradford Shaw wrote: > > Hello, > > We have addressed this issue with mailman-users but without an results so > we are now asking you for help in solving this. > > We are having a problem with a large list (12,000) that has become locked > while uploading members. One of our people were subscribing members using > the web interface and the list locked with a bug error. We can't seem to > get the list to work and would like to seek another method than removing > the list and recreating it. Recreating it will only add confusion to the > members who have already received welcome letters with passwords -- which > would become obsolute. > > In looking into the locks directory, we see 82 files similiar to this: > > <site>.lock.loginname.perilpoint.com.54206 > <site>.lock.loginname.perilpoint.com.55962 > > istname.lock.loginname.perilpoint.com.10275 > listname.lock.loginname.perilpoint.com.16039 > listname.lock.loginname.perilpoint.com.18389 > > We have two questions: > (1) What do we do with these files? Delete them? ?? > (2) How do we unlock the list so that it will operate again? > > Please help. > > Brad Shaw > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From che@debian.org Sat Mar 16 00:46:39 2002 From: che@debian.org (Ben Gertzfield) Date: Sat, 16 Mar 2002 09:46:39 +0900 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <5.1.0.14.2.20020310223835.05439cc0@127.0.0.1> (Nick Simicich's message of "Sun, 10 Mar 2002 23:18:40 -0500") References: <p05101500b8b15039f30f@[207.149.192.229]> <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <p05101500b8b15039f30f@[207.149.192.229]> <5.1.0.14.2.20020310223835.05439cc0@127.0.0.1> Message-ID: <873cz12vbk.fsf@nausicaa.interq.or.jp> >>>>> "Nick" == Nick Simicich <njs@scifi.squawk.com> writes: Nick> All headers should not be case sensitive, so far as I know. Nick> This is right out of RFC822: RFC822 has been supplanted by many many RFCs, but yes, we should be treating the charset and content-type both as non-case-sensitive. Ben -- Brought to you by the letters H and U and the number 5. "He's like.. some sort of.. non-giving up.. school guy!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Sat Mar 16 00:56:35 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 15 Mar 2002 19:56:35 -0500 Subject: [Mailman-Developers] Headers and footers not appearing References: <p05101500b8b15039f30f@[207.149.192.229]> <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <5.1.0.14.2.20020310223835.05439cc0@127.0.0.1> <873cz12vbk.fsf@nausicaa.interq.or.jp> Message-ID: <15506.38979.246165.265799@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield <che@debian.org> writes: >>>>> "Nick" == Nick Simicich <njs@scifi.squawk.com> writes: Nick> All headers should not be case sensitive, so far as I know. Nick> This is right out of RFC822: BG> RFC822 has been supplanted by many many RFCs, but yes, we BG> should be treating the charset and content-type both as BG> non-case-sensitive. We should be good with Content-Type: as the email package's Message.get_type() coerces to lower case (as long as we always compare it with a lower case string <wink>). We just fixed the Charset class to do case insensitive comparisons, and to return a lower case coerced string as its str(). -Barry From jra@baylink.com Sat Mar 16 05:17:54 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 16 Mar 2002 00:17:54 -0500 Subject: [Mailman-Developers] Headers and footers not appearing In-Reply-To: <873cz12vbk.fsf@nausicaa.interq.or.jp>; from Ben Gertzfield <che@debian.org> on Sat, Mar 16, 2002 at 09:46:39AM +0900 References: <p05101500b8b15039f30f@[207.149.192.229]> <Marcel-1.53-0310105919-6d1hxQ&@demon.co.uk> <p05101500b8b15039f30f@[207.149.192.229]> <5.1.0.14.2.20020310223835.05439cc0@127.0.0.1> <873cz12vbk.fsf@nausicaa.interq.or.jp> Message-ID: <20020316001754.29344@scfn.thpl.lib.fl.us> On Sat, Mar 16, 2002 at 09:46:39AM +0900, Ben Gertzfield wrote: > >>>>> "Nick" == Nick Simicich <njs@scifi.squawk.com> writes: > Nick> All headers should not be case sensitive, so far as I know. > Nick> This is right out of RFC822: > > RFC822 has been supplanted by many many RFCs, but yes, we should > be treating the charset and content-type both as non-case-sensitive. You consider "RFC 2822" to be "many, many" RFC's? Cheers -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From listmgr@perilpoint.com Sat Mar 16 17:24:33 2002 From: listmgr@perilpoint.com (Bradford Shaw) Date: Sat, 16 Mar 2002 11:24:33 -0600 Subject: [Mailman-Developers] python problem - please help Message-ID: <4.2.0.58.20020316111549.00cd3180@perilpoint.com> Hello, Well, I thought that solving the lock would solve the problem with the list but it appears that it is worse than that. Probably a python problem. Could someone help me get through this? Here is the latest error log entry (x's indicate private customer info): Mar 16 10:15:17 2002 admin(89755): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(89755): [----- Mailman Version: 2.0.7 -----] admin(89755): [----- Traceback ------] admin(89755): Traceback (most recent call last): admin(89755): File "/usr/local/mailman/scripts/driver", line 96, in run_main admin(89755): main() admin(89755): File "/usr/local/mailman/Mailman/Cgi/admin.py", line 152, in main admin(89755): ChangeOptions(mlist, category, cgidata, doc) admin(89755): File "/usr/local/mailman/Mailman/Cgi/admin.py", line 940, in ChangeOptions admin(89755): mlist.DeleteMember(user) admin(89755): File "/usr/local/mailman/Mailman/MailList.py", line 1184, in DeleteMember admin(89755): self.Save() admin(89755): File "/usr/local/mailman/Mailman/MailList.py", line 857, in Save admin(89755): self.__save(dict) admin(89755): File "/usr/local/mailman/Mailman/MailList.py", line 816, in __save admin(89755): fp.write(marshal.dumps(dict)) admin(89755): MemoryError admin(89755): [----- Python Information -----] admin(89755): sys.version = 2.1.1 (#1, Nov 14 2001, 13:23:13) [GCC 2.95.2 19991024 (release)] admin(89755): sys.executable = /usr/local/bin/python admin(89755): sys.prefix = /usr/local admin(89755): sys.exec_prefix= /usr/local admin(89755): sys.path = /usr/local admin(89755): sys.platform = freebsd4 admin(89755): [----- Environment Variables -----] admin(89755): DOCUMENT_ROOT: /usr/local/etc/httpd/htdocs admin(89755): SERVER_ADDR: xxx.xx.xxx.xx admin(89755): HTTP_ACCEPT_ENCODING: gzip admin(89755): CONTENT_LENGTH: 2843 admin(89755): CONTENT_TYPE: application/x-www-form-urlencoded admin(89755): PATH_TRANSLATED: /usr/local/etc/httpd/htdocs/xxxxxxx/members admin(89755): REMOTE_ADDR: xxx.xxx.xx.xxx admin(89755): SERVER_SOFTWARE: Apache/1.3.22 OpenSSL/0.9.6c (Unix) admin(89755): GATEWAY_INTERFACE: CGI/1.1 admin(89755): HTTP_COOKIE: xxxxxxx:admin=280200000069487d933c732800000061653935353462303838386132653366 613630366666613432306138363733666265643339343465 admin(89755): HTTP_ACCEPT_LANGUAGE: en,pdf admin(89755): REMOTE_PORT: 1071 admin(89755): SERVER_PORT: 80 admin(89755): HTTP_CONNECTION: Keep-Alive admin(89755): HTTP_USER_AGENT: Mozilla/4.72 [en] (Win95; U) admin(89755): HTTP_ACCEPT_CHARSET: iso-8859-1,*,utf-8 admin(89755): HTTP_ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* admin(89755): REQUEST_URI: /mailman/admin/xxxxxxx/members admin(89755): QUERY_STRING: admin(89755): SERVER_PROTOCOL: HTTP/1.0 admin(89755): USER: xxxxxxx admin(89755): HTTP_HOST: xxxxxxx.perilpoint.com admin(89755): REQUEST_METHOD: POST admin(89755): SERVER_SIGNATURE: admin(89755): SCRIPT_NAME: /mailman/admin admin(89755): SERVER_ADMIN: webmaster@xxxxxxx.perilpoint.com admin(89755): SCRIPT_FILENAME: /usr/local/mailman/cgi-bin/admin admin(89755): PYTHONPATH: /usr/local/mailman admin(89755): PATH_INFO: /xxxxxxx/members admin(89755): HTTP_REFERER: http://xxxxxxx.perilpoint.com/mailman/admin/xxxxxxx/members?chunk=246 admin(89755): SERVER_NAME: xxxxxxx.perilpoint.com I would appreciate any help to solve this problem. Thanks, Dan, for the help so far. Brad Shaw From marc_news@vasoftware.com Sun Mar 17 03:19:45 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 16 Mar 2002 19:19:45 -0800 Subject: [Mailman-Developers] Dealing with SMTP server down Message-ID: <20020317031944.GB11598@merlins.org> mailman-cvs gives me: Mar 16 19:18:23 2002 (28557) Uncaught runner exception: (111, 'Connection refused') Mar 16 19:18:23 2002 (28557) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 103, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 153, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/OutgoingRunner.py", line 57, in _dispose self._func(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Handlers/SMTPDirect.py", line 124, in process conn = Connection() File "/var/local/mailman/Mailman/Handlers/SMTPDirect.py", line 49, in __init__ self.__connect() File "/var/local/mailman/Mailman/Handlers/SMTPDirect.py", line 53, in __connect self.__conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) File "/usr/lib/python2.1/smtplib.py", line 222, in connect self.sock.connect((host, port)) error: (111, 'Connection refused') Maybe it could just log the fact that it could not connect to the SMTP server? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Sun Mar 17 05:50:07 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 17 Mar 2002 00:50:07 -0500 Subject: [Mailman-Developers] RELEASED Mailman 2.1 beta 1 Message-ID: <15508.11919.910981.756175@anthem.wooz.org> I've released Mailman 2.1 beta 1; see below for a list of changes since version 2.1 alpha 4. There have been tons of bug fixes, several new languages, and lots of new features. We're finally in feature freeze for Mailman 2.1, although I reserve the right to classify an essential missing feature as a bug <wink>. I'd like to get 2.1 final out soon, and I think it's only fair that we eat our own dogfood before offering it to others, so I'll soon be transfering the mailman-* lists to the new version. Please report all bugs to SourceForge. Discussions about version 2.1 are preferred on mailman-developers. I'd also like to announce the mailman-docs@python.org mailing, which indeed is running under 2.1b1. This list will help coordinate the Mailman documentation effort, so if you'd like to contribute please join that list. This is a great way to help us out, even if you aren't into hacking the code. Enjoy, -Barry -------------------- snip snip -------------------- 2.1 beta 1 (16-Mar-2002) In addition to the usual bug fixes, performance improvements, and GUI changes, here are the highlights: - MIME and other message handling o More robustness against badly MIME encapsulated messages: if a MessageParseError is raised during the initial parse, the message can either be discarded or saved in qfiles/bad, depending on the value of the new configuration variable QRUNNER_SAVE_BAD_MESSAGES. o There is a new per-user option that can be used to avoid receipt of extra copies, when a member of the list is also explicitly CC'd. o Always add an RFC 2822 Date: header if missing, since not all MTAs insert one automatically. o The Sender: and Errors-To: headers are no longer added to outgoing messages. o Headers and footers are always added by concatenation, if the message is not MIME and if the list's charset is a superset of us-ascii. - List administration o An `invitation' feature has been added. This is selectable as a radio button on the mass subscribe page. When selected, users are invited to join instead of immediately joined, i.e. they get a confirmation message. o You can now enable and disable list owner notifications for disabled-due-to-bouncing and removal-due-to-bouncing actions. The site config variables DEFAULT_BOUNCE_NOTIFY_OWNER_ON_DISABLE and DEFAULT_BOUNCE_NOTIFY_OWNER_ON_REMOVAL control the default behavior. o List owners can now decide whether they receive unrecognized bounce messages or not (i.e. messages that the bounce processor doesn't recognize). Site admins can set the default value for this flag with the config variable DEFAULT_BOUNCE_UNRECOGNIZED_GOES_TO_LIST_OWNER. o The admindb summary page gives the option of clearing the moderation flag of members who are on quarantined. o The action to take when a moderated member posts to a list is now configurable. The message can either be held, rejected (bounced), or discarded. If the message is rejected, a rejection notice string can be given. o In the General admin page, you can now set the default value for five per-user flags: concealing the user's email address, acknowledging posts sent by the user, copy suppression, not-me-too selection, and the default digest type. Site admins can set the default bit field with the new DEFAULT_NEW_MEMBER_OPTIONS variable. o A new "Emergency brake" feature for turning on moderation of all list postings. This is useful for when flamewars break out, and the list needs a cooling off period. Messages containing an Approved: header with the list owner password are still allowed through, as are messages approved through the admindb interface. o When a moderated message is approved for the list, add an X-Mailman-Approved-At: header which contains the timestamp of the approval action (changed from X-Moderated: with a different format). o Lists can now be converted to using a less error prone mechanism for variable substitution syntax in headers and footers. Instead of %(var)s strings, you'd use $var strings. You must use "bin/withlist -r convert" to enable this. o When moderating held messages, the header text box and the message excerpt text box are now both read-only. o You can't delete the site list through the web. o When creating new lists through the web, you have the option of setting the "default member moderation" flag. - Security and privacy o New feature: banned subscription addresses. Privacy options/subscription rules now have an additional list box which can contain addresses or regular expressions. Subscription requests from any matching address are automatically rejected. o Membership tests which compare message headers against list rosters are now more robust. They now check, by default these header in order: From:, unixfrom, Reply-To:, Sender:. If any match, then the membership test succeeds. o ALLOW_SITE_ADMIN_COOKIES is a new configuration variable which says whether to allow AuthSiteAdmin cookies or not. Normally, when a list administrator logs into a list with the site password, they are issued a cookie that only allows them to do administration for this one list. By setting ALLOW_SITE_ADMIN_COOKIES to 1, the user only needs to authenticate to one list with the site password, and they can administer any mailing list. I'm not sure this feature is wise, so the default value for ALLOW_SITE_ADMIN_COOKIES is 0. o Marc MERLIN's new recipes for secure Linuxes have been updated. o DEFAULT_PRIVATE_ROSTER now defaults to 1. o Passwords are no longer included in the confirmation pages. - Internationalization o With the approval of Tamito KAJIYAMA, the Japanese codes for Python are now included automatically, so you don't need to download and install these separate. It is installed in a Mailman-specific place so it won't affect your larger Python installation. o The configure script will produce a warning if the Chinese codes are not installed. This is not a fatal error. o Russian templates and catalogs have been added. o Finnish templates and catalogs have been added. - Scripts and utilities o New program bin/unshunt to safely move shunted messages back into the appropriate processing queue. o New program bin/inject for sending a plaintext message into the incoming queue from the command line. o New cron script cron/disabled for periodically culling the disabled membership. o bin/list_members has grown some new command line switches for filtering on different criteria (digest mode, disable mode, etc.) o bin/remove_members has grown the --fromall switch. o You can now do a bin/rmlist -a to remove an archive even after the list has been deleted. o bin/update removes the $prefix/Mailman/pythonlib directory. o bin/withlist grows a --all/-a flag so the --run/-r option can be applied to all the mailing lists. Also, interactive mode is now the default if -r isn't used. You don't need to run this script as "python -i bin/withlist" anymore. o There is a new script contrib/majordomo2mailman.pl which should ease the transition from Majordomo to Mailman. - MTA integration o Postfix integration has been made much more robust, but now you have to set POSTFIX_ALIAS_CMD and POSTFIX_MAP_CMD to point to the postalias and postmap commands respectively. o VERP-ish delivery has been made much more efficient by eliminating extra disk copies of messages for each recipient of a VERP delivery. It has also been made more robust in the face of failures during chunk delivery. This required a rewrite of SMTPDirect.py and one casualty of that rewrite was the experimental threaded delivery. It is no longer supported (but /might/ be resurrected if there's enough demand -- or a contributed patch :). o A new site config variable SMTP_MAX_SESSIONS_PER_CONNECTION specifies how many consecutive SMTP sessions will be conducted down the same socket connection. Some MTAs have a limit on this. o Support for VERP-ing confirmation messages. These are less error prone since the Subject: header doesn't need to be retained, and they allow a more user friendly (and i18n'd) Subject: header. VERP_CONFIRM_FORMAT, VERP_CONFIRM_REGEXP, and VERP_CONFIRMATIONS control this feature (only supported for invitation confirmations currently, but will be expanded to the other confirmations). o Several new list-centric addresses have been added: -subscribe and -unsubscribe are synonyms for -join and -leave, respectively. Also -confirm has been added to support VERP'd confirmations. - Archiver o There's now a default page for the Pipermail archive link for when no messages have yet been posted to the list. o Just the mere presence of an X-No-Archive: is enough to inhibit archiving for this message; the value of the header is now ignored. - Configuring, building, installing o Mailman now has a new favicon, donated by Terry Oda. Not all web pages are linked to the favicon yet though. o The add-on email package is now distributed and installed automatically, so you don't need to do this. It is installed in a Mailman-specific place so it won't affect your larger Python installation. o The default value of VERP_REGEXP has changed. o New site configuration variables BADQUEUE_DIR and QRUNNER_SAVE_BAD_MESSAGES which describe where to save messages which are not properly MIME encoded. o configure should be more POSIX-ly conformant. o The Mailman/pythonlib directory has been removed, but a new $prefix/pythonlib directory has been added. o Regression tests are now installed. o The second argument to add_virtual() calls in mm_cfg.py are now optional. o DEFAULT_FIRST_STRIP_REPLY_TO now defaults to 0. o Site administrators can edit the Mailman/Site.py file to customize some filesystem layout policies. From claw@kanga.nu Sun Mar 17 21:45:18 2002 From: claw@kanga.nu (J C Lawrence) Date: Sun, 17 Mar 2002 13:45:18 -0800 Subject: [Mailman-Developers] another idea to limit disk usage In-Reply-To: Message from Fil <fil@rezo.net> of "Fri, 15 Mar 2002 11:14:27 +0100." <20020315101427.GA29079@rezo.net> References: <20020315101427.GA29079@rezo.net> Message-ID: <22615.1016401518@kanga.nu> On Fri, 15 Mar 2002 11:14:27 +0100 fil <fil@rezo.net> wrote: > Another idea to limit disk usage: shouldn't the "mail/mailman bounces > listname" cut the messages it receives 10 lines or so after any > "Errors-To: listname.*" line it encounters ? You wouldn't lose > interesting data I guess... Arrrgh. I hate systems that do that. Too often I do want the full header set, or some of the data in the message itself for analysis and its been discarded by just such a short-sighted mostly-useless penny pinching. -- 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 fil@rezo.net Sun Mar 17 23:44:04 2002 From: fil@rezo.net (Fil) Date: Mon, 18 Mar 2002 00:44:04 +0100 Subject: [Mailman-Developers] big list In-Reply-To: <15506.19096.191205.554772@anthem.wooz.org> References: <15499.58233.558446.909705@anthem.wooz.org> <15500.3352.980046.610866@localhost.localdomain> <20020311081420.GG29396@rezo.net> <15501.33126.725011.122075@anthem.wooz.org> <20020312091834.GA5891@rezo.net> <20020312093111.GA7691@rezo.net> <15506.13906.500062.189950@anthem.wooz.org> <20020315181155.GE974@rezo.net> <20020315184235.GA16337@rezo.net> <15506.19096.191205.554772@anthem.wooz.org> Message-ID: <20020317234404.GA18151@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > >>>>> "F" == Fil <fil@rezo.net> writes: > F> I am ashamed: "cvs update" did me no good; some scripts were > F> up-to-date, others definitely not. Now everything's a clean > F> install, I'll let the week-end go without a post to the > F> -developpers list. > > :) Hi there, my week end's over! Here are tracebacks of bugs observed with Mailman 2.1b1 (I'm positive this is a nice and complete install from cvs!) over the week end. Two bugs seem to be running: 1) File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmation addr = userdesc.address AttributeError: address One of my lists' admin (his list has 13 000 subscribers) has hit this one several times this weekend (he received the tracebacks by email). 2) A timeout occurs on the 'pending' database and maybe on the list database also when we send many messages. From observing the processes running on the server and the flow of emails, it looks like the culprit is the BounceRunner, which locks these databases for long periods, and does not release the locks fast enough for the other processes. Maybe this is because the lists are big (ie long time opening/saving/checking if the bounce is a member). We don't care much about the BounceRunner losing its lock, but we should let it block the other processes, who are responding to the users (be it the Web interface or the mail command runner). On my setup, a bounce on the 50 000 subscribers' list is processed in about 3-4 seconds. The BounceRunner takes up 100% of one CPU (I have two) and a lot of memory (although less than last time I raised that issue). But count: 3 seconds * 40 000 bounces = 33 hours. So if someone migrates her big list from some bounce-blind MLM to Mailman, she'll run into that issue: sub/unsub/listinfo/whatever requests on the list returning exceptions for 33 hours. This has happened many times also over the week end. Hope this can be helpful. SOME TRACEBACKS: ----- Original Message ----- From: <listname-admin@rezo.net> To: <listname-admin@rezo.net> Sent: Sunday, March 17, 2002 2:09 PM Subject: Erreur Mailman inattendue Une erreur Mailman inattendue s'est produite dans MailCommandHandler.ParseMailCommand(). En voici les raisons: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 273, in ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 727, in ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmation addr = userdesc.address AttributeError: address Pour gerer votre abonnement : http://listes.rezo.net/mailman/listinfo/listname The error log says about the same thing: Mar 17 14:09:04 2002 (9618) Unexpected Mailman error: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 273, in ParseMailCom self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 727, in ProcessConfi results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmation addr = userdesc.address AttributeError: address *********************************************************************** Mar 17 18:52:14 2002 admin(8563): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(8563): [----- Mailman Version: 2.1b1 -----] admin(8563): [----- Traceback ------] admin(8563): Traceback (most recent call last): admin(8563): File "/home/mailman/scripts/driver", line 82, in run_main admin(8563): main() admin(8563): File "/home/mailman/Mailman/Cgi/subscribe.py", line 94, in main admin(8563): process_form(mlist, doc, cgidata, language) admin(8563): File "/home/mailman/Mailman/Cgi/subscribe.py", line 176, in proc admin(8563): mlist.AddMember(userdesc, remote) admin(8563): File "/home/mailman/Mailman/MailList.py", line 711, in AddMember admin(8563): cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) admin(8563): File "/home/mailman/Mailman/Pending.py", line 61, in new admin(8563): lock.lock(timeout=30) admin(8563): File "/home/mailman/Mailman/LockFile.py", line 292, in lock admin(8563): raise TimeOutError admin(8563): TimeOutError *********************************************************************** Mar 17 19:11:25 2002 (9618) Unexpected Mailman error: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 273, in ParseMailCom self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 727, in ProcessConfi results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 968, in ProcessConfirmation data = Pending.confirm(cookie) File "/home/mailman/Mailman/Pending.py", line 94, in confirm lock.lock(timeout=30) File "/home/mailman/Mailman/LockFile.py", line 292, in lock raise TimeOutError TimeOutError *********************************************************************** Mar 17 20:48:03 2002 admin(22240): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(22240): [----- Mailman Version: 2.1b1 -----] admin(22240): [----- Traceback ------] admin(22240): Traceback (most recent call last): admin(22240): File "/home/mailman/scripts/driver", line 82, in run_main admin(22240): main() admin(22240): File "/home/mailman/Mailman/Cgi/options.py", line 164, in main admin(22240): mlist.MailUserPassword(user) admin(22240): File "/home/mailman/Mailman/Deliverer.py", line 107, in MailUse admin(22240): {'user' : cpuser, admin(22240): KeyError: Rxxxxxxxxxxxx@AOL.COM admin(22240): [----- Python Information -----] admin(22240): sys.version = 2.1 (#1, Jun 1 2001, 23:51:21) [GCC 2.95.3 20010125 (prerelease)] admin(22240): sys.executable = /usr/local/bin/python2.1 admin(22240): sys.prefix = /usr/local admin(22240): sys.exec_prefix = /usr/local admin(22240): sys.path = /usr/local admin(22240): sys.platform = linux2 admin(22240): [----- Environment Variables -----] admin(22240): DOCUMENT_ROOT: /var/www/listes.rezo.net admin(22240): SERVER_ADDR: 80.67.170.17 admin(22240): HTTP_ACCEPT_ENCODING: gzip, deflate admin(22240): CONTENT_LENGTH: 54 admin(22240): CONTENT_TYPE: application/x-www-form-urlencoded admin(22240): PATH_TRANSLATED: /var/www/listes.rezo.net/courrier-balkans admin(22240): GATEWAY_INTERFACE: CGI/1.1 admin(22240): UNIQUE_ID: PJTy81BDqhEAAEPnHyQ admin(22240): HTTP_ACCEPT_LANGUAGE: fr admin(22240): REMOTE_ADDR: 19xxxxxxxxxxxxx admin(22240): SERVER_PORT: 80 admin(22240): HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 6.0; AOL 7.0; Wi admin(22240): HTTP_ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpe admin(22240): REQUEST_URI: /mailman/options/courrier-balkans admin(22240): QUERY_STRING: admin(22240): SCRIPT_FILENAME: /home/mailman/cgi-bin/options admin(22240): SCRIPT_URL: /mailman/options/courrier-balkans admin(22240): HTTP_HOST: listes.rezo.net admin(22240): REQUEST_METHOD: POST admin(22240): SERVER_SIGNATURE: admin(22240): SCRIPT_URI: http://listes.rezo.net/mailman/options/courrier-bal admin(22240): SCRIPT_NAME: /mailman/options admin(22240): SERVER_ADMIN: fil@rezo.net admin(22240): SERVER_SOFTWARE: Apache/1.3.23 (Unix) Debian GNU/Linux mod_fast admin(22240): PYTHONPATH: /home/mailman admin(22240): PATH_INFO: /courrier-balkans admin(22240): HTTP_REFERER: http://listes.rezo.net/mailman/options/courrier-b admin(22240): HTTP_PRAGMA: no-cache admin(22240): SERVER_NAME: listes.rezo.net -- Fil From chk@pobox.com Mon Mar 18 15:20:33 2002 From: chk@pobox.com (Harald Koch) Date: Mon, 18 Mar 2002 10:20:33 -0500 Subject: [Mailman-Developers] minor config issue: web_page_url is stored in list config Message-ID: <9210.1016464833@elisabeth.cfrq.net> I installed Mailman 2.1b1 yesterday. I have an active 2.0.8 config, so I installed 2.1b1 in a different directory, and moved a couple of lists over from one install to the other. Everything worked swimmingly, except for one thing: the URLs on web pages were all pointing back to the old mailman installation. Some poking around led me to the following: The value for 'web_page_url' is stored in each individual list config file (config.db/config.pck), instead of always being read from mm_cfg.py. However, that variable is not exported by "config_list -o", so it took me a while to figure it out. The workaround for me was to add "web_page_url = 'http://www.cfrq.net/mm/' to my list config and ran "config_list -i"; thankfully that worked. Ideally, I would expect that this variable always be built from mm_cfg; it's a property of the mailman install, not a property of an individual list. Comments? -- Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry From dale@newfield.org Mon Mar 18 16:05:05 2002 From: dale@newfield.org (Dale Newfield) Date: Mon, 18 Mar 2002 11:05:05 -0500 (EST) Subject: [Mailman-Developers] minor config issue: web_page_url is stored in list config In-Reply-To: <9210.1016464833@elisabeth.cfrq.net> Message-ID: <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> On Mon, 18 Mar 2002, Harald Koch wrote: > Ideally, I would expect that this variable always be built from mm_cfg; > it's a property of the mailman install, not a property of an individual > list. Not quite true. When you have a single machine running lists for numerous virtual domains, the differences in that value in the various lists become important. -Dale From chk@pobox.com Mon Mar 18 16:20:30 2002 From: chk@pobox.com (Harald Koch) Date: Mon, 18 Mar 2002 11:20:30 -0500 Subject: [Mailman-Developers] Re: minor config issue: web_page_url is stored in list config In-Reply-To: dale's message of "Mon, 18 Mar 2002 11:05:05 -0500". <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> References: <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> Message-ID: <9790.1016468430@elisabeth.cfrq.net> Of all the gin joints in all the towns in all the world, Dale Newfield had to walk into mine and say: > > Not quite true. When you have a single machine running lists for numerous > virtual domains, the differences in that value in the various lists become > important. Ah yes; forgot that one. Perhaps the fix would be to simply export the variable when running "config_list -o", so that it is more obvious that it is a per-list setting? (I realize that config_list is aligned with the web-based config, and it would be foolish to change the URL from the web-based config. I don't have any other brilliant suggestions, though...) -- Harald Koch <chk@pobox.com> From totschnig.michael@uqam.ca Mon Mar 18 16:02:32 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Mon, 18 Mar 2002 11:02:32 -0500 Subject: [Mailman-Developers] bug in confirm by web interface Message-ID: <m2it7tamp3.fsf@linux.totschnig.org> Hello, on a CVS mailman updated yesterday, I encounter the following problem when confirming a subscription by the web interface. Everything runs fine but on the page confirming the subscription, the link pointing to the subscribers login page is not expanded correctly: It reads http://hostname/mailman/confirm/%(optionurl)s Maybe the problem is related to the fact that I use Mailman localized in French? Regards, Michael From mentor@alb-net.com Mon Mar 18 17:17:06 2002 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 18 Mar 2002 12:17:06 -0500 (EST) Subject: [Mailman-Developers] installing 2.1b1 on top of 2.0.8 Message-ID: <Pine.GSO.4.44.0203181213180.820-100000@alb-net.com> Has anyone installed 2.1b1 on top of 2.0.8? I'm tempted to do so and I would appreciate any first hand experience. Is this recommended or is it prefered that we install 2.1b1 in another location and than move the 2.0.8 lists to the 2.1b1 location? thanks, Mentor From wilane@yahoo.com Mon Mar 18 17:23:41 2002 From: wilane@yahoo.com (Ousmane Wilane) Date: Mon, 18 Mar 2002 17:23:41 +0000 Subject: [Mailman-Developers] bug in confirm by web interface In-Reply-To: <m2it7tamp3.fsf@linux.totschnig.org> References: <m2it7tamp3.fsf@linux.totschnig.org> Message-ID: <15510.8861.625969.513356@localhost.localdomain> >>>>> "TM" == totschnig michael <totschnig.michael@uqam.ca> writes: TM> Hello, on a CVS mailman updated yesterday, I encounter the TM> following problem when confirming a subscription by the web TM> interface. Everything runs fine but on the page confirming the TM> subscription, the link pointing to the subscribers login page is TM> not expanded correctly: It reads TM> http://hostname/mailman/confirm/%(optionurl)s Maybe the problem TM> is related to the fact that I use Mailman localized in French? Fixed in cvs, I'm sorry. Thanks -- Ousmane Wilane From jarrell@vt.edu Mon Mar 18 17:29:14 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 18 Mar 2002 12:29:14 -0500 Subject: [Mailman-Developers] installing 2.1b1 on top of 2.0.8 In-Reply-To: <Pine.GSO.4.44.0203181213180.820-100000@alb-net.com> Message-ID: <5.1.0.14.2.20020318122733.09ab2ec0@lennier.cc.vt.edu> At 12:17 PM 3/18/02 -0500, you wrote: >Has anyone installed 2.1b1 on top of 2.0.8? I'm tempted to do so and I >would appreciate any first hand experience. > >Is this recommended or is it prefered that we install 2.1b1 in another >location and than move the 2.0.8 lists to the 2.1b1 location? It ought to work just fine. I haven't gone and done my prod machine (this week) but my test machine was getting a never ending stream of "Oh look - 6 more commits came in from 'Commit Happy Barry' :-) while I was doing the install for the last 14." and if it compiled at all, it installed cleanly... Do read the docs carefully - a lot of things have changed; before putting the service back in production you'll need to create the site mailing list, potentially regenerate all your email aliases (there's a program to do so if you aren't using an auto-routing mailer), and change your crontab, just off the top of my head. Oh yea, and go over mm_cfg with a fine tooth comb, cause a lot of stuff changed in there and in Defaults. You'll also need, although not necessarily immediately, an appropriate script to start the persistent qrunners (not out of cron anymore), and if you've been customizing list pages, you'll need some serious repair work there. From brett@twobikes.ottawa.on.ca Mon Mar 18 17:35:49 2002 From: brett@twobikes.ottawa.on.ca (Brett Delmage) Date: Mon, 18 Mar 2002 12:35:49 -0500 (EST) Subject: [Mailman-Developers] qrunner fails to start on 2.1b4 Message-ID: <Pine.LNX.4.33.0203180117510.19608-100000@pannier.cfsc.ottawa.on.ca> I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python 2.1.1 A problem showed up during make install, where paths.py was not copied into the bin, scripts, cron directories. I copied it in manually and that cleared the initial problems: the Cgi parts seemed to work (without exhaustive testing). Now I'm running into the followuing problems with qrunner but I am not sure where to look. Suggestions? It looks like it might still be related to paths.py? Brett # bin/mailmanctl start Starting Mailman's master qrunner. Cannot import runner module Mailman.Queue.VirginRunner Cannot import runner module Mailman.Queue.CommandRunner Cannot import runner module Mailman.Queue.IncomingRunner Cannot import runner module Mailman.Queue.ArchRunner Cannot import runner module Mailman.Queue.BounceRunner Cannot import runner module Mailman.Queue.NewsRunner Cannot import runner module Mailman.Queue.OutgoingRunner in logs/error: Mar 18 00:41:58 2002 mailmanctl(4463): Mar 18 00:42:06 2002 qrunner(4472): Cannot import runner module Mailman.Queue.VirginRunner Mar 18 00:42:06 2002 qrunner(4468): Cannot import runner module Mailman.Queue.CommandRunner Mar 18 00:42:06 2002 qrunner(4469): Cannot import runner module Mailman.Queue.IncomingRunner Mar 18 00:42:07 2002 qrunner(4466): Cannot import runner module Mailman.Queue.ArchRunner Mar 18 00:42:08 2002 qrunner(4467): Cannot import runner module Mailman.Queue.BounceRunner Mar 18 00:42:08 2002 qrunner(4470): Cannot import runner module Mailman.Queue.NewsRunner Mar 18 00:42:08 2002 qrunner(4471): Cannot import runner module Mailman.Queue.OutgoingRunner in logs/qrunner: Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit (pid: 4472, sig: 0, sts: 15, class: VirginRunner, slice: 1/1) Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit (pid: 4468, sig: 0, sts: 15, class: CommandRunner, slice: 1/1) Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit (pid: 4469, sig: 0, sts: 15, class: IncomingRunner, slice: 1/1) Mar 18 00:42:07 2002 (4465) Master qrunner detected subprocess exit (pid: 4466, sig: 0, sts: 15, class: ArchRunner, slice: 1/1) Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit (pid: 4467, sig: 0, sts: 15, class: BounceRunner, slice: 1/1) Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit (pid: 4470, sig: 0, sts: 15, class: NewsRunner, slice: 1/1) Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit (pid: 4471, sig: 0, sts: 15, class: OutgoingRunner, slice: 1/1) From mentor@alb-net.com Mon Mar 18 17:54:23 2002 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 18 Mar 2002 12:54:23 -0500 (EST) Subject: [Mailman-Developers] installing 2.1b1 on top of 2.0.8 In-Reply-To: <5.1.0.14.2.20020318122733.09ab2ec0@lennier.cc.vt.edu> Message-ID: <Pine.GSO.4.44.0203181248020.820-100000@alb-net.com> Thanks for the e-mail. I have already installed 2.1b1 in a separate location (both version 2.0.8 and 2.1b1 working just fine). However, my current 2.1b1 installation is a test instalation only. That's where I test my CVSs before installing in the production location. However, my current 2.1b1 was an incremental upgrade from the CVS every few days, starting with pre 2.1a4. So, hopefully going directly from 2.0.8 to 2.1b1 will not be a problem. Yeh, we have to be carefull about all the small things you have listed below. And hopefully, after I do all of that things will work! :) Judging from previous experience I don't anticipate any problems, but, it does not hurt to ask if someone has already gone through that path.... I'll send an e-mail once I'm done... :) later, Mentor On Mon, 18 Mar 2002, at 12:29 -0500, Ron Jarrell wrote: > At 12:17 PM 3/18/02 -0500, you wrote: > > >Has anyone installed 2.1b1 on top of 2.0.8? I'm tempted to do so and I > >would appreciate any first hand experience. > > > >Is this recommended or is it prefered that we install 2.1b1 in another > >location and than move the 2.0.8 lists to the 2.1b1 location? > > It ought to work just fine. I haven't gone and done my prod machine > (this week) but my test machine was getting a never ending stream of > "Oh look - 6 more commits came in from 'Commit Happy Barry' :-) while > I was doing the install for the last 14." and if it compiled at all, it installed > cleanly... > > Do read the docs carefully - a lot of things have changed; before putting the > service back in production you'll need to create the site mailing list, potentially > regenerate all your email aliases (there's a program to do so if you aren't > using an auto-routing mailer), and change your crontab, just off the top of my > head. Oh yea, and go over mm_cfg with a fine tooth comb, cause a lot of > stuff changed in there and in Defaults. You'll also need, although not > necessarily immediately, an appropriate script to start the persistent > qrunners (not out of cron anymore), and if you've been customizing list > pages, you'll need some serious repair work there. > > From jarrell@vt.edu Mon Mar 18 18:40:14 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 18 Mar 2002 13:40:14 -0500 Subject: [Mailman-Developers] installing 2.1b1 on top of 2.0.8 In-Reply-To: <Pine.GSO.4.44.0203181248020.820-100000@alb-net.com> References: <5.1.0.14.2.20020318122733.09ab2ec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020318133928.041431c0@lennier.cc.vt.edu> At 12:54 PM 3/18/02 -0500, Mentor Cana wrote: >However, my current 2.1b1 was an incremental upgrade from the CVS every few >days, starting with pre 2.1a4. So, hopefully going directly from 2.0.8 to >2.1b1 will not be a problem. Yeh, we have to be carefull about all the I've done large cvs jumps with no trouble - update is pretty smart about knowing what to do to update things, and only doing them once. From barry@zope.com Mon Mar 18 18:43:15 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 13:43:15 -0500 Subject: [Mailman-Developers] installing 2.1b1 on top of 2.0.8 References: <Pine.GSO.4.44.0203181213180.820-100000@alb-net.com> Message-ID: <15510.13635.961744.82630@anthem.wooz.org> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes: MC> Has anyone installed 2.1b1 on top of 2.0.8? I'm tempted to do MC> so and I would appreciate any first hand experience. I have, but only for some test lists. MC> Is this recommended or is it prefered that we install 2.1b1 in MC> another location and than move the 2.0.8 lists to the 2.1b1 MC> location? This is typically the way I tend to upgrade python.org. It let's me make you guys guinea pigs without endangering the Wrath of Guido. :) -Barry From wheakory@isu.edu Mon Mar 18 19:06:34 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Mon, 18 Mar 2002 12:06:34 -0700 Subject: [Mailman-Developers] Problem with mailman 2.0.8 upgrade to Mailman 2.1b1 Message-ID: <3C963ABA.26505CF@isu.edu> Mailman 2.08 was working fine and I decided to upgrade to mailman 2.1b1 and the web interface is fine and it sends out the welcome messages fine. I regenerated the alias file to the new format. I changed the wrapper to mailman in the /etc/smrsh directory. The problem is when I send a message to the list I receive the following error. The original message was received at Mon, 18 Mar 2002 11:41:56 -0500 from ux9-205.isu.edu [134.50.205.114] ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/mailman post korybest" (reason: 2) (expanded from: <korybest@kwlinux.isu.edu>) ----- Transcript of session follows ----- Failure to exec script. WANTED gid 501, GOT gid 12. (Reconfigure to take 12?) 554 5.3.0 unknown mailer error 2 Reporting-MTA: dns; kwlinux.isu.edu Received-From-MTA: DNS; ux9-205.isu.edu Arrival-Date: Mon, 18 Mar 2002 11:41:56 -0500 Final-Recipient: RFC822; korybest@kwlinux.isu.edu X-Actual-Recipient: X-Unix; |/home/mailman/mail/mailman post korybest Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 2 Last-Attempt-Date: Mon, 18 Mar 2002 11:41:56 -0500 I have always used the 501 GID has the group id, I did not specify a different GID in the upgrade when I did the configure, (all I specified was ./configure --prefix=/home/mailman).. How can I reconfigure without losing my lists or starting over. -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From chk@pobox.com Mon Mar 18 19:26:21 2002 From: chk@pobox.com (Harald Koch) Date: Mon, 18 Mar 2002 14:26:21 -0500 Subject: [Mailman-Developers] Re: minor config issue: web_page_url is stored in list config In-Reply-To: chk's message of "Mon, 18 Mar 2002 11:20:30 -0500". <9790.1016468430@elisabeth.cfrq.net> References: <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> <9790.1016468430@elisabeth.cfrq.net> Message-ID: <12297.1016479581@elisabeth.cfrq.net> Of all the gin joints in all the towns in all the world, Harald Koch had to walk into mine and say: > Perhaps the fix would be to simply export the variable when running > "config_list -o", so that it is more obvious that it is a per-list > setting? Especially since it was exported in 2.0.8, as I just discovered while looking for something else... (Too many open-source packages, too little time... <grin>) -- Harald Koch <chk@pobox.com> From spertus@mills.edu Mon Mar 18 21:43:57 2002 From: spertus@mills.edu (Ellen Spertus) Date: Mon, 18 Mar 2002 13:43:57 -0800 Subject: [Mailman-Developers] Modifications to msg Message-ID: <5.1.0.14.0.20020318133136.041ee4c8@ella.mills.edu> --=====================_169733023==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I've been making some modifications to Mailman to support dynamic sublists (http://javamlm.mills.edu). I'm still rather new with Python and have a question about modifying fields (dictionary elements) of the msg data structure. Specifically, I added the following code to change the message's "To" field at the end of CookHeaders.py: 1 if msgdata.get('dlist'): 2 threadID = msgdata['thread_id'] 3 syslog('info', "threadID = %d", threadID) 4 to_line = '%s-%d@%s' % (mlist.real_name.lower(), threadID, mlist.host_name) 5 syslog('info', "to_line = %s", to_line) 6 del msg['To'] 7 msg['To'] = to_line 8 syslog('info', "Set msg['To'] to '%s'", msg['To']) This correctly changes the "To" field of the message from etest-new@hostname to etest-<threadID>@hostname, as shown by the log: Mar 18 13:29:55 2002 (4600) threadID = 19 Mar 18 13:29:55 2002 (4600) to_line = etest-19@javamlm.mills.edu Mar 18 13:29:55 2002 (4600) Set msg['To'] to 'etest-19@javamlm.mills.edu' Similarly, the resulting email message that is sent has the new 'To' field. The problem is I don't see why line 6 above is necessary. When I comment it out, however, I get the incongruous logfile entry: Mar 18 13:36:04 2002 (4640) threadID = 20 Mar 18 13:36:04 2002 (4640) to_line = etest-20@javamlm.mills.edu Mar 18 13:36:04 2002 (4640) Set msg['To'] to 'etest-new@javamlm.mills.edu' as though line 7 had never been executed. The final email message contains two "To" headers, one with "etest-new" and one with "etest-<threadID>". It's not clear to me why the original value is preserved instead of overwritten. Could someone let me know what I'm missing about dictionaries or the email class? Thank you. Ellen Spertus --=====================_169733023==_.ALT Content-Type: text/html; charset="us-ascii" <html> I've been making some modifications to Mailman to support dynamic sublists (<a href="http://javamlm.mills.edu/" eudora="autourl">http://javamlm.mills.edu</a>).  I'm still rather new with Python and have a question about modifying fields (dictionary elements) of the msg data structure.  Specifically, I added the following code to change the message's "To" field at the end of CookHeaders.py:<br><br> 1    if msgdata.get('dlist'):<br> 2        threadID = msgdata['thread_id']<br> 3        syslog('info', "threadID = %d", threadID)<br> 4        to_line =  '%s-%d@%s' % (mlist.real_name.lower(),<br>                                   threadID,<br>                                   mlist.host_name)<br> 5        syslog('info', "to_line = %s", to_line)<br> 6        del msg['To']<br> 7        msg['To'] = to_line<br> 8        syslog('info', "Set msg['To'] to '%s'", msg['To'])<br><br> This correctly changes the "To" field of the message from etest-new@hostname to etest-<threadID>@hostname, as shown by the log:<br> <dl> <dd>Mar 18 13:29:55 2002 (4600) threadID = 19 <dd>Mar 18 13:29:55 2002 (4600) to_line = etest-19@javamlm.mills.edu <dd>Mar 18 13:29:55 2002 (4600) Set msg['To'] to 'etest-19@javamlm.mills.edu'<br><br> </dl>Similarly, the resulting email message that is sent has the new 'To' field.<br><br> The problem is I don't see why line 6 above is necessary.  When I comment it out, however, I get the incongruous logfile entry:<br> <dl> <dd>Mar 18 13:36:04 2002 (4640) threadID = 20 <dd>Mar 18 13:36:04 2002 (4640) to_line = etest-20@javamlm.mills.edu <dd>Mar 18 13:36:04 2002 (4640) Set msg['To'] to 'etest-new@javamlm.mills.edu'<br><br> </dl>as though line 7 had never been executed.  The final email message contains two "To" headers, one with "etest-new" and one with "etest-<threadID>".  It's not clear to me why the original value is preserved instead of overwritten.   Could someone let me know what I'm missing about dictionaries or the email class?<br><br> Thank you.<br><br> Ellen Spertus<br> </html> --=====================_169733023==_.ALT-- From spertus@mills.edu Mon Mar 18 22:15:15 2002 From: spertus@mills.edu (Ellen Spertus) Date: Mon, 18 Mar 2002 14:15:15 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <200203182205.g2IM5MWk019182@utopia.West.Sun.COM> Message-ID: <5.1.0.14.0.20020318141323.04417cb8@ella.mills.edu> At 02:05 PM 3/18/2002 -0800, Dan Mick wrote: >Question one: which version of mailman? The "message" class >changes drastically from 2.0.x to 2.1.x. Sorry to leave that out. I'm using Mailman 2.1a3 and Python 2.2c1. Ellen From mss@mawhrin.net Mon Mar 18 23:41:51 2002 From: mss@mawhrin.net (Mikhail Sobolev) Date: Mon, 18 Mar 2002 23:41:51 +0000 Subject: [Mailman-Developers] erroneous format specification: sync_members Message-ID: <20020318234151.GA25572@mawhrin.net> A small patch to fix it. -- Misha Index: sync_members =================================================================== RCS file: /cvsroot/mailman/mailman/bin/sync_members,v retrieving revision 2.6 diff -u -b -r2.6 sync_members --- sync_members 23 Feb 2002 06:34:14 -0000 2.6 +++ sync_members 18 Mar 2002 23:40:28 -0000 @@ -182,7 +182,7 @@ addr = filemembers[i].strip() if addr == '' or addr[:1] == '#': del filemembers[i] - print _('Ignore : %30(addr)s') + print _('Ignore : %(addr)30s') # first filter out any invalid addresses filemembers = email.Utils.getaddresses(filemembers) From wheakory@isu.edu Mon Mar 18 23:51:47 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Mon, 18 Mar 2002 16:51:47 -0700 Subject: [Mailman-Developers] Problem with mailman 2.0.8 upgrade to Mailman 2.1b1 Message-ID: <3C967D93.58DA839F@isu.edu> Mailman 2.08 was working fine and I decided to upgrade to mailman 2.1b1 and the web interface is fine and it sends out the welcome messages fine. I regenerated the alias file to the new format. I changed the wrapper to mailman in the /etc/smrsh directory. The problem is when I send a message to the list I receive the following error. The original message was received at Mon, 18 Mar 2002 11:41:56 -0500 from ux9-205.isu.edu [134.50.205.114] ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/mailman post korybest" (reason: 2) (expanded from: <korybest@kwlinux.isu.edu>) ----- Transcript of session follows ----- Failure to exec script. WANTED gid 501, GOT gid 12. (Reconfigure to take 12?) 554 5.3.0 unknown mailer error 2 Reporting-MTA: dns; kwlinux.isu.edu Received-From-MTA: DNS; ux9-205.isu.edu Arrival-Date: Mon, 18 Mar 2002 11:41:56 -0500 Final-Recipient: RFC822; korybest@kwlinux.isu.edu X-Actual-Recipient: X-Unix; |/home/mailman/mail/mailman post korybest Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 2 Last-Attempt-Date: Mon, 18 Mar 2002 11:41:56 -0500 I have always used the 501 GID has the group id, I did not specify a different GID in the upgrade when I did the configure, (all I specified was ./configure --prefix=/home/mailman).. How can I reconfigure without losing my lists or starting over. -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From barry@zope.com Tue Mar 19 00:24:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:24:32 -0500 Subject: [Mailman-Developers] erroneous format specification: sync_members References: <20020318234151.GA25572@mawhrin.net> Message-ID: <15510.34112.6216.305139@anthem.wooz.org> >>>>> "MS" == Mikhail Sobolev <mss@mawhrin.net> writes: MS> A small patch to fix it. Got it, thanks! -Barry From barry@zope.com Tue Mar 19 00:39:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:39:32 -0500 Subject: [Mailman-Developers] Modifications to msg References: <5.1.0.14.0.20020318133136.041ee4c8@ella.mills.edu> Message-ID: <15510.35012.847306.245359@anthem.wooz.org> >>>>> "ES" == Ellen Spertus <spertus@mills.edu> writes: ES> I've been making some modifications to Mailman to support ES> dynamic sublists (http://javamlm.mills.edu). I'm still rather ES> new with Python and have a question about modifying fields ES> (dictionary elements) of the msg data structure. It's important to remember that the Message class is not a dictionary, even though it supports dictionary-like syntax. Python is funny in that there is no concrete interface specification, so we tend to say something is "mapping-like" or "file-like" if it supports common methods of those built-in types, but those similes don't really mean anything. But they are amorphous because "file-like" might mean the object supports a write() method with the same signature as a file object's write(), but what does that say about a "file-like" thing's read() method, etc.? Nothing, actually. :) Mapping-like is even more information-free. Usually a mapping-like object supports __getitem__(), and keys(), but does it support items(), values(), setdefault(), etc.? Who knows? <wink> When in doubt, we have to be concrete about what API a class provides or expects, e.g. /this/ method, or /that/ signature. ES> Specifically, I added the following code to change the ES> message's "To" field at the end of CookHeaders.py: | 1 if msgdata.get('dlist'): | 2 threadID = msgdata['thread_id'] | 3 syslog('info', "threadID = %d", threadID) | 4 to_line = '%s-%d@%s' % (mlist.real_name.lower(), | threadID, | mlist.host_name) | 5 syslog('info', "to_line = %s", to_line) | 6 del msg['To'] | 7 msg['To'] = to_line | 8 syslog('info', "Set msg['To'] to '%s'", msg['To']) ES> This correctly changes the "To" field of the message from ES> etest-new@hostname to etest-<threadID>@hostname, as shown by ES> the log: Mar 18 13:29:55 2002 (4600) threadID = 19 Mar 18 ES> 13:29:55 2002 (4600) to_line = etest-19@javamlm.mills.edu Mar ES> 18 13:29:55 2002 (4600) Set msg['To'] to ES> 'etest-19@javamlm.mills.edu' ES> Similarly, the resulting email message that is sent has the ES> new 'To' field. ES> The problem is I don't see why line 6 above is necessary. Here's where the Message class has purposefully different semantics than a dictionary. Specifically, because email messages can have more than one of some kinds of headers, the Message class supports this as well. Therefore __setitem__() -- which is what "msg['to']" maps to -- does not delete existing To: headers. However, I didn't want __getitem__() -- aka msg['to'] -- to return anything but a string, so I decided that in the face of multiple headers, __getitem__() would return "one of them". Which one it returns is purposefully left undetermined. That's why Message.get_all() exists, so that you can get all the To: headers the message might have had. That's also why you must call del first -- aka __delitem__() -- if you want to overwrite all the To: headers. This is all spelled out in the module documentation: http://www.python.org/doc/current/lib/module-email.Message.html Aside: one of the reasons why I want this behavior is because I'd like the Message class (or a derived class possibly) to eventually enforce RFC 2822 rules on the number of specific headers a message can have. E.g. it can have many Received: headers, but only one Reply-To: header (although the latter allows for multiple addresses... go figure). I hope that helps, -Barry From barry@zope.com Tue Mar 19 00:42:07 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:42:07 -0500 Subject: [Mailman-Developers] Problem with mailman 2.0.8 upgrade to Mailman 2.1b1 References: <3C967D93.58DA839F@isu.edu> Message-ID: <15510.35167.232253.4870@anthem.wooz.org> >>>>> "KW" == Kory Wheatley <wheakory@isu.edu> writes: KW> Mailman 2.08 was working fine and I decided to upgrade to KW> mailman 2.1b1 and the web interface is fine and it sends out KW> the welcome messages fine. I regenerated the alias file to the KW> new format. I changed the wrapper to mailman in the /etc/smrsh KW> directory. The problem is when I send a message to the list I KW> receive the following error. I suspect this is caused by a change to the configure script, where it will now use the `mailman' group as the default for --with-mail-gid, if it finds one. Is gid 12 the mailman group? KW> I have always used the 501 GID has the group id, I did not KW> specify a different GID in the upgrade when I did the KW> configure, (all I specified was ./configure KW> --prefix=/home/mailman).. How can I reconfigure without KW> losing my lists or starting over. You definitely do not need to do either such drastic thing! Just re-run configure with --with-mail-gid=501 --prefix=/home/mailman then re-run "make install" and you should be golden. -Barry From barry@zope.com Tue Mar 19 00:49:49 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:49:49 -0500 Subject: [Mailman-Developers] minor config issue: web_page_url is stored in list config References: <9210.1016464833@elisabeth.cfrq.net> Message-ID: <15510.35629.484286.517753@anthem.wooz.org> >>>>> "HK" == Harald Koch <chk@pobox.com> writes: HK> The value for 'web_page_url' is stored in each individual list HK> config file (config.db/config.pck), instead of always being HK> read from mm_cfg.py. However, that variable is not exported by HK> "config_list -o", so it took me a while to figure it out. HK> The workaround for me was to add "web_page_url = HK> 'http://www.cfrq.net/mm/' to my list config and ran HK> "config_list -i"; thankfully that worked. HK> Ideally, I would expect that this variable always be built HK> from mm_cfg; it's a property of the mailman install, not a HK> property of an individual list. As others have pointed out, due to the support for virtual hosts, web_page_url really needs to be a per-list configuration variable. There's a script called "fix_url.py" in the bin directory, which will adjust the web_page_url for any named list. It gets these values from mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.DEFAULT_URL_HOST (aside: it should probably calculate the right value from an inverted search of mm_cfg.VIRTUAL_HOSTS based on the list's host_name attribute). You run this like so (from $prefix directory): % bin/withlist -l -r fix_url mylist Usually a bin/withlist script is much better to write than an input file for bin/config_list, IMO. Hope that helps, -Barry From barry@zope.com Tue Mar 19 00:52:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:52:12 -0500 Subject: [Mailman-Developers] Re: minor config issue: web_page_url is stored in list config References: <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> <9790.1016468430@elisabeth.cfrq.net> <12297.1016479581@elisabeth.cfrq.net> Message-ID: <15510.35772.561757.987262@anthem.wooz.org> >>>>> "HK" == Harald Koch <chk@pobox.com> writes: HK> Especially since it was exported in 2.0.8, as I just HK> discovered while looking for something else... True, but then web_page_url used to be configurable through-the-web. It isn't anymore, because it's quite error prone, and if you f*ck it up, your list will be completely inaccessible except through the command line (i.e. all your urls will be severely busted). So I took it out of the web interface. Really bin/config_list is tied to the web interface, while bin/withlist gives you absolute control over all list object attributes. -Barry From barry@zope.com Tue Mar 19 00:55:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 18 Mar 2002 19:55:12 -0500 Subject: [Mailman-Developers] Modifications to msg References: <5.1.0.14.0.20020318133136.041ee4c8@ella.mills.edu> <15510.35012.847306.245359@anthem.wooz.org> Message-ID: <15510.35952.421615.293584@anthem.wooz.org> Just a quick style nit; I hope you don't mind! | 1 if msgdata.get('dlist'): | 2 threadID = msgdata['thread_id'] | 3 syslog('info', "threadID = %d", threadID) | 4 to_line = '%s-%d@%s' % (mlist.real_name.lower(), ----------------------------------------^^^^^^^^^^^^^^^^^^^^^^^ better to use "mlist.internal_name()". While it's true real_name shouldn't be different except for case changes, I still think internal_name() is more consistent with what Mailman uses internally. | threadID, | mlist.host_name) | 5 syslog('info', "to_line = %s", to_line) | 6 del msg['To'] | 7 msg['To'] = to_line | 8 syslog('info', "Set msg['To'] to '%s'", msg['To']) -Barry From spertus@mills.edu Tue Mar 19 00:57:30 2002 From: spertus@mills.edu (Ellen Spertus) Date: Mon, 18 Mar 2002 16:57:30 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <15510.35012.847306.245359@anthem.wooz.org> References: <5.1.0.14.0.20020318133136.041ee4c8@ella.mills.edu> Message-ID: <5.1.0.14.0.20020318165655.043b8d40@ella.mills.edu> >I hope that helps, It's very helpful. Thank you. Ellen From spertus@mills.edu Tue Mar 19 01:03:14 2002 From: spertus@mills.edu (Ellen Spertus) Date: Mon, 18 Mar 2002 17:03:14 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <15510.35952.421615.293584@anthem.wooz.org> References: <5.1.0.14.0.20020318133136.041ee4c8@ella.mills.edu> <15510.35012.847306.245359@anthem.wooz.org> Message-ID: <5.1.0.14.0.20020318170245.04351cf8@ella.mills.edu> At 07:55 PM 3/18/2002 -0500, Barry A. Warsaw wrote: >Just a quick style nit; I hope you don't mind! > > | 1 if msgdata.get('dlist'): > | 2 threadID = msgdata['thread_id'] > | 3 syslog('info', "threadID = %d", threadID) > | 4 to_line = '%s-%d@%s' % (mlist.real_name.lower(), >----------------------------------------^^^^^^^^^^^^^^^^^^^^^^^ > >better to use "mlist.internal_name()". Not at all. Thanks. Ellen From Dan Mick <dmick@utopia.West.Sun.COM> Tue Mar 19 02:56:29 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Mon, 18 Mar 2002 18:56:29 -0800 (PST) Subject: [Mailman-Developers] Modifications to msg Message-ID: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> > RFC 2822 rules on the number of specific headers a message can have. > E.g. it can have many Received: headers, but only one Reply-To: header > (although the latter allows for multiple addresses... go figure). Ease of parsing. No one but humans typically looks at Received:, but dumb MUAs need to use Reply-To:, so complicated tricks for accumulating a list are limited there. (at least that's what I'd guess at for a rationale.) From mentor@alb-net.com Tue Mar 19 03:03:51 2002 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 18 Mar 2002 22:03:51 -0500 (EST) Subject: [Mailman-Developers] a success! from 2.0.8 to 2.1b1 :) Message-ID: <Pine.GSO.4.44.0203182147210.10162-100000@alb-net.com> I would like to report a succesful upgrade from 2.0.8 to 2.1b1. :) Besides for some small things, the upgrade went fine; per list options and per subscriber options migrated all fine. Obviously, I had to create the default site list, regenerate the aliases file, make sure that qfile/ was empty, go through the mm_cfg.py (which I still have to do more work for fine-tuning), did a backup on few files (in addition to tar-in the entire installation of mailman2.0.8; which does not seem I will need :)), an few other maintenance things. Here are few 'problems': 1. logs/error file logged bunch of errors [see bellow] about corrupt list config files. nevertheless, the lists got upgraded fine. 2. Whatever held messages were in data/ migrated fine. I could approve and reject files on various lists. However, one of the lists (my test-l list) reports an error/bug when clicking on "Tend to pending moderator requests". See bellow for the error. So far I have seen this error on one list. 3. The list archives didn't show until I sent a message to the list, or until I ran the bin/arch <list-name>. I consider these few things not to be substantial problems. :) To MM developers and the support team: EXCELLENT JOB! :) -- Mentor ------------------ Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck.last Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck.last Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck.last Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck Mar 18 18:47:16 2002 (26826) test-l config file was corrupt, trying fallback: /opt/home/mailman/lists/test-l/config.pck.last Mar 18 18:47:17 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck Mar 18 18:47:17 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck.last Mar 18 18:47:17 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck Mar 18 18:47:17 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck.last Mar 18 18:47:18 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck Mar 18 18:47:18 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck.last Mar 18 18:47:18 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck Mar 18 18:47:18 2002 (26826) listowners-l config file was corrupt, trying fallback: /opt/home/mailman/lists/listowners-l/config.pck.last ------------------ ------------------ Mar 18 19:03:10 2002 admin(27321): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(27321): [----- Mailman Version: 2.1b1 -----] admin(27321): [----- Traceback ------] admin(27321): Traceback (most recent call last): admin(27321): File "/opt/home/mailman/scripts/driver", line 82, in run_main admin(27321): main() admin(27321): File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 219, in main admin(27321): show_pending_subs(mlist, form) admin(27321): File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 274, in show_pending_subs admin(27321): time, addr, fullname, passwd, digest, lang = mlist.GetRecord(id) admin(27321): ValueError: unpack tuple of wrong size ------------------ From chk@pobox.com Tue Mar 19 03:17:00 2002 From: chk@pobox.com (Harald Koch) Date: Mon, 18 Mar 2002 22:17:00 -0500 Subject: [Mailman-Developers] Re: minor config issue: web_page_url is stored in list config In-Reply-To: barry's message of "Mon, 18 Mar 2002 19:52:12 -0500". <15510.35772.561757.987262@anthem.wooz.org> References: <Pine.OSX.4.44.0203181103310.12957-100000@core.newfield.org> <9790.1016468430@elisabeth.cfrq.net> <12297.1016479581@elisabeth.cfrq.net> <15510.35772.561757.987262@anthem.wooz.org> Message-ID: <17416.1016507820@elisabeth.cfrq.net> Of all the gin joints in all the towns in all the world, Barry A. Warsaw had to walk into mine and say: > > Really bin/config_list is tied to the web interface, I figured as much. > There's a script called "fix_url.py" in the bin directory, which will > adjust the web_page_url for any named list. Thanks for the pointer; I missed that. Btw, the "web_page_url" issue was the only problem I had with simply moving mailing lists (by moving the files) from my 2.0.8 system to my 2.1b1 system. Congratulations, guys! -- Harald Koch <chk@pobox.com> From mentor@alb-net.com Tue Mar 19 03:28:15 2002 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 18 Mar 2002 22:28:15 -0500 (EST) Subject: [Mailman-Developers] a bug? the latest CVS (2.1b1) Message-ID: <Pine.GSO.4.44.0203182224300.10162-100000@alb-net.com> The "Emergency moderation of all list traffic" check-box does not stay checked beyond the current session. If you "Logout" and login back that the check-box is uncheck and the red-color disappears. -- Mentor From jwblist@olympus.net Tue Mar 19 03:28:59 2002 From: jwblist@olympus.net (John W Baxter) Date: Mon, 18 Mar 2002 19:28:59 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> References: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> Message-ID: <p05101505b8bc5da4dfe1@[207.149.192.229]> At 18:56 -0800 3/18/2002, Dan Mick wrote: >> RFC 2822 rules on the number of specific headers a message can have. >> E.g. it can have many Received: headers, but only one Reply-To: header >> (although the latter allows for multiple addresses... go figure). > >Ease of parsing. No one but humans typically looks at Received:, >but dumb MUAs need to use Reply-To:, so complicated tricks for >accumulating a list are limited there. (at least that's what >I'd guess at for a rationale.) There is rather tortured logic in the old (and maybe new) documents justifying the ability to have multiple addresses in the single From: header. Personally, I've never sent or received one of those, even as a test message (I'm sure to get one now, having said that ;-)). The other side of the coin is that there almost have to be multiple received headers (OK, there could be one, munged some more by each handling MTA, but that sounds dangerous for several reasons including ultimate size), since multiple MTAs along the message's travel MUST each include a Received: header (or would have to stick the information into the one Received: header given the other rule). And, of course, too many hops would be harder if the MTAs had to unwind a 30 sub-item Received: header. So let's turn the question around: of what headers is there a logical reason for multiples. 1. Received, for the reasons mentioned. 2. X-anything (I suspect, since there's little control over those) But not Date: (despite the appearance of multiple ones of those in some messages) and several others. Reply to: ?? There probably shouldn't be huge numbers of Reply to: addresses. Multiple addresses are probably allowed on the same sort of reasoning as multiple addresses in From:--the boss and the secretary thing. (Unlimited reply to headers sounds like a great way to get a Spam multiplier effect, but that wasn't a consideration at RFC writing time.) And remember, too, that some things in RFCs are the way they are because that's the way they are (and are hard to explain any other way). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Dan Mick <dmick@utopia.West.Sun.COM> Tue Mar 19 03:47:30 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Mon, 18 Mar 2002 19:47:30 -0800 (PST) Subject: [Mailman-Developers] Modifications to msg Message-ID: <200203190347.g2J3ldWk007531@utopia.West.Sun.COM> > There is rather tortured logic in the old (and maybe new) documents > justifying the ability to have multiple addresses in the single From: > header. Personally, I've never sent or received one of those, even as a > test message (I'm sure to get one now, having said that ;-)). Geek wedding announcements? :) :) > And remember, too, that some things in RFCs are the way they are because > that's the way they are (and are hard to explain any other way). surely true. And the point about "there sorta must be multiple Received:s" is of course well-taken. From claw@kanga.nu Tue Mar 19 04:12:54 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 18 Mar 2002 20:12:54 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: Message from John W Baxter <jwblist@olympus.net> of "Mon, 18 Mar 2002 19:28:59 PST." <p05101505b8bc5da4dfe1@[207.149.192.229]> References: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> <p05101505b8bc5da4dfe1@[207.149.192.229]> Message-ID: <21042.1016511174@kanga.nu> On Mon, 18 Mar 2002 19:28:59 -0800 John W Baxter <John> wrote: > (Unlimited reply to headers sounds like a great way to get a Spam > multiplier effect, but that wasn't a consideration at RFC writing > time.) RFC 2822 explicitly states that Reply-To can contain a list of headers. RFC 822 is more ambiguous. To my mind this single fact (if used with Reply-To aggregation) obviates most of the arguments in the Reply-To Munging Considered Harmful document. -- 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 marc_news@vasoftware.com Tue Mar 19 06:42:16 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 18 Mar 2002 22:42:16 -0800 Subject: [Mailman-Developers] rejecting messages depending on To:/Cc: content Message-ID: <20020319064215.GC3887@merlins.org> Just to make sure I got this right: If I go to (let's say): http://lists.svlug.org/lists/admin/speakers/privacy/spam I can set values in acceptable_aliases In http://lists.svlug.org/lists/admin/speakers/privacy/sender I can get mailman to auto-reject or discard messages depending on the sender So is there a way to apply the auto-reject or auto-discard on values in the privacy/spam page? (not to worry, if the ansewr is "no", this isn't an official feature request, we gotta stop somewhere :-D) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spertus@mills.edu Tue Mar 19 07:01:14 2002 From: spertus@mills.edu (Ellen Spertus) Date: Mon, 18 Mar 2002 23:01:14 -0800 Subject: [Mailman-Developers] Restrictions on listnames? Message-ID: <5.1.0.14.0.20020318225649.044c0a70@ella.mills.edu> Are there any restrictions on list names? The only implicit restriction I can see in the source is that they can't contain "@" (for good reason). For my modifications, I'd like to be able to assume a specific character (I don't care which) is a delimiter, not part of a list name. Suggestions? Ellen Spertus From R.Barrett@ftel.co.uk Tue Mar 19 09:04:09 2002 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Tue, 19 Mar 2002 09:04:09 +0000 Subject: [Mailman-Developers] Restrictions on listnames? In-Reply-To: <5.1.0.14.0.20020318225649.044c0a70@ella.mills.edu> Message-ID: <5.1.0.14.2.20020319090254.02d271e0@pop.ftel.co.uk> At 23:01 18/03/2002 -0800, Ellen Spertus wrote: >Are there any restrictions on list names? The only implicit restriction I >can see in the source is that they can't contain "@" (for good reason). > >For my modifications, I'd like to be able to assume a specific character >(I don't care which) is a delimiter, not part of a list name. > >Suggestions? Mailman's source code probably doesn't impose enough restrictions to prevent list admins getting into trouble. Your list name will have to serve as: 1. an addr-spec as defined in section 3.4.1 of rfc 2822 2. a directory name in the file system 3. part of a URL path Prgmatically, you probably want list names that are straightforward to enter on the command line and do not include characters that have to be escaped in URLs (&, + and such). Also kepp in mind that there are a set of mail aliases for each list: <listname>, <listname>-owner, <listname>-request ... If it were me I'd stick to a-z, A-Z, 0-9 and - (hyphen) and keep my sanity. >Ellen Spertus > > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers From chk@pobox.com Tue Mar 19 16:16:33 2002 From: chk@pobox.com (Harald Koch) Date: Tue, 19 Mar 2002 11:16:33 -0500 Subject: [Mailman-Developers] 2.1b1: admin_member_chunksize handling? Message-ID: <21918.1016554593@elisabeth.cfrq.net> I liked the old way, where I just get 'n' members of the list at a time on each page. Most of my lists have more than chunksize members, but less than 2*chunksize; one has about 5*chunksize. In other words, my lists aren't large enough to require splitting alphabetically; I get many pages with only one or two addresses on them, which makes it harder to step through the whole list. I don't really want to bump 'chunksize' up to the largest possible number, because that *will* make the HTML screens kinda large for browsers like 'links'. The logic seems to be hardcoded in admin.py; is there any chance of restoring the option of simply displaying chunksize members per page? -- Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry From Dan Mick <dmick@utopia.West.Sun.COM> Tue Mar 19 20:47:22 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Tue, 19 Mar 2002 12:47:22 -0800 (PST) Subject: [Mailman-Developers] 2.1b1: admin_member_chunksize handling? Message-ID: <200203192047.g2JKlWWk005441@utopia.West.Sun.COM> > I liked the old way, where I just get 'n' members of the list at a time > on each page. Yeah, I kinda did too. My ideal would probably be "show me N" with the "search by RE" box at the top. From fil@rezo.net Wed Mar 20 09:53:42 2002 From: fil@rezo.net (Fil) Date: Wed, 20 Mar 2002 10:53:42 +0100 Subject: [Mailman-Developers] bug in the interface ? (new_member_options) Message-ID: <20020320095342.GB5998@rezo.net> Hi, the new_member_options pane in general settings does not work with my server/browser : I suspect it's because all check boxes have the same name (new_member_options)... -- Fil From jra@baylink.com Wed Mar 20 19:53:11 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Mar 2002 14:53:11 -0500 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <21042.1016511174@kanga.nu>; from J C Lawrence <claw@kanga.nu> on Mon, Mar 18, 2002 at 08:12:54PM -0800 References: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> <p05101505b8bc5da4dfe1@[207.149.192.229]> <jwblist@olympus.net> <21042.1016511174@kanga.nu> Message-ID: <20020320145311.65117@scfn.thpl.lib.fl.us> On Mon, Mar 18, 2002 at 08:12:54PM -0800, J C Lawrence wrote: > On Mon, 18 Mar 2002 19:28:59 -0800 > John W Baxter <John> wrote: > > > (Unlimited reply to headers sounds like a great way to get a Spam > > multiplier effect, but that wasn't a consideration at RFC writing > > time.) > > RFC 2822 explicitly states that Reply-To can contain a list of > headers. RFC 822 is more ambiguous. To my mind this single fact (if > used with Reply-To aggregation) obviates most of the arguments in the > Reply-To Munging Considered Harmful document. The Linux Answer Gang list at ssc.com uses multi-player Reply-to's. It confused me at first, because I keep Mutt set to prompt, and it only prompts for the *first* address in the list -- subsequently giving you and edit-mode prompt showing all the reply-to's, which it handles correctly. Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jarrell@vt.edu Wed Mar 20 20:45:09 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 20 Mar 2002 15:45:09 -0500 Subject: [Mailman-Developers] a bug? the latest CVS (2.1b1) In-Reply-To: <Pine.GSO.4.44.0203182224300.10162-100000@alb-net.com> Message-ID: <5.1.0.14.2.20020320151344.0acfd8a0@lennier.cc.vt.edu> At 10:28 PM 3/18/02 -0500, Mentor Cana wrote: >The "Emergency moderation of all list traffic" check-box does not stay >checked beyond the current session. If you "Logout" and login back that the >check-box is uncheck and the red-color disappears. I'm seeing the same thing. The config.pck file does have an emergency attribute, which is set at 0, so it doesn't look like that setting is actually getting saved into the pickle. In admin.py I note that it's built as a CheckBox('emergency', 1, mlist.emergency).. is using a "1" there functionally equivalent to saying "on" or "off" like it's used every where else? I'm thinking that safeint is forcing it to 0 when it's saving it, because it's coming back as "on" or "off", and safeint is expecting a number. (As an aside... Is there any reason to keep the .db files? They're version 36 and we're at version 68... I certainly hope nothing is using them..) From marc_news@vasoftware.com Wed Mar 20 16:17:03 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed Mar 20 16:17:02 2002 Subject: [Mailman-Developers] Are digests broken in mailman 2.1b1? Message-ID: <20020320211210.GB20264@merlins.org> [resending with correct From:] On my live/test system, mailman has been sending empty digests since last friday (when I upgraded to 2.1a4++ and later b1) Is this just me? What I get is exactly: ---------------------------------------------------------------------------- From: svlug-request@svlug.org Subject: svlug Digest, Vol 28, Issue 2 To: svlug@svlug.org X-BeenThere: svlug@lists.svlug.org X-Mailman-Version: 2.1b1 Precedence: bulk List-Help: <mailto:svlug-request@lists.svlug.org?subject=help> List-Post: <mailto:svlug@lists.svlug.org> List-Subscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=subscribe> List-Id: discussion list for the Silicon Valley Linux Users Group. <svlug.lists.svlug.org> List-Unsubscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=unsubscribe> List-Archive: http://lists.svlug.org/archives/svlug/ Content-Type: multipart/mixed; boundary="===============9383223389590416=="; charset="en" Content-Transfer-Encoding: base64 Sender: svlug-bounces+marc=merlins.org@svlug.org Errors-To: svlug-bounces+marc=merlins.org@lists.svlug.org Message-Id: <E16nmGE-0005Jv-00@mail.svlug.org> Date: Wed, 20 Mar 2002 12:00:38 -0800 X-Spam-Status: No, hits=0.6 required=8.0 tests=NO_REAL_NAME version=2.11 Content-Length: 11689 Lines: 337 ---------------------------------------------------------------------------- The mail stops here, there is no body whatsoever. It's not just me, I only subscribed as digest because my users told me it was broken. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Mar 21 07:04:12 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 20 Mar 2002 23:04:12 -0800 Subject: [Mailman-Developers] Does anyone have digests working with mailman 2.1b1? In-Reply-To: <20020320211210.GB20264@merlins.org> References: <20020320211210.GB20264@merlins.org> Message-ID: <20020321070411.GA29246@merlins.org> On Wed, Mar 20, 2002 at 09:12:10PM +0000, Marc MERLIN wrote: > On my live/test system, mailman has been sending empty digests since last > friday (when I upgraded to 2.1a4++ and later b1) > > Is this just me? > > What I get is exactly: ---------------------------------------------------------------------------- From: svlug-request@svlug.org Subject: svlug Digest, Vol 28, Issue 2 To: svlug@svlug.org X-BeenThere: svlug@lists.svlug.org X-Mailman-Version: 2.1b1 Precedence: bulk List-Help: <mailto:svlug-request@lists.svlug.org?subject=help> List-Post: <mailto:svlug@lists.svlug.org> List-Subscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=subscribe> List-Id: discussion list for the Silicon Valley Linux Users Group. <svlug.lists.svlug.org> List-Unsubscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=unsubscribe> List-Archive: http://lists.svlug.org/archives/svlug/ Content-Type: multipart/mixed; boundary="===============9383223389590416=="; charset="en" Content-Transfer-Encoding: base64 Sender: svlug-bounces+marc=merlins.org@svlug.org Errors-To: svlug-bounces+marc=merlins.org@lists.svlug.org Message-Id: <E16nmGE-0005Jv-00@mail.svlug.org> Date: Wed, 20 Mar 2002 12:00:38 -0800 X-Spam-Status: No, hits=0.6 required=8.0 tests=NO_REAL_NAME version=2.11 Content-Length: 11689 Lines: 337 ---------------------------------------------------------------------------- > > The mail stops here, there is no body whatsoever. Ok, after clearing my CVS tree, re-installing mailman from a freshly built CVS tree, and restarting the qrunners, I still get this: I just got digest #3, and again, the body is absolutely empty. Before I go debugging this: am I the only one for whom digests are broken in this way? Or the other way: do you have digests with mailman 2.1b1 working for you? Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 21 20:21:47 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Thu, 21 Mar 2002 12:21:47 -0800 (PST) Subject: [Mailman-Developers] Does anyone have digests working with mailman 2.1b1? Message-ID: <200203212021.g2LKLxWk022954@utopia.West.Sun.COM> > > Is this just me? Digests are still working on my list. From mentor@alb-net.com Thu Mar 21 20:37:56 2002 From: mentor@alb-net.com (Mentor Cana) Date: Thu, 21 Mar 2002 15:37:56 -0500 (EST) Subject: [Mailman-Developers] Does anyone have digests working with mailman 2.1b1? In-Reply-To: <200203212021.g2LKLxWk022954@utopia.West.Sun.COM> Message-ID: <Pine.GSO.4.44.0203211535340.1436-100000@alb-net.com> On Thu, 21 Mar 2002, at 12:21 -0800, Dan Mick wrote: > > > > Is this just me? > > Digests are still working on my list. > Same here.... digests are working on my lists. However, my cron/checkdbs is not working yet. Actually, it is working in my test installation and it isn't working in my production (upgraded from 2.0.8). I get the following: ValueError: unpack tuple of wrong size -- Mentor From danovaro@publinet.it Fri Mar 22 11:10:53 2002 From: danovaro@publinet.it (stefano danovaro) Date: Fri, 22 Mar 2002 12:10:53 +0100 (CET) Subject: [Mailman-Developers] Mailman has found an unexpected error Message-ID: <1016795453.3c9b113d1566e@webmail.publinet.it> Hello! I've mailman version 2.1b1. I've received this email from mailman Mailman has found an unexpected error in MailCommandHandler.ParseMailCommands(). Here the tracing: Traceback (most recent call last): File "/home/mailman/Mailman/MailCommandHandler.py", line 273, in ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/home/mailman/Mailman/MailCommandHandler.py", line 727, in ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/home/mailman/Mailman/MailList.py", line 980, in ProcessConfirmation addr = userdesc.address AttributeError: address Is it a bug o Is it a my error? thanks+, Stefano -------------------------------------------------------------------------------- Stefano Danovaro <danovaro@publinet.it> SIR s.r.l. - Soluzioni In Rete Via XX Settembre 3/6 - 16121 GENOVA http://www.publinet.it/ 16121 GENOVA - Italy ________________________________________________________ From totschnig.michael@uqam.ca Fri Mar 22 14:53:50 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Fri, 22 Mar 2002 09:53:50 -0500 Subject: [Mailman-Developers] message is unparsable and lost data files for filebase Message-ID: <86ofhglkld.fsf@cmo.uqam.ca> Hello, I've got the following two lines in a recent CVS Mailman's error log. Mar 20 13:14:52 2002 (29950) message is unparsable: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b Mar 20 13:14:52 2002 (29950) lost data files for filebase: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b Is this something I should worry about? The message it is talking about, is it a mail Mailman should have processed. There is no entry at that time in the post log. Regards, Michael From dmick@utopia.West.Sun.COM Fri Mar 22 21:04:00 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Fri, 22 Mar 2002 13:04:00 -0800 Subject: [Mailman-Developers] message is unparsable and lost data files for filebase References: <86ofhglkld.fsf@cmo.uqam.ca> Message-ID: <3C9B9C40.71A3BC6A@utopia.west.sun.com> totschnig.michael@uqam.ca wrote: > > Hello, > > I've got the following two lines in a recent CVS Mailman's error log. > > Mar 20 13:14:52 2002 (29950) message is unparsable: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b > Mar 20 13:14:52 2002 (29950) lost data files for filebase: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b > > Is this something I should worry about? The message it is talking > about, is it a mail Mailman should have processed. There is no entry > at that time in the post log. You can probably find it in the qfiles/bad directory, and it's probably a mis-formatted MIME message. From totschnig.michael@uqam.ca Fri Mar 22 21:59:07 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Fri, 22 Mar 2002 16:59:07 -0500 Subject: [Mailman-Developers] Re: message is unparsable and lost data files for filebase In-Reply-To: <3C9B9C40.71A3BC6A@utopia.west.sun.com> (Dan Mick's message of "Fri, 22 Mar 2002 13:04:00 -0800") References: <86ofhglkld.fsf@cmo.uqam.ca> <3C9B9C40.71A3BC6A@utopia.west.sun.com> Message-ID: <86sn6s2ris.fsf@cmo.uqam.ca> Dan Mick <dmick@utopia.West.Sun.COM> wrote: > totschnig.michael@uqam.ca wrote: > > >> Hello, >> >> I've got the following two lines in a recent CVS Mailman's error log. >> >> Mar 20 13:14:52 2002 (29950) message is unparsable: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b >> Mar 20 13:14:52 2002 (29950) lost data files for filebase: 1016648091.497946+bac3be516f3338dba5c030fac9372443209a4c6b >> >> Is this something I should worry about? The message it is talking >> about, is it a mail Mailman should have processed. There is no entry >> at that time in the post log. > > You can probably find it in the qfiles/bad directory, and it's probably > a mis-formatted MIME message. Thank you for your reply! Unfortunately there is no bad directory in the qfiles directory. It only contains, the following. archive bounces commands in news out shunt virgin But by comparing with the MTA's log file, I could understand that the message in question has probably been spam. Is there another place where mailman could have put it for inspection, or do I have to change the configuration to keep track of such problems? Michael From spertus@mills.edu Sat Mar 23 01:13:55 2002 From: spertus@mills.edu (Ellen Spertus) Date: Fri, 22 Mar 2002 17:13:55 -0800 Subject: [Mailman-Developers] How to share Mailman extensions Message-ID: <5.1.0.14.0.20020322165705.031bd760@ella.mills.edu> I'm wondering how best to share my Mailman extensions, assuming they're useful to anyone besides me. For now, I've created a project at sourceforge.net (http://sourceforge.net/projects/dsub/) and released a tarball containing the files I've modified or created. The code is pre-alpha at this point. I hope to have an alpha version by the end of this weekend. While I hope my changes will eventually be incorporated into Mailman, the time has clearly not yet arrived. Any advice on whether to start my own branch of the Mailman CVS tree now or to keep hacking separately until when and if my code is incorporated? When I upload the alpha code, I'll also post a design doc and ask for criticism. I've attached my original description of my changes. Ellen FUNCTIONALITY A user of mailing list foo creates a new thread with a base name of bar by sending email to foo-new-bar@host. The system appends an integer to bar to generate a unique thread name, e.g., bar1. All subscribers to mailing list foo receive the first message of any thread. The message headers are: To: foo-bar1@host From: original-sender@wherever If a user chooses reply, the new message goes to the original sender (assuming a decent MUA). It a user chooses reply-all, the new message becomes part of the thread bar1. When subscribing (or subsequently), each user specifies whether they want to be subscribed to new threads by default. If so, the user gets all messages in a new thread (unless they explicitly unsubscribe). If a user chooses NOT to be subscribed to new threads by default, they only get the initial message unless they explicitly subscribe. Each message contains (un)subscribe information both as a URL and mailto to make the operations as lightweight as possible; e.g., To unsubscribe from this conversation, send email to foo-bar1-unsubscribe@javamlm.mills.edu or visit http://javamlm.mills.edu/scripts/override?listname=foo&conversation=14&preference=0. To unsubscribe from foo, send email to foo-unsubscribe@javamlm.mills.edu. Note that thread membership is determined solely by the address to which a message is sent, not the message's subject, references, or other headers. IMPLEMENTATION We implemented threads by including a threadID in each message's metadata, which was stored in a relational database, as was information about each thread, subscription, etc. The following SQL query determines to whom to send a message in thread 37: SELECT email FROM Subscriber WHERE deleted = FALSE AND ((Subscriber.preference = 1 AND NOT EXISTS (SELECT * FROM Override WHERE Override.subscriber_id = Subscriber.subscriber_id AND Override.thread_id = 37 AND Override.preference = 0)) OR (Subscriber.preference = 0 AND EXISTS (SELECT * FROM Override WHERE Override.subscriber_id = Subscriber.subscriber_id AND Override.thread_id = 37 AND Override.preference = 1))) The full schema is in the paper. I'm including the query here to give you an idea of the complexity and to show that list membership is calculated on the fly. From brett@cfsc.ottawa.on.ca Sun Mar 17 00:31:01 2002 From: brett@cfsc.ottawa.on.ca (Brett Delmage) Date: Sat, 16 Mar 2002 19:31:01 -0500 (EST) Subject: [Mailman-Developers] is it me? In-Reply-To: <20020315154550.GB13758@rezo.net> Message-ID: <Pine.LNX.4.33.0203161923560.13531-100000@pannier.cfsc.ottawa.on.ca> On Fri, 15 Mar 2002, Fil wrote: > Am I the only stupid guy running mailman cvs on a server with many lists? > ;-) No, I am using it for 3 low-traffic "internal committee" lists here now. I figure helping test and find the bugs is the least I can do for free software, being as I am not up to coding python yet (I'm an embedded systems C programmer during my day job.) My users don't always appreciate this(!) but as they are and work with volunteers too they understand that they're part of the Mailman team and helping out simply by using the system. As CfSC uses a lot of free software it's the least we can do... Brett volunteer IT support, Citizens for Safe Cycling From jmeurer@gmx.de Sun Mar 17 12:02:58 2002 From: jmeurer@gmx.de (Jonas Meurer) Date: Sun, 17 Mar 2002 13:02:58 +0100 Subject: [Mailman-Developers] bug at mailman-21 playground Message-ID: <20020317120258.GB1357@jonas.server0.de> Hello, I found a bug at the playground on mail.python.org/mailman-21/listinfo/playground. I tested the languages and when I changed from traditional Chinese to German the bugreport came. This problem comes allways you change from Chinese to German. Here's a copy of the bugreport I got: --- Traceback: Traceback (most recent call last): File "/usr/local/mailman-2.1/scripts/driver", line 82, in run_main main() File "/usr/local/mailman-2.1/Mailman/Cgi/subscribe.py", line 70, in main i18n.set_language(language) File "/usr/local/mailman-2.1/Mailman/i18n.py", line 33, in set_language language) File "/usr/local/lib/python2.1/gettext.py", line 236, in translation mofile = find(domain, localedir, languages) File "/usr/local/lib/python2.1/gettext.py", line 216, in find for nelang in _expand_lang(lang): File "/usr/local/lib/python2.1/gettext.py", line 60, in _expand_lang locale = normalize(locale) File "/usr/local/lib/python2.1/locale.py", line 216, in normalize fullname = localename.lower() AttributeError: lower --- I tested changing the languages in many other directions and ways, and these changes produce the same error: Traditional Chinese -> every language, also traditional Chinese itself. Simplified Chinese -> every language, also simplified Chinese itself. Another problem: If I change from any language to Simplified Chinese the Layout changes a bit. Also from any language to Traditional Chinese. Bye Jonas -- Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon From ice1@austarnet.com.au Mon Mar 18 03:59:16 2002 From: ice1@austarnet.com.au (Craig Grose) Date: Mon, 18 Mar 2002 13:29:16 +0930 Subject: [Mailman-Developers] RE: [Mailman-Announce] RELEASED Mailman 2.1 beta 1 In-Reply-To: <15508.11919.910981.756175@anthem.wooz.org> Message-ID: <000601c1ce31$8c7d8440$9ceadccb@Craig> Please take me off your mailing list. Thankyou. Craig Grose NT Area Manager ICE (NT) Pty Ltd Email : cgrose@iceholdings.com.au Phone: 61 8 89471200 Fax : 61 8 89472822 Mobile: 0417 988 723 -----Original Message----- From: mailman-announce-admin@python.org [mailto:mailman-announce-admin@python.org] On Behalf Of Barry A. Warsaw Sent: Sunday, 17 March 2002 3:20 PM To: mailman-announce@python.org Cc: mailman-users@python.org; mailman-developers@python.org Subject: [Mailman-Announce] RELEASED Mailman 2.1 beta 1 I've released Mailman 2.1 beta 1; see below for a list of changes since version 2.1 alpha 4. There have been tons of bug fixes, several new languages, and lots of new features. We're finally in feature freeze for Mailman 2.1, although I reserve the right to classify an essential missing feature as a bug <wink>. I'd like to get 2.1 final out soon, and I think it's only fair that we eat our own dogfood before offering it to others, so I'll soon be transfering the mailman-* lists to the new version. Please report all bugs to SourceForge. Discussions about version 2.1 are preferred on mailman-developers. I'd also like to announce the mailman-docs@python.org mailing, which indeed is running under 2.1b1. This list will help coordinate the Mailman documentation effort, so if you'd like to contribute please join that list. This is a great way to help us out, even if you aren't into hacking the code. Enjoy, -Barry -------------------- snip snip -------------------- 2.1 beta 1 (16-Mar-2002) In addition to the usual bug fixes, performance improvements, and GUI changes, here are the highlights: - MIME and other message handling o More robustness against badly MIME encapsulated messages: if a MessageParseError is raised during the initial parse, the message can either be discarded or saved in qfiles/bad, depending on the value of the new configuration variable QRUNNER_SAVE_BAD_MESSAGES. o There is a new per-user option that can be used to avoid receipt of extra copies, when a member of the list is also explicitly CC'd. o Always add an RFC 2822 Date: header if missing, since not all MTAs insert one automatically. o The Sender: and Errors-To: headers are no longer added to outgoing messages. o Headers and footers are always added by concatenation, if the message is not MIME and if the list's charset is a superset of us-ascii. - List administration o An `invitation' feature has been added. This is selectable as a radio button on the mass subscribe page. When selected, users are invited to join instead of immediately joined, i.e. they get a confirmation message. o You can now enable and disable list owner notifications for disabled-due-to-bouncing and removal-due-to-bouncing actions. The site config variables DEFAULT_BOUNCE_NOTIFY_OWNER_ON_DISABLE and DEFAULT_BOUNCE_NOTIFY_OWNER_ON_REMOVAL control the default behavior. o List owners can now decide whether they receive unrecognized bounce messages or not (i.e. messages that the bounce processor doesn't recognize). Site admins can set the default value for this flag with the config variable DEFAULT_BOUNCE_UNRECOGNIZED_GOES_TO_LIST_OWNER. o The admindb summary page gives the option of clearing the moderation flag of members who are on quarantined. o The action to take when a moderated member posts to a list is now configurable. The message can either be held, rejected (bounced), or discarded. If the message is rejected, a rejection notice string can be given. o In the General admin page, you can now set the default value for five per-user flags: concealing the user's email address, acknowledging posts sent by the user, copy suppression, not-me-too selection, and the default digest type. Site admins can set the default bit field with the new DEFAULT_NEW_MEMBER_OPTIONS variable. o A new "Emergency brake" feature for turning on moderation of all list postings. This is useful for when flamewars break out, and the list needs a cooling off period. Messages containing an Approved: header with the list owner password are still allowed through, as are messages approved through the admindb interface. o When a moderated message is approved for the list, add an X-Mailman-Approved-At: header which contains the timestamp of the approval action (changed from X-Moderated: with a different format). o Lists can now be converted to using a less error prone mechanism for variable substitution syntax in headers and footers. Instead of %(var)s strings, you'd use $var strings. You must use "bin/withlist -r convert" to enable this. o When moderating held messages, the header text box and the message excerpt text box are now both read-only. o You can't delete the site list through the web. o When creating new lists through the web, you have the option of setting the "default member moderation" flag. - Security and privacy o New feature: banned subscription addresses. Privacy options/subscription rules now have an additional list box which can contain addresses or regular expressions. Subscription requests from any matching address are automatically rejected. o Membership tests which compare message headers against list rosters are now more robust. They now check, by default these header in order: From:, unixfrom, Reply-To:, Sender:. If any match, then the membership test succeeds. o ALLOW_SITE_ADMIN_COOKIES is a new configuration variable which says whether to allow AuthSiteAdmin cookies or not. Normally, when a list administrator logs into a list with the site password, they are issued a cookie that only allows them to do administration for this one list. By setting ALLOW_SITE_ADMIN_COOKIES to 1, the user only needs to authenticate to one list with the site password, and they can administer any mailing list. I'm not sure this feature is wise, so the default value for ALLOW_SITE_ADMIN_COOKIES is 0. o Marc MERLIN's new recipes for secure Linuxes have been updated. o DEFAULT_PRIVATE_ROSTER now defaults to 1. o Passwords are no longer included in the confirmation pages. - Internationalization o With the approval of Tamito KAJIYAMA, the Japanese codes for Python are now included automatically, so you don't need to download and install these separate. It is installed in a Mailman-specific place so it won't affect your larger Python installation. o The configure script will produce a warning if the Chinese codes are not installed. This is not a fatal error. o Russian templates and catalogs have been added. o Finnish templates and catalogs have been added. - Scripts and utilities o New program bin/unshunt to safely move shunted messages back into the appropriate processing queue. o New program bin/inject for sending a plaintext message into the incoming queue from the command line. o New cron script cron/disabled for periodically culling the disabled membership. o bin/list_members has grown some new command line switches for filtering on different criteria (digest mode, disable mode, etc.) o bin/remove_members has grown the --fromall switch. o You can now do a bin/rmlist -a to remove an archive even after the list has been deleted. o bin/update removes the $prefix/Mailman/pythonlib directory. o bin/withlist grows a --all/-a flag so the --run/-r option can be applied to all the mailing lists. Also, interactive mode is now the default if -r isn't used. You don't need to run this script as "python -i bin/withlist" anymore. o There is a new script contrib/majordomo2mailman.pl which should ease the transition from Majordomo to Mailman. - MTA integration o Postfix integration has been made much more robust, but now you have to set POSTFIX_ALIAS_CMD and POSTFIX_MAP_CMD to point to the postalias and postmap commands respectively. o VERP-ish delivery has been made much more efficient by eliminating extra disk copies of messages for each recipient of a VERP delivery. It has also been made more robust in the face of failures during chunk delivery. This required a rewrite of SMTPDirect.py and one casualty of that rewrite was the experimental threaded delivery. It is no longer supported (but /might/ be resurrected if there's enough demand -- or a contributed patch :). o A new site config variable SMTP_MAX_SESSIONS_PER_CONNECTION specifies how many consecutive SMTP sessions will be conducted down the same socket connection. Some MTAs have a limit on this. o Support for VERP-ing confirmation messages. These are less error prone since the Subject: header doesn't need to be retained, and they allow a more user friendly (and i18n'd) Subject: header. VERP_CONFIRM_FORMAT, VERP_CONFIRM_REGEXP, and VERP_CONFIRMATIONS control this feature (only supported for invitation confirmations currently, but will be expanded to the other confirmations). o Several new list-centric addresses have been added: -subscribe and -unsubscribe are synonyms for -join and -leave, respectively. Also -confirm has been added to support VERP'd confirmations. - Archiver o There's now a default page for the Pipermail archive link for when no messages have yet been posted to the list. o Just the mere presence of an X-No-Archive: is enough to inhibit archiving for this message; the value of the header is now ignored. - Configuring, building, installing o Mailman now has a new favicon, donated by Terry Oda. Not all web pages are linked to the favicon yet though. o The add-on email package is now distributed and installed automatically, so you don't need to do this. It is installed in a Mailman-specific place so it won't affect your larger Python installation. o The default value of VERP_REGEXP has changed. o New site configuration variables BADQUEUE_DIR and QRUNNER_SAVE_BAD_MESSAGES which describe where to save messages which are not properly MIME encoded. o configure should be more POSIX-ly conformant. o The Mailman/pythonlib directory has been removed, but a new $prefix/pythonlib directory has been added. o Regression tests are now installed. o The second argument to add_virtual() calls in mm_cfg.py are now optional. o DEFAULT_FIRST_STRIP_REPLY_TO now defaults to 0. o Site administrators can edit the Mailman/Site.py file to customize some filesystem layout policies. _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From Jack.Jansen@oratrix.com Mon Mar 18 11:52:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 18 Mar 2002 12:52:09 +0100 Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1 beta 1 In-Reply-To: <15508.11919.910981.756175@anthem.wooz.org> Message-ID: <941C2602-3A66-11D6-A2B1-0030655234CE@oratrix.com> On Sunday, March 17, 2002, at 06:50 , Barry A. Warsaw wrote: > o The Sender: and Errors-To: headers are no longer added to > outgoing messages. Huh? I hope this doesn't mean that those headers will no longer be in the mesages I receive.... It would completely break my procmail setup, and I wouldn't be surprised if it does so for most people in te known universe... -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dagilbert@raytheon.com Tue Mar 19 00:53:23 2002 From: dagilbert@raytheon.com (David A Gilbert) Date: Mon, 18 Mar 2002 16:53:23 -0800 Subject: [Mailman-Developers] clone_member -rq not working? Message-ID: <OFF46356B0.8F9E2C10-ON88256B81.00039C70@rsc.raytheon.com> Answer to my own question: Looks like the default in Defaults.py is SMART_ADDRESS_MATCH=1 When set to 0, my problem below no longer occurs. Doesn't seem very intuitive to me that the remove would take place after getting the MMAlreadyAMember error, but I guess since the addresses are considered equivalent, it is operating as expected. Don't think SMART_ADDRESS_MATCH=1 should be set as a default setting. Regards, David ----- Forwarded by David A Gilbert/RWS/Raytheon/US on 03/18/2002 04:40 PM ----- David A Gilbert To: mailman-users@python.org cc: 03/18/2002 Subject: clone_member -rq not working? 10:28 AM When I do the clone_member -r as below, all the mailing list subscriptions get removed for that user instead of cloned to the new address. Am using Mailman 2.0.6 on RedHat Linux 7.2. Is there any reason why this wouldn't work? Any suggestions appreciated. Thanks, Logged in as mailman user: bash-2.05$ ./find_member dagilbert bash-2.05$ more ../tmp/users dagilbert@west.raytheon.com bash-2.05$ ./add_members -d ../tmp/users -w n junk-obejas bash-2.05$ ./find_member dagilbert dagilbert@west.raytheon.com found in: junk-obejas bash-2.05$ ./clone_member -rq dagilbert@west.raytheon.com dagilbert@raytheon.co m original address removed: dagilbert@west.raytheon.com bash-2.05$ ./find_member dagilbert bash-2.05$ Regards, David ---------------------------------------------------------------------------- David A Gilbert Raytheon Company 310.334.1070 Notes mail: David A Gilbert/RWS/Raytheon/US SMTP mail: dagilbert@west.raytheon.com ----------------------------------------------------------------------------- From Samuele Pedroni" <pedroni@inf.ethz.ch Tue Mar 19 20:16:52 2002 From: Samuele Pedroni" <pedroni@inf.ethz.ch (Samuele Pedroni) Date: Tue, 19 Mar 2002 21:16:52 +0100 Subject: [Mailman-Developers] including archive link - feature? Message-ID: <012b01c1cf83$028635e0$6d94fea9@newmexico> Hi. I'm just a user on the sending/receiving side of MM lists. I don't know if the following feature is already implemented, and I don't know the innards of the archive mechanism to know whether it can be implemented. I just wonder whether each message sent through a list could optionally contain a web link to the archived post, like http://mail.python.org/pipermail/python-dev/2002-March/021429.html Even if the link does not work immediately but just after a bit of time, it would be valuable, IMHO. regards. PS: please cc, I'm not subscribed to this list. From yua@yudesigns.com Tue Mar 19 21:53:04 2002 From: yua@yudesigns.com (Alex Yu) Date: Tue, 19 Mar 2002 16:53:04 -0500 Subject: [Mailman-Developers] 2.1b1 bug - getting msg_footer twice Message-ID: <001c01c1cf90$7407c0f0$6601000a@monkey> Hi, I just upgraded to 2.1b1 from 2.1 alpha. Every e-mail that gets through list has msg_footer twice. How can I fix this? Alex From Tom Eagle" <tom@ESEstudios.com Tue Mar 19 23:18:02 2002 From: Tom Eagle" <tom@ESEstudios.com (Tom Eagle) Date: Tue, 19 Mar 2002 17:18:02 -0600 Subject: [Mailman-Developers] Re: Virus Filtering References: <15183.22232.119442.302021@anthem.wooz.org> Message-ID: <006501c1cf9c$536a2e80$6501a8c0@none> Is there a Virus Filtering package that works with Mailman? Tom Eagle From marc@merlins.org Wed Mar 20 21:12:10 2002 From: marc@merlins.org (Marc MERLIN) Date: Wed, 20 Mar 2002 13:12:10 -0800 Subject: [Mailman-Developers] Are digests broken in mailman 2.1b1? Message-ID: <20020320211210.GB20264@merlins.org> On my live/test system, mailman has been sending empty digests since last friday (when I upgraded to 2.1a4++ and later b1) Is this just me? What I get is exactly: ---------------------------------------------------------------------------- From: svlug-request@svlug.org Subject: svlug Digest, Vol 28, Issue 2 To: svlug@svlug.org X-BeenThere: svlug@lists.svlug.org X-Mailman-Version: 2.1b1 Precedence: bulk List-Help: <mailto:svlug-request@lists.svlug.org?subject=help> List-Post: <mailto:svlug@lists.svlug.org> List-Subscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=subscribe> List-Id: discussion list for the Silicon Valley Linux Users Group. <svlug.lists.svlug.org> List-Unsubscribe: <http://lists.svlug.org/lists/listinfo/svlug>, <mailto:svlug-request@lists.svlug.org?subject=unsubscribe> List-Archive: http://lists.svlug.org/archives/svlug/ Content-Type: multipart/mixed; boundary="===============9383223389590416=="; charset="en" Content-Transfer-Encoding: base64 Sender: svlug-bounces+marc=merlins.org@svlug.org Errors-To: svlug-bounces+marc=merlins.org@lists.svlug.org Message-Id: <E16nmGE-0005Jv-00@mail.svlug.org> Date: Wed, 20 Mar 2002 12:00:38 -0800 X-Spam-Status: No, hits=0.6 required=8.0 tests=NO_REAL_NAME version=2.11 Content-Length: 11689 Lines: 337 ---------------------------------------------------------------------------- The mail stops here, there is no body whatsoever. It's not just me, I only subscribed as digest because my users told me it was broken. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From totschnig.michael@uqam.ca Mon Mar 18 01:37:10 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Sun, 17 Mar 2002 20:37:10 -0500 Subject: [Mailman-Developers] bug in confirm by web interface Message-ID: <m2y9gq3bcp.fsf@linux.totschnig.org> Hello, on a CVS mailman updated today, I encounter the following problem when confirming a subscription by the web interface. Everything runs fine but on the page confirming the subscription, the link pointing to the subscribers login page is not expanded correctly: It reads http://hostname/mailman/confirm/%(optionurl)s Maybe the problem is related to the fact that the page is localized in French? Regards, Michael From dagilbert@raytheon.com Mon Mar 18 18:22:04 2002 From: dagilbert@raytheon.com (David A Gilbert) Date: Mon, 18 Mar 2002 10:22:04 -0800 Subject: [Mailman-Developers] clone_member -rq not working? Message-ID: <OF7E49D323.35629AAD-ON88256B80.0064325E@rsc.raytheon.com> When I do the clone_member -r as below, all the mailing list subscriptions get removed for that user instead of cloned to the new address. Am using Mailman 2.0.6 on RedHat Linux 7.2. Is there any reason why this wouldn't work? Any suggestions appreciated. Thanks, Logged in as mailman user: bash-2.05$ ./find_member dagilbert bash-2.05$ more ../tmp/users dagilbert@west.raytheon.com bash-2.05$ ./add_members -d ../tmp/users -w n junk-obejas bash-2.05$ ./find_member dagilbert dagilbert@west.raytheon.com found in: junk-obejas bash-2.05$ ./clone_member -rq dagilbert@west.raytheon.com dagilbert@raytheon.co m original address removed: dagilbert@west.raytheon.com bash-2.05$ ./find_member dagilbert bash-2.05$ Regards, David ---------------------------------------------------------------------------- David A Gilbert Raytheon Company 310.334.1070 Notes mail: David A Gilbert/RWS/Raytheon/US SMTP mail: dagilbert@west.raytheon.com ----------------------------------------------------------------------------- From barry@zope.com Sat Mar 23 06:18:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 01:18:08 -0500 Subject: [Mailman-Developers] Re: message is unparsable and lost data files for filebase References: <86ofhglkld.fsf@cmo.uqam.ca> <3C9B9C40.71A3BC6A@utopia.west.sun.com> <86sn6s2ris.fsf@cmo.uqam.ca> Message-ID: <15516.7712.181820.288979@anthem.wooz.org> >>>>> "tm" == totschnig michael <totschnig.michael@uqam.ca> writes: tm> But by comparing with the MTA's log file, I could understand tm> that the message in question has probably been spam. Is there tm> another place where mailman could have put it for inspection, tm> or do I have to change the configuration to keep track of such tm> problems? Dan's right, but you need to enable saving of bad messages by setting QRUNNER_SAVE_BAD_MESSAGES = 1 in your mm_cfg.py file. Bad messages aren't saved by default. This is almost always going to be caused by malformed MIME messages, which are (almost?) always spam. I wouldn't worry about them. -Barry From barry@zope.com Sat Mar 23 06:49:34 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 01:49:34 -0500 Subject: [Mailman-Developers] is it me? References: <20020315154550.GB13758@rezo.net> Message-ID: <15516.9598.966755.931271@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> Am I the only stupid guy running mailman cvs on a server with F> many lists? ;-) I'm beginning to use it on real lists for python.org, but mostly low traffic stuff currently. I use it on all my wooz.org mailing lists (again, mostly low traffic). F> Here's another bug F> Mar 15 16:42:21 2002 (6105) Unexpected Mailman error: Traceback F> (most recent call last): File F> "/home/mailman/Mailman/MailCommandHandler.py", line 272, in F> ParseMailCommands F> self.__dispatch[cmd](args, line, msg) File F> "/home/mailman/Mailman/MailCommandHandler.py", line 720, in F> ProcessConfirmCmd F> results = self.ProcessConfirmation(args[0], msg) File F> "/home/mailman/Mailman/MailList.py", line 980, in F> ProcessConfirmation addr = userdesc.address F> AttributeError: address Can you give some more details? What were you confirming? Is this reproducible, and if so, please give exact instructions. I tried emailing mylist-join, and then replying to the subsequent message. I got subscribed with no problems. -Barry From barry@zope.com Sat Mar 23 06:50:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 01:50:03 -0500 Subject: [Mailman-Developers] is it me? References: <20020315154550.GB13758@rezo.net> <Pine.LNX.4.33.0203161923560.13531-100000@pannier.cfsc.ottawa.on.ca> Message-ID: <15516.9627.711850.913609@anthem.wooz.org> >>>>> "BD" == Brett Delmage <brett@cfsc.ottawa.on.ca> writes: >> Am I the only stupid guy running mailman cvs on a server with >> many lists? ;-) BD> No, I am using it for 3 low-traffic "internal committee" lists BD> here now. I figure helping test and find the bugs is the least BD> I can do for free software, being as I am not up to coding BD> python yet (I'm an embedded systems C programmer during my day BD> job.) BD> My users don't always appreciate this(!) but as they are and BD> work with volunteers too they understand that they're part of BD> the Mailman team and helping out simply by using the BD> system. As CfSC uses a lot of free software it's the least we BD> can do... Trust me, /I/ appreciate it! It makes Mailman much better software. -Barry From barry@zope.com Sat Mar 23 06:51:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 01:51:25 -0500 Subject: [Mailman-Developers] 2.1b1 bug - getting msg_footer twice References: <001c01c1cf90$7407c0f0$6601000a@monkey> Message-ID: <15516.9709.181798.81998@anthem.wooz.org> >>>>> "AY" == Alex Yu <yua@yudesigns.com> writes: AY> I just upgraded to 2.1b1 from 2.1 alpha. Every e-mail that AY> gets through list has msg_footer twice. How can I fix this? Hmm, this is another problem I can't verify. starting-to-get-nervous-ly y'rs, -Barry From barry@zope.com Sat Mar 23 06:52:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 01:52:48 -0500 Subject: [Mailman-Developers] including archive link - feature? References: <012b01c1cf83$028635e0$6d94fea9@newmexico> Message-ID: <15516.9792.665533.257344@anthem.wooz.org> >>>>> "SP" == Samuele Pedroni <pedronis@bluewin.ch> writes: SP> Hi. SP> I'm just a user on the sending/receiving side of MM lists. I SP> don't know if the following feature is already implemented, SP> and I don't know the innards of the archive mechanism to know SP> whether it can be implemented. SP> I just wonder whether each message sent through SP> a list could optionally contain a web link to the archived SP> post, like SP> http://mail.python.org/pipermail/python-dev/2002-March/021429.html SP> Even if the link does not work immediately but just after a SP> bit of time, it would be valuable, IMHO. It would be incredibly valuable, but the current architecture doesn't really support this. It's something we've talked about for Zest (if that project pans out). http://zest.sf.net -Barry From barry@zope.com Sat Mar 23 07:06:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 02:06:03 -0500 Subject: [Mailman-Developers] clone_member -rq not working? References: <OFF46356B0.8F9E2C10-ON88256B81.00039C70@rsc.raytheon.com> Message-ID: <15516.10587.12674.471254@anthem.wooz.org> >>>>> "DAG" == David A Gilbert <dagilbert@raytheon.com> writes: DAG> Answer to my own question: Looks like the default in DAG> Defaults.py is SMART_ADDRESS_MATCH=1 When set to 0, my DAG> problem below no longer occurs. Doesn't seem very intuitive DAG> to me that the remove would take place after getting the DAG> MMAlreadyAMember error, but I guess since the addresses are DAG> considered equivalent, it is operating as expected. Don't DAG> think SMART_ADDRESS_MATCH=1 should be set as a default DAG> setting. I cannot reproduce this problem in MM2.1 beta1. -Barry From fil@rezo.net Sat Mar 23 11:14:35 2002 From: fil@rezo.net (Fil) Date: Sat, 23 Mar 2002 12:14:35 +0100 Subject: [Mailman-Developers] is it me? In-Reply-To: <15516.9598.966755.931271@anthem.wooz.org> References: <20020315154550.GB13758@rezo.net> <15516.9598.966755.931271@anthem.wooz.org> Message-ID: <20020323111435.GA27136@rezo.net> @ Barry A. Warsaw <barry@zope.com> : > F> Here's another bug .../... > F> ProcessConfirmation addr = userdesc.address > F> AttributeError: address > > Can you give some more details? What were you confirming? Is this > reproducible, and if so, please give exact instructions. Some of my list-admins got it, but I couldn't reproduce it myself. I'll keep you posted if it creeps up again. For me the biggest problem to date is that the BounceRunner has the same priority than the other runners and scripts, and makes them fail if it's processing hundreds of bounces (it processes them quite slowly, you'll have to admit). -- Fil From barry@zope.com Sat Mar 23 17:34:36 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 12:34:36 -0500 Subject: [Mailman-Developers] is it me? References: <20020315154550.GB13758@rezo.net> <15516.9598.966755.931271@anthem.wooz.org> <20020323111435.GA27136@rezo.net> Message-ID: <15516.48300.365870.304539@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> For me the biggest problem to date is that the BounceRunner has F> the same priority than the other runners and scripts, and makes F> them fail if it's processing hundreds of bounces (it processes F> them quite slowly, you'll have to admit). Yup, that one's on my radar... -Barry From barry@zope.com Sat Mar 23 17:51:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 23 Mar 2002 12:51:12 -0500 Subject: [Mailman-Developers] Quick note Message-ID: <15516.49296.632247.957742@anthem.wooz.org> Just a quick note to folks playing with MM2.1. Remember that when you install a new version, do an update, or make a change, you really should do bin/mailmanctl restart to get the qrunner daemon to see the new code. -Barry From claw@kanga.nu Sat Mar 23 18:12:52 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 23 Mar 2002 10:12:52 -0800 Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1 beta 1 In-Reply-To: Message from Jack Jansen <Jack.Jansen@oratrix.com> of "Mon, 18 Mar 2002 12:52:09 +0100." <941C2602-3A66-11D6-A2B1-0030655234CE@oratrix.com> References: <941C2602-3A66-11D6-A2B1-0030655234CE@oratrix.com> Message-ID: <18108.1016907172@kanga.nu> On Mon, 18 Mar 2002 12:52:09 +0100 Jack Jansen <Jack.Jansen@oratrix.com> wrote: > On Sunday, March 17, 2002, at 06:50 , Barry A. Warsaw wrote: >> The Sender: and Errors-To: headers are no longer added to outgoing >> messages. > Huh? I hope this doesn't mean that those headers will no longer be in > the mesages I receive.... It would completely break my procmail setup, > and I wouldn't be surprised if it does so for most people in te known > universe... Better MTAs will add/enforce the Sender: header. -- 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 marc_news@vasoftware.com Sun Mar 24 03:46:46 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 23 Mar 2002 19:46:46 -0800 Subject: [Mailman-Developers] Modifications to msg In-Reply-To: <21042.1016511174@kanga.nu>; from claw@kanga.nu on Mon, Mar 18, 2002 at 08:12:54PM -0800 References: <200203190256.g2J2udWk006147@utopia.West.Sun.COM> <p05101505b8bc5da4dfe1@[207.149.192.229]> <jwblist@olympus.net> <21042.1016511174@kanga.nu> Message-ID: <20020323194646.C9737@merlins.org> On Mon, Mar 18, 2002 at 08:12:54PM -0800, J C Lawrence wrote: > RFC 2822 explicitly states that Reply-To can contain a list of > headers. RFC 822 is more ambiguous. To my mind this single fact (if > used with Reply-To aggregation) obviates most of the arguments in the > Reply-To Munging Considered Harmful document. Not really, it only addresses the limited problem that Reply-To munging removes the Reply-To that the posting user could have been set. In the case where I want replies to go to another address than my posting address, that's fine, and indeed extending Reply-To: is much better than replacing it. This doesn't affect however the many other problems including: - me trying to set a reply-to to redirect traffic to another list (not that it works that well anyway, but at least it can give a clue) - you replying to me privately without having to hand edit headers - mailing list loops with broken autoresponders) - etc... (see reply-to considered harmful document for "etc") Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Sun Mar 24 06:15:00 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 23 Mar 2002 22:15:00 -0800 Subject: [Mailman-Developers] Re: Dealing with SMTP server down + SMTP_MAX_SESSIONS_PER_CONNECTION fix In-Reply-To: <20020317031944.GB11598@merlins.org>; from marc_news@vasoftware.com on Sat, Mar 16, 2002 at 07:19:45PM -0800 References: <20020317031944.GB11598@merlins.org> Message-ID: <20020323221500.L9737@merlins.org> On Sat, Mar 16, 2002 at 07:19:45PM -0800, Marc MERLIN wrote: > mailman-cvs gives me: > > Mar 16 19:18:23 2002 (28557) Uncaught runner exception: (111, 'Connection refused') (...) > File "/usr/lib/python2.1/smtplib.py", line 222, in connect > self.sock.connect((host, port)) > error: (111, 'Connection refused') > > Maybe it could just log the fact that it could not connect to the SMTP server? Ok, I fixed that (although my fix might need to be tweaked further), and more importantly I fixed the non working SMTP_MAX_SESSIONS_PER_CONNECTION option. Yeah, it does break the one patch, one fix rule, but it's trivial to take the two apart. --- mailman-cvs/Mailman/Handlers/SMTPDirect.py Fri Mar 15 22:05:17 2002 +++ /var/local/mailman/Mailman/Handlers/SMTPDirect.py Sat Mar 23 22:03:54 2002 @@ -50,27 +50,39 @@ def __connect(self): self.__conn = smtplib.SMTP() - self.__conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) + try: + self.__conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) + except socket.error: + if mm_cfg.SMTPPORT: + syslog("error", "Fatal error: cannot connect to SMTP server %s on port %d", mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) + else: + syslog("error", "Fatal error: cannot connect to SMTP server %s", mm_cfg.SMTPHOST) + raise + self.__numsessions = mm_cfg.SMTP_MAX_SESSIONS_PER_CONNECTION def sendmail(self, envsender, recips, msgtext): - try: - return self.__conn.sendmail(envsender, recips, msgtext) - except smtplib.SMTPException: - # For safety, reconnect - self.__conn.quit() - self.__connect() - # Let exceptions percolate up - raise # Decrement the session counter, reconnecting if necessary self.__numsessions -= 1 # By testing exactly for equality to 0, we automatically handle the # case for SMTP_MAX_SESSIONS_PER_CONNECTION <= 0 meaning never close # the connection. We won't worry about wraparound <wink>. + # There is a really small bug where the first batch will contain one + # less mail as asked. That's ok though, we are simply one below the MAX + # value for the first batch -- Marc if self.__numsessions == 0: self.__conn.quit() self.__connect() + try: + return self.__conn.sendmail(envsender, recips, msgtext) + except smtplib.SMTPException: + # For safety, reconnect + self.__conn.quit() + self.__connect() + # Let exceptions percolate up + raise + def quit(self): self.__conn.quit() @@ -111,7 +139,6 @@ deliveryfunc = bulkdeliver refused = {} t0 = time.time() - numsessions = mm_cfg.SMTP_MAX_SESSIONS_PER_CONNECTION # Open the initial connection origrecips = msgdata['recips'] # `undelivered' is a copy of chunks that we pop from to do deliveries. @@ -121,7 +148,11 @@ # This means at worst, the last chunk for which delivery was attempted # could get duplicates but not every one, and no recips should miss the # message. - conn = Connection() + try: + conn = Connection() + except socket.error: + # There is probably a better thing to do here -- Marc + return try: msgdata['undelivered'] = chunks while chunks: -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spertus@mills.edu Sun Mar 24 18:39:38 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sun, 24 Mar 2002 10:39:38 -0800 Subject: [Mailman-Developers] My extensions to Mailman for threading Message-ID: <5.1.0.14.0.20020324103627.0226a7b0@ella.mills.edu> The design document is available at https://sourceforge.net/docman/display_doc.php?docid=10285&group_id=44608. My code is available at https://sourceforge.net/project/showfiles.php?group_id=44608. I invite criticism. Ellen From claw@kanga.nu Sun Mar 24 19:02:50 2002 From: claw@kanga.nu (J C Lawrence) Date: Sun, 24 Mar 2002 11:02:50 -0800 Subject: [Mailman-Developers] My extensions to Mailman for threading In-Reply-To: Message from Ellen Spertus <spertus@mills.edu> of "Sun, 24 Mar 2002 10:39:38 PST." <5.1.0.14.0.20020324103627.0226a7b0@ella.mills.edu> References: <5.1.0.14.0.20020324103627.0226a7b0@ella.mills.edu> Message-ID: <4422.1016996570@kanga.nu> On Sun, 24 Mar 2002 10:39:38 -0800 Ellen Spertus <spertus@mills.edu> wrote: > The design document is available at > https://sourceforge.net/docman/display_doc.php?docid=10285&group_id=44608. My > code is available at > https://sourceforge.net/project/showfiles.php?group_id=44608. I > invite criticism. Short story: I run an active technically oriented list which suffers a number of growth curve and elder game problems. Basic response to proposed patch: Love the idea. Complexity needs to be hidden so that members can use the functionality if they want to but don't have to. Want subscriptions to default to getting all messages on all threads. Want easy/trivially_automatic way to flag reply to current thread as a thread fork and/or thread merge (both happen frequently for me). Want easy/trivially_automatic way to flag reply to current thread as a topic shift (same subject, very different viewpoint on it). Problems with handling replies from digests (even properly edited replies). Needs to automatically pick up new thread creations using "Subject: foo (was: blah)" form. Need all above capabilities expressed trivially to users AND moderation interface. -- 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 marc_news@vasoftware.com Mon Mar 25 06:36:13 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 24 Mar 2002 22:36:13 -0800 Subject: [Mailman-Developers] Does anyone have digests working with mailman 2.1b1? In-Reply-To: <20020321070411.GA29246@merlins.org>; from marc_news@vasoftware.com on Wed, Mar 20, 2002 at 11:04:12PM -0800 References: <20020320211210.GB20264@merlins.org> <20020321070411.GA29246@merlins.org> Message-ID: <20020324223613.S9737@merlins.org> On Wed, Mar 20, 2002 at 11:04:12PM -0800, Marc MERLIN wrote: > > The mail stops here, there is no body whatsoever. > > Ok, after clearing my CVS tree, re-installing mailman from a freshly built > CVS tree, and restarting the qrunners, I still get this: I just got digest > #3, and again, the body is absolutely empty. Ok, I fell stupid. The body was empty, but the messages were inside the mail as separate mime attachements. I've not used digests in a long time, ut I know something changed, and it apparently confused some of my users too. Can mailman say in the body: "The digested messages are attached as mime parts" or something, so that the mail doesn't look empty (which it really does if you look at it with mutt) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Mar 25 06:44:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Mar 2002 01:44:42 -0500 Subject: [Mailman-Developers] bug at mailman-21 playground References: <20020317120258.GB1357@jonas.server0.de> Message-ID: <15518.51034.313839.631117@anthem.wooz.org> >>>>> "JM" == Jonas Meurer <jmeurer@gmx.de> writes: JM> I found a bug at the playground on JM> mail.python.org/mailman-21/listinfo/playground. I tested the JM> languages and when I changed from traditional Chinese to JM> German the bugreport came. This problem comes allways you JM> change from Chinese to German. JM> Another problem: If I change from any language to Simplified JM> Chinese the Layout changes a bit. Also from any language to JM> Traditional Chinese. Both of these are caused by issues in the Chinese templates. For the former, I fixed some of the tag placements, so these should work now. For the latter, we need to get the Chinese translation updated. -Barry From barry@zope.com Mon Mar 25 06:47:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Mar 2002 01:47:19 -0500 Subject: [Mailman-i18n] Re: [Mailman-Developers] Bug in Chinese language selections and options page? References: <200203140323.g2E3NoWk029732@utopia.West.Sun.COM> <15505.12623.171701.557645@anthem.wooz.org> <3C91590D.3D756E47@turbolinux.com.cn> Message-ID: <15518.51191.652450.567338@anthem.wooz.org> MY> I am native Chinese speaker, and I have installed MY> mailman-2.0.8 English version successfully on my computer, and MY> I want to help building Chinese templates, what should I do MY> then? Max, it would be really greate to get some updates to the Chinese templates and message catalogs. Please grab Mailman 2.1b1, and read the README-I18N.en file for instructions. Or grab them from the latest langpack file release on SF. When you're ready, you can send me updates to messages.po and the templates directory. Preferred mode of delivery is a tar file that I can un pack at the top of the source tree (i.e. in the parent directory of messages/ and templates/). Thanks, -Barry From jra@baylink.com Mon Mar 25 15:52:01 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Mar 2002 10:52:01 -0500 Subject: [Mailman-Developers] My extensions to Mailman for threading In-Reply-To: <5.1.0.14.0.20020324103627.0226a7b0@ella.mills.edu>; from Ellen Spertus <spertus@mills.edu> on Sun, Mar 24, 2002 at 10:39:38AM -0800 References: <5.1.0.14.0.20020324103627.0226a7b0@ella.mills.edu> Message-ID: <20020325105201.28990@scfn.thpl.lib.fl.us> On Sun, Mar 24, 2002 at 10:39:38AM -0800, Ellen Spertus wrote: > The design document is available at > https://sourceforge.net/docman/display_doc.php?docid=10285&group_id=44608. > My code is available at > https://sourceforge.net/project/showfiles.php?group_id=44608. > I invite criticism. I hate the Jacuzzi. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Mon Mar 25 15:52:48 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Mar 2002 10:52:48 -0500 Subject: [Mailman-Developers] Does anyone have digests working with mailman 2.1b1? In-Reply-To: <20020324223613.S9737@merlins.org>; from Marc MERLIN <marc_news@vasoftware.com> on Sun, Mar 24, 2002 at 10:36:13PM -0800 References: <20020320211210.GB20264@merlins.org> <20020321070411.GA29246@merlins.org> <20020324223613.S9737@merlins.org> Message-ID: <20020325105248.63226@scfn.thpl.lib.fl.us> On Sun, Mar 24, 2002 at 10:36:13PM -0800, Marc MERLIN wrote: > "The digested messages are attached as mime parts" or something, so that the > mail doesn't look empty (which it really does if you look at it with mutt) ...or GoMail, or any of a *number* of other non-aware clients. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jarrell@vt.edu Mon Mar 25 19:56:03 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Mar 2002 14:56:03 -0500 Subject: [Mailman-Developers] Re: Virus Filtering In-Reply-To: <006501c1cf9c$536a2e80$6501a8c0@none> References: <15183.22232.119442.302021@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020325145313.04209980@lennier.cc.vt.edu> At 05:18 PM 3/19/02 -0600, you wrote: >Is there a Virus Filtering package that works with Mailman? That would more properly be an MTA issue, not an MLM issue. Depending on what you're running, there are various vendors who have plugins that can scan. Trend has several unixy variants for instance, although they're not cheap. We use Mirapoint's solution; an MD300 message directory sitting in from of our main mail servers scrubbing all inbound and outbound mail with Trend's engine. (Soon to be Sophos's engine, since Mirapoint, thanks to their agreements, was able to underbid Trend on every contract for a combined hardware and software solution, charging less than Trend would for just the software...) None of them are cheap, though.. From Dan Mick <dmick@utopia.West.Sun.COM> Mon Mar 25 22:42:30 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Mon, 25 Mar 2002 14:42:30 -0800 (PST) Subject: [Mailman-Developers] Re: message is unparsable and lost data files for filebase Message-ID: <200203252242.g2PMgjWk009213@utopia.West.Sun.COM> > >>>>> "tm" == totschnig michael <totschnig.michael@uqam.ca> writes: > > tm> But by comparing with the MTA's log file, I could understand > tm> that the message in question has probably been spam. Is there > tm> another place where mailman could have put it for inspection, > tm> or do I have to change the configuration to keep track of such > tm> problems? > > Dan's right, but you need to enable saving of bad messages by setting > QRUNNER_SAVE_BAD_MESSAGES = 1 in your mm_cfg.py file. Bad messages > aren't saved by default. > > This is almost always going to be caused by malformed MIME messages, > which are (almost?) always spam. I wouldn't worry about them. Depressingly, about half of mine are misformatted bounce messages. Apparently people just can't keep their damned fingers off bounce messages. From barry@zope.com Mon Mar 25 23:50:40 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Mar 2002 18:50:40 -0500 Subject: [Mailman-Developers] a bug? the latest CVS (2.1b1) References: <Pine.GSO.4.44.0203182224300.10162-100000@alb-net.com> Message-ID: <15519.47056.919283.416198@anthem.wooz.org> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes: MC> The "Emergency moderation of all list traffic" check-box does MC> not stay checked beyond the current session. If you "Logout" MC> and login back that the check-box is uncheck and the red-color MC> disappears. Fixed in CVS. >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> In admin.py I note that it's built as a CheckBox('emergency', RJ> 1, mlist.emergency).. is using a "1" there functionally RJ> equivalent to saying "on" or "off" like it's used every where RJ> else? Yes, but the problem here is that I thought we'd get a tri-state value when looking at the (Python interface to the) form data. I.e. None == not present, 0 == not set, 1 == set. That's not the case, so I special cased this to avoid setting mlist.emergency when logging in. RJ> (As an aside... Is there any reason to keep the .db files? RJ> They're version 36 and we're at version 68... I certainly RJ> hope nothing is using them..) No you don't need to keep them. Once they're converted to .pck files, they can be deleted. I just don't feel confident having Mailman do that automatically. -Barry From Dan Mick <dmick@utopia.West.Sun.COM> Mon Mar 25 23:58:22 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Mon, 25 Mar 2002 15:58:22 -0800 (PST) Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom Message-ID: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> I don't know why the first time I tried this, it seemed hard, but it's easy, and I like this a *lot* better: Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 2.66 diff -u -r2.66 admin.py --- Mailman/Cgi/admin.py 25 Mar 2002 23:48:12 -0000 2.66 +++ Mailman/Cgi/admin.py 25 Mar 2002 23:58:14 -0000 @@ -492,12 +492,8 @@ subcat = Utils.GetPathPieces()[-1] if subcat not in ('list', 'add', 'remove'): subcat = 'list' - # Add member category specific tables - form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) - form.AddItem(Center(submit_button('setmemberopts_btn'))) # In "list" subcategory, we can also search for members if subcat == 'list': - form.AddItem('<hr>\n') table = Table(width='100%') table.AddRow([Center(Header(2, _('Additional Member Tasks')))]) table.AddCellInfo(table.GetCurrentRowIndex(), 0, colspan=2, @@ -525,6 +521,10 @@ mlist.default_member_moderation), SubmitButton('allmodbit_btn', _('Set'))]) form.AddItem(table) + # Add member category specific tables + form.AddItem('<hr>\n') + form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) + form.AddItem(Center(submit_button('setmemberopts_btn'))) elif category == 'passwords': form.AddItem(Center(password_inputs(mlist))) form.AddItem(Center(submit_button())) From chk@pobox.com Tue Mar 26 15:39:14 2002 From: chk@pobox.com (Harald Koch) Date: Tue, 26 Mar 2002 10:39:14 -0500 Subject: [Mailman-Developers] 2.1b1 Moderation and From: vs. Sender: Message-ID: <25756.1017157154@elisabeth.cfrq.net> I have a small problem with a moderated list as part of my upgrades from 2.0.8 to 2.1b1. This is a "joke of the day" style list. I'm supposed to be the only one who can submit messages to the list; all of the members are moderated (except me). Outgoing messages are stored in a queue, and one is sent automatically by cron once per day. With 2.0.8, I was processing a message by adding a Sender: tag with my address; my address was listed in the 'posters' variable. With "USE_ENVELOPE_SENDER = 1" in my mm_cfg.py, this worked. The list upgrade process handled the 'posters' variable correctly; my list address was marked *unmoderated*, and the other addresses were copied into the new 'accept_these_nonmembers' field. (Good attention to detail, there, btw; kudos!) However, my 'trick' of adding a Sender: field doesn't work anymore, and I get a confusing log/hold message that says "humour post from chk@cfrq.net held: Post by a moderated member". 'chk@cfrq.net' is not moderated. It turns out that, in order to find the moderation flag of the user that send a message, Handlers/Moderate.py calls msg.get_senders, which returns a *list* of senders with the Sender: last; Moderate.py only looks at the first return value, which is the From: header. The address in the From: field *is* moderated, and so the message is rejected. Later, however, Handlers/Hold.py routine hold_for_approval calls the old msg.get_sender (singular vs. plural), which returns the Sender: field if "USE_ENVELOPE_SENDER = 1" is set, which is why I get the confusing log message. So, two things: 1) The message rejection is confusing. 2) What's the right way to do this under 2.1? Thanks, -- Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry From chk@pobox.com Tue Mar 26 15:49:13 2002 From: chk@pobox.com (Harald Koch) Date: Tue, 26 Mar 2002 10:49:13 -0500 Subject: [Mailman-Developers] Re: 2.1b1 Moderation and From: vs. Sender: In-Reply-To: Your message of "Tue, 26 Mar 2002 10:39:14 -0500". <25756.1017157154@elisabeth.cfrq.net> References: <25756.1017157154@elisabeth.cfrq.net> Message-ID: <26055.1017157753@elisabeth.cfrq.net> Once upon a time in a land far, far away I wrote: > 2) What's the right way to do this under 2.1? Ok, I just found the Approved: header processing... *sigh. The hold message is still confusing though. <grin> -- Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry From jarrell@vt.edu Tue Mar 26 23:09:53 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Mar 2002 18:09:53 -0500 (EST) Subject: [Mailman-Developers] Misc thoughs on 2.0.5ish to 2.1b1 Message-ID: <200203262309.g2QN9rx14979@babylon5.cc.vt.edu> Upgrading my production server... I'm amazed I didn't notice some of this stuff on my test server, although that might be the fact that this big a jump has side effects that regular cvs updates didn't, (since update didn't necessarily do some things if I let it run before it knew how to do something, I suspect), or maybe the fact that my test lists are basically *me* in a variety of configurations, or maybe I'm just suddenly hitting bugs.. The upgrade process really ought not fill the errors log during the update process with "database for list whatever is corrupt, falling back to (whatever)"... Was the site password supposed to die? I can't remember if that happened to me during the various cvs upgrades I've done. The site password, once fixed, no longer works the same way when used as a trump password. For instance, *just* using the site password (and any old string under "email address") could get me into archives, listinfo screens, subscriber lists, etc. Now it seems I have to explicitly know an address that's subscribed to the list to use the sitepass - which is particularly annoying when I'm testing a new list that doesn't *have* subscribers on it! I'd rather the test be "(valid address and pass) OR site pass" not "valid address and (valid pass or site pass)" like it used to be... ***THE UPGRADE REALLY OUGHT NOT PUT IN THE "There are not messages in the archive" HOLDER URL FOR LISTS THAT *HAVE* THINGS IN THE ARCHIVE ALREADY!!** The above scared the (#($*# out of me... Having now had to use a list that had more than 2 test users on it, I agree with the comments made earlier - the new alphabetical subdivision system is a royal pain. I'm getting just 4-5 users at a time, and have to click as many as 28 times to quickly scan my users to see, for instance, who's in nomail, whereas before it was at most 4-5 chunks. Allowing an optional "just show me a chunk worth" is *well* worth it for convenience sake. Or just let the regexp display show them by chunks.. (I was really hoping that it would, but no, it just broke them down by alphabet when it got to be too many again...) For "new" flags, like "nodupes", when converting users, shouldn't we apply the current default user flag mask? With the default 256, no old users will have nodupes set, but all new users will... I'm sure I'll think of more :-) From jarrell@vt.edu Tue Mar 26 23:14:23 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Mar 2002 18:14:23 -0500 (EST) Subject: [Mailman-Developers] unshunt error Message-ID: <200203262314.g2QNENu15426@babylon5.cc.vt.edu> /home/mailman/bin/unshunt * Traceback (most recent call last): File "/home/mailman/bin/unshunt", line 76, in ? main() File "/home/mailman/bin/unshunt", line 64, in main usage(1) File "/home/mailman/bin/unshunt", line 42, in usage print >> sys.stderr, _(__doc__) NameError: global name '_' is not defined From jarrell@vt.edu Tue Mar 26 23:22:04 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Mar 2002 18:22:04 -0500 (EST) Subject: [Mailman-Developers] install trouble Message-ID: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> Interesting... Didn't have this trouble on my test solaris box, but on my prod solaris box, with a neigh unto identical config (other than sol 8 vs 7) I'm having the "wanted gid 30, got gid 1" Mailman appears to have properly sussed out that my mailman group is 30, and, in fact, installed mailman setgid to mailman, but suddenly it's not actually taking that gid. From marc_news@vasoftware.com Tue Mar 26 23:25:56 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 26 Mar 2002 15:25:56 -0800 Subject: [Mailman-Developers] unshunt error In-Reply-To: <200203262314.g2QNENu15426@babylon5.cc.vt.edu> References: <200203262314.g2QNENu15426@babylon5.cc.vt.edu> Message-ID: <20020326232555.GZ6829@merlins.org> On Tue, Mar 26, 2002 at 06:14:23PM -0500, Ron Jarrell wrote: > > /home/mailman/bin/unshunt * > Traceback (most recent call last): > File "/home/mailman/bin/unshunt", line 76, in ? > main() > File "/home/mailman/bin/unshunt", line 64, in main > usage(1) > File "/home/mailman/bin/unshunt", line 42, in usage > print >> sys.stderr, _(__doc__) > NameError: global name '_' is not defined Add from Mailman.i18n import _ in the imports section, that should fix it. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jarrell@vt.edu Tue Mar 26 23:34:03 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Mar 2002 18:34:03 -0500 Subject: [Mailman-Developers] install trouble In-Reply-To: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> At 06:22 PM 3/26/02 -0500, Ron Jarrell wrote: >Interesting... Didn't have this trouble on my test solaris box, but >on my prod solaris box, with a neigh unto identical config (other >than sol 8 vs 7) I'm having the "wanted gid 30, got gid 1" > >Mailman appears to have properly sussed out that my mailman >group is 30, and, in fact, installed mailman setgid to mailman, but >suddenly it's not actually taking that gid. Ah, I see what's going on.. configure changed between 2.0.5 and 2.1; in 2.0.5 it just checks "other mail demon" for possible groups - and at the time I reviewed that, and realized it'd make the right choice. in 2.1 it now checks "mailman other mail demon", which causes it to guess wrong, because while mailman is the group I want all mailman procs running under, sendmail runs in a different group... Of course, now I have to go back to my test machine and see why it didn't break *there* too. Feh. From jarrell@vt.edu Wed Mar 27 04:16:21 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Mar 2002 23:16:21 -0500 (EST) Subject: [Mailman-Developers] Ok, this is weird... Message-ID: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> Mar 26 21:56:41 2002 (558) Uncaught runner exception: Continuation line seen before first header Mar 26 21:56:41 2002 (558) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Tagger.py", line 47, in process matchlines.extend(scanbody(msg, mlist.topics_bodylines_limit)) File "/home/mailman/Mailman/Handlers/Tagger.py", line 101, in scanbody msg = email.message_from_string(EMPTYSTRING.join(lines)) File "/home/mailman/pythonlib/email/__init__.py", line 36, in message_from_string return _Parser(_class).parsestr(s) File "/home/mailman/pythonlib/email/Parser.py", line 45, in parsestr return self.parse(StringIO(text)) File "/home/mailman/pythonlib/email/Parser.py", line 40, in parse self._parseheaders(root, fp) File "/home/mailman/pythonlib/email/Parser.py", line 69, in _parseheaders raise Errors.HeaderParseError( HeaderParseError: Continuation line seen before first header Now, I'd believe there was something wrong with the header (although mm ought to catch this more elegantly), except the user had just sent it to list1@myserver,list2@myserver, and it made it to *list2*, it just won't go through to list1. I unshunted it, and it failed again the same way. So how in heck did it get to list2? Barry, I saved the copy I got (I'm on both lists), and the shunt files, if you want them; there's nothing private in the message. From jarrell@vt.edu Wed Mar 27 05:13:14 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 27 Mar 2002 00:13:14 -0500 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020327001202.03ef8540@lennier.cc.vt.edu> At 11:16 PM 3/26/02 -0500, Ron Jarrell wrote: >Mar 26 21:56:41 2002 (558) Uncaught runner exception: Continuation line seen before first header It behooves me to point out that this is with 2.1b1 + today's cvs activity, down through barry's double commit of add_user. Ok, I eliminated differences between the list configurations (one had multiple languages enabled, and topics, the other didn't.) Getting their configs to match, other than the names of the lists and such didn't change the process enough to cure the error. I did find one odd thing. The messages was delivered to my mm box in the same SMTP transaction, although, of course, it started 2 seperate pipes up for the delivery. The header on the one I received through list 2 includes Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g2R2udI145446; Tue, 26 Mar 2002 21:56:39 -0500 (EST) (Where that first whitespace on the continuation lines really is a space.) The header on the one in my shunt pickle is: Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g2R2udI145446; Tue, 26 Mar 2002 21:56:39 -0500 (EST) Where that initial whitespace is a tab. I'm guessing someone, somewhere, rewrote my received lines after it hit mailman... Otherwise why are they folded differently? But, anyway, unless mm is bitching about a continuation line starting with a [, I'm at a loss why two messages that were identical until injected into mm delivery would react so differently. From barry@zope.com Wed Mar 27 05:19:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 00:19:03 -0500 Subject: [Mailman-Developers] Problem in checkdbs References: <1011027893.2575.20.camel@julieta> Message-ID: <15521.22087.923217.76207@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas <rodolfo@linux.org.uy> writes: RP> I am receving the following notice from my server. (I use RP> Python 2.0 and MM 2.1a3) RP> Can you tell me how to fix it? (thank you) This should be fixed in cvs now, but you'll need to run "bin/update -f" after doing an install (this won't be necessary after I release beta2). -Barry From barry@zope.com Wed Mar 27 05:23:26 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 00:23:26 -0500 Subject: [Mailman-Developers] Re: message is unparsable and lost data files for filebase References: <200203252242.g2PMgjWk009213@utopia.West.Sun.COM> Message-ID: <15521.22350.741783.380240@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> Depressingly, about half of mine are misformatted bounce DM> messages. Apparently people just can't keep their damned DM> fingers off bounce messages. Yeah, it's not like there are standards or anything <1894 wink>. -Barry From barry@zope.com Wed Mar 27 05:33:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 00:33:54 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> Message-ID: <15521.22978.322543.826836@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> I don't know why the first time I tried this, it seemed hard, DM> but it's easy, and I like this a *lot* better: Hmm. Sorry, I'm not crazy about it, so I'll give it a -0 (which means I'm open to being swayed if there is a hue and cry). -Barry From fil@rezo.net Wed Mar 27 10:07:47 2002 From: fil@rezo.net (Fil) Date: Wed, 27 Mar 2002 11:07:47 +0100 Subject: [Mailman-Developers] new BounceRunner Message-ID: <20020327100747.GB4238@rezo.net> While the recent commits for BounceRunner seem to be working fine in terms of memory and CPU, I'm suddenly seing many files in the qfiles/bad/ directory. These files seem to be legitimate bounces (ie the usual postfix-format bounce message). -- Fil From chk@pobox.com Wed Mar 27 17:17:23 2002 From: chk@pobox.com (Harald Koch) Date: Wed, 27 Mar 2002 12:17:23 -0500 Subject: [Mailman-Developers] 2.1b1: new_member_options and web GUI Message-ID: <6796.1017249443@elisabeth.cfrq.net> I could not reset the "Filter out duplicate messages to list members (if possible)" flag in "new_member_options" from the web UI; the setting didn't take. I can change it with config_list, and that change is then reflected in the web GUI. By playing with the flags, I discovered that the problem is this; I cannot clear *all* of the flags. As long as one is set, the setting takes. Looks like a piece of code somewhere is treating "0" as a special case, but I haven't found it yet. -- Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry From jwblist@olympus.net Wed Mar 27 17:22:12 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 27 Mar 2002 09:22:12 -0800 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom In-Reply-To: <15521.22978.322543.826836@anthem.wooz.org> References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> Message-ID: <p05101502b8c7afc6b478@[207.149.192.229]> At 0:33 -0500 3/27/2002, Barry A. Warsaw wrote: >>>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: > > DM> I don't know why the first time I tried this, it seemed hard, > DM> but it's easy, and I like this a *lot* better: > >Hmm. Sorry, I'm not crazy about it, so I'll give it a -0 (which means >I'm open to being swayed if there is a hue and cry). [Tossing a log onto the fire...] Is there a reason that we're discussing putting the box at the top OR the bottom, without also discussing whether to put it at the top AND the bottom? --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From barry@zope.com Wed Mar 27 19:10:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 14:10:57 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> <p05101502b8c7afc6b478@[207.149.192.229]> Message-ID: <15522.6465.291850.668678@anthem.wooz.org> >>>>> "JWB" == John W Baxter <jwblist@olympus.net> writes: JWB> Is there a reason that we're discussing putting the box at JWB> the top OR the bottom, without also discussing whether to put JWB> it at the top AND the bottom? I tried that with the nav links in the admin page and I just found it to be a waste of real estate. In general I don't think it's a good idea to duplicate ui widgets on the same page, it leads to confusion. This is especially true of something like the regexp search items. Keep in mind that we're all just amateurs here. Well, /I/ am at least. :) -Barry From barry@zope.com Wed Mar 27 19:43:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 14:43:20 -0500 Subject: [Mailman-Developers] unshunt error References: <200203262314.g2QNENu15426@babylon5.cc.vt.edu> <20020326232555.GZ6829@merlins.org> Message-ID: <15522.8408.401660.850284@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> Add MM> from Mailman.i18n import _ MM> in the imports section, that should fix it. Yup. Fixed in CVS. -Barry From barry@zope.com Wed Mar 27 19:45:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 14:45:19 -0500 Subject: [Mailman-Developers] Ok, this is weird... References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> Message-ID: <15522.8527.761356.749127@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> Now, I'd believe there was something wrong with the header RJ> (although mm ought to catch this more elegantly), except the RJ> user had just sent it to list1@myserver,list2@myserver, and it RJ> made it to *list2*, it just won't go through to list1. I RJ> unshunted it, and it failed again the same way. RJ> So how in heck did it get to list2? RJ> Barry, I saved the copy I got (I'm on both lists), and the RJ> shunt files, if you want them; there's nothing private in the RJ> message. Yes, please do send them to me! -Barry From barry@zope.com Wed Mar 27 19:50:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 14:50:42 -0500 Subject: [Mailman-Developers] clean install of mailman-2.1a4 References: <3C92175A.6356703@isu.edu> Message-ID: <15522.8850.871662.218174@anthem.wooz.org> >>>>> "KW" == Kory Wheatley <wheakory@isu.edu> writes: KW> I did a clean install of mailman-2.1a4 and the web interface KW> is working fine, but I'm having problems with sending KW> messages. I'm running Red Hat 7.2 with Python 2.2 and sendmail KW> 8.11. My aliases for the list I created are correct. I changed KW> the symbolic link in /etc/smrsh to point to mailman rather KW> than wrapper. KW> Here is the following error, I hope I can get some feedback on KW> the solution to the problem. Try cutting Mailman out of the loop, and just write a little script to use smtplib on the same machine to send a canned message to yourself. If you get the same exception, then try going one level down and telnetting to the smtp port directly, typicing the SMTP dialogs by hand. I suspect it's a problem with your sendmail configuration. -Barry From barry@zope.com Wed Mar 27 20:20:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 15:20:19 -0500 Subject: [Mailman-Developers] install trouble References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> Message-ID: <15522.10628.198.448841@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> Ah, I see what's going on.. configure changed between 2.0.5 RJ> and 2.1; in 2.0.5 it just checks "other mail demon" for RJ> possible groups - and at the time I reviewed that, and RJ> realized it'd make the right choice. in 2.1 it now checks RJ> "mailman other mail demon", which causes it to guess wrong, RJ> because while mailman is the group I want all mailman procs RJ> running under, sendmail runs in a different group... Yeah, I made this change because it makes Postfix installation much easier. With that MTA, you want your mail programs running under user.group mailman, so that default makes the most sense (i.e. a simple "configure ; make install" Just Works). Am I being too biased towards Postfix to the detriment of other MTAs? -Barry From barry@zope.com Wed Mar 27 20:21:46 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Mar 2002 15:21:46 -0500 Subject: [Mailman-Developers] new BounceRunner References: <20020327100747.GB4238@rezo.net> Message-ID: <15522.10714.991702.79509@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> While the recent commits for BounceRunner seem to be working F> fine in terms of memory and CPU, I'm suddenly seing many files F> in the qfiles/bad/ directory. These files seem to be legitimate F> bounces (ie the usual postfix-format bounce message). Can you send one of the .pck/.db pairs to me? Thanks, -Barry From fil@rezo.net Wed Mar 27 20:43:21 2002 From: fil@rezo.net (Fil) Date: Wed, 27 Mar 2002 21:43:21 +0100 Subject: [Mailman-Developers] 2.1b1: new_member_options and web GUI In-Reply-To: <6796.1017249443@elisabeth.cfrq.net> References: <6796.1017249443@elisabeth.cfrq.net> Message-ID: <20020327204321.GC22548@rezo.net> @ Harald Koch <chk@pobox.com> : > I could not reset the "Filter out duplicate messages to list members (if > possible)" flag in "new_member_options" from the web UI; the setting > didn't take. I can change it with config_list, and that change is then > reflected in the web GUI. > > By playing with the flags, I discovered that the problem is this; I > cannot clear *all* of the flags. As long as one is set, the setting > takes. Looks like a piece of code somewhere is treating "0" as a special > case, but I haven't found it yet. I mentioned this bug recently : it's apparently because the new_member_options is set by multiple checkboxes which all have the same name (ie new_member_options), instead of being new_member_options_bit0, new_member_options_bit1, and so on. I don't know if some web browsers accept this, but none of mine do. -- Fil From dmick@utopia.West.Sun.COM Wed Mar 27 20:45:11 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Wed, 27 Mar 2002 12:45:11 -0800 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> Message-ID: <3CA22F57.F4E106EA@utopia.west.sun.com> the point is, with a properly working, easy-to-reach search, I *never* use the list. Ever. But I wasn't necessarily suggesting a global change, just that others here who have expressed dislike of the new alphabetic interface might be interested; if you were, fine, but... If there were a less-visually-clunky tweak to include it at the top of the list, I think it would be better yet. I'll hack around a bit (it seemed like a patch job to me visually too). "Barry A. Warsaw" wrote: > > >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: > > DM> I don't know why the first time I tried this, it seemed hard, > DM> but it's easy, and I like this a *lot* better: > > Hmm. Sorry, I'm not crazy about it, so I'll give it a -0 (which means > I'm open to being swayed if there is a hue and cry). > > -Barry From fil@rezo.net Wed Mar 27 21:07:22 2002 From: fil@rezo.net (Fil) Date: Wed, 27 Mar 2002 22:07:22 +0100 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom In-Reply-To: <3CA22F57.F4E106EA@utopia.west.sun.com> References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> <3CA22F57.F4E106EA@utopia.west.sun.com> Message-ID: <20020327210722.GA25138@rezo.net> @ Dan Mick <dmick@utopia.West.Sun.COM> : > If there were a less-visually-clunky tweak to include it at the top of the > list, I think it would be better yet. I'll hack around a bit (it seemed > like a patch job to me visually too). I like the idea of having this search box right on the top, on every admin pane (but very small, ie without helpline and no big button). -- Fil From wheakory@isu.edu Wed Mar 27 22:01:37 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Wed, 27 Mar 2002 15:01:37 -0700 Subject: [Mailman-Developers] Mailman 2.1b1 Message-ID: <3CA24141.37D8B7B8@isu.edu> Where's the documentation that goes in detail about all the new and changed features for Mailman 2.1b1. -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From marc_news@vasoftware.com Thu Mar 28 02:43:11 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 27 Mar 2002 18:43:11 -0800 Subject: [Mailman-Developers] install trouble In-Reply-To: <15522.10628.198.448841@anthem.wooz.org> References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> <15522.10628.198.448841@anthem.wooz.org> Message-ID: <20020328024310.GL8332@merlins.org> On Wed, Mar 27, 2002 at 03:20:19PM -0500, Barry A. Warsaw wrote: > > >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: > > RJ> Ah, I see what's going on.. configure changed between 2.0.5 > RJ> and 2.1; in 2.0.5 it just checks "other mail demon" for > RJ> possible groups - and at the time I reviewed that, and > RJ> realized it'd make the right choice. in 2.1 it now checks > RJ> "mailman other mail demon", which causes it to guess wrong, > RJ> because while mailman is the group I want all mailman procs > RJ> running under, sendmail runs in a different group... > > Yeah, I made this change because it makes Postfix installation much > easier. With that MTA, you want your mail programs running under > user.group mailman, so that default makes the most sense (i.e. a > simple "configure ; make install" Just Works). > > Am I being too biased towards Postfix to the detriment of other MTAs? I think it's good for mailman to default being run as UID mailman. exim also runs the wrapper as UID mailman in most configs Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Thu Mar 28 05:29:17 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Mar 2002 00:29:17 -0500 Subject: [Mailman-Developers] install trouble References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> <15522.10628.198.448841@anthem.wooz.org> <20020328024310.GL8332@merlins.org> Message-ID: <15522.43565.551226.649812@anthem.wooz.org> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes: MM> I think it's good for mailman to default being run as UID MM> mailman. exim also runs the wrapper as UID mailman in most MM> configs Agreed. Good. We'll just have to make sure the MM2.1 docs are clear about this. Thanks, -Barry From barry@zope.com Thu Mar 28 05:29:35 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Mar 2002 00:29:35 -0500 Subject: [Mailman-Developers] Mailman 2.1b1 References: <3CA24141.37D8B7B8@isu.edu> Message-ID: <15522.43583.778436.869845@anthem.wooz.org> >>>>> "KW" == Kory Wheatley <wheakory@isu.edu> writes: KW> Where's the documentation that goes in detail about all the KW> new and changed features for Mailman 2.1b1. The NEWS file is as good as it gets. -Barry From barry@zope.com Thu Mar 28 05:48:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Mar 2002 00:48:05 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> <3CA22F57.F4E106EA@utopia.west.sun.com> Message-ID: <15522.44693.111180.556842@anthem.wooz.org> >>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes: DM> the point is, with a properly working, easy-to-reach search, I DM> *never* use the list. Ever. That's a good point. DM> But I wasn't necessarily suggesting a global change, just that DM> others here who have expressed dislike of the new alphabetic DM> interface might be interested; if you were, fine, but... DM> If there were a less-visually-clunky tweak to include it at DM> the top of the list, I think it would be better yet. I'll DM> hack around a bit (it seemed like a patch job to me visually DM> too). See what you think about this (against cvs)... -Barry -------------------- snip snip -------------------- Index: admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 2.66 diff -u -r2.66 admin.py --- admin.py 25 Mar 2002 23:48:12 -0000 2.66 +++ admin.py 28 Mar 2002 05:47:51 -0000 @@ -502,18 +502,6 @@ table.AddRow([Center(Header(2, _('Additional Member Tasks')))]) table.AddCellInfo(table.GetCurrentRowIndex(), 0, colspan=2, bgcolor=mm_cfg.WEB_HEADER_COLOR) - table.AddRow([_( - '''<li>Find members by - <a href="http://www.python.org/doc/current/lib/re-syntax.html" - >Python regular expression</a> (<em>regexp</em>)<br>''')]) - table.AddCellInfo(table.GetCurrentRowIndex(), 0, colspan=2) - table.AddRow([Label(_('Regexp:')), - TextBox('findmember', - value=cgidata.getvalue('findmember', ''), - size='75%')]) - table.AddRow([Center(SubmitButton('findmember_btn', - _('Search...')))]) - table.AddCellInfo(table.GetCurrentRowIndex(), 0, colspan=2) # Add a blank separator row table.AddRow([' ', ' ']) # Add a section to set the moderation bit for all members @@ -789,6 +777,16 @@ header.AddCellInfo(header.GetCurrentRowIndex(), 0, colspan=2, bgcolor=mm_cfg.WEB_HEADER_COLOR) container.AddItem(header) + # Add a "search for member" button + table = Table(width='100%') + link = Link('http://www.python.org/doc/current/lib/re-syntax.html', + _('regular expression')).Format() + table.AddRow([Label(_('Find member by %(link)s:')), + TextBox('findmember', + value=cgidata.getvalue('findmember', '')), + SubmitButton('findmember_btn', _('Search...'))]) + container.AddItem(table) + container.AddItem('<hr><p>') usertable = Table(width="90%", border='2') # If there are more members than allowed by chunksize, then we split the # membership up alphabetically. Otherwise just display them all. From barry@zope.com Thu Mar 28 06:31:47 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Mar 2002 01:31:47 -0500 Subject: [Mailman-Developers] 2.1b1: new_member_options and web GUI References: <6796.1017249443@elisabeth.cfrq.net> <20020327204321.GC22548@rezo.net> Message-ID: <15522.47315.491698.864013@anthem.wooz.org> >>>>> "F" == Fil <fil@rezo.net> writes: F> I mentioned this bug recently : it's apparently because the F> new_member_options is set by multiple checkboxes which all have F> the same name (ie new_member_options), instead of being F> new_member_options_bit0, new_member_options_bit1, and so on. F> I don't know if some web browsers accept this, but none of mine F> do. Actually, the problem is that when none of the checkboxes are selected, the form data will not include a key for 'new_member_options'. The fact that the checkboxes all have the same name is no problem; posting that form data just means the 'new_member_options' key will have a list value instead of a simple string. The list contains all the checked boxes. The hack-around is to add a hidden field with the same name, but with a value 'ignore'. This guarantees that the form data will always contain a 'new_member_options' key, even when all checkboxes are deselected. I will commit a patch shortly, which I've verified with Moz 0.9.9, NS 4.7x, and Konq 2.2, all on various Linuxes. I'd be grateful if someone could test IE5 and IE6 for me. -Barry From jarrell@vt.edu Thu Mar 28 07:32:27 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 28 Mar 2002 02:32:27 -0500 Subject: [Mailman-Developers] install trouble In-Reply-To: <15522.10628.198.448841@anthem.wooz.org> References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020328023136.00a58a30@lennier.cc.vt.edu> At 03:20 PM 3/27/02 -0500, Barry A. Warsaw wrote: > >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: > > RJ> Ah, I see what's going on.. configure changed between 2.0.5 > RJ> and 2.1; in 2.0.5 it just checks "other mail demon" for > RJ> possible groups - and at the time I reviewed that, and > RJ> realized it'd make the right choice. in 2.1 it now checks > RJ> "mailman other mail demon", which causes it to guess wrong, > RJ> because while mailman is the group I want all mailman procs > RJ> running under, sendmail runs in a different group... > >Yeah, I made this change because it makes Postfix installation much >easier. With that MTA, you want your mail programs running under >user.group mailman, so that default makes the most sense (i.e. a >simple "configure ; make install" Just Works). > >Am I being too biased towards Postfix to the detriment of other MTAs? Well, I do get the impression that Postfix is the Official MTA of Mailman, although you're welcome to use one of those *sniff* Other MTA's... From jarrell@vt.edu Thu Mar 28 07:41:57 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 28 Mar 2002 02:41:57 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom In-Reply-To: <20020327210722.GA25138@rezo.net> References: <3CA22F57.F4E106EA@utopia.west.sun.com> <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> <3CA22F57.F4E106EA@utopia.west.sun.com> Message-ID: <5.1.0.14.2.20020328023715.00a317f0@lennier.cc.vt.edu> At 10:07 PM 3/27/02 +0100, Fil wrote: >@ Dan Mick <dmick@utopia.West.Sun.COM> : > > If there were a less-visually-clunky tweak to include it at the top of the > > list, I think it would be better yet. I'll hack around a bit (it seemed > > like a patch job to me visually too). > >I like the idea of having this search box right on the top, on every admin >pane (but very small, ie without helpline and no big button). I think the help and big button are important. *We* don't need it, but one thing mailman has so far been excellant for is handing to only vaugely computer competant people to handle their own lists. I have several lists run by folks for whom the height of technology is using a web browser. They cope quite nicely. But I think we're getting away from that, and they're coping less nicely. I've already gotten a plaintive cry of "where did all my users go?" to the new membership page, followed, after a short explanation of "Ok, explain again everything after "regular expression"? Why do a put an asterisk after the period?" If we don't have an "expert/novice" toggle, then handholding good. From jarrell@vt.edu Thu Mar 28 07:43:55 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 28 Mar 2002 02:43:55 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom In-Reply-To: <20020327210722.GA25138@rezo.net> References: <3CA22F57.F4E106EA@utopia.west.sun.com> <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> <3CA22F57.F4E106EA@utopia.west.sun.com> Message-ID: <5.1.0.14.2.20020328024220.00a5b870@lennier.cc.vt.edu> At 10:07 PM 3/27/02 +0100, Fil wrote: >@ Dan Mick <dmick@utopia.West.Sun.COM> : > > If there were a less-visually-clunky tweak to include it at the top of the > > list, I think it would be better yet. I'll hack around a bit (it seemed > > like a patch job to me visually too). > >I like the idea of having this search box right on the top, on every admin >pane (but very small, ie without helpline and no big button). Oh, and I might add that the biggest complaint came from the owner of the jarrell family genealogy list I host... Amazingly the "J" bucket is *really* busy on that one, and the others have 1 or 2 users, if any :-). From barry@zope.com Thu Mar 28 14:51:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Mar 2002 09:51:41 -0500 Subject: [Mailman-Developers] install trouble References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> <5.1.0.14.2.20020328023136.00a58a30@lennier.cc.vt.edu> Message-ID: <15523.11773.51777.212646@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: RJ> Well, I do get the impression that Postfix is the Official MTA RJ> of Mailman, although you're welcome to use one of those RJ> *sniff* Other MTA's... There is no official MTA of Mailman. Most of my testing happens on Postfix because that's what I happen to use to run my own personal sites. We use Exim on python.org/zope.org, so that one gets a fairly good workout as well. I really want Mailman to be MTA agnostic, but for some of the trickier integration issues, I really need support from you developers to help with MTAs I don't have access too. I'm committed to supporting Sendmail and Qmail, and whatever else folks in the field feel passionately enough about to send me contributions for. The same goes for web servers, although I think there is much less variability on *nix platforms in this regard. -Barry From fil@rezo.net Thu Mar 28 17:24:58 2002 From: fil@rezo.net (Fil) Date: Thu, 28 Mar 2002 18:24:58 +0100 Subject: [Mailman-Developers] lower : traceback Message-ID: <20020328172458.GA7962@rezo.net> While processing bounces, I suspect: ==> logs/error <== Mar 28 18:22:51 2002 (15837) Uncaught runner exception: 'None' object has no attribute 'lower' Mar 28 18:22:51 2002 (15837) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 119, in _dispose mlist.registerBounce(addr, msg) File "/var/local/mailman/Mailman/Bouncer.py", line 96, in registerBounce if not self.isMember(member): File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 79, in isMember cpaddr, where = self.__get_cp_member(member) File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 62, in __get_cp_member lcmember = member.lower() AttributeError: 'None' object has no attribute 'lower' -- Fil From Dan Mick <dmick@utopia.West.Sun.COM> Thu Mar 28 23:30:38 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Thu, 28 Mar 2002 15:30:38 -0800 (PST) Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom Message-ID: <200203282330.g2SNUdWk019177@utopia.West.Sun.COM> > I think the help and big button are important. *We* don't need it, > but one thing mailman has so far been excellant for is handing > to only vaugely computer competant people to handle their own lists. > I have several lists run by folks for whom the height of technology is > using a web browser. They cope quite nicely. But I think we're getting > away from that, and they're coping less nicely. I've already gotten a > plaintive cry of "where did all my users go?" to the new membership > page, followed, after a short explanation of "Ok, explain again everything > after "regular expression"? Why do a put an asterisk after the period?" Novices have *no business* using anything but substring searches... so they don't have to know about . or *. But yes, a "search" button and a help link are good to have regardless. From jarrell@vt.edu Thu Mar 28 23:57:40 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 28 Mar 2002 18:57:40 -0500 Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom In-Reply-To: <3CA22F57.F4E106EA@utopia.west.sun.com> References: <200203252358.g2PNwcWk016100@utopia.West.Sun.COM> <15521.22978.322543.826836@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020328185541.03f234d0@lennier.cc.vt.edu> At 12:45 PM 3/27/02 -0800, Dan Mick wrote: >the point is, with a properly working, easy-to-reach search, I *never* >use the list. Ever. I think it depends on what you're doing... I spend far more time browsing my subscribers, looking for, say, who's in nomail, or something like that, and less often am I in "I need bob" mode, so a clunky browse the list interface really bothers me (and several of my admins). The search box is great if you're looking for someone in particular. But useless if you just want to see all your subscribers. From jarrell@vt.edu Fri Mar 29 06:04:11 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 01:04:11 -0500 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <15522.8527.761356.749127@anthem.wooz.org> References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> At 02:45 PM 3/27/02 -0500, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes: > > RJ> Now, I'd believe there was something wrong with the header > RJ> (although mm ought to catch this more elegantly), except the > RJ> user had just sent it to list1@myserver,list2@myserver, and it > RJ> made it to *list2*, it just won't go through to list1. I > RJ> unshunted it, and it failed again the same way. > > RJ> So how in heck did it get to list2? > > RJ> Barry, I saved the copy I got (I'm on both lists), and the > RJ> shunt files, if you want them; there's nothing private in the > RJ> message. > >Yes, please do send them to me! >-Barry Hey, Barry? It's the topic processor causing it. I got a second message to that same list that generated the same error. I'd tried turning off topics before, since that was one of the two differences between the working, and non working, list. But when I did that, I didn't *delete* the topic, I just disabled it. (Although, if topics are disabled, that really should skip all the topic header scanning... Apparently it doesn't.) I tried disabling topics, *and* deleting my one trial topic. Suddenly the two messages (the one I sent you, and the latest one) would unshunt. The only trial topic I had was, for fooling around purposes, on that list was (from config_list): topics_enabled = 1 topics_bodylines_limit = 5 topics = [('Illuminati', '[fF]nord', 'Illuminated Messages', 0)] From bob@nleaudio.com Fri Mar 29 06:14:36 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 29 Mar 2002 01:14:36 -0500 Subject: [Mailman-Developers] 2.0.6 error Message-ID: <3CA4064C.5EC4ACC1@nleaudio.com> Hi Barry and gang, Just noticed this error from one of my 2.0.6 machines: Mar 10 15:22:24 2002 admin(20550): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(20550): [----- Mailman Version: 2.0.6 -----] admin(20550): [----- Traceback ------] admin(20550): Traceback (most recent call last): admin(20550): File "/home/csc/mailman/scripts/driver", line 96, in run_main admin(20550): main() admin(20550): File "../Mailman/Cgi/private.py", line 160, in main admin(20550): cookie='archive') admin(20550): File "/home/csc/mailman/Mailman/SecurityManager.py", line 66, in WebAuthenticate admin(20550): self.ConfirmUserPassword(user, password) admin(20550): File "/home/csc/mailman/Mailman/SecurityManager.py", line 141, i n ConfirmUserPassword admin(20550): if self.ValidAdminPassword(pw): admin(20550): File "/home/csc/mailman/Mailman/SecurityManager.py", line 45, in ValidAdminPassword admin(20550): if Utils.CheckSiteAdminPassword(pw): admin(20550): File "/home/csc/mailman/Mailman/Utils.py", line 413, in CheckSit eAdminPassword admin(20550): return Crypt.crypt(pw1, salt) == pw2 admin(20550): TypeError: argument 1 must be string without null bytes, not str Any ideas? Was this fixed in subsequent patches? Bob From jarrell@vt.edu Fri Mar 29 06:36:56 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 01:36:56 -0500 Subject: [Mailman-Developers] suggestion for configure Message-ID: <5.1.0.14.2.20020329012652.0553d080@lennier.cc.vt.edu> Add a --with-fqdn and --with-url or equivalent. The current cvs snapshot can't guess my fqdn on my production box, and it's used now to build a web of interconnected addresses, as well as populate the VIRTUAL_HOSTS table, so I had to do a bunch of deleting and repairing in mm_cfg. I can, if I *remember*, which I've already forgotten once, fix it when I build by setting FQDN and URL environment variables, so that configure picks those up by default, but I have a habit of just looking at config.status to see how I ran configure the last time. Having an explicit configure switch would be nice. From jarrell@vt.edu Fri Mar 29 09:50:32 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 04:50:32 -0500 (EST) Subject: [Mailman-Developers] mm-handler Message-ID: <200203290950.g2T9oWH03191@babylon5.cc.vt.edu> Barry - dgc's mm-handler isn't prepared to handle 2.1; it's using the old structure for aliases. Not surprisingly. However, since it's referenced in the docs as a sendmail solution, it'll probably surprise some people who try it, when things go majorly foobar (even the wrapper script name is wrong.) I've gotten it working in my installation. At some point I'll contribute again my mc file that makes installing it a more "sendmail like" operation then the way dgc does it. I've got it on my production and test servers right now, and it seems to be working cleanly. Here's a diff against cvs. I had to change a couple of paths above and beyond the minimum required to get it 2.1 clean, simply to get it to work on my machine, but otherwise this seems to do it. David might have his own way of fixing it, but I'm happy as is now :-). Index: mm-handler =================================================================== RCS file: /cvsroot/mailman/mailman/contrib/mm-handler,v retrieving revision 1.1 diff -r1.1 mm-handler 1c1 < #!/opt/bin/perl --- > #!/usr/local/bin/perl 5d4 < 7,11c6,17 < ## testlist: "|/opt/pkgs/mailman/mail/wrapper post testlist" < ## testlist-admin: "|/opt/pkgs/mailman/mail/wrapper mailowner testlist" < ## testlist-request: "|/opt/pkgs/mailman/mail/wrapper mailcmd testlist" < ## owner-testlist: testlist-admin < ## testlist-owner: testlist-admin --- > ## > ##testlist: "|/home/mailman/mail/mailman post testlist" > ##testlist-admin: "|/home/mailman/mail/mailman admin testlist" > ##testlist-bounces: "|/home/mailman/mail/mailman bounces testlist" > ##testlist-confirm: "|/home/mailman/mail/mailman confirm testlist" > ##testlist-join: "|/home/mailman/mail/mailman join testlist" > ##testlist-leave: "|/home/mailman/mail/mailman leave testlist" > ##testlist-owner: "|/home/mailman/mail/mailman owner testlist" > ##testlist-request: "|/home/mailman/mail/mailman request testlist" > ##testlist-subscribe: "|/home/mailman/mail/mailman subscribe testlist" > ##testlist-unsubscribe: "|/home/mailman/mail/mailman unsubscribe testlist" > ##owner-testlist: testlist-owner 14,15c20,21 < $MMWRAPPER = "/opt/pkgs/mailman/mail/wrapper"; < $MMLISTDIR = "/var/mailman/lists"; --- > $MMWRAPPER = "/home/mailman/mail/mailman"; > $MMLISTDIR = "/home/mailman/lists"; 122a129,130 > my @validfields = qw(admin bounces confirm join leave owner request > subscribe unsubscribe); 124,132c132,139 < if ($addr =~ /(.*)-admin$/ < || $addr =~ /(.*)-owner$/ < || $addr =~ /^owner-(.*)$/) { < $list = $1; < $cmd = "mailowner"; < } elsif ($addr =~ /(.*)-request$/) { < $list = $1; < $cmd = "mailcmd"; < } else { --- > $addr =~ /(.*)-(.*)$/; > $list = $1; > $cmd = $2; > if ($list eq "owner") { > $list = $cmd; > $cmd = "owner"; > } > if (!grep /^$cmd$/, @validfields) { 190c197 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") { 192c199 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") { From fil@rezo.net Fri Mar 29 10:15:59 2002 From: fil@rezo.net (Fil) Date: Fri, 29 Mar 2002 11:15:59 +0100 Subject: [Mailman-Developers] traceback (still due to the BounceRunner) Message-ID: <20020329101559.GB10726@rezo.net> Hello, I've sent yesterday one of these "big bounce list" message, and the BounceRunner is still processing bounces, 100% CPU for hours... Not a problem if the new locking scheme worked, but, unfortunately, it doesn't when the qfiles/bounces/ directory is full : the BounceRunner doesn't know how to pause from time to time. >From what I see it needs about 5-6 seconds (on a 50000 subscribers' list) to process and register one bounce. So it really shouldn't process more than 4 in a row (ie in a minute) if we want the lockfile to be released before 30 secs. However that would mean processing 4 bounces per minute. If you have 50 000 bounces, that's 12 500 minutes... not good. I don't know what to suggest, except maybe to make a BounceRunner preprocessor that doesn't read or write the list files, but just extracts the bounce information and gets rid fast of the bounce files. Then for the "real" BounceRunner to process the bounce information already computed would be very fast. Traceback (most recent call last): File "/var/local/mailman/Mailman/MailCommandHandler.py", line 273, in +ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/var/local/mailman/Mailman/MailCommandHandler.py", line 727, in +ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/var/local/mailman/Mailman/MailList.py", line 967, in +ProcessConfirmation data = Pending.confirm(cookie) File "/var/local/mailman/Mailman/Pending.py", line 94, in confirm lock.lock(timeout=30) File "/var/local/mailman/Mailman/LockFile.py", line 292, in lock raise TimeOutError TimeOutError -- Fil From jarrell@vt.edu Fri Mar 29 10:47:56 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 05:47:56 -0500 Subject: [Mailman-Developers] cgi create error Message-ID: <5.1.0.14.2.20020329054424.05230e00@lennier.cc.vt.edu> Didn't "ko" need to get added to the LC_DESCRIPTIONS dictionary in Defaults? Traceback (most recent call last): File "/home/mailman/scripts/driver", line 82, in run_main main() File "/home/mailman/Mailman/Cgi/create.py", line 60, in main request_creation(doc) File "/home/mailman/Mailman/Cgi/create.py", line 375, in request_creation [_(Utils.GetLanguageDescr(L)) for L in langs], File "/home/mailman/Mailman/Utils.py", line 647, in GetLanguageDescr return mm_cfg.LC_DESCRIPTIONS[lang][0] KeyError: ko From jarrell@vt.edu Fri Mar 29 11:00:06 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 06:00:06 -0500 (EST) Subject: [Mailman-Developers] config_list Message-ID: <200203291100.g2TB06M08966@babylon5.cc.vt.edu> Uh, I think the cutting and pasting was a little too literal here... A segment from a dump of one of my lists... ## Privacy options # # When a message is posted to the list, a series of moderation steps are # take to decide whether the a moderator must first approve the message # or not. This section contains the controls for moderation of both # member and non-member postings. # # <p>Member postings are held for moderation if their <b>moderation # flag</b> is turned on. You can control whether member postings are # moderated by default or not. # # <p>Non-member postings can be automatically <a # href="?VARHELP=privacy/sender/accept_these_nonmembers" >accepted</a>, # <a href="?VARHELP=privacy/sender/hold_these_nonmembers">held for # moderation</a>, <a # href="?VARHELP=privacy/sender/reject_these_nonmembers" >rejected</a> # (bounced), or <a # href="?VARHELP=privacy/sender/discard_these_nonmembers" # >discarded</a>, either individually or as a group. Any posting from a # non-member who is not explicitly accepted, rejected, or discarded, # will have their posting filtered by the <a # href="?VARHELP=privacy/sender/generic_nonmember_action">general # non-member rules</a>. # # <p>In the text boxes below, add one address per line; start the line # with a ^ character to designate a <a href= # "http://www.python.org/doc/current/lib/module-re.html" >Python regular # expression</a>. When entering backslashes, do so as if you were using # Python raw strings (i.e. you generally just use a single backslash). # # <p>Note that non-regexp matches are always done first. # Each list member has a moderation flag which says whether messages # from the list member can be posted directly to the list, or must first # be approved by the list moderator. When the moderation flag is turned # on, list member postings must be approved first. You, the list # administrator can decide whether a specific individual's postings will # be moderated or not. # # When a new member is subscribed, their initial moderation flag takes # its value from this option. Turn this option off to accept member # postings by default. Turn this option on to, by default, moderate # member postings first. You can always manually set an individual # member's moderation bit by using the membership management screens. # # legal values are: # 0 = "No" # 1 = "Yes" default_member_moderation = 1 BTW, am I just missing it, or is config_list the only place you can change default_member_moderation? I didn't see a likely checkbox in the cgi screens... From jarrell@vt.edu Fri Mar 29 11:20:13 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 06:20:13 -0500 Subject: [Mailman-Developers] mm-handler In-Reply-To: <200203290950.g2T9oWH03191@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020329061916.044d8bc0@lennier.cc.vt.edu> At 04:50 AM 3/29/02 -0500, I wrote: >but I'm happy as is now :-). Mostly happy. I just realized that while I've built in support for all the basic stuff, the VERP-like bouncing isn't handled... Which won't be too much of a chore to add. From jarrell@vt.edu Fri Mar 29 12:33:10 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 07:33:10 -0500 (EST) Subject: [Mailman-Developers] mm-handler redux Message-ID: <200203291233.g2TCXAm16595@babylon5.cc.vt.edu> Ok. Diff against cvs again. Handles the VERP tokens just fine. If I wasn't *still* here fiddling at 7am it'd probably be a tad more elegant, but it work. Index: mm-handler =================================================================== RCS file: /cvsroot/mailman/mailman/contrib/mm-handler,v retrieving revision 1.1 diff -r1.1 mm-handler 1c1 < #!/opt/bin/perl --- > #!/usr/local/bin/perl 5d4 < 7,11c6,17 < ## testlist: "|/opt/pkgs/mailman/mail/wrapper post testlist" < ## testlist-admin: "|/opt/pkgs/mailman/mail/wrapper mailowner testlist" < ## testlist-request: "|/opt/pkgs/mailman/mail/wrapper mailcmd testlist" < ## owner-testlist: testlist-admin < ## testlist-owner: testlist-admin --- > ## > ##testlist: "|/home/mailman/mail/mailman post testlist" > ##testlist-admin: "|/home/mailman/mail/mailman admin testlist" > ##testlist-bounces: "|/home/mailman/mail/mailman bounces testlist" > ##testlist-confirm: "|/home/mailman/mail/mailman confirm testlist" > ##testlist-join: "|/home/mailman/mail/mailman join testlist" > ##testlist-leave: "|/home/mailman/mail/mailman leave testlist" > ##testlist-owner: "|/home/mailman/mail/mailman owner testlist" > ##testlist-request: "|/home/mailman/mail/mailman request testlist" > ##testlist-subscribe: "|/home/mailman/mail/mailman subscribe testlist" > ##testlist-unsubscribe: "|/home/mailman/mail/mailman unsubscribe testlist" > ##owner-testlist: testlist-owner 14,15c20,21 < $MMWRAPPER = "/opt/pkgs/mailman/mail/wrapper"; < $MMLISTDIR = "/var/mailman/lists"; --- > $MMWRAPPER = "/home/mailman/mail/mailman"; > $MMLISTDIR = "/home/mailman/lists"; 122a129,130 > my @validfields = qw(admin bounces confirm join leave owner request > subscribe unsubscribe); 124,126c132 < if ($addr =~ /(.*)-admin$/ < || $addr =~ /(.*)-owner$/ < || $addr =~ /^owner-(.*)$/) { --- > if ($addr =~ /(.*)-(.*)\+.*$/) { 128,129c134,136 < $cmd = "mailowner"; < } elsif ($addr =~ /(.*)-request$/) { --- > $cmd = "$2"; > } else { > $addr =~ /(.*)-(.*)$/; 131c138,144 < $cmd = "mailcmd"; --- > $cmd = $2; > } > if (grep /^$cmd$/, @validfields) { > if ($list eq "owner") { > $list = $cmd; > $cmd = "owner"; > } 190c203 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") { 192c205 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") { From jarrell@vt.edu Fri Mar 29 12:34:52 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 07:34:52 -0500 (EST) Subject: [Mailman-Developers] important VERP safety tip... Message-ID: <200203291234.g2TCYqu16784@babylon5.cc.vt.edu> Important thing to remember (and probably something that ought to go into the faq, or the readme, or somewhere, or even into Defaults.py)... If you change your VERP options, do a mailmanctl restart so that the damn queuerunners will re-read mm_cfg.py... Unless you *like* chasing your tail for a couple of hours. From mentor@alb-net.com Fri Mar 29 13:19:23 2002 From: mentor@alb-net.com (Mentor Cana) Date: Fri, 29 Mar 2002 08:19:23 -0500 (EST) Subject: [Mailman-Developers] bin/qrunner picking up changes Message-ID: <Pine.GSO.4.44.0203290811010.10515-100000@alb-net.com> With the latest CVS, whenever list's configuration changes (i.e. new headers or footers) a bin/mailmanctl restart is needed. This could confuse lists owners who expect (rightfully so) to see the changed footers or headers on their lists as soon as they save the configuration. Should the "Submit Your Changes" button do a "bin/mailmanctl restart" after successfully saving list's changes? (I'm not sure of this behavior is limited to headers and footers only) -- Mentor From db@bibsys.no Fri Mar 29 13:57:36 2002 From: db@bibsys.no (Daniel Buchmann) Date: Fri, 29 Mar 2002 14:57:36 +0100 Subject: [Mailman-Developers] config_list References: <200203291100.g2TB06M08966@babylon5.cc.vt.edu> Message-ID: <3CA472D0.3A306900@bibsys.no> Ron Jarrell wrote: > BTW, am I just missing it, or is config_list the only place you > can change default_member_moderation? I didn't see a likely checkbox > in the cgi screens... Looks like you've missed something, because the privacy/sender screen has it all... (Privacy Options -> Sender Filters) ;) From jarrell@vt.edu Fri Mar 29 14:02:42 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 09:02:42 -0500 Subject: [Mailman-Developers] config_list In-Reply-To: <3CA472D0.3A306900@bibsys.no> References: <200203291100.g2TB06M08966@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020329090201.08932c70@lennier.cc.vt.edu> At 02:57 PM 3/29/02 +0100, Daniel Buchmann wrote: >Ron Jarrell wrote: > >> BTW, am I just missing it, or is config_list the only place you >> can change default_member_moderation? I didn't see a likely checkbox >> in the cgi screens... > >Looks like you've missed something, because the privacy/sender screen >has it all... >(Privacy Options -> Sender Filters) Huh. Sure enough, right there. Ok, it must be time to go to bed, I swear I looked there, but never saw it. I'm getting too bleary. From jwblist@olympus.net Fri Mar 29 17:52:17 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 29 Mar 2002 09:52:17 -0800 Subject: [Mailman-Developers] bin/qrunner picking up changes In-Reply-To: <Pine.GSO.4.44.0203290811010.10515-100000@alb-net.com> References: <Pine.GSO.4.44.0203290811010.10515-100000@alb-net.com> Message-ID: <p05101502b8ca59a1274c@[207.149.192.229]> At 8:19 -0500 3/29/2002, Mentor Cana wrote: >With the latest CVS, whenever list's configuration changes (i.e. new headers >or footers) a bin/mailmanctl restart is needed. > >This could confuse lists owners who expect (rightfully so) to see the >changed footers or headers on their lists as soon as they save the >configuration. Should the "Submit Your Changes" button do a "bin/mailmanctl >restart" after successfully saving list's changes? > >(I'm not sure of this behavior is limited to headers and footers only) > The issue is bigger than presented above (I don't have a 2.1.anything installation to play with). But simply telling a list owner to run bin/mailmanctl restart won't do the trick: most list owners don't have the power to run that command (or any shell access at all). Therefore, I'm pretty sure a solution is in the works. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From mentor@alb-net.com Fri Mar 29 18:08:03 2002 From: mentor@alb-net.com (Mentor Cana) Date: Fri, 29 Mar 2002 13:08:03 -0500 (EST) Subject: [Mailman-Developers] bin/qrunner picking up changes In-Reply-To: <p05101502b8ca59a1274c@[207.149.192.229]> Message-ID: <Pine.GSO.4.44.0203291305220.14979-100000@alb-net.com> On Fri, 29 Mar 2002, at 09:52 -0800, John W Baxter wrote: > >This could confuse lists owners who expect (rightfully so) to see the > >changed footers or headers on their lists as soon as they save the > >configuration. Should the "Submit Your Changes" button do a "bin/mailmanctl > >restart" after successfully saving list's changes? > > > >(I'm not sure of this behavior is limited to headers and footers only) > > > The issue is bigger than presented above (I don't have a 2.1.anything > installation to play with). > > But simply telling a list owner to run > bin/mailmanctl restart > won't do the trick: most list owners don't have the power to run that > command (or any shell access at all). > > Therefore, I'm pretty sure a solution is in the works. My suggestions was that the "Submit Your Changes" button perform (transparently from the list owner) the "bin/mailmanctl restart" after saving the list configuration (if there was a change). -- Mentor From barry@zope.com Fri Mar 29 19:02:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 29 Mar 2002 14:02:42 -0500 Subject: [Mailman-Developers] 2.0.8 - qrunner on solaris References: <20020307121214.L38424@web.ca> Message-ID: <15524.47698.321788.407318@anthem.wooz.org> >>>>> "RE" == Rob Ellis <rob@web.ca> writes: RE> I'm not sure if this is appropriate here, so apologies in RE> advance if it isn't... Yup, this is the right place. RE> We're using Mailman 2.0.8 on a sun ultra with solaris 8, RE> and we were running into two problems with qrunner... RE> The first was a race condition where this code in qrunner RE> - # If the .db file has no corresponding .msg file, we might RE> as well - # remove the .db file, since there's little we can RE> do about it. - if not os.path.exists(root+'.msg'): - RE> syslog('qrunner', 'Unlinking orphaned .db file: %s.db' % root) RE> - os.unlink(root+'.db') RE> was unlinking .db files before their corresponding .msg files RE> were created. We just removed those lines and it seems to be RE> ok -- no orphaned .db files and no more orphaned .msg files. I don't think this is quite the right fix. In MM2.0.x, qrunner keys off the .msg file, and Message.Enqueue() is careful to write the .db file first and then the .msg file. You're right that there's a race condition though, because the test in qrunner's main() is backwards! Since the .db is written first, followed by the .msg, you really want to look for orphaned .msg files not .db files. This is because .db files may legitimately not have a corresponding .msg file if the enqueing processes hasn't completed yet. See the attached patch for a better solution, which also includes some paranoia guards in Message.Enqueue() so that it atomically makes the .msg files available. Note: this patch is untested, and I don't think I'll get to testing it today. I will likely test it next week on python.org (yikes!) and if it looks good, I will issue a MM2.0.9 with this fix (and a few others). I'd appreciate it if someone else could verify this works and doesn't break anything else. RE> The second problem was that qrunner was crashing on some kinds RE> of bounce messages (?), causing messages to pile up in the RE> queue occasionally. It was generating errors like this: RE> The patch below seems to fix the problem (?)... we're now RE> seeing some errors like this: Good patch. This can happen if a message doesn't have a Content-Type: header at all. This will be in MM2.0.9 as well. -Barry -------------------- snip snip -------------------- Index: Mailman/Message.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Message.py,v retrieving revision 1.40 diff -u -r1.40 Message.py --- Mailman/Message.py 2 Aug 2000 02:00:13 -0000 1.40 +++ Mailman/Message.py 29 Mar 2002 19:00:57 -0000 @@ -177,11 +177,14 @@ marshal.dump(msgdata, dbfp) dbfp.close() # If it doesn't already exist, or if the text of the message has - # changed, write the message file to disk. + # changed, write the message file to disk, but do it atomically so as + # not to hit a race condition with the qrunner. if not existsp or dirty: - msgfp = Utils.open_ex(msgfile, 'w') + tmpfile = msgfile + '.tmp' + msgfp = Utils.open_ex(tmpfile, 'w') msgfp.write(text) msgfp.close() + os.rename(tmpfile, msgfile) Index: cron/qrunner =================================================================== RCS file: /cvsroot/mailman/mailman/cron/Attic/qrunner,v retrieving revision 1.18.2.3 diff -u -r1.18.2.3 qrunner --- cron/qrunner 18 Apr 2001 03:58:35 -0000 1.18.2.3 +++ cron/qrunner 29 Mar 2002 19:00:58 -0000 @@ -195,13 +195,11 @@ lock.refresh() root, ext = os.path.splitext(os.path.join(mm_cfg.QUEUE_DIR, file)) if ext == '.db': - # If the .db file has no corresponding .msg file, we might as well - # remove the .db file, since there's little we can do about it. - if not os.path.exists(root+'.msg'): - syslog('qrunner', 'Unlinking orphaned .db file: %s.db' % root) - os.unlink(root+'.db') - # just trigger off the .msg files + # Just trigger off the .msg files continue + if not os.path.exists(root+'.db'): + syslog('qrunner', 'Unlinking orphaned .msg file: %s.msg' % root) + os.unlink(root+'.msg') # Have we exceeded either resource limit? if mm_cfg.QRUNNER_PROCESS_LIFETIME is not None and \ (time.time() - t0) > mm_cfg.QRUNNER_PROCESS_LIFETIME: From barry@zope.com Fri Mar 29 19:17:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 29 Mar 2002 14:17:48 -0500 Subject: [Mailman-Developers] How you can help (was: Re: [Mailman-i18n] korean translation) References: <87vgbfll0j.fsf@nausicaa.interq.or.jp> <200203291508.g2TF8HtM008902@paros.informatik.hu-berlin.de> <15524.36073.411853.571625@anthem.wooz.org> Message-ID: <15524.48604.43662.749564@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: BAW> One way to help out right now: I can add you as a tracker BAW> admin and you can help do triage on the bugs and patches. BAW> This actually would be an enormous help, because there's a BAW> lot of things to go through. Even weeding out those issues BAW> that are no longer relevant for MM2.1, and assigning BAW> everything that's left to me would help a lot. Here's another way volunteers could really help the project out. If we had a release czar for the 2.0.x series, then it would free me up to concentrate on finishing 2.1. As an example, my previous message on the qrunner race condition in MM2.0.8. I'm at the pont where I can /only/ find the time to fix the most critical of bugs in 2.0.x, and I definitely do not have the time to add anything new, or even vette any large patches. I obviously haven't done very well at managing the 2.0.x bug and patch trackers. The Python project has been very successful with release czars for maintenance branches older than the trunk, and I think those successes could translate here (we're smaller so it should be easier). Some of you have a very good working knowledge of the code base, and I think you would do a good job as MM2.0.x czar. I'm always here to consult of course. :) Cheers, -Barry From barry@zope.com Fri Mar 29 19:21:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 29 Mar 2002 14:21:12 -0500 Subject: [Mailman-Developers] qrunner fails to start on 2.1b4 References: <Pine.LNX.4.33.0203180117510.19608-100000@pannier.cfsc.ottawa.on.ca> Message-ID: <15524.48808.431952.741177@anthem.wooz.org> >>>>> "BD" == Brett Delmage <brett@twobikes.ottawa.on.ca> writes: BD> I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python BD> 2.1.1 BD> A problem showed up during make install, where paths.py was BD> not copied into the bin, scripts, cron directories. Okay, you need to figure out why paths.py wasn't copied. It may be a permission problem, or it may be something deeper. I definitely haven't seen this myself, so something weird's going on with your environment. BD> I copied it in manually and that cleared the initial problems: BD> the Cgi parts seemed to work (without exhaustive testing). BD> Now I'm running into the followuing problems with qrunner but BD> I am not sure where to look. Suggestions? It looks like it BD> might still be related to paths.py? Very likely, although if bin/qrunner (which is what spits out these errors) couldn't import Mailman.Queue.* via the __import__() call in make_qrunner() , then how did it get far enough to import the various modules at the top of the file? Very strange. -Barry From barry@zope.com Fri Mar 29 19:30:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 29 Mar 2002 14:30:42 -0500 Subject: [Mailman-Developers] bin/qrunner picking up changes References: <Pine.GSO.4.44.0203290811010.10515-100000@alb-net.com> Message-ID: <15524.49378.309511.942924@anthem.wooz.org> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes: MC> With the latest CVS, whenever list's configuration changes MC> (i.e. new headers or footers) a bin/mailmanctl restart is MC> needed. I can reproduce this, and it is definitely a bug. When you change a list's configuration through the web, it should never require a bin/mailmanctl restart. I'll work on a fix, but no promises that it'll be working by the weekend. The restart may be necessary if you change stuff in Defaults.py/mm_cfg.py, but that's okay because you already have command line access in that case. Aside: a restart isn't necessary if you're just mucking with the web side of things. -Barry From dmick@utopia.West.Sun.COM Fri Mar 29 21:53:17 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Fri, 29 Mar 2002 13:53:17 -0800 Subject: [Mailman-Developers] important VERP safety tip... References: <200203291234.g2TCYqu16784@babylon5.cc.vt.edu> Message-ID: <3CA4E24D.2527B5F3@utopia.west.sun.com> I never do *anything* to my Mailman setup without running /etc/init.d/mailman stop first, and then /etc/init.d/mailman start later. (I got this training when restart didn't really work, and it keeps me from having inconsistent files while the runners are running, which might not be an issue, or might, I don't know.) Ron Jarrell wrote: > > Important thing to remember (and probably something that ought to > go into the faq, or the readme, or somewhere, or even into Defaults.py)... > > If you change your VERP options, do a mailmanctl restart so that the damn > queuerunners will re-read mm_cfg.py... Unless you *like* chasing your > tail for a couple of hours. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From jarrell@vt.edu Sat Mar 30 02:34:16 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 21:34:16 -0500 Subject: [Mailman-Developers] bin/qrunner picking up changes In-Reply-To: <Pine.GSO.4.44.0203291305220.14979-100000@alb-net.com> References: <p05101502b8ca59a1274c@[207.149.192.229]> Message-ID: <5.1.0.14.2.20020329213151.00a17260@lennier.cc.vt.edu> At 01:08 PM 3/29/02 -0500, Mentor Cana wrote: >On Fri, 29 Mar 2002, at 09:52 -0800, John W Baxter wrote: > > >This could confuse lists owners who expect (rightfully so) to see the > > >changed footers or headers on their lists as soon as they save the > > >configuration. Should the "Submit Your Changes" button do a > "bin/mailmanctl > > >restart" after successfully saving list's changes? > > > > > >(I'm not sure of this behavior is limited to headers and footers only) > > > > > The issue is bigger than presented above (I don't have a 2.1.anything > > installation to play with). > > > > But simply telling a list owner to run > > bin/mailmanctl restart > > won't do the trick: most list owners don't have the power to run that > > command (or any shell access at all). > > > > Therefore, I'm pretty sure a solution is in the works. > >My suggestions was that the "Submit Your Changes" button perform >(transparently from the list owner) the "bin/mailmanctl restart" after >saving the list configuration (if there was a change). That could lead to havoc on a busy machine - imagine a site with a couple of hundred lists - just 4-5 administrators making a couple of changes here and there could cause dozens of restarts in a short period of time. A better, long term, solution, is for the qrunners to detect that changes have happened in the files that contain structures they need, and for them to either reinstantiate the strucutre if possible, or, if not, to voluntarily restart themselves then. From marc_news@vasoftware.com Sat Mar 30 02:55:27 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 29 Mar 2002 18:55:27 -0800 Subject: [Mailman-Developers] install trouble In-Reply-To: <5.1.0.14.2.20020328023136.00a58a30@lennier.cc.vt.edu> References: <200203262322.g2QNM4M16097@babylon5.cc.vt.edu> <5.1.0.14.2.20020326183123.043b0060@lennier.cc.vt.edu> <5.1.0.14.2.20020328023136.00a58a30@lennier.cc.vt.edu> Message-ID: <20020330025527.GX31155@merlins.org> On Thu, Mar 28, 2002 at 02:32:27AM -0500, Ron Jarrell wrote: > >Am I being too biased towards Postfix to the detriment of other MTAs? > > Well, I do get the impression that Postfix is the Official MTA of Mailman, > although you're welcome to use one of those *sniff* Other MTA's... Funny, I thought it was exim all this time. Barry just hasn't switched yet :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick <dmick@utopia.West.Sun.COM> Sat Mar 30 04:13:21 2002 From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick) Date: Fri, 29 Mar 2002 20:13:21 -0800 (PST) Subject: [Mailman-Developers] "search for member with RE" box at top instead of bottom Message-ID: <200203300413.g2U4DMWk019085@utopia.West.Sun.COM> > See what you think about this (against cvs)... Very nice; thank you. From jarrell@vt.edu Sat Mar 30 04:01:10 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 23:01:10 -0500 Subject: [Mailman-Developers] admindb Message-ID: <5.1.0.14.2.20020329230006.00a0a9b0@mail.vt.edu> When selecting the "forward to" option (and leaving it otherwise deferred) I get this: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 82, in run_main main() File "/home/mailman/Mailman/Cgi/admindb.py", line 159, in main process_form(mlist, doc, cgidata) File "/home/mailman/Mailman/Cgi/admindb.py", line 644, in process_form forward, forwardaddr) File "/home/mailman/Mailman/ListAdmin.py", line 175, in HandleRequest forward, addr) File "/home/mailman/Mailman/ListAdmin.py", line 311, in __handlepost copy, lang) File "/home/mailman/Mailman/Message.py", line 158, in __init__ self.set_payload(text, charset) File "/home/mailman/pythonlib/email/Message.py", line 160, in set_payload self.set_charset(charset) File "/home/mailman/pythonlib/email/Message.py", line 198, in set_charset cte(self) File "/home/mailman/pythonlib/email/Encoders.py", line 75, in encode_7or8bit orig.encode('ascii') AttributeError: Message instance has no attribute 'encode' This was a fairly large note with a mime attachment. From jarrell@vt.edu Sat Mar 30 04:50:59 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 29 Mar 2002 23:50:59 -0500 Subject: [Mailman-Developers] admindb In-Reply-To: <5.1.0.14.2.20020329230006.00a0a9b0@mail.vt.edu> Message-ID: <5.1.0.14.2.20020329235030.00a17200@lennier.cc.vt.edu> At 11:01 PM 3/29/02 -0500, I wrote: >When selecting the "forward to" option (and leaving it otherwise deferred) >I get this: Actually, turns out, when I select *anything* I get that traceback... From claw@kanga.nu Sat Mar 30 20:20:50 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 30 Mar 2002 12:20:50 -0800 Subject: [Mailman-Developers] traceback (still due to the BounceRunner) In-Reply-To: Message from Fil <fil@rezo.net> of "Fri, 29 Mar 2002 11:15:59 +0100." <20020329101559.GB10726@rezo.net> References: <20020329101559.GB10726@rezo.net> Message-ID: <27113.1017519650@kanga.nu> On Fri, 29 Mar 2002 11:15:59 +0100 fil <fil@rezo.net> wrote: > From what I see it needs about 5-6 seconds (on a 50000 subscribers' > list) to process and register one bounce. So it really shouldn't > process more than 4 in a row (ie in a minute) if we want the lockfile > to be released before 30 secs. However that would mean processing 4 > bounces per minute. If you have 50 000 bounces, that's 12 500 > minutes... not good. I don't know what to suggest, except maybe to > make a BounceRunner preprocessor that doesn't read or write the list > files, but just extracts the bounce information and gets rid fast of > the bounce files. Then for the "real" BounceRunner to process the > bounce information already computed would be very fast. Bounce processing really needs to be abstracted into a two pass process. Due to its current ad-hoc nature load and lookup expense for processing the membership roster is dominating the equation. Suggest: One pass does nothing but parse the incoming bounces for addresses and then adds them to a local/shared DB. An infrequently run cronjob (suggest no more than a couple times a day), then picks up this DB and handles the removals in a single fast locked process. -- 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 spertus@mills.edu Sat Mar 30 23:25:21 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 30 Mar 2002 15:25:21 -0800 Subject: [Mailman-Developers] Problem with substitution of %(listname) Message-ID: <5.1.0.14.0.20020330151038.03574a90@ella.mills.edu> --=====================_22988906==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I created a new list named "Sys". When I subscribe and confirm by web, I get the following web page. Note the "%(listname)s" on the second line. Awaiting moderator approval You have successfully confirmed your subscription request to the mailing list %(listname)s, however final approval is required from the list moderator before you will be subscribed. Your request has been forwarded to the list moderator, and you will be notified of the moderator's decision. -------------------------------------------------------------------------------- Sys list run by spertus at mills.edu Sys administrative interface (requires authorization) Overview of all javamlm.mills.edu mailing lists Later substitutions (such as at the foot of the page) are successful. When I look at the list directly in Python, it seems to be okay: >>> sys <mailing list "sys" (unlocked) at 82fb764> >>> sys.real_name 'Sys' >>> sys._internal_name 'sys' I'm using Mailman 2.1a3. Any ideas what could be wrong? Ellen --=====================_22988906==_.ALT Content-Type: text/html; charset="us-ascii" <html> I created a new list named "Sys".  When I subscribe and confirm by web, I get the following web page.  Note the "%(listname)s" on the second line.<br> <dl> <dd>Awaiting moderator approval <dd>You have successfully confirmed your subscription request to the mailing list %(listname)s, however final approval is required from the list moderator before you will be subscribed. Your request has been forwarded to the list moderator, and you will be notified of the moderator's decision. <dd>--------------------------------------------------------------------------------<br><br> <dd>Sys list run by spertus at mills.edu <dd>Sys administrative interface (requires authorization) <dd>Overview of all javamlm.mills.edu mailing lists<br><br> </dl>Later substitutions (such as at the foot of the page) are successful.  When I look at the list directly in Python, it seems to be okay:<br> <dl> <dd>>>> sys <dd><mailing list "sys" (unlocked) at 82fb764> <dd>>>> sys.real_name <dd>'Sys' <dd>>>> sys._internal_name <dd>'sys'<br><br> </dl>I'm using Mailman 2.1a3.  Any ideas what could be wrong?<br><br> Ellen<br> </html> --=====================_22988906==_.ALT-- From marc_news@vasoftware.com Sun Mar 31 06:09:34 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 30 Mar 2002 22:09:34 -0800 Subject: [Mailman-Developers] RFE: configurable bounce message Message-ID: <20020331060934.GM7277@merlins.org> I had to modify the string Moderate.py to give a more appropriate reject message. Ideally this should be a string per list. ----- Forwarded message from svlug-owner@svlug.org ----- Subject: test 3 From: x To: y You are not allowed to post to this mailing list without being subscribed, and your message has been automatically rejected. You should subscribe to the list to be able to post. If you think that you messages are being rejected in error, contact the mailing list owner at svlug-owner@lists.svlug.org. (...) ----- End forwarded message ----- -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From james@daa.com.au Mon Mar 25 14:21:03 2002 From: james@daa.com.au (James Henstridge) Date: Mon, 25 Mar 2002 22:21:03 +0800 Subject: [Mailman-Developers] mailman filter for SpamAssassin support Message-ID: <3C9F324F.5070906@daa.com.au> I uploaded a patch to the SF bug tracker today that adds support for doing SpamAssassin (http://spamassassin.taint.org/) checks to the mailman message pipeline: http://sourceforge.net/tracker/?func=detail&aid=534577&group_id=103&atid=300103 This will contact the spamd daemon to score the message. If the message gets scored above one threshold, it gets discarded (this defaults to 10, but can be customised in the mm_cfg.py file). If the message scores above another lower threshold, it gets held for moderation (this defaults to 5). I wrote this to try and reduce the number of messages held for moderation. I wrote it for mailman 2.0.x (as that is what I am using at the moment), but it should be fairly easy to update for 2.1. It might be worth using on the python.org mailing lists ... James. (I am not on the mailing list, so please don't remove me from the CC list on replies). -- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/ From barry@zope.com Fri Mar 29 15:48:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 29 Mar 2002 10:48:57 -0500 Subject: [Mailman-Developers] Re: [Mailman-i18n] korean translation References: <87vgbfll0j.fsf@nausicaa.interq.or.jp> <200203291508.g2TF8HtM008902@paros.informatik.hu-berlin.de> Message-ID: <15524.36073.411853.571625@anthem.wooz.org> >>>>> "MvL" == Martin von Loewis <loewis@informatik.hu-berlin.de> writes: MvL> Then please take my apologies: from your response, I assumed MvL> that you would indeed co-maintain mailman. My original MvL> question remains, though: MvL> Is anybody considering these patches (not just my own; I MvL> notice that the oldest patch which had no review is dated MvL> 2000-09-21)? At present, I'm really the only one actually committing changes to cvs, although several people (Ben, Dan and Daniel, Ron, etc.) do provide very excellent patches. You too Martin. But this means I'm the bottleneck for getting fixes in, and that's subject to the vagaries of my "real" job. ;) One way to help out right now: I can add you as a tracker admin and you can help do triage on the bugs and patches. This actually would be an enormous help, because there's a lot of things to go through. Even weeding out those issues that are no longer relevant for MM2.1, and assigning everything that's left to me would help a lot. I'd also love it if someone would take responsibility for Pipermail. As crufty as it is, it's all we have, and it's good enough for many people. But it's a complicated system that needs its own steward. Anybody willing to put the time and effort into it, I'd be happy to add as a cvs committer (although we have to watch out about GNU issues -- but several people have already assigned their future changes to the FSF). As for the core system, I admit to being protective of it. I'm willing to loosen my grip if it helps Mailman development move along faster. There are folks in the community who know enough about the system, and whom I trust to make changes to the code. -Barry From vladimir@acm.org Fri Mar 29 22:10:23 2002 From: vladimir@acm.org (Vladimir G. Ivanovic) Date: Fri, 29 Mar 2002 14:10:23 -0800 Subject: [Mailman-Developers] A quick thank you Message-ID: <200203292210.g2TMANO18099@bach.leonora.org> After struggling with Majordomo(*), a heartfelt thanks to all for making mailing lists so painless. I was up and running in minutes. --- Vladimir (*) Majordomo was wonderful in its day, but clearly its day is past. -------- Vladimir G. Ivanovic http://leonora.org/~vladimir 2770 Cowper St. vladimir@acm.org Palo Alto, CA 94306-2447 +1 650 678 8014