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…
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…
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…
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…
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…
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…
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…
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…
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…
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…