I block SPF softfails and had this one getting blocked today. According to  http://www.openspf.org/Why - http://www.openspf.org/Why  it shouldn't have been, i suspect it is the EXISTS that isn't handled correct?

/pds

04/29/11 10:14:25:094 -- (8380) Detected TCP Connection: 192.66.33.189

04/29/11 10:14:25:094 -- (8380) Connection from: 192.66.33.189  -  Originating country : Denmark

04/29/11 10:14:25:297 -- (8380) Received MAIL FROM: <xxx@tdc.dk>

04/29/11 10:14:25:297 -- (8380) Received RCPT TO: yyy@mycompany.tld

04/29/11 10:14:25:500 -- (8380) found SPF record for tdc.dk: v=spf1 exists:%{i}.spf.tdc.dk include:spf.w11.dk ~all

04/29/11 10:14:25:625 -- (8380) found SPF record for spf.w11.dk: v=spf1 ip4:195.69.128.114 ip4:195.69.128.115 ip4:195.69.128.116 ip4:195.69.128.118 ip4:195.69.128.121 ip4:195.69.128.122 ip4:86.58.131.176 -all

04/29/11 10:14:25:625 -- (8380) SPF query result: fail

04/29/11 10:14:25:625 -- (8380) - SPF analysis for spf.w11.dk done: - fail

04/29/11 10:14:25:625 -- (8380) SPF query result: softfail

04/29/11 10:14:25:625 -- (8380) - SPF analysis for tdc.dk done: - softfail

04/29/11 10:14:25:625 -- (8380) failed SPF test (softfail) - Disconnecting 192.66.33.189

04/29/11 10:14:25:625 -- (8380) 192.66.33.189 - Mail from: xxx@tdc.dk To: yyy@mycompany.tld will be disconnected

04/29/11 10:14:25:657 -- (8380) Blacklist cache - Added 192.66.33.189 to limbo

04/29/11 10:14:25:657 -- (8380) Disconnect

The build 4.2.4.844 is a pre-release build that is available for registered users , even though it's our release candidate that is actually scheduled to be released officially tonite - excellent timing :-)

We compared the SPF features in both 4.2.4.844 and 4.2.4.834, and they are identical, except for a bug fix in 4.2.4.844 which addresses cases where a domain has (incorrectly) configured more than one SPF record in DNS (which is not the case here). The way the "exists:" mechanism, and the %{i} macro are handled appear identical, so I do not think upgrading should fix the issue.

and since the exists part isn't even mentioned in the log, it still leads me to suspect that it isn't being proccessed, especially since it is that rule that should make it pass.

Do you get a different output than me?

/pds

We had tested by sending an actual email faking the IP to be 192.66.33.189. I ran a test using the "Test SPF" button, using both SpamFilter 4.2.4.844 and 4.2.4.834. In both cases the result is "pass" - I included a screenshot so you can see (I manually inserted word-wraps in the result to make it more visible). The actual line there reads:

What is a bit strange is your output in your last post on 5/2/11 00:11:59 is missing a (threadID) value, meaning that it wasn't the result of an incoming email. It was thus likely the result of the SPF test. That output however is not sent to the activity logfile/screen by those two versions of SpamFilter - the SPF test result appears only on one line in the result window. This type of logging was occurring on very old versions of SpamFilter instead. Are you absolutely certain you are using SpamFilter v4.2.4.434, and not an earlier version? Could you please email us at support @ logsat.com with a screenshot of your SpamFilter showing the "Test SPF" button and the failure results?

First of, I have solved my problem. I upgraided to 844 and that didn't help, and since you couldn't reproduce the problem with either 834 and 844, it had to come from somewhere else, and the only other place was my DNS server. It seems that it got upgraided at some point and had a new default 'feature' to filter out 127.0.0.1 (amongst other internal subnets) responses from external servers,  great feature for some, but poison in this context.