SPF and SERVFAIL

I perceive a 3-part problem with SPF and SERVFAIL.

1) Most SPF implementations treat any failure in
resolving/retrieving/parsing an SPF record as a TEMPFAIL and issuing
4xx. On the surface, this appears to be a reasonable approach - unless
something in that process is broken....

2) Most mail sysadmins seem to have no idea on how to
manage/tune/control their SPF mechanisms. They simply come bolted on to
a mail filter appliance they own and they check the box that save "SPF
Checking Enabled" and that's the end of the story. They also do not
collect statistics; do no reporting and probably aren't aware of where
(if any) log files are stored. This makes it difficult for them to
resolve issues in part 1.

3) The technical competence of the organisation or ISP seems to be
inversely proportional to its size. This generally means the greater the
effect on your organisation, the more difficult it is to get the remote
organisation to even recognise a problem exists.

Over the past 12 months, I have had five incidences of remote mail
servers rejecting email based on SERVFAIL. The problem has not been our
DNS or our SPF record. It has been the problem of the remote mail server
performing the SPF lookup and failing on "something". In most cases the
other end has not been able to determine the cause and they have simply
chosen to whitelist our domain - which IMO is not a solution and defeats
the purpose of SPF.

One recent case involves a very large ISP in Australia. It has taken
four weeks for them to recognise a problem exists. 

That's four weeks of me calling them every day.

I suspect the problem lies in the lesser utilised features of SPF. Our
record adds an IP4 netblock. Another domain has an include statement.
These are the only two domains that have experienced problems with
SERVFAIL. We don't use macros but I wonder how well some of the
implementations will handle that?

IMO, the default and recommended response to an SPF SERVFAIL should be a
NEUTRAL result. Ie treat the domain as if it had no SPF record at all.
This would eliminate issues such as this which can only occur if the
sending domain actually has an SPF record.
********************************************************************************************************
Disclaimer: This email message and any attachments are confidential.   
The information contained in this email message and any attachments may be 
confidential information. If you are not the intended recipient, any use, interference with, 
disclosure or copying of this material is unauthorised and prohibited.
This email and any attachments are also subject to copyright.  
No part of them may be reproduced, adapted or transmitted without the written
permission of the copyright owner.
If you have received this email in error please immediately advise the sender 
by return email and delete the message from your system. 
Although this email has been checked for viruses and other defects, no responsibility 
can be accepted for any loss or damage arising from its receipt or use.
Racing Victoria Limited respects your privacy. Our privacy policy can be accessed 
from our web site: "http://www.racingvictoria.net.au"
********************************************************************************************************