From fenton at cisco.com Thu Jul 2 12:27:37 2009 From: fenton at cisco.com (Jim Fenton) Date: Thu, 02 Jul 2009 12:27:37 -0700 Subject: [ietf-dkim] [Fwd: New Version Notification - draft-ietf-dkim-rfc4871-errata-07.txt] In-Reply-To: <4A459193.8070408@dcrocker.net> References: <4A459193.8070408@dcrocker.net> Message-ID: <4A4D0A29.3060007@cisco.com> Lest anyone interpret silence as agreement, I'm OK (not enthusiastic, but OK) with most of the added text in this revision, but I have a problem with the last two paragraphs. > This does not state what the implicit value of "i=" is, relative to > "d=". In this context, that fact is irrelevant. I'm not sure what point is being made, but RFC 4871 does explicitly define the default value of "i=" (an empty Local-part followed by an "@" followed by the domain from the "d=" tag). It isn't clear what "this" context is, and the paragraph is likely to introduce confusion as to whether the default value in RFC 4871 no longer exists. > Another example is the difference between the socket interface to TCP > versus the TCP protocol itself. There is the activity within the > protocol stack, and then there is the activity within in the software > libraries that are actually used. This analogy isn't clearly stated, and in any case is discussion that is irrelevant in the context of a protocol specification. Both of these paragraphs should be removed. -Jim Dave CROCKER wrote: > -------- Original Message -------- > Subject: New Version Notification - draft-ietf-dkim-rfc4871-errata-07.txt > Date: Fri, 26 Jun 2009 19:30:01 -0700 (PDT) > From: Internet-Draft at ietf.org > To: dkim-chairs at tools.ietf.org, draft-ietf-dkim-rfc4871-errata at tools.ietf.org, > pasi.eronen at nokia.com > > New version (-07) has been submitted for draft-ietf-dkim-rfc4871-errata-07.txt. > http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871-errata-07.txt > > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871-errata-07 > > IETF Secretariat. > > > From dhc at dcrocker.net Thu Jul 2 20:21:50 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Thu, 02 Jul 2009 20:21:50 -0700 Subject: [ietf-dkim] [Fwd: New Version Notification - draft-ietf-dkim-rfc4871-errata-07.txt] In-Reply-To: <4A4D0A29.3060007@cisco.com> References: <4A459193.8070408@dcrocker.net> <4A4D0A29.3060007@cisco.com> Message-ID: <4A4D794E.4050402@dcrocker.net> Jim Fenton wrote: >> This does not state what the implicit value of "i=" is, relative to >> "d=". In this context, that fact is irrelevant. > > I'm not sure what point is being made, but RFC 4871 does explicitly > define the default value of "i=" (an empty Local-part followed by an "@" > followed by the domain from the "d=" tag). It isn't clear what "this" > context is, and the paragraph is likely to introduce confusion as to > whether the default value in RFC 4871 no longer exists. The text needs to be taken in the context in which it occurs. So, for example, the "This" parallels the "This Update" in the preceding paragraph. Equally, the reference to implicit value is within the Update, not to RFC 4871. > Both of these paragraphs should be removed. The concerned area director(s) found the added text helpful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc at dcrocker.net Wed Jul 8 08:19:41 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Wed, 08 Jul 2009 08:19:41 -0700 Subject: [ietf-dkim] RFC 5585 on DomainKeys Identified Mail (DKIM) Service Overview In-Reply-To: <20090707230630.B16BC2E7511@bosco.isi.edu> References: <20090707230630.B16BC2E7511@bosco.isi.edu> Message-ID: <4A54B90D.5030502@dcrocker.net> Formatted html and pdf versions are at: d/ rfc-editor at rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 5585 > > Title: DomainKeys Identified Mail (DKIM) Service > Overview > Author: T. Hansen, D. Crocker, > P. Hallam-Baker > Status: Informational > Date: July 2009 > Mailbox: tony+dkimov at maillennium.att.com, > dcrocker at bbiw.net, > phillip at hallambaker.com > Pages: 24 > Characters: 54110 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-dkim-overview-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc5585.txt -- Dave Crocker Brandenburg InternetWorking bbiw.net From Internet-Drafts at ietf.org Sat Jul 11 11:30:01 2009 From: Internet-Drafts at ietf.org (Internet-Drafts at ietf.org) Date: Sat, 11 Jul 2009 11:30:01 -0700 (PDT) Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-06.txt Message-ID: <20090711183001.8532E3A6AE4@core3.amsl.com> From Internet-Drafts at ietf.org Sat Jul 11 11:45:01 2009 From: Internet-Drafts at ietf.org (Internet-Drafts at ietf.org) Date: Sat, 11 Jul 2009 11:45:01 -0700 (PDT) Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-07.txt Message-ID: <20090711184501.890703A6890@core3.amsl.com> From barryleiba at computer.org Sun Jul 12 07:52:46 2009 From: barryleiba at computer.org (Barry Leiba) Date: Sun, 12 Jul 2009 10:52:46 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-07.txt In-Reply-To: <20090711184501.890703A6890@core3.amsl.com> References: <20090711184501.890703A6890@core3.amsl.com> Message-ID: <6c9fcc2a0907120752l7354e8acle9131524accc920c@mail.gmail.com> The authors and the chairs think this version of the "deployment" draft is ready. Therefore, we'll start a working-group last call on it, which will end on Friday, 7 August -- the Friday after the end of the Stockholm IETF meeting. Everyone: please review this version and bring up any issues you have with it -- please change the subject and start a new thread for that. If you agree that this version's ready to go, please post a "WFM" message to this thread. This is the last document in this working group's charter. At some level, we're done. We have a 2-hour session scheduled in Stockholm on Tuesday afternoon (28 July), and the time there will be spent discussing next steps, and possible rechartering. We'll have a suggested agenda up soon. On Sat, Jul 11, 2009 at 2:45 PM, wrote: > 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 ? ? ? ? ? : DomainKeys Identified Mail (DKIM) Development, Deployment and Operations > ? ? ? ?Author(s) ? ? ? : T. Hansen, et al. > ? ? ? ?Filename ? ? ? ?: draft-ietf-dkim-deployment-07.txt > ? ? ? ?Pages ? ? ? ? ? : 50 > ? ? ? ?Date ? ? ? ? ? ?: 2009-07-11 > > DomainKeys Identified Mail (DKIM) allows an organization to claim > responsibility for transmitting a message, in a way that can be > validated by a recipient. ?The organization can be the author's, the > originating sending site, an intermediary, or one of their agents. ?A > message can contain multiple signatures, from the same or different > organizations involved with the message. ?DKIM defines a domain-level > digital signature authentication framework for email, using public > key cryptography, using the domain name service as its key server > technology [RFC4871]. ?This permits verification of a responsible > organization, as well as the integrity of the message contents. ?DKIM > will also provide a mechanism that permits potential email signers to > publish information about their email signing practices; this will > permit email receivers to make additional assessments about messages. > DKIM's authentication of email identity can assist in the global > control of "spam" and "phishing". ?This document provides > implementation, deployment, operational and migration considerations > for DKIM. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dkim-deployment-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From dhc at dcrocker.net Sun Jul 12 10:17:05 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Sun, 12 Jul 2009 10:17:05 -0700 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-07.txt In-Reply-To: <20090711184501.890703A6890@core3.amsl.com> References: <20090711184501.890703A6890@core3.amsl.com> Message-ID: <4A5A1A91.50102@dcrocker.net> > Title : DomainKeys Identified Mail (DKIM) Development, Deployment and Operations > Author(s) : T. Hansen, et al. > Filename : draft-ietf-dkim-deployment-07.txt ... > http://www.ietf.org/internet-drafts/draft-ietf-dkim-deployment-07.txt html and pdf versions are at: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc at dcrocker.net Sun Jul 12 10:50:03 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Sun, 12 Jul 2009 10:50:03 -0700 Subject: [ietf-dkim] DKIM field usage survey Message-ID: <4A5A224B.50006@dcrocker.net> Folks, G'day. One requirement for moving a specification from Proposed to Draft status is to supply an Implementation Report: I've put together survey forms -- one for signers and one for verifiers -- that should supply us with some raw field data, to make it possible to assemble a detailed report. * If you run a DKIM signing and/or verifying operation, please complete the appropriate survey questionnaire and return it to me. * If you know of others operate DKIM signing and/or verifying services -- such as your customers -- please forward this to them and request that they complete a version, returning it to me. Because the report seeks information about interoperability, it does not ask about the capabilities of software, but rather looks for actual usage. It is information about /interaction/ between software that is important, not merely what code exists. This is why real field data is sought, rather than a report from developers. I'm hoping we can get a useful set of responses by the time of the IETF meeting, so that we can start considering the feedback. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rfc4871-impl-form-sign-01dc.txt Url: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090712/5e0cde2f/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rfc4871-impl-form-verify-01dc.txt Url: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090712/5e0cde2f/attachment-0001.txt From sm at resistor.net Sun Jul 19 01:22:29 2009 From: sm at resistor.net (SM) Date: Sun, 19 Jul 2009 01:22:29 -0700 Subject: [ietf-dkim] Comments on draft-ietf-dkim-deployment-07 Message-ID: <6.2.5.6.2.20090718212715.02ee2a88@elandnews.com> Hello, I have the following comments about draft-ietf-dkim-deployment-07. The document is for people involved in development, deployment and operations. These are different audiences. Some of the material in this document is at a high level and might be a challenge for people involved in deployment and operations. I'm not suggesting any change to that. In Section 2.3, it is mentioned that a DKIM signing entity can serve different roles, such as author of content, versus operator of the mail service, versus operator of a reputation service. I don't understand the use of the word role in the content of a reputation service. From the examples, it sounds more like an input instead of a role. "For those originating message content, the most likely choice of sub- domain naming scheme will by based upon type of content ... where the choices are best dictated by whether they provide the Identity Assessor with the ability to discriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety." I noticed that some sub-domain schemes are used as an "opaque identifier". "For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different sub-domain label for each customer. For example: widgetco.example.net" I am not in favor of such a scheme as it is vendor-oriented. If the customer changes their messaging service, their signing identify is no longer valid. One of the advantages of DKIM is that it doesn't rely on the originating IP address, i.e. the service or content is not tied to IP addresses. We would be taking a short term approach by encouraging a tie-in with the transmitter of the message. I'm going to use this mailing list as an example. The message is sent through songbird.com. I don't know the relationship between mipassoc.org and songbird.com. I know that the mailing list is associated with the mipassoc.org domain. As the receiver, it's easier for me if the DKIM signer is mipassoc.org. If we were to use the obvious scheme, then the DKIM signer would be mipassoc.org.songbird.com or something similar. If the mailing list is moved to att.com, the DKIM signer would be mipassoc.org.att.com. The change in signing identity is not to the advantage of the sender or the receivers. Section 2.5 focuses on variations in Organizational Trust versus Message Risk. Adopting an Accept and Contact approach without any filtering is troublesome for messages from some types of senders. This is my opinion and not a suggestion to change that section. In Section 6.2, is the "i=marketing.domain.example" correct? Section 6.3 is about third party signatures. ESPs and ISPs are in the same paragraph. In my opinion, they are different as they have different orientations. What they have in common is the aggregation of mail traffic which means that you will see "good" mail and "bad" mail. The level of bad mail from an ISP varies according to the "quality" of its users at any given point. There is some good advice in this document which might help. Third party signatures from ESPs are not that useful when the ESPs aggregate their mail traffic. This is not a rule. There are mechanisms outside the scope of DKIM where the information may be of use. I'm not too keen about the paragraph about Forwarders as it mixes forwarding mail with mailing list. There are two types of traffic. The second one generally "breaks" DKIM signatures. Senders which would like to prevent phishing might want to avoid third party signatures. There are valid cases when third party signatures are useful, e.g. forwarders, etc. In Section 7.3.3: "An organization (Company A) may specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP Company A MUST first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain." I do not understand what the authors mean by "misdelivery". From the example, an ADSP of "discardable" means that the email can be discarded. That isn't a wrong delivery as the receiver accepted delivery of the message. In Section 7.4: "An organization may choose to outsource certain key services to an independent company" Third-party is more appropriate than "independent company". BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete. Regards, -sm From dhc at dcrocker.net Sun Jul 19 16:19:42 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Sun, 19 Jul 2009 16:19:42 -0700 Subject: [ietf-dkim] Comments on draft-ietf-dkim-deployment-07 In-Reply-To: <6.2.5.6.2.20090718212715.02ee2a88@elandnews.com> References: <6.2.5.6.2.20090718212715.02ee2a88@elandnews.com> Message-ID: <4A63AA0E.9050004@dcrocker.net> SM wrote: > Hello, > > I have the following comments about > draft-ietf-dkim-deployment-07. The document is for people involved > in development, deployment and operations. These are different > audiences. Some of the material in this document is at a high level > and might be a challenge for people involved in deployment and > operations. I'm not suggesting any change to that. > > In Section 2.3, it is mentioned that a DKIM signing entity can serve > different roles, such as author of content, versus operator of the > mail service, versus operator of a reputation service. I don't > understand the use of the word role in the content of a reputation > service. From the examples, it sounds more like an input instead of a role. A proactive reputation service vouches for the sender. The sender could collaborate with the reputation service, to affix signature by that reputation service to the message; this is a means of imparting the reputation service's own reputation to the sender. Hence, the reputation service is performing a proactive role for that sender. (By way of example, this is what Goodmail does, which perhaps explains why I might think of this scenario...) > I noticed that some sub-domain schemes are used as an "opaque identifier". Only some? > "For those operating messaging services on behalf of a variety of > customers, an obvious scheme to use has a different sub-domain label > for each customer. For example: > > widgetco.example.net" > > I am not in favor of such a scheme as it is vendor-oriented. If the > customer changes their messaging service, their signing identify is > no longer valid. One of the advantages of DKIM is that it doesn't What you or I or anyone in the working group is in favor isn't the issue. The issue is what a signer and an assessor might find useful. The paper suggests some schemes that are likely to have assessment utility. Choices for labels to use, for distinguishing different message streams will have tradeoffs. Any particular choice will have negatives as well as positives. In this example, the premise was that the service provider's domain name was being used, rather than the customer's. Sometimes that choice makes sense or is the only one that is available. The purpose of the paper is not to dictate normative behavior -- note that it intends 'informational' status; it is to explain how things work and what sorts of choices can be available. If you feel that tradeoffs are inadequately explicated -- and I mean tradeoffs, rather than preferences -- please do supply some additional text. > Section 2.5 focuses on variations in Organizational Trust versus > Message Risk. Adopting an Accept and Contact approach without any > filtering is troublesome for messages from some types of > senders. This is my opinion and not a suggestion to change that section. What language are you suggesting to change, and in what way? > In Section 6.2, is the "i=marketing.domain.example" correct? yes. If your concern is the use of .example as a TLD: http://www.rfc-editor.org/rfc/rfc2606.txt If you have some other concern, what is it? > Section 6.3 is about third party signatures. ESPs and ISPs are in > the same paragraph. In my opinion, they are different as they have > different orientations. What they have in common is the aggregation > of mail traffic which means that you will see "good" mail and "bad" > mail. The level of bad mail from an ISP varies according to the > "quality" of its users at any given point. There is some good advice > in this document which might help. Third party signatures from ESPs > are not that useful when the ESPs aggregate their mail traffic. This > is not a rule. There are mechanisms outside the scope of DKIM where > the information may be of use. You appear to be commenting on the efficacy of particular choices, but that's not the purpose of this document. It is trying to explain the choices, in terms of DKIM use, not assert recommendations. > I'm not too keen about the paragraph about Forwarders as it mixes > forwarding mail with mailing list. There are two types of > traffic. The second one generally "breaks" DKIM signatures. A variety of processes can break them. I guess the challenge is in finding a single term to cover them. RFC 5598 doesn't quite permit calling them all "mediators". Forwarding is pretty generic. > Senders which would like to prevent phishing might want to avoid > third party signatures. Oh boy. That's a topic I hope the documented is not required to touch. > In Section 7.3.3: > > "An organization (Company A) may specify its signing practices by > publishing an ADSP record with "dkim=all" or "dkim=discardable". In > order to avoid misdelivery of its mail at receivers that are > validating ADSP Company A MUST first have done an exhaustive > analysis to determine all sources of outbound mail from its domain > (companyA.example) and ensure that they all have valid author > signatures from that domain." > > I do not understand what the authors mean by "misdelivery". From the > example, an ADSP of "discardable" means that the email can be > discarded. That isn't a wrong delivery as the receiver accepted > delivery of the message. What the receiver does with the message can be delivery as intended by the sender or it can be delivery elsewhere, such as a junk folder. From an end-to-end standpoint, that's effectively misdelivery. > In Section 7.4: > > "An organization may choose to outsource certain key services to an > independent company" > > Third-party is more appropriate than "independent company". Well, "third-party" is a term of art in the DKIM realm and it means something potentially different than meant here. > BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete. So? This isn't normative use. And they are not irrelevant. (On the other hand, 3164 appears to be an unused citation.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl at iecc.com Mon Jul 20 05:05:28 2009 From: johnl at iecc.com (John Levine) Date: 20 Jul 2009 12:05:28 -0000 Subject: [ietf-dkim] Comments on draft-ietf-dkim-deployment-07 In-Reply-To: <4A63AA0E.9050004@dcrocker.net> Message-ID: <20090720120528.58331.qmail@simone.iecc.com> >> Senders which would like to prevent phishing might want to avoid >> third party signatures. Only if they deeply fail to understand what DKIM does. I agree this has no place in a deployment document. R's, John From barryleiba at computer.org Mon Jul 20 14:01:47 2009 From: barryleiba at computer.org (Barry Leiba) Date: Mon, 20 Jul 2009 17:01:47 -0400 Subject: [ietf-dkim] Agenda for IETF 75 Message-ID: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> I have uploaded the following agenda to the IETF meeting materials manager: https://datatracker.ietf.org/meeting/75/materials.html ------------------------------------------ Agenda for DKIM meeting at IETF 75, Stockholm We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time. The primary purpose of the meeting is to talk about next steps, which may include 4871bis work. Agenda: 1. Administrative: agenda review, WG status review, etc. (5 mins) 2. Discussion of next steps. (the rest of the time) Specific topics for discussion: - Is there enough energy to update DKIM base (RFC 4871) & go to draft standard? - Is DKIM base ready for that? Do we have enough experience to know it's stable? - Should we eliminate features in the process, to steamline? - If so, what features? - Do we have good statistics on what features are used on each side? ------------------------------------------ If anyone wants to make a specific presentation, please post here, or let us know at . Barry (as chair) From dhc at dcrocker.net Mon Jul 20 16:02:00 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Mon, 20 Jul 2009 16:02:00 -0700 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> Message-ID: <4A64F768.3030804@dcrocker.net> Barry, I think it is unlikely that there will be much response data, by the time of the meeting, to the deployment survey I've sent. Still, it might be worth some discussion, including where else to circulate it to and what we think we'll know after we get a sufficient number of responses. d/ Barry Leiba wrote: > I have uploaded the following agenda to the IETF meeting materials manager: > https://datatracker.ietf.org/meeting/75/materials.html > > ------------------------------------------ > Agenda for DKIM meeting at IETF 75, Stockholm -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists at gmail.com Tue Jul 21 11:42:31 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Tue, 21 Jul 2009 14:42:31 -0400 Subject: [ietf-dkim] DKIM field usage survey In-Reply-To: <4A5A224B.50006@dcrocker.net> References: <4A5A224B.50006@dcrocker.net> Message-ID: <6c9fcc2a0907211142u3b719f12ted68a19510af696a@mail.gmail.com> DKIM folks: > One requirement for moving a specification from Proposed to Draft status is > to supply an Implementation Report: > > ? > > ? > > I've put together survey forms -- one for signers and one for verifiers -- > that should supply us with some raw field data, to make it possible to > assemble a detailed report. If you haven't already, please respond to Dave's surveys (you can reply directly to him, and don't have to post your response here), and please forward his surveys on to others whose input we should collect. Thanks. Barry (as chair) From iesg-secretary at ietf.org Thu Jul 23 01:56:44 2009 From: iesg-secretary at ietf.org (The IESG) Date: Thu, 23 Jul 2009 01:56:44 -0700 (PDT) Subject: [ietf-dkim] Protocol Action: 'RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update' to Proposed Standard Message-ID: <20090723085644.B13773A69AF@core3.amsl.com> The IESG has approved the following document: - 'RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update ' as a Proposed Standard This document is the product of the Domain Keys Identified Mail Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871-errata-07.txt Technical Summary This document updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures. Specifically the document clarifies the nature, roles and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an errata entry. Working Group Summary This document arose from an errata report against RFC 4871, and from attempts to address the issue raised, which required clarification of some terminology. After some discussion, it was clear that the working group is divided as to how extensive the clarification needs to be, with a significant majority opting for the more extensive version represented here. In a spirit of compromise and a desire for progress, the working group agreed to some changes to the text that make it acceptable to most of the participants. RFC 4871 was published two years ago, and since then, the collective understanding of the role of DKIM has improved based on deployment experience and work on the other DKIM WG drafts (Author Domain Signing Practices; Service Overview; Development, Deployment and Operations). Since it is not absolutely clear that the clarifications completely match the intent at the time when RFC 4871 was published (when the role of DKIM was less well understood), they are published as an RFC updating RFC 4871 instead of an RFC Editor errata, to ensure that they go through the normal IETF consensus process. Document Quality There is a significant level of deployment of DKIM, as documented by RFC 4871. In fact, the existing deployment and good interoperability is what makes a part of the working group unsure that a clarification of this nature is necessary. Nevertheless, discussion within the working group made it clear to many that there is a significant amount of disagreement as to what was meant in some less-used areas of RFC 4871. The working group believes that these updates will clarify the terminology and improve chances of interoperability among implementations that use those features. Personnel The document shepherd is Barry Leiba, and the responsible area director is Pasi Eronen. From barryleiba at computer.org Thu Jul 23 10:15:47 2009 From: barryleiba at computer.org (Barry Leiba) Date: Thu, 23 Jul 2009 13:15:47 -0400 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <4A6895C5.9050201@cisco.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> <4A6895C5.9050201@cisco.com> Message-ID: <9abf48a60907231015l1e36792bq81c39df6df876610@mail.gmail.com> > In order to level-set the group on the draft standard process, can > someone please send a pointer to the process for moving from PS to DS > (what the requirements are, and what is and isn't allowed to change)? > If more of us are on the same page with understanding that process, the > discussion is likely to be more productive. Dave's note that has his surveys also has a couple of pointers, though the first one is wrong now, after the IETF web site change. So, to be complete: The IETF standards process (BCP 9, RFC 2026): http://tools.ietf.org/html/rfc2026 Update to RFC 2026 on implementation reports (in last call since 7 July): http://tools.ietf.org/html/draft-dusseault-impl-reports IESG page of implementation reports: http://www.ietf.org/iesg/implementation-report.html Barry From barryleiba.mailing.lists at gmail.com Thu Jul 23 10:25:39 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Thu, 23 Jul 2009 13:25:39 -0400 Subject: [ietf-dkim] Fwd: Email statistics for SEC WGs In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: <6c9fcc2a0907231025x7464fe5dm49bcaf206a72ffa6@mail.gmail.com> Pasi sent the message below out, and I thought this group would like to see it. We "win" by a wide margin, it seems. Go, team! Well, as Pasi says, "I'm not sure what conclusions can be drawn from this," but "perhaps someone finds these interesting." Barry (as chair, and for what it's worth) ---------- Forwarded message ---------- From: Pasi.Eronen at nokia.com Date: Thu, Jul 23, 2009 at 4:02 AM Subject: [secdir] Email statistics for SEC WGs To: secdir at ietf.org FYI: Here's some data about how active the WG mailing lists in security area have been in 2009. I'm not sure what conclusions can be drawn from this -- different WGs are in different phases of their work, have different number of work items, and communication styles are different. But perhaps someone finds these interesting... Emails on WG mailing list from 2009-01-01 to 2009-07-21 (some spam excluded manually when it would have had a big effect on the numbers): WG ? ? ? ?messages/month ========= ============== dkim ? ? ?240 ipsecme ? 139 sasl ? ? ?103 pkix ? ? ?88 krb-wg ? ?83 isms ? ? ?82 tls ? ? ? 65 hokey ? ? 47 keyprov ? 36 smime ? ? 25 emu ? ? ? 23 kitten ? ?15 syslog ? ?11 nea ? ? ? 7 btns ? ? ?4 ltans ? ? 2 msec ? ? ?1 ============== total ? ? 971 Best regards, Pasi From fenton at cisco.com Thu Jul 23 09:54:29 2009 From: fenton at cisco.com (Jim Fenton) Date: Thu, 23 Jul 2009 09:54:29 -0700 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> Message-ID: <4A6895C5.9050201@cisco.com> In order to level-set the group on the draft standard process, can someone please send a pointer to the process for moving from PS to DS (what the requirements are, and what is and isn't allowed to change)? If more of us are on the same page with understanding that process, the discussion is likely to be more productive. -Jim Barry Leiba wrote: > I have uploaded the following agenda to the IETF meeting materials manager: > https://datatracker.ietf.org/meeting/75/materials.html > > ------------------------------------------ > Agenda for DKIM meeting at IETF 75, Stockholm > > We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time. > > The primary purpose of the meeting is to talk about next steps, which > may include 4871bis work. > > Agenda: > 1. Administrative: agenda review, WG status review, etc. (5 mins) > 2. Discussion of next steps. (the rest of the time) > > Specific topics for discussion: > - Is there enough energy to update DKIM base (RFC 4871) & go to draft standard? > - Is DKIM base ready for that? Do we have enough experience to know > it's stable? > - Should we eliminate features in the process, to steamline? > - If so, what features? > - Do we have good statistics on what features are used on each side? > ------------------------------------------ > > If anyone wants to make a specific presentation, please post here, or > let us know at . > > Barry (as chair) > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > From tony at att.com Thu Jul 23 12:22:46 2009 From: tony at att.com (Tony Hansen) Date: Thu, 23 Jul 2009 15:22:46 -0400 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <4A6895C5.9050201@cisco.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> <4A6895C5.9050201@cisco.com> Message-ID: <4A68B886.9090704@att.com> The key document is RFC 2026. It's been updated by several other RFCs, but none of them affect the status transitions. The key section is "4.1.2 Draft Standard". It's five paragraphs can be summarized as follows: 1) interoperable a) 2 independent & interoperable implementations b) "sufficient operational experience" c) "a strong belief that spec is mature and will be useful" 2) interoperability is applied on a option & feature basis a) any options or features not demonstrated to be interoperable by independent implementations must be removed 3) WG chair responsible for documenting implementations a) used for the qualification, and b) documentation about the testing of the interopability. c) Includes information on individual options/features. d) Submits to AD. 4) DS must be a) well understood and b) quite stable. c) Wide spread field experience is NOT required. ("it is possible ... [for DS specs] to demonstrate unforeseen behavior when subjected to large-scale use in production environments.") 5) Changes hereafter are only to fix specific problems encountered while deploying widely. Section 6.2 further adds 6) Must be at PS at least six months. That pretty much covers it. Tony Hansen tony at att.com Jim Fenton wrote: > In order to level-set the group on the draft standard process, can > someone please send a pointer to the process for moving from PS to DS > (what the requirements are, and what is and isn't allowed to change)? > If more of us are on the same page with understanding that process, the > discussion is likely to be more productive. > > -Jim > > Barry Leiba wrote: >> I have uploaded the following agenda to the IETF meeting materials manager: >> https://datatracker.ietf.org/meeting/75/materials.html >> >> ------------------------------------------ >> Agenda for DKIM meeting at IETF 75, Stockholm >> >> We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time. >> >> The primary purpose of the meeting is to talk about next steps, which >> may include 4871bis work. >> >> Agenda: >> 1. Administrative: agenda review, WG status review, etc. (5 mins) >> 2. Discussion of next steps. (the rest of the time) >> >> Specific topics for discussion: >> - Is there enough energy to update DKIM base (RFC 4871) & go to draft standard? >> - Is DKIM base ready for that? Do we have enough experience to know >> it's stable? >> - Should we eliminate features in the process, to steamline? >> - If so, what features? >> - Do we have good statistics on what features are used on each side? >> ------------------------------------------ >> >> If anyone wants to make a specific presentation, please post here, or >> let us know at . >> >> Barry (as chair) From jdfalk-lists at cybernothing.org Mon Jul 27 12:45:37 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Mon, 27 Jul 2009 13:45:37 -0600 Subject: [ietf-dkim] remote participation info Message-ID: <4A6E03E1.2020507@cybernothing.org> I'll be waking up early in Denver since I can't join y'all in Stockholm, so I've collected remote participation links from a handful of different tools pages. Please let me know if I've missed anything here: agenda: http://tools.ietf.org/wg/dkim/agenda?item=agenda75.html chair slides: http://www3.ietf.org/proceedings/75/slides/dkim-0.pdf other docs: http://tools.ietf.org/agenda/75/docs/dkim.tar.gz audio: http://feed.verilan.com/ietf/stream06.m3u jabber: xmpp:dkim at jabber.ietf.org?join jabber logs: http://jabber.ietf.org/logs/dkim -- J.D. Falk Return Path Inc http://www.returnpath.net/ From dhc at dcrocker.net Mon Jul 27 14:16:34 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Mon, 27 Jul 2009 23:16:34 +0200 Subject: [ietf-dkim] remote participation info In-Reply-To: <4A6E03E1.2020507@cybernothing.org> References: <4A6E03E1.2020507@cybernothing.org> Message-ID: <4A6E1932.1030901@dcrocker.net> JD, This is sufficiently diligent of you to make me a little surprised that you did not include a link to a complete recording of what we are going to say... I'm starting to feel as if actually being in the room will be redundant. d/ J.D. Falk wrote: > I'll be waking up early in Denver since I can't join y'all in Stockholm, so > I've collected remote participation links from a handful of different tools > pages. Please let me know if I've missed anything here: > > agenda: http://tools.ietf.org/wg/dkim/agenda?item=agenda75.html > > chair slides: http://www3.ietf.org/proceedings/75/slides/dkim-0.pdf > > other docs: http://tools.ietf.org/agenda/75/docs/dkim.tar.gz > > audio: http://feed.verilan.com/ietf/stream06.m3u > > jabber: xmpp:dkim at jabber.ietf.org?join > > jabber logs: http://jabber.ietf.org/logs/dkim > -- Dave Crocker Brandenburg InternetWorking bbiw.net From fenton at cisco.com Mon Jul 27 18:13:22 2009 From: fenton at cisco.com (Jim Fenton) Date: Mon, 27 Jul 2009 18:13:22 -0700 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <4A68B886.9090704@att.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> <4A6895C5.9050201@cisco.com> <4A68B886.9090704@att.com> Message-ID: <4A6E50B2.5000309@cisco.com> Tony, Do you have any information on what options and features were tested in the DKIM interoperability event in Fall 2007? That should establish the independent and interoperable implementations for a number of things? I found notes describing what had been found to need clarification, but not on what had been tested. -Jim Tony Hansen wrote: > The key document is RFC 2026. It's been updated by several other RFCs, > but none of them affect the status transitions. > > The key section is "4.1.2 Draft Standard". It's five paragraphs can be > summarized as follows: > > 1) interoperable > a) 2 independent & interoperable implementations > b) "sufficient operational experience" > c) "a strong belief that spec is mature and will be useful" > > 2) interoperability is applied on a option & feature basis > a) any options or features not demonstrated to be interoperable > by independent implementations must be removed > > 3) WG chair responsible for documenting implementations > a) used for the qualification, and > b) documentation about the testing of the interopability. > c) Includes information on individual options/features. > d) Submits to AD. > > 4) DS must be > a) well understood and > b) quite stable. > c) Wide spread field experience is NOT required. ("it is > possible ... [for DS specs] to demonstrate unforeseen behavior > when subjected to large-scale use in production environments.") > > 5) Changes hereafter are only to fix specific problems encountered > while deploying widely. > > Section 6.2 further adds > 6) Must be at PS at least six months. > > That pretty much covers it. > > Tony Hansen > tony at att.com > > Jim Fenton wrote: > >> In order to level-set the group on the draft standard process, can >> someone please send a pointer to the process for moving from PS to DS >> (what the requirements are, and what is and isn't allowed to change)? >> If more of us are on the same page with understanding that process, the >> discussion is likely to be more productive. >> >> -Jim >> >> Barry Leiba wrote: >> >>> I have uploaded the following agenda to the IETF meeting materials manager: >>> https://datatracker.ietf.org/meeting/75/materials.html >>> >>> ------------------------------------------ >>> Agenda for DKIM meeting at IETF 75, Stockholm >>> >>> We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time. >>> >>> The primary purpose of the meeting is to talk about next steps, which >>> may include 4871bis work. >>> >>> Agenda: >>> 1. Administrative: agenda review, WG status review, etc. (5 mins) >>> 2. Discussion of next steps. (the rest of the time) >>> >>> Specific topics for discussion: >>> - Is there enough energy to update DKIM base (RFC 4871) & go to draft standard? >>> - Is DKIM base ready for that? Do we have enough experience to know >>> it's stable? >>> - Should we eliminate features in the process, to steamline? >>> - If so, what features? >>> - Do we have good statistics on what features are used on each side? >>> ------------------------------------------ >>> >>> If anyone wants to make a specific presentation, please post here, or >>> let us know at . >>> >>> Barry (as chair) >>> > > > From mike at mtcc.com Wed Jul 22 06:17:23 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 22 Jul 2009 06:17:23 -0700 Subject: [ietf-dkim] Agenda for IETF 75 In-Reply-To: <4A6E50B2.5000309@cisco.com> References: <6c9fcc2a0907201401p2ac5db1dj42ae71100b67abd9@mail.gmail.com> <4A6895C5.9050201@cisco.com> <4A68B886.9090704@att.com> <4A6E50B2.5000309@cisco.com> Message-ID: <4A671163.4050802@mtcc.com> IIRC, we showed interoperability with all aspects of the spec. In particular, both Murray's and mine have had the ability to do everything, but Tony's, Arvil's, the folks at Port 25 and most of the other "mature" implementations all interoperated, where "mature" was two years ago. I imagine that the less mature ones at the time have come up to speed in the mean time. So for the sake of DS, we've had abundant evidence of "interoperable" for almost 2 years at least. Mike Jim Fenton wrote: > Tony, > > Do you have any information on what options and features were tested in > the DKIM interoperability event in Fall 2007? That should establish the > independent and interoperable implementations for a number of things? I > found notes describing what had been found to need clarification, but > not on what had been tested. > > -Jim > > Tony Hansen wrote: > >> The key document is RFC 2026. It's been updated by several other RFCs, >> but none of them affect the status transitions. >> >> The key section is "4.1.2 Draft Standard". It's five paragraphs can be >> summarized as follows: >> >> 1) interoperable >> a) 2 independent & interoperable implementations >> b) "sufficient operational experience" >> c) "a strong belief that spec is mature and will be useful" >> >> 2) interoperability is applied on a option & feature basis >> a) any options or features not demonstrated to be interoperable >> by independent implementations must be removed >> >> 3) WG chair responsible for documenting implementations >> a) used for the qualification, and >> b) documentation about the testing of the interopability. >> c) Includes information on individual options/features. >> d) Submits to AD. >> >> 4) DS must be >> a) well understood and >> b) quite stable. >> c) Wide spread field experience is NOT required. ("it is >> possible ... [for DS specs] to demonstrate unforeseen behavior >> when subjected to large-scale use in production environments.") >> >> 5) Changes hereafter are only to fix specific problems encountered >> while deploying widely. >> >> Section 6.2 further adds >> 6) Must be at PS at least six months. >> >> That pretty much covers it. >> >> Tony Hansen >> tony at att.com >> >> Jim Fenton wrote: >> >> >>> In order to level-set the group on the draft standard process, can >>> someone please send a pointer to the process for moving from PS to DS >>> (what the requirements are, and what is and isn't allowed to change)? >>> If more of us are on the same page with understanding that process, the >>> discussion is likely to be more productive. >>> >>> -Jim >>> >>> Barry Leiba wrote: >>> >>> >>>> I have uploaded the following agenda to the IETF meeting materials manager: >>>> https://datatracker.ietf.org/meeting/75/materials.html >>>> >>>> ------------------------------------------ >>>> Agenda for DKIM meeting at IETF 75, Stockholm >>>> >>>> We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time. >>>> >>>> The primary purpose of the meeting is to talk about next steps, which >>>> may include 4871bis work. >>>> >>>> Agenda: >>>> 1. Administrative: agenda review, WG status review, etc. (5 mins) >>>> 2. Discussion of next steps. (the rest of the time) >>>> >>>> Specific topics for discussion: >>>> - Is there enough energy to update DKIM base (RFC 4871) & go to draft standard? >>>> - Is DKIM base ready for that? Do we have enough experience to know >>>> it's stable? >>>> - Should we eliminate features in the process, to steamline? >>>> - If so, what features? >>>> - Do we have good statistics on what features are used on each side? >>>> ------------------------------------------ >>>> >>>> If anyone wants to make a specific presentation, please post here, or >>>> let us know at . >>>> >>>> Barry (as chair) >>>> >>>> >> >> > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > From barryleiba.mailing.lists at gmail.com Thu Jul 30 00:52:00 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Thu, 30 Jul 2009 03:52:00 -0400 Subject: [ietf-dkim] DKIM summary report (IETF 75) Message-ID: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> The DKIM working group met on Tuesday afternoon. The group's chartered work is nearly done (the last document is in WGLC, and two others are now in the RFC Editor queue), so the goal of this meeting was to discuss implementation reports and draft-standard progression for the base protocol. Dave Crocker has posted implementation surveys to the mailing list, but has so far gotten few replies. WG participants were urged to complete them, and to pass them on to others. Barry will pass them to MAAWG (Messaging Anti-Abuse Working Group) and urge response, as IETF liaison to MAAWG. Barry would like to collect data not only on feature use by signers and verifiers, but also on what use the verifiers make of the results. There was much discussion about dropping unused or little-used features in the process of going to draft standard. We note that RFC 2026 *requires* dropping features that are truly unused, but whether to drop others is a different question. Several opinions were given about keeping all features, because, while there's plenty of experience with signing and verifying, knowledge of usage of the result of verifying is still limited. We don't yet know what verifiers will decide is important, over time. Counter-argument: history shows that when we learn that, we'll find that the features we kept purely speculatively will be the wrong ones anyway. Informal vote showed approximately a 2-to-1 preference for keeping *all* features, versus removing some. Chairs don't consider that to be sufficient for "rough consensus", so it will be discussed on the list. Pasi pointed out, and the chairs agree, that because we had consensus on these to start with, the default action, lacking clear consensus to remove a feature, is to keep it. There was also discussion indicating that documenting DKIM use cases could be helpful. Perhaps this could be added to the "deployment" document (in WGLC now), or perhaps using an easily updated wiki. Barry Leiba (and Stephen Farrell) From dhc at dcrocker.net Thu Jul 30 03:17:45 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Thu, 30 Jul 2009 12:17:45 +0200 Subject: [ietf-dkim] DKIM summary report (IETF 75) In-Reply-To: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> References: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> Message-ID: <4A717349.3010900@dcrocker.net> Barry Leiba wrote: > The DKIM working group met on Tuesday afternoon. Barry, Just wanted to thank you for writing such an excellent summary of the meeting. I think you captured the salient points perfectly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From gmail.sant9442 at winserver.com Thu Jul 30 10:40:34 2009 From: gmail.sant9442 at winserver.com (hector) Date: Thu, 30 Jul 2009 13:40:34 -0400 Subject: [ietf-dkim] DKIM summary report (IETF 75) In-Reply-To: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> References: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> Message-ID: <4A71DB12.7030408@winserver.com> Whats missing is possible a survey on why there is a market of potential implementators who are on the fence, have not gave the "go ahead" or are just plain leary about the whole thing, even among those who have been involved since early on. In other words, a survey to find out what are the barriers to implementation. -- Barry Leiba wrote: > The DKIM working group met on Tuesday afternoon. The group's > chartered work is nearly done (the last document is in WGLC, and two > others are now in the RFC Editor queue), so the goal of this meeting > was to discuss implementation reports and draft-standard progression > for the base protocol. > > Dave Crocker has posted implementation surveys to the mailing list, > but has so far gotten few replies. WG participants were urged to > complete them, and to pass them on to others. Barry will pass them to > MAAWG (Messaging Anti-Abuse Working Group) and urge response, as IETF > liaison to MAAWG. Barry would like to collect data not only on > feature use by signers and verifiers, but also on what use the > verifiers make of the results. > > There was much discussion about dropping unused or little-used > features in the process of going to draft standard. We note that RFC > 2026 *requires* dropping features that are truly unused, but whether > to drop others is a different question. Several opinions were given > about keeping all features, because, while there's plenty of > experience with signing and verifying, knowledge of usage of the > result of verifying is still limited. We don't yet know what > verifiers will decide is important, over time. Counter-argument: > history shows that when we learn that, we'll find that the features we > kept purely speculatively will be the wrong ones anyway. > > Informal vote showed approximately a 2-to-1 preference for keeping > *all* features, versus removing some. Chairs don't consider that to > be sufficient for "rough consensus", so it will be discussed on the > list. Pasi pointed out, and the chairs agree, that because we had > consensus on these to start with, the default action, lacking clear > consensus to remove a feature, is to keep it. > > There was also discussion indicating that documenting DKIM use cases > could be helpful. Perhaps this could be added to the "deployment" > document (in WGLC now), or perhaps using an easily updated wiki. > > Barry Leiba (and Stephen Farrell) > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From barryleiba.mailing.lists at gmail.com Thu Jul 30 10:59:47 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Thu, 30 Jul 2009 13:59:47 -0400 Subject: [ietf-dkim] DKIM summary report (IETF 75) In-Reply-To: <4A71DB12.7030408@winserver.com> References: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> <4A71DB12.7030408@winserver.com> Message-ID: <6c9fcc2a0907301059n28d1d658l27da231e4a3e192f@mail.gmail.com> (Removed SAAG from the cc list.) > Whats missing is possible a survey on why there is a market of > potential implementators who are on the fence, have not gave the "go > ahead" or are just plain leary about the whole thing, even among those > who have been involved since early on. I like that idea. Dave, can you incorporate this into one of the surveys, or should we have a third survey for this that we could pass around (and take to MAAWG)? Barry From dhc at dcrocker.net Fri Jul 31 00:01:01 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Fri, 31 Jul 2009 09:01:01 +0200 Subject: [ietf-dkim] DKIM summary report (IETF 75) In-Reply-To: <6c9fcc2a0907301059n28d1d658l27da231e4a3e192f@mail.gmail.com> References: <6c9fcc2a0907300052m71a3846kb8adae1370e4c678@mail.gmail.com> <4A71DB12.7030408@winserver.com> <6c9fcc2a0907301059n28d1d658l27da231e4a3e192f@mail.gmail.com> Message-ID: <4A7296AD.20303@dcrocker.net> Barry Leiba wrote: > (Removed SAAG from the cc list.) > >> Whats missing is possible a survey on why there is a market of >> potential implementators who are on the fence, have not gave the "go >> ahead" or are just plain leary about the whole thing, even among those >> who have been involved since early on. > > I like that idea. Dave, can you incorporate this into one of the > surveys, or should we have a third survey for this that we could pass > around (and take to MAAWG)? Market research, such as understanding the reasons for consumer choices, can indeed be helpful. However attempting to study the reasons that potential "consumers" of DKIM do or not deploy it requires fundamentally different methodology, and produces fundamentally different information, than the implementation report. Simply put, one looks for a few kinds of 'what' and the other looks for a few kinds of 'why'. One obtains objective data. The other subjective. In addition in this particular case, they the target subjects are in explicitly non-overlapping populations. One has deployed DKIM. The other has not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tony at att.com Fri Jul 31 07:19:43 2009 From: tony at att.com (Tony Hansen) Date: Fri, 31 Jul 2009 10:19:43 -0400 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <200810301842.50416.Mark.Martinec+dkim@ijs.si> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> Message-ID: <4A72FD7F.5090502@att.com> Mark Martinec wrote: > John Levine wrote: >> It is certainly the kind of bug that occurs in PHP scripts when the >> programmer doesn't perfectly understand the quoting rules. It's >> happened to me. > > I'm collecting a set of common mistakes breaking DKIM signatures. Pulling up a message from a while ago. Mark, did you ever get further with your set of common mistakes? I had occasion to look at a number of DNS key records, and find the following common mistakes: Sample size: 65456 DNS _domainkey (DKIM+DK) records 16 missing semi-colons between fields 1 missing any separators (k=rsap=....) 14 invalid quotation marks (") surrounding the entire record 2 invalid \" surrounding the entire record 5 invalid parens or paren+quotes surrounding the entire record 47 \-quoted characters, particularly \; 9 TTL value or other random DNS data showing up in the record 1 TTL value being in the record instead of the public key 17 random characters in the record, e.g. {, CRLF, backspace, SUB, > 113 SPF records being returned 13 key only, no p= or any other options 1 encoded ; as %3B 1 missing tag before = 8 other data in record (dkim=all, O=-, r=, &, ") 1 v=DKIM1 not first field in record 50 other random errors --- 299 I was not able to verify if any of the keys that had spaces within them were actually valid keys or not. The good news is that of the sample, the majority of the records were just fine. I'm wondering if there is a need for a web interface at dkim.org that would validate someone's _domainkey TXT record. Thoughts? Tony Hansen tony at att.com From fenton at cisco.com Fri Jul 31 10:22:37 2009 From: fenton at cisco.com (Jim Fenton) Date: Fri, 31 Jul 2009 10:22:37 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <4A72FD7F.5090502@att.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> Message-ID: <4A73285D.3020909@cisco.com> Tony, If you still have the records, can you count the number of records with g=; ? That's used in an example in some of the DomainKey specs and works for DK but means "match nothing" for DKIM. -Jim Tony Hansen wrote: > Mark Martinec wrote: > > John Levine wrote: > >> It is certainly the kind of bug that occurs in PHP scripts when the > >> programmer doesn't perfectly understand the quoting rules. It's > >> happened to me. > > > > I'm collecting a set of common mistakes breaking DKIM signatures. > > Pulling up a message from a while ago. Mark, did you ever get further > with your set of common mistakes? > > I had occasion to look at a number of DNS key records, and find the > following common mistakes: > > Sample size: 65456 DNS _domainkey (DKIM+DK) records > > 16 missing semi-colons between fields > 1 missing any separators (k=rsap=....) > 14 invalid quotation marks (") surrounding the entire record > 2 invalid \" surrounding the entire record > 5 invalid parens or paren+quotes surrounding the entire record > 47 \-quoted characters, particularly \; > 9 TTL value or other random DNS data showing up in the record > 1 TTL value being in the record instead of the public key > 17 random characters in the record, e.g. {, CRLF, backspace, SUB, > > 113 SPF records being returned > 13 key only, no p= or any other options > 1 encoded ; as %3B > 1 missing tag before = > 8 other data in record (dkim=all, O=-, r=, &, ") > 1 v=DKIM1 not first field in record > 50 other random errors > --- > 299 > > I was not able to verify if any of the keys that had spaces within them > were actually valid keys or not. > > The good news is that of the sample, the majority of the records were > just fine. > > I'm wondering if there is a need for a web interface at dkim.org that > would validate someone's _domainkey TXT record. > > Thoughts? > > Tony Hansen > tony at att.com > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > From ietf-dkim at kitterman.com Fri Jul 31 12:08:44 2009 From: ietf-dkim at kitterman.com (Scott Kitterman) Date: Fri, 31 Jul 2009 15:08:44 -0400 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <4A72FD7F.5090502@att.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> Message-ID: <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >I'm wondering if there is a need for a web interface at dkim.org that >would validate someone's _domainkey TXT record. > I'd say yes. It would provide a good way to isolate record specific issues from other potential problems people are having error sources when troubleshooting. Scott K From msk at cloudmark.com Fri Jul 31 13:24:00 2009 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Fri, 31 Jul 2009 13:24:00 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> Message-ID: > -----Original Message----- > From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- > bounces at mipassoc.org] On Behalf Of Scott Kitterman > Sent: Friday, July 31, 2009 12:09 PM > To: ietf-dkim at mipassoc.org > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: > >I'm wondering if there is a need for a web interface at dkim.org that > >would validate someone's _domainkey TXT record. > > I'd say yes. It would provide a good way to isolate record specific > issues > from other potential problems people are having error sources when > troubleshooting. A verifier equipped with additional code to email sites whose keys or policy records contain errors might be useful. Then again, it might also be obnoxious. From steve at wordtothewise.com Fri Jul 31 14:02:20 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Fri, 31 Jul 2009 14:02:20 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> Message-ID: <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> (This may be a duplicate, I have too many email addresses) On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: > On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >> I'm wondering if there is a need for a web interface at dkim.org that >> would validate someone's _domainkey TXT record. >> > I'd say yes. It would provide a good way to isolate record specific > issues > from other potential problems people are having error sources when > troubleshooting. I have some perl code that does some validation for internal use; it'd be fairly easy to turn it into a webapp. Cheers, Steve From franck at genius.com Fri Jul 31 15:22:39 2009 From: franck at genius.com (Franck Martin) Date: Sat, 1 Aug 2009 10:22:39 +1200 (FJT) Subject: [ietf-dkim] DKIM adoption Message-ID: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Looking at DKIM adoption. I have seen statements that some mailers will do DKIM based reputation if available, but I have yet to see a statement as either: -an email not signed with DKIM will have its reputation lowered (less likely to pass filters) -an email signed with DKIM will have its reputation increased (more likely to pass filters) I think if there were some postmasters making such statement it would boost the adoption of DKIM. I think stating that some postmasters are moving to domain based reputation is just encouraging the status quo of not DKIM signing to stay in IP based reputation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090801/900552c8/attachment.html From steve at wordtothewise.com Fri Jul 31 16:17:29 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Fri, 31 Jul 2009 16:17:29 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Jul 31, 2009, at 3:22 PM, Franck Martin wrote: > Looking at DKIM adoption. I have seen statements that some mailers > will do DKIM based reputation if available, but I have yet to see a > statement as either: > -an email not signed with DKIM will have its reputation lowered > (less likely to pass filters) > -an email signed with DKIM will have its reputation increased (more > likely to pass filters) > > I think if there were some postmasters making such statement it > would boost the adoption of DKIM. I doubt that either is true, though. A DKIM signature allows you to acquire increased or decreased reputation based on the history of that signing token. If I've never seen that token before, or I've seen bad behaviour associated with that token, it's not going to increase the reputation of the email (not in any sane mail filtering system anyway). Conversely, if I see unsigned mail coming in from an IP address that's sent great mail forever, I'm not going to decimate the mail stream just to encourage DKIM adoption. Might there be a grey area where the existence of a DKIM signature just pushes it over the edge? Maybe, but it's going to be a pretty small grey area. > I think stating that some postmasters are moving to domain based > reputation is just encouraging the status quo of not DKIM signing to > stay in IP based reputation. And there's nothing wrong with that. People should be moving to DKIM because of the actual advantages, not because of that sort of artificial pressure on them, I think. Requiring DKIM before setting up an FBL or a red carpet seems a more reasonable sort of pressure for an ISP to apply, should they feel so inclined. Cheers, Steve From franck at genius.com Fri Jul 31 17:51:01 2009 From: franck at genius.com (Franck Martin) Date: Sat, 1 Aug 2009 12:51:01 +1200 (FJT) Subject: [ietf-dkim] DKIM adoption In-Reply-To: Message-ID: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> Yes the reputation of the domain override things, but what happens when it is the first time a domain is seen? Does DKIM help or not? Also, I'm thinking in terms of points like for spammassin. Seeing some patterns in the email increase or lower the points. I don't think a whole reputation judgement would be done on DKIM alone, unless the email is proven forged by DKIM but we are not there yet as ADSP is not widely spread nor adopted. ----- Original Message ----- From: "Steve Atkins" To: "DKIM WG" Sent: Saturday, 1 August, 2009 11:17:29 AM GMT +12:00 Fiji Subject: Re: [ietf-dkim] DKIM adoption On Jul 31, 2009, at 3:22 PM, Franck Martin wrote: > Looking at DKIM adoption. I have seen statements that some mailers > will do DKIM based reputation if available, but I have yet to see a > statement as either: > -an email not signed with DKIM will have its reputation lowered > (less likely to pass filters) > -an email signed with DKIM will have its reputation increased (more > likely to pass filters) > > I think if there were some postmasters making such statement it > would boost the adoption of DKIM. I doubt that either is true, though. A DKIM signature allows you to acquire increased or decreased reputation based on the history of that signing token. If I've never seen that token before, or I've seen bad behaviour associated with that token, it's not going to increase the reputation of the email (not in any sane mail filtering system anyway). Conversely, if I see unsigned mail coming in from an IP address that's sent great mail forever, I'm not going to decimate the mail stream just to encourage DKIM adoption. Might there be a grey area where the existence of a DKIM signature just pushes it over the edge? Maybe, but it's going to be a pretty small grey area. > I think stating that some postmasters are moving to domain based > reputation is just encouraging the status quo of not DKIM signing to > stay in IP based reputation. And there's nothing wrong with that. People should be moving to DKIM because of the actual advantages, not because of that sort of artificial pressure on them, I think. Requiring DKIM before setting up an FBL or a red carpet seems a more reasonable sort of pressure for an ISP to apply, should they feel so inclined. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090801/9c2dcec7/attachment.html From steve at wordtothewise.com Fri Jul 31 18:18:58 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Fri, 31 Jul 2009 18:18:58 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> References: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <2BB921A0-CEC8-4644-B004-8BB1A3532533@wordtothewise.com> On Jul 31, 2009, at 5:51 PM, Franck Martin wrote: > Yes the reputation of the domain override things, but what happens > when it is the first time a domain is seen? Does DKIM help or not? If there's no DKIM, then there's not really any obvious domain to be talking about when it comes to reputation, so I don't think that's a question that makes sense (at least not without more details as to what you mean by seeing a domain). > > Also, I'm thinking in terms of points like for spammassin. Seeing > some patterns in the email increase or lower the points. I don't > think a whole reputation judgement would be done on DKIM alone, Not all the time, no. But if the domain token attached to the message via DKIM is on a whitelist, or if there's a significant positive history, then it's quite likely that the DKIM based reputation would override other measures (and would likely be used to short circuit analysis to avoid expensive content-based work). > unless the email is proven forged by DKIM but we are not there yet > as ADSP is not widely spread nor adopted. > Yup. That's probably out of scope for this discussion, anyway. Cheers, Steve From ietf-dkim at kitterman.com Fri Jul 31 19:12:41 2009 From: ietf-dkim at kitterman.com (Scott Kitterman) Date: Fri, 31 Jul 2009 22:12:41 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> References: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <93754-SnapperMsgD8DB99B6C6995521@[75.197.60.166]> On Sat, 1 Aug 2009 12:51:01 +1200 (FJT) Franck Martin wrote: >Yes the reputation of the domain override things, but what happens when it is the first time a domain is seen? Does DKIM help or not? > It can't. >Also, I'm thinking in terms of points like for spammassin. Seeing some patterns in the email increase or lower the points. > > Some of the people involved early in the SPF project had the same idea. It did encourage spaammer to adopt it, but it also had a big backlash after people noticed spammers could publish SPF record just fine and the positive points were just helping spammers. I don't suggest a repeat. Scott K From dhc at dcrocker.net Fri Jul 31 21:04:28 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Sat, 01 Aug 2009 06:04:28 +0200 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> References: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4A73BECC.8010204@dcrocker.net> Franck Martin wrote: > Yes the reputation of the domain override things, but what happens when > it is the first time a domain is seen? Does DKIM help or not? Does the presence of a signature provide any objective data about the goodness or badness of the signer? If the claim is that it does, there needs to be an explanation of the basis, because I don't see it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From franck at genius.com Fri Jul 31 21:17:59 2009 From: franck at genius.com (Franck Martin) Date: Sat, 1 Aug 2009 16:17:59 +1200 (FJT) Subject: [ietf-dkim] DKIM adoption In-Reply-To: <14355841.10451249100204336.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> I was curious by Scott comment re SPF. Is there a class of spam that cannot get a DKIM signature? I would think botnets would be that class, as they usually infect computers and not sure they could DKIM sign as it would require them to set a DNS entry too. Knowing that botnets are 70% of spam, if DKIM could solve this one it would be great. so my question to add to your question "Does the presence of a signature provide any objective data about the goodness or badness of the signer?" is: is there a class of spam that cannot get a DKIM signature? ----- Original Message ----- From: "Dave CROCKER" To: "Franck Martin" Cc: "DKIM WG" Sent: Saturday, 1 August, 2009 4:04:28 PM GMT +12:00 Fiji Subject: Re: [ietf-dkim] DKIM adoption Franck Martin wrote: > Yes the reputation of the domain override things, but what happens when > it is the first time a domain is seen? Does DKIM help or not? Does the presence of a signature provide any objective data about the goodness or badness of the signer? If the claim is that it does, there needs to be an explanation of the basis, because I don't see it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090801/4c0fc967/attachment.html From steve at wordtothewise.com Fri Jul 31 22:02:25 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Fri, 31 Jul 2009 22:02:25 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> References: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Jul 31, 2009, at 9:17 PM, Franck Martin wrote: > I was curious by Scott comment re SPF. > > Is there a class of spam that cannot get a DKIM signature? > > I would think botnets would be that class, as they usually infect > computers and not sure they could DKIM sign as it would require them > to set a DNS entry too. Knowing that botnets are 70% of spam, if > DKIM could solve this one it would be great. This is trivial for botnets to do. Apart from the obvious ways, many botnets already run DNS. > > so my question to add to your question "Does the presence of a > signature provide any objective data about the goodness or badness > of the signer?" is: > is there a class of spam that cannot get a DKIM signature? It says that the software generating the email was written at some point after 2007. Which is a data point, but not a terribly useful one. Cheers, Steve From tony at att.com Sat Aug 1 09:45:22 2009 From: tony at att.com (Tony Hansen) Date: Sat, 01 Aug 2009 12:45:22 -0400 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <4A73285D.3020909@cisco.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <4A73285D.3020909@cisco.com> Message-ID: <4A747122.4020108@att.com> Jim Fenton wrote: > If you still have the records, can you count the number of records > with g=; ? That's used in an example in some of the DomainKey specs > and works for DK but means "match nothing" for DKIM. I was planning on doing an analysis of the key values anyway, so here goes. 65461 DNS _domainkey records were examined that did not contain syntax errors. Of these, 37309 were used by DKIM and 46623 were used by DomainKeys. (Some were used by both.) Of them, 2186 have v=DKIM1. ==== mistakes ==== As noted before, there were a number of mistakes found within the key records. I found occurrences of all of these DKIM=unknown O=- a=rsa-sha1 c=nofws c=relaxed/relaxed d=SOMEDOMAIN dkim=all i=* kv=DKIM1 o=- o=~ q=dns If I trim the list down to the v=DKIM1 records, there are STILL errors: c=relaxed/relaxed o=- There are a few records that have r=EMAIL values in them. ==== legal keys ==== ====== g= ====== The following valid g= values were used by DKIM: g= g=* g=noreply For v=DKIM1 records, it's just g=* g=noreply This confirms the suggestion a couple meetings ago that vendors should treat g= as equivalent to g=* if v=DKIM1 is not found. There were NO cases of g=; found for v=DKIM1 records. ====== h= ====== The following valid h= values were used by DKIM. All of these were in v=DKIM1 records: h=sha1 h=sha1:sha256 h=sha256 A notable mistake was an entry with this value: h=rsa-sha1 ====== k= ====== The following valid k= values were used by DKIM. k=rsa A notable mistake was an entry with this value: k=rsa-sha1 It was NOT the same record as the similar h= mistake. ====== n= ====== 1879 of the records used n=. ====== s= ====== The value s=email was used in 33 records, 31 along with v=DKIM1. ====== t= ====== The following valid t= values were used by DKIM. t=s t=s:y t=y t=y:s Of note are these two mistakes: t=n t=s|y Hope people found this of interest. Tony Hansen tony at att.com From franck at genius.com Sat Aug 1 21:14:15 2009 From: franck at genius.com (Franck Martin) Date: Sun, 2 Aug 2009 16:14:15 +1200 (FJT) Subject: [ietf-dkim] DKIM adoption In-Reply-To: <20090802032607.14763.qmail@simone.iecc.com> Message-ID: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> But is ICANN supposed to clean all these random valid domains? ;) ----- Original Message ----- From: "John Levine" To: ietf-dkim at mipassoc.org Cc: franck at genius.com Sent: Sunday, 2 August, 2009 3:26:07 PM GMT +12:00 Fiji Subject: Re: [ietf-dkim] DKIM adoption >Yes the reputation of the domain override things, but what happens when it is >the first time a domain is seen? Does DKIM help or not? If it did, how many milliseconds do you think it would take spammers to start signing with random valid domains? Using wildcards for the key records, it's a trivial little programming exercise. R's, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090802/422e58a2/attachment.html From johnl at iecc.com Sat Aug 1 20:26:07 2009 From: johnl at iecc.com (John Levine) Date: 2 Aug 2009 03:26:07 -0000 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <3631594.10291249087860289.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20090802032607.14763.qmail@simone.iecc.com> >Yes the reputation of the domain override things, but what happens when it is >the first time a domain is seen? Does DKIM help or not? If it did, how many milliseconds do you think it would take spammers to start signing with random valid domains? Using wildcards for the key records, it's a trivial little programming exercise. R's, John From markd+dkim at yahoo-inc.com Sat Aug 1 22:06:52 2009 From: markd+dkim at yahoo-inc.com (Mark Delany) Date: Sat, 1 Aug 2009 22:06:52 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: > But is ICANN supposed to clean all these random valid domains? > > ;) You half-joke, but one of the arguments we presented to the FTC back in 2003 or so regarding spam was that we had an opportunity to regulate issuance of domain names. If not regulate, then at least insist on an identifiable legal entity being required to register a domain. With that "simple" expedient and wide-spread deployment of DKIM you have potential legal recourse to inappropriate email. ICANN of course couldn't care less as they are in it for the money, just as registrars are, but as I understand it, ICANN still operates under an MoA from the US Department of Commerce so the opportunity is not completely lost, yet. Unfortunately that opportunity may disappear soon as ICANN are pushing hard for complete autonomy, at which point profit will always be the primary motive. My point being, issuance of domain names could be a choke-point and combined with DKIM potentially provides recourse that is currently not available. This attacks the opposite end of the spectrum that "reputation" focusses on. Having said that, you could then have reputation systems based on jurisdictional recourse. What if you receive traffic from a domain and you are able to query for the legal owner of that domain and whether you could sue that domain for spamming? A jurisdictional market for domains could move good senders to register in tougher jurisdictions whereas the bad guys would stay well clear. Just as companies today decide whether to register on the NYSE or in the Cayman Islands. Just another arrow in the quiver, but a useful one methinks. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090801/27c73261/attachment.html From johnl at iecc.com Sun Aug 2 04:30:44 2009 From: johnl at iecc.com (John R. Levine) Date: Sun, 2 Aug 2009 07:30:44 -0400 (EDT) Subject: [ietf-dkim] DKIM adoption In-Reply-To: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > But is ICANN supposed to clean all these random valid domains? Ahem. Domain is not a synonym for top-level or second-level domain. These are all domains: foo.badguy.com bar.badguy.com baz.badguy.com goo.badguy.com Don't even think of suggesting that domains are the "same" if the last N components are the same, until you have read and understood the endless discussions here and elsewhere of why that doesn't work. R's, John >> Yes the reputation of the domain override things, but what happens when it is >> the first time a domain is seen? Does DKIM help or not? > > If it did, how many milliseconds do you think it would take spammers to > start signing with random valid domains? Using wildcards for the key > records, it's a trivial little programming exercise. From johnl at iecc.com Sun Aug 2 04:38:13 2009 From: johnl at iecc.com (John R. Levine) Date: Sun, 2 Aug 2009 07:38:13 -0400 (EDT) Subject: [ietf-dkim] DKIM adoption In-Reply-To: <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> Message-ID: > You half-joke, but one of the arguments we presented to the FTC back in 2003 > or so regarding spam was that we had an opportunity to regulate issuance of > domain names. If not regulate, then at least insist on an identifiable legal > entity being required to register a domain. Without going into the rococo nightmare that is ICANN politics, forget it. Beyond the fact that ICANN has no interest in making it harder to register domains (other than perhaps via incremental price increases), they only set the rules for generic TLDs, three letters and longer, not two-letter country code TLDs. The Joint Project Agreement with the US government isn't going away any time soon, and the US government has always been in favor of more accountability, e.g., the .US domain forbids proxy registrations, but it's political problem due to privacy laws in the EU and Canada protecting domains that at least claim to be registered by individuals. R's, John From prussell at nd.edu Sun Aug 2 05:33:19 2009 From: prussell at nd.edu (Paul Russell) Date: Sun, 02 Aug 2009 08:33:19 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> References: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4A75878F.7020004@nd.edu> On 8/1/2009 00:17, Franck Martin wrote: > I was curious by Scott comment re SPF. > > Is there a class of spam that cannot get a DKIM signature? > > I would think botnets would be that class, as they usually infect > computers and not sure they could DKIM sign as it would require them > to set a DNS entry too. Knowing that botnets are 70% of spam, if DKIM > could solve this one it would be great. You will not eliminate botnet spam by requiring a valid DKIM signature on every message accepted your mail servers. DKIM signatures are associated with domains, not sending IP addresses or the DNS hostnames associated with those IP addresses. Spammers register countless domains every day; they could easily generate and publish DKIM keys for those domains. The spamware used on zombies could be modified to use sender addresses in those domains and generate DKIM signatures for outbound messages. There is no technical reason why it could not be done. On the other hand, in the absence of wide-spread adoption of DKIM by legitimate senders, there is little, if any, incentive for spammers to move in this direction, because it eliminates their ability to used bogus/forged sender addresses in domains they do not control. There are techniques which can be used to block most spam from botnets, without the overhead of validating DKIM signatures. Most, if not all, of these tecniques have non-zero FP rates, but some sites have decided that the benefits of these techniques outweigh the costs. > so my question to add to your question "Does the presence of a signature > provide any objective data about the goodness or badness of the signer?" is: > is there a class of spam that cannot get a DKIM signature? Probably not. But DKIM is not designed to provide a message recipient with the ability to determine whether a message is spam; it is designed to provide a message recipient with the ability to determine whether a message was sent by the apparent sender. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame From steve at wordtothewise.com Sun Aug 2 18:33:52 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Sun, 2 Aug 2009 18:33:52 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> Message-ID: On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote: > (This may be a duplicate, I have too many email addresses) > > On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: > >> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >>> I'm wondering if there is a need for a web interface at dkim.org >>> that >>> would validate someone's _domainkey TXT record. >>> >> I'd say yes. It would provide a good way to isolate record >> specific issues >> from other potential problems people are having error sources when >> troubleshooting. > > I have some perl code that does some validation for internal use; it'd > be fairly easy to turn it into a webapp. http://dkimcore.org/tools/dkimrecordcheck.html Given a selector and a domain it'll slurp the record from DNS. Then it parses it, using the BNF from the spec (why, oh, why do we support FWS in a DNS record?) and then sanity checks the various fields and gives a good / bad message. If anyone has good (or known bad) records that it gets wrong I'm interested to hear about it. Cheers, Steve From tony at att.com Mon Aug 3 02:20:37 2009 From: tony at att.com (Tony Hansen) Date: Mon, 03 Aug 2009 05:20:37 -0400 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> Message-ID: <4A76ABE5.7040401@att.com> Excellent job. Perhaps a pointer to this can go on the dkim.org site? Tony Hansen tony at att.com Steve Atkins wrote: > On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote: > >> (This may be a duplicate, I have too many email addresses) >> >> On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: >> >>> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >>>> I'm wondering if there is a need for a web interface at dkim.org >>>> that >>>> would validate someone's _domainkey TXT record. >>>> >>> I'd say yes. It would provide a good way to isolate record >>> specific issues >>> from other potential problems people are having error sources when >>> troubleshooting. >> I have some perl code that does some validation for internal use; it'd >> be fairly easy to turn it into a webapp. > > http://dkimcore.org/tools/dkimrecordcheck.html > > Given a selector and a domain it'll slurp the record from DNS. > > Then it parses it, using the BNF from the spec (why, oh, > why do we support FWS in a DNS record?) and then > sanity checks the various fields and gives a good / bad message. > > If anyone has good (or known bad) records that it gets wrong I'm > interested to hear about it. > > Cheers, > Steve > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From Bill.Oxley at cox.com Mon Aug 3 05:21:45 2009 From: Bill.Oxley at cox.com (Bill.Oxley at cox.com) Date: Mon, 3 Aug 2009 08:21:45 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <057C838A3833684986A72FB86DB055FD068FBE02EB@CATL0MS104.corp.cox.com> I am not ready to make that statement yet. Considering that a lot of spam has valid DKIM signatures I am not sure when I will make that statement ________________________________ From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Franck Martin Sent: Friday, July 31, 2009 6:23 PM To: ietf-dkim at mipassoc.org Subject: [ietf-dkim] DKIM adoption Looking at DKIM adoption. I have seen statements that some mailers will do DKIM based reputation if available, but I have yet to see a statement as either: -an email not signed with DKIM will have its reputation lowered (less likely to pass filters) -an email signed with DKIM will have its reputation increased (more likely to pass filters) I think if there were some postmasters making such statement it would boost the adoption of DKIM. I think stating that some postmasters are moving to domain based reputation is just encouraging the status quo of not DKIM signing to stay in IP based reputation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090803/a9db9b6e/attachment.html From msk at cloudmark.com Mon Aug 3 09:13:45 2009 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 3 Aug 2009 09:13:45 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> Message-ID: > -----Original Message----- > From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- > bounces at mipassoc.org] On Behalf Of Steve Atkins > Sent: Sunday, August 02, 2009 6:34 PM > To: DKIM WG > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > [...] Nice work! However: > If anyone has good (or known bad) records that it gets wrong I'm > interested to hear about it. It reports the contents of medusa3._domainkey.blackops.org as invalid which is not correct. That record contains an "r=" and an "rs=" tag, both of which are defined by active I-Ds. Those tags may be unknown to RFC4871, but that specification says such should merely be ignored; they don't render the record invalid. -MSK From steve at wordtothewise.com Mon Aug 3 09:58:55 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Mon, 3 Aug 2009 09:58:55 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> Message-ID: <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- >> bounces at mipassoc.org] On Behalf Of Steve Atkins >> Sent: Sunday, August 02, 2009 6:34 PM >> To: DKIM WG >> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >> >> [...] > > Nice work! However: > >> If anyone has good (or known bad) records that it gets wrong I'm >> interested to hear about it. > > It reports the contents of medusa3._domainkey.blackops.org as > invalid which is not correct. That record contains an "r=" and an > "rs=" tag, both of which are defined by active I-Ds. Those tags may > be unknown to RFC4871, but that specification says such should > merely be ignored; they don't render the record invalid. For typical DKIM users though, commenting on an invalid field as "This is probably invalid, but there might be an experimental I-D that's using it, so maybe it's OK and receivers may or may not ignore it" is going to be far more confusing than "This is wrong, fix it." - as if they're using "r=" it's probably a typo or a misunderstanding, rather than intentional use of an experimental field. You're intentionally using non-standard or experimental fields - so you know better than the mechanical validator, and that's OK. (If we were to add a form on dkim.org that points to the checker, that might be the place to discuss what it considers valid and what it doesn't.) It might be interesting to have an alternate checker that tracks the additional fields being discussed in active I-Ds too, though. Is there a registry of experimental fields or list of I-Ds anywhere? Cheers, Steve From msk at cloudmark.com Mon Aug 3 10:28:42 2009 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 3 Aug 2009 10:28:42 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> Message-ID: > -----Original Message----- > From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- > bounces at mipassoc.org] On Behalf Of Steve Atkins > Sent: Monday, August 03, 2009 9:59 AM > To: DKIM WG > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > For typical DKIM users though, commenting on an invalid field as "This > is probably invalid, but there might be an experimental I-D that's > using it, so maybe it's OK and receivers may or may not ignore it" is > going to be far more confusing than "This is wrong, fix it." - as if > they're using "r=" it's probably a typo or a misunderstanding, rather > than intentional use of an experimental field. How about: "The following tags are non-standard and will likely be ignored by most verifiers"? Some of Tony's examples such as "h=rsa-sha1" can certainly be reported as "invalid" as they are standardized tags with illegal values (i.e., the legal values are enumerated). > It might be interesting to have an alternate checker that tracks the > additional fields being discussed in active I-Ds too, though. Is there > a registry of experimental fields or list of I-Ds anywhere? Alas, no. And it would be difficult, I think, to try to corral people into using one in general (though the audience is currently pretty small so for now it's a practical idea). -MSK From steve at wordtothewise.com Mon Aug 3 10:37:02 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Mon, 3 Aug 2009 10:37:02 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> Message-ID: On Aug 3, 2009, at 10:28 AM, Murray S. Kucherawy wrote: >> >> >> For typical DKIM users though, commenting on an invalid field as >> "This >> is probably invalid, but there might be an experimental I-D that's >> using it, so maybe it's OK and receivers may or may not ignore it" is >> going to be far more confusing than "This is wrong, fix it." - as if >> they're using "r=" it's probably a typo or a misunderstanding, rather >> than intentional use of an experimental field. > > How about: "The following tags are non-standard and will likely be > ignored by most verifiers"? > > Some of Tony's examples such as "h=rsa-sha1" can certainly be > reported as "invalid" as they are standardized tags with illegal > values (i.e., the legal values are enumerated). > >> It might be interesting to have an alternate checker that tracks the >> additional fields being discussed in active I-Ds too, though. Is >> there >> a registry of experimental fields or list of I-Ds anywhere? > > Alas, no. And it would be difficult, I think, to try to corral > people into using one in general (though the audience is currently > pretty small so for now it's a practical idea). Ah. If there's no registry of fields then there's nothing to say that a receiver isn't experimenting with an r= field that's completely different to the r= field that Tony is publishing. So it isn't safe to assume that a receiver that isn't using Tony's definition of r= will ignore his r= field, rather we're solidly into undefined behavior and something that is definitely an error in a production record (as opposed to a record used for pre-arranged testing with a specific receiver). Cheers, Steve From mike at mtcc.com Mon Aug 3 10:34:03 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 03 Aug 2009 10:34:03 -0700 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> Message-ID: <4A771F8B.7090308@mtcc.com> On 08/03/2009 09:13 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- >> bounces at mipassoc.org] On Behalf Of Steve Atkins >> Sent: Sunday, August 02, 2009 6:34 PM >> To: DKIM WG >> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >> >> [...] > > Nice work! However: > >> If anyone has good (or known bad) records that it gets wrong I'm >> interested to hear about it. > > It reports the contents of medusa3._domainkey.blackops.org as invalid which is not correct. That record contains an "r=" and an "rs=" tag, both of which are defined by active I-Ds. Those tags may be unknown to RFC4871, but that specification says such should merely be ignored; they don't render the record invalid. An active I-D does not a standard make ;-) But yeah, it should probably just tag them as unknown/ignored-by-4871 rather than an error. Mike From dotis at mail-abuse.org Mon Aug 3 10:31:37 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 03 Aug 2009 13:31:37 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> Message-ID: <4A771EF9.7080308@mail-abuse.org> On 8/2/09 1:06 AM, Mark Delany wrote: > On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: > >> But is ICANN supposed to clean all these random valid domains? > > You half-joke, but one of the arguments we presented to the FTC back in > 2003 or so regarding spam was that we had an opportunity to regulate > issuance of domain names. If not regulate, then at least insist on an > identifiable legal entity being required to register a domain. Rather than viewing control of a domain as indicative of good email behavior, positive reputations based upon histories of DKIM signatures could offer an alternative or enhancement to methods currently used in the disposition of messages. As SMTP transitions into the use of IPv6, IP address reputations will also need to rapidly transition to a positive mode of assessment as perhaps the only method that has a chance to scale in the face of new levels of abuse. It might be interesting to review information exchanged during DKIM assessment, such as a hash of the i= value in conjunction with the DKIM key location. Perhaps a new industry standard could be adopted in this regard. It might be interesting to find whether there might be interest in developing third-party authorization schemes. -Doug From markd+dkim at yahoo-inc.com Mon Aug 3 11:01:13 2009 From: markd+dkim at yahoo-inc.com (Mark Delany) Date: Mon, 3 Aug 2009 11:01:13 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A771EF9.7080308@mail-abuse.org> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> <4A771EF9.7080308@mail-abuse.org> Message-ID: <40AF6913-E906-4C8A-ABDD-B67B10B3F9A5@yahoo-inc.com> On Aug 3, 2009, at 10:31 AM, Douglas Otis wrote: > On 8/2/09 1:06 AM, Mark Delany wrote: >> On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: >> >>> But is ICANN supposed to clean all these random valid domains? >> >> You half-joke, but one of the arguments we presented to the FTC >> back in >> 2003 or so regarding spam was that we had an opportunity to regulate >> issuance of domain names. If not regulate, then at least insist on an >> identifiable legal entity being required to register a domain. > > Rather than viewing control of a domain as indicative of good email > behavior, positive reputations based upon histories of DKIM > signatures could offer an alternative or enhancement to methods > currently used in the disposition of messages. > That's entirely orthogonal and nothing new. My point was something stronger and different from "reputation", namely something jurisdictional; can I find (and sue) the owner of the domain on the DKIM signature? Mark. From mike at mtcc.com Mon Aug 3 12:17:10 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 03 Aug 2009 12:17:10 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <40AF6913-E906-4C8A-ABDD-B67B10B3F9A5@yahoo-inc.com> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> <4A771EF9.7080308@mail-abuse.org> <40AF6913-E906-4C8A-ABDD-B67B10B3F9A5@yahoo-inc.com> Message-ID: <4A7737B6.2080109@mtcc.com> On 08/03/2009 11:01 AM, Mark Delany wrote: > On Aug 3, 2009, at 10:31 AM, Douglas Otis wrote: > >> On 8/2/09 1:06 AM, Mark Delany wrote: >>> On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: >>> >>>> But is ICANN supposed to clean all these random valid domains? >>> You half-joke, but one of the arguments we presented to the FTC >>> back in >>> 2003 or so regarding spam was that we had an opportunity to regulate >>> issuance of domain names. If not regulate, then at least insist on an >>> identifiable legal entity being required to register a domain. >> Rather than viewing control of a domain as indicative of good email >> behavior, positive reputations based upon histories of DKIM >> signatures could offer an alternative or enhancement to methods >> currently used in the disposition of messages. >> > > That's entirely orthogonal and nothing new. My point was something > stronger and different from "reputation", namely something > jurisdictional; can I find (and sue) the owner of the domain on the > DKIM signature? I think that it's larger than that: Given a domain name, what can we educe from it? 1) who the registrant? o how long has it been around o etc, etc 2) who is the registrar? o how hard is it to mass-enroll domains? o are they known to turn a blind eye to spammers? etc, etc. That is, start looking up the food chain for bad behavior. Until there are negative consequences, registrars will take the free if smelly money. What can we do to create a negative consequence? Mike From jdfalk-lists at cybernothing.org Mon Aug 3 11:49:33 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Mon, 03 Aug 2009 12:49:33 -0600 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4A77313D.30709@cybernothing.org> Franck Martin wrote: > Looking at DKIM adoption. I have seen statements that some mailers will > do DKIM based reputation if available, but I have yet to see a statement > as either: > -an email not signed with DKIM will have its reputation lowered (less > likely to pass filters) > -an email signed with DKIM will have its reputation increased (more > likely to pass filters) > > I think if there were some postmasters making such statement it would > boost the adoption of DKIM. Yahoo! broadly hinted, some years ago, that they'd start giving a slight positive bump to messages signed with DomainKeys. Two things happened: 1. serious hardcore spammers (not just misguided marketers) started including DomainKeys signatures 2. lots of people who really should've known better started saying "use DomainKeys and your deliverability will improve!" We also wrote about the slow emergence of domain reputation recently, trying to avoid piling on to the hyperbolic misrepresentations so common on other email marketing blogs: http://www.returnpath.net/blog/2009/07/domain-reputation-what-it-mean.php -- J.D. Falk Return Path Inc http://www.returnpath.net/ From dhc at dcrocker.net Mon Aug 3 12:46:02 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Mon, 03 Aug 2009 12:46:02 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A75878F.7020004@nd.edu> References: <4026257.10471249100277484.JavaMail.franck@franck-martins-macbook-pro.local> <4A75878F.7020004@nd.edu> Message-ID: <4A773E7A.5050707@dcrocker.net> Paul Russell wrote: > Probably not. But DKIM is not designed to provide a message recipient with > the ability to determine whether a message is spam; it is designed to provide a > message recipient with the ability to determine whether a message was sent by > the apparent sender. Since your caution constructively seeks to pay attention to what DKIM is *not* and especially since that goes against most folks' expectations for DKIM, it's tempting simply to agree. Strictly speaking, however, the 'apparent sender' reference is likely to be problematic since those same "most folks" will think it means the author (From: field) and it might or might not. The signing does not even have to be a direct handler of the message, per the Goodmail form signing "on behalf of" the author's organization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc at dcrocker.net Mon Aug 3 12:51:29 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Mon, 03 Aug 2009 12:51:29 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <057C838A3833684986A72FB86DB055FD068FBE02EB@CATL0MS104.corp.cox.com> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <057C838A3833684986A72FB86DB055FD068FBE02EB@CATL0MS104.corp.cox.com> Message-ID: <4A773FC1.2080701@dcrocker.net> Bill.Oxley at cox.com wrote: > , but I have yet to see a statement > as either: > -an email not signed with DKIM will have its reputation lowered (less > likely to pass filters) > -an email signed with DKIM will have its reputation increased (more > likely to pass filters) The presence or absence of a DKIM signature carries no inherent semantics about reputation of the signer. Consequently anyone increasing or lowering a reputation assessment based on the presence or absence of a DKIM signature is going far beyond its stated purpose. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis at mail-abuse.org Mon Aug 3 13:18:03 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 03 Aug 2009 13:18:03 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <40AF6913-E906-4C8A-ABDD-B67B10B3F9A5@yahoo-inc.com> References: <13545231.10531249186452277.JavaMail.franck@franck-martins-macbook-pro.local> <45815E4E-26EA-49EE-B348-34020C6ED546@yahoo-inc.com> <4A771EF9.7080308@mail-abuse.org> <40AF6913-E906-4C8A-ABDD-B67B10B3F9A5@yahoo-inc.com> Message-ID: <4A7745FB.4080601@mail-abuse.org> On 8/3/09 11:01 AM, Mark Delany wrote: > That's entirely orthogonal and nothing new. My point was something > stronger and different from "reputation", namely something > jurisdictional; can I find (and sue) the owner of the domain on the DKIM > signature? An ISP might, but recipients had their legal standing removed by CAN-SPAM. Regardless, reputation would be more cost effective. -Doug From tony at att.com Mon Aug 3 13:32:15 2009 From: tony at att.com (Tony Hansen) Date: Mon, 03 Aug 2009 16:32:15 -0400 Subject: [ietf-dkim] Escaping things in key/ADSP records In-Reply-To: <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> References: <20081029235250.47421.qmail@simone.iecc.com> <200810301842.50416.Mark.Martinec+dkim@ijs.si> <4A72FD7F.5090502@att.com> <93594-SnapperMsgD8DB99B6C698F1C4@[75.199.26.202]> <883510FB-2FE1-4534-8DF4-9C31ABB60D1E@wordtothewise.com> <4AF482FF-0489-4B64-992E-AB896E5C318F@wordtothewise.com> Message-ID: <4A77494F.6040107@att.com> It could put in a heading of "Unrecognized tag X=" for each such tag. Tony Hansen tony at att.com Steve Atkins wrote: > On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote: > >>> -----Original Message----- >>> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- >>> bounces at mipassoc.org] On Behalf Of Steve Atkins >>> Sent: Sunday, August 02, 2009 6:34 PM >>> To: DKIM WG >>> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >>> >>> [...] >> Nice work! However: >> >>> If anyone has good (or known bad) records that it gets wrong I'm >>> interested to hear about it. >> It reports the contents of medusa3._domainkey.blackops.org as >> invalid which is not correct. That record contains an "r=" and an >> "rs=" tag, both of which are defined by active I-Ds. Those tags may >> be unknown to RFC4871, but that specification says such should >> merely be ignored; they don't render the record invalid. > > For typical DKIM users though, commenting on an invalid field as "This > is probably invalid, but there might be an experimental I-D that's > using it, so maybe it's OK and receivers may or may not ignore it" is > going to be far more confusing than "This is wrong, fix it." - as if > they're using "r=" it's probably a typo or a misunderstanding, rather > than intentional use of an experimental field. > > You're intentionally using non-standard or experimental fields - so > you know better than the mechanical validator, and that's OK. > > (If we were to add a form on dkim.org that points to the checker, that > might be the place to discuss what it considers valid and what it > doesn't.) > > It might be interesting to have an alternate checker that tracks the > additional fields being discussed in active I-Ds too, though. Is there > a registry of experimental fields or list of I-Ds anywhere? > > Cheers, > Steve > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From steve at wordtothewise.com Mon Aug 3 16:15:52 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Mon, 3 Aug 2009 16:15:52 -0700 Subject: [ietf-dkim] Everything not forbidden is permitted Message-ID: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> Chatting with people offlist the issue of whether there is such a thing as a good or bad DKIM record came up. I'm trying to get a feel for peoples views on that so, to give a concrete example, if your postmaster came to you with this DKIM record they wanted you to publish in DNS, would you publish it as-is? If not, why not? september2006._domainkey.example.com 300 IN TXT "version=DKIM1; a=rsa- sha1; c=simple/simple; hash=sha1; t=testing; p=MIGfMA0G;" Cheers, Steve From franck at genius.com Mon Aug 3 16:33:23 2009 From: franck at genius.com (Franck Martin) Date: Tue, 4 Aug 2009 11:33:23 +1200 (FJT) Subject: [ietf-dkim] Everything not forbidden is permitted In-Reply-To: <15353695.741249342201978.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <14604644.761249342401146.JavaMail.franck@franck-martins-macbook-pro.local> Just some clarification, there is no way for an outsider to query this record if you don't know it exists? The selector basically hides the record from DNS in comparison to SPF which is easy to find in a DNS zone. ----- Original Message ----- From: "Steve Atkins" To: "DKIM WG" Sent: Tuesday, 4 August, 2009 11:15:52 AM GMT +12:00 Fiji Subject: [ietf-dkim] Everything not forbidden is permitted Chatting with people offlist the issue of whether there is such a thing as a good or bad DKIM record came up. I'm trying to get a feel for peoples views on that so, to give a concrete example, if your postmaster came to you with this DKIM record they wanted you to publish in DNS, would you publish it as-is? If not, why not? september2006._domainkey.example.com 300 IN TXT "version=DKIM1; a=rsa- sha1; c=simple/simple; hash=sha1; t=testing; p=MIGfMA0G;" Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090804/21cfc85e/attachment.html From steve at wordtothewise.com Mon Aug 3 16:40:19 2009 From: steve at wordtothewise.com (Steve Atkins) Date: Mon, 3 Aug 2009 16:40:19 -0700 Subject: [ietf-dkim] Everything not forbidden is permitted In-Reply-To: <14604644.761249342401146.JavaMail.franck@franck-martins-macbook-pro.local> References: <14604644.761249342401146.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Aug 3, 2009, at 4:33 PM, Franck Martin wrote: > Just some clarification, there is no way for an outsider to query > this record if you don't know it exists? Yup. > The selector basically hides the record from DNS in comparison to > SPF which is easy to find in a DNS zone. Assume the postmaster is going to be signing your outbound email using "september2006" as the selector. They're not messing with you - they're deploying DKIM, using the private key that goes with the p= public key in the record below. Cheers, Steve > > ----- Original Message ----- > From: "Steve Atkins" > To: "DKIM WG" > Sent: Tuesday, 4 August, 2009 11:15:52 AM GMT +12:00 Fiji > Subject: [ietf-dkim] Everything not forbidden is permitted > > Chatting with people offlist the issue of whether there is such a > thing as a good or bad DKIM record came up. > > I'm trying to get a feel for peoples views on that so, to give a > concrete example, if your postmaster came to you with this DKIM record > they wanted you to publish in DNS, would you publish it as-is? If not, > why not? > > september2006._domainkey.example.com 300 IN TXT "version=DKIM1; a=rsa- > sha1; c=simple/simple; hash=sha1; t=testing; p=MIGfMA0G gunk>;" > > Cheers, > Steve > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From gmail.sant9442 at winserver.com Mon Aug 3 17:28:56 2009 From: gmail.sant9442 at winserver.com (hector) Date: Mon, 03 Aug 2009 20:28:56 -0400 Subject: [ietf-dkim] Everything not forbidden is permitted In-Reply-To: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> References: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> Message-ID: <4A7780C8.90202@winserver.com> The near issue has already come up and the end-result - NO. A customer was asked by their direct marketing spammer to add DKIM/DKEY records because YAHOO was forcing the issue on the spammer to access YAHOO recipients. They wanted to signed: coupons.majorcompany.com and ask the company to add DNS selector records. But the major company did have a way to stop fake or 3rd party majorcompany.com dept.majorcompany.com services.majorcompany.com signatures once bad guys learned that the domain was being signed! Since DKIM lacks fault detection, the answer was no. -- HLS Steve Atkins wrote: > Chatting with people offlist the issue of whether there is such a > thing as a good or bad DKIM record came up. > > I'm trying to get a feel for peoples views on that so, to give a > concrete example, if your postmaster came to you with this DKIM record > they wanted you to publish in DNS, would you publish it as-is? If not, > why not? > > september2006._domainkey.example.com 300 IN TXT "version=DKIM1; a=rsa- > sha1; c=simple/simple; hash=sha1; t=testing; p=MIGfMA0G gunk>;" > > Cheers, > Steve From dotis at mail-abuse.org Tue Aug 4 08:13:18 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 04 Aug 2009 08:13:18 -0700 Subject: [ietf-dkim] Everything not forbidden is permitted In-Reply-To: <4A7780C8.90202@winserver.com> References: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> <4A7780C8.90202@winserver.com> Message-ID: <4A78500E.9090408@mail-abuse.org> On 8/3/09 5:28 PM, hector wrote: > The near issue has already come up and the end-result - NO. A > customer was asked by their direct marketing spammer to add DKIM/DKEY > records because YAHOO was forcing the issue on the spammer to access > YAHOO recipients. > > They wanted to signed: > > coupons.majorcompany.com > > and ask the company to add DNS selector records. But the major > company did have a way to stop fake or 3rd party > > majorcompany.com > dept.majorcompany.com > services.majorcompany.com > > signatures once bad guys learned that the domain was being signed! > > Since DKIM lacks fault detection, the answer was no. The g= tag within the key could limit the local-part of the i= value found in the signature header, but would not prevent the use of subdomains. This would mean that g=noreply would allow: noreply at coupons.majorcompany.com noreply at dept.coupons.majorcompany.com noreply at services.coupons.majorcompany.com and even without the g= restriction the key would not allow: majorcompany.com dept.majorcompany.com services.majorcompany.com -Doug From MHammer at ag.com Tue Aug 4 08:44:52 2009 From: MHammer at ag.com (MH Michael Hammer (5304)) Date: Tue, 4 Aug 2009 11:44:52 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Interesting replies. My apologies for my delayed response. I was off in Vegas at defcon and intentionally not getting online for the duration. While I don't believe that receivers would be particularly well served by lowering reputation for unsigned emails or raising reputation for those that are signed, it would certainly be useful if receivers took a stronger stance in saying they are taking advantage of DKIM signatures to track reputation. While in the past I have been primarily interested in first party signing, I have been thinking about potential benefits of our organization signing with a second signature so that we can use it across properties. Mike ________________________________ From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Franck Martin Sent: Friday, July 31, 2009 6:23 PM To: ietf-dkim at mipassoc.org Subject: [ietf-dkim] DKIM adoption Looking at DKIM adoption. I have seen statements that some mailers will do DKIM based reputation if available, but I have yet to see a statement as either: -an email not signed with DKIM will have its reputation lowered (less likely to pass filters) -an email signed with DKIM will have its reputation increased (more likely to pass filters) I think if there were some postmasters making such statement it would boost the adoption of DKIM. I think stating that some postmasters are moving to domain based reputation is just encouraging the status quo of not DKIM signing to stay in IP based reputation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090804/6e57360f/attachment.html From tony at att.com Tue Aug 4 14:51:42 2009 From: tony at att.com (Tony Hansen) Date: Tue, 04 Aug 2009 17:51:42 -0400 Subject: [ietf-dkim] Everything not forbidden is permitted In-Reply-To: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> References: <389D769D-3F0D-4B0B-8D11-308A56CC8BEA@wordtothewise.com> Message-ID: <4A78AD6E.6010609@att.com> I would ask them "Are you aware that this record contains tag keys and values that are not part of DKIM?" If they say yes and can tell me what they're doing, I'd gladly publish the record. If they say no, I'd have a chance to educate them and we'd go through the record point by point. Tony Hansen Steve Atkins wrote: > Chatting with people offlist the issue of whether there is such a > thing as a good or bad DKIM record came up. > > I'm trying to get a feel for peoples views on that so, to give a > concrete example, if your postmaster came to you with this DKIM record > they wanted you to publish in DNS, would you publish it as-is? If not, > why not? > > september2006._domainkey.example.com 300 IN TXT "version=DKIM1; a=rsa- > sha1; c=simple/simple; hash=sha1; t=testing; p=MIGfMA0G gunk>;" > > Cheers, > Steve From gmail.sant9442 at winserver.com Thu Aug 6 00:15:28 2009 From: gmail.sant9442 at winserver.com (hector) Date: Thu, 06 Aug 2009 03:15:28 -0400 Subject: [ietf-dkim] DKIM adoption In-Reply-To: References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4A7A8310.60502@winserver.com> MH Michael Hammer (5304) wrote: > While I don't believe that receivers would be particularly well served > by lowering reputation for unsigned emails or raising reputation for > those that are signed, it would certainly be useful if receivers took a > stronger stance in saying they are taking advantage of DKIM signatures > to track reputation. While in the past I have been primarily interested > in first party signing, I have been thinking about potential benefits of > our organization signing with a second signature so that we can use it > across properties. I find it very hard to justify to finishing the addition of DKIM into our wcSMTP and wcListServer products. We were all set to go when SSP was still in play and part of the DKIM API. Without policy and no public reputation services, adding DKIM would add confusion to our customer base as to its purpose. To me, technology come first, not marketing. So I ask you, how do you track "reputation?" especially anonymous? Doug and I had this discussion 2-3 years ago about the problem of "Blitz" attacks in order to force a DoS facsimile forcing the receiver to turn of DKIM processing. If DKIM needs batteries in order to have a payoff or some values, what batteries do you recommend? Also, with our mail model, post SMTP processing is after the mail is checked. Our stock mail filtering scripting language are at the SMTP and DATA level before a response is provided. When Mail is finally accepted, our design takes it very serious to no longer be part of the content decision making process - the buck (heuristic considerations) is passed to the operator. Its an old school philosophy that accepting mail is taken very serious. But if we were to add DKIM support, we would do so at the DATA level with our package. Efficiency and scalability is important. It has to be fast. That is why policy and fault tolerance was very important. The idea of processing and still accepting failure is a big waste of time for us. Note: that doesn't stop customers from adding DKIM themselves using some external post smtp scripting engine or whatever. But it won't be ours and 99$ of them are going use what we provide. After quite frankly, if I got 2 blind request for DKIM support, that would be a lot. If we don't support DKIM, it won't happen for them. -- From dotis at mail-abuse.org Thu Aug 6 08:25:56 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 06 Aug 2009 08:25:56 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A7A8310.60502@winserver.com> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <4A7A8310.60502@winserver.com> Message-ID: <4A7AF604.3060806@mail-abuse.org> On 8/6/09 12:15 AM, hector wrote: > If DKIM needs batteries in order to have a payoff or some values, what > batteries do you recommend? It seems DKIM might be used to bypass filtering that typically good messages would otherwise confront as a means to reduce false positives. Since few domains have only perfect users, one could also create a block list based upon the hash of the i= (on-behalf-of) value. The query might look something like: Query: .. For domains that have problematic users and don't offer even an opaque i= value that corresponds to message sources, the domain would need to be removed from the list which might have prevented false positive detections. -Doug From msk at cloudmark.com Thu Aug 6 10:50:39 2009 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Thu, 6 Aug 2009 10:50:39 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A7AF604.3060806@mail-abuse.org> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <4A7A8310.60502@winserver.com> <4A7AF604.3060806@mail-abuse.org> Message-ID: > -----Original Message----- > From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- > bounces at mipassoc.org] On Behalf Of Douglas Otis > Sent: Thursday, August 06, 2009 8:26 AM > To: hector > Cc: ietf-dkim at mipassoc.org; MH Michael Hammer (5304) > Subject: Re: [ietf-dkim] DKIM adoption > > Since few domains have only perfect users, one could also create a > block list based upon the hash of the i= (on-behalf-of) value. The > query might look something like: > > Query: .. In fact, there is an experimental DKIM reputation service out there now that does something of this nature. The implementation I wrote has optional support for it. I don't yet have any information about who's using it or what the results of such are. From jdfalk-lists at cybernothing.org Thu Aug 6 13:08:23 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 06 Aug 2009 14:08:23 -0600 Subject: [ietf-dkim] DKIM adoption In-Reply-To: References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <4A7A8310.60502@winserver.com> <4A7AF604.3060806@mail-abuse.org> Message-ID: <4A7B3837.8050409@cybernothing.org> Murray S. Kucherawy wrote: > In fact, there is an experimental DKIM reputation service out there now that does something of this nature. The implementation I wrote has optional support for it. I don't yet have any information about who's using it or what the results of such are. And, there are others in progress. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From dhc at dcrocker.net Fri Aug 7 07:21:38 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Fri, 07 Aug 2009 07:21:38 -0700 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A7B3837.8050409@cybernothing.org> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <4A7A8310.60502@winserver.com> <4A7AF604.3060806@mail-abuse.org> <4A7B3837.8050409@cybernothing.org> Message-ID: <4A7C3872.2080601@dcrocker.net> J.D. Falk wrote: > Murray S. Kucherawy wrote: > >> In fact, there is an experimental DKIM reputation service out there now that does something of this nature. The implementation I wrote has optional support for it. I don't yet have any information about who's using it or what the results of such are. > > And, there are others in progress. Folks, Within the obvious limits of protecting proprietary concerns, it would be quite helpful to be able to have the dkim.org site list existing and planned DKIM-based reputation services. Such services move DKIM from promising to useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fenton at cisco.com Fri Aug 14 10:01:46 2009 From: fenton at cisco.com (Jim Fenton) Date: Fri, 14 Aug 2009 10:01:46 -0700 Subject: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)] Message-ID: <4A85987A.8010006@cisco.com> I haven't seen this announcement here, probably because rfc-editor at rfc-editor.org doesn't subscribe to this list. -------- Original Message -------- Subject: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) Date: Wed, 12 Aug 2009 16:53:22 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: ietf-dkim at mipassoc.org, rfc-editor at rfc-editor.org Newsgroups: gmane.ietf.announce,gmane.ietf.dkim A new Request for Comments is now available in online RFC libraries. RFC 5617 Title: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) Author: E. Allman, J. Fenton, M. Delany, J. Levine Status: Standards Track Date: August 2009 Mailbox: eric+dkim at sendmail.org, fenton at cisco.com, markd+dkim at yahoo-inc.com, standards at taugh.com Pages: 21 Characters: 43093 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dkim-ssp-10.txt URL: http://www.rfc-editor.org/rfc/rfc5617.txt DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS TRACK] This document is a product of the Domain Keys Identified Mail Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From gmail.sant9442 at winserver.com Sat Aug 15 04:32:54 2009 From: gmail.sant9442 at winserver.com (hector) Date: Sat, 15 Aug 2009 07:32:54 -0400 Subject: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)] In-Reply-To: <4A85987A.8010006@cisco.com> References: <4A85987A.8010006@cisco.com> Message-ID: <4A869CE6.2000608@winserver.com> Congratulations on getting this published. Hopefully, it will taken serious by many domains to help provide a reasonable return on DKIM processing. In lieu of a standardized (and public) reputation system, network, ADSP can give some value. I have a few questions seeking clarification, confirmation mostly, because if I'm going to begin to implement DKIM with an ADSP focus for our customers, we will need to be able translate the information in the spec into easy to understand documented and online "Help" for customers. 1) With the policies: dkim=all vs dkim=discardable In layman terms, one is actionable (discardable) and one is not (all). One is an "Error" resulting in a reject, one is a "Warning" not resulting in a reject, in both cases, can be logged/recorded? Our GUI setup may show it like so for example: Author Domain: domain.example DKIM Signing Policy: (o) unknown - your mail may be signed (_) all - Your mail are always sign, however verifiers SHOULD NOT reject invalid signatures. (_) discardable - Your mail are always sign, and verifiers MUST reject invalid signatures. [ PUBLISH ] [CANCEL ] Is that the basic translation and fair way to put it? 2) DKIM=UNKNOWN Is there any actionable logic for optional signing? I mean, you may not always sign, but if you do, it must not be invalid? I just want to make sure in our help/doc to indicate whether publishing with unknown is the same as no ADSP record. One is explicit, the other is implicit. I may not always sign, but if I do, take it serious. Having no records could be viewed you don't care either way. I guess as it seems to be now, it would be a "Warning" but still acceptable (no rejection on this basis). But see the tail end of 3. 3) Finally 3rd party signatures. Please believe me I don't wish to rehash this. It was the one thing that I really felt will help domains. Not so much in defining the difficult task for valid use cases for the inclusion of 3rd signature policies, but rather the exclusion of 3rd parties. For example, appendix B.4 says: B.4. Third-Party Senders Another common use case is for a third party to enter into an agreement whereby that third party will send bulk or other mail on behalf of a designated Author or Author Domain, using that domain in the [RFC5322] From: or other headers. Due to the many and varied complexities of such agreements, third-party signing is not addressed in this specification. Ok, I accept this, we had hard time defining 3rd party situations. But this is not the same as the one hard logical conclusion a domain may have: He doesn't do 3rd party signatures nor expect it. So it seems me that the explicit declaration of a ADSP policy, the only options provided to prevent it are the explicit DKIM=ALL and DKIM=DISCARDABLE declarations. However, does the explicit DKIM=UNKNOWN declaration also imply exclusive Author Domain Signing? An explicit DKIM=UNKNOWN should suggest ADSP operations only, even if the signature is optional. Is that a correct or incorrect consideration? Thanks --- Jim Fenton wrote: > I haven't seen this announcement here, probably because > rfc-editor at rfc-editor.org doesn't subscribe to this list. > > -------- Original Message -------- > Subject: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain > Signing Practices (ADSP) > Date: Wed, 12 Aug 2009 16:53:22 -0700 (PDT) > From: rfc-editor at rfc-editor.org > To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org > CC: ietf-dkim at mipassoc.org, rfc-editor at rfc-editor.org > Newsgroups: gmane.ietf.announce,gmane.ietf.dkim > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5617 > > Title: DomainKeys Identified Mail (DKIM) Author > Domain Signing Practices (ADSP) > Author: E. Allman, J. Fenton, > M. Delany, J. Levine > Status: Standards Track > Date: August 2009 > Mailbox: eric+dkim at sendmail.org, > fenton at cisco.com, > markd+dkim at yahoo-inc.com, > standards at taugh.com > Pages: 21 > Characters: 43093 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-dkim-ssp-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc5617.txt > > DomainKeys Identified Mail (DKIM) defines a domain-level > authentication framework for email to permit verification of the > source and contents of messages. This document specifies an adjunct > mechanism to aid in assessing messages that do not contain a DKIM > signature for the domain used in the author's address. It defines a > record that can advertise whether a domain signs its outgoing mail as > well as how other hosts can access that record. [STANDARDS TRACK] > > This document is a product of the Domain Keys Identified Mail Working > Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From dkim at spam3.gm.transpac.fr Mon Aug 17 06:38:33 2009 From: dkim at spam3.gm.transpac.fr (kim d) Date: Mon, 17 Aug 2009 15:38:33 +0200 Subject: [ietf-dkim] DKIM V 2.4.O - SSP and timeout Message-ID: Hi (Hope i am at the right place - it is the first time i use this list) I have Postfix/DKIM version V 2.4.0 installed. My server configuration is: On-DNSError tempfail DNSTimeout 10 SSP policy: _ssp._domainkey.spam3.gm.transpac.fr. 900 IN TXT "dkim=all \; handling=deny \; t=s") Test = sending a non internal unsigned message with a faked from header => result expected = message rejected as per SSP policy in place When my DNS server is responding within DNSTimeout then I have 2 log lines including the SSP reject log line unknown-jobid) external host be-1-data attempted to send as spam3.gm.transpac.fr rejected per sender domain policy => result is ok When my DNS server is NOT responding within DNSTimeout I have not the SSP log line (ok) but the message passes tru the system. (unknown-jobid) external host be-1-data attempted to send as spam3.gm.transpac.fr => I expected to have a tempfail Is it a bug or something I do not understand ? Nb: I would prefer not to migrate to a new version. Thank you for your help. Rgds Alain From msk at cloudmark.com Mon Aug 17 08:48:20 2009 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 17 Aug 2009 08:48:20 -0700 Subject: [ietf-dkim] DKIM V 2.4.O - SSP and timeout In-Reply-To: References: Message-ID: > -----Original Message----- > From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim- > bounces at mipassoc.org] On Behalf Of kim d > Sent: Monday, August 17, 2009 6:39 AM > To: ietf-dkim at mipassoc.org > Cc: dkim at spam3.gm.transpac.fr > Subject: [ietf-dkim] DKIM V 2.4.O - SSP and timeout > > Hi > > (Hope i am at the right place - it is the first time i use this list) Nope, wrong place. This list is for discussing DKIM-related work of the Internet Engineering Task Force, which is about setting standards and not producing software. You should repost your question to the mailing list that supports the DKIM software you're trying to use. From chittushanmugam at gmail.com Mon Aug 17 22:00:29 2009 From: chittushanmugam at gmail.com (deiva shanmugam) Date: Tue, 18 Aug 2009 10:30:29 +0530 Subject: [ietf-dkim] DKIM - Is policy record required? Message-ID: Hi, Could someone let me know, is querying the policy record essential for DKIM at verification side as DKIM is derived from Domainkeys? In RFC 4871, usage of policy record was not clearly mentioned. But in section 6.3, the RFC says "when communicating with a peer who, by prior agreement, agrees to only *send signed messages*" and in section 8.4, RFC says "A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data as well as *fetching signing domain policy*." So, i'm not sure whether the policy record in DNS TXT record in _domainkey. need to be queried for DKIM? Thanks, Deiva Shanmugam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090818/65b70328/attachment.html From doug.mtview at gmail.com Mon Aug 17 23:44:21 2009 From: doug.mtview at gmail.com (Doug Otis) Date: Mon, 17 Aug 2009 23:44:21 -0700 Subject: [ietf-dkim] DKIM - Is policy record required? In-Reply-To: References: Message-ID: <4A8A4DC5.20209@gmail.com> On 8/17/09 10:00 PM, deiva shanmugam wrote: > Hi, > > Could someone let me know, is querying the policy record essential for > DKIM at verification side as DKIM is derived from Domainkeys? > > In RFC 4871, usage of policy record was not clearly mentioned. But in > section 6.3, the RFC says "when communicating with a peer who, by prior > agreement, agrees to only /send signed messages/" and in section 8.4, > RFC says "A second security issue related to the DNS revolves around the > increased DNS traffic as a consequence of fetching selector-based data > as well as /fetching signing domain policy/." So, i'm not sure whether > the policy record in DNS TXT record in _domainkey. need to > be queried for DKIM? Some might view policy records as a means to offer advice in creating phished lists. These lists identify domains suffering from being spoofed, where such policy records grant permission to reject non-compliant messages. Some receivers might discard non-compliant messages, which of course could place messages forwarded through a mailing list at risk. These records are unlikely queried on a per message basis at some negative caching rate, as this would be needed for every email domain, and not just for those with a DKIM signature. Instead, a periodic sampling of DKIM domains or a third-party service could consolidate into a list the domains in need of stringent handling from those that have been seen using DKIM. -Doug From chittushanmugam at gmail.com Tue Aug 18 00:32:53 2009 From: chittushanmugam at gmail.com (deiva shanmugam) Date: Tue, 18 Aug 2009 13:02:53 +0530 Subject: [ietf-dkim] DKIM - Is policy record required? In-Reply-To: <4A8A4DC5.20209@gmail.com> References: <4A8A4DC5.20209@gmail.com> Message-ID: Hi, Thanks Doug for the clarification. So, eventhough the DKIM RFC explicitly doesn't mention the use of policy record in the verification side, still we should query for the policy record. Thanks, Deiva Shanmugam On Tue, Aug 18, 2009 at 12:14 PM, Doug Otis wrote: > On 8/17/09 10:00 PM, deiva shanmugam wrote: > >> Hi, >> >> Could someone let me know, is querying the policy record essential for >> DKIM at verification side as DKIM is derived from Domainkeys? >> >> In RFC 4871, usage of policy record was not clearly mentioned. But in >> section 6.3, the RFC says "when communicating with a peer who, by prior >> agreement, agrees to only /send signed messages/" and in section 8.4, >> RFC says "A second security issue related to the DNS revolves around the >> increased DNS traffic as a consequence of fetching selector-based data >> as well as /fetching signing domain policy/." So, i'm not sure whether >> the policy record in DNS TXT record in _domainkey. need to >> be queried for DKIM? >> > > Some might view policy records as a means to offer advice in creating > phished lists. These lists identify domains suffering from being spoofed, > where such policy records grant permission to reject non-compliant messages. > Some receivers might discard non-compliant messages, which of course could > place messages forwarded through a mailing list at risk. > > These records are unlikely queried on a per message basis at some negative > caching rate, as this would be needed for every email domain, and not just > for those with a DKIM signature. Instead, a periodic sampling of DKIM > domains or a third-party service could consolidate into a list the domains > in need of stringent handling from those that have been seen using DKIM. > > -Doug > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090818/ae5e8dc5/attachment.html From gmail.sant9442 at winserver.com Tue Aug 18 04:19:13 2009 From: gmail.sant9442 at winserver.com (hector) Date: Tue, 18 Aug 2009 07:19:13 -0400 Subject: [ietf-dkim] DKIM - Is policy record required? In-Reply-To: References: <4A8A4DC5.20209@gmail.com> Message-ID: <4A8A8E31.2040402@winserver.com> deiva shanmugam wrote: > Hi, > > Thanks Doug for the clarification. > > So, eventhough the DKIM RFC explicitly doesn't mention the use of policy > record in the verification side, still we should query for the policy > record. > > Thanks, > Deiva Shanmugam I believe that is an implementation question who may be policy centric and wishes to supports DKIM related policy concepts to help protect domains, and today, with protection as defined in the recently IETF published RFC 5617 (ADSP) standard. I'm sure you will follow up on the new ADSP RFC, I wish to comment on a few highlights: The ADSP lookup key: _adsp._domainkey.domain.example where domain.example is the domain in the 5322.From: field. ADSP has three policies: dkim=unknown ---> equivalent to Domainkey policy o=~ dkim=all ---> equivalent to Domainkey policys o=- dkim=discardable discardable is the same as all but with an explicit author domain authorization for receivers to discard/reject an invalid author domain signature, including no signatures found. No 5321 Bounce Requirement is required for failure to deliver after accepting a message - the message is "discarded!" Regarding DNS lookup overhead, as you noted in section 8.4, I believe many of the DNS people here do believe and stated that there is little concern with policy lookups as most systems already do many DNS queries for many mail related, anti-spam reasons for anonymous incoming domains. Today DNS clients and Server caching resolves many of theses issues however it was recognized initial adoptions phases could yield a higher degree of policy lookup failure. I personally like to use SPF as an example, I don't think the system broke down when SPF was first introduced and was growing, and I believe SPF does have a higher processing overhead than a primitive DKIM policy record lookup where there is no recursion overhead unless SPF. Nonetheless, RFC 5016 (Policy Requirements), attempts to assist here by providing a requirement for policy lookup in section 5.3 item 9: 9. SSP MUST NOT be required to be invoked if a valid first party signature is found. It probably helps a little in reducing 1st party signature policy lookups. But IMV, it won't play a significant role in a world where there is a high degree of fraudulent legacy messages with no signatures, and as the roll out expands, a world with increased failed 1st and 3rd party fraudulent valid signatures. In such a case, it could be that wasteful DKIM rehash processing (which does include 1 DNS lookup anyway) could out pace any concerns over DNS Policy lookups which in a good bit of the transactions there would be no need for a DKIM KEY lookup, just a DKIM policy lookup. Anyway, ultimately, of course, we need to see how ADSP is adopted. I am more optimistic than most here. IMV, ADSP will it limited offerings is still useful to many, especially the millions of small to large private domains who IMV want exclusivity in there transactions and would like a first level of defense at a wider range of receivers using discardable domain fraud protection. --- From johnl at iecc.com Tue Aug 18 13:23:12 2009 From: johnl at iecc.com (John Levine) Date: 18 Aug 2009 20:23:12 -0000 Subject: [ietf-dkim] DKIM - Is policy record required? In-Reply-To: Message-ID: <20090818202312.3349.qmail@simone.iecc.com> >Could someone let me know, is querying the policy record essential for DKIM >at verification side as DKIM is derived from Domainkeys? No. ADSP is entirely optional, and I don't expect most DKIM implementations either to publish or to query it. R's, John From fenton at cisco.com Tue Aug 18 14:36:04 2009 From: fenton at cisco.com (Jim Fenton) Date: Tue, 18 Aug 2009 14:36:04 -0700 Subject: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)] In-Reply-To: <4A869CE6.2000608@winserver.com> References: <4A85987A.8010006@cisco.com> <4A869CE6.2000608@winserver.com> Message-ID: <4A8B1EC4.3040807@cisco.com> Hector, Here are my interpretations. Everyone, please bear in mind that these are just that and others are free to disagree. I'm not interested in getting into a debate about this. It's not clear to me that this is really a standardization discussion at this point, so perhaps we should take discussions of this sort to another list such as dkim-ops at mipassoc.org. Comments inline... hector wrote: > Congratulations on getting this published. Hopefully, it will taken > serious by many domains to help provide a reasonable return on DKIM > processing. In lieu of a standardized (and public) reputation system, > network, ADSP can give some value. > > I have a few questions seeking clarification, confirmation mostly, > because if I'm going to begin to implement DKIM with an ADSP focus for > our customers, we will need to be able translate the information in > the spec into easy to understand documented and online "Help" for > customers. > > 1) With the policies: > > dkim=all vs dkim=discardable > > In layman terms, one is actionable (discardable) and one is not (all). > One is an "Error" resulting in a reject, one is a "Warning" not > resulting in a reject, in both cases, can be logged/recorded? Our GUI > setup may show it like so for example: > > Author Domain: domain.example > > DKIM Signing Policy: > > (o) unknown - your mail may be signed > > (_) all - Your mail are always sign, however > verifiers SHOULD NOT reject invalid signatures. > > (_) discardable - Your mail are always sign, and > verifiers MUST reject invalid signatures. > > [ PUBLISH ] [CANCEL ] > > Is that the basic translation and fair way to put it? I disagree that "all" is not actionable. There are several things the verifier/assessor can do. (1) Apply more stringent content checking (perhaps changing the threshold values or something). (2) If the GUI is under the control of the assessor (such as a webmail client), display a visual warning. If not, do something like add [dkim unverified] to the subject line. Some of you may have seen that if I responded hastily to a message without cleaning that up, because I have been trying that out for quite some time now. > > 2) DKIM=UNKNOWN > > Is there any actionable logic for optional signing? > > I mean, you may not always sign, but if you do, it must not be invalid? > > I just want to make sure in our help/doc to indicate whether > publishing with unknown is the same as no ADSP record. One is > explicit, the other is implicit. I may not always sign, but if I do, > take it serious. Having no records could be viewed you don't care > either way. > > I guess as it seems to be now, it would be a "Warning" but still > acceptable (no rejection on this basis). But see the tail end of 3. I would advise against treating a signature that is invalid any differently from a signature that isn't present. There are intermediate agents that might break the signature, and we don't want to give the impression that applying a signature might increase the risk of non-delivery. Furthermore, dkim=unknown has the same meaning as the lack of an ADSP record. > > 3) Finally 3rd party signatures. > > Please believe me I don't wish to rehash this. It was the one thing > that I really felt will help domains. Not so much in defining the > difficult task for valid use cases for the inclusion of 3rd signature > policies, but rather the exclusion of 3rd parties. For example, > appendix B.4 says: > > B.4. Third-Party Senders > > Another common use case is for a third party to enter into an > agreement whereby that third party will send bulk or other mail on > behalf of a designated Author or Author Domain, using that domain > in the [RFC5322] From: or other headers. Due to the many and > varied complexities of such agreements, third-party signing is not > addressed in this specification. > > Ok, I accept this, we had hard time defining 3rd party situations. But > this is not the same as the one hard logical conclusion a domain > may have: He doesn't do 3rd party signatures nor expect it. > > So it seems me that the explicit declaration of a ADSP policy, the > only options provided to prevent it are the explicit DKIM=ALL and > DKIM=DISCARDABLE declarations. > > However, does the explicit DKIM=UNKNOWN declaration also imply > exclusive Author Domain Signing? An explicit DKIM=UNKNOWN should > suggest ADSP operations only, even if the signature is optional. > > Is that a correct or incorrect consideration? dkim=unknown doesn't imply that there is any Author Domain Signing going on, and it is always (regardless of the ADSP value) OK for an intermediary to apply a DKIM signature if it's willing to take responsibility. So ADSP is completely silent on the presence or absence of third-party signatures. Again, dkim=unknown has exactly the same semantics as the lack of an ADSP record. A published ADSP record will normally have a longer time-to-live than the negative caching of the lack of one, so publishing a record will cut down on DNS traffic. My answer is that this is an incorrect consideration. Hope this helps. -Jim From gmail.sant9442 at winserver.com Tue Aug 18 22:59:05 2009 From: gmail.sant9442 at winserver.com (hector) Date: Wed, 19 Aug 2009 01:59:05 -0400 Subject: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)] In-Reply-To: <4A8B1EC4.3040807@cisco.com> References: <4A85987A.8010006@cisco.com> <4A869CE6.2000608@winserver.com> <4A8B1EC4.3040807@cisco.com> Message-ID: <4A8B94A9.2030903@winserver.com> Jim Fenton wrote: > Hector, > > Here are my interpretations. Everyone, please bear in mind that these > are just that and others are free to disagree. I'm not interested in > getting into a debate about this. > > It's not clear to me that this is really a standardization discussion at > this point, so perhaps we should take discussions of this sort to > another list such as dkim-ops at mipassoc.org. Perhaps. Not interesting in extending this beyond other than a thought. If others want to initiate an ERRATA, I am not asking for it. I think it is unclear of the purpose of having DKIM=UNKNOWN if its not for optional but exclusive Author Domain (AD) signing. I hear what you said. But ADSP is about exclusive AD signing. No? OPTIONAL ALWAYS ALWAYS+DISCARD IF INVALID is pretty much how I read it and how I was thinking of it having it documented for people. Not having a ADSP should be the only thing that says you are not an ADSP participant. The people JL says will never publish it. But having one, even as an UNKNOWN should suggest something other than non-ADSP participation. JMO --- > > Comments inline... > > hector wrote: >> Congratulations on getting this published. Hopefully, it will taken >> serious by many domains to help provide a reasonable return on DKIM >> processing. In lieu of a standardized (and public) reputation system, >> network, ADSP can give some value. >> >> I have a few questions seeking clarification, confirmation mostly, >> because if I'm going to begin to implement DKIM with an ADSP focus for >> our customers, we will need to be able translate the information in >> the spec into easy to understand documented and online "Help" for >> customers. >> >> 1) With the policies: >> >> dkim=all vs dkim=discardable >> >> In layman terms, one is actionable (discardable) and one is not (all). >> One is an "Error" resulting in a reject, one is a "Warning" not >> resulting in a reject, in both cases, can be logged/recorded? Our GUI >> setup may show it like so for example: >> >> Author Domain: domain.example >> >> DKIM Signing Policy: >> >> (o) unknown - your mail may be signed >> >> (_) all - Your mail are always sign, however >> verifiers SHOULD NOT reject invalid signatures. >> >> (_) discardable - Your mail are always sign, and >> verifiers MUST reject invalid signatures. >> >> [ PUBLISH ] [CANCEL ] >> >> Is that the basic translation and fair way to put it? > > I disagree that "all" is not actionable. There are several things the > verifier/assessor can do. (1) Apply more stringent content checking > (perhaps changing the threshold values or something). (2) If the GUI is > under the control of the assessor (such as a webmail client), display a > visual warning. If not, do something like add [dkim unverified] to the > subject line. Some of you may have seen that if I responded hastily to > a message without cleaning that up, because I have been trying that out > for quite some time now. > >> 2) DKIM=UNKNOWN >> >> Is there any actionable logic for optional signing? >> >> I mean, you may not always sign, but if you do, it must not be invalid? >> >> I just want to make sure in our help/doc to indicate whether >> publishing with unknown is the same as no ADSP record. One is >> explicit, the other is implicit. I may not always sign, but if I do, >> take it serious. Having no records could be viewed you don't care >> either way. >> >> I guess as it seems to be now, it would be a "Warning" but still >> acceptable (no rejection on this basis). But see the tail end of 3. > > I would advise against treating a signature that is invalid any > differently from a signature that isn't present. There are intermediate > agents that might break the signature, and we don't want to give the > impression that applying a signature might increase the risk of > non-delivery. Furthermore, dkim=unknown has the same meaning as the > lack of an ADSP record. > >> 3) Finally 3rd party signatures. >> >> Please believe me I don't wish to rehash this. It was the one thing >> that I really felt will help domains. Not so much in defining the >> difficult task for valid use cases for the inclusion of 3rd signature >> policies, but rather the exclusion of 3rd parties. For example, >> appendix B.4 says: >> >> B.4. Third-Party Senders >> >> Another common use case is for a third party to enter into an >> agreement whereby that third party will send bulk or other mail on >> behalf of a designated Author or Author Domain, using that domain >> in the [RFC5322] From: or other headers. Due to the many and >> varied complexities of such agreements, third-party signing is not >> addressed in this specification. >> >> Ok, I accept this, we had hard time defining 3rd party situations. But >> this is not the same as the one hard logical conclusion a domain >> may have: He doesn't do 3rd party signatures nor expect it. >> >> So it seems me that the explicit declaration of a ADSP policy, the >> only options provided to prevent it are the explicit DKIM=ALL and >> DKIM=DISCARDABLE declarations. >> >> However, does the explicit DKIM=UNKNOWN declaration also imply >> exclusive Author Domain Signing? An explicit DKIM=UNKNOWN should >> suggest ADSP operations only, even if the signature is optional. >> >> Is that a correct or incorrect consideration? > > dkim=unknown doesn't imply that there is any Author Domain Signing going > on, and it is always (regardless of the ADSP value) OK for an > intermediary to apply a DKIM signature if it's willing to take > responsibility. So ADSP is completely silent on the presence or absence > of third-party signatures. > > Again, dkim=unknown has exactly the same semantics as the lack of an > ADSP record. A published ADSP record will normally have a longer > time-to-live than the negative caching of the lack of one, so publishing > a record will cut down on DNS traffic. > > My answer is that this is an incorrect consideration. > > Hope this helps. > > -Jim > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html From Internet-Drafts at ietf.org Tue Aug 25 13:00:02 2009 From: Internet-Drafts at ietf.org (Internet-Drafts at ietf.org) Date: Tue, 25 Aug 2009 13:00:02 -0700 (PDT) Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt Message-ID: <20090825200002.1529D3A6A25@core3.amsl.com> From tony at att.com Tue Aug 25 13:08:03 2009 From: tony at att.com (Tony Hansen) Date: Tue, 25 Aug 2009 16:08:03 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: <20090825200002.1529D3A6A25@core3.amsl.com> References: <20090825200002.1529D3A6A25@core3.amsl.com> Message-ID: <4A9444A3.4060204@att.com> This version resolves all issues brought up during WGLC that needed to be fixed. Tony Hansen tony at att.com Internet-Drafts at ietf.org wrote: > 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 : DomainKeys Identified Mail (DKIM) Development, Deployment and Operations > Author(s) : T. Hansen, et al. > Filename : draft-ietf-dkim-deployment-08.txt > Pages : 50 > Date : 2009-08-25 From barryleiba.mailing.lists at gmail.com Wed Aug 26 18:55:18 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Wed, 26 Aug 2009 21:55:18 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: <4A9444A3.4060204@att.com> References: <20090825200002.1529D3A6A25@core3.amsl.com> <4A9444A3.4060204@att.com> Message-ID: <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> > This version resolves all issues brought up during WGLC that needed to > be fixed. We won't be doing another formal WGLC on this, but it will take me a few days to do the PROTO writeup and submit it to Pasi. Everyone, please use that time to review this version and speak up if there's anything we should reconsider before it goes to the IESG. Barry (as chair) From tony at att.com Wed Aug 26 19:27:30 2009 From: tony at att.com (Tony Hansen) Date: Wed, 26 Aug 2009 22:27:30 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> References: <20090825200002.1529D3A6A25@core3.amsl.com> <4A9444A3.4060204@att.com> <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> Message-ID: <4A95EF12.6060009@att.com> There's one reference that will need to be updated, now that RFC 5672 is out. Tony Barry Leiba wrote: >> This version resolves all issues brought up during WGLC that needed to >> be fixed. > > We won't be doing another formal WGLC on this, but it will take me a > few days to do the PROTO writeup and submit it to Pasi. Everyone, > please use that time to review this version and speak up if there's > anything we should reconsider before it goes to the IESG. From sager at agitos.de Thu Aug 27 09:04:08 2009 From: sager at agitos.de (Florian Sager) Date: Thu, 27 Aug 2009 18:04:08 +0200 Subject: [ietf-dkim] DKIM adoption In-Reply-To: <4A7C3872.2080601@dcrocker.net> References: <8169209.10251249078956375.JavaMail.franck@franck-martins-macbook-pro.local> <4A7A8310.60502@winserver.com> <4A7AF604.3060806@mail-abuse.org> <4A7B3837.8050409@cybernothing.org> <4A7C3872.2080601@dcrocker.net> Message-ID: <4A96AE78.7000109@agitos.de> Dave CROCKER schrieb: > J.D. Falk wrote: > >> Murray S. Kucherawy wrote: >>> n fact, there is an experimental DKIM reputation service out there now that does something of this nature. The implementation I wrote has optional support for it. I don't yet have any information about who's using it or what the results of such are. >>> >> And, there are others in progress. >> > > Within the obvious limits of protecting proprietary concerns, it would be quite > helpful to be able to have the dkim.org site list existing and planned > DKIM-based reputation services. Such services move DKIM from promising to useful. > Hi, let me summarize some insights we collected running www.dkim-reputation.org since March 08: 1) I was in contact with Murray in Dec 08 the last time discussing uniform requests/responses to reputation systems. Today I think it would be helpful to publish - at least - something like a recommendation on (a) suitable publishing systems (DNS is appropriate in my view) (b) request parameters and (c) response formats. (a) IN: identifier, DKIM-based (b) OUT: scalar, good/bad in a recommended, min/max limited range with (simple) textual explanations of sub-ranges (not too detailed, cannot be differentiated by implementors anyway). Within dkim-reputation.org I am using for (a) as DNS RR subdomain: (i) if i= is available including local-part: base64(md5(local-part_i)).base64(md5(domain-part_i)).base64(md5(signdom_d)) (ii) if i= is not available including local-part as a fallback (spoofable inside a trusted signing domain): base64(md5(local-part_from)).base64(md5(domain-part_from)).base64(md5(signdom_d)) This format is quite useful: - if used in combination with DNS, wildcards can be used in the zone to combine either domain parts and/or users below the reputation of the signing domain - copied parts of the list (DNS caches, DNS mirrors or plain ASCII feeds) can't reveal existing addresses (confirmations of addresses remain possible) - if long usernames or domains are used this doesn't bother the system (btw: a very long domain name our crawlers at dkim-reputation.org found was "registeringdomainnamesismorefunthandoingrealwork.com" ;) ) Within dkim-reputation.org I am using for (b) the value of a TXT record that contains (i) a timestamp of the last record update (e.g. the last spam hit) (ii) the reputation value at the time this hit was generated (within a range of -1000 to 1000) (iii) a proposed value how much to increase/decrease this value per day to forgive bad reputation after some time (iii) is very special and could be implemented on client side individually: shouldn't be part of a recommendation. (i) is quite useful to prevent regular updates of a DNS record on the provider side. (ii) is mandatory. I'd appreciate if someone could follow this topic, I'm unfortunately too busy to push this at time. 2) our statistics on http://www.dkim-reputation.org/statistics/ are quite interesting: while those that send valid DomainKeys/DKIM signed spam to us told us their entire spam traffic increased, we see that the number of spammers using DKIM (directly with own signing domains or indirectly by using ISP accounts) drops. The individual user accounts we detected belong mostly to Gmail and Yahoo!. Here you can see the most significant decrease; both E-Mail Services successfully react on ARF reports today and block the according accounts. It's also interesting to see that the number of bad domains decreases. On the other hand I see that the number of entire signing domains increases (Cisco was talking about a triplication since last year, I measured factor 2.5). This is interesting but might remain without any consequences concerning filtering: DKIM reputation - in my view - makes 100% sense concerning the reduction of false positives. Since false positives aren't a great problem at time I don't push dkim-reputation.org too much, waiting for a time it becomes more necessary. Concerning bad reputation there is some usage, but I saw: the hits that our DKIM-reputation spamassassin plugin generated were just confirmations of spam mails already rated bad. So no big advantage here, just one means in a combined approach. The idea to rate non-signed emails worse should be banned in my view: thinking about DKIM failure scenarios as well you always should rate unsigned emails as well as non-validly signed emails neutrally. 3) To get back to "DKIM adoption": since DKIM reputation obviously doesn't boost there must be other drivers in my view, special example: the German government is looking for a way to get court-proof emails. They defined a concept that's very likely too complicated to become true, instead small steps would be more helful; to provide long-term-proof I could imagine the following setup (signer has to be trusted, users can change the ISP without loosing the proof, just an idea): http://www.agitos.de/pub/20090703-ingoing-dkim-for-stability-proof.pdf Two aspects in this context, my view: - as long as spoofing mails isn't a very promising attack like it is today signatures will remain rather unimportant - if we'd have signatures (of higher quality than DKIM) and therefore would use email to e.g. place contracts, attacks on email would be more promising and signatures would become important 5) a wish: in some scenarios it would be helpful if MUAs could work with DKIM check results. If the client could somehow decide if an Authentication-Results header was added by the trusted mailserver the client could use the server-side generated results. If the server-id inside the Authentication-Results header could be checked against a confirming DNS record being in the same zone as the MX entry the client-side validation could be skipped. @Murray: is there some news about this? Best regards, Florian === Agitos Technologies und Agitos Webhosting Florian Sager Emil-Geis-Stra?e 40, 81379 M?nchen Telefon: 089/45867554 Telefax: 089/45867555 Support: support at agitos.de http://www.agitos.de From thomas at gelf.net Sat Aug 29 05:29:06 2009 From: thomas at gelf.net (Thomas Gelf) Date: Sat, 29 Aug 2009 14:29:06 +0200 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> References: <20090825200002.1529D3A6A25@core3.amsl.com> <4A9444A3.4060204@att.com> <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> Message-ID: Barry Leiba wrote: > We won't be doing another formal WGLC on this, but it will take me a > few days to do the PROTO writeup and submit it to Pasi. Everyone, > please use that time to review this version and speak up if there's > anything we should reconsider before it goes to the IESG. 5.4 Inbound Mail Filtering, last line: acomplished -> accomplished Best regards, Thomas Gelf From johnl at iecc.com Sat Aug 29 08:51:36 2009 From: johnl at iecc.com (John Levine) Date: 29 Aug 2009 15:51:36 -0000 Subject: [ietf-dkim] reputation formats, was DKIM adoption In-Reply-To: <4A96AE78.7000109@agitos.de> Message-ID: <20090829155136.77997.qmail@simone.iecc.com> > Today I think it would be helpful to publish - at least - something >like a recommendation on (a) suitable publishing systems (DNS is >appropriate in my view) (b) request parameters and (c) response >formats. Back when we were developing VBR, we spent a fair amount of time considering reputation query formats as a followon to VBR. We came up with some rough ideas, but the general feeling was that we don't understand reputation well enough to try to nail anything down, and that seems as true now as it ever was. With respect to your specific proposal, I have two comments. One is that although the scheme for encoding i= strings is clever, since we just went through a lengthy process to establish the d= domain as the primary identifier, so I would just use that. Using a plain domain also makes it easier to use a system on top of other authentication systems like SPF and Sender-ID. (Although I am a fan of neither, there are certainly some cases where they can give you a solid enough positive result to use.) The other is that "reputation" is hardly a single dimension. In our work, we had a DNS query that returned a reputation number on a 0-100 scale, but we also had a confidence value to give a hint about how certain we were that our opinion was right, and a code to indicate what sort of organization it was. (The code was a SIC number, a common business type code used in North America.) The idea was that if you got mail from someone, and the lookup said it was a bank, a poor reputation might indicate that it was likely to be spam, but since it's from a real bank, it's unlikely to be a phish so you might want to deliver it anyway. It occurs to me that you might need a variety of reputation scales for spamminess, phishiness, sleaziness, and so forth, since different receivers are likely to have different opinions of, e.g., unsolicited mail advertising an actual vendor of fancy coffee. This strikes me as a fine topic for the ASRG since it is, you know, research. It would be quite reasonble to publish one or more experimental RFCs via the ASRG with proposed reputation exchange formats to document what we've been thinking about and give the rest of the world a place to start. R's, John From tony at att.com Sat Aug 29 14:39:10 2009 From: tony at att.com (Tony Hansen) Date: Sat, 29 Aug 2009 17:39:10 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: References: <20090825200002.1529D3A6A25@core3.amsl.com> <4A9444A3.4060204@att.com> <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> Message-ID: <4A999FFE.1060604@att.com> thanks! Thomas Gelf wrote: > Barry Leiba wrote: >> We won't be doing another formal WGLC on this, but it will take me a >> few days to do the PROTO writeup and submit it to Pasi. Everyone, >> please use that time to review this version and speak up if there's >> anything we should reconsider before it goes to the IESG. > > 5.4 Inbound Mail Filtering, last line: acomplished -> accomplished From stephen.farrell at cs.tcd.ie Fri Sep 11 03:32:25 2009 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Fri, 11 Sep 2009 11:32:25 +0100 Subject: [ietf-dkim] [Fwd: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available] Message-ID: <4AAA2739.607@cs.tcd.ie> FYI. Stephen. -------------- next part -------------- An embedded message was scrubbed... From: "Mary Barnes" Subject: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Date: Wed, 9 Sep 2009 09:46:38 -0500 Size: 9322 Url: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090911/0b7f9992/attachment.eml From barryleiba.mailing.lists at gmail.com Sun Sep 13 07:04:27 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Sun, 13 Sep 2009 10:04:27 -0400 Subject: [ietf-dkim] No DKIM meeting at IETF 76 Message-ID: <6c9fcc2a0909130704yb91fe84t3bb5f67417877218@mail.gmail.com> I'm just noting, for the record, that the DKIM working group will not be meeting at IETF 76 in Hiroshima. I'll also note that I still owe a draft charter update to the group, and I will get that done this week. Barry, as chair From barryleiba.mailing.lists at gmail.com Wed Sep 30 09:00:55 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Wed, 30 Sep 2009 12:00:55 -0400 Subject: [ietf-dkim] DKIM charter update proposal Message-ID: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> Pasted below is my proposal for an updated DKIM WG charter. Stephen has reviewed it and agrees, and now it's the working group's turn. I've kept two of the paragraphs from the original introduction, changing only the tenses, from things like "will produce" to "has produced". I've turned the original deliverables list into a summary of what's been delivered. I've put in new deliverables that basically amount to "advance the two protocols through the standards process, as appropriate." And I've left the "this stuff is out of scope" section, because it's my sense that we still want to stay away from those items, at least for now. Please comment on it. If you like it, please say so. If you want changes, please specify, and suggest specific text. If you don't care, and just want to get out of here, that's useful input as well. Let's define a two-week comment period, which we'll extend if needed... so, comment as soon as possible, and no later than Friday, 16 October. Barry, as chair ---------------------------------- Domain Keys Identified Mail (dkim) ---------------------------------- Chairs: Stephen Farrell Barry Leiba Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: ietf-dkim at mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ Description of Working Group: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group has produced standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications do not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The previously chartered deliverables for the DKIM working group have been completed: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. (RFC 4686) * A standards-track specification for DKIM signature and verification. (RFC 4871, updated by RFC 5672) * A standards-track specification for DKIM policy handling. (RFC 5617) * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. (RFC 5585 and draft-ietf-dkim-deployment, in its final stages) (One previously chartered deliverable, a standards-track specification for DKIM DNS Resource Record(s), was dropped by agreement between the working group and the Area Directors.) The working group is now ready to switch its focus to refining and advancing the DKIM protocols. The current deliverables for the DKIM working group are these: * Advance the base DKIM protocol (RFC 4871) to Draft Standard. * Collect data on the deployment and interoperability of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard or advance it to Draft Standard, as appropriate. As before, several related topics remain out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. ---------------------------------- From barryleiba.mailing.lists at gmail.com Wed Sep 30 09:04:12 2009 From: barryleiba.mailing.lists at gmail.com (Barry Leiba) Date: Wed, 30 Sep 2009 12:04:12 -0400 Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-deployment-08.txt In-Reply-To: <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> References: <20090825200002.1529D3A6A25@core3.amsl.com> <4A9444A3.4060204@att.com> <6c9fcc2a0908261855h587b9fabg61748c09bb5db5a@mail.gmail.com> Message-ID: <6c9fcc2a0909300904x7ef02bf1j13531d409d7f032e@mail.gmail.com> > We won't be doing another formal WGLC on this, but it will take me a > few days to do the PROTO writeup and submit it to Pasi. An update: I'm sorry that I've let this slip. Rather than "a few days", it's been a month. I have the writeup done, and I've asked Tony to look at some issues with references, boilerplate, and such, before we proceed. As soon as we get that sorted out, I'll send the writeup to Pasi and ask for IETF last call. Barry, as chair From jdfalk-lists at cybernothing.org Wed Sep 30 10:24:34 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Wed, 30 Sep 2009 11:24:34 -0600 Subject: [ietf-dkim] DKIM charter update proposal In-Reply-To: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> References: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> Message-ID: <4AC39452.9020704@cybernothing.org> Barry Leiba wrote: > Please comment on it. If you like it, please say so. I like it. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From ietf-dkim at kitterman.com Wed Sep 30 10:45:54 2009 From: ietf-dkim at kitterman.com (Scott Kitterman) Date: Wed, 30 Sep 2009 13:45:54 -0400 Subject: [ietf-dkim] DKIM charter update proposal In-Reply-To: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> References: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> Message-ID: <17839-SnapperMsgD8DB99B6C6E949D9@[70.198.91.0]> If advancing DKIM/ADSP along the standards heirarchy is all that's on the table, I think it should wait. Effective rollout of DKIM in large hetrgenous organizations is complex and takes time. I think it's better to pause for a while and give broad operational experience more of a chance to exercise what has just been standardized. Scott K From franck at genius.com Wed Sep 30 11:01:38 2009 From: franck at genius.com (Franck Martin) Date: Thu, 1 Oct 2009 06:01:38 +1200 (FJT) Subject: [ietf-dkim] DKIM charter update proposal In-Reply-To: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> Message-ID: <10502860.12831254333693079.JavaMail.franck@franck-martins-macbook-pro.local> Seems to me something is missing: gather data to establish if DKIM specifications have in any way alleviated any misuse of the email system, in particular but not limited to spam, phishing attacks and fraud. ----- Original Message ----- From: "Barry Leiba" To: "IETF DKIM WG" Sent: Thursday, 1 October, 2009 4:00:55 AM GMT +12:00 Fiji Subject: [ietf-dkim] DKIM charter update proposal Pasted below is my proposal for an updated DKIM WG charter. Stephen has reviewed it and agrees, and now it's the working group's turn. I've kept two of the paragraphs from the original introduction, changing only the tenses, from things like "will produce" to "has produced". I've turned the original deliverables list into a summary of what's been delivered. I've put in new deliverables that basically amount to "advance the two protocols through the standards process, as appropriate." And I've left the "this stuff is out of scope" section, because it's my sense that we still want to stay away from those items, at least for now. Please comment on it. If you like it, please say so. If you want changes, please specify, and suggest specific text. If you don't care, and just want to get out of here, that's useful input as well. Let's define a two-week comment period, which we'll extend if needed... so, comment as soon as possible, and no later than Friday, 16 October. Barry, as chair ---------------------------------- Domain Keys Identified Mail (dkim) ---------------------------------- Chairs: Stephen Farrell Barry Leiba Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: ietf-dkim at mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ Description of Working Group: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group has produced standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications do not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The previously chartered deliverables for the DKIM working group have been completed: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. (RFC 4686) * A standards-track specification for DKIM signature and verification. (RFC 4871, updated by RFC 5672) * A standards-track specification for DKIM policy handling. (RFC 5617) * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. (RFC 5585 and draft-ietf-dkim-deployment, in its final stages) (One previously chartered deliverable, a standards-track specification for DKIM DNS Resource Record(s), was dropped by agreement between the working group and the Area Directors.) The working group is now ready to switch its focus to refining and advancing the DKIM protocols. The current deliverables for the DKIM working group are these: * Advance the base DKIM protocol (RFC 4871) to Draft Standard. * Collect data on the deployment and interoperability of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard or advance it to Draft Standard, as appropriate. As before, several related topics remain out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. ---------------------------------- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From dhc at dcrocker.net Wed Sep 30 14:00:31 2009 From: dhc at dcrocker.net (Dave CROCKER) Date: Wed, 30 Sep 2009 14:00:31 -0700 Subject: [ietf-dkim] DKIM charter update proposal In-Reply-To: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> References: <6c9fcc2a0909300900v66aabean7cb8600a28818af3@mail.gmail.com> Message-ID: <4AC3C6EF.9040907@dcrocker.net> Barry Leiba wrote: > Description of Working Group: > > The Internet mail protocols and infrastructure allow mail sent > from one domain to purport to be from another. While there are > sometimes legitimate reasons for doing this, it has become a > source of general confusion, as well as a mechanism for fraud and > for distribution of spam (when done illegitimately, it's called > "spoofing"). The DKIM working group has produced standards-track > specifications that allow a domain to take responsibility, using > digital signatures, for having taken part in the transmission of > an email message and to publish "policy" information about how it > applies those signatures. Taken together, these will assist > receiving domains in detecting (or ruling out) certain forms of > spoofing as it pertains to the signing domain. I suggest replacing the last sentence with something more generic, to avoid the debate about how much any of this pertains to spoofing, per se. Perhaps instead have a value proposition statement derived from the one in the Overview abstract: These mechanisms permit email receivers to make additional assessments about messages. > While the techniques specified by the DKIM working group will not > prevent fraud or spam, they will provide a tool for defense > against them by assisting receiving domains in detecting some > spoofing of known domains. The standards-track specifications do > not mandate any particular action by the receiving domain when a > signature fails to validate. That said, with the understanding > that guidance is necessary for implementers, the DKIM documents > discuss a reasonable set of possible actions and strategies, and > analyze their likely effects on attacks and on normal email > delivery. Delete the first sentence, per my concern above. At the least, the sentence appears to be largely redundant with the preceding paragraph's last sentence. Isn't the second sentence incorrect? Doesn't DKIM mandate treated a failed validation the same as no signature present? > > The previously chartered deliverables for the DKIM working group > have been completed: > > * An informational RFC presenting a detailed threat analysis of, > and security requirements for, DKIM. (RFC 4686) > > * A standards-track specification for DKIM signature and > verification. (RFC 4871, updated by RFC 5672) > > * A standards-track specification for DKIM policy handling. > (RFC 5617) > > * An informational RFC providing an overview of DKIM and how it > can fit into overall messaging systems, how it relates to other > IETF message signature technologies, implementation and > migration considerations, and outlining potential DKIM > applications and future extensions. (RFC 5585 and > draft-ietf-dkim-deployment, in its final stages) > > (One previously chartered deliverable, a standards-track > specification for DKIM DNS Resource Record(s), was dropped by > agreement between the working group and the Area Directors.) Do re-charters usually contain all this history? > The working group is now ready to switch its focus to refining and > advancing the DKIM protocols. The current deliverables for the > DKIM working group are these: > > * Advance the base DKIM protocol (RFC 4871) to Draft Standard. > > * Collect data on the deployment and interoperability of the > Author Domain Signing Practices protocol (RFC 5617), and > determine if/when it's ready to advance on the standards track. > Update it at Proposed Standard or advance it to Draft Standard, > as appropriate. > > As before, several related topics remain out of scope for the DKIM > working group. These topics include: > > * Reputation and accreditation systems. While we expect these to > add value to what is defined by the DKIM working group, their > development will be separate, and is out of scope for the DKIM > working group. > > * Message content encryption. > > * Additional key management protocols or infrastructure. > > * Signatures that are intended to make long-term assertions beyond > the expected transit time of a message from originator to > recipient, which is normally only a matter of a few days at > most. > > * Signatures that attempt to make strong assertions about the > identity of the message author, and details of user-level > signing of messages (as distinguished from domain-level keys > that are restricted to specific users). > > * Duplication of prior work in signed email, including S/MIME and > OpenPGP. -- Dave Crocker Brandenburg InternetWorking bbiw.net