Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] [RFC] implementing taRgrey

2009-07-07 by Adam Katz

Bob Friesenhahn wrote:
> If you are talking about CONNECTION_RATE_THROTTLE, then this is just 
> playing into the hands of someone who intends to cause DOS.  By making 
> the server more resistent to those who intend to send spam, you make 
> your mail server easier to block entirely, just like the kids who 
> punch all the buttons on the elevator as they step out the door.

Hrm, interesting; I thought that was per IP.

>>> It also assumes that the bots are implemented well and will sever
>>> slow connections.
>> Please refer to http://mailchannels.com/images/drop-off.png (also in
>> my last email), which uses Spamhaus data to prove that assumption.
>> More to the point, 500 seconds is enough time for the connection to be
>> severed, which is far less than the typical greylisting delay time.
> 
> This chart only summarizes current behavior.  It does not prove 
> anything.  If many mail servers start to slow the connections, then 
> the sbambots will respond by extending the allowed connection times. 
> Spammers have more resources available than you do.

Right, it doesn't predict the future.  All it does is sum up the past.
 It's probably a safe assumption that the future will have smarter
bots, and smarter should in this case refer to aborting more readily
(time is money).

Allow me to apply your exact argument to greylisting:  "If many mail
servers start to greylist, then the spambots will respond by
implementing reconnection attempts."  Yet here you are on a
greylisting mailing list.

Spam fighting is an arms race.  When new tricks come about on either
side, the other side compensates.  That's just how it works.

The nice thing about greylisting and tarpitting is that they create
mandatory delays, which means that the number of spams a zombie can
blast out is drastically reduced.  It means that honeynets and other
indices can use this delay to do their work and publish their data in
time for the real-world recipients.

Other tricks like improperly faked email browser identification can
easily be fixed by attentive spambot programmers, but that just isn't
the case.  Most spammers aren't thorough enough to do it, and the
spammers' tools don't propagate from writers to users very
efficiently, so this is a race that we can (and do) consistently win.

My favorite example of an easily defeated anti-spam measure is
nolisting, as it's trivial to set up (it's just two DNS entries; no
software needed) and far safer to deploy than greylisting.  Spammers
don't evade uncommon techniques like nolisting and greylisting until
they are common, which arguably won't happen for either.

Fighting tarpits is quite nontrivial given its required sacrifice in
volume (since spam's profitability is something like one in a few
million emails, volume is EVERYTHING).  Tarpitting and greylisting
imply good protection which implies savvy users; even if you get
through whatever further spam-fighting measures remain, the users
aren't as likely to be suckers, so it's better to search for suckers
elsewhere.  The best target for spam is the non-technical end-user of
webmail or ISP-provided mail.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.