Man, they'll try anything to hack your system...

[Dan Jenkins]

Ben Scott wrote:

>  On 1/28/06, Python <python at venix.com> wrote:
>
> > A huge percentage of my spam comes from IP addresses with no
> > reverse lookup.
>
>  A huge percentage of my spam contains the character 'e' in the
>  message body.
>
>  Both the above statements illustrate a classic spam-fighting mistake.
>  It's *absolutely useless* to say "A huge percentage of my spam meets
>  such-and-such a criteria" unless you can *also* say "A huge
>  percentage of my ham does *not* meet the same criteria". If you've
>  got that, you've got something useful. Otherwise, forget it.
>
>  Anyone here have figures on what percentages of their ham violates
>  standards or best practices? I don't, but based on anecdotal
>  evidence from operators much larger then me, the answer is: "A lot."
>
>  The key is to distinguish spam from ham, not merely to assign
>  characteristics to spam.

A cursory examination of two of my clients' mail logs over the last 
couple of days shows about 3/4 incoming email was spam. About 4/5 of the 
spam had bad MX or PTR. Of the 1/4 ham arriving, 1/5 had bad MX or PTR 
records. Since one of the clients was a school, that might skew the data.

So, rejecting on bad senders' MX/PTR/etc., would reject 20% of the ham 
coming in there. Better than a few years back when 60% of senders of ham 
were rejected, but not acceptable yet. I was hoping to find it better 
than that, which is why I asked the question in the first place (being 
too lazy to check it out myself :-). YMMV. I would hope business email 
to be better. I guess I'll start using bad MX/PTR as a weight towards 
spam-hood, but not heavily weighted.

>  I find bayesian filtering with a good user feedback loop is still the
>  overall best solution.
>
>  At Net Tech, for IMAP clients, I was working on a solution that used
>  spamassassin and procmail to sort mail into folders, along with a few
>  specially-named folders clients could move mail to identify it as
>  "also-spam" or "not-spam". A cron job ran nightly to process those
>  exceptions and train the filter. I left Net Tech before it went
>  beyond the initial testing phase, but it looked promising.

That's what I do for most of our clients. It works pretty well. In 
conjunction with Mozilla junk training, it helps alot.

-- 
Dan Jenkins (dan at rastech.com)
Rastech Inc., Bedford, NH, USA --- 1-603-206-9951
*** Technical Support Excellence for over a quarter century