Patches item #1520343, was opened at 2006-07-11 13:34
Message generated for change (Settings changed) made by ikedasoji
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&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 UI
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
Priority: 7
Submitted By: ikedasoji (ikedasoji)
>Assigned to: Tokio Kikuchi (tkikuchi)
>Summary: FIX: Inputs are imcompletely escaped & saved (2.1 & 2.2)
Initial Comment:
Inputs on admin pages are imcompletely escaped, then
the escaped values are saved (excpet 'info' property).
This expedient solution have caused following problems:
o Input including `"' breaks HTML formatting.
o `<' is not allowed in admin/user option value (it is
replaced with '<' in many contexts).
o 'info' in admin page might break HTML formatting with
some sort of tags (e.g. '</textarea>').
This patch solve these problems. Always unescaped
value is saved (except '<script>' in 'info') and
escaped only when it is displayed as HTML.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…
Patches item #1520343, was opened at 2006-07-11 13:34
Message generated for change (Settings changed) made by ikedasoji
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&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 UI
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
>Priority: 7
Submitted By: ikedasoji (ikedasoji)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inputs are imcompletely escaped & saved (2.1 & 2.2)
Initial Comment:
Inputs on admin pages are imcompletely escaped, then
the escaped values are saved (excpet 'info' property).
This expedient solution have caused following problems:
o Input including `"' breaks HTML formatting.
o `<' is not allowed in admin/user option value (it is
replaced with '<' in many contexts).
o 'info' in admin page might break HTML formatting with
some sort of tags (e.g. '</textarea>').
This patch solve these problems. Always unescaped
value is saved (except '<script>' in 'info') and
escaped only when it is displayed as HTML.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…
Patches item #1520343, was opened at 2006-07-11 13:34
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=1520343&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 UI
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
Priority: 5
Submitted By: ikedasoji (ikedasoji)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inputs are imcompletely escaped & saved (2.1 & 2.2)
Initial Comment:
Inputs on admin pages are imcompletely escaped, then
the escaped values are saved (excpet 'info' property).
This expedient solution have caused following problems:
o Input including `"' breaks HTML formatting.
o `<' is not allowed in admin/user option value (it is
replaced with '<' in many contexts).
o 'info' in admin page might break HTML formatting with
some sort of tags (e.g. '</textarea>').
This patch solve these problems. Always unescaped
value is saved (except '<script>' in 'info') and
escaped only when it is displayed as HTML.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…
Bugs item #1519881, was opened at 2006-07-10 10: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=1519881&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: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Barrett (ppsys)
Assigned to: Nobody/Anonymous (nobody)
Summary: lost messages risk with contrib/mm-handler
Initial Comment:
As far as I am aware, this bug is present in all versions of the
contributed sendmail mailer contrib/mm-handler
The Perl code in subversion /trunk/mailman/contrib/mm-handler
contains the following fragment:
$wrapper = new FileHandle "|$MMWRAPPER $cmd $list";
if (!defined($wrapper)) {
## Defer?
print STDERR "$0: cannot exec ",
"\"$MMWRAPPER $cmd $list\": deferring\n";
exit (-1);
}
# Don't need these without the "n" flag on the mailer def....
#$date = &mboxdate(time);
#$wrapper->print ("From $sender $date\n");
# ...because we use these instead.
$from_ = <STDIN>;
$wrapper->print ($from_);
$wrapper->print ("X-Mailman-Handler: $VERSION\n");
while (<STDIN>) {
$wrapper->print ($_);
}
close($wrapper);
This is the code that actually hands off the message from sendmail to
the mailman wrapper.
I note that it still has the problem which the original author, David
Champion <dgc(a)uchicago.edu>, was made aware some years ago.
The Perl code fails to check the value returned by the close($wrapper).
As the FileHandle being closed is a pipe, the close operation returns
the status value returned by the Mailman wrapper at the far end of the
pipe. This value should be checked.
Not checking this status value means that if the mailman wrapper fails
to successfully enqueue the message for any reason this is not
detected by the sendmail mailer. Meanwhile, the mailer blithely tells
sendmail that the message was successfully delivered.
The likely consequence is that the message will be silently lost.
Adding a test after:
close($wrapper);
such as:
close($wrapper);
die "Mailman delivery wrapper failed" if $?;
nods in the direction of correcting the problem.
I leave aside suggestions that more appropriate, mail related, return
code values might sensibly be used by this sendmail mailer, amongst
other things.
btw: this risk is not theoretical. Some years ago it caused the only loss
of messages by our Mailman system that we have experienced. We
initially fixed, then replaced with a python implementation and finally
ceased all use of this type of sendmail mailer.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1519881&group_…
Feature Requests item #1469343, was opened at 2006-04-12 15:16
Message generated for change (Comment added) made by cras
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&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: Timo Sirainen (cras)
Assigned to: Nobody/Anonymous (nobody)
Summary: Per-user Reply-To mungling for sent mails
Initial Comment:
This feature request isn't the same as the existing
ones about per-user reply-to mungling (eg. 788314).
I like the ability for users to be able to select if
they want to get both private and list replies (highly
useful in big traffic lists) or only list replies (if
you're going to read all the mails in the list anyway).
Now this is already possible assuming that everyone
hits Reply-to-all, which I think is what most people
do. However for those who want only the list replies,
they need to set "Reply-To: list" header for their own
mails. This is impossible or difficult to configure to
be automatic in most email clients.
So, a user-specific option to specify if the Reply-To
header should be added to mails the user himself sends
would be nice.
----------------------------------------------------------------------
>Comment By: Timo Sirainen (cras)
Date: 2006-07-10 01:11
Message:
Logged In: YES
user_id=11334
Yes, "Avoid duplicate copies" could do the same, except I find that whole
feature a really bad idea to use. I guess it works by Mailman not sending the
message to the user if he's already in To/Cc headers? If this is done then
those messages won't have the List-ID header and filtering must be done in
less reliable ways. Also it could lose the mail completely if the direct reply
wasn't received (eg. more strict SMTP server checks or even intentionally
faked), making you the only one in the list not seeing the mail.
And sure, sender's MUA could in theory also add the header, except there are
only a couple MUAs which allow doing it automatically. I probably wouldn't
have bothered with the patch for this if Evolution had allowed me to do it. :)
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-07-10 00:27
Message:
Logged In: YES
user_id=1123998
Apparently, as you say, this is not the same as RFEs 788314
and 828564. Those ask that a member be able to specify
whether or not to receive posts from the list with a
Reply-To: the list added.
This RFE (and the associated patch 1515716) asks that a
posting member be able to instruct the list to put a
Reply-To: the list in her posts delivered to the list members.
I really don't see the need for this. If a member selects
the "Avoid duplicate copies", he will only receive one copy
of a "reply all" whether or not he is explicitly addressed
in the reply.
Further, the poster can simply add a Reply-To: the list to
her post if desired (and if her MUA allows this conveniently).
Finally, the appropriate reply address is dynamic. For some
posts one may want replies to the list and for others one
may want replies off list, and it is as much the choice of
the responder as the original poster which is appropriate in
any particular case.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_…
Patches item #1515716, was opened at 2006-07-01 19:29
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1515716&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: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Timo Sirainen (cras)
Assigned to: Nobody/Anonymous (nobody)
Summary: Per-user selectable Reply-to header
Initial Comment:
Feature request 1469343 explains this.
Having the field remembered in listinfo page causes
most of the changes and I think it's missing some
backwards compatibility checks for the pending requests
in database. I'd be happy to have it just in the
options page too.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-09 17:28
Message:
Logged In: YES
user_id=1123998
See my comment to RFE 1469343 -
https://sourceforge.net/tracker/index.php?func=detail&aid=1469343&group_id=…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1515716&group_…
Feature Requests item #1469343, was opened at 2006-04-12 08:16
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&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: Timo Sirainen (cras)
Assigned to: Nobody/Anonymous (nobody)
Summary: Per-user Reply-To mungling for sent mails
Initial Comment:
This feature request isn't the same as the existing
ones about per-user reply-to mungling (eg. 788314).
I like the ability for users to be able to select if
they want to get both private and list replies (highly
useful in big traffic lists) or only list replies (if
you're going to read all the mails in the list anyway).
Now this is already possible assuming that everyone
hits Reply-to-all, which I think is what most people
do. However for those who want only the list replies,
they need to set "Reply-To: list" header for their own
mails. This is impossible or difficult to configure to
be automatic in most email clients.
So, a user-specific option to specify if the Reply-To
header should be added to mails the user himself sends
would be nice.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-09 17:27
Message:
Logged In: YES
user_id=1123998
Apparently, as you say, this is not the same as RFEs 788314
and 828564. Those ask that a member be able to specify
whether or not to receive posts from the list with a
Reply-To: the list added.
This RFE (and the associated patch 1515716) asks that a
posting member be able to instruct the list to put a
Reply-To: the list in her posts delivered to the list members.
I really don't see the need for this. If a member selects
the "Avoid duplicate copies", he will only receive one copy
of a "reply all" whether or not he is explicitly addressed
in the reply.
Further, the poster can simply add a Reply-To: the list to
her post if desired (and if her MUA allows this conveniently).
Finally, the appropriate reply address is dynamic. For some
posts one may want replies to the list and for others one
may want replies off list, and it is as much the choice of
the responder as the original poster which is appropriate in
any particular case.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_…
Bugs item #1518281, was opened at 2006-07-06 10:27
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&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: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Crotwell (crotwell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad Content-Disposition breaks senddigest
Initial Comment:
We are using the default mailman on mac osx server 10.3
which is mailman 2.1.2, so this may be old. But just in
case, we got an email with attachement that caused
mailman to croak in senddigest. Here is the output of
running it by hand. I added 2 prints to see what the
offending filename variable had in it. The
Content-Disposition headers are below. Note that the
two parts of the filename have been joined, but because
of the bizarre endquoting in filename*0, there is an
embedded \n\t.
We fixed this locally by editing the mbox to change the
offending filename to be shorter and not split into two
parts, but it might be nice if mailman would check for
illegal characters embedded in filenames?
In addition to senddigest croaking, all emails after
this bad one were not added to the archive. Luckily we
had made a copy of digest.mbox before running
senddigest manually and were able to manually add the
lost emails to the archive mbox.
roo:/usr/share/mailman root# python -S cron/senddigests
-l chair-archive
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
Traceback (most recent call last):
File "cron/senddigests", line 94, in ?
main()
File "cron/senddigests", line 86, in main
mlist.send_digest_now()
File "/usr/share/mailman/Mailman/Digester.py", line
60, in send_digest_now
ToDigest.send_digests(self, mboxfp)
File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
130, in send_digests
send_i18n_digests(mlist, mboxfp)
File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
303, in send_i18n_digests
msg = scrubber(mlist, msg)
File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
257, in process
url = save_attachment(mlist, part, dir)
File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
348, in save_attachment
fnext = os.path.splitext(msg.get_filename(''))[1]
File "/usr/share/mailman/pythonlib/email/Message.py",
line 709, in get_filename
return unicode(newvalue[2], newvalue[0])
TypeError: unicode() argument 2 must be string, not None
--Apple-Mail-5-348793981
Content-Transfer-Encoding: base64
Content-Type: application/msword; x-unix-mode=0666;
name="Outside Professional Activities GS
Policy_4-22-03 rev
5-16-05.doc"
Content-Disposition: attachment;
filename*0="Outside Professional Activities GS
Policy_4-22-03 rev
5-16-05.do"; filename*1=c
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-07 18:07
Message:
Logged In: YES
user_id=1123998
>We fixed this locally by editing the mbox to change the
>offending filename to be shorter and not split into two
>parts, but it might be nice if mailman would check for
>illegal characters embedded in filenames?
I'm not sure if it is clear from my first comment, but the
cause of this exception (bug) was the RFC2231 splitting, not
the '\n\t' from header folding. Also, in later Mailman
versions, Scrubber is much more robust against bad
characters/encodings in filenames.
>In addition to senddigest croaking, all emails after
>this bad one were not added to the archive. Luckily we
>had made a copy of digest.mbox before running
>senddigest manually and were able to manually add the
>lost emails to the archive mbox.
I suspect these messages were shunted and could have been
reprocessed to the archive by bin/unshunt. At this point,
since the messages are in the archive, you should check to
see if they are still in qfiles/shunt/ and if so, delete
them from there so the don't get inadvertently unshunted in
the future.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-07-07 17:50
Message:
Logged In: YES
user_id=1123998
There are a couple of different issues here.
The '\n\t' in the filename come about because the header is
folded in the middle of the quoted value of the filename*0
parameter. The filename*0 and filename*1 parameters split
the filename per RFC2231, the very purpose of which is to
allow breaking of long parameter values into smaller pieces
so that header folding/unfolding can be accomplished at
syntactic breaks - e.g. at the semicolons.
In this case, either the generating MUA (Apple Mail) folded
the header in the middle of the filename*0 value or it made
the value so long that a subsequent MTA folded it. Thus,
with respect to the '\n\t' in the middle of the name, it
results from a non-compliant message.
The immediate cause of the exception in your case was fixed
in the email library shipped with Mailman 2.1.3. The fix
replaces
return unicode(newvalue[2], newvalue[0])
with
return unicode(newvalue[2], newvalue[0] or
'us-ascii')
and makes a similar change in a few other places. The patch
for this change is attached here.
There is also a bug in the (in your case)
/usr/share/mailman/pythonlib/email/Utils.py module. See the
post at
http://mail.python.org/pipermail/email-sig/2006-July/000293.html
for more on this and a possible patch.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_…
Bugs item #1518281, was opened at 2006-07-06 10:27
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&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: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Crotwell (crotwell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad Content-Disposition breaks senddigest
Initial Comment:
We are using the default mailman on mac osx server 10.3
which is mailman 2.1.2, so this may be old. But just in
case, we got an email with attachement that caused
mailman to croak in senddigest. Here is the output of
running it by hand. I added 2 prints to see what the
offending filename variable had in it. The
Content-Disposition headers are below. Note that the
two parts of the filename have been joined, but because
of the bizarre endquoting in filename*0, there is an
embedded \n\t.
We fixed this locally by editing the mbox to change the
offending filename to be shorter and not split into two
parts, but it might be nice if mailman would check for
illegal characters embedded in filenames?
In addition to senddigest croaking, all emails after
this bad one were not added to the archive. Luckily we
had made a copy of digest.mbox before running
senddigest manually and were able to manually add the
lost emails to the archive mbox.
roo:/usr/share/mailman root# python -S cron/senddigests
-l chair-archive
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
Traceback (most recent call last):
File "cron/senddigests", line 94, in ?
main()
File "cron/senddigests", line 86, in main
mlist.send_digest_now()
File "/usr/share/mailman/Mailman/Digester.py", line
60, in send_digest_now
ToDigest.send_digests(self, mboxfp)
File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
130, in send_digests
send_i18n_digests(mlist, mboxfp)
File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
303, in send_i18n_digests
msg = scrubber(mlist, msg)
File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
257, in process
url = save_attachment(mlist, part, dir)
File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
348, in save_attachment
fnext = os.path.splitext(msg.get_filename(''))[1]
File "/usr/share/mailman/pythonlib/email/Message.py",
line 709, in get_filename
return unicode(newvalue[2], newvalue[0])
TypeError: unicode() argument 2 must be string, not None
--Apple-Mail-5-348793981
Content-Transfer-Encoding: base64
Content-Type: application/msword; x-unix-mode=0666;
name="Outside Professional Activities GS
Policy_4-22-03 rev
5-16-05.doc"
Content-Disposition: attachment;
filename*0="Outside Professional Activities GS
Policy_4-22-03 rev
5-16-05.do"; filename*1=c
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-07 17:50
Message:
Logged In: YES
user_id=1123998
There are a couple of different issues here.
The '\n\t' in the filename come about because the header is
folded in the middle of the quoted value of the filename*0
parameter. The filename*0 and filename*1 parameters split
the filename per RFC2231, the very purpose of which is to
allow breaking of long parameter values into smaller pieces
so that header folding/unfolding can be accomplished at
syntactic breaks - e.g. at the semicolons.
In this case, either the generating MUA (Apple Mail) folded
the header in the middle of the filename*0 value or it made
the value so long that a subsequent MTA folded it. Thus,
with respect to the '\n\t' in the middle of the name, it
results from a non-compliant message.
The immediate cause of the exception in your case was fixed
in the email library shipped with Mailman 2.1.3. The fix
replaces
return unicode(newvalue[2], newvalue[0])
with
return unicode(newvalue[2], newvalue[0] or
'us-ascii')
and makes a similar change in a few other places. The patch
for this change is attached here.
There is also a bug in the (in your case)
/usr/share/mailman/pythonlib/email/Utils.py module. See the
post at
http://mail.python.org/pipermail/email-sig/2006-July/000293.html
for more on this and a possible patch.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_…
Bugs item #1230865, was opened at 2005-07-01 03:51
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&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: security/privacy
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alex (ams001)
Assigned to: Nobody/Anonymous (nobody)
Summary: spam filters get removed when changing other privacy pages
Initial Comment:
Originally reported in 1020013
http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=10…
This problem still very annoyingly ocurrs in the 2.1.6
release which appears not to include the patch
submitted. I have updated the patch against 2.1.6 and
included it below.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-06 18:13
Message:
Logged In: YES
user_id=1123998
The bug reported in the 2005-07-08 comment was fixed in
2.1.7 as well as in the trunk (2.2.0a0).
The bug described in report 1020013 was fixed in 2.1.6b5.
The patch attached to this report for 2.1.6 is redundant and
only adds a second test
if subcat == 'spam':
in the _handleForm() method definition when the test has
already been applied before calling _handleForm().
Apparently, the submitter confused the original bug which
had been fixed differently but equivalently to the patch
with the different bug reported in the 2005-07-08 comment.
If you have evidence that any bug with these symptoms is
still in 2.1.7 or 2.1.8, please submit a new report with
supporting information as to how to reproduce it.
----------------------------------------------------------------------
Comment By: Mantas K (mantas)
Date: 2006-07-06 12:49
Message:
Logged In: YES
user_id=439618
According to bugreporter (and my personal experience with
mailman) spam filters still gets removed when changing other
privacy pages in mailman 2.1.x :(
I think this bug should be reopened and closed only when it
will be really fixed in stable release of mailman.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2005-09-20 21:30
Message:
Logged In: YES
user_id=67709
Fixed in CVS. (2.2.0a0)
----------------------------------------------------------------------
Comment By: Alex (ams001)
Date: 2005-07-08 10:29
Message:
Logged In: YES
user_id=1156173
Unfortunately this patch does not fix all occurances of the
problem. I can reliably "lose" all spam filters entered by
going directly to the spam filter section after logging out.
To reproduce:
1. Login as list admin
2. Goto Privacy / Spam filters and create a spam filter
3. Logout
4. Modify logout URL from
.../<listname>/logout
to
.../<listname>/privacy/spam
5. Enter password and observe absense of Spam filter.
The worrying thing is that it appears to be the login
through the privacy/spam script that kills the spam filter.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&group_…