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
<quote who="bwarsaw(a)users.sourceforge.net">
> --- NEW FILE: README.txt ---
> This is a very rough work in progress. All Mailman 3.x work will
> occur in this directory under the top level CVS repository. Because I
> intend to reorganize the source tree, I think it's just better to
> start fresh. This does however mean that for anything we copy over
> (and hopefully that will be a good bit of code), we'll lose the CVS
> history for it.
It might be a bit of extra work, but why not just copy the files around in
the repository? History is important! :-)
- Jeff
--
linux.conf.au 2004: Adelaide, Australia http://lca2004.linux.org.au/
"Ah, now we see the violence inherent in the system." - From Monty
Python to ESR, by way of Al Viro
[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've been trying to set up a list behind my firewall on the local
network. The machine hosting mailman uses 192.168.0.2 as a static IP,
but the world sees me as ernest.isa-geek.org, the DNS entry I got
through dyndns.org.
If you try to subscribe to the list I created, the subscribe button
sends the request to 192.168.0.2 instead of ernest.isa-geek.org. While
that works fine from here, people out there aren't having any luck.
How do I make the subscribe button use the dns name vs the IP?
You can see what I'm talking about by going here and trying to subscribe
to the list:
http://www.ernest.isa-geek.org/mailman/listinfo/deltaflyers
I just noticed that the listinfo page says that there "currently are no
publicly-advertised Mailman mailing lists on www.ernest.isa-geek.org".
How do I make the list publicly-advertised?
--
----Because I can----
http://www.ernest.isa-geek.org/
------------------------
I tryed change the default page and link colors by adding relevant fields in
Default.py to mm_cfg.py. Changing all of the directives worked except for
WEB_LINK_COLOR
which did not result in a change. I found the offending error in
htmlformat.py line 326. It should read:
'link'
when it reads
'alink'
Changed to 'link' and default web links now change.
Mailman version 2.1.2
David Blomquist
Principal, Tentra IT Solutions
www.tentra.com
I have a problem with the Mailman servers I run related to an issue which
was discussed during the 2.0.4 to 2.0.5 transition some time ago. The
problem relates to people who click the stop button on their browser while
Mailman is doing its stuff. If the person in question is the list admin,
making changes to the list, then Mailman just aborts without saving the
list changes. Like the posters in the original discussion on this list
some 2 years ago I can live with these semantics, almost....
The problem is that Mailman always returns the content of the page, which
says that everything has been done, before it saves the list. For example,
see lines 236-238 of admindb.py in 2.1:
print doc.Format()
# Commit all changes
mlist.Save()
The problem with this is that mlist.Save() is taking quite a while for
large lists so I have to educate my list owners to be really patient and
wait for the browser to finish - with very little visual cue that it is
doing anything. (OK, animated wavy windows, spinning worlds, sparkly N's
apart....)
What would make much more sense to me (and my users) is if these two lines
were done the other way around. At least the users would then understand
that the system was doing something and shouldn't be interupted because
they would be looking at a blank browser window. They wouldn't be told
that their changes had been successfully carried out until they actually
had!
What do you all think? Can you see any problems with switching these two
lines (similarly in the other CGI handlers)?
Steve Lay
I would like to generate a link in the footer of each email that would take the user directly to their options page so that, if they want to unsubscribe, they can do so with a maximum of two steps one to click to the page and one to unsubscribe via the web page with no further confirmation steps. Is there a script for this already or should I look into creating one?
Thank you,
David Blomquist
Principal, Tentra IT Solutions
Hello,
this was originally: Mandrake 9.1 / ImportError
As a result of a suggestion from
Luca Olivetti (Mandrake list member)
I think now that you are maybe wrong with that line
255 in maimanctl.
The original line is
> os.execl(mm_cfg.PYTHON, 'qrunner', exe, rswitch, '-s')
But this is a semantic error we think.
The first parameter is arg0 no arg1, so you should be
using something like
os.execl(mm_cfg.PYTHON, '' , exe, rswitch, '-s')
Here is the diff for a patch:
255c255
< os.execl(mm_cfg.PYTHON, '' , exe, rswitch, '-s')
---
> os.execl(mm_cfg.PYTHON, 'qrunner', exe, rswitch, '-s')
This bug breaks several python installations.
It don't work for my Mandrake system for example.
It is possible to correct this in future releases?
What do you think?
- oliver
--
Oliver Egginger <Oliver.Egginger(a)dvz.fh-giessen.de>
Fachochschule Giessen-Friedberg
>>>>> "Jim" == Jim Garrett <Jim_Garrett(a)bd.com>
>>>>> on Fri, 16 May 2003 16:34:00 -0400 writes:
Jim> Hi Martin, Seeing the message below, I had the
Jim> impression that I was subscribed to the mailing list,
Jim> when perhaps I wasn't. At least, I sent a message to
Jim> the list and didn't receive it, so I thought I wasn't
Jim> signed up (maybe the list is intelligent enough not to
Jim> send me my own messages...). So I subscribed, and all
Jim> seems well.
no, not from here.
If I look at the members list, I only see the 6 people that have
been subscribed for many many months, but not all the new ones I
subscribed on May 7 -- nor your new subscription as of May 15.
I'm very much startled and even shocked about such a problem --
that I haven't seen in the past for the many other mailman lists
we manage here successfully.
If I read the "subscribe" log file (of mailman) which
tells me about the subscription it `did' :
May 07 09:16:30 2003 (23390) r-sig-qa: new "Jim_Garrett(a)bd.com" <>
May 07 09:16:30 2003 (23390) r-sig-qa: new "Rob.Balshaw(a)syreon.com" <>
May 07 09:16:30 2003 (23390) r-sig-qa: new "barker(a)medtap.com" <>
May 07 09:16:30 2003 (23390) r-sig-qa: new "fharrell(a)virginia.edu" <>
May 07 09:16:31 2003 (23390) r-sig-qa: new "gregory_r_warnes(a)groton.pfizer.com" <>
May 07 09:16:31 2003 (23390) r-sig-qa: new "luke(a)inpharmatica.co.uk" <>
May 07 09:16:31 2003 (23390) r-sig-qa: new "maechler(a)stat.math.ethz.ch" <>
May 07 09:16:31 2003 (23390) r-sig-qa: new "p.murrell(a)auckland.ac.nz" <>
May 07 09:16:31 2003 (23390) r-sig-qa: new "partha_bagchi(a)hgsi.com" <>
May 07 09:16:32 2003 (23390) r-sig-qa: new "rossini(a)blindglobe.net" <>
May 07 09:16:32 2003 (23390) r-sig-qa: new "rreeve(a)liposcience.com" <>
May 07 09:16:32 2003 (23390) r-sig-qa: new "tura(a)centroin.com.br" <>
May 07 09:16:32 2003 (23390) r-sig-qa: new "v_bill_pikounis(a)merck.com" <>
May 07 09:16:32 2003 (23390) r-sig-qa: new "werner_engl(a)baxter.com" <>
May 15 22:05:38 2003 (20223) r-sig-qa: pending Jim Garrett <jim_garrett(a)bd.com> 198.232.248.8
May 15 22:13:52 2003 (20630) r-sig-qa: new "jim_garrett(a)bd.com" <Jim Garrett>
everything looks fine, but when I then look at the members
lists, nobody new one is there....
Jim> I wonder if it's possible that some people think they
Jim> are subscribed when in fact they are not. Could you
Jim> please verify how many are subscribed? I tried to
Jim> check the subscriber list but wasn't allowed (even
Jim> after giving my password).
as you see, I did subscribe you and all these by a so-called
"mass subscription" and you did get the corresponding welcome
e-mail (that you had appended here).
I just tried again (needs a tiny bit longer when working from
home), and it didn't work again -- when I tried to "upload a
file" of new member addresses.
However when I tried (the old way of) pasting the new members
e-mails in to the web-interface form -- it did work.
This is clearly a bug with mailman (2.1.2) or our setup of
mailman (the web server doesn't have the same files mounted, the
file I used is only available on the client and the
machine where mailman runs, but not on the machine
where httpd runs).
For this reason, I forward this answer to quite a few other
people.
Anyway, the new subscription are now up.
Probably you should send a new short mail mentioning that
everyone can use the list archives to read your last posting and
Kurt Hornik's reply to it, via the usual web interface, or very
directly going to
https://www.stat.math.ethz.ch/pipermail/r-sig-qa/2003-May/thread.html
Please apologize the problem!
Martin Maechler <maechler(a)stat.math.ethz.ch> http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228 <><
