Re: SPF isn't going to change, was Deprecating SPF
Andrew Sullivan <[email protected]>
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
Hi, Thanks for the outline of the transition strategy. Let me walk through it, piece by pice, and see how it works. I'm going to use "SPF-99" and "SPF-16" in what follows to disambiguate the query cases. I'll call the existing SPF implementations "SPFCheck" -- no matter what they do -- and the new implementations that prefer SPF-99 first, then SPF-16 "SPFCheckNG". On Sat, Aug 24, 2013 at 12:36:57PM +1000, Mark Andrews wrote: > You say MUST query for SPF and if there is a NO DATA response you > MAY query for TXT. Modern spf libraries already do this. Legacy > SPF checkers are no longer compliant. Even checkers running under > Windows can meet this MUST. I am an SPF validator. On day 0, there are very few people publishing SPF-99 records, and many publishing SPF-16 records. I have a lot of mail volume coming in. What is my incentive to embrace SPFCheckNG? Please address the latency effects for large mail operators. > You say that nameservers SHOULD synthesis SPF records from TXT > v=spf1 records. This helps registrars stuck with broken web > interfaces. Code for this is written. I'm an operator of a DNS zone. I publish TXT and SPF records. On day 0, there are very few people publishing SPF-99 records. What is my incentive to deploy code that aoutomatically increases my storage cost and my opportunity for bugs, given that everyone who accepts my mail is satisfied with SPF-16? > You say that nameservers SHOULD reject loading of zones without SPF > records when there are v=spf1 TXT records. This provides education > for everybody else. Code for this is written. I'm an operator of a DNS zone. On day 0, my zone works. What is my incentive to accept a new DNS server software update that makes my zone broken, given that it was working on day 0-1? I offer my thanks in advance for your investigation of the answers to the above. Best, A -- Andrew Sullivan [email protected] _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext