spf-discuss
[Top] [All Lists]

Re: Is SenderID supposed to stumble on garbage records? (paging Jim Lyon) C&C

2005-08-25 14:14:44
On 8/24/05 5:29 PM, Scott Kitterman sent forth electrons to convey:
I'm curious what makes you think this is anything to do with SPF or even
Sender ID.
There's some reason that exchange.microsoft.com sent me the mail it did, and Sender ID seems to be the most likely reason, as it's likely to be doing Sender ID checks that would produce a FAIL. As I stated before, it's possible it's something else. Clear? If you think there's another reason, please enlighten me.

BTW, since you almost bring it up... Thank you for the service you've done me and the implementation I help maintain with your SPF record.
You're welcome. I'm willing to live with the False Positives due to SPF breaking forwarding for the time being. Has hotmail turned on SenderID checks as was threatened? Checking to see what happens to mail sent there... bcc'ing now...
Your domain makes a good test case for processing limits.  A compliant
implementation returns PermError, FYI.
The ip4 mechanism won't hit because the mail is forwarded. (On non-forwarded I think it should provide a PASS... I'm cc'ing this to spf2(_at_)kit(_dot_)(_dot_)(_dot_) as a test; please let me know the results.)

Actually, the current spec seems CONTRADICTORY. It says the record should be evaluated left to right and on a match, processing ends. It ALSO says that in all cases, any syntax errors anywhere in the record MUST be detected. Damn confusing! IIRC, the latter bit is a recent addition, which has broken backwards compatibility. :( This needs clarification. The situation where the HELO check produces one result and the MFROM check produces another also needs definition. The spec should not leave this undefined, IMO. These situations result in incompatibilities that the IETF process is supposed to avoid. I guess your implementation first checks the whole record for syntax errors and then processes it left to right. Is that correct? If so, do you stop processing on a match?

I actually had thought the stunt DNS server at slow.sp.am had been turned off. I see now that it's still working (slowly and unreliably, as intended). If the record results in >10 DNS lookups, there should be a PermError, as you state. DNS queries that time out could well result in a TempError instead; one of the two would happen given a compliant implementation. A (noncompliant) implementation could get to the ~all, resulting a SoftFail, of course. And given the record uses obsoleted syntax, other things could happen. (%{r} only in exp - which usually results in "unknown"). I noticed the DNS log warnings a few days ago that indicate that %{h} is deprecated by some implementations as well.

Just made some changes to the elvey.com SPF record, BTW. We'll see if the implementations that don't like h don't like s either. I'm guessing h is marked deprecated because it breaks caching. (Yes, slow.sp.am will continue to help keep things 'interesting'.)

Thanks for helping advance the cause...
Thanks for triggering my irony detector... I do think I'm advancing some good causes.