On 9/20/10 6:35 PM, Michael Deutschmann wrote: > On Mon, 20 Sep 2010, Douglas Otis wrote: > > It seems this is making two assumptions that are likely incorrect: > > > > 1) receiving domains know which mailing-lists their users have > > subscribed. > > Most don't. But such sites are also incapable of deploying TPA as a > sender. So that's just as good an argument for the impracticality > of TPA, as for the impracticality of except-mlist.
Domains heavily phished are in a different situation. For these domains, there would be a strong incentive for offering third-party information, and they are more likely to know which third-party services are being used. An except-mlist would likely cause phishing attempts to have List-ID headers included. With these headers not being displayed, such an assertion would provide recipients little, if any, benefit. > > 2) receiving domains reliably recognize mailing-list messages. > > This also hurts TPA just as much. The only defense against forgery > of lists that can only be recognized weakly (by accepting unsigned > messages from any IP that display the correct List-Id:), is not to > subscribe to such lists. Disagree. A message not signed by DKIM therefore depends upon other authentication methods. Within a single transaction, the TPA-Label scheme indicates whether an authentication method should be attempted for a domain, and whether the domain should be rejected outright without authentication attempted. > "except-mlist" comes out slightly ahead here. Since the subscription > whitelist is consumed where it is compiled, and thus doesn't need to > be converted into a standard "language" such as TPA, it can include > ad-hoc measures such as "fake SPF records" to limit forgery of > troublesome lists. Sorry, but I am unable to follow this. Are you suggesting receiving domains should compile a white-list for all mailing-lists? How will fake SPF record be helpful? > > Disagree. While there are many domains offering third-party email > > services, this still represents a finite dataset. In contrast, > > the domains used by bad actors represent an infinite dataset. > > You seem to be hinting a global whitelist of mailing lists would be > feasable -- so the domains in question could just salute one and be > done with it. If they are happy with the results, why not? > That doesn't sound practical to me. Especially since users at such > ISPs will likely subscribe to lists that are too insecure to be put > on the GW. Are ISPs normally phishing targets? > Insecure mailing lists in private whitelist are at least > obscure, but a global whitelist cannot tolerate a single one. For sensitive domains, third-party services will need to be closely monitored. A requirement to include List-ID headers, for example, better ensures the messages will be unlikely considered something directed to a specific person. Of course, nothing is absolute, but most mailing-lists are normally quick to respond to abuse. > Basically, the problem is that users at such ISPs do not want > protection from forgeries *of themselves directed at others* badly > enough to make the sacrifices needed to stop that cold. Such as > dropping a non-DKIM, non-SPF mailinglist where all their best > friends hang out. The need for the scheme is to protect domains being phished. When ISPs find their domain is being used to phish others, there might be some interest. IMHO, this is not an immediate problem. In addition, some third-party services might offer extremely strong authentication methods stipulated by the TPA-Label. > But, I want protection from forgeries *of other people directed at > me*, and the use of "dkim=unknown" or no-ADSP by those other people > hampers my ability to achieve that. I don't need them to go > whole-hog TPA, I just need help squelching the > supposedly-first-person forgeries, and I can take care of the > supposedly-via-list forgeries myself. Preventing phishing requires comprehensive policy. Gaps in this policy will provide little tangible benefit. Again, you are assuming you can recognize all valid first-person and third-party exchanges? BTW, the TPA-Label scheme is also able to secure first-person exchanges as well. Your strategy places additional burdens on the receiver, but when they fail in some manner, the sender is likely harmed. On the other hand, the TPA-Label ensures those who benefit make the added effort. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
