[vox-tech] Test/Upgrade

[Bill Broadley]

On 1/8/19 8:25 PM, Rick Moen wrote:
> 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.

I hear this line of thought, and am always puzzled by it.  My recipe is:
1) run a current OS with a current spam assassin, like the newest ubuntu LTS or
   newest debian stable.
2) run postfix and whatever glue you like (mail filter, amavis, and amavis-ng
   are popular)
3) use greylisting

That results in close to zero spam, at least for me.  The only thing to change
in the last decade is blocking the spam only domains like .click, .link, .party,
.review, .science, .top, .webcam, .xyz, .stream, and .ga.  Oh and I updated
greylisting to deal with IPv6.  Not many changes for a decade really.  I did of
course do an OS upgrade, every 5 years or so (last was 2016), haven't had to
rebuild anything from scratch in a decade or so, the mailserver "just worked"
each time.  The only mail problem I recall was one of the bind upgrades that was
incompatible with my configuration file for bind.  Of course email didn't work
without DNS.

For LUGOD usage I do wonder if clamav is worth it, are attachments really worth
the pain/memory/cost of running clamav?  There's quite a few alternatives to
sharing files via attachments these days.  Your IP reputation (that causes
non-delivery of email) can take a REAL hit if you forward a malicious
attachment.  Is it really worth having attachments if major mail services stop
accepting email from you?

> 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/

Heh, well using current software is much easier than engineering it from
scratch.  Last time I did this it was apt-get install postfix-dovecot, 1 apt-get
for amavis, and one postfix config line.  Once that worked I moved all the
tables into SQL.

Typically the defaults "just work", just need to specify things like MyNetwork
if you want hosts to be able to send outgoing email without a username/password.

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

Not sure what you get by throwing everything away and using some ancient guide.
 Mail servers these days are nearly turnkey.  "apt install postfix
amavisd-new-postfix" will get you (or suggest to you) very recent versions of
spamassassin, amavisd, clamav, postfix, SPF checking, etc.   Doesn't take much
glue to turn the above into a working mail server that will likely last with
minimal tuning for another decade.

I'd start recommend with something updated in 2018 instead of 2011 though.

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

Greylisting + current SA works wonders + sane postfix checks works wonders.
Keep in mind you can't just update the SA rules, you have to update SA itself
for the best protection.  Sure if you want to keep tuning SA supports training
on HAM and SPAM, but I've never bothered the spam is pretty rare as it is.

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

There are technical work around that are a pain in the ass.  But generally I
recommend avoiding .forward, aliases, and similar for mailing lists.  Seems fine
for admin at foo.com to human at bar.com.  I keep my forwards, users, domains, and
maildirs in mysql.  Supporting a new mail domain is just an sql insert statement.

Mailman + postfix can be configured to skip the /etc/aliases hack, that way you
don't end up with a computer program (mailman), and a human fighting over the
state of a single text file that's easy to corrupt with a single wrong character.

Sympa seems more functional, more enterprisey, but generally overkill for what I
know of the Lugod use cases.
> 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. 

Indeed, including at least partial support for automatically handling bounces,
the bane of running any mailing list.

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

Heh, yeah, overkill.  Generally I'd just use greylisting + SA to minimize the
crap and then forward them into a folder of whoever will look at the periodically.

Sieve can do things like:

if header :contains "To" "root at lugod.com" {
  fileinto "admin.root";
  redirect :copy "poor.soul at randomdomain.com";
}

A wee bit easier to read than the equivalent .procmailrc.  Quite a bit more
secure as well.  Postfix's default delivery agent understands sieve.  It also
integrates really well if you want to let people read their email over imap.  In
particular the delivery agent is aware of postfix and dovecot so the
caching/indexing is never out of date.  Combine that with maildir and you end up
with less disk I/O, less corruption, and many many less race conditions.

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

Wow, I'd think that would be pretty unpopular and unnecessary.   I'm not an
officer.  But for my work I do support an admins@ and help@ that's heavily used,
does forward, and has never had a problem.  The people behind those address have
changed quite a few times over the years, wouldn't want to annoy folks when they
leave just because someone got used to using a personal email instead of the
correct one.

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

I can see a man week to build it from scratch.  Or an hour ish to use existing
packages.  This is really simple stuff.  I suspect I have 20 lines are different
than the default, and that was for personal preferences, not just to get it
working.  If you pick something that's built already to handle SPF, greylisting,
virus checking, anti-spam, TLS, etc in a nice clear config file it's pretty
straight forward.

All of my anti-spam is in two configuration lines:

smtpd_recipient_restrictions = reject_unknown_sender_domain,
  reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks,
  permit_sasl_authenticated, reject_unauth_destination, check_client_access
  hash:/etc/postfix/rbl_override_whitelist, check_policy_service
  unix:private/policy-spf, check_policy_service inet:127.0.0.1:10023

The :10023 is the greylisting daemon.

And:
content_filter = smtp-amavis:[127.0.0.1]:10024

Which is amavis.   Amavis handles things like banned attachment types, max
attachment size, rewriting malicious html if you want, preventing link hiding,
how to talk to SA, quarantining email, how to talk to clamav, etc.  I took most
of the defaults, probably 5-10 lines are non-default and included total of 20
lines of config file I customized.

Heh, my newest amavis conf file was changed in 2013, the OS I'm running was
upgraded in 2016.

> Sorry to be the bearer of bad news.

I agree it's quite a bit of work, but there are much easier ways to do it.
Generally I find using newer software includes 100s if not 1000s of tiny little
details by default that help minimize resource utilization, makes mail servers
that talk to you happier, helps protect your IP reputation, and maximizes your
chances at delivery with popular services.

Seems like an hours worth of work from fresh OS, the correct DNS records, SSL
certs, and related.  The hard part that can take significant time is migrating
the old/broken stuff into a new wave of doing things.  Things like:
* mailbox -> maildir migrations
* .procmailrc -> sieve
* ugly /etc/aliases -> anything sane
* mailman archives -> whatever
* email delivery into ~/Mail with local account -> email delivery into maildir
  with no local user shell.
* accounts/username info to allow web based email reading

The above can easily take a week depending on how ugly it is.  But a nice clean
new mail server with great anti-spam is really easy these days.  It's the
backwards compatibility with something ugly that's hard.

Some examples of docs/guides.

1) simple postfix+SSL+dovecot:
https://help.ubuntu.com/lts/serverguide/postfix.html.en

I believe amavis is just an apt and a single config file line to add to the above.

An overkill guide including things much more than I do:
https://help.ubuntu.com/community/PostfixCompleteVirtualMailSystemHowto

The one I used back in 2008 or so (ubuntu hardy) was similar to this one:

https://www.howtoforge.com/tutorial/perfect-server-ubuntu-18.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig

Basically postfix, mysql, dovecot, amavids, SA, clamav, and mailman.  It's 3
pages, but includes a huge amount of what I don't use (apache, webmail, XMPP
server, ISPCONFIG, phpmyadmin, pear, pureftpd, quotas, vlogger, awstats,
jailkit, fail2ban, etc.)

Now my first mail server was in 1994 or so, and back then it was hard.  Probably
put a man week or two into that one.  Computers were WAY slower, the internet
much less useful for troubleshooting, google didn't exist.  Users mostly used a
mail/mailx at the command line or eudora.  Sendmail and it's config
files/language (M4) were PAINFUL to get working and even worse to debug.  Which
leads to one of my favorite stories:

  http://web.mit.edu/jemorris/humor/500-miles