Duplicate Posts - Burst Posts...

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Thu Jun 17 17:56:48 2004

It was thus said that the Great der Mouse once stated:
>
> > Most ISPs seem to be drowning in a sea of spam these days and
> > completely overloaded - at least they are over here.
>
> I've always wondered, when I see such things. I can easily name a
> half-dozen simple technical measures that will _drastically_ cut the
> incoming spam load to a mailserver. They're all fairly well known,
> even. Yet ISPs refuse to implement them, usually citing the "but it
> might refuse legitimate mail!" mantra, apparently preferring to lose
> legitimate mail randomly and silently to overload than to lose
> legitimate mail obviously and controlledly to filters, a mindset I just
> don't get - especially since the "legitimate" mail that will be lost is
> all defective to at least some extent already (because such defects are
> what the filters test for).

  Well, a large web hosting company here in Boca Raton, Florida (where my
girlfriend works as tech support) put in some new anti-spam
measures---basically, if the reverse DNS doesn't exist, or it's in one of
the black lists (don't know which ones they use) the mail is rejected
outright. The switch over was last week.

  They're still backlogged with email support issues ("I'M LOOSING
MAIL!!!!!!! WHATS WRONG WITH YOU IDIOTS?!?!?! MY FRIEND ISN'T A SPAMMER!
AND YOU'RE REJECTING HIS/HER/ITS EMAIL!") to the point where *everybody* (up
to managers) are on the phones and answering email.

  Granted, they handle a tremendous amount of email (it's a huge facility,
hundreds of machines, thousands upon thousands of sites) so the strain of
the mail servers is incredible (they had to shut them down for 12 hours last
week, just to let things settle down).

  If I were running an ISP I might be hesitant to implement some of the
measures, simply due to support issues alone.

> A good example is sleep-before-banner. It kills an awful lot of
> ratware dead, is difficult at best for them to adapt to, and won't kill
> anyone who bothers to pay attention to the minimum timeouts specified
> in RFCs 1123 and 2821. I've seen it said that as little as 15 seconds
> is effective (I use 90).

  That, however, is a good idea. Might do that myself.

  -spc (Didn't hear of that one ... )
Received on Thu Jun 17 2004 - 17:56:48 BST