On Mon, 18 Sep 2006, Scott Kitterman wrote:
> that..." isn't justification. The RFC explicitly calls out the cases that
> get a permerror and this isn't one of them. I wish the RFC were different,
> but it's not.
>
> We can't use the test suite to back-door in requirements that aren't in the
> RFC. I think it undermines the credibility of the test suite.
>
> Feel free to forward this to Julian or the appropriate lists.
>
Did that. Your opinion is in the minority. (Doesn't mean its wrong.)
The "some people feel that..." refers to the minority opinion. I didn't
take a formal poll, however.
In defense of the majority, let me point out that a permerror result
is explicitly required for the other limits, the MX limit immediately follows
the others, and an English speaking reader can reasonably assume the
permerror result applies to the MX limit as well.
Furthermore, returning a pass, neutral, or softfail, or fail in this case
goes completely against the spirit of those results.
In defense of the minority opinion, at least the order the MX records are
checked in is well defined - provided there aren't any leftover cache records
(which can cause unstable results for other mechanisms as well) AND that the
priorities are unique.
Perhaps a compromise is to have permerror as the preferred result, and
neutral as an acceptable result. I mean, if the RFC doesn't explicitly
designate the required result, you can pick anything you want, right?
tests:
mx-limit:
description: >-
there MUST be a limit of no more than 10 MX looked up and checked.
comment: >-
While the MX and PTR limits immediately follow a paragraph mandating
a permerror for exeeding limits, some of the SPF community feel that
more than 10 MX records should simply be ignored. However, ignoring
the excess MX records can cause SPF results that are different for
each query. A permerror is the right response.
spec: 10.1/7
helo: mail.example.com
host: 1.2.3.5
mailfrom: foo@e4.example.com
result: permerror
zonedata:
mail.example.com:
- A: 1.2.3.4
e4.example.com:
- SPF: v=spf1 mx
- MX: [0, mail.example.com]
- MX: [1, mail.example.com]
- MX: [2, mail.example.com]
- MX: [3, mail.example.com]
- MX: [4, mail.example.com]
- MX: [5, mail.example.com]
- MX: [6, mail.example.com]
- MX: [7, mail.example.com]
- MX: [8, mail.example.com]
- MX: [9, mail.example.com]
- MX: [10, e4.example.com]
- A: 1.2.3.5
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
> that..." isn't justification. The RFC explicitly calls out the cases that
> get a permerror and this isn't one of them. I wish the RFC were different,
> but it's not.
>
> We can't use the test suite to back-door in requirements that aren't in the
> RFC. I think it undermines the credibility of the test suite.
>
> Feel free to forward this to Julian or the appropriate lists.
>
Did that. Your opinion is in the minority. (Doesn't mean its wrong.)
The "some people feel that..." refers to the minority opinion. I didn't
take a formal poll, however.
In defense of the majority, let me point out that a permerror result
is explicitly required for the other limits, the MX limit immediately follows
the others, and an English speaking reader can reasonably assume the
permerror result applies to the MX limit as well.
Furthermore, returning a pass, neutral, or softfail, or fail in this case
goes completely against the spirit of those results.
In defense of the minority opinion, at least the order the MX records are
checked in is well defined - provided there aren't any leftover cache records
(which can cause unstable results for other mechanisms as well) AND that the
priorities are unique.
Perhaps a compromise is to have permerror as the preferred result, and
neutral as an acceptable result. I mean, if the RFC doesn't explicitly
designate the required result, you can pick anything you want, right?
tests:
mx-limit:
description: >-
there MUST be a limit of no more than 10 MX looked up and checked.
comment: >-
While the MX and PTR limits immediately follow a paragraph mandating
a permerror for exeeding limits, some of the SPF community feel that
more than 10 MX records should simply be ignored. However, ignoring
the excess MX records can cause SPF results that are different for
each query. A permerror is the right response.
spec: 10.1/7
helo: mail.example.com
host: 1.2.3.5
mailfrom: foo@e4.example.com
result: permerror
zonedata:
mail.example.com:
- A: 1.2.3.4
e4.example.com:
- SPF: v=spf1 mx
- MX: [0, mail.example.com]
- MX: [1, mail.example.com]
- MX: [2, mail.example.com]
- MX: [3, mail.example.com]
- MX: [4, mail.example.com]
- MX: [5, mail.example.com]
- MX: [6, mail.example.com]
- MX: [7, mail.example.com]
- MX: [8, mail.example.com]
- MX: [9, mail.example.com]
- MX: [10, e4.example.com]
- A: 1.2.3.5
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com