Mailman 3 March 2002 - Mailman-Developers

Macintosh files when uploading "mass subscription " lists
by Fil 12 Mar '02

12 Mar '02

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

3 4

Bug in latest CVS: confirm.py
by Dan Mick 12 Mar '02

12 Mar '02

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

2 1

Database version updates drop nomail settings
by Les Niles 12 Mar '02

12 Mar '02

There's a small bug in 2.1alpha4 in updating a list's database to the DATA_FILE_VERSION, causing "nomail" settings to not be propagated forward: MailList.CheckVersion() reloads the database, taking care to make sure that the reload doesn't trigger a recursive call to CheckVersion(). But if the list wasn't locked, CheckVersion() then calls Lock(), and Lock() calls Load() again, this time generating a recursive call to CheckVersion(). This recursion is only one deep because now the list is locked, but even that is too much for versions.CanonicalizeUserOptions() since it clears the old-style "nomail" flag after setting the delivery status in the new database. Here's a patch that fixes this. -les --------------------------------------------------------------------- *** MailList.py.orig Sun Jan 6 23:04:01 2002 --- MailList.py Sat Feb 9 22:42:36 2002 *************** *** 146,157 **** # # Lock management # ! def Lock(self, timeout=0): self.__lock.lock(timeout) # Must reload our database for consistency. Watch out for lists that # don't exist. try: ! self.Load() except Exception: self.Unlock() raise --- 146,157 ---- # # Lock management # ! def Lock(self, timeout=0, check_version=1): self.__lock.lock(timeout) # Must reload our database for consistency. Watch out for lists that # don't exist. try: ! self.Load(check_version) except Exception: self.Unlock() raise *************** *** 557,563 **** # We must hold the list lock in order to update the schema waslocked = self.Locked() if not waslocked: ! self.Lock() try: from versions import Update Update(self, stored_state) --- 558,564 ---- # We must hold the list lock in order to update the schema waslocked = self.Locked() if not waslocked: ! self.Lock(check_version=0) try: from versions import Update Update(self, stored_state)

3 4

Does mailman-cvs remove reply-to?
by Marc MERLIN 11 Mar '02

11 Mar '02

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(a)merlins.org for PGP key

3 8

Feedback needed: nodupes patch and reply-to munging per user
by Marc MERLIN 11 Mar '02

11 Mar '02

[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(a)merlins.org for PGP key

3 2

New option for mailman-cvs: reply-to munging per user
by Marc MERLIN 11 Mar '02

11 Mar '02

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(a)merlins.org for PGP key

2 2

BounceRunner eating up alot of memory
by Fil 11 Mar '02

11 Mar '02

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

2 3

a problem in upgrading with moderated lists
by Fil 11 Mar '02

11 Mar '02

Hi, when you upgrade Mailman to 2.1a3 from 2.0, moderated lists correctly take on the attributes generic_nonmember_action = Hold default_member_moderation = Yes However the latter is valid only for NEW subscribers. Subscribers already registered have their moderation bit set to 0 (not moderated) whereas it should be set to 1 (moderated) to conform to the previous settings. And, by the way, these settings are not given through config_list -o -- Fil

2 1

Problem while upgrade to mailman 2.1 alpha
by Dan Ohnesorg 09 Mar '02

09 Mar '02

I am also triing to upgrade to never version and I have this troubles: Upgrading from version 0x20005f0 to 0x20100a4 getting rid of old source files fixing all the perms on your old html archives to work with b6 If your archives are big, this could take a minute or two... hotovo Updating mailing list: test - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me Fixing language templates: test Updating mailing list: kecy Traceback (most recent call last): File "./update", line 531, in ? errors = main() File "./update", line 413, in main errors = errors + dolist(listname) File "./update", line 183, in dolist mlist = MailList.MailList(listname, lock=0) File "../Mailman/MailList.py", line 101, in __init__ self.Load() File "../Mailman/MailList.py", line 543, in Load self.CheckVersion(dict) File "../Mailman/MailList.py", line 560, in CheckVersion self.Lock() File "../Mailman/MailList.py", line 154, in Lock self.Load() File "../Mailman/MailList.py", line 543, in Load self.CheckVersion(dict) File "../Mailman/MailList.py", line 563, in CheckVersion Update(self, stored_state) File "../Mailman/versions.py", line 53, in Update CanonicalizeUserOptions(l) File "../Mailman/versions.py", line 339, in CanonicalizeUserOptions if l.getMemberOption(k, mm_cfg.DisableDelivery): File "../Mailman/OldStyleMemberships.py", line 120, in getMemberOption self.__assertIsMember(member) File "../Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member Mailman.Errors.NotAMemberError: fickman(a)atlas.cz and it is alo true, that this user is listed only in section 'user_options': { '3zsmost(a)schoolnet.cz': 8, 'fickman(a)atlas.cz': 8, of dump_db. Sure, the database is corrupt, but it is not fatal, i think the upgrage should run OK. cheers dan -- ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan(a)feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Nezlob se na růži, že má trny; raduj se, že tak trnitý keř má růže. -- Arabské přísloví

2 1

Re: [Mailman-Developers] Missing footers with latest CVS
by Dan Mick 09 Mar '02

09 Mar '02

> >>>>> "Dan" == Dan Mick <dmick(a)utopia.west.sun.com> 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?

7 6