Mailman 3 November 2002 - Mailman-Developers

[ mailman-Bugs-635462 ] Admin pages HTML does not set TEXT color
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #635462, was opened at 2002-11-08 07:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635462&group_i… Category: Web/CGI >Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Marcin Orlowski (carl-os) Assigned to: Nobody/Anonymous (nobody) Summary: Admin pages HTML does not set TEXT color Initial Comment: Mailman admin pages believe that TEXT color is always black and does not set it to, hoping nobody changes the defaults. And this is false assumption ;-) For testing purposes my defaults are black bg color and yellow text. And since admin pages sets bg to white it now exposes yellow fonts on white background here. Kinda unreadable. Solution -> fix template/css/whatever to set up text color to black. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635462&group_i…

1 0

[ mailman-Patches-644810 ] Sendmail mailer in Python
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Patches item #644810, was opened at 2002-11-27 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=644810&group_i… Category: mail delivery Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Sendmail mailer in Python Initial Comment: This patch provide a Python implementation (with C wrapper) of a Sendmail mailer, if Sendmail is your MTA of choice, which removes the necessity of maintining an aliases database on your Mailman server. All subject to a bunch of conditions most prominent of which is that the server has to be pretty much dedicated to MM. This patch draws on an original contribution by David Champion <dgc(a)uchicago.edu> which is included in the contrib directory of the Mailman 2.1b distribution as mm-handler. See the README.SENDMAIL.mailer installed by this patch for differences between this and David's Perl original and more information of what you are getting into if you use this patch. Versions of the patch for MM 2.0.13 and MM 2.1b5 are available. This patch requires patch 644797 to be installed before it. In the MM build directory say: patch -p1 < patch-filename ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=644810&group_i…

1 0

[ mailman-Bugs-640374 ] 2.1b4 Mailman bug
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #640374, was opened at 2002-11-18 17:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=640374&group_i… Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1b4 Mailman bug Initial Comment: When I try to access some of my lists via the web interface to moderate them I receive this error message: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 87, in run_main main() File "/var/mailman/Mailman/Cgi/admindb.py", line 227, in main show_pending_unsubs(mlist, form) File "/var/mailman/Mailman/Cgi/admindb.py", line 332, in show_pending_unsubs fullname = Utils.uncanonstr(mlist.getMemberName (addr), lang) File "/var/mailman/Mailman/OldStyleMemberships.py", line 128, in getMemberName self.__assertIsMember(member) File "/var/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member NotAMemberError: capeterson28(a)hotmail.com This is only a problem for some of my lists. Some lists I can log into and moderate successfully from the Web. I am running Mailman 2.1b4 on RedHat Linux 7.3. Let me know if you need more information. Thanks for your help. Paul Marshall ---------------------------------------------------------------------- Comment By: Paul Marshall (paulmarshll) Date: 2002-11-19 14:27 Message: Logged In: YES user_id=582441 I recently upgraded to Mailman 2.1b5, however I still receive this error when I try to log into some of the lists. Thanks. Paul. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=640374&group_i…

1 0

[ mailman-Bugs-214205 ] e-mail<-> usenet gateway Reply-To header (PR#303)
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #214205, was opened at 2000-09-11 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214205&group_i… Category: nntp/news Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: e-mail<->usenet gateway Reply-To header (PR#303) Initial Comment: Jitterbug-Id: 303 Submitted-By: orion(a)tribble.dyndns.org Date: Mon, 24 Jul 2000 18:54:02 -0400 (EDT) Version: 2.0beta4 OS: Debian linux potato I'm running a plain e-mail<->usenet gateway. When someone replies to a usenet post through the list, his e-mail client sets an In-Reply-To: header instead of a Reply-To: header. This causes newsreaders to improperly thread messages. I inserted the following bit into Mailman/Handlers/ToUsenet.py at around line 82: # if the message is a reply to a previous post, change the header so # that newsreaders can thread it properly if msg.getheader('in-reply-to'): msg.headers.append('References: %s\n' % msg.getheader('in-reply-to')) del msg['in-reply-to'] I'm happy to say that this solved the problem. (before you laugh at me, take note that I never looked at python before.) ==================================================================== Audit trail: None ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:38 Message: Logged In: YES user_id=12800 Changing the group to 2.1 beta because I want to look at threading issues for gated messages before 2.1 final is released. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-01 08:34 Message: Logged In: YES user_id=531451 What a coincidence! I had the same problem and I looked into the code, then modified it to work properly. The coincidence is that my patch is *identical* to yours. So, for sure it works :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-27 17:00 Message: RFC 2076 says nothing about using In-Reply-To for news, so it might not be a bad idea to copy In-Reply-To to References when gating a message from mail to news. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-19 12:48 Message: This sounds like the email client in question is broken. Mine for example, correctly inserts References: headers and the news readers properly thread the messages. I'm not inclined to cater to broken email or news clients. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214205&group_i…

1 0

[ mailman-Bugs-640360 ] path relative URLs with /base vs /base/
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #640360, was opened at 2002-11-18 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=640360&group_i… Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: path relative URLs with /base vs /base/ Initial Comment: Our Apache server accepts path requests with or with a trailing slash, indifferently. (I understand there is no redirect.) This affects (cripples) relative paths, because http://host/mailman/private/name is the same page as http:// host/mailman/private/name/, but is different in reference to relative paths. The relative location of a month would be `href="name/2002-November/subject.html"' for the former, but `href="2002-November/subject.html"' for the latter. I suspect that the "private" URL is rarely entered by hand anyway, but FYI. /mailman/private/name/2002-November/ subject.html is OK, as far as I know. 2.1b4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=640360&group_i…

1 0

[ mailman-Bugs-451475 ] header munging ruins threading
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #451475, was opened at 2001-08-16 03:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=451475&group_i… Category: nntp/news Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: CrackMonkey (monkeymaster) Assigned to: Barry A. Warsaw (bwarsaw) Summary: header munging ruins threading Initial Comment: The header hacking done by ToUsenet.py ruins threading in mail! It takes a perfectly good message ID, and throws it away! news replies to a mail message appear to be replies to the parent (since the news messag references contain the references of the parent + some crazy mailman message ID). This is bogus. At the very least, could you add the real message ID somewhere so that newsreaders will include it in the references headers? Some of us actually use threaded mailers, you know! ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-12 12:16 Message: Logged In: YES user_id=12800 The problem is that many NNTP servers are really picky about message-id's; they won't allow duplicates, and they won't allow cross-postings with the same message-id. I suppose if the message had an id we could try to preserve it, attempt a post, and if that's rejected by the nntpd, we could try again with our own crafted message-id. I'm up for any suggestions that are rfc-compliant and work with the widest range of currently existing nntpds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=451475&group_i…

1 0

[ mailman-Bugs-219808 ] Missing dependancy for 'configure'.
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #219808, was opened at 2000-10-30 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=219808&group_i… Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Missing dependancy for 'configure'. Initial Comment: The Mailman makefile is missing a dependancy on 'configure', so when 'configure' is updated, it isn't re-run automatically, and you aren't warned to reconfigure. (definately low-priority bug though :) (I also ran into something weird when running 'config.status' to do the reconfiguring for me... it set 'MAILMAN_UID' in Defaults.py to 'mailman', without quotes, instead of the numeric uid. That might be caused by a mix of an old config.status and a new configure, though, as I wasn't able to reproduce it on another box.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=219808&group_i…

1 0

[ mailman-Bugs-621597 ] list creation ignores DEFAULT_EMAIL_HOST
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #621597, was opened at 2002-10-10 18:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621597&group_i… Category: None Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Greg Ward (gward) Assigned to: Nobody/Anonymous (nobody) Summary: list creation ignores DEFAULT_EMAIL_HOST Initial Comment: If I set DEFAULT_EMAIL_HOST in mm_cfg.py, its value is ignored when creating a new list. It's pretty easy to see why: MailList.InitVars uses DEFAULT_HOST_NAME. But the two are only equal as long as mm_cfg.py is not used. If DEFAULT_HOST_NAME and DEFAULT_EMAIL_HOST are really supposed to be the same, perhaps DEFAULT_HOST_NAME should not be set in Defaults.py -- rather, any code that looks at DEFAULT_EMAIL_HOST should check to see if DEFAULT_HOST_NAME happens to be defined in mm_cfg, and use it if so. Or something like that. I'm happy to supply a patch if someone agrees that this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621597&group_i…

1 0

[ mailman-Bugs-621689 ] Subscribe requests dropped from admin db
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #621689, was opened at 2002-10-10 23:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_i… Category: (un)subscribing Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe requests dropped from admin db Initial Comment: Occasionally, subscribe requests (via the web page) to a list that requires moderator approval for subscriptions never make it to the admin db for that list. They are listed in the subscribe log file, but never show up on the admin db page. Log file entries look like this: Oct 10 18:43:43 2002 (31168) eventmasters: pending XXXXXX.swfla.rr.com But the admin db page for the list shows no outstanding issues. I have verified that there was an actual subscription request behind this log entry. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-11-22 01:08 Message: Logged In: YES user_id=598228 Unfortunately, it's still occurring under 2.1b4. I'll check it under 2.1b5 as soon as the patches for htdig integration are released, as I need those to implement. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-22 10:11 Message: Logged In: YES user_id=12800 I'm going to defer this one until 2.1b4 goes out. I've fixed some related bugs in cvs, so hopefully this will be fixed in the new version. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-20 13:14 Message: Logged In: YES user_id=598228 Sorry - I'm running 2.1b3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 11:48 Message: Logged In: YES user_id=12800 What version of Mailman are you using. It's import to know the exact version, i.e. 2.1beta3, or if you're running from cvs. A lot of these problems have been fixed in cvs, which will soon be released as 2.1 beta 4. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-11 00:29 Message: Logged In: YES user_id=598228 I just verified, by cat'ing pending.pck, that the appropriate changes seem to be in there. But the web interface never picks them up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_i…

1 0

[ mailman-Bugs-612174 ] subscribe_policy + ALLOW_OPEN_SUBSCRIBE
by noreply＠sourceforge.net 27 Nov '02

27 Nov '02

Bugs item #612174, was opened at 2002-09-20 11:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=612174&group_i… Category: command line scripts Group: 2.1 beta Status: Open Resolution: None >Priority: 7 Submitted By: Jay Luker (lbjay) Assigned to: Nobody/Anonymous (nobody) Summary: subscribe_policy + ALLOW_OPEN_SUBSCRIBE Initial Comment: There is a flaw somewhere in the logic that alters the value of subscribe_policy based on the value of mm_cfg.ALLOW_OPEN_SUBSCRIBE. I have ALLOW_OPEN_SUBSCRIBE = 0. When I attempt to set subscribe_policy = 1 via the config_list script, subscribe_policy is always set to 2. ---------------------------------------------------------------------- Comment By: Jay Luker (lbjay) Date: 2002-09-20 12:02 Message: Logged In: YES user_id=51347 OK, I was just able to track this down further. The problem (I think) lies in Gui/Privacy.py. _setValue states: "For subscribe_policy when ALLOW_OPEN_SUBSCRIBE is true, we need to add one to the value because the page didn't present an open list as an option." ... but then the subsequent code actually adds one to the value if ALLOW_OPEN_SUBSCRIBE is untrue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=612174&group_i…

1 0