On Wed, Aug 09, 2006 at 10:29:52PM -0500, Robert J. Hantson wrote:
So with all this talk of Blacklists... does anyone have any suggestions that would be helpful to curb the onslaught of email, without being an adminidictator?
Yes. First, run a quality MTA -- that *requires* an open-source MTA that is subject to ongoing, frequent, and strenuous peer review. I recommend one of {postfix, sendmail, exim, courier}. I recommend against qmail. Second, use the built-in capabilities of that MTA to block SMTP traffic from misbehaving mail servers. Examples: (1) Use the greet_pause (sendmail) or equivalent feature. (2) enable checks for forward and reverse DNS existence. (3) enable checks for HELO/EHLO (only to see if it's a FQDN, not to see if it matches connecting host). (4) use postgrey (or equivalent) with whitelisting of hosts that are "known" to you. And so on -- each MTA has a myriad of features that boil down to "reject mail from misbehaving hosts" and those features can be used to reject an awful lot of spam. (Yes, these measures will also occasionally reject mail from hosts which are either running highly broken software or which are badly misconfigured. This is a feature, not a bug, and the onus is on the operators of those hosts to bring them into compliance with Internet standards, both codified and de facto.) Third, Put in the Spamhaus DROP list on your border routers/firewalls. There is no reason to accept ANY network traffic, nor send any network traffic to, any network on that list. Nothing good can come of it -- for you, that is. Update once a month. Fourth, use a judicious selection of DNSBLs/RHSBLs (to do outright rejection). I use and recommend: Spamhaus XBL (which is the XBL+CBL combined zone). NJABL DSBL TQMcube zone: dhcp SORBS zones: http, socks, misc, smtp, web, zombie, dul AHBL I've never had a FP from the first three over many years of use. I've had a handful of scattered FPs from the second three, but each has been quickly addressed by the zone's maintainers -- and about half of those weren't their fault anyway, but they still fixed the problem. Fifth, if you don't need to accept mail from certain countries: don't. Many people (including me) refuse all mail from Korean and Chinese IP space because *at their site* it's 100.00% spam. TQMcube provides DNSBls for that, as do others. (Conversely, if you happen to be in either of those countries, you may find that 100.00% of your incoming traffic from the US is spam...in which case you should consider blocking all US IP space.) Sixth, consider a combination of AV/AS measures. One such combination might be ClamAV and SpamAssassin; another might use those two glued together with Amavis-new. But: it's not worth doing this until you've done all the other stuff, because otherwise you will burden these (relatively) computationally-intensive programs with traffic that you could -- and should -- have already rejected near the beginning of the SMTP transaction. If you use SpamAssassin, you can also use various DNSBLs as part of weighted scoring. This is a fallback if you're not comfortable using them to do outright rejection. Seventh, do not use SMTP callbacks -- they are abusive and readily lend themselves to DDoS attacks. They're also pointless and stupid. Don't bother using DomainKeys/SPF/whatever -- these technologies were failures from the beginning despite grandiose promises ("Spam as a technical problem is solved by SPF"). And do everything possible to make sure you don't emit outscatter (aka backscatter): reject during the SMTP conversation, don't accept-then-bounce. Eighth, get on the mailing lists that discuss this, like Spam-L, spam-research, spam-tools, spambayes, etc. NANOG really isn't the best place for this conversation. Finally, and perhaps most importantly: don't be a source of spam or a supporter of it (by providing HTTP, DNS or other services to spammers). Make sure you have a working, unblocked "abuse" address, read it, and act on what you receive there promptly - by immediately and permanently revoking all services that you're providing to spammers. Make sure that you have a TOS/AUP in place that allows you to shut them down without prior notice -- i.e. the only warning they get is the one in the TOS/AUP when they sign it. Add a clause that allows you to confiscate their data/equipment -- this will deter a *lot* of spammers from even trying to sign up with you, which in turn will greatly diminish the risk to your network and the amount of work you may have to do later. (The only reason any network has persistent/systemic issues with spam (as opposed to sporadic/isolated issues, which can happen to anyone) is that its operators are (1) lazy (2) stupid (3) incompetent (4) greedy. There are no exceptions. There are also no excuses.) ---Rsk