[Dshield] Protection against spammer dictionary attacks
wayne_jr at pacbell.net
Tue Oct 7 03:19:08 GMT 2003
Please excuse a dumb question, but if I (as a personal user) bounce a
spam email off my ISP's mail server w/o downloading it (with
MailWasher), will that stop a spam harvester from getting my email
address, or does the mere fact that the spam makes it onto the ISP's
mail server (Pacbell in my case) enough for the harvester? I don't
really understand how these things work... Maybe me bouncing spam
doesn't do any good?
On Mon, 06 Oct 2003 18:35:35 -0700, ronin wrote:
>hi i have problems understanding how to accomplish the things you
>say to do...would it be possible to out line steps to follow in
>amanner that a neophyte like me can understand. iwould really
>appreciate any help i can get.. thanx,
>cyrilwilliams at msn.com...............
>----- Original Message -----
>From: Jon R. Kibler
>To: list at dshield.org
>Sent: Sunday, October 05, 2003 12:16 PM
>Subject: [Dshield] Protection against spammer dictionary attacks
>We have seen a big jump in the number of dictionary attacks against
>our mail system in the past few days. I don't know if it is just the
>domains we manage, or whether it is more widespread. However, I
>thought I would pass on a schema that we use to limit the impact of
>such attacks. These options are specific to sendmail, but most MTAs
>have similar configuration options.
>These attacks typically try to send to 10 to 50 recipients per
>envelope. Our strategy is two-fold:
>1) Slow down the rate at which the spammer can attempt to harvest
>2) Clog up the spammer's queue and/or confuse their address
>The sendmail options we use to accomplish this are:
>The first option says that after 2 bad recipients in a given
>envelope, sendmail will wait 1 second after each 'RCPT To:' before
>responding. Thus, instead of being able to slam 50 or so probes into
>our mail system in less than a second, it would drag out such probes
>for almost a minute. This both reduces the load on our MTA and slows
>down how fast the spammer can collect email addresses (probably by
>about 2 orders of magnitude!).
>The second option limits the number of recipients per envelope.
>After 5 recipients are received per envelope, the rest are temp
>failed. (Note: This does not limit the number of "To: recipient"s,
>etc., it only limits the number of recipients your mail server will
>process in a single attempt to send a message.) For legitimate
>senders, this has minimal impact: if a sender tries to send to more
>than 5 recipients on your mail system at one time, the first 5
>receive the message immediately, and the other experience a slight
>delay while the message is requeued. However, for spammers, this
>option causes one of three things to occur on their address
>1) All the temp failed addresses are queued for later retry (which
>really slows down the spammer). Whereas this will cause some
>additional load on your MTA should the spammer's software actually
>retry these addresses, we find that retries seldom occur in reality.
>2) The spammer uses a 'dumb' address harvester that treats the temp
>fail as a permanent error, and the addresses that are temp failed
>are judged to be bogus addresses.
>3) The spammer uses an even dumber address harvester that cannot
>handle temp fails, and their harvester dies.
>Of course, it is needless to say, no one should ever use a common
>name for an email address (like joe at ...) -- unless, of course, the
>address is intended as spam bait.
>Anyway, just some thoughts on protecting yourself against one form
>of email address harvesting. Hope someone finds them useful.
>Jon R. Kibler
>Chief Technical Officer
>Charleston, SC USA
>Filtered by: TRUSTEM.COM's Email Filtering Service
>No Spam. No Viruses. Just Good Clean Email.
>list mailing list
>list at dshield.org
>To change your subscription options (or unsubscribe), see:
More information about the list