[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
> -----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 -
> On 8/24/2010 6:42 AM, MH Michael Hammer (5304) wrote:
> > Please show us in RFC4871 where it says DKIMs main purpose is
> > 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
> specification. So it might or might not contain language about the
> signature is intended to fit into a larger processing environment.
> The second is that we've been struggling with finding the right
> describing systems issues about DKIM. Note that we even managed to
> protocol document without defining the protocol's output, which is why
> an errata document. So we need to be careful about using RFC 4871
> 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
> implementation in the email infrastructure rather than email end
> 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
> processing, where is the detailed specification or guidance that would
> interoperable use of it? Without that, use becomes idiosyncratic and
> non-interoperable. (This is a version of the same logic we all
> 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
> > 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
> 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
> >> 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.
> > DKIM (and non-DKIM) values can also be delivered to this
> > well as to a more general message evaluation filtering engine.
> > However, this additional activity is outside the scope of the
> > 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
> Overview, RFC 5585,
> > . +-----+--+----+ +-------+ .
> > . | | / Check \<............+
> > . | +-------->/ Signing \
> > . | / Practices \<..........+
> > . | +-------+-------+ .
> > . | | .
> > . | V .
> > +----+--------+ | +-----------+ +------+-----+
> > |Reputation/ | | | Message | | Local Info |
> > |Accreditation| +----------->| Filtering | | on Sender |
> > |Info | | Engine | | Practices |
> > +-------------+ +-----------+ +------------+
> > verifying:
> >If the signature passes, reputation information is used to assess
> > the signer and that information is passed to the message
Still doesn't indicate "primacy", only that reputation can be part of
> 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
> > that decides whether to deliver -- and possibly whether to
> > mark -- a message. Filtering Engines have become complex and
"popular" does not equal primary.
> Deployment, RFC 5863,
> > 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
> > shown in Figure 1, validation is an intermediary step, having the
> > of passing a validated Responsible Identifier to the Identity
> > The Identity Assessor uses this
> > single, provided Identifier for consulting whatever assessment data
> > are deemed appropriate by the assessing entity. In turn, output
> > Identity Assessor is fed into a Handling Filter engine that
> > of factors, along with this single output value.
> and the accompanying figure:
> along with:
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
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.
More information about the ietf-dkim