Patches item #1710185, was opened at 2007-04-30 13:00
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=1710185&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: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael McGraw-Herdeg (mherdeg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for digest_size_threshold = 0
Initial Comment:
This patch results in no more than one digest being sent per day if digest_size_threshold is set to zero.
This behavior is documented at http://www.gnu.org/software/mailman/mailman-admin/node19.html:
"Set this variable to zero to specify that there is no size threshold, in which case no more than one digest will be sent out per day."
ToDigest.py does not currently implement this behavior. Under the current code, a threshold of zero will always be exceeded, so digest mode will not result in any reduction of traffic for recipients (and will in fact increase message size.) This patch expands the test to check the zero case.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1710185&group_…
Bugs item #1696053, was opened at 2007-04-07 17:24
Message generated for change (Comment added) made by dovzamir
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dubi (dovzamir)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hebrew Translation Attached!
Initial Comment:
Attached are the Hebrew files for Mailman 2.1.9
I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION'
function. They have been changed, and diffs are attached...
./Mailman/Cgi/create.py
./Mailman/Defaults.py.in
./Mailman/Defaults.py
./Mailman/Utils.py
./messages/es/README.es
./messages/ja/README.ja
./messages/ja/doc/Defaults.py.in
./messages/eu/README.eu
Likewise, all translation files are attached.
There is still a problem displaying command line output in the correct direction. Still looking for a solution...
----------------------------------------------------------------------
>Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:33
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:30
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:27
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…
Bugs item #1696053, was opened at 2007-04-07 17:24
Message generated for change (Comment added) made by dovzamir
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dubi (dovzamir)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hebrew Translation Attached!
Initial Comment:
Attached are the Hebrew files for Mailman 2.1.9
I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION'
function. They have been changed, and diffs are attached...
./Mailman/Cgi/create.py
./Mailman/Defaults.py.in
./Mailman/Defaults.py
./Mailman/Utils.py
./messages/es/README.es
./messages/ja/README.ja
./messages/ja/doc/Defaults.py.in
./messages/eu/README.eu
Likewise, all translation files are attached.
There is still a problem displaying command line output in the correct direction. Still looking for a solution...
----------------------------------------------------------------------
>Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:30
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:27
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…
Bugs item #1696053, was opened at 2007-04-07 17:24
Message generated for change (Comment added) made by dovzamir
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dubi (dovzamir)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hebrew Translation Attached!
Initial Comment:
Attached are the Hebrew files for Mailman 2.1.9
I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION'
function. They have been changed, and diffs are attached...
./Mailman/Cgi/create.py
./Mailman/Defaults.py.in
./Mailman/Defaults.py
./Mailman/Utils.py
./messages/es/README.es
./messages/ja/README.ja
./messages/ja/doc/Defaults.py.in
./messages/eu/README.eu
Likewise, all translation files are attached.
There is still a problem displaying command line output in the correct direction. Still looking for a solution...
----------------------------------------------------------------------
>Comment By: Dubi (dovzamir)
Date: 2007-04-26 21:27
Message:
Logged In: YES
user_id=1207589
Originator: YES
File Added: Mailman_2.1.9_he.tar.gz
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…
Feature Requests item #1707731, was opened at 2007-04-25 15:13
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1707731&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
Private: No
Submitted By: Knut Auvor Grythe (auvor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't munge reply-to if one already exists -- feature reques
Initial Comment:
As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to.
Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this.
A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one.
The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish).
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2007-04-25 18:50
Message:
Logged In: YES
user_id=1123998
Originator: NO
Per your comment I am moving this to Feature Requests. I'm sorry for the
confusion, but it's not my tracker either :-)
----------------------------------------------------------------------
Comment By: Knut Auvor Grythe (auvor)
Date: 2007-04-25 15:28
Message:
Logged In: YES
user_id=1137196
Originator: YES
Ooops. I didn't realize that the "Submit new" menu choice acted
differently based on where one was in the tracker when clicking it, and
expected to be able to mark the request as a feature request on the next
page or something. I'm very sorry about that. I'd normally try to clean up
after myself, but this time I expect I'd just worsen the mess :-|
As you've probably guessed, I've never used the SourceForge bugtracker
before ;-)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1707731&group_…
Patches item #1707731, was opened at 2007-04-26 00:13
Message generated for change (Comment added) made by auvor
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&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
Private: No
Submitted By: Knut Auvor Grythe (auvor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't munge reply-to if one already exists -- feature reques
Initial Comment:
As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to.
Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this.
A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one.
The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish).
----------------------------------------------------------------------
>Comment By: Knut Auvor Grythe (auvor)
Date: 2007-04-26 00:28
Message:
Logged In: YES
user_id=1137196
Originator: YES
Ooops. I didn't realize that the "Submit new" menu choice acted
differently based on where one was in the tracker when clicking it, and
expected to be able to mark the request as a feature request on the next
page or something. I'm very sorry about that. I'd normally try to clean up
after myself, but this time I expect I'd just worsen the mess :-|
As you've probably guessed, I've never used the SourceForge bugtracker
before ;-)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&group_…
Patches item #1707731, was opened at 2007-04-26 00:13
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=1707731&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
Private: No
Submitted By: Knut Auvor Grythe (auvor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't munge reply-to if one already exists -- feature reques
Initial Comment:
As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to.
Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this.
A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one.
The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&group_…
Feature Requests item #782436, was opened at 2003-08-03 19:32
Message generated for change (Comment added) made by umardarmaji
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: JC Dill (jcdill)
Assigned to: Nobody/Anonymous (nobody)
Summary: members per page on admin page
Initial Comment:
Put a radio button option on the membership page to
allow list owners to change the number of members
returned on each page. I suggest that the options include:
25 per page
50 per page
100 per page
200 per page
500 per page
all subscribers on one page (use with caution if you
have a big list!)
----------------------------------------------------------------------
Comment By: oemardarmaji (umardarmaji)
Date: 2007-04-18 07:19
Message:
Logged In: YES
user_id=1772313
Originator: NO
Test
----------------------------------------------------------------------
Comment By: John W. Baxter (jwbaxter)
Date: 2006-06-11 17:55
Message:
Logged In: YES
user_id=664644
This seems like a quite reasonable proposal.
Is the intent to return to the old method, where the pages (except last)
were all
full and there was on each page an index of links giving the first (first
and last)
address on each other page?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_i…
Feature Requests item #1387243, was opened at 2005-12-22 03:01
Message generated for change (Comment added) made by tpv
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&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
Private: No
Submitted By: Matt Swift (msswift)
Assigned to: Nobody/Anonymous (nobody)
Summary: option to discard messages that lack explicit destination
Initial Comment:
The configurable variable require_explicit_destination
is a boolean that selects whether to hold a message for
moderation if neither the list address nor any aliases
appear in the To: or Cc: headers. On certain lists I
manage, a lot of spam is sent to the lists via BCC:.
Setting this variable keeps this spam off the list,
which is great, but I spend a lot of time discarding
the spam. I can't simply discard all messages held for
moderation, because there are occasional legitimate
messages held for another reason that I want to accept.
So I have to trawl through it all.
Therefore, please make the require_explicit_destination
setting offer the familiar choices of allow, hold,
reject, and discard. I'd be happy if you added just
"discard" without adding "reject", but the full four
choices would be consistent with the rest of Mailman.
This will save me a lot of time, and I would think many
other users are in the same situation.
----------------------------------------------------------------------
Comment By: Tim Vernum (tpv)
Date: 2007-04-18 00:17
Message:
Logged In: YES
user_id=4727
Originator: NO
This RFE is becoming a significant issue for some lists that I run. What
can be done to get this fixed?
Would a patch help, or is there some specific piece of work that you want
to bundle it up with?
I'm happy to put together a patch (although my python is a little rusty)
but I don't want to waste everyone's time if you want it done a specific
way.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2005-12-22 04:28
Message:
Logged In: YES
user_id=1123998
While we're at it, we probably should also add hold, reject
and discard choices if max_num_recipients is > 0
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2005-12-22 03:32
Message:
Logged In: YES
user_id=1123998
I think this is a good idea.
In the mean time, see the post and reply at
<http://mail.python.org/pipermail/mailman-users/2005-December/048078.html>
and
<http://mail.python.org/pipermail/mailman-users/2005-December/048086.html>
for some interim patch ideas.
Also see the post at
<http://mail.python.org/pipermail/mailman-users/2005-February/042954.html>
for a way to do this with spam filters that doesn't require
patching.
----------------------------------------------------------------------
Comment By: Matt Swift (msswift)
Date: 2005-12-22 03:29
Message:
Logged In: YES
user_id=1409646
P.S. I realize that I can accomplish what I want by an
appropriate setting of header_filter_rules, but it's not
very convenient, since I can't make use of
acceptable_aliases.
The introduction of header_filter_rules is great, but it
creates confusion by making the existing sender and
recipient filters redundant. I suggest renaming the section
in which header_filter_rules from "spam filters" to
"advanced filter" or something like that. All three
sections can be used to filter spam, so it's misleading to
distinguish a "spam filter" from sender and recipient
filters. The documentation for header_filter_rules /
"advanced filter" section should explain that this filter is
a general mechanism which exists; the sender/recipient
filters are special cases that are common enough to merit a
convenient interface just for them.
Even with this clarification of the header_filter_rules, I
still think require_explicit_destination should be expanded
to offer all four actions. If you're going to go to the
trouble of setting up the special interface to filter a lack
of explicit destination, it really ought to offer complete
options. It won't complicate the interface (really, it will
simplify it to have the familiar four actions offered), and
it seems very awkward to have to recreate this nice
interface in header_filter_rules (acceptable_aliases and so
on) just because the manager wants an action other than
"accept" or "hold".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…
Bugs item #1698759, was opened at 2007-04-11 16:23
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=1698759&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
Private: No
Submitted By: Krystal (krystalz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Digest delivery using EUC-JP
Initial Comment:
I have a set of servers, each of which run approximately 2,000 Mailman lists.
We started receiving complaints from users on one of these particular servers that they were unable to send digests.
After another technician and I went through the error logs, we found one specific list which had an MBOX file for digests, but didn't have any users which used digest mode. (digest was turned on). We moved the mbox
file, and within minutes all of the digests started to go through and the problem went away.
We found this was the only of our lists which had digests turned on (whether used or not), for all of our servers, which happened to be using EUC-JP.
This was discussed on the MAILMAN-USERS group, and it was mentioned it should be forwarded here. I am including a snippit of the conversation below:
> > > I don't fully understand your situation but there is a common problem in Japanese people who don't care (or ignorant) about 'machine dependent characters' like number in circle or double width roman numerals. If
those characters are used in 'iso-2022-jp' declaration of charset, mailman and python codecs fail to process such characters and single processes like 'cron/senddigests' stops working.
> > > My advice is to remove (or rename for later inspection) the digest.mbox file from the Japanese list directory and set digestable=0 if they keep using the 'machine dependent characters'.
> > > -Tokio
> > > Please file a bug report. I am just as frustrated as Kikuchi-san is with the Japanese attitude toward standards, but this behavior of Mailman is a violation of the Postel Principle ("be strict in what
you emit, but lax in what you accept"). Mailman functionality should
not be disabled by the contents of posts it handles; if it doesn't like them, it should strip them or quarantine them without impeding the flow of other posts.
> > > In the short run, you probably should disable digestible for that list. Mailman's I18N is not very robust in this respect, and it may take some time to fix. Tokio, is it possible that you could just default the error policy for codecs as "replace" for charsets that are known to be prone to "vendor extension"? And add an option for the set of "replace-able" charsets
to be set by the list admin?
> > > -Stephen
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1698759&group_…