On 6/1/10 3:47 AM, Dave CROCKER wrote: > >> In the same way that receiver practices have previously changed
> >> the way email is sent DKIM, despite its infancy has also had an > >> impact. Brett has mentioned earlier the positive effects for > >> paypal as a mechanism that domains can use to protect their > >> customers from phishing. > DKIM, by itself, does not protect against phishing. DKIM does not > attempt to help find bad actors. Generic statements about DKIM and > phishing, in some DKIM documents, has no technical substance. > > On the other hand, ADSP certainly was motivated by the direct goal > of finding spoofed From: domains. Agreed. See section 4.3, third paragraph: ,--- [ADSP] presents an additional challenge. Per that specification, when a message is unsigned or the signature can no longer be verified, the verifier must discard the message. There is no exception in the policy for a message that may have been altered by an MLM. Verifiers are thus advised to honor the policy and disallow the message. Furthermore, authors whose ADSP is published as "discardable" are advised not to send mail to MLMs as it is likely to be rejected by ADSP-aware recipients. (This is discussed further in Section 5.3 below.) '--- There is no MUST discard, only "encourage". Secondly, there is no clear definition for discard, although it is generally understood to mean silently delete. This recommendation appears to be making deliver-ability distinctions between "discardable" and "all", that does not exist in the ADSP specification. Problems caused by MLMs are true for refusals based upon "all" as well. In fact, "all" precludes silently deleting which could even help reduce the number of subscribers being dropped. Please include "all" and "discardable" whenever making general policy statements. The only difference between "all" and "discardable" is permission granted to silently delete, however either may cause messages to be refused. When email integrity is important, "all" should be used instead of "disardable". Section 2.4, Message Streams ( in conflict with ADSP) ,--- This document makes reference to the concept of "message streams". The idea is to identify groups of messages originating from within an ADMD that are distinct in intent, origin and/or use, and partition them somehow (most commonly via DNS subdomains, and the "d=" tag value in the context of DKIM) so as to keep them associated to users yet operationally distinct. '--- Please add a statement indicating this concept is in conflict with ADSP. Such as: ADSP is in conflict with the Message Stream concept, since An Author Domains Signature must match exactly with the email-address domain. Section 4.1. Author-Related Signing ,--- If an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author is advised to be cautious when deciding whether or not to sign the message. The MLM could make a change that would invalidate the author's signature but not remove it prior to re-distribution. Hence list recipients would receive a message message purportedly from the author but bearing a DKIM signature that would not verifiy. This problem would be compounded further if there were receivers that applied signing policies ([ADSP]) and the author published any kind of strict policy. If this is cause for concern, the originating site can consider using a sub-domain for the "personal" mail that is different from domain(s) used for other mail streams, so that they develop independent reputations, and more stringent policies (including ADSP) can be applied to the mail stream(s) that do not go through mailing lists. '--- From a phishing perspective, advocating use of different domains, or sub-domains will lead to phishing being more successful, and also likely increase the number of attempts. There are some 20K financial institutions being heavily phished, with perhaps a similar number involving other institutions. Clearly, the phishing problem affects a small percentage of the domains in current use, albeit causing substantial damage to their ability to utilize email for personal and transactional exchanges. There are a number of U.S. regulations affecting these institutions, such as PCI DSS, HIPAA and GLBA. Third-party services being used by this small segment of domains should already be known by their administrators. Publishing a list of these services would enable specific ADSP policy exceptions, and significantly reduce possible phishing sources. This approach would also allow these institutions a means to directly react to any reported abuses. Importantly, specific authorization of third-party services avoids highly detrimental advice of using multiple domains. It seems many marketing departments, (including our own) still need to be educated on this matter. Please don't offer confusing advice about using similar domains. Don't recommend use of different domains, when there is a better alternative that should be advocated. People are taken in by phishing, see: http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf ,--- Most maliciously registered domain strings offered nothing to confuse a potential victim. Placing brand names or variations thereof in the domain name itself is not a favored tactic, since brand owners are proactively scanning Internet zone files for such names. As we have observed in the past, the domain name itself usually does not matter to phishers, and a hacked domain name of any meaning, in any TLD, will usually do. Instead, phishers almost always place brand names in subdomains or subdirectories. This puts the misleading string somewhere in the URL, where potential victims may see it and be fooled. Internet users are rarely knowledgeable enough to be able to pick out the "base" or true domain name being used in a URL. '--- Advocating that targets of phishing attacks utilize similar sub-domain tactics will lead to greater confusion. If anything, consumers need to experience greater predictability in which domains names these institutions use. This also helps the receivers attempting to manually mitigate this problem. > >> MLMs, like mailman, have taken the simple option of stripping > >> DKIM signatures which has also had a positive effect for many > >> list admins. > > This implies that DKIM-stripping is an active choice among MLMs. It > isn't. Clearly, it is? Section 4.2 of RFC 4871 states: ,--- Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. '--- This is not a MUST NOT and then states: ,--- Verifiers SHOULD ignore failed signatures as though there were not present in the message. '--- The choice is open. How would you envision an invalid signature being valuable with respect to third-party services? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
