I have a couple of implementation questions arising from the spec:
Q1.
It is not immediately clear what the use of the '?' modifier on individual
mechanisms may be, since it does not 'short-circuit' evaluation.
I assume that if no subsequent mechanisms match, then the result of the prior
'?'-modified match would be returned. Would this be the most-recent or the
least-recent such match? This is relevant for calculating the result's cache
TTL using the various DNS record TTLs.
Would it be fair to describe a '?'-modified match as replacing the default
modifier for subsequent evaluation? In which case the most-recent such match
would be the most logical interpretation.
If this interpretation is correct, how is the new default modifier interpreted
for subsequent mechanisms which have no explicit modifier? Does the following
from section 3.0 of the spec also apply here:
If "default=deny", matching mechanisms return "allow" by default.
If "default=softdeny", matching mechanisms return "allow" by default.
If "default=unknown", matching mechanisms return "allow" by default.
If "default=allow", matching mechanisms return "deny" by default.
If so then can we say that any not-explicitly-modified match subsequent to a
'?'-match will be interpreted as 'allow', regardless of what was in your
original default modifier?
Q2.
The PTR section is really confusing. Am I supposed to do a PTR lookup of the
IP at in-addr.arpa, or somewhere else? I thought the in-addr.arpa mappings
were supposed to be one-to-one? Are there any examples of one-to-many
mappings there at present? Could a malicious domain do this?
Additional comment:
One of the things I like about the original SMTP spec (rfc821) is the
inclusion of implementation guides in the form of state diagrams. With
something more complex like SPF it would be wise to include such things.
In particular I am worried about the complexity of getting result caching
calculations right, given the number of records brought into play. This
requires some analysis to get right and at worst might leave individual sites
or perhaps the wider internet open to DoS and DDoS attacks if a poorly
considered implementation becomes widespread (eg if any of sendmail, qmail,
exim, exchange etc get it wrong)
Could we have some discussion of and notes on result/partial result caching
please?
- Dan
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡