Over the last few weeks of Security Levity, we've looked at how DNS blocklists (DNSBLs) evolved from the spam filtering equivalent of primordial ooze, and how they became reputation services. This week I want to look at where we're going: what's the future for sender reputation?
I mentioned this briefly last week; the idea is that the reputation of a sender can depend on where the recipient is. In other words, if you want to know whether this sender is a spammer, the answer depends on who's asking and where they are.
For example, if I'm in China and a Chinese company is sending me email, I'm much more likely to consider the email to be legitimate than if I'm in North America. (We discussed this aspect of the Chinese culture of spam, back in October.)
It's not just about IP addresses
Up to this point, we've only been talking about the reputation of a sender's IP address. But, increasingly, sender reputation's not just about IP addresses. An IP address, on its own, is an inexact and potentially error-prone way of identifying the message's sender. Of course, the message has a From: header and an SMTP envelope sender, but as we discussed before, these are easily forged.
Ideally, we'd like to know the reputation of an email address (or at least of its domain). So first we need to know whether the sender information is legitimate, by detecting forgeries.
Detecting forgeries for domain reputation
Last month, we talked about sender address forgery and the standards for verifying that a message was actually sent by the domain it claims as its sender. If a message's sender uses DomainKeys Identified Mail, a recipient can verify that the sending domain is who it claims to be. DKIM does this by the 'magic' of public key cryptography, as described in RFC 4871, et al.
There are other methods, such as the SPF/SenderID family of specifications, which are weaker but easier to implement.
If we can verify the domain by one or both of these methods, we're able to confidently look up the reputation of this sender's domain. Effectively, getting the reputation of the actual email address, not just the IP address.
So, for example, if the message came from email@example.com and the message's DKIM signature checks out, we can look up the reputation of example.com in the reputation service. If the service doesn't know the reputation of example.com, then we can fall back to looking up the reputation of the IP address.
Vouching: reputation services for senders
A proposed standard called "Vouch By Reference" (VBR) intends to allow reputation services to vouch for 'legitimate' outgoing mail sent by others (although the draft standard refers to the services as "certification providers"). VBR would add an additional header to the outgoing mail, which could be verified on receipt, to check that the service did actually vouch for the sender.
It's an interesting spin on reputation services, as it primarily services the needs of senders, rather than recipients and it differs from existing allowlists by speaking to the reputation of the domain, not the sending IP address.
However, one concern is that such vouching services might have a financial incentive to vouch for spammers. The worry is that, if a sender starts off being legitimate but later turns into a spammer, a paid-for vouching service might be slow to stop saying that the sender is trustworthy. One way to combat this is to legally define the service fee as a bond or deposit: money that the sender forfeits if the service receives too many complaints.
Finally, if a service is offering reputation opinions about a sender, it's important for recipients to be able to send feedback to the service about email received from that sender. Ideally, the feedback mechanism would be automatic, to react quickly and to minimize inconsistencies.
For example, if a user discovered a false positive that was caused by the sender's reputation being low, a receiving spam filter could automatically send feedback to the reputation service, informing it of a possible error. Such reports could be collated from around the internet and could be used to update the reputation stored for that sender.
That's it for my three-part holiday series on sender reputation. I hope you found it interesting and enlightening. Again, if you missed any earlier posts in this series, here's part 1 and here's part 2.
In the near future, I also plan to talk about web reputation, so please stay tuned.
I want to make this an interactive place: where I can answer questions and cover topics that you suggest. Feel free to add comments and ask Amir!