Catching Spam by Looking at Traffic, Not Content

AngryDad writes "HexView has proposed a method to deal with spam without scanning actual message bodies. The method is based solely on traffic analysis. They call it STP (Source Trust Prediction). A server, like a Real-time Spam Black list, collects SMTP session source and destination addresses from participating Mail Transfer Agents (MTAs) and applies statistics to identify spam-like traffic patterns. A credibility score is returned to the MTA, so it can throttle down or drop possibly unwanted traffic. While I find it questionable, the method might be useful when combined with traditional keyword analysis." What do you think? Is this snake oil, or is there something to this?

Comments

sounds good to me

[seanadams.com]

I realize most of us here would ordinarily prefer for our ISPs to just move bits around, but it seems like they are in a pretty good position to curb spam if they were to start look at traffic patterns like this. If some DSL customer suddenly starts opening hundreds of outgoing SMTP connections, that would be a pretty reliable sign that his machine is pwned. Just block or throttle port 25, and send the customer an email telling him to fix his computer, and keep it blocked until he does - or he contacts abuse@ with a legitimate explanation. Not filtering based on the contents of the data should let them maintain plausible deniability and common carrier status.

We can't do this on our personal or company internet connections because we only see individual messages coming from many different IPs, but on the other end of the connection, or even at the backbone level, this strikes me as a pretty solid solution. They could even just tag the packets with the evil bit and let us decide if we want to filter them or not.

The problem with this

[wiredog]

Mailing lists. How does it not tag a server that sends out mail to a list as a spammer?