On 06/Jan/12 00:37, Scott Kitterman wrote:
> "Murray S. Kucherawy" <[email protected]> wrote:
>>
>>> Assuming (and I think it's a safe assumption) that SPFbis sticks with
>>> interoperability with current deployments as a goal, it can't change.
Julian's SPF scope adds no results, but I think they'll have to be
reported with a different method. For a shot in the dark:
Authentication-Results: authserv-id.example;
spf=pass smtp.mailfrom=example.org;
spf-scope=fail scope-id=hdr-from header.from=example.com
To clarify, spf-scope would have to be registered at IANA's for the
above to be correct. By contrast, the values of the Auth-Failure
field, such as the "spf" we're talking about, don't have a IANA register.
>>Then how about:
>>
>>spf: The evaluation of the author domain's SPF record produced a
>>"none", "fail", "softfail", "temperror" or "permerror" result. ("none"
>>is not strictly a failure per [SPF], but a service that demands
>>successful SPF evaluations of clients could treat it like a failure.)
>>
>>?
>
> Looks good.
I liked better Murray's previous text. This one is acceptable as long
as it doesn't imply that "SPF evaluations" have to be carried out
according to [SPF] only. Thus a report could set the following in its
2nd part:
Feedback-Type: auth-failure
Auth-Failure: spf
Authentication-Results: authserv-id.example;
spf-scope=fail scope-id=hdr-from header.from=example.com
(Note that the value "spf" is in a different field than keywords
listed in its definition.)
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
