[Mailman-Users] compress full mbox files?

Back on November 18, 2001, Jackie Meese asked about gzipping the full mbox files in the mailman archive system: http://www.mail-archive.com/mailman-users@python.org/msg05253.htm There was no answer that I could see. Is there an answer? The uncompressed file is many megabytes on active lists.

[Mailman-Users] old request causes checkdbs failure in 2.1

I updated my site (red hat linux 6.2, i686) to mailman 2.1 and python 2.2.2. Unfortunately, I managed to create a request to the new `mailman' list during the upgrade which ended up in the old format, and is causing cron/checkdbs to fail (see below). At least that's what I gather from the couple

[Mailman-Users] sys.exit(0) causes no cgi output

Red Hat 7.2 (i686), apache 1.3.26, python 2.2.2, mailman 2.1.1 (also happened with 2.1). After applying the htdig patches, we found that calls to http://.../mailman/htdig/... got an internal server error (HTTP 500). (An example full url: http://tug.org/mailman/htdig/pdftex/2002-July/002843.html.)

[Mailman-Users] downloading private archives in batch?

Has anyone happened to have written a script to allow downloading the archives of a private mailman list offline (not in a browser)? That is, you give the mailman username/password on the command line, it does the mailman authentication over http[s], remembers the cookie, and gets you the full

[Mailman-Users] newsgroup-mailman moderation

Greetings, For gnu.org, we have always had gatewaying between Usenet and mailman for quite a few lists, e.g., help-gnu-emacs and bug-gnu-utils. When a message is gatewayed *from* Usenet to the mailing list, Mailman evidently omits any of the usual moderation features (generic_nonmember_action

[Mailman-Users] per-list email at munging?

I just set up some mailman lists for commit archives. I'd like to avoid the "@" -> " at " munging for them (at least in the bodies, though also in the headers is fine/expected), while retaining that minimal munging for the other lists on the server. Looking at HyperArch.py (and Defaults.py), it

[Mailman-Users] automatic decode of base64 text/plain

Some mailers annoyingly send text/plain parts in base64 encoding, making grep and all other standard tools ineffective. I wonder if it would be feasible for mailman to automatically decode such back into normal text, at least for the archives. Maybe also for sending out, though clearly that is

[Mailman-Users] template directives, prev/next period?

In the template files, e.g., templates/en/archidxhead.html and article.html, is there a %(...)s value that would link to the next/prev archive period? It would be nice for browsing. More generally, is there a reference list of the % values available? Sorry if this information is in the

[Mailman-Users] Re: subscription flood, redux

Thanks to everyone for the great replies. davidg> I have it setup, but it's not very sophisticated ... failregex = .*\/\s+-\s+-\s+\[.*\]\s+"POST\s+\/mailman\/subscribe It's just looking for repeated subscribe attempts. Thanks David! What are you using for maxretry, findtime,

[Mailman-Users] subscription flood, redux

I was just hit with a subscription flood, along the lines of https://mail.python.org/pipermail/mailman-users/2014-May/076880.html https://bugs.launchpad.net/mailman/+bug/1082746 I've mitigated the current attack, but it's happened before and will happen again. I'm already using

[Mailman-Users] Re: detecting pending subscriptions across many lists?

By list_requests, do you mean https://www.msapiro.net/scripts/list_requests? Yes. (Thank you again for all your helper scripts.) If so, just running it with no arguments will process all lists. Yes, that's probably the best way. It just takes a while with so many lists, so I was

[Mailman-Users] detecting pending subscriptions across many lists?

On lists.gnu.org, we have some 3300 mailman lists. Is there any way to know, or even probabilistically guess, which have pending subscriptions, short of running list_requests on every one? For pending messages, we can look for the presence of heldmsg-* files in the mailman data dir