Let's rock!
-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Tuesday, August 24, 2010 11:54 AM
To: MH Michael Hammer (5304)
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures -
mua
considerations
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.
Why yes we do need to be careful <G>
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.
I think a better way of describing it would be that reputation systems
are a nice subset of what is in the right arena.
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.
Your statement was taken (at least by me) as an assertion that begged
for supporting evidence.
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.
I read it and I reread it and I still nothing that supports your
assertion that the main purpose is assessment by reputation filtering
engines.
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.
Still doesn't indicate "primacy", only that reputation can be part of
the process.
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.
"popular" does not equal primary.
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>
And yet again I read and I reread but find nada that says reputation is
primary. Perhaps if you had said "In my humble opinion reputation is the
primary...."
I remember that we collectively kicked the can down the road by saying
what someone did with the value returned in evaluating a message for
DKIM was out of scope.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html