Spam Spotlight on Reputation
<http://www.eweek.com/print_article/0,1761,a=134748,00.asp> EWeek Spam Spotlight on Reputation Spam Spotlight on Reputation September 6, 2004 By Dennis Callaghan As enterprises continue to register Sender Protection Framework records, hoping to thwart spam and phishing attacks, spammers are upping the ante in the war on spam and registering their own SPF records. E-mail security company MX Logic Inc. will report this week that 10 percent of all spam includes such SPF records, which are used to authenticate IP addresses of e-mail senders and stop spammers from forging return e-mail addresses. As a result, enterprises will need to increase their reliance on a form of white-listing called reputation analysis as a chief method of blocking spam. E-mail security appliance developer CipherTrust Inc., of Alpharetta, Ga., also last week released a study indicating that spammers are supporting SPF faster than legitimate e-mail senders, with 38 percent more spam messages registering SPF records than legitimate e-mail. The embrace of SPF by spammers means enterprises' adoption of the framework alone will not stop spam, which developers of the framework have long maintained. Enter reputation analysis. With the technology, authenticated spammers whose messages get through content filters would have reputation scores assigned to them based on the messages they send. Only senders with established reputations would be allowed to send mail to a user's in-box. Many anti-spam software developers already provide such automated reputation analysis services. MX Logic announced last week support for such services. "There's no question SPF is being deployed by spammers," said Dave Anderson, CEO of messaging technology developer Sendmail Inc., in Emeryville, Calif. "Companies have to stop making decisions about what to filter out and start making decisions about what to filter in based on who sent it," Anderson said. The success of reputation lists in organizations will ultimately depend on end users' reporting senders as spammers, Anderson said. "In the system we're building, the end user has the ultimate control," he said. Scott Chasin, chief technology officer of MX Logic, cautioned that authentication combined with reputation analysis services still won't be enough to stop spam. Chasin said anti-spam software vendors need to work together to form a reputation clearinghouse of good sending IP addresses, including those that have paid to be accredited as such. "There is no central clearinghouse at this point to pull all the data that anti-spam vendors have together," said Chasin in Denver. "We're moving toward this central clearinghouse but have to get through authentication first." -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote:
E-mail security company MX Logic Inc. will report this week that 10 percent of all spam includes such SPF records,
I have mentioned this problem more than a year ago in context of my RMX draft (SPF, CallerID and SenderID are based on RMX). Interestingly, nobody really cared about this major security problem. All RMX-derivatives block forged messages (more or less). But what happens if the attacker doesn't forge? That's a hard problem. And a problem known from the very beginning of the sender verifikation discussion. The last 17 month of work in ASRG (Anti Spam Research Group, IRTF) and MARID (Mail authorization records in DNS, IETF) are an excellent example of how to not design security protocols. This was all about marketing, commercial interests, patent claims, giving interviews, spreading wrong informations, underminding development, propaganda. It completely lacked proper protocol design, a precise specification of the attack to defend against, engineering of security mechanisms. It was a kind of religious war. And while people were busy with religious wars, spammers silently realized that this is not a real threat to spam. Actually, it sometimes was quite the opposite: I was told of some cases where MTAs were configured to run every mail through spam assassin. Spam assassin assigns a message a higher score if the sender had a valid SPF record. Since most senders with valid recors were the spammers, spam received a higher score than plain mail, which is obviously the opposite of security. People spent more time in marketing and public relations than in problem analysis and verifikation of the solution. That's the result. What can we learn from this? Designing security protocols requires a certain level of security skills and discipline in what you want to achieve. Although RMX/SPF/CallerID/SenderID does not make use of cryptography, similar problems can be sometimes found in context of cryptography. Knowing security primitives is not enough, you need to know how to assemble them to a security mechanism. Good lectures are given about the mathematical aspects of cryptography. But are there lectures about designing security protocols? I don't know of any yet. And there is a new kind of attack: Security protocols themselves can be hijacked and raped by patent claims. regards Hadmut
At 03:15 PM 9/6/2004, Hadmut Danisch wrote:
On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote:
E-mail security company MX Logic Inc. will report this week that 10 percent of all spam includes such SPF records,
I have mentioned this problem more than a year ago in context of my RMX draft (SPF, CallerID and SenderID are based on RMX). Interestingly, nobody really cared about this major security problem. All RMX-derivatives block forged messages (more or less). But what happens if the attacker doesn't forge? That's a hard problem. And a problem known from the very beginning of the sender verification discussion.
It's not a hard problem, just a different problem. Whitelisting your friends and aggressively filtering strangers is an obvious technique for reducing false positives without increasing false negatives, but it fails if spammers can forge identities of your friends. RMX-derivatives help this problem, and they help the joe-job problem. If a spammer wants to claim that they're the genuine spammers-are-us.biz, well, let them. I find it more annoying that there are spammers putting PGP headers in their messages, knowing that most people who use PGP assume PGP-signed mail is from somebody genuine and whitelist it. ---- Bill Stewart bill.stewart@pobox.com
Bill Stewart wrote:
At 03:15 PM 9/6/2004, Hadmut Danisch wrote:
On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote:
E-mail security company MX Logic Inc. will report this week that 10
percent
of all spam includes such SPF records,
I have mentioned this problem more than a year ago in context of my RMX draft (SPF, CallerID and SenderID are based on RMX). Interestingly, nobody really cared about this major security problem. All RMX-derivatives block forged messages (more or less). But what happens if the attacker doesn't forge? That's a hard problem. And a problem known from the very beginning of the sender verification discussion.
It's not a hard problem, just a different problem.
Whitelisting your friends and aggressively filtering strangers is an obvious technique for reducing false positives without increasing false negatives, but it fails if spammers can forge identities of your friends. RMX-derivatives help this problem, and they help the joe-job problem.
If a spammer wants to claim that they're the genuine spammers-are-us.biz, well, let them.
I find it more annoying that there are spammers putting PGP headers in their messages, knowing that most people who use PGP assume PGP-signed mail is from somebody genuine and whitelist it.
Surely you should check that: a) The signature works b) Is someone in your list of good keys before whitelisting? -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
At 1:33 PM +0100 9/13/04, Ben Laurie wrote:
Surely you should check that:
a) The signature works b) Is someone in your list of good keys
before whitelisting?
Amen. A (cryptographic) whitelist for my friends, all others pay cash. :-) Cheers, RAH -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
----- BEGIN PGP SIGNED MESSAGE ----- At 05:33 AM 9/13/2004, Ben Laurie wrote:
Bill Stewart wrote:
I find it more annoying that there are spammers putting PGP headers in their messages, knowing that most people who use PGP assume PGP-signed mail is from somebody genuine and whitelist it.
Surely you should check that: a) The signature works b) Is someone in your list of good keys before whitelisting?
My terminology was a bit sloppy, but until recently, you could use the presence of PGP format indicators as a whitelist entry, or at least a SpamAssassin good weight - spammers didn't use the stuff, and the worst would be quasi-spam like Yet Another Invitation to some crypto-industry marketroid's seminar. It might be a rant from Detweiler or some other cypherpunk that you bozofilter, but at least that was a job for your email program to sort out, not your first-tier spamfilter. Besides, with most email clients, you can't check the PGP information without opening the email (more obviously true for PGP encrypted mail than signed mail), so the email filters just go for basic syntax. Bill Stewart bill.stewart@pobox.com -----END PGP SIGNED MESSAGE----- LKJEDGFDAFKLHFDSAFDSLAFHLKDFHLKJDHFHLDSKFHLKDHFLKDHFKLFDSFLDSFHDX DASHFLDSFHDSFKLFDSLKFLKDJSFKLSDHFLKJHDFLKJFJKDSHFDLKJHFDLKSHFLDSK BADSIGNATUREBADSIGNATUREBADSIGNATURENODOUGHNUTBADSIGNATUREBADSIGN -----END PGP SIGNATURE-----
participants (4)
-
Ben Laurie -
Bill Stewart -
Hadmut Danisch -
R. A. Hettinga