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

[Michael Paoli]

Thanks Rick!  :-)

I (over?-)tweaked the mailman list page - it's got just about nothing
on it except bit to unsubscribe or edit options.  Could alternatively
put it mostly to default, and just strip out the bits about subscribe
and post ... but practically, don't know if it makes all that much
difference.  Folks(/bots) could still subscribe via email.

I did turn off the requiring approval to subscribe to that list;
but I'm (at least presently) the only listadmin on that list - so
I might just only annoy myself if it's set to also require approval.
... maybe I ought set the "emergency moderation"?, so nothing gets
posted without held post being approved?  That could be less annoying,
as (with appropriate setting) I approve it then does time out such
held for moderation items.  Could also put relevant text on web page,
etc., so it's clear postings to mailman list itself won't be approved.

Also, the "not advertised" - seems to work or mostly work.
The only (maybe?) exception I see is if mail is sent to
the mailman list with the command list - it does include
itself in the list - but if one's emailing it anyway, maybe
kind'a pointless for it to not show itself?  But if list command is
sent to balug-test-request, it no longer lists the mailman list - so
that looks good (and ditto for main web link that summarizes all the
"public" lists).  Also set list archive for mailman list itself to
private - probably doesn't particularly matter - but hey, prevent it
from being some cracker/spammer's free publicly accessible web storage
archive, so that might (slightly) reduce potential abuse.

BALUG-Test now has a relatively complete description on its web page.
I did tweak the tag from [balug-test] to [BALUG-Test] - notably to be
consistent with everything else including existing lists ... but yes,
[Balug-test] was just plain wrong (and what mailman did by default).
On the mailman list, it set it to [Mailman] - but I'm leaving that one
as the list ought be about zilch usage as an actual "list", and, for
anyone that actually uses it more-or-less as such ... principle of
least surprise 'n all that, as [Mailman] is mailman's default,
and since I/we don't particularly care much what the tag looks like
on *that* list - leaving it as the default.

Anyway, pretty darn close to officially "announcing" the BALUG-Test
list, as it seems to be working mostly pretty dang well (and better than
DreamHost.com!).  I think I just need tweak some of the mailman text - at
least for now - so folks don't - at least based upon the text sent from
this mailman installation - expect that command in Subject: header with
blank body will work (heck, they can make it as most simple work-around
by including "end" in the body).  I think that's "quite close enough"
for now, and "good enough" to go forward - with (pending) those adjustments to
the text that gets sent.

> From: "Rick Moen" <rick@linuxmafia.com>
> Subject: Re: [BALUG-Admin] BALUG lists ... mailman list(?!), blank  
> body with command in Subject: header
> Date: Sat, 15 Jul 2017 22:11:05 -0700

> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
>
>> 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 actually was meaning to talk to you about this matter.  You'll notice
> http://linuxmafia.com/mailman/listinfo
> and
> http://lists.svlug.org/lists/listinfo
>
> both have mailing list 'Mailman' set as 'Advertise this list when people
> ask what lists are on this machine?' = no.  I don't think there's
> actually any functionality advantage to requiring listadmin approval,
> because nobody can actually do anything as a member of that list.  The
> downside of your setting 'Confirm and approve', there, is that _if_ some
> numbnuts attempts to subscribe, that request will land in the admin
> queue, and you and I will continue to be pestered about whether to
> approve it or not.  Unlike held _mail_, held subscribe requests never
> expire out of queue:  There is no 'discard held subscribe requests after
> N days' configuration item.
>
> So, I really do think setting 'Confirm and approve' on mailing list
> Mailman is an actively bad idea, and think you should revert that.
>
> You're certainly right that any _advertised_ Mailman list will get
> subscriptions, no matter how nonsensical that idea is for a particular
> mailing list.  Consider, for example
> http://lists.svlug.org/lists/listinfo/speakers .
> As it says on the listinfo page, that is an explicitly read-only archive
> of a _formerly_ active mailing list, so it's flat crazy to try to
> subscribe to it.