Jason Bertoch wrote:

A message passed through my server yesterday from an @allianzlife.com address with the following Received header:

Received: from allianzlife.com (securemail.allianzlife.com [204.52.250.91] (may be forged))

While investigating other issues with the message, I noted that (unless my coffee hasn't kicked in yet) it should have matched on SPF_SOFTFAIL, but didn't. In fact, it didn't match on _any_ SPF rules. I have a number of other messages in my logs that hit all of the various SPF rules, so I know that things are at least partially working. The ugly spf trace is included in the pastebin link, but essentially this falls back on "~all". Am I missing something obvious?


http://pastebin.com/m1134a08b



Replying to my own post, I've continued to dig around due to the fact that no SPF rules hit. It occurred to me that the problem may be the complex and somewhat malformed SPF record this company has produced.

"v=spf1 mx mx:alfemp01.allianzlife.com. mx:blfemp01.allianzlife.com. mx:mail04.allianzlife.com.ppus.azmx.de. mx:mail05.allianzlife.com.ppus.azmx.net. include:cust-spf.exacttarget.com. ~all"

Notably, they use the mx: prefix where I suspect they needed an a: prefix. (Actually, these are completely unnecessary as these hosts are all listed as MX records and they've already specified the "mx" parameter). I would expect that there should be some sanity checks on the number of (failed) DNS lookups made in an SPF query. If that's the case, it might explain why I have no match on SPF rules. Can anyone confirm or deny that there are lookup restrictions with regard to SPF records?

/Jason

Reply via email to