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.
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]
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]
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
[SPF] and [SENDERID] results are indicated with the methods spf-method
and senderid-method respectively. The spf-method MUST
contain a ptype of ptype-spf whose value contains the [SMTP].mailfrom or
[SMTP].helo address. The senderid-method MUST return a ptype-senderid
specifying the header field found using PRA defined in [SENDERID]
The result values used by spf-method and senderid-method are as follows:
pass: The message passed the authentication method's tests.
hardfail: The message did not pass the authentication method's
tests.
neutral: The message was passed through the authentication algorithm
but no conclusion about the sender's authenticity could be
reached.
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 policy record from DNS. A later attempt may produce a
final result.
[mat: does this make any sense for SPF? SID?]
permerror: The message could not be verified due to some error which
is unrecoverable, such as a required header field being absent. A
later attempt is unlikley to produce a final result.
[mat: shouldn't we have other values for like -all? that's what I'm
thinking
about for SSP; see below]
2.4.3. IPREV Results
IPREV results are indicated using the method "iprev".
The iprev-method MUST return a ptype-iprev whose
value is the client IP address initiating the connection.
The result values used by the iprev-method, defined in
Section 3, are as follows:
pass: The reverse DNS evaluation succeeded, i.e. the "reverse" and
"forward" lookup results were in agreement.
hardfail: The reverse DNS evaluation failed. In particular, the
"reverse" and "forward" lookups each produced results but they
were not in agreement.
softfail: The reverse DNS evaluation failed. In particular, one or
both of the "reverse" and forward lookups returned no data (i.e. a
DNS reply code of NODATA).
temperror: The reverse DNS evaluation could not be completed due to
some error which is likely transient in nature, such as a
temporary DNS error. A later attempt may produce a final result.
permerror: The reverse DNS evaluation could not be completed due to
some error which is unrecoverable (e.g. a DNS reply code of
NXDOMAIN). A later attempt is unlikely to produce a final result.
2.4.4. SMTP AUTH Results
SMTP AUTH results are indicated using the method auth-method.
The auth-method MUST return a ptype of ptype-smtp whose
value is the [SMTP].mailfrom address, if available.
The result values used by the auth-method are as follows:
none: SMTP authentication was not attempted.
pass: The SMTP client had authenicated to the server reporting the
result using the protocol described in [AUTH].
hardfail: The SMTP client had attempted to authenticate to the
server using the protocol described in [AUTH] but was not
successful, yet continued to send the message about which a result
is being reported.
temperror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the
attempt due to some error which is likely transient in nature,
such as a temporary LDAP lookup error. A later attempt may
produce a final result.
Note that an agent making use of the data provided by this header
field SHOULD consider "hardfail" and "temperror" to be the synonymous
in terms of message authentication, i.e. the client did not
authenticate.
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