Shaken-Not-Stirred Technology Mixed Right!

To SPF or not SPF that is the question.

Ring....Ring....Ring..

Me: Good day.

Headhunter: I sent you an email and it bounced back. Do you have a working email address you can give me.

Me: Yes, wynkoop AT wynn.com

Headhunter: That is what I used and it bounced back

Me: Why did it bounce back?

Headhunter: I do not know it does not say, it just says it bounced back

Me: I am sure it says something. Can you read it to me?

Headhunter: No really it does not say anything.

Me: Can you please read the bounce back message and use your scroll bar to scroll down as you read it.

Headhunter: It says "Rejected - IP 10.0.0.54 not authorized to send mail for example.com"

Me: Ok that tells me the problem is on your end. You need to check your email server and dns server and correct the error on your dns server.

Headhunter: I never had this problem before. I send lots of email it must be you. Please can you give me a good email address?

The above is a conversation that I seem to have at least once a week. The problem is not always SPF, sometimes it is email from an IP that is in a block list, other times the email trips a bayesian filter or is rejected for a combination of reasons. I run a very tight spam filter at wynn.com that pays strict attention to the RFCs that govern SMTP and DNS.

Usually I offer my services to the company in question to fix their problem for them. Most of the time the recruiting firm has no real technical talent and while they may be happy to place an expert out in their name, they are scared to have that same expert fix the recruiting firm's own computing problems.

Today I decided to go the extra mile and send a detailed report to the recruiter on the off chance that I might get the gig to fix their email infrastructure.

So why was the email to me rejected. The story lies in DNS text records. Please note the domain and ip information has been changed to protect the guilty.

[wynkoop@wa3yre ~]$ nslookup
set type=txt
example.com
Server: 199.89.147.3
Address: 199.89.147.3#53

Non-authoritative answer:
example.com text = "MS=ms48171289"
example.com text = "v=spf1 include:spf.protection.example.net -all"

Authoritative answers can be found from:
example.com nameserver = ns25.domaincontrol.com.
example.com nameserver = ns26.domaincontrol.com.


So the above tells we have to take another look. This time we need to lookup spf.protection.example.net.

spf.protection.example.net

text = "v=spf1 ip4:192.168.20.0/24 include:spfa.protection.example.net -all

So now our smtp server knows that it can accept example.com mail only from 192.168.20.0/24 or from what ever spf.protection.example.net expands to....yep you guessed it they had an endless loop in their SPF record, but wait as they say on TV "That's not all! You also get this lovely SENDER/SPF mismatch at no additional cost".

The ASSP logfile teaches us this:

Mar-22-15 18:40:32 64032-18820 10.0.0.54 to: wynkoop@wynn.com [spam found][blocked] -- SPF fail -- [[hot linux admin contract]] -> /usr/local/assp/spam/64032-18820.eml;

If we examine the line above we see the connection came in from 10.0.0.54, not any system in the 192.168.20.0/24 net as the SPF record indicates. Further the SPF record tells SPF checking MTAs that if you get email claiming to be from example.com and it is not from 192.168.20.0/24 do a hard fail of the message.

So my mail server was doing exactly what the folks at example.com had instructed it to do by way of their SPF entry (the -all means reject if not from a host specified in this record).

Do I find it odd that the gentleman on the phone told me that I was the only one he ever had this issue with? No, not really. Most mail servers on the internet today are improperly configured in one way or another, and another common misconfiguration would mask this problem. Many mail servers either silently drop spam, or silently put it into a spambox for the user. Either way the email is not delivered to the user and the sender gets no feedback to let them know there is a problem. The sender just thinks he was ignored. When I told the recruiter about this second common misconfiguration he exclaimed "That must be why so many people seemed to be ignoring my email this past week".

In more than 30 years of having an internet connected email server I have never found a delivery problem to be caused by my end of the path, but the number of delivery issues has been on the rise. I feel this is largely because people do not expose themselves to the RFCs and figure, well if it seems to work it must be OK. In many cases smaller companies, like the one in question here, do not have staff on hand that understand the technology and they outsource their email hosting to ---SOME---BIG---COMPANY---IN--THE-CLOUD--. There is a very good chance that ---SOME---BIG---COMPANY---IN--THE-CLOUD-- does not have fully competent staff. There has been a real trend in IT to eliminate higher paid senior engineering staff because "most of the time it just works". As a result subtle problems can arise that the inexperienced or improperly trained technical staff will never notice.

If you use email or DNS and do not have your own expert on staff to assist with assuring your servers are properly configured I suggest you hire a consultant for a couple of days to get a health check and take corrective actions if needed.

Remember no SPF record is better than a BROKEN SPF record, if you want your outbound email to be delivered.

-Brett
wynkoop--at--wynn.com
917-642-6925