On 7/27/11 12:13 AM, Michael Deutschmann wrote: > I have one comment to make which ties together both my stance on Otis' > doublefrom crusade, and some reforms I have argued for in ADSP. > > Basically, at present the doublefrom trick is simply *unnecessary* for > someone trying to pass me a forged mail. My MTA, Exim-4.76, does not > natively support ADSP. It does support core DKIM, but without ADSP it's > not reasonable for the DKIM result to have any effect on the message > disposition. > > It probably wouldn't be *that* hard to cobble together some receiverside > ADSP implementation using Exim's other features, but it's just not worth > my while. > > I'm not afraid of any phish fooling me, but I am interested in anything > that reduces the amount of "bad mail" reaching my inbox. But while a > lot of spam is forged, it's forged to be from some ordinary schlub, not > Paypal. > > I keep records going back to 2007, and since the start of that year 254 > bad mails (spam and viruses) have gotten through to me. They represent > 210 alleged From: domains. Of those domains, -absolutely none- of them, > -today-, have ADSP records at all. Not even a "dkim=unknown"! Thus > retrospective analysis shows ADSP is unlikely to make any difference. > > I may well implement double-From: detection alone. *It* would have > blocked three spams from that interval (none of which bear any attempt > at a signature). > > > Now, all that aside, Paypal would probably still really like me to arm > ADSP, just in case. But while it may be worth *their* time to sail > 100km to meet me (that is, by actually maintaining no-mailing-list > discipline so they can use discardable), it's not worth *my* time to > drive 1km from my hilltop home to the port to meet them. > > If ADSP were fixed so that it could be deployed meaningfully at ordinary > domains, with users who post to mailing lists, this might change. > > I've already stated my fix -- add "dkim=except-mlist", which states that > any message with broken/absent signatures should be considered bogus if > it is known not to be a mailing list message. > > While merely adding a fake "List-Id:" header might let forgeries of > except-mlist domains get through to many users, that will never work on > me. I recognize my mailing lists via other indicia that are harder to > forge (the MAIL FROM:). Michael,
Your fix will not control phishing or spoofing abuse and would expose these domains to open-ended sources. Reactive methods will prove less and less effective as the name and address space grows. DKIM should be viewed as a Work-In-Progress still missing a viable policy layer. Key sharing will not scale well enough to solve the mailing list issue. Not having a solution for open third-party services leaves ADSP suitable only for a tiny fraction of senders that could benefit from improved anti-phishing measures. For DKIM's protections to be comprehensive, policy needs an authorization structure able to include open but trusted third-party services. Such policies can be supported by a DNS zone of the domain or one referencing that of a reputation provider. The authorization in either case can be resolved within a single and small transaction. http://tools.ietf.org/html/draft-kucherawy-dkim-atps-03 Unfortunately, such a goal makes little sense when DKIM fails to validate input for valid DKIM signatures by ignoring multiple From header fields. None of this will happen over-night, where indeed the eventual strategy must be easy for administrators to implement. IMHO, easy should not always mean the use of TXT records however. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
