|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Bill Cole (postfixlists-070913
billmail.scconsult.com)
Date: Mon Jan 07 2008 - 09:00:32 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 2:51 PM +0100 1/7/08, Bernhard Reiter wrote:
>There is a method proposed to reduce spam:
>Simulate a tar pit so that spammers will give up,
>by stuttering the first n bytes of an SMTP connection.
>
>I have just read an article by Thomas Eggendorfer
>in the German Linuxmagazin (02/08 pages 74ff.).
>Eggendorfer published about this a lot, see
>http://www.unibw.de/inf3/institut/personen/wimis/eggendorfer/eggendorfer_publ
>.
>
>I have not yet found an English paper which would be openly accessible,
>there is a slide show with the rough concept (check pages 12ff):
>http://lxxi.org/files/spamcon07/eggendorfer-smtp_tar_pit_simulator.pdf
>(MIT Spam Conference 2007).
>
>The Linuxmagazin article contains pseudo code for sendmail,
>has somebody tried doing this with postfix?
>
>Eggendorfer claims that 80% of spammers disconnected if a maximum of 120 Bytes
>was stuttered with a maximum of 1.5 seconds pause (per Byte I assume). He
>puts forward the argument that early tar pit detection will be made harder
>with intelligent stuttering, thus raising costs for spammers while imposing
>only small limits on legitimate users.
>
>Having a stuttering postfix seems attractive. ;)
Not to anyone handling a lot of simultaneous connections already...
There are two major problems with all spam-control approaches that
slow senders:
1. Spammers have more fully-redundant parallel resources than any one
receiving system can hope to tie up in any significant way.
2. Slowing sessions means increasing parallelism on your own system,
and that can be a major problem if you have not planned for it
carefully. If you have a system that handles an SMTP transaction in 3
seconds on average and make it stutter so that each one takes 3
minutes, you need to be prepared for handling 60 times as many
simultaneous sessions.
These do not make such approaches useless, but they have to be
examined as part of whole solutions with real mail streams, not just
on how they perform monolithically in small tests. Slowing SMTP
sessions CAN drive away legitimate senders, so for systems bigger
than a handful of users, such tactics have to be used very carefully.
--
Bill Cole
bill
scconsult.com
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]