Epic Softfail

Somebody complained today that an e-mail I sent got caught in MIT’s spam filters, so I took a look at the message to see if I could figure out why it went through for me.

(For the record, using just the headers at your disposal to figure out why spam filtering is doing something strange is always a futile endeavor)

I didn’t figure out what was going on, but then I noticed this in the headers:

Received: by 10.102.218.17 with SMTP id q17cs56702mug;
        Thu, 11 Feb 2010 09:42:54 -0800 (PST)
Received: by 10.224.59.28 with SMTP id j28mr118230qah.109.1265910085825;
        Thu, 11 Feb 2010 09:41:25 -0800 (PST)
Return-Path:

Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15])
        by mx.google.com with ESMTP id 17si5760822qyk.35.2010.02.11.09.41.25;
        Thu, 11 Feb 2010 09:41:25 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning prvs=165867b240=uptrack@ksplice.com does not designate 18.9.25.15 as permitted sender) client-ip=18.9.25.15;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning prvs=165867b240=uptrack@ksplice.com does not designate 18.9.25.15 as permitted sender) smtp.mail=prvs=165867b240=uptrack@ksplice.com
Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41])
	by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id A4.AB.13801.441447B4; Thu, 11 Feb 2010 12:41:24 -0500 (EST)
Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12])
	by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id o1BHdVsa009188
	for ; Thu, 11 Feb 2010 12:41:23 -0500
X-AuditID: 1209190f-b7bbfae0000035e9-cf-4b7441445cb2
Received: from mail-qy0-f202.google.com (mail-qy0-f202.google.com [209.85.221.202])
	by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id 6B.AF.10714.241447B4; Thu, 11 Feb 2010 12:41:22 -0500 (EST)
Received: by qyk40 with SMTP id 40so1272989qyk.14
        for ; Thu, 11 Feb 2010 09:41:22 -0800 (PST)
Received: by 10.229.130.205 with SMTP id u13mr94912qcs.47.1265910082497;
        Thu, 11 Feb 2010 09:41:22 -0800 (PST)
Received: from ksplice.com ([64.27.0.149])
        by mx.google.com with ESMTPS id 20sm1621806qyk.9.2010.02.11.09.41.20
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 11 Feb 2010 09:41:21 -0800 (PST)

A lot of spew, of course, but the interesting lines are the two SPF softfails near the top: “domain of transitioning prvs=165867b240=uptrack@ksplice.com does not designate 18.9.25.15 as permitted sender”

It took me a little while to figure out what was going on – I know that Ksplice sends its e-mails through Gmail, and I know that ksplice.com’s SPF record includes the Gmail mail servers.

But that e-mail went to a list at MIT, which then expanded to my MIT e-mail address, which then forwards to my GAFYD address. That SPF validation was performed by Gmail when it received the e-mail from MIT’s mail servers, and MIT’s mail servers aren’t authorized to send mail from ksplice.com.

I’m not sure how this is avoidable for this sort of mail forwarding – MIT’s mail servers could just as easily be spammers pretending to forward mail from ksplice.com. Maybe the solution is some way for me to tell Gmail that MIT is authorized to send my mail to me. Either way, it’s just more proof that SPF doesn’t work.

Update: Anders points out that this can be solved with “Sender Rewriting Scheme“, which basically just changes the envelope on the message to something that contains an obfuscated form of the original e-mail, but whose domain is that of the forwarder.