On Tue, Feb 03, 2004 at 11:44:26AM +0100, Christophe Saout wrote:
| Am Di, den 03.02.2004 schrieb Paul Fisher um 06:12:
|
| > 2. Semantics of "include" mechanism are no longer clear
| >
| > Since the extra result values were added in 02.9.5, it's not clear how
| > "include" should behave. For example, Test #82 seems to indicate that
| > if a recursive query returns "none", then "include" should return
| > "unknown". Could text be added to Section 4.2 that covers all
| > possible recursive return values, much like the "include" section from
| > the November 02.7 RFC Draft (when softfail was last seen)?
|
| When the recursive lookup returns either ("none", "fail", "softfail" or
| "neutral") the include mechanism does not match. "pass" makes it return
| the prefix (+ -> "pass", - -> "fail", ~ -> "softfail", ? -> "neutral").
| Errors are directly returned.
The use case is:
vanity.domain.com TXT "v=spf1 include:myisp.com -all"
myisp.com TXT "v=spf1 a mx -all"
But then one day mysip.com's DNS gets messed up and the SPF record is
lost.
vanity.domain.com TXT "v=spf1 include:myisp.com -all"
myisp.com NXDOMAIN
So if myisp.com has no SPF record, do you want vanity.domain.com to
return FAIL or UNKNOWN?
If you want it to return FAIL, you treat "none" as no-match.
If you want it to return UNKNOWN, you treat "none" as an exception, UNKNOWN.
I think returning UNKNOWN is safer.
* * *
I have updated 4.2 in my working draft, 02.9.6, to say:
Example.net could say
"v=spf1 include:example.com include:example.org -all".
This mechanism matches when the new query result returns a pass, and
doesn't match when the result is fail. However, if the new query
returns none, unknown, or error, then processing of the entire SPF
query stops immediately and returns the unknown or error result.
pass => match, return the prefix value for "include"
fail => no match, continue processing
softfail => no match, continue processing
neutral => no match, continue processing
error => error, abort
unknown => unknown, abort
none => unknown, abort # see below
If the parent domain includes another domain, and that domain one day
loses its SPF record, it is better for the query to abort with
"unknown" than to continue on to a potential "-all".
If the text could be improved, please send me a patch :)
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
| Am Di, den 03.02.2004 schrieb Paul Fisher um 06:12:
|
| > 2. Semantics of "include" mechanism are no longer clear
| >
| > Since the extra result values were added in 02.9.5, it's not clear how
| > "include" should behave. For example, Test #82 seems to indicate that
| > if a recursive query returns "none", then "include" should return
| > "unknown". Could text be added to Section 4.2 that covers all
| > possible recursive return values, much like the "include" section from
| > the November 02.7 RFC Draft (when softfail was last seen)?
|
| When the recursive lookup returns either ("none", "fail", "softfail" or
| "neutral") the include mechanism does not match. "pass" makes it return
| the prefix (+ -> "pass", - -> "fail", ~ -> "softfail", ? -> "neutral").
| Errors are directly returned.
The use case is:
vanity.domain.com TXT "v=spf1 include:myisp.com -all"
myisp.com TXT "v=spf1 a mx -all"
But then one day mysip.com's DNS gets messed up and the SPF record is
lost.
vanity.domain.com TXT "v=spf1 include:myisp.com -all"
myisp.com NXDOMAIN
So if myisp.com has no SPF record, do you want vanity.domain.com to
return FAIL or UNKNOWN?
If you want it to return FAIL, you treat "none" as no-match.
If you want it to return UNKNOWN, you treat "none" as an exception, UNKNOWN.
I think returning UNKNOWN is safer.
* * *
I have updated 4.2 in my working draft, 02.9.6, to say:
Example.net could say
"v=spf1 include:example.com include:example.org -all".
This mechanism matches when the new query result returns a pass, and
doesn't match when the result is fail. However, if the new query
returns none, unknown, or error, then processing of the entire SPF
query stops immediately and returns the unknown or error result.
pass => match, return the prefix value for "include"
fail => no match, continue processing
softfail => no match, continue processing
neutral => no match, continue processing
error => error, abort
unknown => unknown, abort
none => unknown, abort # see below
If the parent domain includes another domain, and that domain one day
loses its SPF record, it is better for the query to abort with
"unknown" than to continue on to a potential "-all".
If the text could be improved, please send me a patch :)
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h