Trilight Zone Forum Index Trilight Zone
Privacy & Anonymity is our speciality !
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Reputation and SMTP Authentication

 
Post new topic   Reply to topic    Trilight Zone Forum Index -> Security
Author Message
tricore
Guest





PostPosted: Thu Feb 01, 2007 2:40 am    Post subject: Reputation and SMTP Authentication Reply with quote

Perhaps the main enabling factor in e-mail abuse, from spam to mail worms, is the unauthenticated nature of SMTP e-mail. When an attacker sends a message, he can make it look to the user as if the message comes from, for example, president@whitehouse.gov. Unfortunately, SMTP provides no way for the recipient to determine whether President George W. Bush actually sent the message.

Great battles were fought in standards bodies over the last few years in order to create authentication standards. The winners appear to be two vendor-created standards, Microsoft's Sender ID Framework and DomainKeys Identified Mail from Yahoo and Cisco.

Experts can and do argue over which system is better at authenticating senders, although they both have a good deal in common. But in the real world, they both lack something critical to their own effective use: though they can tell you who the sender is, they can't tell you whether that sender is trustworthy.

SMTP authentication has suffered, throughout its short life, from the accusation that spammers would simply adopt it in order to subvert it. This presumes that recipients would accept any e-mail that was authenticated, but that would be a bad policy. To use authentication correctly, one needs to combine it with information on the reputation of the sender.

Reputation services

Reputation services, better known as DNSBLs (DNS Blackhole Lists) or RBLs (Realtime Blackhole Lists), have actually existed for years. Such services are lists of IP addresses of mail servers—or, more accurately, lists of systems that have functioned as mail servers—and have been caught sending spam or some other form of abuse. Not all of the systems on the lists are actual servers, of course. Many are client computers infected with a bot. Two of the larger DNSBLs are MAPS (Mail Abuse Prevention System, now part of Trend Micro) and SPEWS (Spam Prevention Early Warning System).

These services have a mixed reputation. They are widely used by ISPs and other mail providers, because by blocking all mail coming from systems on the list, one can block a huge amount of spam. But it's not unheard of for these services, in the process of black-holing (i.e. blacklisting) an address, to take down innocent collateral sites. This usually is the case because the sites share IP addresses over a period of time, such as on a shared mail server at a hosting service. Also, when issues have been addressed at the server (perhaps when the spamming user is denied access and the spam stops), the reputation service may not be fast enough for the user's taste in removing the address from the blacklist.

Collateral damage

The issue of collateral damage is in part a result of the lack of authentication in SMTP: there is no reliable way to demonstrate what domain the mail came from, so all mail coming from the address is blocked. But reliable SMTP authentication will end this problem and allow reputation services to block or allow based on a domain.

How will this change the industry?

Some IP-based reputation services have been attempting for some time to perform reverse-lookups on the IP address. This is of questionable accuracy, except when combined with analysis of other mail characteristics. It is generally more accurate for large domains.

Because it doesn't really exist yet, imagine a world in which the large majority of e-mail is sent from a domain that supports a strong authentication system like SIDF or DKIM. Reputation services could then develop reputation data for those domains to be used by mail recipients. The collateral damage problem thus would go away, because only the offending domain would be blacklisted, not the other domains on the same server.

It's likely that the market for reputation services will resemble that of network spam filtering. Here, large enterprises that often provide their own mail security will need to make their own decisions about reputation services. But in the consumer space, users will look upon it as an infrastructure element that is provided by the ISP as part of the e-mail system. They won't be willing to pay more for it—they'll just demand good e-mail service, and that the better ISPs use better reputation data.

Controversy expectations

Expect controversy to increase over time about the transparency of rating methods at reputation services. Much like credit agencies, domain owners will demand to know how they are rated, and how they can improve their ratings.

Expect more controversy as well over how reputation is handled for small domains as compared to large. For example, if you receive 10 viruses from rinkydink-company.com that indicates a problem, you might blacklist it—but you wouldn't blacklist all of hotmail.com for it.

Ultimately, domain authentication and reputation monitoring have some compelling arguments on their side. For one, they make mail filtering much cheaper for recipients in terms of computation and network bandwidth as compared to content-based filtering. These systems aren't exactly known to be perfect, so it's possible that a reputation-based system could end up being fairer as well. In the end, as long as e-mail ends up cleaner, users will be happy.
Back to top
Display posts from previous:   
Post new topic   Reply to topic    Trilight Zone Forum Index -> Security All times are GMT
Page 1 of 1

 


Powered by phpBB © 2001, 2005 phpBB Group