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
