-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
Alex van den Bogaerdt wrote:
Are you saying here you can point to RFC4408 and justify returning
"None" in the discussed case where looking for SPF does not return
an error, and looking for TXT does?
I can understand your justification when SPF times out and TXT does
not, but we're discussing the opposite?
Yes, but as Guy just posted, RFC 4408 doesn't care which way it happens.
And I think that's exactly the issue at hand. I do understand the
rationale for the spec saying what it is saying, but I think special-
casing the "SPF = None, TXT = timeout" case would have been wise, given
the fact that "no SPF-type SPF records but some TXT-type SPF records" is
by far the dominant case now and certainly will be for quite some time.
Having "TempError" returned in that case would even have been backwards
compatible to the earlier SPF specs.
I agree with Wayne that the SPF RR type complicates things, but unlike him,
I think it's with a purpose. Yes, (ab)using the TXT type is viable (as
can be observed in the real world), but IMO a dedicated RR type is a good
thing. But that discussion is for another thread (on another day).
It is too late to fix things for SPFv1 now, but a cross table _could_ have
avoided the need for lengthy descriptions of the required behavior:
| If an implementation checks both the SPF and TXT RR types, and either of
| the queries fails, it should determine its result according to the
| following table:
|
| | SPF type |
| +-------------+-----------+--------------+
| | no SPF recs | time-out | RCODE != 0/3 |
| -----+--------------+-------------+-----------+--------------+
| | no SPF recs | None | None | None |
| +--------------+-------------+-----------+--------------+
| TXT | time-out | TempError | TempError | TempError |
| type +--------------+-------------+-----------+--------------+
| | RCODE != 0/3 | TempError | TempError | TempError |
| -----+--------------+-------------+-----------+--------------+
For illustration, the spec currently requires the following behavior:
| | SPF type |
| +-------------+-----------+--------------+
| | no SPF recs | time-out | RCODE != 0/3 |
| -----+--------------+-------------+-----------+--------------+
| | no SPF recs | None | None | None |
| +--------------+-------------+-----------+--------------+
| TXT | time-out | None | TempError | TempError |
| type +--------------+-------------+-----------+--------------+
| | RCODE != 0/3 | None | TempError | TempError |
| -----+--------------+-------------+-----------+--------------+
For a future SPFv3, it is likely that it would support the SPF RR type only
(which would also be a nice incentive for domain owners to have their
software/equipment upgraded to support it), so there wouldn't be any
complications. (However, I wouldn't like to carve that decision into
stone just yet.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFpP26wL7PKlBZWjsRAmRTAKCVpFhdRodXSPhAKJgbScn23TEejgCgkKMB
rGolz0Z+SpLldb5L80LRbNQ=
=A6TV
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735