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

[Michael Paoli]

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.