On Jun 22, 2013, at 9:49 PM, Michael Deutschmann <mich...@talamasca.ocis.net> wrote:
> Ukh. This again. > > I think I see what the problem is with the DKIM design community. > > Most of you assume that once DKIM and an accessory protocol of choice > (DMARC, etc.) reaches a sufficient amount of respect from the RFC > machinery, it will magically be deployed absolutely everywhere it is > relevant. > > Otis is just a shade more humble. He thinks the magical deployment will > occur, but will be accomplished by a jerk literal genie, who will try to > pass as much bad mail as possible while keeping to the letter of the > final DKIM spec. Dear Michael, A serious security vulnerability occurs when system administrators logically follow DKIM deployment instructions. They likely have a reasonable desire to avoid complains caused by reactive Bayesian filters. This filtering is supplanted by more deterministic message acceptance based on trust established by a DKIM signing domain specifically as suggested by the deployment specifications. Rather than DKIM admitting a process error where valid signatures are returned for messages having invalidly prefixed header fields, the fix was to suggest there is some undefined check left to some undefined subsequent agent. So much for providing clean protocol layering. Use of DKIM requires an undefined "degrading" process per section 8.15 to be implemented subsequent to signature validation. This is putting the cart before the horse since a DKIM validation process must walk up and down the entire header field stack. It is also clear very few domains implement the non-intuitive double listing of singleton header fields. Even so called "high value" domains don't bother with this ugly hack. The OpenDKIM implementation can place the cart behind the horse, but as a seldom used option. An option that should be a REQUIREMENT. RFC5863: ,--- 5.4. Inbound Mail Filtering DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message. Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services. The precise means by which this is accomplished is outside the scope of DKIM. '--- ,--- 8.4. Email Infrastructure Agents ... Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification. An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451]. ... '--- ,--- 8.5. Mail User Agent ... Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path; if a signature fails, the message is to be treated the same as a message that does not have a signature. ... '--- [RFC6376]: ,--- 3.8. Input Requirements ... Accordingly, DKIM's design is predicated on valid input. Therefore, Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards. See Section 8.15 for additional discussion. '--- Regards, Douglas Otis
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html