Hi,

It is an emergency mailing list that only gets used in a major emergency, 19000 subscribers. We dont really care who subscribes but we dont want "important" ppl un-subscribing and then complaining they didnt get teh emergency email down the track.

regards

Steven ________________________________________ From: Mailman-Users mailman-users-bounces+steven.jones=vuw.ac.nz@python.org on behalf of Keith Bierman khbkhb@gmail.com Sent: Tuesday, 8 December 2015 10:47 a.m. To: Mark Sapiro Cc: mailman-users@python.org Subject: Re: [Mailman-Users] feature request

Probably betrays my ignorance of the OP's needs, but I'd have thought:

1. tracking who joins is more interesting than those leaving
2. client side filtering (including automated discarding) allows the

administrators to save their sanity ...

So I find the described request slightly surprising. Kudos to Mark for not pushing back on this basis ... but perhaps the OP can provide a little more context for why this would be a generally GoodThing.

Keith Bierman khbkhb@gmail.com kbiermank AIM 303 997 2749

On Mon, Dec 7, 2015 at 2:31 PM, Mark Sapiro mark@msapiro.net wrote:

On 12/06/2015 06:06 PM, Steven Jones wrote:

...

"Should administrator get notices of subscribes and unsubscribes? "

Would it be possible to split these as our list admins would like to see

unsubscribes but not subscribes.

There are no plans to implement such a split in official MM 2.1 releases, but if you wanted to implement it, it could be simple depending on what you wanted to do.

I.e. if you just wanted to modify the code so that admin_notify_mchanges meant "unsubscribes only", you could just find the two lines

    if admin_notif is None:
        admin_notif = self.admin_notify_mchanges

about 20 lines below the start of the definition of ApprovedAddMember in Mailman/MailList.py and delete them.

Actually splitting the switches into admin_notify_subscribes and admin_notify_unsubscribes is more complicated and involves changes to multiple modules.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

---

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/khbkhb%40gmail.com

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/steven.jones%40vuw.ac....

Keith Bierman writes:

Probably betrays my ignorance of the OP's needs, but I'd have thought:

1. tracking who joins is more interesting than those leaving

That depends. In many organizational settings monitoring certain channels is part of the job of certain people. And of course there's the "emergency list" use case mentioned by Steven.

2. client side filtering (including automated discarding) allows the

administrators to save their sanity ...

Some people just don't get it, though, and they're sometimes very competent in their own areas, too. And some filtering is just plain hard. Eg, I have a couple of committee chairs who think it is a good idea to emphasize the importance of college-level list traffic related to their committee work, that comes on lists we're all subscribed to, by forwarding them to everybody in the department -- I'd like to spambucket them based on list serial numbers, but sometimes there is actual content in the forward (especially dangerous is the occasional gloss like "this means you, Prof. Turnbull" -- since these messages are written in Japanese, that's actually more helpful than annoying :-).