Mailman-Developers April 2003

mailman-developers@python.org

63 participants
65 discussions

Bounce removal parameters default values

by Greg Stark

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

17 years, 4 months

RELEASED Mailman 2.1.2

by Barry Warsaw

[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/mailman http://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

17 years, 6 months

Re: [Mailman-Developers] Mailman password and administrative reminders

by Dan Mick

? 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.

17 years, 6 months

public and private archives problem

by Kory Wheatley

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.

17 years, 10 months

Priority/status of moderated-edit and external user DB

by Kevin McCann

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

17 years, 10 months

Mails get lost with different 2.1.x mailmans, including today's CVS

by Tonu Samuel

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>

17 years, 10 months

More tracebacks with mailman-cvs

by Marc MERLIN

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

17 years, 10 months

Request update of list information page

by Anthony E. Greene

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

17 years, 10 months

What happened to MAILMAN_UID, MAILMAN_GID?

by Marc MERLIN

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

17 years, 10 months

Bounce processing performance, pending.pck possible bug/redesign

by John Distler

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?

17 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers April 2003