[ale] Spam fighting strategies

[Bob Toxen]

Hi Michael,
> Hey Bob,

Yes, MailScanner would be a medium-level OSS solution for those willing
to spend the time to configure it and train SpamAssassin.  I note that
it makes no claims as to effectiveness.

My non-OSS solution blocks about 97% of spam with a very low false-
positive level (and offering a White List capability).  This almost
certainly is better than MailScanner and proven better than SpamAssassin
alone.  When I add the "Greeting Delay" this month I expect to get that
to 98.5 or 99%.  For those with a small budget it is an excellent solution
as at least several ALErs know.

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!