ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations

2010-08-24 10:59:02


On 8/24/2010 6:42 AM, MH Michael Hammer (5304) wrote:
Please show us in RFC4871 where it says DKIMs main purpose is assessment
by reputation filtering engines.

It's a fair question, but answering it encounters three core problems.

The first is that 4871 is not a systems specification.  It's a component 
specification.  So it might or might not contain language about the way a 
signature is intended to fit into a larger processing environment.

The second is that we've been struggling with finding the right language for 
describing systems issues about DKIM.  Note that we even managed to write a 
protocol document without defining the protocol's output, which is why we 
needed 
an errata document. So we need to be careful about using RFC 4871 outside of 
the 
larger context of work done since it was published.

As I recall Mark Delany's explanation of the original intent for Domainkeys, it 
was considered a primary goal to design the system in a way that targeted 
implementation in the email infrastructure rather than email end systems.  The 
reduced granularity, of having an organization rather than user identifier, was 
an example of this. It massively reduced administrative overhead.

And third, if DKIM has a "main purpose" for something involving end user 
processing, where is the detailed specification or guidance that would 
encourage 
interoperable use of it?  Without that, use becomes idiosyncratic and therefore 
non-interoperable.  (This is a version of the same logic we all debated we had 
about i=/d=, concerning signer intent and assessor interpretation.)

That said, your citation of RFC 4871:

6.3.  Interpret Results/Apply Local Policy
...
Once the signature has been verified, that information MUST be
    conveyed to higher-level systems (such as explicit allow/whitelists
    and reputation systems) and/or to the end user.

Is at least nicely in the right arena, IMO.


But again, no verbage that matches your assertion.

I wasn't aware that my statement was offered as a quotation.  I certainly 
didn't 
intend it to be.


On the other hand...

If we look at additional DKIM related RFCs, the only explicit use of the
identifier is found in the ADSP RFC...

You missed the relevant, related RFCs:

Errata, RFC 5672:
8.  RFC 4871, Section 2.11, Identity Assessor
...
      A module that consumes DKIM's mandatory payload, which is the
      responsible Signing Domain Identifier (SDID).  The module is
      dedicated to the assessment of the delivered identifier.  Other
      DKIM (and non-DKIM) values can also be delivered to this module as
      well as to a more general message evaluation filtering engine.
      However, this additional activity is outside the scope of the DKIM
      signature specification.


Overview, RFC 5585, <http://dkim.org/specs/rfc5585.html#rfc.section.5>:

     .        +-----+--+----+      +-------+              .
     .              |  |          / Check   \<............+
     .              |  +-------->/  Signing  \
     .              |           /   Practices \<..........+
     .              |          +-------+-------+          .
     .              |                  |                  .
     .              |                  V                  .
+----+--------+     |            +-----------+     +------+-----+
|Reputation/  |     |            | Message   |     | Local Info |
|Accreditation|     +----------->| Filtering |     | on Sender  |
|Info         |                  | Engine    |     | Practices  |
+-------------+                  +-----------+     +------------+

and:

verifying:
...
If the signature passes, reputation information is used to assess
  the signer and that information is passed to the message filtering system.

and <http://dkim.org/specs/rfc5585.html#rfc.section.5.5>

5.5. Assessing
...
A popular use of reputation information is as input to a Filtering Engine
that decides whether to deliver -- and possibly whether to specially
 mark -- a message. Filtering Engines have become complex and sophisticated.


Deployment, RFC 5863,
<http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#system>:

2.1 A Systems View of Email Trust Assessment
...
The recipient then makes handling decisions based on a collection of
assessments, of which the DKIM mechanism is only a part. In this model, as
shown in Figure 1, validation is an intermediary step, having the sole task
of passing a validated Responsible Identifier to the Identity Assessor.
...
     The Identity Assessor uses this
single, provided Identifier for consulting whatever assessment data bases
are deemed appropriate by the assessing entity. In turn, output from the
Identity Assessor is fed into a Handling Filter engine that considers a range
of factors, along with this single output value.

and the accompanying figure:

   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.figure.1>

along with:

   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.2.4>
and
   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.2.5>


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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