[mail-vet-discuss] results should be method specific

[Tony Hansen]

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.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