taint.org: Justin Mason’s Weblog

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: recently, I’ve been getting a lot of spam bounces; that is, messages sent by people’s autoresponders, in response to forged spam claiming to come from my domain. (I have an SPF record, but these autoresponders naturally don’t bother to check that before replying.)

I have a SpamAssassin ruleset which catches these, and it gets rid of the vast majority — but the odd wierd one gets past. This one caught my eye before I deleted it:

On October 5, 2004, I will be going to the Illinois Department of Corrections for approximately 18 months. If you wish to contact me, please snail mail me at: (address deleted)
Your letters will be forwarded to me and I will reply as soon as I receive them! Thanks…and please do write! Mail is vitally important! :-)

… ouch. Good luck to this guy, whoever he is…

Tags: domain, lot, mail, majority, record, response, ruleset, spam, spamassassin, spf

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

Spam: Craig is publishing SPF records. Worth noting that I’ve been publishing SPF records for jmason.org for a month or two, even though the protocol hasn’t even stabilised yet — working on the ‘if you build it, they will come’ approach ;)

Anubis looks great; I’ve been meaning to hack up something like that. Nifty!

Tags: anubis, approach, jmason, month, org, protocol, something, spam, spf, the, worth

Spam: SMTP Sender Authentication, by David Jeske of Y! Groups (pointer from Jeremy.

Schemes similar to this — calling back to a sending server to verify that a mail was really sent via that host — have been proposed before in several venues, the most high-profile and public being the ASRG list. Here is a message I sent to that list in April 2003 discussing a few of those schemes:

• J C Lawrence’s ‘forward chained digital signatures’ on Received headers
• William at elan.net’s ‘complex callback verification requirying full message tracking server functionality with dns extensions’
• Russ Nelson’s Q249
• Our own ‘porkhash’

I still like this style of system, I think, but in terms of deployability and simplicity, I’m supporting Sender-Permitted From for now — which similarly forces senders to use registered relays for a given SPF-supporting domain, but using DNS as the protocol and IP addresses as the hard-to-forge identity component.

Another bonus of SPF is that it’s simple, easy to implement, has *running code* out there now, and is being pushed strongly by a pragmatic and sane driving person (in the form of Meng Weng Wong). It’s not always easy in the anti-spam field to find a solution like that ;)

BTW, SPF also, similarly, breaks envelope sender forging. However, I agree, this is one egg that has to be broken to help stop spam (or at least force spammers to use their own domains and IPs.)

Tags: authentication, list, mail, message, pointer, schemes, sender, server, smtp, spam, spf

SMTP Sender Authentication, by David Jeske of Y! Groups (pointer from Jeremy.

Schemes similar to this — calling back to a sending server to verify that a mail was really sent via that host — have been proposed before in several venues, the most high-profile and public being the ASRG list. Here is a message I sent to that list in April 2003 discussing a few of those schemes:

• J C Lawrence’s ‘forward chained digital signatures’ on Received headers
• William at elan.net’s ‘complex callback verification requirying full message tracking server functionality with dns extensions’
• Russ Nelson’s Q249
• Our own ‘porkhash’

I still like this style of system, I think, but in terms of deployability and simplicity, I’m supporting Sender-Permitted From for now — which similarly forces senders to use registered relays for a given SPF-supporting domain, but using DNS as the protocol and IP addresses as the hard-to-forge identity component.

Another bonus of SPF is that it’s simple, easy to implement, has *running code* out there now, and is being pushed strongly by a pragmatic and sane driving person (in the form of Meng Weng Wong). It’s not always easy in the anti-spam field to find a solution like that ;)

BTW, SPF also, similarly, breaks envelope sender forging. However, I agree, this is one egg that has to be broken to help stop spam (or at least force spammers to use their own domains and IPs.)

Tags: authentication, list, mail, message, pointer, schemes, sender, server, smtp, spf