Re: [ietf-dkim] Authorizing List Domains
On 9/29/10 11:15 AM, Murray S. Kucherawy wrote: > > On Tuesday, September 28, 2010 7:01 PM, Douglas Otis wrote: > >> On 9/28/10 3:27 PM, Murray S. Kucherawy wrote: > > > > The TPA-Label draft offers additional ADSP assertions having > > semantics intended to support _existing_ mailing-list and > > third-party practices. The DKIM charter states the following: >>,--- > > Consider issues related to mailing lists, beyond what is already > > documented. ... >>'--- > > I believe the intent of that item is to document current MLM/DKIM > issues vis a vis already-published documents, as is done in the draft > that is currently a WG item. Extending ADSP or creating new > protocols doesn't seem to fit within that goal. While done with the best intentions, the dkim-mailinglists draft in section 4.1 Author-Related Signing, recommendations should be considered a bad practice for domains being phished and making strict ADSP assertions. http://tools.ietf.org/html/draft-ietf-dkim-mailinglists-02#page-11 The motivation behind strict ADSP assertions is to mitigate damage caused when recipients are heavily phished. Redirecting phishing to unprotected sub-domains represents a bad practice as this will add to user confusion and dissatisfaction. Problems related to ADSP will not be resolved by permitting delivery of phishing attempts that purport to be from a sub-domain. At least the last sentence in the section admits only prohibiting use of mailing-lists is likely to be successful since any restrictive ADSP assertion will disrupt most of these informal third-party services. DKIM/ADSP can exclude delivery of deceptive messages that neither SPF or Sender-ID are able to reliably accomplish. Using ADSP with TPA-Label exceptions can also significantly reduce false positives by taking advantage of the strongest verification method available. This includes, but is not limited to, using DKIM signatures not within the Author Domain. As a secondary effect, domains making the only actionable restrictive ADSP assertion of "discardable" will find their email delivery integrity will suffer. In no small part, much of the damage to delivery integrity is caused by a unilateral change with ADSP assertion of "strict" to "discardable". This change was done with a mistaken belief DKIM signatures are not normally verified prior to acceptance. > > Sorry, should have said DKIM/ADSP deliverability, which is based > > upon DKIM Author Domain Signatures. The TPA-Label draft offers > > alternative ADSP assertions that indicate the possible availability > > of domain specific exceptions. When exceptions are not found, > > non-compliant messages are to be rejected, as opposed to being > > discarded or scored in some fashion. > > I'm confused. You say TPA allows fallback to other adopted > verification methods, but you also say it refers specifically to > DKIM/ADSP deliverability. I'm not clear on how both can be > simultaneously true. SPF authorizations fail more often than DKIM signature validations, but the percentages for either are not insignificant. As such, some domains would like path verifications to act as a fallback method whenever DKIM signatures don't verify. More than a third of business related domains publish the most restrictive SPF assertions that pertain to Mail From parameters, and only 0.3% of domains being heavily phished publish the most restrictive ADSP assertions that pertain to the From header field. As such, ADSP's inability to pass accountability to subsequent systems makes "simple" ADSP implementations incompatible with most third-party services. TPA-Label records give senders a means to recommend appropriate exceptions that are needed to overcome ADSP's accountability passing limitations. Without this ability, ADSP is likely to remain largely unpublished, and when published, not acted upon due to its high rate of false positives. > >> The DNSOP working group has repeatedly advised against use of > >> reverse DNS as a mechanism for client authentication. Do we claim > >> to have expertise they are lacking? > > > > See: > > http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4 > > > > The SMTP EHLO or HELO hostname must resolve the IP address of the > > SMTP client. Reverse DNS is not used. > > I think that's a marginal improvement. Even if the HELO/EHLO > parameter can be resolved to the client IP address, that doesn't tell > you anything about the client other than it has control over some > portion of the DNS. Control of the DNS also identifies the DKIM administrative domain. In addition, verification of the SMTP client indicates which domain is actually introducing the message into the mail stream, where DKIM may not whenever a signature does not include an origination header field that matches the RCPT TO parameter. This difference becomes significant when dealing with replay abuse. > > Requiring additional header field compliance be
Re: [ietf-dkim] Updated implementation report
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of MH Michael Hammer (5304) > Sent: Wednesday, September 29, 2010 4:10 PM > To: Hector Santos; ietf-dkim@mipassoc.org > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Updated implementation report > > Outstanding job Murray. Is this sufficient to achieve the intended > goal? I've asked our AD to comment on that very question. I'll let you know what he says (or he might post his review of it here). > It would be interesting if the data could be sliced and diced a little > differently. > > For example, it would be interesting to look at percentage based on > volume compared to percentage based on number of domains. In other > words, are a small number of large domains skewing the reported > numbers. > > It would also be interesting to look at breakout percentage of domains > signing based on number of emails received from that domain. So, > arbitrarily segment the set into quintiles based on number of mails > received for that domain and then look at signing practices within the > quintile. We can do both of those. What colour would you like it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Hector Santos > Sent: Wednesday, September 29, 2010 5:23 PM > To: ietf-dkim@mipassoc.org > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Updated implementation report > > Murray S. Kucherawy wrote: > > I've posted a new issue of the DKIM implementation report. The most > interesting changes are the inclusion of a day of sample data from AOL and > a revision of the data summary reported by the OpenDKIM stats project > using the updated schema, which allows a few interesting new observations. > > Outstanding job Murray. Is this sufficient to achieve the intended goal? > > Thanks for the report. > > I believe the most outstanding data point here is the extremely high > original signing of mail. AOL's 1.2 out of 1.4 billion or 86% > signatures were 1st party and your own statistics showed 73% were 1st > party. > This isn't particularly surprising to me. I've always believed there is a significantly higher value for 1st party signing compared to 3rd party. The value proposition has always seemed to be much more compelling to me. It would be interesting if the data could be sliced and diced a little differently. For example, it would be interesting to look at percentage based on volume compared to percentage based on number of domains. In other words, are a small number of large domains skewing the reported numbers. It would also be interesting to look at breakout percentage of domains signing based on number of emails received from that domain. So, arbitrarily segment the set into quintiles based on number of mails received for that domain and then look at signing practices within the quintile. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
Murray S. Kucherawy wrote: > I've posted a new issue of the DKIM implementation report. The most > interesting changes are the inclusion of a day of sample data from AOL and a > revision of the data summary reported by the OpenDKIM stats project using the > updated schema, which allows a few interesting new observations. > Thanks for the report. I believe the most outstanding data point here is the extremely high original signing of mail. AOL's 1.2 out of 1.4 billion or 86% signatures were 1st party and your own statistics showed 73% were 1st party. This validates what I have always been felt is the high promise for DKIM exclusive (1st party or passive 3rd party) operations. Policy is inevitable to facilitate policy (domain expectation) fault detection. -- 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
[ietf-dkim] Updated implementation report
I've posted a new issue of the DKIM implementation report. The most interesting changes are the inclusion of a day of sample data from AOL and a revision of the data summary reported by the OpenDKIM stats project using the updated schema, which allows a few interesting new observations. (You'll just have to read it to find out what they are!) -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : RFC4871 Implementation Report Author(s) : M. Kucherawy Filename: draft-ietf-dkim-implementation-report-01.txt Pages : 14 Date: 2010-09-29 This document contains an implementation report for the IESG covering DKIM in support of the advancement of that specification along the Standards Track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] broadcast lists
On Tue, Sep 28, 2010 at 10:40 PM, John R. Levine wrote: >>> Even though ESPs are generally sending mail on behalf of customers, >>> their relationship to the customers allows them to be the customer, as >>> far as mail authentication is concerned. There are some issues about >>> how a customer delegates part of its identity to its ESP, but they are >>> completely, totally, unrelated to the MLM issues we've been arguing >>> about. >> >> A document on those delegation issues might be helpful also. > > I'd be happy to work on one if anyone thinks that ESPs who don't already > everything it says will read it. I'm coming up blank on what those issues would be. If we are talking about how ESPs could go about it, last time I read Steve Atkins' web page, it seemed like a good start. Is there something more? -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John Levine > Sent: Wednesday, September 29, 2010 10:52 AM > To: ietf-dkim@mipassoc.org > Cc: ietf-d...@kitterman.com > Subject: Re: [ietf-dkim] Corner cases and loose ends, was, > draft-vesely-dkim-joint-sigs > > >>This might be a good time to remind people that MLMs in their > >>current form are not broken, and any proposal that requires them to > >>stop doing something that they're currently doing, like rewriting > >>messages or adding message tags, is a non-starter. > > >Since nothing requires anyone do anything with respect to DKIM, I'm > >hard pressed to imagine something that doesn't meet that requirement. > > I was thinking of the various proposals to rewrite From: addresses, to > outlaw subject tags and message footers, and otherwise change the > behaviors that MLM users expect in order to make them conform to > various ideas of how DKIM and/or ADSP are supposed to work. If the current MLM draft attempts to "outlaw" anything, that should be corrected. But I don't think it hurts anyone to point out that an MLM that actually does want to try to preserve author signatures, for whatever reason, should realize what options it has. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
>>This might be a good time to remind people that MLMs in their >>current form are not broken, and any proposal that requires them to >>stop doing something that they're currently doing, like rewriting >>messages or adding message tags, is a non-starter. >Since nothing requires anyone do anything with respect to DKIM, I'm >hard pressed to imagine something that doesn't meet that requirement. I was thinking of the various proposals to rewrite From: addresses, to outlaw subject tags and message footers, and otherwise change the behaviors that MLM users expect in order to make them conform to various ideas of how DKIM and/or ADSP are supposed to work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
"John R. Levine" wrote: >> The law requires that there be an easy to use address for unsubscribing. >> The List-unsubscribe header: would do the job nicely, if the majority of >> people were using mail clients that expose it by default. I don't know of >> any mail client which does that. > >pine/alpine does, but I agree, most MUAs don't show headers other than To, >From, Cc, and Subject. > >This might be a good time to remind people that MLMs in their current form >are not broken, and any proposal that requires them to stop doing >something that they're currently doing, like rewriting messages or adding >message tags, is a non-starter. > Since nothing requires anyone do anything with respect to DKIM, I'm hard pressed to imagine something that doesn't meet that requirement. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] IGNORE list signature test
The last message to the list echoed backed to me as a bad signature: Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_SIGNATURE_BAD) header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=pass policy=all author.d=isdg.net asl.d=mipassoc.org; This is a test to see if it can be repeated. -- 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
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Dave CROCKER wrote: > > On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: >> If a domain publishing ADSP discardable has not gotten control of their >> mailstreams then all I can say is "Darwin was right". > > > I agree with you completely. > > The problem is that customers of a receiving ISP often do /not/ agree with > you. > > When their ISP discards mail the customer wanted, the explanation "well, it's > what the author told me to do" typically does not work. And since the > customer's contact is with the receiving ISP, it is the receiving ISP that > must > alter their activity. Since discarding got them in trouble, they will, at > best, > start discarding much more selectively. "Selectively" means using information > beyond ADSP. > > Given sufficient selectivity, the mechanism that defines "selective" will > contain enough information to make ADSP redundant. > Dave, Policy is policy, whether its another form or not, heuristic policy, classification, reputation or a "selective approach" or what have you, it is still a sender/receiver "policy" per se. I don't think anyone wants to delete mail for no good reason, thats no fun. And that includes mail marked as discardable. For some implementations, it could just mean a larger negative weight for a classification policy. But I think those who believed in strong self-asserting policies, as in SSH and and SPF will also like to see them in DKIM as well. There many industry special arrangements where a hard DKIM policy is desirable before REPUTATION - a requirement I believe, takes place. The Online Trust Alliance started in its September 2010 "Email Authentication Adoption Progress Report" [1] Use of ADSP is recommended for high profile brands at potential risk of abuse. The popular MLM Mailman started [2] To develop standards to assist with email lists as an alternative to the last option above that provides a neat solution, there could be a third-party domain signing policies. Some standard that allows senders to define which third party signatures receipents should receive, even if the author domain signature is broken. SpamAssasin now incorporates logic to "assign" local ADSP policy overrides for domains that don't have them [3] The eCert report "Email Sender Authentication Deployment Best Practices and Considerations" is riddled with recommendations for strong DKIM Polices [4], even though the 2009 report recognize ADSP is still work in progress. The inertia is growing and systems large to small, from all segments of the industry want to see how DKIM implementation can help besides just reputation. The point is - give people the option to screw up and get their sender/receiver policy and technology right to allow them the learn how to disseminate their mail more deterministically than what Reputation currently provides. One small point. On our system, the stats show a high phishing of our local domain or hosted domain accounts (MAIL FROM: phished-n...@hosteddomain.com). They are all 100% immediately rejected simply because the names don't exist. Some systems will not have a SMTP LEVEL Mail From check (for scalability reasons or just not capable, not integrated) and if the mail was allowed to be accepted, only will a DKIM+POLICY provide a 100% equivalent protection. Without policy, many of these exclusive messages would be passed to the user putting them at risk. Note there is an operational reason for validating the MAIL FROM. I am not speaking of CBV (Call back Verifier), but local account verification. If not checked, a bounce can to a non-existing account. So we check the return path if its locally hosted domain. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] https://otalliance.org/resources/authentication/Q3_2010%20Email%20AuthenticationSup9-14.pdf [2] http://wiki.list.org/display/DEV/DKIM [3] http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200903.mbox/%3cbug-6087...@https.issues.apache.org/SpamAssassin/%3E [4] http://www.bitsinfo.org/downloads/Publications%20Page/BITSSenderAuthenticationDeploymentFINALJun09.pdf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
