[BALUG-Admin] BALUG lists ... mailman list(?!), blank body with command in Subject: header

[Michael Paoli]

mailman list - I don't fully grok why, but ... with the Debian
install of mailman, it instructs one to create a list named mailman,
which I dutifully did so.  I'm guestimating removing such a list
may be a *bad idea* - so I've no intention of doing so unless I
knew quite certainly there was no specific downside on that (including
even any specific ways Debian might happen to use such list).
However, seems a bit odd - and potentially problematic(/annoying)
to have it shown among the "advertised" lists,
so, I changed the setting on that list to:
Advertise this list when people ask what lists are on this machine?  No
That prevents it from showing in:
https://temp.balug.org/cgi-bin/mailman/listinfo
I also changed setting to:
What steps are required for subscription?  Confirm and approve
Thinkin' folks really ought not be subscribed to that list,
and adding approval requirement may help prevent unintended
subscriptions to that list.
I'm guestimating primary reason such list is created, is to have
standard localpart addresses that can be used for mailman requests,
e.g. user can send an email with body of:
help
to: mailman-request@
and get the basic help information,
they could also send the command:
lists
and they would get a listing of - I presume - the "advertised"
lists (help text says "public mailing lists" - I'm presuming
synonymous descriptors).
So ... I suppose folks (and admins) might expect the various
mailman-{request,admin,...} email addresses to exit.
As for mailman@ itself?  Default behavior would be to post to
the list - that might not be so useful - but might also
satisfy the rule of least astonishment (even if it doesn't
successfully post - e.g. sender not subscribed).
Could maybe just have that be alias to go to list / (mailman) site admins,
but that may be more work/annoyance for the admins than optimal,
and may also violate rule of least astonishment.

blank body (with command(s) in Subject: header)
This one isn't so trivial to "fix" for mailman, while leaving the
appropriate bits in place for the generally desired anti-spam.
I'm leaning towards deprioritizing fixing that, and just giving suitable
information about putting command(s) in email body - could put that in
the information going out, web page(s) as relevant, and tweak (add to)
the mailman text it sends, so that's reasonably clear.
As for attempting proper fix on that ... in eximconfig,
there's rule that rejects empty body.  It even has a part to allow
if a recipient address includes (case insensitive) the string
unsubscribe.  I did even adjust that to match other mailman list
addresses (but not list posting address) ... that "worked" - for
certain definitions of worked - made it past that rule okay,
but alas, then immediately failed on a similar subsequent rule that has
no provisions in it for exception by recipient (it's in collection of
general body reject rules).  The latter rule, effectively saying, after we
strip out images and the like, if our net resultant body is empty/blank,
reject it (e.g. it's likely image spam).  So ... sounds in general like a
good rule to have and keep ... but ... to selectively allow exception,
adding that, not so trivial (I do grok regular expressions ... but alas,
not python yet).  Actually, ideally, for list addresses that would generally
take commands, if body is blank (or blank after stripping images and such),
if Subject: header is also empty - still ought reject it as spam - but allow
it if the Subject: header isn't empty.  Anyway, I'm inclined to mostly
deprioritize a more proper fix of that (hopefully come back to it later),
and move along with other relevant bits (which are generally coming along
quite nicely).