And ... after the custom bits are no longer needed/present in the "General list information page" pages for each list (which is apparently stored in: /var/lib/mailman/lists/NAME_OF_LIST/en/listinfo.html ) - the custom bits coming instead from intro - An introductory description ... the custom /var/lib/mailman/lists/NAME_OF_LIST/en/listinfo.html files are no longer needed ... removed those, restart mailman and ... functions the same as if they were there ... even though they aren't. As far as I'm aware it defaults to using: /etc/mailman/en/listinfo.html which it apparently initially initializes from: /usr/share/mailman/en/listinfo.html ... only other additional change being it applies some HTMLizations / char set adjustments, going from: /usr/share/mailman/en/listinfo.html to: /var/lib/mailman/lists/NAME_OF_LIST/en/listinfo.html ... or, where the above doesn't actually exist, works as a virtual/phantom as if it were there (defaulting to using content based on: /etc/mailman/en/listinfo.html ). So, anyway, with that minor tweak, does leave things a bit simpler and (more "guaranteed") consistent.
I'd earlier put in per-list tweaks in: /var/lib/mailman/lists/balug-{announce,talk,admin}/en/listinfo.html (via the admin web GUI) when, after lists had been moved, but archives not yet moved and merged - older archives were still on DreamHost.com hosting - so had some custom information in there to provide that information and additionally links to the older archives. Since that's now all merged and moot, have done away with those unneeded customizations regarding two separate archive locations (current and older).
The other bits mentioned earlier regarding customizations around blank body anti-spam rejects work-arounds (notably tweaking instructions mailman gives to users, etc.) - those customizations are located in other files - and those remain - at least until I/we theoretically get around to fixing that particular false positive on the anti-spam SMTP rejection.
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: [BALUG-Admin] BALUG lists ... blank body with command in Subject: header, ... Date: Thu, 20 Jul 2017 07:43:38 -0700
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] BALUG lists ... blank body with command in Subject: header, ... subscriber options Date: Wed, 19 Jul 2017 23:55:03 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
So, bit of searching (find(1)) and such ... looks like those relevant texts are configurable under: /etc/mailman/en/....
Sure, if what you want to do is tweak the text. In some cases, you might want to edit the HTML of one of the stock Web pages associated with the list, specifically the
o General list information page o Subscribe results page o User specific options page o Welcome email text file
A listadmin of a Mailman mailing list can do so via the admin WebUI. I've sometimes found that useful and convenient.
Yes, well, from what I see of the files and such, looks like originally the files in /etc/mailman/en/ match those in /usr/share/mailman/en/ And looks like the bits editable in web GUI default to (after a restart of mailman) using those in /usr/share/mailman/en/ Also, however, since those GUI editable bits are per-list, appears if they're changed from their defaults (loaded from /etc/mailman/en/), then they're per-list saved in /var/lib/mailman/lists/name-of-list/en/ So, e.g., presently have these individual per-list ones: /var/lib/mailman/lists/mailman/en/listinfo.html /var/lib/mailman/lists/balug-test/en/listinfo.html but these: https://temp.balug.org/cgi-bin/mailman/edithtml/balug-test/subscribeack.txt https://temp.balug.org/cgi-bin/mailman/edithtml/balug-test/masthead.txt very nicely picked up from /etc/mailman/en/ covering *all* lists. :-) and I presume if they're edited in GUI, would be saved to: /var/lib/mailman/lists/balug-test/en/ (or the applicable lists's directory) ... at present, the balug-test and mailman lists don't have per-list files for masthead.txt and subscribeack.txt in their applicable per-list directory, so they just use what's in /etc/mailman/en/ - which is fine :-) - since I edited the files there. FYI, these were the files in /etc/mailman/en/ I tweaked the text of: convert.txt disabled.txt help.txt invite.txt masthead.txt newlist.txt subscribeack.txt unsub.txt userpass.txt verify.txt Essentially I reviewed all the file in that directory that contained the string subject (regardless of text), and edited those that needed their instructions tweaked so it would be reasonably clear that command in subject with blank body wasn't going to make it past the present anti-spam configuration.
Or another way to put it, precedence: /var/lib/mailman/lists/name-of-list/en/ /etc/mailman/en/ The last of which would seem to originally be copied from: /usr/share/mailman/en/ And per FHS, etc., the above typically wouldn't be editable (/usr filesystem may be mounted read-only - and on most of my hosts it is, likewise /boot, and I also add the hooks into apt so apt actions (e.g. installs/updates) remount /usr and /boot rw, and after, attempt to remount them ro (but treat as non-fatal error if the remount to ro fails - often it will fail, especially on /usr, due to unlinked open files - notably older libraries/binaries that were unlinked but are still open by running program(s); debian-goodies package also has the handy checkrestart(1) to help track down such running programs still using unlinked files - handy for, e.g. finding and restarting them to close vulnerabilities, typically without need to reboot host)). I also notice in /usr/share/mailman/en/ that as mailman runs as list:list, it has permissions to read, but not write, those files (even if/when /usr is mounted rw).
I suppose too, I ought set up some user in group (or with access to group) list, so that many of the list related commands can be run fine with less-than-root privileges - a not otherwise privileged user but also in group list would seem optimal - as group list seems to have the permissions to do the needed, but would generally lack permissions to muck with stuff it ought not (e.g. files owned by list by not writable by group list). At least on Debian, of what I've seen so far, looks like all the normally needed actions to manage mailman lists, are controlled/accessed via the list group.