mail-vet-discuss
[Top] [All Lists]

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

2008-02-28 14:57:33
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 

<Prev in Thread] Current Thread [Next in Thread>