[BALUG-Admin] Config settings (was: pre-announce / "soft" open) BALUG-Test list)

[Rick Moen]

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.