Mailman 3 June 2002 - Mailman-Developers

[ mailman-Patches-573509 ] ToUsenet: subject prefix stripping
by noreply＠sourceforge.net 25 Jun '02

25 Jun '02

Patches item #573509, was opened at 2002-06-25 07:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_i…

1 0

[ mailman-Patches-573508 ] ToUsenet: subject prefix stripping
by noreply＠sourceforge.net 25 Jun '02

25 Jun '02

Patches item #573508, was opened at 2002-06-25 07:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_i…

1 0

[ mailman-Patches-573505 ] usenet threading improvements
by noreply＠sourceforge.net 25 Jun '02

25 Jun '02

Patches item #573505, was opened at 2002-06-25 06:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573505&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: usenet threading improvements Initial Comment: Basically message-id munging for all messages. Might be better as an option? This helps with threading in usenet gating, as what happens is this: someone sends a mail with message- id foo(a)bar.com gating replaces the message-id with mailman.123.456.list(a)list.com list member replies via mail, "in-reply-to" header is set to the foo(a)bar.com now when the message is gated it can't thread because in-reply-to: (which is translated into references:) is wrong. Solution is to munge all message-ids. Doesn't really do any harm AFAICT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573505&group_i…

1 0

[ mailman-Patches-573503 ] message-id munge error in ToUsenet.py
by noreply＠sourceforge.net 25 Jun '02

25 Jun '02

Patches item #573503, was opened at 2002-06-25 06:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573503&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: message-id munge error in ToUsenet.py Initial Comment: # Our Message-ID format is <mailman.secs.pid.listname@hostname> msgid = msg.get('message-id') hackmsgid = 1 if msgid: mo = re.search( msgid, r'<mailman.\d+.\d+.(?P<listname>[^@]+)@(?P<hostname>[^>]+)>') in the re.search, the parameters are the wrong way around. The consequence is that a new message-id is assigned to each message and threading is easily broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573503&group_i…

1 0

Bug in the latest 2.1 CVS
by Bob Puff＠NLE 25 Jun '02

25 Jun '02

Here's something I just got when installing a brand new 2.1b fresh from CVS tonight: Jun 25 01:17:51 2002 (21415) Uncaught runner exception: isinstance() arg 2 must be a class or type Jun 25 01:17:51 2002 (21415) Traceback (most recent call last): File "/home/mm21/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mm21/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mm21/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispo se status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mm21/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopip eline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mm21/mailman/Mailman/Handlers/Hold.py", line 141, in process if mlist.administrivia and Utils.is_administrivia(msg): File "/home/mm21/mailman/Mailman/Utils.py", line 492, in is_administrivia for line in email.Iterators.body_line_iterator(msg): File "/home/mm21/mailman/pythonlib/email/_compat22.py", line 41, in body_line_ iterator if isinstance(payload, StringTypes): TypeError: isinstance() arg 2 must be a class or type This happened when I sent the first message to the first list. BOb

1 0

[ mailman-Feature Requests-573394 ] separate auto-disable and "nomail" flags
by noreply＠sourceforge.net 24 Jun '02

24 Jun '02

Feature Requests item #573394, was opened at 2002-06-24 16:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Stein (gstein) Assigned to: Nobody/Anonymous (nobody) >Summary: separate auto-disable and "nomail" flags Initial Comment: Currently, Mailman will disable email to accounts (say, because they bounced too many times) by setting the "nomail" option. *However*, that option is also used by users. As a result, I have no way to determine which subscriptions are old/invalid, and which correspond to actual users. It would be nice to record disabling as a separate field... say, as the date the account was disabled. Then, I could periodically find all accounts which were disabled more than a year ago and simply delete them. Thus, users who temporarily disable mail delivery will not accidentally have their subscriptions purged :-) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-24 18:50 Message: Logged In: YES user_id=6501 Yes, that is a definite improvement. Note that logs get rotated, so you might not know "when" a particular transition occurred. For my particular problem, I'd be happy with the current 2.1 behavior, and would be even happier with the change date added, too. thx! ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-06-24 16:52 Message: Logged In: YES user_id=10725 MM 2.1 adds a "reason" enumeration to the disabled flag, so at least the 'bounce' vs. 'user' or 'administrator' distinction is obvious. The date of the event is also available in the log files. Not that that's as useful as what you suggest, but it's partway there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i…

1 0

[ mailman-Feature Requests-573394 ] separate auto-disable and "nomail" flags
by noreply＠sourceforge.net 24 Jun '02

24 Jun '02

Feature Requests item #573394, was opened at 2002-06-24 23:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Stein (gstein) Assigned to: Nobody/Anonymous (nobody) Summary: separate auto-disable and "nomail" flags Initial Comment: Currently, Mailman will disable email to accounts (say, because they bounced too many times) by setting the "nomail" option. *However*, that option is also used by users. As a result, I have no way to determine which subscriptions are old/invalid, and which correspond to actual users. It would be nice to record disabling as a separate field... say, as the date the account was disabled. Then, I could periodically find all accounts which were disabled more than a year ago and simply delete them. Thus, users who temporarily disable mail delivery will not accidentally have their subscriptions purged :-) ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-06-24 23:52 Message: Logged In: YES user_id=10725 MM 2.1 adds a "reason" enumeration to the disabled flag, so at least the 'bounce' vs. 'user' or 'administrator' distinction is obvious. The date of the event is also available in the log files. Not that that's as useful as what you suggest, but it's partway there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i…

1 0

[ mailman-Feature Requests-573394 ] separate auto-disable and "nomail" flags
by noreply＠sourceforge.net 24 Jun '02

24 Jun '02

Feature Requests item #573394, was opened at 2002-06-24 16:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Stein (gstein) Assigned to: Nobody/Anonymous (nobody) Summary: separate auto-disable and "nomail" flags Initial Comment: Currently, Mailman will disable email to accounts (say, because they bounced too many times) by setting the "nomail" option. *However*, that option is also used by users. As a result, I have no way to determine which subscriptions are old/invalid, and which correspond to actual users. It would be nice to record disabling as a separate field... say, as the date the account was disabled. Then, I could periodically find all accounts which were disabled more than a year ago and simply delete them. Thus, users who temporarily disable mail delivery will not accidentally have their subscriptions purged :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i…

1 0

Re: [Mailman-Users] Python problems, mm 2.1b2, rh71
by Dominic Hargreaves 24 Jun '02

24 Jun '02

[posted to mailman-developers separately because I'm subscribed with a different address] On Mon, Jun 24, 2002 at 01:55:57AM +0100, Dominic Hargreaves wrote: > Hi, > > I'm having some problems upgrading from mailman 2.0.11 to 2.1b2. > > The setup is redhat 7.1 with the python2 package (python2-2.0-3) installed > from powertools. Someone has pointed out to me by private mail that I need python 2.1 [0] to run mailman 2.1, so it was a mistake on my part not to have read the requirements carefully enough. However, it's worth pointing out that the configure script complained when I tried to run it with python 1.5.2, but not when I ran it with 2.0. Should this be fixed? Cheers, Dom. [0] I said 2.2 in the mail to mailman-users. Need more coffee.

1 0

[ mailman-Bugs-573071 ] nonmembers can post after upgrading
by noreply＠sourceforge.net 24 Jun '02

24 Jun '02

Bugs item #573071, was opened at 2002-06-24 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id… Category: security/privacy Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: nonmembers can post after upgrading Initial Comment: After upgrading to current CVS (2.1b2+), nonmembers are now allowed to post to a list that used to be members-only (in MM 2.0.11). The member_posting_only config variable is not propagated to the generic_nonmember_action variable when upgrading. This caused me a lot of trouble... :) The fix is probably trivial, but my lack of python experience prevents me from submitting a patch... ;) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id…

1 0