[ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations
MH Michael Hammer (5304)
MHammer at ag.com
Tue Aug 24 09:11:38 PDT 2010
Let's rock!
> -----Original Message-----
> From: Dave CROCKER [mailto:dhc at dcrocker.net]
> Sent: Tuesday, August 24, 2010 11:54 AM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim at mipassoc.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
More information about the ietf-dkim
mailing list