[vox-tech] Test/Upgrade

[Rick Moen]

Quoting Timothy D Thatcher (daniel.thatcher at gmail.com):

> What happened was that I discovered earlier today that ClamAV had
> apparently been misbehaving and had tanked mail/listserv service
> entirely, and for a few days, it turned out. I also actually ran an
> apt update/upgrade and rebooted the server myself several hours ago,
> and indeed it brought the mail server roaring back to life... which is
> probably why you've been seeing all those messages suddenly, as it
> tries to process through the backlog. Sorry about the blast of
> mailer-daemon notices.
 How/where are you receiving them?
> 
> I'm still getting chunks of mail blasting in, myself, both daemon
> notices and junk. I installed clamAV (and spamassassin, too) a while
> ago when I was trying to clean up the mail server a bit.

I question would the utility and effectiveness of _ClamAV_ in the
use-case of the LUGOD MLM/MTA server.  I think that's solving the wrong
problem.  (I realise that you almost certainly inherited the problem.)
In the context of a LUG's officers, malware mail isn't a problem because
of the malware.  It's just funny-looking spam.  The problem really is
the spam.  So, use good antispam.  Which brings me to:

Architecting effective antispam for a modern mail server is an art form,
alas.  You can very easily set up an MTA on essentially any Linux
distro, but it'll default to basically no spam-rejection at all, and
improving on that gets punted to the local administrator.  Which sucks.

IMO, in architecting from scratch an effective spam defence, and finding
the right balance of false negatives vs. false positives, I've found
J.P. Boggis's 'EximConfig' tarball and accompanying documentation a good
starting place.  Unavoidably, it has started to suffer from lack of
maintenance, e.g., the software recommended for SPF checking is no
longer packaged, so one must do more work than when it was last revised 
around 2011.  http://www.jcdigita.com/eximconfig/

I recommend studying Boggis's tarball & docs irrespective of whether one
uses the exact platform he targeted (Exim4 MTA on Debian), because his
ideas can be adapted.

For the separate problem of 'existing production SMTP host has a
terrible spam problem', that's a harder nut to crack without migrating
to a better-architected replacement, and you have my sympathies.


> We have a pretty severe incoming spam problem, and particularly the
> way much of it is getting processed/procmailed out to me and other
> officers using gmail and similar services has actually been kind of a
> serious problem--and one that is going to need revisiting eventually.

Here, you're talking about /etc/aliases-based redirection, right?  In
other words, root@, sys@, typescript@, @devnull@, if@, demo@, pr@, and
webmaster@ ?  If so -- frankly -- here in 209, y'all need to give those up.

You've noticed, obviously, part of the reason:  Those aliases get
clobbered as collateral damage in the spam war, and have been
increasingly for about a decade and a half.  The temptation is to think
that you can keep making those feasible if only you make the MTA's
spam-rejection really, really exceptional, except that it'll never be
quite good enough.  The more spam you forward via aliases (either
/etc/alias entries or ~/.forward files), the more the receiving MTA
perceives your relaying host as a spamhaus, and punishes it, especially
receiving domians like gmail.com that do dynamic scoring of spamicity.

The other reason:  Those aliases inherently fall afould of anti-forgery
techniques (SPF, DMARC), and so, depending on the mail's sender domain,
are at grave risk of getting either rejected upon redelivery or
spamboxed.  This cannot realistically be fixed.  My current view is 
that /etc/alias or ~/.forward redirection is now suitable and reliable
only for intradomain purposes.

The other type of redirection (other than the /etc/alias and ~/.forward
one) is of course mailing list managers (MLMs) like Mailman and Sympa. 
These have the advantages that (1) they rewrite the SMTP envelope, hence
can be made to comply with anti-forgery techniques, and (2) they have
exactly the substantial built-in intelligent handling and filtering that
is missing from the other redirection types.   Someone might eventually
suggest converting root@, sys@, typescript@, etc. each to its own
Mailman mailing list.  Don't.  The manual administration and hassle
required will drive you batty.




> I'm up for suggestions on the next move.

1.  Cease using /etc/alias entries for cross-domain redirection.
(Yes, this is a painful step and an end to a cherished LUGOD tradition.)
Instead, list on http://www.lugod.org/contact/ the office-holders'
current direct, real, e-mail addresses.

2.  Next SMTP host rebuild, spend about a week working on a modern
antispam architecture for it, possibly with reference to Boggis's work.
Expect it to take real sysadmin work, not just package installation.

Sorry to be the bearer of bad news.