On Thu, 1 Dec 2022 23:20:09 -0500
"Stewart C. Russell via talk" <[email protected]> wrote:
> On 01/12/2022 02.30, ac via talk wrote:
> > 
> > When "directors" or "boards" or "leaders" make decisions on policy
> > it affects operations. Always. and many times it is "politics" and
> > ...  
> 
> Note that in our case, GTALUG directors are very close to the users. 
> Generally, the services we have are the ones the users were
> interested in. I've been on the board twice, I've seen all the little
> cogwheels turning ...
> 
this is good news, nut it seems that, as a group, we do not have
actual policy rules regarding incoming email relay?

I am willing to work with any other admins or by myself to harden and
configure or re-configure any of the scripts any other admin has added
to the vps [email protected] - and I can setup rules for the 
smtp server - so that it could function the way the group/board specifies. 

I could also setup wordpress, harden etc - but again - rules will be
needed - plugins/theme additions etc. etc. and add any of the other
services the group requires.

At the AGM may someone also discuss the option that the services could
be split? - it does not have to be all @google, we can re-configure the
gandi zone to utilise the best of everything?

Regarding even mailing lists @google - I do not see any technical issues, 
but I do see rules/policy issues/problems - @google there will be other
issues, for example for myself @ a dot me domain name, which relay
frequently either disappears or ends up in spam boxes, and other issues
for people with no main @gmail.com accounts, etc.

So the policy or user group rules should deal with the actual issues
for example if any user relays from @google (or any hacked/abusive smtp
server) and that server is listed as drop on abc/xyz/what? rbl as DROP,
then what are the rules? 

Should our server simply whitelist the affected smtp server? or
should the server bounce the email (as it is probably setup to do now)
(or should the email simply be deleted and disappear (which our server
could also be setup to do...)

> > ... then you need more automation/scripts - seriously, it cannot
> > take that much of your time  
> 
> Part of the problem is that a whole bunch of GTALUG services are held 
> together by legacy scripts. Which the maintainer has moved on from. 

Uhm, okay, but we all (all system admins) have our own scripts that
also work on mailman... soo, I am still not getting the issue(s)?
(and we can all read conf files, and read any scripts/code and either
edit/replace/whatever as required)

> Which the new operator may not understand, or even know they are
> there. We may have lost the documentation (though it's probably in
> the GTALUG github, somewhere - most likely last edited by Chris). So
> more automations will solve some problems and create new ones too.

unless the scripts are compiled and there is no source, (in which
case the new/other/any admin will just add their own)  I do not
understand how an admin would not know/find/edit any of these legacy
scripts?

> You also can't automate moderation in any useful way
> 
on the smtp side additional scripts could reduce incoming trash, which
will reduce high end admin load, there are also some additional changes
that could be made to reduce/automate some of the admin.

and there is no shortage of additional high level admin volunteers, as
Erica has demonstrated?

Just a thought about docs though, maybe we can make another rule that 
everything must be documented, exactly so that anyone can easily do 
whatever they need to do, so if there are/were/is no current proper
doc, this itself can also easily be fixed) - in fact this should probably be
done anyway, no matter if we end up at @linode or @google or at a mix of both

> There are no 'clock' problems: everything here is a 'cloud' (to 
> appropriate Karl Popper's concept of defined, soluble problems vs 
> indeterminate, insoluble ones). The board is burned out. It's good
> that folks are stepping up, but it might not be enough.
> 
email spam @google or @microsoft or @most_places have been mostly
stopped and in 2022 there is still some spam, but it is not a problem
at most providers.

Sure, something still leaks through when trusted users own accounts are 
compromised, but in general, there are no more real issues with spam... 
and there are so many reasonably accurate real time services - so filtering 
incoming relay is not an insoluble problem, it does just need rules though.

so, advice for a burned out board: Improve settings by adding,
following and accepting rules, then, get/involve more high level admins
and add more software to reduce high end admin load

I guess ymmv but with a little tolerance - if your @google server does 
not seem to be able to deliver to @gtalug - and/or correctly
asking/blaming your @google provider,  OR making user group rules stating
that @google (or anyone) is to be whitelisted if their servers are
abusive and they also expect to relay email or/and a whitelisting web
interface (10 minutes) to whitelist the abusive @google server so that
your emergent post to the list can be immediately accepted, etc.

of course if the wolf now does watches the sheep and the lists move to
@google - the @google problem goes away anyway but there will arise
other problems.

> Thanks, Evan, for your thoughtful answers. Whatever system we end up 
> using must have public, web-accessible archives, as anything locked 
> behind a user login is not a useful resource.
> 
+1 

Andre
---
Post to this mailing list [email protected]
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Reply via email to