Criminals, The Network, and You [Was: Something Else]

Wed Sep 12 21:43:22 UTC 2007

Hi Steve,

In my opinion, the first and fourth statements are not necessarily in
conflict. A reputation system based purely on reverses is pretty broken.
Also, it is not necessary to use it as a factor in calculating a very
reliable reputation. I'm having trouble seeing how the first and third
are in conflict as well, but I may be indexing statements differently.

Regarding the second, you're absolutely right. It's not your
responsibility if a 3rd party doesn't have a rDNS entry (at all or
non-generic), however the reality is you're going to have to deal with
it anyway. If your customers allow you to tell the senders to buzz off
and fix it, that's terrific.  However, you're in a more authoritarian
(IT-wise) environment than most I would suspect. Also, you risk hurting
your customers. As an example, it's not a suitable answer to our law
firm customers who are critically-dependent on receiving e-mail from
hopelessly broken senders.

>As for the third, well, now you know why I use generic rDNS detection
to
>defeat bots. As you say, "It's not that hard for a bot to figure out
>[any infected host]'s reverse entry and use that for its HELO". In
fact,
>that's exactly what many of them do, when they're not forging well
known
>services or sending unqualified/unresolvable strings in HELO/EHLO. And
>that, in itself, is responsible for over a fifth of our SMTP-time spam
>detections (and rejections, so there's no outscatter, unlike with a
wide
>variety of "antispam" appliances, such as Barracudas). It's a sensible
>and sane perimeter defense tactic, far better than what I see most
doing.

It's not disputable that rejecting generic rDNS hits (or failures
depending on your point of view) will gain you benefits. What I think is
disputable, is the benefit to false positive ratio. About 60% of our
botnet analyses show unqualified, or outright out-of-spec HELOs. One can
catch the remaining 40% through correlation of certain SMTP factors with
the results of content-analysis. Near real-time data mining of both
informational inputs shouldn't be underplayed. Lastly, I fully agree one
should reject as much as possible before the SMTP session ends.

Whether or not rDNS is a good anti-spam measure for you entails a lot of
factors. I posit from our own statistical analyses the benefit to pain
ratio issue is not high enough. Particularly, when there so many other
correlations you can run that have lower false positive rates.

Best Regards,
Jason