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