Dave CROCKER wrote: ?> In Section 5.8: >> >> "DKIM-aware authoring MLMs MUST sign the mail they send according to >> the regular signing guidelines given in [DKIM]. >> >> One concern is that having an MLM apply its signature to unsigned >> mail might cause some verifiers or receivers to interpret the >> signature as conferring more authority or authenticity to the message >> content than is defined by [DKIM]. This is an issue beyond MLMs and >> primarily entails receive-side processing outside of the scope of >> [DKIM]. It is nevertheless worth noting here." >> >> Removing the MUST and saying: >> >> DKIM-aware authoring MLMs signs the messages they send according to >> the regular signing guidelines given in [DKIM] >> >> gives more weight to the last two paragraphs, especially with the >> note about the concern. > > Not really. The latter paragraph merely notes that there are receivers > that do not understand what a DKIM signature means.
Something is amiss if after 6 years of development, after countless repeated explanations and messages over the years, it still seems very a difficult feat to describe in one or two sentences to the layman what DKIM is suppose to do for them, today or in the some distance future. The fact is DKIM has many conflictive semantics. While the above says its out of scope, it says the opposite in RFC 46751bis 6.3: Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. See the SHOULD? See the technical association highlighted between the signer domain (SDID) and the the originating, copyright holder/author of the Message? Now, look at the conflict in the Abstract and repeated again in Section 1.2 defining the Signing Identity: DKIM separates the question of the identity of the signer of the message from the purported author of the message. What question is that? RFC4871 never quite clearly defined thee "question." Lets think about what that question may be. Answer this: Do Electronic Mail Author Domains have any security rights and controls over who DKIM signs their mail? Be nice for someone to answer that question. Then of course, we have augmented RFC productions, such as RFC5585 that describes the "DKIM Service Architecture" and the illustration has that Author Domain "Checking Signing Practices" process component displayed in the diagram: |- RFC5322 Message V +--------+ +--------------------------------+ | Private| | ORIGINATING OR RELAYING ADMD | | Key +...>| Sign Message with SDID | | Store | +---------------+----------------+ +--------+ | (paired) [Internet] +--------+ | +-----------+ | Public | +--------------------------------+ | Remote | | Key | | RELAYING OR DELIVERING ADMD | | Sender | | Store | | Message Signed? | | Practices | +----+---+ +-----+--------------------+-----+ +-----+-----+ . |yes |no . . V | . . +-------------+ | . +.......>| Verify +--------+ | . | Signature | | | . +------+------+ | | . pass| fail| | . V | | . +-------------+ | | . | | | | . +.......>| Assessments | | | . . | | V V . . +-----+--+----+ +-------+ . . | | / Check \<............+ . | +-------->/ Signing \ . | / Practices \<..........+ . | +-------+-------+ . . | | . . | V . +----+--------+ | +-----------+ +------+-----+ |Reputation/ | | | Message | | Local Info | |Accreditation| +----------->| Filtering | | on Sender | |Info | | Engine | | Practices | +-------------+ +-----------+ +------------+ Figure 1: DKIM Service Architecture Then you have the RFC5863 Development guide with a few dedicated sections, but not the only sections: 7.3. Author Domain Signing Practices 7.3.2. A Few Definitions 7.3.3. Some ADSP Examples Then finally, you have the crux of the problem with this RFC5017 section 5.3 item #10 statement: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. So on the one hand you have functional specifications across multiple RFC which recommends receivers to honor author domain signing practices as a security measure to help product DKIM domains, but then we have miscellaneous peppered injections of statement that conflicts with these goals by telling receivers they MUST (not a MAY) to mind their own bee's wax if they see an unexpected, unsolicited, unknown, unauthorized non-first party DKIM signed mail when the author domain may have a policy that says "Thats a NO NO" Dave, you got receivers all twisted up in knots! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html