see below
Michael Thomas wrote:
The current draft breaks out the meaning of the results into a method
specific section. This is an improvement over the previous draft which
didn't discuss them at all, but shoe-horning the global set of results
into method specific results seems rather contrived and arbitrary.
Why, for example, is an SSP all failure dkim-ssp=softfail? Worse is
that the current draft doesn't allow for more results than are in
that table. That means, for example, that SSP can't return NXDOMAIN
when that's what it found.
I'd like to propose that we name the results in a method specific
way, as well as remove result codes that don't seem to actually
even apply to that method.
+1
Here's a stab at section 2.4:
2.4. Result Values
Each individual authentication method returns method specific
result values. The
subsections below define these results for the authentication
methods specifically supported by this memo. New methods not
specified in this document intended to be supported by header field
defined in this memo MUST include a similar result table either in
its defining memo or in a supplementary one.
2.4.1. DKIM and DomainKeys Results
[DKIM] and [DOMAINKEY] results are indicated with dkim-method
and domainkeys-method respectively. The dkim-method MUST
contain a ptype of ptype-dkim whose value contains the i= value for
[DKIM] (or
its default if missing). The domainkeys-method MUST
return a ptype-domainkey for the first [MAIL].From address.
Note that there may be multiple signatures in a given message.
When multiple signatures are present, the Authentication Results
SHOULD produce results for each signature present.
Each [DKIM] or [DOMAINKEYS] signature present that is evaluated
produce the following dkim-method or domainkeys-method result values:
[mat: i've removed the "acceptable" parts... i'm not sure what that's
bringing to the table... why should auth res go into the filter's
domain? same goes for other methods, I suspect]
none: No valid signatures were found. [mat: is this needed?? i just
use the ssp result here]
There are people who have expressed a desire to have an A-R header that
list results for all of the auth types they are processing. In the case
of DKIM/DK, a non-existent signature header would result in "dkim=none".
pass: The signature passed verification.
fail: The message was signed and the signature but it failed the
verification test.
[mat: i nuked neutral and permerror... how are they different from fail?
less is better here, I think]
+1
temperror: The message could not be verified due to some error which
is likely transient in nature, such as a temporary inability to
retrieve a [DKIM] selector resource record. A later attempt may
produce
a final result.
2.4.2. SPF and Sender-ID Results
No comments on the rest.
Tony Hansen
tony(_at_)att(_dot_)com
2.4.5. SSP Results
SSP results are indicated with the method ssp-method. The ssp-method
MUST return a ptype of ptype-ssp whose value is the [MAIL].From
address being evaluated.
Note that [SSP] can return multiple result values if the [MAIL].From
field contains multiple addresses. When multiple addresses are present,
the Authentication Results SHOULD produce multiple individual results
for each address.
The result values used by ssp-method are as follows:
pass: A valid first party signature as defined by [SSP] was present
in the message for this given [MAIL].From address tested.
unknown: No valid first party signature was present in the message,
and the SSP result indicates that the [MAIL].From domain publishes
the "unknown" practice. This result is also produced in other
situations
where a result cannot be determined, such as when no valid [SSP]
resource
record was found, or the message contained a malformed or missing
[MAIL].From domain.
all-fail: No valid first party signature was present in the message,
and the [SSP] result indicates that the [MAIL].From domain publishes
the "all" practice.
discardable-fail: No valid first party signature was present in the
message,
and the [SSP] result indicates that the [MAIL].From domain publishes
the "discardable" practice.
nxdomain: No valid first party signature was present in the message,
and the [SSP] result indicates that the [MAIL].From domain or its
parent domain was not found.
temperror: The message could not be verified due to some error which
is likely transient in nature, such as a temporary inability to
retrieve the [SSP] resource record. A later attempt may produce a
final
result.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html