Re: Validator Testing Request

Richard Parker wrote:
> On Aug 9, 2005, at 5:42 AM, Scott Kitterman wrote:
>
> > First, and without delay, change ptr:cox.net to ?ptr:cox.net.  That  will
> > achieve the goal of matching something before the all without  giving 
> > all the
> > zombies a pass.
>
> On Aug 9, 2005, at 7:07 AM, Stuart D. Gathman wrote:
>
> > Because he sometimes sends mail through those ISPs.  What is  probably 
> > better
> > practice in that situation is the following:
> >
> > 1) TXT electrophobia.com:
> >     "v=spf1 ?ptr:cox.net include:dsis.net include:easydns.com -all"
> >
> > In fact, any ISP you include that does not actively prevent
> > cross-customer forgery should be NEUTRAL.
>
> Yes, in fact I used to be using the exact record that Scott and  Stuart 
> recommend.  Unfortunately I received an unacceptably high  number of 
> mail rejections from people who appear to implement a  policy of "reject 
> mail if SPF record exists and it doesn't return  PASS".  So my choice 
> was an overly permissive SPF record, no SPF  record, or mail 
> rejections.  I chose door number 1.  I suppose I  could have kept my 
> record the same and tried to track down and  personally contact via 
> another e-mail address all of those who were  implementing that broken 
> policy, but I'm not dedicated to my use of  SPF enough to do that.
> On Aug 9, 2005, at 5:42 AM, Scott Kitterman wrote:
>
> > Not only is this type of approach much tighter, it's also MUCH  easier 
> > on DNS
> > and more reliable than PTR.
>
> Oh I agree.  I could indeed track down the dozens of outgoing Cox  mail 
> servers, identify their IP addresses and net blocks, assemble my  own 
> list in proxy for Cox's lack of SPF, and constantly monitor their  
> activity to keep the list up to date as they add, remove, or change  IP 
> addresses.  It may be lazy of me, but as I intimated above I think  I'd 
> probably chose to depublish SPF before I committed to constantly  
> maintaining it in such a fashion.  On the other hand, if the SPF  
> community chose to assemble and publish proxy records for large ISPs  
> that don't publish their own SPF records (e.g. something like  
> "include:cox.net.proxy_records.openspf.org"), I'd be willing to use  
> them if the DNS server setup for the proxy records looked reliable.
This is an option which I would be prepared to set up and administer, using input from all 
those who are having such problems. I have a reliable DNS server (touch wood) and a remote 
back-up, though I'd be happy if others would do further back-ups, or allow me access to do 
it myself.
I will create TXT and SPF records for a subdomain of one of my own domains as proxy for 
any domains that do not currently publish.
e.g. For comcast. and assuming I use spfhelp.net, I will add these lines to the zonefile 
for spfhelp.net (thanks to ScottK for the IP ranges)
comcast.net.proxy.spfhelp.net.  IN  TXT   "v=spf1 ?ip4:204.127.202.0/24 
?ip4:204.127.198.0/24 ?ip4:216.148.227.0/24 ?ip4:63.240.76.0/24 ~all"
comcast.net.spfhelp.net.  IN  SPF   "v=spf1 ?ip4:204.127.202.0/24 ?ip4:204.127.198.0/24 
?ip4:216.148.227.0/24 ?ip4:63.240.76.0/24 ~all"
Anyone needing to use comcast could therefore add include:comcast.net.proxy.spfhelp.net to 
their record.
I will post all such proposed records here and on spf-help for comment, amendment, etc., 
prior to actually doing them. I will also use the least disruptive method os zonefile 
editing by adjusting the ttl's as needed.
Comments, criticism, advice, offers of help all welcome ;-)

Slainte,
JohnP.