taint.org: Justin Mason’s Weblog

• Dublin bike scheme billboards threat to drivers : JC Decaux’ “free” bikes are now delayed another 6 months — to next spring. in the meantime, the ads are up all over Dublin. what a rip-off
  (tags: jc-decaux bikes cycling dublin advertising spam civic ireland)

• Return Path to Acquire Habeas : that’s the two main legit-email whitelisting reputation dbs merged into one
  (tags: return-path habeas ssc bsp bonded-sender spamassassin anti-spam dnswl dnsbl reputation deliverability)

• scammers buying phones, then wardialing the nearby number-space to scam them : this just happened to Simon Willison, pretending to offer to cancel extremely expensive insurance, but with a “cancellation fee”. great demo of why consecutive assigned numbering schemes are bad for security
  (tags: phishing scams phones uk iphone via:simonw security numbering ids)

• DRI calls for data-breach disclosure in Ireland : +1
  (tags: breach-disclosure security exploits social-welfare ireland identity-theft)

Tags: advertising, anti-spam, bikes, bonded-sender, breach-disclosure, bsp, civic, cycling, deliverability, dnsbl, dnswl, dublin, exploits, habeas, identity-theft, ids, iphone, ireland, jc-decaux, numbering, phishing, phones, reputation, return-path, scams, security, social-welfare, spam, spamassassin, ssc, uk, via:simonw

An interesting post from Simon Willison, noting that he is now publishing a list of “non-spammy” OpenID identities (namely people who posted one or more non-spammy comments to his blog).

I attempted to comment, but my comments haven’t appeared — either they got moderated as irrelevant (I hope not!) or his new anti-comment-spam heuristics are wonky ;) Anyway, I’ll publish here instead.

It’s possible to publish a whitelist in a “secure” fashion — allowing third parties to verify against it, without explicitly listing the identities contained. One way is using Google’s enchash format. Another is using something like the algorithm in LOAF.

Also, a small group of people (myself included) tried social-network-driven whitelisting a few years back, with IP addresses and email, as the Web-o-Trust.

Social-network-driven whitelisting is not as simple as it first appears. Once someone in the web — a friend of a friend — trusts a marginally-spammy identity, and a spam is relayed via that identity, everyone will get the spam, and tracking down the culprit can be hard unless you’ve designed for that in the first place (this happened in our case, and pretty much killed the experiment). I think you need to use a more complex Advogato-style trust algorithm, and multiple “levels” of outbound trust, instead of the simplistic Web-o-Trust model, to avoid this danger.

Basically, my gut feeling is that a web of trust for anti-spam is an attractive concept, possible, but a lot harder than it looks. It’s been suggested repeatedly ever since I started writing SpamAssassin, but nobody’s yet come up with a working one… that’s got to indicate something ;) (Mind you, the main barrier has probably been waiting for workable authentication, which is now in place with DK/SPF/DKIM.)

In the meantime, the concept of a trusted third party who publishes their concept of an identity’s reputation — like Dun and Bradstreet, or Spamhaus — works very nicely indeed, and is pretty simple and easy to implement.

Tags: anti-spam, email, enchash, loaf, openid, reputation, trust, web-o-trust, whitelisting

There’s a common misconception about spam, email, and email authentication; Matt Cutts has been the most recent promulgator, asking ‘Where’s my authenticated email?’, in which various members of the comment thread consider this as an anti-spam question.

Here’s the thing — email these days is authenticated. If you send a mail from GMail, it’ll be authenticated using both SPF and DomainKeys. However, this alone will not help in the fight against spam.

Put simply — knowing that a mail was sent by ‘jm3485 at massiveisp.net’, is not much better than knowing that it was sent by IP address 192.122.3.45, unless you know that you can trust ‘jm3485 at massiveisp.net’, too. Spammers can (and do) authenticate themselves.

Authentication is just a step along the road to reputation and accreditation, as Eric Allman notes:

Reputation is a critical part of an overall anti-spam, anti-phishing system but is intentionally outside the purview of the DKIM base specification because how you do reputation is fundamentally orthogonal to how you do authentication.

Conceptually, once you have established an identity of an accountable entity associated with a message you can start to apply a new class of identity-based algorithms, notably reputation. … In the longer term reputation is likely to be based on community collaboration or third party accreditation.

As he says, in the long term, several vendors (such as Return Path and Habeas) are planning to act as accreditation bureaus and reputation databases, undoubtedly using these standards as a basis. Doubtless Spamhaus have similar plans, although they’ve not mentioned it.

But there’s no need to wait — in the short term, users of SpamAssassin and similar anti-spam systems can run their own personal accreditation list, by whitelisting frequent correspondents based on their DomainKeys/DKIM/SPF records, using whitelist_from_spf, whitelist_from_dkim, and whitelist_from_dk.

Hopefully more ISPs and companies will deploy outbound SPF, DK and DKIM as time goes on, making this easier. All three technologies are useful for this purpose (although I prefer DKIM, if pushed to it ;).

It’s worth noting that the upcoming SpamAssassin 3.2.0 can be set up to run these checks upfront, “short-circuiting” mail from known-good sources with valid SPF/DK/DKIM records, so that it isn’t put through the lengthy scanning process.

That’s not to say Matt doesn’t have a point, though. There are questions about deployment — why can’t I already run “apt-get install postfix-dkim-outbound-signer” to get all my outbound mail transparently signed using DKIM signatures? Why isn’t DKIM signing commonplace by now?

Tags: accreditation, anti-spam, authentication, dkim, domainkeys, email, habeas, reputation, return-path, smtp, spam, spamhaus, spf

Spam: Jon Udell: How to forge an S/MIME signature, and Liudvikas Bukys’ take on the results: ‘Jon Udell tries his hand at S/MIME signature forgery, revealing that PKI is not a panacea. A digital signature proves something. The proof is strong but the something is weak (if it just demonstrates that you clicked a few things to get a persona certificate).’

He then suggests two ways to use this info in useful ways:

The first is ‘higher-class certificates (where certificate authorities demand more proof, and encode that fact in the certificate). But higher quality means harder to get and less actual deployment. And higher quality means more attractive target for theft of keys.’

In the anti-spam case, it also means that you trust the certificate provider to both (a) accept money from their customers to issue them certs, and (b) take away those certs from their own customers if they infringe by sending spam messages. This is the hard part. There’s an active financial disincentive for a company to do this; the people who benefit (the end-users) are not their paying customers, whereas the people who get hurt (the infringers) are. Economics dictates that they water down the requirements, in order to maximise their profits – making the system useless.

On the other hand we have: ‘reputation systems. Of course, building robust reputation systems is not easy. Users may wish to have multiple sources of reputation information to fit their own definitions of good and bad behavior and how fast those judgments are made. It replays the whole DNS blacklist deployment. Some reputation systems may seem arbitrary and capricious. Others may be too slow or too tolerant. They are all lawsuit targets. Will there be too many to choose from?’

‘zackly. An excellent illustration of how S/MIME or other PKI will not solve the spam problem, and we’ll still have the same DNSBL situation as we have now (although hopefully working a lot better).

S/MIME may solve the forged-email problem, like SPF does — however, like SPF it will still need to work with reputation systems to be usable as an anti-spam scheme.

Tags: certificate, hand, jon, mime, proof, quality, reputation, signature, something, spam, udell

Spam: filster: Linking reputations networks to email whitelists. Very interesting — a tool to use the social network data from Orkut, FOAFweb, Reputation Research Network, and CPAN to whitelist email senders in SpamAssassin. Only problems I can see:

• needs an anti-forging mechanism like SPF to avoid spammers forging their way through your whitelist — but the author does cover that.
• some of the site terms of service may prohibit scraping — Orkut’s, for example, is very strict.

Still, a very nifty idea, and one worth more investigation… the combination of FOAF and SPF in particular, given that tribe.net (if I recall correctly?) will be generating FOAF data, is quite cool.

Tags: email, filster, foaf, foafweb, network, orkut, reputation, spam, spf, tool, whitelist

Tech: So, I just looked at NTK; it has a brief bit about Bram Cohen ‘having solved content distribution, (announcing) he was now tackling other simple problems: reputation systems, version control and perhaps after lunch the NP-complete set.’

Hmm, interesting! Let’s take a look at his diary — and what do I find but a whole load of entries on using trust metrics against spam. Bugger. Looks like I have my weekend reading cut out for me.

Also notable: Advogato has added native RSS support, which makes this pretty pointless; and they’ve also added an XML-RPC interface. Expect to see taint.org entries getting copied up there soon, as a result. ;)

Tags: bit, content, control, distribution, hmm, lunch, np-complete, ntk, reputation, tech, version