spf-discuss
[Top] [All Lists]

Re: Interpreting Results From Multiple "Identical" RR Sets (Was several threads on type 99)

2005-08-12 08:30:10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Scott Kitterman wrote:
Dealing with SPF records in two different record types with live data is the
one part of SPF that is, in fact, brand new and experimental.  The
discussion we've been having on this topic makes it clear that there are
some lessons to be learned.  I also think that many of these lessons are
generic to other technologies (e.g. DKIM) that hope to do something similar.
So it isn't surprising we'd learn some things that ought to be folded into
the AUTH48.

The first point I would like to make is that while some people have issues
with "MUST be identical", from a validation/implementation perspective this
is a very simple concept to code.  Type 99 support for pyDNS was, IIRC 4
lines of code and multiple rr support (TXT/type 99) in pySPF was 6.  If we
say anything other than "MUST be identical", then implementation complexity
will jump considerably.

You say this, then you go on to propose that SPF/type99 record take priority
over SPF/TXT records below. Simply put, if we say:
if lookup(SPF)
then use SPF
else if lookup(TXT)
then use TXT
else no record.

The issue of whether the SPF/type99 record is identical
to the SPF/TXT record is a moot point, and should not
be mentioned at all as a requirement (MUST), but rather as an
advisory (SHOULD) since for most sites they should be the same
if both present, but there may exist sites for which they need to be
different to account for non-compliant receivers, and allowing
for the possibility does no harm that I can perceive.



This isn't as complex as it probably sounds.

The current hierarchy of responses is:

1.  TempError - if either RR returns an error it's a TempError
2.  SPF - if SPF records are present in both SPF and TXT, use SPF
3.  TXT or SPF - if SPF records are only in one RR type, use it
4.  None - If no records are returned and there are no errors, the result is
None.

All I'm really proposing is that we say that any answer on either RR type
means it's not a TempError since we have good evidence the the remote DNS is
uo and reachable:

1.  SPF - if SPF records are present in both SPF and TXT, use SPF
2.  TXT or SPF - if SPF records are only in one RR type, use it
3.  None - If no records are returned and there are no errors, the result is
None.
4.  TempError - if either RR returns an error it's a TempError.

The impact of these changes would be confined to paragraph 4.4:

http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anc
hor19

If this has any legs, I'll write up proposed language for the AUTH48.

My opinion on this is starting to swing back to "none". The only
apparent hazard of ignoring DNS errors or missing include:'s is the
possibility of a false reject when a record reaches "-all" without
a match. Since generating error states when an include: is missing
is likely to result in more DSN's or rejects for cases where the missing
include: isn't even involved it seems to be more demanding on the
system.

One could reject or DSN on errors, to let the publishing domain
owner know that they have a problem, but since this _is_ e-mail
and the default has always been "when in doubt, deliver", it makes
more sense to treat SPF errors as a lack of a (compliant) SPF record.
i.e. if you can't be bothered to publish properly, your record
     will be ignored and you gain no benefit from it.


- --
Daniel Taylor          VP Operations            Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com   http://www.vocalabs.com/        
(952)941-6580x203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC/MCC8/QSptFdBtURAn6OAJ0bi/5HVNOjWE1NcVhAW3pTKZJ3qgCeNhkD
abIjUNzDQIBoBWm3vExMTvc=
=/SZr
-----END PGP SIGNATURE-----