Re: Publishing of SPF Records

Stefan Engelbert wrote:
> > No they wouldn't; you fail to see a key problem here. Any 
> > domain that didn't implement DNS-SPF would then be hit for 
> > HTTP-SPF requests. 
> > Effectively you make DNS-SPF compulsory for anyone not 
> > wishing to suffer the HTTP penalty.
> ;-) - and they would hurry up to implement DNS access for their
> customers....
So basically you want to implement HTTP-SPF as a secondary and temporary 
measure entirely to be a nuisance to web hosting providers (who are NOT 
neccessarily the same as domain registrars), in the knowledge that it 
will not work for most cases and will place extra load on a vast number 
of webservers and all SPF checking agents, perhaps on the basis that web 
hosts will then go and do precisely what you should have done in the 
first place; that is, request DNS-TXT editing capabilities from registrars?
(I am quite aware that this is not what you think you are saying, but 
your apparent lack of understanding of both SPF and network principles 
mean that this is, in fact, what you are proposing).
> > In my personal case you'd need over 12 web
> > servers in place of 2 DNS servers (of which I'd only need to 
> > reconfigure the master one for any changes).
> NO, you wouldnt since u have DNS and so not need the web server anymore.
> http was ment to be a fallback mechanism in case no dns txt record
> exist.
I am quite aware of that; this was intended as an example. My point is 
that even if I didn't have DNS, HTTP would be chronically unsuited to 
the task.
Furthermore, by proposing a non-DNS alternative, you are in fact giving 
registrars an excuse NOT to support arbitrary TXT records for customers, 
and therefore slowing down the availability of this pre-requisite of 
true SPF.
I fail to see any merit in your suggestion, or evidence that you have 
considered all issues at hand. How would you handle SPF records for HELO 
hosts, for example? Do you envision your proposal having any use except 
in the case where there is precisely one hostname per domain, with that 
hostname also being a webserver? What proportion of SPF record requests 
would you expect the HTTP fallback to capture?
SPF penetration for domains appears to be in the order of 1% - actually 
an astounding accomplishment for a technology this young - so in almost 
all cases an SPF-checking agent would have to perform the HTTP test 
(since you provide no mechanism for signifying that this measure should 
not be performed). DNS servers (which are by definition present for a 
domain) will provide (except in rare error cases) a near-instant "no 
record" for the request, wheras HTTP servers will require a second 
lookup (an 'A' record) and generally NOT be present, requiring the 
SPF-checking agent to wait for a socket timeout (with an order of 
several seconds). If the socket *is* accepted, considering the far lower 
responsiveness of web servers compared to DNS servers, it could easily 
take another 30 seconds worst-case to return a large, complex '404' 
response which needs far heavier parsing than a DNS response. (Yes, 
responses need parsing too, not just SPF TXT strings. HTTP is a 
heavyweight protocol in this respect).
This makes the previous estimate of 10 times more load on an 
SPF-checking agent look decidedly conservative. In other words your 
proposal would increase the load on SPF checking agents (NOT record 
servers) by a factor of, say 20 to 50 - something that mailservers are 
not going to accept.
To put this simply: Your proposal is designed to make your own life 
simpler, by making life harder for the majority. Why do you feel that 
such a proposal should be accepted?
If, despite these issues, you feel that your proposal still has merit, I 
would ask that you answer all the questions raised above, as they will 
be required by other list readers wishing to fully evaluate your proposal.
        
        Wechsler