In
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20040413200206(_dot_)0554a408(_at_)imaps(_dot_)mailpen(_dot_)net>
"Dean Gibson (Mail Administrator)" <spf(_at_)ultimeth(_dot_)com> writes:
Earlier today I was using an (unnamed, for reasons you will see) SPF
test site to validate my SPF TXT record:
*sigh*
I know of two SPF test sites. Both of them get this wrong. (Well,
the spf.pobox.com/why.html webpage is also kind of a test site and it
gets it right.
I believe that our method is correct --
http://spf.pobox.com/draft-mengwong-spf-00.txt section 4.6 shows
that it should match if the reverse DNS entry ends in "verizon.net".
I found this response incredulous for the following reasons:
1. He claims that his method is correct, when it disagrees with an SPF
test implemented by the author of the RFC on his web page.
The perl SPF implementation, libspf and libspf-alt all get this right.
I don't want to "dump" on
the author of the first SPF test site, as he is trying to provide a
valuable service, but I found his justification of his test methods
without any logical basis.
I agree and I greatly appreciate the efforts that all of the test
sites have put into this stuff. However, I know of bugs in every SPF
implementation that I've been able to test, and you have found a bug.
ps: I will increase the TTL on the SPF TXT record when I am done
testing. Any recommendations for the TTL (my normal value is 8 hours)?
Personally, I have most of my TTLs set to several days since I
generally know several days in advance if I need to change anything.
Note that I can *add* something at any time, it is just stuff that
won't work with the old value that is a problem. If it looks like I
may need to update stuff soon, I drop the TTL down to a matter of
hours or minutes.
-wayne