Error in process of SPF EXISTS? |
Post Reply |
Author | |
psamsig
Newbie Joined: 29 April 2011 Location: Denmark Status: Offline Points: 4 |
Post Options
Thanks(0)
Posted: 29 April 2011 at 5:34am |
I block SPF softfails and had this one getting blocked today. According to 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
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
psamsig,
We're not able to reproduce this - SpamFilter is correctly accepting the SPF record "v=spf1 exists:%{i}.spf.tdc.dk include:spf.w11.dk ~all" when the sender's IP is 192.66.33.189. The result of that SPF record depends on the existence of an A record for: 192.66.33.189.spf.tdc.dk which does exist (at least it does today) and resolves to 127.0.0.1. Are you still having this issue today? In theory it could be possible that 192.66.33.189.spf.tdc.dk did not resolve to anything yesterday which is why the email would have been blocked. Just to make sure there isn't an unknown bug in earlier versions of SpamFilter, could you let us know what build of SpamFilter you're using? We verified this record to work as expected with SpamFilter v4.2.4.844.
|
|
psamsig
Newbie Joined: 29 April 2011 Location: Denmark Status: Offline Points: 4 |
Post Options
Thanks(0)
|
We are running v4.2.4.834, which I thought was the latest build (according to the program it self), I'll try upgraid as soon as I figure out if we still have maintenance.
Thank you for a quick answer. /pds
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
psamsig,
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.
|
|
psamsig
Newbie Joined: 29 April 2011 Location: Denmark Status: Offline Points: 4 |
Post Options
Thanks(0)
|
I just checked, and if I try with the above mentioned information (xxx@tdc.dk sending from 192.66.33.189), the 'Test SPF' in Spam Filter still gives a softfail
05/02/11 00:11:59:763 -- found SPF record for tdc.dk: v=spf1 exists:%{i}.spf.tdc.dk include:spf.w11.dk ~all Result: softfail 05/02/11 00:11:59:841 -- 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 05/02/11 00:11:59:841 -- SPF query result: fail 05/02/11 00:11:59:841 -- - SPF analysis for spf.w11.dk done: - fail 05/02/11 00:11:59:841 -- SPF query result: softfail 05/02/11 00:11:59:841 -- - SPF analysis for tdc.dk done: - softfail 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
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
psamsig,
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: 05/04/11 00:23:16:843 -- - SPF analysis for tdc.dk done: - pass 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? |
|
psamsig
Newbie Joined: 29 April 2011 Location: Denmark Status: Offline Points: 4 |
Post Options
Thanks(0)
|
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. Thank you very much for your support, it has been very helpfull! /pds
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.113 seconds.