[ale] Spam fighting strategies

[Michael H. Warfield]

Hey Bob,

On Thu, 2007-10-04 at 14:50 -0400, Bob Toxen wrote:
> On Wed, Oct 03, 2007 at 03:53:18PM -0400, Jeff Lightner wrote:
> > The other night in the AUUG meeting it was mentioned  by one person that
> > they had turned on a "read delay" in email (Postfix I think) and that
> > this had eliminated about 80% of the spam because the bots would
> > disconnect.   

> > Unfortunately I didn't have a chance to follow up then but mentioned it
> > to our Exchange admin because they've been fighting an increase seen
> > recently in connection attempts.  It sounds as if Exchange can't do this
> > natively.

> > I'm wondering if anyone has done this on Postfix/Sendmail or some other
> > OSS MTA and would be willing to provide details?   

> > My coworker found something called "Greeting Delay" that sounds like
> > what I heard as "Read Delay" so it may be this but apparently that has a
> > problem with people that do call back to check whether email is coming
> > from a valid site.
> Yes, the person mentioning "read delay" probably means the "Greeting
> Delay" technique.  Yes, this is quite effective.  Most spammers will
> assume that there is something wrong with the recipient, drop the
> connection, and go on to the next as being more efficient.

	I was that person and I mentioned Greet Delay (actually, it's
"greet_pause" in the sendmail.mc configuration) in sendmail.

> Most spammers also blast their entire dialog and message, once the TCP/IP
> connection is established, without bothering to follow the proper SMTP
> protocol of waiting for a response to each phase before going on to
> the next.  A spam filter technique is to detect such output before our
> side sends its reply and then treating the email as spam (because it's
> violating SMTP specifications.)

	Actually, Greet Delay implements this as well.  While sendmail is
waiting out the time period before it sends its banner, if data comes
down the channel, it dumps the connection right then and there.  So you
get both effects...  Some spammers give up and disconnect, and others
force the data down the connection and get disconnected.

	An extension to the "Greet Delay" is the tarpit option.  With a tarpit
option, each command "EHLO, RCTP, FROM, etc" in smtp is delayed slowing
down the initial handshake up to the DATA part.  I haven't tried this,
and I don't believe it's in stock sendmail or postfix, but some people
have claimed success.  I'm not sure if I would see much more success
over the simple Delay Greet option.

	I had not heard that there was a problem with people that do call back
to check whether email is coming from a valid side or not but that's
highly broken behavior since the outgoing mail server may be different
from the incoming mail server and may, in fact, legitimately not
reachable.  IAC, there is a whitelisting feature in Delay Greet and you
can set those legitimate sites to not get a delay.  In fact, you want to
do this for all your internal addresses, to avoid unduly delaying them.
So, it's an easy fix for their broken behavior.

> These two techniques currently are being added to my SpamCracker(tm)
> spam filter that I offer.  (It happily will work in front of Exchange
> as well as any other mail server.)
> 
> > Also he found doing bogus MX records in DNS - the idea being you put
> > your first and final MX records to dead IPs as most spam bots only check
> > the first or final and not the intervening real ones.   Has anyone tried
> > this and if so what results did you have?
> This also is quite effective and trivial to implement with no loss of
> legitimate email.

	Yup, another technique I've used successfully.

> > Essentially we're looking at putting in a Linux server as if it were an
> > SMTP gateway to the Exchange server which will continue to be the
> > primary mail server for the company.   Any other ideas (other than
> > getting rid of Exchange which won't happen) would be appreciated.
> While those techniques will eliminate a substantial percentage of spam,
> they will not solve the problem.  The solution requires a good spam
> filter such as ours that has 12 additional filtering steps, including
> a number of anti-spoofing steps and steps that detect senders trying
> to evade spam filtering techinques.  It blocks about 97% of spam with
> a very low false-positive rate.

	Check out the latest version of MailScanner, www.mailscanner.info.  It
includes techniques for watermarking outbound messages, bayesian
filtering, CRM114, SpamAssassin, and, now, a dynamic list of phishing
sites as well as hooks for a variety of AV products.  Drops in on
Sendmail or Postfix with or without the above techniques.

> Bob Toxen
> bob at verysecurelinux.com               [Please use for email to me]
> http://www.verysecurelinux.com        [Network&Linux/Unix security consulting]
> http://www.realworldlinuxsecurity.com [My book:"Real World Linux Security 2/e"]
> Quality Linux & UNIX security and SysAdmin & software consulting since 1990.
> Quality spam and virus filters.
> 
> "Microsoft: Unsafe at any clock speed!"
>    -- Bob Toxen 10/03/2002

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part