[sf-lug] spam vs. anti-spam

[Michael Paoli]

spam vs. anti-spam ...
Ah, the war continues.  :-/
Will probably always be a war of escalation - at least into the
foreseeable future.  (And don't even get me started about
unsolicited scam/crud phone calls ... now well over 80% of my incoming
phone calls ... can we go back to the "good old days" when international
phone calls cost about the price of a sandwich for the first 3 minutes,
and another quarter sandwich for each minute thereafter?  How 'bout also
the price of a piece of Bazooka bubblegum wrapped with its comic or more per
minute for all non-local calls?  I want a sizable financial disincentive
against those scammers & such.  But I digress.)

So ... recently ...
http://linuxmafia.com/pipermail/sf-lug/2021q2/015255.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015257.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015258.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015259.html
Did have some "discussions" regarding spam, and anti-spam, and
MTAs and lists, and listadmin email address(es), etc.

And, yeah, rather recently, did fair bit 'o cleanup, etc. on
some relatively crusty older configurations ... though the core software
had been quite kept up, the configurations were no longer up-to-snuff,
nor were they particularly manageable/maintainable ... so ...
spent a fair bit 'o time improving that and getting it (much) more
current and up-to-snuff.  Still lots (or at least quite a bit) more
to do ... but now in considerably better shape.
And ... covered most of that else-list(s):
https://lists.balug.org/pipermail/balug-admin/2021-April/001047.html
https://lists.balug.org/pipermail/balug-admin/2021-April/001048.html
https://lists.balug.org/pipermail/balug-admin/2021-April/001049.html
https://lists.balug.org/pipermail/balug-admin/2021-April/001050.html
https://lists.balug.org/pipermail/balug-admin/2021-April/001051.html
Also quite a bit on wiki:
https://www.wiki.balug.org/wiki/doku.php?id=system:annoyances
And spammers abusing the BALUG VM is a problem that goes way back,
even many years ago, they had bots using the wiki registration form ...
because it generates an email.  Spammers and their bots love to use any
email or web means that can generate/forward/relay an email, most notably
if they can control most any content of it - even if it's only some tiny
bit - they don't care.  So, e.g., a lots of web registration stuff -
wiki, WordPress ... locked down 'cause - well, spammers and their bots.
Heck, at one point in time many years ago, the spambots were putting such
a load on the host's web server that it would lock the host up solid.
Took a bit of digging to get to the bottom of that (and some
reconfiguration and tuning to cut the problem off).
Captcha?  Only slightly useful - AI is already starting to outpace the
humans on much of that - so spammers will soon win that war too.
I've, over the years from various spambot goings on - even if they
couldn't manage to send anything - doesn't mean they didn't try - have
done large purges of spambot/badbot (there are bots that also spamvertise
by posting to wikis and blogs and the like) "user" registrations on both
wiki and WordPress ... though both seem pretty under control on that now
and have been for years or more now (may not be down to zero ... but ...
manageable trickle).

Anyway, still lots more to do - including some items Rick has also pointed
out.  So, yeah listadmin email - though legitimate, received
non-locally ... and even telling the relevant systems, no, this email isn't
spam - over and over, some of 'em just don't get it ... so that also
probably doesn't help.

There's also stuff I still want to do/complete to keep down listadmin
(notably me) annoyance factor.  E.g. all the list posting attempts from
those not authorized to post to list - almost always not even member of
list - but even if they are (like almost never), they've got
moderator flag set - e.g. BALUG-Announce - as most can't post to that
list (low volume list - max of 3 posting per month).  So, just the other
night ... did up bit 'o software to automagically get the relevant
information from Mailman - notably to test if a sender is authorized to
post to list or not - and if so just outright hard fail it, rather than
toss it in listadmin's queue to review.  Mostly got that working as I
wanted ... but not quite.  Mailman uses aliases, to pipe the mail to
Mailman.  Thought I'd adjust the pipe to have that filter built-in.  Bit
easier to implement that way anyway.  Well ... that sort'a kind'a mostly
works.  That stops the mail in its tracks ... but unfortunately it still
doesn't cut it off at SMTP time.  I want to be able to reject based upon
sender and RCPT TO: - no need to go past that if it's a bad match ...
that might also get the spammer's bots to not try so hard if they're
mostly all gonna fail anyway.  Anyway, should be able to work that into
bit more upstream in the processing, and hard reject at SMTP time (and
with suitable diagnostic codes and message text).
There's also lots of cruft failing in logs from spammer attempts.  I want
to get that fed into fail2ban ... not there yet.  The fail2ban rules come with
stuff for MTA, but much of the default configurations for those and the
MTA logging - there's significant mismatch - notably in some key formatting
bits.  So I probably want to well fix that ... and maybe even more notably,
add some of my own filter/ban bits to that too - as the failures I'm getting
may not be that close to matching the existing rules anyway.  Might also end
up with some to add as I add customization for more MTA filter rejecting,
e.g. anyone attempting to post to list that's not authorized to do so.
Yeah, lots more I could work to feed into fail2ban - that would also keep
the log and noise level down.  Heck, it was literally the noise that first
got me to use fail2ban ... my otherwise fairly quiet computer would
buzz with hard drive activity logging all the failed ssh attempts - the
noise was annoying ... fail2ban quieted that right down.
So, yeah, stuff to add ... my current quick analysis reporting - which
covers about 3 days of various failures:
# Rejectlog_report
6334 Unrouteable address
38 relay not permitted
26 SMTP protocol synchronization error (input sent without waiting for  
greeting)
12 SPF check failed
5 missing or malformed local part
4 maximum allowed line length
3 too many syntax or protocol errors
#
Yeah, that top one ought make it through to fail2ban ... and maybe a few
more or so too ... or at least if they ever show up in non-trivial numbers
of attempts.