[sf-lug] spam vs. anti-spam

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> 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

Since you mention that, I'll comment what I'd been thinking about a
view you've expressed several times including in the last of those posts
linked above:

[EximConfig:]

> Yep, once-upon-a-time.  But alas, that time is gone.
> Might still possible "mine" it for anti-spam ideas in general,
> though ... and carefully pick and choose from that - along with
> considerations of modern, best practices, etc.

I respect your views on this, because you've worked through this stuff
more recently, and, well, unlike many who mouth off, have actually done
the work.  Also, I don't have recent experience doing effective antispam
with main-alternative MTAs such as Postfix, either.

That being said...

You grumble recurringly about the EximConfig bundle of antispam
enhancements/extensions and canned rulesets including some number of
rules that turn out to be overzealous or misconceived, the classic
example being one bundled Exim rule that autorejects any mail arriving
with completely null body text -- which is an unwise antispam heuristic
because there are several legitimate and necessary use-cases for mails
lacking body text.  OK, good example.  Years ago, when I tried out the
EximConfig bundle on a Debian Exim4 setup running my server, I soon
found that rule, considered it annoying and a bit dumb, regretting its
role in briefly shooting my system in the foot, commented out the rule's
line somewhere under /etc/exim4, regenerated exim4.conf using the handy
system script for that purpose, restarted the MTA, and composed a
slightly curt mail to J.P. Boggis, the EximConfig maintainer, saying why
that rule was dumb and ought to be at least disabled by default if not
terminated with extreme prejudice.

And I believe I likewise found four or five others (can't recall
details) and did likewise.  

But, as John Oliver would put it, 'The point is...' that even with
several overzealous rules that need to be hunted down and scotched, 
EximConfig was still in its day (and might be still?) far and away
the easiest and most effective way of building a good antispam system
without painfully architecting one from scratch over a year or two.

So, for example, EximConfig provides, right out of the box,
preconfigured automated callout functions that Exim4 is induced to make
during inbound SMTP connections, back to the connecting IP, to test the
remote MTA in real time (before accepting or rejecting the pending
delivery) to test its compliance with several RFCs all SMTP originating
systems are required to meet.  This is awesome because RFC-compliance is
an excellent antispam heuristic, _and_ the rule is superlightweight and 
fast/low-RAM because it's leveraging Exim4's front-end C code rather
than some perl monstrosity.

Last time I checked, no Linux distro, not even yet, preconfigures an MTA
with effective antispam.  AFAIK, all you get is an MTA that has been
verified to not be an open relay.  That's not _nothing_, i.e., you don't
start out life with every DNSBL on the planet hating you, but still
leaves you as (almost) roadkill on the Information Superhighway, wide
open to a merciless barrage of spam 24x7.  So, what is worse, an
enormously effective, cutting-edge bundle of antispam methods you can
drop right into Debian's Exim4 that is marred by a few dumb things you
must hunt down and shut off, or an MTA with effectively zero antispam?
Or is there a third alternative, now?  If so, what is it?

Or does the exim4-daemon-heavy or Postfix package for Debian _now_
include meaningful antispam that bears comparison with Debian Exim4
as enhanced by dropping EximConfig into it?  I ask because I'm seriously
not up to date on what's provided by default.


[The annoyance of comment spam on Web sits:]

> Captcha?  Only slightly useful 

What strikes me as likely _very_ effective is just asking a question
that any human can easily answer but is AI-resistant, and that is also
scripting-resistant unless some bad guy custom-scripts for each target
Web site.  Like:  "Please type the word that isn't the first word in
this sentence, but rather the next one after that".  Or "What do you get
if you subtract 1 from 5?"  This sort of CGI Q&A can be provided as
canned code but with the page adminstrator able to provide a custom,
per-site, question and answer.  

I'm pretty sucky at writing CGIs, or I'd have tried to make one, myself.

> 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). 

When Josef Grosch was running the Bay Area FreeBSD User Group mailing
lists (on Mailman), he at one point just set them all to autodiscard any
posting received from a non-subscribed address.  On the one hand, that's
breathtakingly effetive:  It makes the whole problem go away.  On the
other hand, it's a bit BOfHish of a solution, kind of 'I don't want to
even know about your accidental attempts to post from your alternate
address.  I just want the attempt to silently fail and you have no idea
why, because it's Your Problem Not Mine[tm]."  

That's one shiny set of sysadmin jackboots Josef was wearing -- but I
never quite had the nerve.  I prefer to be able to tell people about
their misstep, and have them not just be mystified.

Anyway, you certainly could do that Kill the Problem with Fire solution,
a la Joe Grosch.


> Mailman uses aliases, to pipe the mail to Mailman.

Does it?  I am guessing you're talking about some use of pipes that is
internal to Mailman -- as opposed to the old thing we all used to do in
the 1990s and early 2000s of relying on _MTA_ alias lines (like
/etc/aliases) that included shell piping.  

The latter was discovered around 20 years ago to be a serious security
liability, and pretty much every MTA including Debian Exim4 shut off
support for shell piping in MTA aliases -- with dire warnings in the
configs that you should think twice before re-enabling.  This caused a
lot of confusion at the time, for admins attempting to enable MTA "glue"
to tie in GNU Mailman to their MTAs, because standard recipes on the
Internet for doing that relied on the /etc/aliases shell-pipelining
technique.  You can still find those recipes, to this day.

Whatever you're talking about within Mailman, I sure hope it's better
architected than that /etc/aliases stuff we all used for a while, that
was left over from the Majordomo days.  _That_ stuff was a genuine
security nightmare.  OTOH, it was Bourne shell.  Maybe you're talking
about some more-careful use of pipes in Mailman's Python plumbing.