SORBS Contact

Thu Aug 10 14:03:42 UTC 2006

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