Hey guys, I cleared up some confusion in the return codes --- the old
"unknown" conflated two concepts, an explicit "?" and an error state
caused by parsing / interpretation problems. They have been
disambiguated into "neutral" ("?") and "unknown".
Functionally they are identical so this change is fully backward
compatible with existing libraries.
I also added two new return codes, "none" and "softfail" as per
discussion earlier this week.
Implementors, please add these codes to your Received-SPF header.
It took me about 20 minutes to make the change in Mail::SPF::Query.
On Thu, Jan 29, 2004 at 08:24:02PM -0500, Philip Gladstone wrote:
| Does this mean I should change MSQ to return these 7 results? I think
| that it makes sense to do so, and I will do so unless someone shouts
I believe they're all in 1.991 as of late last night.
| mengwong@dumbo.pobox.com wrote:
|
| >
| >3 Interpretation
| >
| > When an SPF client evaluates a domain's SPF policy, this evaluation
| > produces one of seven results:
| >
| > None: The domain does not publish SPF data.
| >
| > Neutral (?): The SPF client MUST proceed as if a domain did not
| > publish SPF data. This result occurs if the domain explicitly
| > specifies a "?" value, or if processing "falls off the end" of
| > the SPF record.
| >
| > Pass (+): the message meets the publishing domain's definition of
| > legitimacy. MTAs proceed to apply local policy and MAY accept or
| > reject the message accordingly.
| >
| > Fail (-): the message does not meet a domain's definition of
| > legitimacy. MTAs MAY reject the message using a permanent
| > failure reply code. (Code 550 is RECOMMENDED. See RFC2821 [11]
| > section 7.1)
| >
| > Softfail (~): the message does not meet a domain's strict
| > definition of legitimacy, but the domain cannot confidently state
| > that the message is a forgery. MTAs SHOULD accept the message
| > but MAY subject it to a higher transaction cost, deeper scrutiny,
| > or an unfavourable score in a rule-based system.
| >
| > There are two error conditions, one temporary and one permanent.
| >
| > Error: indicates an error during lookup; an MTA MAY reject the
| > message using a transient failure code, such as 450.
| >
| > Unknown: indicates incomplete processing: an MTA MUST proceed as
| > if a domain did not publish SPF data.
| >
| >So what used to be "unknown" has now been broken out into
| >"unknown-as-error" and "neutral-as-explicitly-defined".
| >
| >You end up with the same behaviour but you can speak more accurately
| >about the semantics.
| >
| >And we bring back softfail because I really think AOL should be doing
| >~all and not ?all. Of all the ISPs in the world they probably have the
| >most tightly constrained userbase, and can say with the most confidence
| >that if it's not coming through an AOL server, it's not really an AOL
| >user. Correct me if I'm wrong.
| >
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
"unknown" conflated two concepts, an explicit "?" and an error state
caused by parsing / interpretation problems. They have been
disambiguated into "neutral" ("?") and "unknown".
Functionally they are identical so this change is fully backward
compatible with existing libraries.
I also added two new return codes, "none" and "softfail" as per
discussion earlier this week.
Implementors, please add these codes to your Received-SPF header.
It took me about 20 minutes to make the change in Mail::SPF::Query.
On Thu, Jan 29, 2004 at 08:24:02PM -0500, Philip Gladstone wrote:
| Does this mean I should change MSQ to return these 7 results? I think
| that it makes sense to do so, and I will do so unless someone shouts
I believe they're all in 1.991 as of late last night.
| mengwong@dumbo.pobox.com wrote:
|
| >
| >3 Interpretation
| >
| > When an SPF client evaluates a domain's SPF policy, this evaluation
| > produces one of seven results:
| >
| > None: The domain does not publish SPF data.
| >
| > Neutral (?): The SPF client MUST proceed as if a domain did not
| > publish SPF data. This result occurs if the domain explicitly
| > specifies a "?" value, or if processing "falls off the end" of
| > the SPF record.
| >
| > Pass (+): the message meets the publishing domain's definition of
| > legitimacy. MTAs proceed to apply local policy and MAY accept or
| > reject the message accordingly.
| >
| > Fail (-): the message does not meet a domain's definition of
| > legitimacy. MTAs MAY reject the message using a permanent
| > failure reply code. (Code 550 is RECOMMENDED. See RFC2821 [11]
| > section 7.1)
| >
| > Softfail (~): the message does not meet a domain's strict
| > definition of legitimacy, but the domain cannot confidently state
| > that the message is a forgery. MTAs SHOULD accept the message
| > but MAY subject it to a higher transaction cost, deeper scrutiny,
| > or an unfavourable score in a rule-based system.
| >
| > There are two error conditions, one temporary and one permanent.
| >
| > Error: indicates an error during lookup; an MTA MAY reject the
| > message using a transient failure code, such as 450.
| >
| > Unknown: indicates incomplete processing: an MTA MUST proceed as
| > if a domain did not publish SPF data.
| >
| >So what used to be "unknown" has now been broken out into
| >"unknown-as-error" and "neutral-as-explicitly-defined".
| >
| >You end up with the same behaviour but you can speak more accurately
| >about the semantics.
| >
| >And we bring back softfail because I really think AOL should be doing
| >~all and not ?all. Of all the ISPs in the world they probably have the
| >most tightly constrained userbase, and can say with the most confidence
| >that if it's not coming through an AOL server, it's not really an AOL
| >user. Correct me if I'm wrong.
| >
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h