Let's rock! > -----Original Message----- > From: Dave CROCKER [mailto:[email protected]] > Sent: Tuesday, August 24, 2010 11:54 AM > To: MH Michael Hammer (5304) > Cc: [email protected] > 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
