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
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?
? This very message came to me with the following header:
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
>From the documentation, the default installation path is /home/mailman.
It is practical we install mailman in /home/mailman or we should install it at other location? (e.g /var/www/html)
Or do you have special installation path to install mailman. I'm asking this silly question because
i'm quiet confuse when other software(actually i'm trying to setup savannah) always asking me where is
mailman cgi-bin path?
Syed Ahmad Shazali Syed Abdullah
Researcher, Open Source Development
MIMOS Berhad, Malaysia
This message is primary for those of you writing or using alternative
MemberAdaptor implementations (e.g. SQL).
Yesterday I checked in a working implementation of a member adaptor
based on BerkeleyDB. It seems to greatly improve the memory footprint
for really huge lists, at the cost of greater administrative overhead
(because you have to know how to setup and manage BerkeleyDBs), and
potentially slower performance (I haven't benchmarked it; this is just
based on my experience with BerkeleyDB in general).
I've found a few things during this experience that point to things we
ought to improve. I don't have a lot of time right now, but I wanted
to put this out there to start the discussion. I'll quickly mention a
- I wanted to hook into the BDB transaction (txn) machinery, and I
found a convenient hook. I overloaded MailList.Lock() to include a
txn begin, MailList.Save() to do a txn commit, and MailList.Unlock()
to do a txn abort. This seems to work well as long as aborting
after committing is harmless (it is in BDB). I'd like to get
feedback from the SQL folks (or other MemberAdaptor developers) on
whether we need more explicit transaction support or whether the
basically necessary hooks are already there.
- To make this work, however, I found I had to change the order of
when the extend.py hook gets run. Specifically, I needed it to run
/before/ the list is locked in MailList.__init__(), otherwise
locking contructors don't hook into the machinery. I want to commit
this change but I don't want to break other MemberAdaptors or
- We really need to optimize the MemberAdaptor API and the
implementations that use them. Especially methods that return
lists, e.g. getMembers() and friends. Right now, everything has to
return a list, but I could do much better by returning iterators,
because I can load my iterator up with a BDB cursor. This has the
advantage of not requiring the entire member database to be loaded
into memory just to iterate over it. Unfortunately, too much of the
rest of the code assumes these methods return lists, and while I
started to go down the iterator path, I backed out of it because of
There are other optimizations that would require a bit more
thought. E.g. the admin's Membership List page seems to require
that the entire member database be iterated over to chunkify and
bucketize. Fixing this probably requires both changes to the u/i
and changes to the interface. It also makes life more difficult for
OldStyleMemberships, although BDBMemberAdaptor can probably be
fairly easily elaborated.
I'd like to hear from other member adaptor implementations on their
- I'd love for any BerkeleyDB experts to review the BDBMemberAdaptor
code, especially in some of the choices I've made for creating and
opening the environment. I had a lot of practical problems with
this part of the code, especially in getting multiple processes to
cooperate reasonably. Any BerkeleyDB experts out there? (I'm
fairly happy with the schemas, at least for the current
- I'm leaning heavily toward having this stuff in Mailman 2.2 and
/not/ porting it to 2.1.x. Too many changes for a micro release,
although it makes project management more complicated, especially in
merging fixes back into the 2.1.x maintenance branch. Sigh.
Okay, I'm out of time for today. Any feedback will be appreciated,
even if I can't respond immediately.
Also, the BerkeleyDB based member adaptor seems to work, but should be
considered experimental. See the BDBMemberAdaptor.py comments for how
to hook this up to a mailing list. There is currently no migration
tool from classic member adaptors to BDBMemberAdaptors, although I
intend to write such a beast and run a few of my personal lists on the
code to flesh things out.
I've recently created a mailing list with mailman and are quite satisfied.
However I have one simple question/request:
If I have public archives and a member of the list has a signature in their
email reader, this signature is included in the archive. But - at least in my
list - it is quite common for signatures to include the posters email adress
which therefore are being made accesible on a public webpage.
Is it possible to strip messages of the signature before they are being
archived? If so - how?
Hi i am a new developer in Mailman.
I need know if exist a function to retrive a admin password like....
oldpw = mlist.getMemberPassword(address)
PS: Sorry For my bad english
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 01/27/2003
On 2003-02-26 at 18:00:06 [+0100], mailman-developers-request(a)python.org
> Chuq Von Rospach wrote:
> > you go tell hotmail to fix itself, Barry.
> ...or tell your users to drop that piece of crap.
> yes yes, I know, millions on the Internet, elitist attitude, yadda yadda.
Actually it's worse than that it's counterproductive and that for two
reasons: criticising the what a user uses is implied criticism of the user
and this is not very friendly and as Chuq has pointed out may cause them to
leave; more importantly, however, the big mail services are interested in
having as good a relationship with list-servers as well. They like bounces
as much as we do so they are really happy the fewer they get. Talking to
the admins can be surprisingly helpful. I've got a list with a huge bias
towards hotmail and will be talking to them about working together as well
as possible. I'll post any useful response.
You could have searched the archive.
David Gibbs wrote:
> I'm sorry, I've lost track of patches.
> Things are crazy around here ... got code freeze at work in about 2
> weeks and we just found a major problem :(
> Can you refresh my memory?
> At 06:02 PM 2/27/2003, you wrote:
>> Have you tried my latest patch ?
>> You should make sure that patched version is properly installed
>> and restart mailmanctl.
>> David Gibbs wrote:
>>> "Tokio Kikuchi" <tkikuchi(a)is.kochi-u.ac.jp> wrote in message
>>>> Use of Latin-1 character in english list is a different matter.
>>>> If the subscribers use these character in your list, then see
>>> I don't think that the character set relates to how the subject is being
>>> wrapped ... look at this thread ... there are a bunch of TAB
>>> characters in
>>> the text that (IMHO) shouldn't be there.
>> Mailman-Developers mailing list
> | Internet: david(a)midrange.com
> | WWW: http://david.fallingrock.net
> | AIM: MidrangeMan
> | We're not in the middle of nowhere...
> | we're on the outskirts of everywhere!
> | - DMRoth (adapted)
I've noticed some odd behavior in the latest CVS that I updated to ... the
subject line is being treated as if it's blank.
Here's an example of a message that was processed by one of my lists ...
> Content-Type: text/plain; charset="US-ASCII"
> X-Content-Filtered-By: Mailman/MimeDel 2.1+
> Re: V4R4 to V5R1 upgrade [was Re: Off-topic, and not sorry one iota]
> X-BeenThere: midrange-l(a)midrange.com
> X-Mailman-Version: 2.1+
> Precedence: list
Notice that the subject is on a seperate line.
This list does NOT have a prefix configured.
I've started a mailing list, ng-arch, for design and development of a
better mail archiving system. To subscribe go to:
It would be nice if this new archiver's implementation can be suitable
for inclusion with Mailman 2.2 (and can be implemented in time), but
if that's not possible it might be a standalone project.
BASSANIO: The world is still deceived with ornament.
-- _The Merchant of Venice_, III, ii