Quoting Timothy D Thatcher (daniel.thatc...@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. _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech