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
Things have been a bit busy, but I've finally moved to v2.1.* and Exim4,
and in the process have had to adapt my setup for fronting Mailman lists
with TMDA and an external optional/controllable MIME processor
(MimeFilter, can be turned off on a per-message basis by a custom
header).
If there's sufficient interest I'll update the HOWTO with the details.
There's nothing really hard in the deal, just an excess of details.
Interested?
ObNote: If you don't know what I'm talking about, please see the
UserFAQ and the archives of this list for definitions, implementation
details and implications, and prior discussion of same.
ObNote2: TMDA as of v0.75 (latest .deb)is not able to read Mailman
v2.1 list configurations to extract the membership rosters (the pickle
now contains bounce objects so the naive cPickle.load fails). This
doesn't create a major problem, just means that you have to comment
sections of your TMDA filters until that's fixed. (Jason: If you want
example configs and other details, just give me the word and I'll
attach them over).
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
<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.
Mailman 2.1.2, Apache 1.3.27, and Python 2.2.2:
On initial configuration, on attempting to create the mailman list
itself, the output from newlist mailman is:
To finish creating your mailing list, you must edit your /etc/aliases
(or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:
## mailman mailing list
mailman: "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join: "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave: "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner: "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request: "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe: "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe
mailman"
Hit enter to notify mailman owner...
Traceback (most recent call last):
File "bin/newlist", line 226, in ?
main()
File "bin/newlist", line 218, in main
text, mlist.preferred_language)
File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__
errors='replace')
TypeError: __init__() got an unexpected keyword argument 'errors'
John S.
1) The sliding/N'th_message pseudo-VERP supports rocks.
2) The new admindb interface is a significant improvement.
3) Forwarding messages from the admindb as message/rfc822 parts needs to
be optional. Previously I used that feature support heavily to move
messages between lists as a moderator as threads drifted. The use of
MIME attachments now makes that a pain.
4) I have HOLD_MESSAGES_AS_PICKLES=0 in mm_cfg.py and seem to get
occasional orphaned messages in ~mailman/data. There's a
held-<listname>-* file there, but there's no entry in the appropriate
matching data structures. I suspect a race condition as the three times
this has happened have all been when I've had over 20 messages delivered
to a single list within a couple seconds.
5) MTAs that send bounces to Return-path headers in messages rather than
the envelope suck.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
hello,
i realized some strange behavior of mailman with the
EXTERNAL_PUBLIC_ARCHIVER option. simply setting it to
'/usr/bin/id > /tmp/log 2>&1' gives in /tmp/log:
uid=38(list) gid=38(list) groups=0(root),102(lpadmin),109(shutdown)
at commandline:
$ whoami
list
$ id
uid=38(list) gid=38(list) groups=38(list),106(lurker)
why does user list member different lists in the two cases? same uid, same
gid, only the lists it members are different.
bye
mejo
--
Efficiency and progess is ours one more
Now that we have the Neutron bomb
It's nice and quick and clean and gets things done
Kill kill kill kill kill the poor tonight
On Sat, 28 Jun 2003 13:12:26 -0700
Ross Boylan <RossBoylan(a)stanfordalumni.org> wrote:
> On Sat, Jun 28, 2003 at 12:44:44PM -0400, Barry Warsaw wrote:
>> On Sat, 2003-06-28 at 12:12, J C Lawrence wrote: >
> I can confirm that email is not installed properly. My debian/testing
> installation (apt-get upgrade) failed with
# apt-get -t unstable python2.1 python2.1-email
Solved it for me (see my message to Barry).
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On 28 Jun 2003 12:44:44 -0400
Barry Warsaw <barry(a)python.org> wrote:
> On Sat, 2003-06-28 at 12:12, J C Lawrence wrote:
> Something's wrong with the Mailman installation. I'm suspecting that
> the email package didn't get installed correctly and Message.py is
> using the email.Header module from whatever version of Python you're
> using. Look under /var/lib/mailman/pythonlib to see if email 2.5.x is
> installed.
> I've seen this before and it always comes down to some Python
> rpm/package not being installed....
Excellent analysis Barry -- accurate and revealing.
Short version of the results:
The 2.1.2-2 Mailman package in /testing is broken in that it uses the
floor operator, and yet the Python2.1 package shipped in /testing
don't -- which means that the python2.1-email package in /testing
fails to install properly due to you use of the floor // operator in
_compat22.py.
Solution: upgrade python2.1 to /unstable and make sure that the
python2.1-email package is installed.
Hopefully the Debian mailman maintainer will read this (I'll CC this to
him later if he doesn't ack me here).
> I hope to have time to spin 2.1.3 tomorrow.
It would help me if we could squeeze the Return-Path fix in there. TMDA
requires a Return-Path header and the work-arounds for the Mailman/TMDA
integration are ungraceful. I won't have time today, and likely not
tomorrow either alas. If you could delay a bit I can likely do it in
the early days of this week.
BTW I may finally be able to buy you some of those beers I owe you. I'm
on a consulting gig in Groton CT these days (a long and dismal story).
Where are you again?
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
