Bugs item #1567408, was opened at 2006-09-28 18:30
Message generated for change (Settings changed) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: bounce detection
>Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Bron Gondwana (brong)
Assigned to: Mark Sapiro (msapiro)
Summary: Admin address over quota causes bounce loop
Initial Comment:
X-Mailman-Version: 2.1.9.cp1
Hi,
I'm not the administrator of the Mailman instance,
just the poor sysadmin of a mail service who was
woken in the middle of the night by our MX servers
being severely overloaded by a mail loop.
One of our users hit their quota in Cyrus and hence
their mail was bouncing. This user is the admin for
a Mailman list, and the list has been configured to
forward all bounces to the admin.
The message was:
--===============2109117388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
As list administrator, your authorization is
requested for the
following mailing list posting:
List: *****
From: *****
Subject: *****
Reason: Message body is too big: 7519566 bytes
with a limit of 40 KB
At your convenience, visit:
http://...
to approve or deny the request.
And above that stacks of:
--===============0756822160==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
The attached message was received as a bounce, but
either the bounce
format was not recognized, or no member addresses
could be extracted
from it. This mailing list has been configured to
send all
unrecognized bounce messages to the list
administrator(s).
For more information see:
http://.../bounce
I will point the owners of the offending bug at this
thread so they can provide more specific information
if they wish, without giving their privacy away.
Bron.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-09-28 19:56
Message:
Logged In: YES
user_id=1123998
I am moving this to bugs as it is a bug report, not a patch.
Your list owners don't need to provide any additional
information. I understand exactly what's happening here.
(but see below)
There are two issues. The first is that we don't protect
against this loop and I think we should try to. I'll look
into fixing it, although I suspect it will not be easy as
anything I might put in the 'unrecognized bounce' message to
try to detect a loop can be munged or dropped by the MTA
that returns the next bounce.
The other part of the issue is that the MTA that is
returning the 'over quota' denial is not returning an RFC
3464 or RFC 1894 compliant DSN or any of the many other
formats that Mailman heuristically recognizes. If it were,
it would be recognized and not sent back to the list owner.
There is one thing you can provide and that is the actual
'delivery status' part of the unrecognized bounce. You can
alter addresses and domains if you wish for privacy, but if
I have the exact message including headers, I can add a
recognizer for it. What I need is the contents of the
message/rfc822 part that follows the "The attached message
was received" notice you quote above up to the first
"original message follows". I.e., just the DSN part and it's
headers, not any of the multiple preceeding messages/DSNs/etc.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…
Patches item #534298, was opened at 2002-03-25 00:18
Message generated for change (Comment added) made by mbp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: list administration
Group: Mailman 2.0.x
Status: Closed
Resolution: Out of Date
Priority: 1
Submitted By: Martin Pool (mbp)
Assigned to: Nobody/Anonymous (nobody)
Summary: forward unhandled bounces to admin
Initial Comment:
samba.org handles a lot of mail messages, and therefore
suffers a lot of bounced messages. Mailman's automatic
bounce handling is great, but the problem is that
people keep dreaming up new and wierd bounce messages.
With Mailman 2.0.8, if I turn on automatic bounce
handling then some bouncing addresses are not correctly
detected and therefore keep generating large amounts of
traffic indefinitely. If I turn it off, we get about
3000 bounces per day.
Some of these are just not handled yet by the
BouncerAPI and need patches. In some cases there is in
fact no deterministic way to work out the bouncing
address (at least until we have VERP), and human
intervention is required. For example, Novell's
brilliant mail software includes no information in the
Received lines or bounce message to indicate what the
bouncing address is!
Anyhow, this patch changes the behaviour of the bounce
handler so that bounce messages which do not cause any
positive action are forwarded to the list
administrator. "Positive action" can mean noticing
that the address is already disabled, or marking it as
bouncing, or similar things. It doesn't include
addresses which don't seem to be on the list, which
probably means that we have not interpreted the message
properly and more help is required.
So in summary bounces which can be automatically
handled will be, and others will go to the admin.
I'm not sure this is the perfect behaviour, but it
certainly seems like an improvement. Perhaps you want
to make it more configurable. Please merge this, or
something like it.
----------------------------------------------------------------------
>Comment By: Martin Pool (mbp)
Date: 2006-09-29 13:29
Message:
Logged In: YES
user_id=521
> Does this make you responsible for this behaviour?
Since my patch was closed/out-of-date, presumably not. At
any rate the behaviour is optional.
> (consider the case where the admin addres is bouncing)
Are you suggesting it will loop? I'm not sure whether admin
messages are subject to normal bounce processing, but I
think not. Anyhow, it will make it obvious that you need to
fix the admin address. :)
----------------------------------------------------------------------
Comment By: Bron Gondwana (brong)
Date: 2006-09-29 11:15
Message:
Logged In: YES
user_id=9941
Does this make you responsible for this behaviour? Next
time you're down in Melbourne remind me to buy you a beer
and tip it over you.
(consider the case where the admin addres is bouncing)
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:48
Message:
Logged In: YES
user_id=34209
As mentioned in email, I'll re-check the other
bounce-detection patches, but the ones I checked didn't
apply to 2.1 for other reasons as well (like their original
module being completely rewritten.)
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2003-03-12 11:43
Message:
Logged In: YES
user_id=521
> Yeah, Mailman 2.1's bounce detection and handling was
> largely rewritten. It also uses VERP now, so it should solve
> most of your bounce problems, if not all.
Yes, we're using VERP now and it's beautiful. In particular
we have a
lot of Exchange subscribers, and their bounce messages are
nearly
unintelligible.
> I'm going to close this patch, as well as your other pending
> bounce-detection patches, but if you see any new unhandled
bounces
> (or find that previously-reported ones still fail to
detect) please
> do open a new bug- or patch-report.
I am OK about closing this one, but please reopen the
others. Since
Mailman still has the option of using a bounce parser rather
than VERP
it seems to make sense to have the parser be as smart as
possible.
Some people might not want to use VERP. Unless the patches
no longer
merge, I would encourage you to put them in.
> (Preferably with an example message for us to test on.)
I will do that in future. I think that was not mentioned
when I sent
them, though I do think the patches have partial examples in
their
comments.
> I promise we wont let it rest as long as this one has. :-)
Thanks. I know it can be hard to get around to these things.
--
Martin
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:19
Message:
Logged In: YES
user_id=34209
Yeah, Mailman 2.1's bounce detection and handling was
largely rewritten. It also uses VERP now, so it should solve
most of your bounce problems, if not all. I'm going to close
this patch, as well as your other pending bounce-detection
patches, but if you see any new unhandled bounces (or find
that previously-reported ones still fail to detect) please
do open a new bug- or patch-report. (Preferably with an
example message for us to test on.) I promise we wont let it
rest as long as this one has. :-)
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2003-03-11 12:16
Message:
Logged In: YES
user_id=521
This seems to be already fixed in 2.1.
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2002-04-03 12:18
Message:
Logged In: YES
user_id=521
Tim, that's not quite so much of a problem as you might
think. When excessive bounces are detected Mailman only
*disables* addresses rather than removing them. With or
without this patch, bouncing addresses which are already
disabled are noted in the log file and not further action is
taken.
Problems can occur if the address is actually removed. This
can arise in two ways.
One way is that the mail administrator might explicitly
remove the user from the list because of manual bounce
processing. In that case, any later bounces will also go
through to the admin. That's the reason for my patch to add
--disable to remove_members.
Secondly, users might unsubscribe themselves and then have
their address start bouncing.
You can imagine Mailman remembering previously-subscribed
members so that it could handle these cases, but that's a
much bigger project, and probably best done in conjunction
with VERP.
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2002-03-25 12:03
Message:
Logged In: YES
user_id=521
This patch modifies the behaviour when handling bounce
messages with multiple addresses, such as from Postfix. Now
messages in which any of the bouncing addresses cannot be
automatically handled are forwarded to the administrator.
Eventually it might be nice to put a notice in the message
explaining the problem -- e.g. user not found, is not a
member, etc.
This update also makes "digester lucked out" be considered
successful processing.
----------------------------------------------------------------------
Comment By: Tim Potter (tpot)
Date: 2002-03-25 10:18
Message:
Logged In: YES
user_id=9949
The scenario where addresses which don't seem to be on the
list can be caused by bounces received after the user has
been disabled due to the size of the mail queue. It may
cause confusion forwarding them to the admin as there is
nothing they can do about it except puzzle over why it was
received.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…
Bugs item #1567408, was opened at 2006-09-28 18:30
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bron Gondwana (brong)
>Assigned to: Mark Sapiro (msapiro)
Summary: Admin address over quota causes bounce loop
Initial Comment:
X-Mailman-Version: 2.1.9.cp1
Hi,
I'm not the administrator of the Mailman instance,
just the poor sysadmin of a mail service who was
woken in the middle of the night by our MX servers
being severely overloaded by a mail loop.
One of our users hit their quota in Cyrus and hence
their mail was bouncing. This user is the admin for
a Mailman list, and the list has been configured to
forward all bounces to the admin.
The message was:
--===============2109117388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
As list administrator, your authorization is
requested for the
following mailing list posting:
List: *****
From: *****
Subject: *****
Reason: Message body is too big: 7519566 bytes
with a limit of 40 KB
At your convenience, visit:
http://...
to approve or deny the request.
And above that stacks of:
--===============0756822160==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
The attached message was received as a bounce, but
either the bounce
format was not recognized, or no member addresses
could be extracted
from it. This mailing list has been configured to
send all
unrecognized bounce messages to the list
administrator(s).
For more information see:
http://.../bounce
I will point the owners of the offending bug at this
thread so they can provide more specific information
if they wish, without giving their privacy away.
Bron.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-09-28 19:56
Message:
Logged In: YES
user_id=1123998
I am moving this to bugs as it is a bug report, not a patch.
Your list owners don't need to provide any additional
information. I understand exactly what's happening here.
(but see below)
There are two issues. The first is that we don't protect
against this loop and I think we should try to. I'll look
into fixing it, although I suspect it will not be easy as
anything I might put in the 'unrecognized bounce' message to
try to detect a loop can be munged or dropped by the MTA
that returns the next bounce.
The other part of the issue is that the MTA that is
returning the 'over quota' denial is not returning an RFC
3464 or RFC 1894 compliant DSN or any of the many other
formats that Mailman heuristically recognizes. If it were,
it would be recognized and not sent back to the list owner.
There is one thing you can provide and that is the actual
'delivery status' part of the unrecognized bounce. You can
alter addresses and domains if you wish for privacy, but if
I have the exact message including headers, I can add a
recognizer for it. What I need is the contents of the
message/rfc822 part that follows the "The attached message
was received" notice you quote above up to the first
"original message follows". I.e., just the DSN part and it's
headers, not any of the multiple preceeding messages/DSNs/etc.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…
Patches item #1567408, was opened at 2006-09-29 11:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1567408&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: bounce processing
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bron Gondwana (brong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin address over quota causes bounce loop
Initial Comment:
X-Mailman-Version: 2.1.9.cp1
Hi,
I'm not the administrator of the Mailman instance,
just the poor sysadmin of a mail service who was
woken in the middle of the night by our MX servers
being severely overloaded by a mail loop.
One of our users hit their quota in Cyrus and hence
their mail was bouncing. This user is the admin for
a Mailman list, and the list has been configured to
forward all bounces to the admin.
The message was:
--===============2109117388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
As list administrator, your authorization is
requested for the
following mailing list posting:
List: *****
From: *****
Subject: *****
Reason: Message body is too big: 7519566 bytes
with a limit of 40 KB
At your convenience, visit:
http://...
to approve or deny the request.
And above that stacks of:
--===============0756822160==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
The attached message was received as a bounce, but
either the bounce
format was not recognized, or no member addresses
could be extracted
from it. This mailing list has been configured to
send all
unrecognized bounce messages to the list
administrator(s).
For more information see:
http://.../bounce
I will point the owners of the offending bug at this
thread so they can provide more specific information
if they wish, without giving their privacy away.
Bron.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1567408&group_…
Patches item #534298, was opened at 2002-03-25 00:18
Message generated for change (Comment added) made by brong
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: list administration
Group: Mailman 2.0.x
Status: Closed
Resolution: Out of Date
Priority: 1
Submitted By: Martin Pool (mbp)
Assigned to: Nobody/Anonymous (nobody)
Summary: forward unhandled bounces to admin
Initial Comment:
samba.org handles a lot of mail messages, and therefore
suffers a lot of bounced messages. Mailman's automatic
bounce handling is great, but the problem is that
people keep dreaming up new and wierd bounce messages.
With Mailman 2.0.8, if I turn on automatic bounce
handling then some bouncing addresses are not correctly
detected and therefore keep generating large amounts of
traffic indefinitely. If I turn it off, we get about
3000 bounces per day.
Some of these are just not handled yet by the
BouncerAPI and need patches. In some cases there is in
fact no deterministic way to work out the bouncing
address (at least until we have VERP), and human
intervention is required. For example, Novell's
brilliant mail software includes no information in the
Received lines or bounce message to indicate what the
bouncing address is!
Anyhow, this patch changes the behaviour of the bounce
handler so that bounce messages which do not cause any
positive action are forwarded to the list
administrator. "Positive action" can mean noticing
that the address is already disabled, or marking it as
bouncing, or similar things. It doesn't include
addresses which don't seem to be on the list, which
probably means that we have not interpreted the message
properly and more help is required.
So in summary bounces which can be automatically
handled will be, and others will go to the admin.
I'm not sure this is the perfect behaviour, but it
certainly seems like an improvement. Perhaps you want
to make it more configurable. Please merge this, or
something like it.
----------------------------------------------------------------------
Comment By: Bron Gondwana (brong)
Date: 2006-09-29 11:15
Message:
Logged In: YES
user_id=9941
Does this make you responsible for this behaviour? Next
time you're down in Melbourne remind me to buy you a beer
and tip it over you.
(consider the case where the admin addres is bouncing)
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:48
Message:
Logged In: YES
user_id=34209
As mentioned in email, I'll re-check the other
bounce-detection patches, but the ones I checked didn't
apply to 2.1 for other reasons as well (like their original
module being completely rewritten.)
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2003-03-12 11:43
Message:
Logged In: YES
user_id=521
> Yeah, Mailman 2.1's bounce detection and handling was
> largely rewritten. It also uses VERP now, so it should solve
> most of your bounce problems, if not all.
Yes, we're using VERP now and it's beautiful. In particular
we have a
lot of Exchange subscribers, and their bounce messages are
nearly
unintelligible.
> I'm going to close this patch, as well as your other pending
> bounce-detection patches, but if you see any new unhandled
bounces
> (or find that previously-reported ones still fail to
detect) please
> do open a new bug- or patch-report.
I am OK about closing this one, but please reopen the
others. Since
Mailman still has the option of using a bounce parser rather
than VERP
it seems to make sense to have the parser be as smart as
possible.
Some people might not want to use VERP. Unless the patches
no longer
merge, I would encourage you to put them in.
> (Preferably with an example message for us to test on.)
I will do that in future. I think that was not mentioned
when I sent
them, though I do think the patches have partial examples in
their
comments.
> I promise we wont let it rest as long as this one has. :-)
Thanks. I know it can be hard to get around to these things.
--
Martin
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:19
Message:
Logged In: YES
user_id=34209
Yeah, Mailman 2.1's bounce detection and handling was
largely rewritten. It also uses VERP now, so it should solve
most of your bounce problems, if not all. I'm going to close
this patch, as well as your other pending bounce-detection
patches, but if you see any new unhandled bounces (or find
that previously-reported ones still fail to detect) please
do open a new bug- or patch-report. (Preferably with an
example message for us to test on.) I promise we wont let it
rest as long as this one has. :-)
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2003-03-11 12:16
Message:
Logged In: YES
user_id=521
This seems to be already fixed in 2.1.
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2002-04-03 12:18
Message:
Logged In: YES
user_id=521
Tim, that's not quite so much of a problem as you might
think. When excessive bounces are detected Mailman only
*disables* addresses rather than removing them. With or
without this patch, bouncing addresses which are already
disabled are noted in the log file and not further action is
taken.
Problems can occur if the address is actually removed. This
can arise in two ways.
One way is that the mail administrator might explicitly
remove the user from the list because of manual bounce
processing. In that case, any later bounces will also go
through to the admin. That's the reason for my patch to add
--disable to remove_members.
Secondly, users might unsubscribe themselves and then have
their address start bouncing.
You can imagine Mailman remembering previously-subscribed
members so that it could handle these cases, but that's a
much bigger project, and probably best done in conjunction
with VERP.
----------------------------------------------------------------------
Comment By: Martin Pool (mbp)
Date: 2002-03-25 12:03
Message:
Logged In: YES
user_id=521
This patch modifies the behaviour when handling bounce
messages with multiple addresses, such as from Postfix. Now
messages in which any of the bouncing addresses cannot be
automatically handled are forwarded to the administrator.
Eventually it might be nice to put a notice in the message
explaining the problem -- e.g. user not found, is not a
member, etc.
This update also makes "digester lucked out" be considered
successful processing.
----------------------------------------------------------------------
Comment By: Tim Potter (tpot)
Date: 2002-03-25 10:18
Message:
Logged In: YES
user_id=9949
The scenario where addresses which don't seem to be on the
list can be caused by bounces received after the user has
been disabled due to the size of the mail queue. It may
cause confusion forwarding them to the admin as there is
nothing they can do about it except puzzle over why it was
received.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…
Bugs item #1565707, was opened at 2006-09-26 14:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1565707&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hypnos Software (alexcomps)
Assigned to: Nobody/Anonymous (nobody)
Summary: Newlist and groups
Initial Comment:
In function main:
if os.getgid() != mm_cfg.MAILMAN_GROUP:
os.setgid(gid)
it is comparing a string and a number, so it always run
os.setgid(gid)
Also I think that it would be better if it checks if
you belong to the group, because maybe it is not your
primary group but it is one of you secondary ones.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1565707&group_…
Patches item #1564527, was opened at 2006-09-24 15:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1564527&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configure/install
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thijs Kinkhorst (kink)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to separate Makefile arch-dep and arch-indep install
Initial Comment:
Hello!
When packaging Mailman for Debian, we create different
packages for architecture-specific files and
architecture-independent ones. For this we need to
separate those install steps.
Attached patch adds that possibility to the Mailman
makefile; it adds two new targets "do-arch-install" and
"do-indep-install"; the old "doinstall" remains and
calls both new targets.
I think this might be useful to others who wish to
separate arch-dep and arch-indep files and it doesn't
hurt other users. That's why I request this patch to be
included into Mailman.
regards,
Thijs Kinkhorst
Debian Developer
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1564527&group_…
Bugs item #1562922, was opened at 2006-09-21 08:05
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Web/CGI
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan Astoorian (djast)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Discard all...Defer" button appears on mod. detail page
Initial Comment:
This is a clarification and restatement of bug
#1000699, which was marked "closed" but describes a bug
which is still present.
On the admindb pages, there is a checkbox labelled
"Discard all messages marked Defer" near each of the
submit buttons at the top and bottom of the page. This
checkbox appears on the default admindb page (where the
requests are grouped by sender), and also on the
"?details=all" page (which is reached by following the
"You can also view the details of all held postings" link).
The checkboxes have no effect on the "?details=all"
page (because the form is structured differently from
the default admindb page).
The comments in Bug #1000699 says that "the 'discard
all deferred' checkbox was intended to work only on the
summary page. It's appearance on the detail pages was a
mistake that was fixed in 2.1.6"; from this I assume
that the checkboxes are not supposed to appear on the
"?details=all" page, but they're still there.
The test in Cgi/admindb.py for whether to supply the
button is "if not (sender or msgid):"; perhaps the test
should be changed to something like "if not (details or
sender or msgid):".
(I mentioned this in a comment I attached to closed bug
#1000699, but there's been no further discussion, and
the bug is still present as of 2.1.9.)
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-09-21 11:28
Message:
Logged In: YES
user_id=1123998
Your comment on bug # 1000699 slipped through the cracks.
I'm sorry.
This has now been fixed as you suggest in subversion on both
the trunk and the Release_2_1-maint branch.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…
Bugs item #1562922, was opened at 2006-09-21 11:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Web/CGI
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Astoorian (djast)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Discard all...Defer" button appears on mod. detail page
Initial Comment:
This is a clarification and restatement of bug
#1000699, which was marked "closed" but describes a bug
which is still present.
On the admindb pages, there is a checkbox labelled
"Discard all messages marked Defer" near each of the
submit buttons at the top and bottom of the page. This
checkbox appears on the default admindb page (where the
requests are grouped by sender), and also on the
"?details=all" page (which is reached by following the
"You can also view the details of all held postings" link).
The checkboxes have no effect on the "?details=all"
page (because the form is structured differently from
the default admindb page).
The comments in Bug #1000699 says that "the 'discard
all deferred' checkbox was intended to work only on the
summary page. It's appearance on the detail pages was a
mistake that was fixed in 2.1.6"; from this I assume
that the checkboxes are not supposed to appear on the
"?details=all" page, but they're still there.
The test in Cgi/admindb.py for whether to supply the
button is "if not (sender or msgid):"; perhaps the test
should be changed to something like "if not (details or
sender or msgid):".
(I mentioned this in a comment I attached to closed bug
#1000699, but there's been no further discussion, and
the bug is still present as of 2.1.9.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…
Bugs item #1562369, was opened at 2006-09-20 13:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562369&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Web/CGI
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Robbins (smr99)
Assigned to: Nobody/Anonymous (nobody)
Summary: error if reading web archive while changing address
Initial Comment:
I triggered a bug in the mailing list software, Mailman.
I was reading the insight-developers mailing list
archives
(http://www.itk.org/mailman/listinfo/insight-developers)
via the web, logged in with my old email address,
steven.robbins(a)videotron.ca. While I was doing that, I
updated my email to this one,
smr(a)sumost.ca. After responding positively to the
confirmatory email, I went back to
reading the archives in the *same* browser session,
resulting in an error page (below).
Once I cleared my cookie cache, all is well again.
Cheers,
-Steve
Bug in Mailman version 2.1.4
We\'re sorry, we hit a bug!
If you would like to help us identify the problem,
please email a copy of this page to
the webmaster for this site with a description of what
happened. Thanks!
Traceback:
Traceback (most recent call last):
File \"/var/lib/mailman/scripts/driver\", line 96, in
run_main
main()
File \"/usr/lib/mailman/Mailman/Cgi/private.py\", line
120, in main
password, username):
File \"/var/lib/mailman/Mailman/SecurityManager.py\",
line 220, in WebAuthenticate
ok = self.CheckCookie(ac, user)
File \"/var/lib/mailman/Mailman/SecurityManager.py\",
line 300, in CheckCookie
ok = self.__checkone(c, authcontext, user)
File \"/var/lib/mailman/Mailman/SecurityManager.py\",
line 310, in __checkone
key, secret = self.AuthContextInfo(authcontext, user)
File \"/var/lib/mailman/Mailman/SecurityManager.py\",
line 105, in AuthContextInfo
secret = self.getMemberPassword(user)
File
\"/var/lib/mailman/Mailman/OldStyleMemberships.py\",
line 102, in getMemberPassword
raise Errors.NotAMemberError, member
NotAMemberError: steven.robbins(a)videotron.ca
Python information:
Variable Value
sys.version 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4
(Debian 1:3.3.4-2)]
sys.executable /usr/bin/python
sys.prefix /usr
sys.exec_prefix /usr
sys.path /usr
sys.platform linux2
Environment variables:
Variable Value
HTTP_REFERER
http://www.itk.org/mailman/listinfo/insight-developers
SERVER_SOFTWARE Apache/1.3.33 (Debian GNU/Linux)
mod_gzip/1.3.26.1a mod_ssl/2.8.22
OpenSSL/0.9.7e PHP/4.3.10-16 mod_perl/1.29 mod_layout/3.2.1
SCRIPT_NAME /mailman/private
SERVER_SIGNATURE
Apache/1.3.33 Server at www.itk.org Port 80
REQUEST_METHOD GET
HTTP_KEEP_ALIVE 300
SERVER_PROTOCOL HTTP/1.1
QUERY_STRING
HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8.0.7)
Gecko/20060909 Firefox/1.5.0.7
HTTP_CONNECTION keep-alive
HTTP_COOKIE
insight-developers+user+steven.robbins--at--videotron.ca=280200000069931a0f45732800000037363963626234366538656630316532326531613230346364326334323062353966373332383935
SERVER_NAME www.itk.org
REMOTE_ADDR 64.4.70.10
PATH_TRANSLATED
/projects/Insight/WWW/InsightDocuments/Web/insight-developers/
SERVER_PORT 80
SERVER_ADDR 192.168.115.100
DOCUMENT_ROOT /projects/Insight/WWW/InsightDocuments/Web
PYTHONPATH /var/lib/mailman
SCRIPT_FILENAME /usr/lib/cgi-bin/mailman/private
SERVER_ADMIN webmaster(a)public.kitware.com
HTTP_HOST www.itk.org
REQUEST_URI /mailman/private/insight-developers/
HTTP_ACCEPT
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
GATEWAY_INTERFACE CGI/1.1
REMOTE_PORT 16695
HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5
HTTP_ACCEPT_ENCODING gzip,deflate
PATH_INFO /insight-developers/
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562369&group_…