by The cool thing about being a sysadmin is you’re always learning – whether you want to or not…
Today I sent an email to a colleague from my corporate email account, and while we were IRC’ing about other stuff– he told me that no, he didn’t get the email. Huh. I double-checked my sent-items folder– yes, the email address WAS correct. No, still no email.
About 2 minutes later, he eventually found it – in his ‘Spam’ folder.
While I was thrilled he got the email (something that took me a bit of time to compose), I was now immediately wondering- why the heck was my email, something that contained only technical text (no attachments), considered as SPAM? Time to check it out.
Before I describe the hunt process- I have to briefly describe our email setup. We’re a one-off. That is, our department is SO huge on our campus, we run our own exchange servers. INBOUND email all goes through the corporate gateways (and gets forwarded..), but OUTBOUND email (from us) goes directly out our exchange servers and filters. There’s lots of reasons for this setup- I’ll leave it at that.
So, the first thing I assumed was “Well, heck– one or both of our exchange servers must be blacklisted….”. I checked the blacklist-checking sites– nope, all green- we’re good. Nobody is listing us as being evil. Good news, but still did not explain why my email got tagged.
I then had my colleague send me BACK the email he had eventually located– with the headers. And in the email headers, I saw something I had never seen in email headers before (slightly edited for security reasons):
Received-SPF: softfail (google.com: domain of transitioning kcb@domain.org does not designate 111.222.333.44 as permitted sender) client-ip=111.222.333.44;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning kcb@domain.org does not designate 111.222.333.44 as permitted sender) smtp.mail=kcb@domain.org
So- what the heck is this SPF thing that was classifying my email as not being a “permitted sender”?
The IP address above is one of OUR email servers (not the corporate one). And after some brief checking (and finding http://www.openspf.org), here’s what I found out:
SPF stands for Sender Policy Framework. It’s a trick, using a combination of DNS and email headers, to kind of sort of verify you are supposed to be sending from that email server. It’s not perfect (face it, SMTP is full of issues)- but is certainly another layer against evil-doers…
Here’s how the basics work: Let’s say your organization’s email domain is “fred.org”. Like most domains, fred.org has an MX record in there somewhere, which points to your email server. And there’s “A” records (IP address), “NS” records (nameservers), etc. SPF basically has you add a NEW kind of dns record, using the TEXT type. In other words, it’s a DNS comment.
Let’s say fred.org has an email server, and it’s IP address is 111.222.555.66. The DNS record for SPF ‘authentication’ looks like this:
fred.org. IN TXT “v=spf1 ip4:111.222.555.66”
Once that magical DNS entry is there, the magic happens.
The user at “fred.org” sends an email to joe.bubba@gmail.com. The gmail email server sees that the email is actually coming from the Ip address of 111.222.555.66. OK, so far so good. It sees that the email is supposedly coming from “joe@fred.org”. And finally, it does the special DNS check, and sees that yes, 111.222.555.66 *is* indeed listed as a valid email server for sending from the fred.org domain.
Voila! Like I said, it’s a simple trick, using DNS. Nothing more.
If the entries do NOT match up– then the email server can decide what to do with the message– drop it, file it as spam, whatever.
Back to our setup? Seems the corporate folks did create an SPF domain record- and only listed THEIR email server. Ours weren’t included. Thus, my friend’s gmail classified my message as spam.
SPF is now new – I was surprised to learn it’s been around quite a while. However, it seems that SPF adoption is finally beginning; I see its value and I am forecasting it gets adopted both widely and rapidly. It’s pretty cool. But it’s totally dependant on each receiving email server to adopt it.
Your task for the day? If your organization does not yet have SPF DNS record(s) set up- do it quick. Otherwise you risk recipients never getting your emails……
One final note: The SPF record types are very flexible– allowing for multiple hosts by IP, NAME, and some other options. go to the spf web site listed above and check it out.
OK, now back to what I was SUPPOSED to be doing for today…………………