Need Assistance in SPF resolving error

Discussion:

Rasul Sharif .J via spf-discuss

2014-07-24 12:15:40 UTC

Hi,

We are a small ISP firm and one of our client SPF record exist in our public DNS server and it was working fine but suddenly without making any changes in the SPF record we are receiving error in result while making SPF query in kitterman.com tool so Regarding to remove the below error, your assistance will be highly appreciated.

Checked link- http://www.kitterman.com/getspf2.py

Results - PermError SPF Permanent Error: Void lookup limit of 2 exceeded

But other tools I don't see any error.

My client SPF record- v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105 mx:mail2.sasref.com.sa ip4:62.3.44.100 -all

Which point to domain name - sasref.com.sa

Regards

Rasul

________________________________
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the addressee(s) named herein. If you are not the intended recipient or addressee, you should not use, disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of "Al Harbi Telecom" and or its units.

Warning: Although reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. If you have received this electronic mail message in error, please contact the sender directly

-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20140724081600:3CEBB502-132C-11E4-8B67-820E63FA3163
Powered by Listbox: http://www.listbox.com

Stuart Gathman via spf-discuss

2014-07-24 13:52:15 UTC

Permalink

Post by Rasul Sharif .J via spf-discuss
Checked link- http://www.kitterman.com/getspf2.py
<http://www.kitterman.com/getspf2.py>
Results - PermError SPF Permanent Error: Void lookup limit of 2 exceeded
But other tools I don't see any error.
My client SPF record- v=spf1 mx ptr mx:mail.sasref.com.sa
ip4:62.3.44.105 mx:mail2.sasref.com.sa ip4:62.3.44.100 -all
Which point to domain name -- sasref.com.sa

The new SPF RFC (no longer experimental!) added a limit of 2 void DNS
lookups (i.e. nothing found) to prevent the use of SPF to make mail
servers participate in DDoS attacks.

There is no MX record for the mail.sasref.com.sa and mail2.sasref.com.sa
domains.

That said, that is only *two* void lookups. Unless the ip you gave also
had no PTR record, and I wonder if that is supposed to count against the
2 void lookup limit?

But your SPF record is very bad. The mx:mail... mechanisms are
redundant. You probably meant a:mail.sasref.com.sa, etc, and those are
already listed by your earlier mx mechanism. The ip4: mechanisms are
also redundant - since those are the ips for your 2 mail servers.
However, ip4 is more efficient - but that only helps if it comes first
in your policy.

So here is what your policy should look like:

v=spf1 ip4:62.3.44.105 ip4:62.3.44.100 mx ptr -all

Legit mail will be from one of the 2 ips, and be very fast to validate.
If you change ips, or mail servers, the mx mechanism will help pick up
the new mail servers if the checker hasn't seen your new SPF policy yet.

-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20140724095307:CF3E0F10-1339-11E4-9C4C-ECDA75638004
Powered by Listbox: http://www.listbox.com

alan via spf-discuss

2014-07-24 14:20:39 UTC

Permalink

ok first off this record violates all best practice rules and Must be fixed asap

second to fix it we need first to know what ips this record should actually be authorising to send email from ***@sasref.com.sa

but first we can guess that some of the ips implied by the sub-optimal record are ok so we will first optimise it

rules to be applied
terms
externally administered domain == a domain that ips cannot be enumerated without use of a:domain mx:domain ptr:domain include:domain or other dns lookup as the dns records are changed/modified/updated by another administrator without notice to the administrator of the spf record

rules
1 never ever use ptr (its dumb unreliable fails often and is unnecessary when not referencing an externally administered domain and impossible to cost in advance)
2 never use mx (its wastefull and unnecessary when not referencing an externally administered domain)
3 never unneccisarily use a (its unnecessary when not referencing an externally administered domain or to compress many single ips into a single record when many includes would cost more dns lookups(rare))
4 list lowest cost statements first ie ip4 then a:external then mx:external then include: etc

original record
v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105 mx:mail2.sasref.com.sa ip4:62.3.44.100 -all
(cost 6+ptr)

expanding all implied fields
v=spf1 +mx:sasref.com.sa +ptr:sasref.com.sa +mx:mail.sasref.com.sa +ip4:62.3.44.105 +mx:mail2.sasref.com.sa +ip4:62.3.44.100 -all

applying rule 4
v=spf1 +ip4:62.3.44.105 +ip4:62.3.44.100 +mx:sasref.com.sa +mx:mail.sasref.com.sa +mx:mail2.sasref.com.sa +ptr:sasref.com.sa -all

next applying rule 2
first lookup the 3 mx records mentioned in bad spf (all lookups and results shown at end of mail)
2 of them flat out fail and are broken thus removing
mx:mail.sasref.com.sa
and
mx:mail2.sasref.com.sa

the one that does work mx:sasref.com.sa is now replaced by the corresponding a records
a:mail.sasref.com.sa
a:mail2.sasref.com.sa

v=spf1 +ip4:62.3.44.105 +ip4:62.3.44.100 +a:mail.sasref.com.sa +a:mail2.sasref.com.sa +ptr:sasref.com.sa -all
(cost 3+ptr)

next applying rule 3 looking up the a records give us the 2 ips
+a:mail.sasref.com.sa +a:mail2.sasref.com.sa becomes == +ip4:62.3.44.105 +ip4:62.3.44.100 thus totally redundant

v=spf1 +ip4:62.3.44.105 +ip4:62.3.44.100 +ptr:sasref.com.sa -all
(cost 1+ptr)

and at this stage it looks like the ptr also serves no purpose so use either the fixed original

v=spf1 ip4:62.3.44.105 ip4:62.3.44.100 ptr -all

or the more likely correct
v=spf1 ip4:62.3.44.105 ip4:62.3.44.100 -all

thank you

dnslookups made + results
--------------------------------------------

set type=mx
sasref.com.sa

Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
sasref.com.sa MX preference = 100, mail exchanger = mail.sasref.com.sa
sasref.com.sa MX preference = 10, mail exchanger = mail2.sasref.com.sa
-------------------------------------------------------------------------------

set type=mx
mail.sasref.com.sa

Server: google-public-dns-a.google.com
Address: 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
sasref.com.sa
primary name server = dns1
responsible mail addr = tim.sky2net.com
serial = 2005121910
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
------------------------------------------------------------------------------------

set type=mx
mail2.sasref.com.sa

set type=a
mail.sasref.com.sa

Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: mail2.sasref.com.sa
Address: 62.3.44.105
-------------------------------------------------------------------------------------------

set type=a
mail2.sasref.com.sa

Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: mail2.sasref.com.sa
Address: 62.3.44.100
---------------------------------------------------------------------------------------------

Hi,
We are a small ISP firm and one of our client SPF record exist in our public DNS server and it was working fine but suddenly without making any changes in the SPF record we are receiving error in result while making SPF query in kitterman.com tool so Regarding to remove the below error, your assistance will be highly appreciated.
Checked link- <http://www.kitterman.com/getspf2.py>http://www.kitterman.com/getspf2.py
Results - PermError SPF Permanent Error: Void lookup limit of 2 exceeded
But other tools I dont see any error.
My client SPF record- v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105 mx:mail2.sasref.com.sa ip4:62.3.44.100 -all
Which point to domain name sasref.com.sa
Regards
Rasul
----------
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the addressee(s) named herein. If you are not the intended recipient or addressee, you should not use, disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of "Al Harbi Telecom and or its units.
Warning: Although reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. If you have received this electronic mail message in error, please contact the sender directly
Sender Policy Framework: <http://www.openspf.net>http://www.openspf.net
Modify Your Subscription: <http://www.listbox.com/member/>http://www.listbox.com/member/
<https://www.listbox.com/member/archive/735/=now>Archives<https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568> | <https://www.listbox.com/member/?&>Modify Your Subscription | <https://www.listbox.com/unsubscribe/?&&post_id=20140724081600:3CEBB502-132C-11E4-8B67-820E63FA3163>Unsubscribe Now<http://www.listbox.com>

Stuart Gathman via spf-discuss

2014-07-24 15:42:29 UTC

Permalink

I also don't get the error when using the page you reference:
---------------------%<----------%<------------------

SPF record lookup and validation for: sasref.com.sa

SPF records are published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105
mx:mail2.sasref.com.sa ip4:62.3.44.100 -all

Checking to see if there is a valid SPF record.

Found v=spf1 record for sasref.com.sa:
v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105
mx:mail2.sasref.com.sa ip4:62.3.44.100 -all

evaluating...
SPF record passed validation test with pySPF (Python SPF library)!
---------------------%<----------%<------------------

You still need to fix your record.

-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20140724114313:325592D0-1349-11E4-AD06-B02BC48871AE
Powered by Listbox: http://www.listbox.com

HECTOR SANTOS via spf-discuss

2014-07-30 17:34:02 UTC

Permalink

Rasul,

In my book, the getspf2.py processor is buggy. It shouldn't be barfing
on this highly subjective nonsense, dumb, 2 MX limit despite what it
was controversially written in the latest specification. That fell
thru the crack and its too bad it was MISSED.

There is nothing wrong with your domain SPF record. Can it be
improved? Sure, like
move the IP4 checks to the beginning, leaving the higher overhead
processing to last, but thats all subjective too. This processor was
apparently updated to RFC7208. The author of both. But it is flawed
because the RFC7208 recommendation is MUST DEFINITELY flawed. If I had
saw that, it would of been challenged during SPF-BIS.

Any limit related to this should always be based on the REDUNDANCY of
such operations and thats is only as LOCAL SPF DEPLOYMENT
consideration. That specs SHOULD of made that very clear. 2 limit?
Come on.

In addition, the common limit from the old and new specs is 10, not 2.
So there is technical semantics "limits" ambiguity already with
section 4.6.4 and 11.1. 2 limit? Really?

Rasul, this SPF record is fine. If you own it, your only recourse is
to MOVE the IP4 rules upfront before the MX checking is done. But
rest assure you are NOT the bug here - the GetSPF2.py is the bug and
the author should seriously consider relaxing that 2 limit. Odds are
good he will be forced to do it some day when more reports come in and
he gets tired of hearing about it. Blame others generally have an
expiration date in the support world and this is one of them. 2
limit? unbelievable.
--
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)
Office: 305-248-3204

Post by Rasul Sharif .J via spf-discuss
Hi,
We are a small ISP firm and one of our client SPF record exist in our public DNS server and it was working fine but suddenly without making any changes in the SPF record we are receiving error in result while making SPF query in kitterman.com tool so Regarding to remove the below error, your assistance will be highly appreciated.
Checked link- http://www.kitterman.com/getspf2.py
Results - PermError SPF Permanent Error: Void lookup limit of 2 exceeded
But other tools I don't see any error.
My client SPF record- v=spf1 mx ptr mx:mail.sasref.com.sa ip4:62.3.44.105 mx:mail2.sasref.com.sa ip4:62.3.44.100 -all
Which point to domain name - sasref.com.sa
Regards
Rasul
________________________________
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the addressee(s) named herein. If you are not the intended recipient or addressee, you should not use, disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of "Al Harbi Telecom" and or its units.
Warning: Although reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. If you have received this electronic mail message in error, please contact the sender directly
-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/993478-34c23837
Modify Your Subscription: https://www.listbox.com/member/?&
Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20140724081600:3CEBB502-132C-11E4-8B67-820E63FA3163
Powered by Listbox: http://www.listbox.com

alan via spf-discuss

2014-07-30 21:54:07 UTC

Permalink

Post by HECTOR SANTOS via spf-discuss
Rasul,
In my book, the getspf2.py processor is buggy. It shouldn't be barfing on this highly subjective nonsense, dumb, 2 MX limit despite what it was controversially written in the latest specification. That fell thru the crack and its too bad it was MISSED.

its not a 2 mx limit
its a 2 failure limit
he has 2 mxs listed that dont exist thus fail

Post by HECTOR SANTOS via spf-discuss
There is nothing wrong with your domain SPF record.

it has mention of 2 records that flatly dont exist

Post by HECTOR SANTOS via spf-discuss
Can it be improved?

obviously A LOT
did you read all the previous diagnosis and analasis?

Post by HECTOR SANTOS via spf-discuss
Sure, like
move the IP4 checks to the beginning, leaving the higher overhead processing to last, but thats all subjective too. This processor was apparently updated to RFC7208. The author of both. But it is flawed because the RFC7208 recommendation is MUST DEFINITELY flawed. If I had saw that, it would of been challenged during SPF-BIS.
Any limit related to this should always be based on the REDUNDANCY of such operations and thats is only as LOCAL SPF DEPLOYMENT consideration. That specs SHOULD of made that very clear. 2 limit? Come on.
In addition, the common limit from the old and new specs is 10, not 2. So there is technical semantics "limits" ambiguity already with section 4.6.4 and 11.1. 2 limit? Really?
Rasul, this SPF record is fine. If you own it, your only recourse is to MOVE the IP4 rules upfront before the MX checking is done. But rest assure you are NOT the bug here - the GetSPF2.py is the bug and the author should seriously consider relaxing that 2 limit. Odds are good he will be forced to do it some day when more reports come in and he gets tired of hearing about it. Blame others generally have an expiration date in the support world and this is one of them. 2 limit? unbelievable.
--
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)
Office: 305-248-3204

-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
Modify Your Subscription: https://www.listbox.com/member/?&
Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20140730155336:2EA26AB2-1823-11E4-934D-B3B67BCCFB40
Powered by Listbox: http://www.listbox.com