-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of wayne
Sent: Tuesday, July 19, 2005 1:55 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: "/" inside an exists: domain-spec?
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0507182114310(_dot_)13934-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
The 10 MX limit is a MUST, so I think PermError is appropriate.
Question for Frank, if >10 MX are to be ignored, does that mean:
a) ignore the MX mechanism entirely
b) use only the first 10 sorted by
i) priority,domain
ii) priority,random
If b.i, how do you defend rather arbitrary ordering by domain?
If b.ii, how you do you defend random results?
See section 5.4 "mx":
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#me
ch-mx
To prevent DoS attacks, more than 10 MX names MUST NOT be looked up
during the evaluation of an "mx" mechanism (see Section 10
(Security Considerations)). If any address matches, the mechanism
matches.
So, the mx: mechanism should not be ignored, but no ordering of which
10 MX records should be checked is given. I guess it could give an
ordering, but really, if a domain owner wants sensible results, they
shouldn't have that many MX records and use an mx: mechanism.
The same goes for PTR records and the ptr: mechanism.
I think, in practice, that you will find very few cases of more than
10 MX records.
-wayne
OK. I guess then that we have three types of errors. Two explicit and one
silent.
2.5.6. TempError
A "TempError" result means that the SPF client encountered a transient error
while performing the check. Checking software can choose to accept or
temporarily reject the message. If the message is rejected during the SMTP
transaction for this reason, the software SHOULD use an SMTP reply code of
451 and, if supported, the 4.4.3 DSN code.
2.5.7. PermError
A "PermError" result means that the domain's published records couldn't be
correctly interpreted. This signals an error condition that requires manual
intervention to be resolved, as opposed to the TempError result. Be aware
that if the domain owner uses macros (Section 8 (Macros)), it is possible
that this result is due to the checked identities having an unexpected
format.
Silent incomplete processing
...To prevent DoS attacks, more than 10 MX names MUST NOT be looked up
during the evaluation of an "mx" mechanism (see Section 10 (Security
Considerations)). If any address matches, the mechanism matches....
...To prevent DoS attacks, more than 10 PTR names MUST NOT be looked up
during the evaluation of a "ptr" mechanism (see Section 10 (Security
Considerations)). If <ip> is among the returned IP addresses, then that
domain name is validated. ...
... When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there
MUST be a limit of no more than 10 MX or PTR RRs looked up and checked....
Now when I added all that up, it looked like PermError to me.
"A 'PermError' result means that the domain's published records couldn't be
correctly interpreted." In my mind, as soon as the SPF record wants me to
look up that 11th MX or PTR, the record couldn't be correctly interpreted.
"This signals an error condition that requires manual intervention to be
resolved..." Since those extra MX/PTR records aren't going away, manual
intervention is required.
As I read the draft, it seems clear to me that more than 10 MX/PTR is a
PermError. Otherwise the protocol is unreliable. Silent errors and
inconsistencies are exactly what we need to avoid and exactly what everyone
was arguing we needed to avoid when I wanted to go back to PermError/Unknown
~ Neutral/None.
It seems to me then, that this is a bug in the draft.
Just look at the multiple requirements example to see how this could have a
very bad effect:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anc
hor46
I don't see an arguement in favor of having check_host be silently wrong.
Scott K