I find I am being removed from mailman mailing lists left and right. I believe
the default values for the bounce removal should be reconsidered. It's
possible that you haven't had many users in my situation and so haven't really
had a chance to tune these parameters on the low end yet. But they clearly
aren't working for me at a few sites.
My particular situation is that my site has seen fit to filter viruses by
refusing delivery. This causes a bounce from the remote MTA every time someone
sends me an Outlook virus. Why my site administrators felt this was necessary
is a question for another day, it's not like I use Outlook or like my spam
filters wouldn't have thrown these messages away anyways, but whatever.
The net result is that some small fraction of messages to me bounce and list
management software notices this. The only reason I became aware of the
problem was because ezmlm also does this type of processing but it sends a
warning message before removing users. It only removes you if the warning
message itself bounces. In fact it sends two such warning messages and only
removes the user if *both* bounce. This provides the user with a chance to
react to the first message and fix the problem -- if they ever see the
message.
I could beg for a similar feature in mailman, but I'm not sure it's necessary.
But I am sure it's necessary to tune the bounce processing parameters. The
relatively few bounces I'm generating shouldn't be causing me to get removed
when all the real messages are being delivered fine.
It seems the legitimate messages that are correctly delivered should reset the
count of bounces to 0. Reading the source it seems it has to see
DEFAULT_MAX_POSTS_BETWEEN_BOUNCES such legitimate posts between messages. I'm
fairly convinced this parameter should always be 0. If any successful delivery
occurs the user should never be removed due to bounces.
What I don't understand is how DEFAULT_MAX_POSTS_BETWEEN_BOUNCES relates to
the parameters I see in the admin. None of the parameters in the admin
corresponds to this. How is it calculated?
--
greg
[Apologies for the empty dups -- been fiddling with my email client again. ;}
-BAW]
I've just released Mailman 2.1.2 which includes many bug fixes and
language updates, as well as support for two new languages,
Portuguese/Portugal and Polish. I recommend all Mailman 2.1 users
upgrade to this release.
The full source tarball has been made available from the usual sites.
Currently, there is no patch available, but you should be able to
install 2.1.2 over your existing 2.1.x installation. See
http://sourceforge.net/project/showfiles.php?group_id=103
for links to download all the patches and the source tarballs.
Be sure you restart your mailman daemon by doing a "mailmanctl restart"
after installing.
See also:
http://www.gnu.org/software/mailmanhttp://www.list.org (not yet updated)
http://mailman.sf.net
Cheers,
-Barry
-------------------- snip snip --------------------
2.1.2 (22-Apr-2003)
- New languages Portuguese (Portugal) and Polish.
- Many convenient constants have been added to the Defaults.py
module to (hopefully) make it more readable.
- Email addresses which contain 8-bit characters in them are now
rejected and won't be subscribed. This is not the same as 8-bit
characters in the realname, which is still allowed.
- The X-Originating-Email header is removed for anonymous lists.
Hotmail apparently adds this header.
- When running make to build Mailman, you can specify $DESTDIR to
the install target to specify an alternative location for
installation, without influencing the paths stored in
e.g. Defaults.py. This is useful to package managers.
- New Defaults.py variable DELIVERY_RETRY_WAIT which controls how
long the outgoing qrunner will wait before it retries a
tempfailure delivery.
- The semantics for the extend.py hook to MailList objects has
changed slightly. The hook is now called before attempting to
lock and load the database.
- Mailman now uses the email package version 2.5.1
- bin/transcheck now checks for double-%'s
- bin/genaliases grew a -q / --quiet flag
- cron/checkdbs grew a -h / --help option.
- The -c / --change-msg option has been removed from bin/add_members
- bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n
directory. The various .mo files are now no longer distributed
with Mailman. They are generated at build time instead.
- A new file misc/sitelist.cfg which can be used with
bin/config_list provides a small number of recommended settings
for your site list. Be sure to read it over before applying!
sitelist.cfg is installed into the data directory.
- Many bug fixes, including these SourceForge bugs closed and
patches applied: 677668, 690448, 700538, 700537, 673294, 683906,
671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941,
658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755,
661138, 716754, 716702, 667167, 725369, 726415
? This very message came to me with the following header:
Errors-To: mailman-developers-admin(a)python.org
All my bounces come to the list admin address, set in
the admin webpage, in the second field of General Options.
Do you have that set to something, and bounces still come to root?
> 2. Bounces are sent to the poor postmaster instead of a -admin address.
> I'm not entirely certain, but I think an Errors-To: header or something
> like that in all Mailman messages might allow one to distribute that load
> somewhat.
I'm getting this below error when an user tries to open up there
archives. I've run check_perms and all the permissions are correct.
When I change the archive options on this list to public I get this
below error when I change it back to private I can view the threaded
archives fine, is there a solution to this. I've tested this with my
other lists and it does the same thing. There most be something that
I've got configured wrong that a list can't be setup to view the
archives in the (public) setting.
ACCESS DENIED !
You don't have permission to access the requested directory. There
is either no index document or the directory is read-protected.
If you think this is a server error, please contact the webmaster
ERROR 403
mm.isu.edu
Wed Apr 30 11:47:13 2003
Apache/2.0.40 (Red Hat Linux)
--
Kory Wheatley
Academic Computing Analyst Sr.
Phone 282-3874
#########################################
Everything must point to him.
Hello,
I'm curious about the status and priority of two features which, as far as I
know, have yet to be implemented in Mailman.
1) External user database. I'm sure you're all aware of the desire of some
folks to have this. I found a Wiki document somewhere on the zope.org site
that had discussions on this but I believe it was somewhat dated. Have any
conclusions been reached with respect to the direction here? I think I read
talk of a Zope-specific solution. I'm wondering if this means that we're
likely never to see a Mailman that can talk to a MySQL database. I believe
this one feature alone would elevate Mailman significantly. How hgh of a
priority is this to the development team and what is the status? Are there
current discussions on this somewhere other than the list (wiki boards,
chats, what-have-you) , and if so, may I take part?
2) Moderated-edit. I'm running Mailman on a couple of boxes but I also have
a few hundred lists on a box running Lyris. I want to move them but one of
the deal breakers at the moment is moderated-edit - the ability of a
moderator to edit a message before it goes out. I personally don't use this
feature for the lists I am the admin of but this seems to be a very
important feature to some. An absolute must, in fact. I'm wonderig if this
is in the cards, is it high on the priority list, should we expect to see it
soon?
I understand this is a non-paying gig for Barry and others, and I understand
there are likely a ton of other items to deal with. But knowing what the
priority and status of these two items are would give me a realistic idea of
when I might be able to drop the oh-so-commercial Lyris.
Finally, I'm not a Python programmer (yet), mostly Perl and PHP. But if I
can help the cause in non-Python coding ways let me know.
Thanks,
Kevin
New to this list but checked FAQ. Was not able to find solution. I am
using mailman from CVS and this bug seems to be unfixed.
Description:
We are running company with 200 computer workstations and over 20 lists
on mailman. Once our user was able to prove, that sometime mailman just
deletes the subject. Instead of original subject we have "[foo] (no
subject)".
My first reaction was to upgrade mailman. I did "cvs update" and
behaviour changed - no mails come through from this user. I believe
after many tests I knopw what is the issue but I do not want to dig into
Python code. Hope, someone else can fix it.
We are located in Estonia and our native language uses some unique
characters ä and õ (in HTML terms). At some point Microsoft
invented new charset "Windows-1257" while actually "ISO8859-15" covers
our needs. Many kind of software tries to interpret charsets and gets
confused on pretty usual characters because this "windows-1257".
I have no power to make different people change their country settings.
Only way is to make software act different when unknown charset appears.
Mailman currently "eats" characters with unknown charsets and this is
bad for us.
Original mail subject line in raw data:
Subject: =?windows-1257?Q?FW:_=E4=E4test_kustutage_=E4ra?=
And this makes mailman to loose mail. With latest version it archives
mail without subject and never sends it out to subscribers. No error
messages sent to anyone indicating mail loss. In some point it saved
this mail in "shunt" folder but mail lost without any tracks after
"unshunt" command.
Any fixes? ideas? I propose to include bytes from unknown charsets in
redistributed mails. If this seems not possible, read "windows-1257" as
ISO8859-15 and I think it will work for most cases.
--
Tonu Samuel <tonu(a)spam.ee>
I just did a CVS update again since I was still getting these, and one of
my installs also dies on subscriptions
Traceback (most recent call last):
File "/var/local/mailman/scripts/driver", line 87, in run_main
main()
File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 96, in main
process_form(mlist, doc, cgidata, language)
File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form
mlist.AddMember(userdesc, remote)
File "/var/local/mailman/Mailman/MailList.py", line 806, in AddMember
cookie = Pending.new(Pending.SUBSCRIPTION, userdesc)
File "/var/local/mailman/Mailman/Pending.py", line 75, in new
db = _load()
File "/var/local/mailman/Mailman/Pending.py", line 163, in _load
return cPickle.load(fp)
EOFError
(go to http://lists.svlug.org/lists/listinfo/svlug and join if you want
to reproduce)
Thanks
Marc
----- Forwarded message from Cron Daemon <root(a)svlug.org> -----
From: root(a)svlug.org (Cron Daemon)
To: mailman(a)svlug.org
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/local/mailman>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=mailman>
Subject: Cron <mailman@svlug> /usr/bin/python -S /var/local/mailman/cron/disabled
Traceback (most recent call last):
File "/var/local/mailman/cron/disabled", line 209, in ?
main()
File "/var/local/mailman/cron/disabled", line 201, in main
mlist.sendNextNotification(member)
File "/var/local/mailman/Mailman/Bouncer.py", line 212, in sendNextNotification
Pending.confirm(info.cookie)
File "/var/local/mailman/Mailman/Pending.py", line 133, in confirm
db = _load()
File "/var/local/mailman/Mailman/Pending.py", line 163, in _load
return cPickle.load(fp)
EOFError
----- End forwarded message -----
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key
I've been a list owner for several years, using several different list mgt
packages. I've also managed web sites and done some help desk work. I'm
not a Mailman developer, but the Sourceforge page for bug submission
suggested that the developers be notified directly of bug submissions, so
here goes.
********************************************************************
Bug# 728122: Unsub instructions difficult to find
The default Mailman info page for the list could stand some improvements.
I've noticed it over and over and finally decided to contribute to a
solution instead of griping about the problem. ;-)
I recommend these two changes:
1. Move the administrative "$listname Subscribers" section to the bottom
of the page. Admins will know where to look and subscribers should not
have to read through admin info to get to the section that concerns
them (changing subscription options).
2. Add a standard colored section header titled "Change Options or
Unsubscribe". The original format for this section did not clearly
indicate that this is the section for unsubscribing. Users have to
read the fine print. Reading the fine print is fine for detailed
instructions, but the users should have some idea that the unsub
instructions are there just by looking at the section header.
*********************************************************************
A sample HTML page is attached to the Bug record.
Tony
--
Anthony E. Greene <mailto:Anthony%20E.%20Greene%20%3Cagreene@pobox.com%3E>
OpenPGP Key: 0x6C94239D/7B3D BD7D 7D91 1B44 BA26 C484 A42A 60DD 6C94 239D
AOL/Yahoo Chat: TonyG05 HomePage: <http://www.pobox.com/~agreene/>
Linux. The choice of a GNU generation. <http://www.linux.org/>
It looks like those were removed or renamed recently and it broke
check_perms_grsecurity.py
What am I supposed to use now?
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key
I'm currently running Mailman 2.1.1
I recently completed splitting my large 190,000 member list into 72 sublists
for performance
reasons (primarily bounce processing).
I split the lists leaving bounce disabled addresses in the mix to be able to
measure performance
of the new setup.
My first mailing to my 72 sublists generated over 15,000 bounces, however
the performance wasn't what I expected.
The first few bounces were processed at over 8 per second. However that
slowed to 5 seconds PER BOUNCE near the end.
After investigation I noticed that ~mailman/data/pending.pck had grown to
almost 2 megabytes in size.
Even though I have my bounce threshold set to 5.0 and NO addresses were
disabled because of bouncing, pending.pck contained over
15,000 "re-enable" entries along with generated confirmation strings.
I double checked the bounce information was correctly registered by dumping
the config.pck for the mailing list. None of these addresses were disabled
and the bounce information is correct.
I looked at the code in Bouncer.py at the "registerbounce" routine and this
behavior appears to be by design.
Am I missing something here or is this a bug?