[BALUG-Admin] BALUG lists ... blank body with command in Subject: header, ...

[Michael Paoli]

> 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.