I'm no longer desperately short on sleep, but unfortunately I'm still time-constrained, so I'll have to abbreviate this more than I'd prefer.
*I* wrote:
I didn't change that (what you refer to as public name of the list) -- only the Subject header 'tag'. GNU Mailman's defaults evince a fetish for initial capitalisation that I find silly and am at some pains to correct.
That fetish for initial capitalisation includes General Options item 'The public name of this list (make case-changes only)' aka config item real_name. E.g., when I first created the conspire@linuxmafia.com mailing list, GNU Mailman defaulted its 'public name' to Conspire -- which I later corrected in General Options to conspire.
I have nothing against _mindful_, deliberate use of capital letters such as your idea of using 'BALUG-Test'. I just dislike the AOL-user-like mindless initial capital being used automatically.
You probably know what I mean about the AOL mindset: You find that johnsmith@aol.com keeps insisting that that form of his address is incorrect and that you should re-edit it to 'Johnsmith@aol.com'.
*I* wrote:
There's a great deal of dumb online arguing about Mailman's _traditional_ default of mailing each subscriber his/her subscription password on the first of each month. After much pondering, I think on balance it's A Good Thing for several reasons I won't get into unless you wish me to.
The dumbest objection is 'mailing passwords in plaintext is bad security', which misses Mailman pointedly advising users to never use a significant password for this role, and the fact that subscriber passwords otherwise can't do significant mischief.
Benefits of automailing each subscriber his/her subscriber password: 1. Reminds the user. Let's face it, subscribers don't keep (or cannot refind) the welcome message, and somehow the information never sinks in that they can have a reminder sent via the listinfo page. 2. Helps periodically revalidate the subscribed address, and let the listadmin know about subscribed addresses that have become permanently bad but haven't yet raised bounce score enough to disable delivery or unsubscribe.
For example, I run mailing list linuxcare-alumni for ex-employees of that long-vanished San Francisco firm. Because of bounced password-reminder mails, I get early notice of when longtime members are about to fall off because they've stopped using their longtime mail address but failed to update the subscription with their new one. I can then ask the assembled 'Hey, Andrew Scott's ascott@tuatha.org subscription has become invalid because he isn't accepting SMTP any more at that domain. Does anyone know his current address?'
You wrote:
Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies. (from_is_list) - looks like that's set to: No Do nothing special ... anyway, probably should reasonably do as existing lists - if that's not too broken; in any case, can review later.
DMARC has mailing list admins in a bind, because the readdressing that mailing lists perform upon redelivery to subscribers makes the 'From:' header of postings form DMARC-using domains appear to be forged (because it breaks DMARC validation). As mentioned, I did _not_ leave that set to 'Do nothing special'. I have it set to "Munge from'. This is on Privacy Options, Sender Options.
I'm guessing you mistakenly though I was referring to a confusingly similar configuration item on General Options that (AFAIK) does _unconditional_ munging of all postings irrespective of whether they are from DMARC domains. I do _not_ recommend the latter, as it spreads the damage from DMARC across _all_ postings, not just those that require it.
You wrote:
Send mail to poster when their posting is held for approval? (Edit respond_to_post_requests) ... debatable, not critical,
Explaining my view on this is going to require some background and exposition, so I'll return to it later.