[ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : RFC4871 Implementation Report Author(s) : M. Kucherawy Filename: draft-ietf-dkim-implementation-report-06.txt Pages : 17 Date: 2011-03-28 This document contains an implementation report for the IESG covering DomainKeys Identified Mail (DKIM) in support of the advancement of that specification along the Standards Track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-06.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-05.txt Pages : 29 Date: 2011-03-28 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. As the industry has now gained some deployment experience, the goal for this document is to explore the use of DKIM for scenarios that include intermediaries, such as Mailing List Managers (MLMs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-05.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-05.txt
-Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Monday, March 28, 2011 12:15 AM To: i-d-annou...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: I-D Action:draft-ietf-dkim-mailinglists-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-05.txt Pages : 29 Date: 2011-03-28 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. As the industry has now gained some deployment experience, the goal for this document is to explore the use of DKIM for scenarios that include intermediaries, such as Mailing List Managers (MLMs). [...] Mostly editorial changes I found on the flight over to Prague, and also a refresh of the expiration date in the repository. No major changes, pending discussion in the WG meeting later today. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-06.txt
-Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Monday, March 28, 2011 12:15 AM To: i-d-annou...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: I-D Action:draft-ietf-dkim-implementation-report-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : RFC4871 Implementation Report Author(s) : M. Kucherawy Filename: draft-ietf-dkim-implementation-report-06.txt Pages : 17 Date: 2011-03-28 This document contains an implementation report for the IESG covering DomainKeys Identified Mail (DKIM) in support of the advancement of that specification along the Standards Track. [...] This is just an update of the OpenDKIM numbers to keep them reasonably current, and a bit more chatter about the changed header fields portion of the report. No other major changes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DomainKeys Identified Mail (DKIM) Signatures Author(s) : D. Crocker, et al. Filename: draft-ietf-dkim-rfc4871bis-04.txt Pages : 75 Date: 2011-03-28 DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-04.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM minutes from IETF 80
I have posted the attached minutes to the IETF meeting materials page: https://datatracker.ietf.org/meeting/80/materials.html Barry, as chair DKIM working group session, IETF 80 (Prague), Monday, 28 March 2011. Begin at 13:00. 1. Discussion of the implementation report document: Murray gave status of the document. There are no issues with this document. It will not be last-called, but will only be used to support the 4871bis advancement. As such, it will be recorded on the IESG page with other interoperability reports. 2. Discussion and resolution of 4871bis issues: We reviewed the changes since the last reviewed version. The editors believe they have all the open issues addressed. Remaining changes required after discussion: 1. Rewrite paragraph 3 in section 8.15, due to Dave's concern about strong advice that's out of scope for the document. 2. Murray will add a paragraph in an appendix advising removal of empty g=. 3. Murray will add IANA considerations to add a status column to the registries. Values will be active and historic, and g= will be made historic. The schedule is set for changes to be made by 10 April, WGLC after an updated version is posted. 3. Discussion of mailinglists document: Murray listed some questions he has... 1. Should we include an appendix discussing what we see as useful changes to MUAs? a: No; out of scope. Perhaps an MUA BCP done at another time. 2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. 3. Should we remove discussion about dealing with broken DKIM implementations? a: No. 4. Should we put advice in about what header fields re-signing MLMs should sign? a: No. 5. Should explicitly reference ESPs? They're different from MLMs. a: No. 6. Should we change advice about subdomains, creating streams? a: No. The schedule is set for changes to be made by 10 April, WGLC after an updated version is posted. 4. Discussion of the future of the working group Two charter items not yet done: 3. Collect data on the deployment, interoperability, and effectiveness 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, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. - Is there energy and desire to do this? - Should we recharter instead for different work? - Should we close the working group? Consensus in room and jabber is to close. Will confirm on the mailing list. Tony noted that there are changes to deployment/overview docs because of removal of g=, along with other minor changes. We can handle those before the WG closes, or Stephen (as AD) will sponsor that as an individual submission. Adjourn at 14:05. --- Documents: implementation: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report 4871bis: http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis mailinglists: http://tools.ietf.org/html/draft-ietf-dkim-mailinglists ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Work group future
As you'll see from the minutes (available at https://datatracker.ietf.org/meeting/80/materials.html ), consensus in the room and among remote participants at the IETF 80 DKIM session was to close the working group after the 4871bis and mailng-lists documents have been finished. From the minutes: -- 4. Discussion of the future of the working group Two charter items not yet done: 3. Collect data on the deployment, interoperability, and effectiveness 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, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. - Is there energy and desire to do this? - Should we recharter instead for different work? - Should we close the working group? Consensus in room and jabber is to close. Will confirm on the mailing list. Tony noted that there are changes to deployment/overview docs because of removal of g=, along with other minor changes. We can handle those before the WG closes, or Stephen (as AD) will sponsor that as an individual submission. -- We need to hear (or read) any objection or discussion here. The schedule currently is to have the documents ready for working group last call by 10 April, which means that we should be able to get them to the IESG by the end of April, if they are, indeed, ready. The sense at the meeting was that after five years, the working group has finished its productive work. Are there objections to this? Does anyone want to convince us that there's interest and energy to keep it open and do more work? Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DomainKeys Identified Mail (DKIM) Signatures Author(s) : D. Crocker, et al. Filename: draft-ietf-dkim-rfc4871bis-05.txt Pages : 76 Date: 2011-03-28 DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-05.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-06.txt Pages : 29 Date: 2011-03-28 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. As the industry has now gained some deployment experience, the goal for this document is to explore the use of DKIM for scenarios that include intermediaries, such as Mailing List Managers (MLMs) and describe the Best Current Practices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-06.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
Hi, On 3/28/11 3:34 PM, Barry Leiba wrote: As you'll see from the minutes (available at https://datatracker.ietf.org/meeting/80/materials.html ), consensus in the room and among remote participants at the IETF 80 DKIM session was to close the working group after the 4871bis and mailng-lists documents have been finished. From the minutes: -- 4. Discussion of the future of the working group Two charter items not yet done: 3. Collect data on the deployment, interoperability, and effectiveness 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, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. - Is there energy and desire to do this? - Should we recharter instead for different work? - Should we close the working group? Consensus in room and jabber is to close. Will confirm on the mailing list. I seem to remember that there was neither consensus for close, nor for continue. But I was a remote participant, so I may have it wrong. I wonder whether there should be a followup on the figures, presented by Murray in the implementation report. Excellent work (thanks Murray), but are we satisfied with the outcome? Is 93% successful verification OK? Is it good, is it good enough, is it bad? What if SMTP had been designed in such a way, that in 93% of all cases messages were delivered with contents unchanged, but in 7% of all cases message content was lost or malformed? Would it have been a success? What are these 7% DKIM signature verification failures, are these: * spammers? * MTA's violating the rules? * MTA's fixing stuff, that did not comply with the standards? * other? Furthermore, I'm not sure whether the DKIM WG has concluded on thinking about the value of DKIM, what it can be used for. Is it's purpose limited to providing input to a reputation engine? Is that it? Or is there more than that? Anyway, these things will not fit into the current charter... /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
Furthermore, I'm not sure whether the DKIM WG has concluded on thinking about the value of DKIM, what it can be used for. Is it's purpose limited to providing input to a reputation engine? Is that it? Or is there more than that? Those are all interesting questions, but I don't see what they have to do with standards development. If at some point in the future we figure out something where there would be a benefit if everyone did it the same way, we can charter a son-of-DKIM group to work on it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
Hi Rolf, I think the simple answer is that there wasn't anything close to consensus in the room or on the Jabber to recharter to cover the questions you posed. We didn't even have enough consensus to complete the one or two chartered items that haven't been finished. And because of the nature of the way cryptography works, it's hard to tell what the 7% of failures are; crypto either passes or it doesn't, without telling you what broke or why. We have some hints from the use of z= to compare to messages that fail to verify, but that only describes a subset of failures. We can't conclude that the 7% are spammers because lots of signatures on spam verify just fine. I think the answer is a mix of things you listed as well as some others you didn't. Reputation is an application that takes DKIM as input, but is not itself part of the DKIM protocol. Applications that consume DKIM in general have a scope outside of what DKIM can and should define. And in general, I think this group has gone as far as it can go. It's time for some other group, or context, to take over. Perhaps where do we go from here is a question best tackled by something like the IRTF. -MSK From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld Sent: Monday, March 28, 2011 3:23 PM To: Barry Leiba Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Work group future Hi, On 3/28/11 3:34 PM, Barry Leiba wrote: As you'll see from the minutes (available at https://datatracker.ietf.org/meeting/80/materials.html ), consensus in the room and among remote participants at the IETF 80 DKIM session was to close the working group after the 4871bis and mailng-lists documents have been finished. From the minutes: -- 4. Discussion of the future of the working group Two charter items not yet done: 3. Collect data on the deployment, interoperability, and effectiveness 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, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. - Is there energy and desire to do this? - Should we recharter instead for different work? - Should we close the working group? Consensus in room and jabber is to close. Will confirm on the mailing list. I seem to remember that there was neither consensus for close, nor for continue. But I was a remote participant, so I may have it wrong. I wonder whether there should be a followup on the figures, presented by Murray in the implementation report. Excellent work (thanks Murray), but are we satisfied with the outcome? Is 93% successful verification OK? Is it good, is it good enough, is it bad? What if SMTP had been designed in such a way, that in 93% of all cases messages were delivered with contents unchanged, but in 7% of all cases message content was lost or malformed? Would it have been a success? What are these 7% DKIM signature verification failures, are these: * spammers? * MTA's violating the rules? * MTA's fixing stuff, that did not comply with the standards? * other? Furthermore, I'm not sure whether the DKIM WG has concluded on thinking about the value of DKIM, what it can be used for. Is it's purpose limited to providing input to a reputation engine? Is that it? Or is there more than that? Anyway, these things will not fit into the current charter... /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton Sent: Monday, March 28, 2011 2:27 PM To: IETF DKIM WG; Dave Crocker Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04 0. Can you clarify what it is about the definition that is not clear? (Any guidance at all will help for understanding the nature of what needs fixing.) The initial text is the definition and it's simplicity makes it difficult to guess what the problem is. 1. authors and their organizations could be misinterpreted to mean that the conjunction defines a single identity. But the current text says ...examples include the author, ... so that misinterpretation exists there as well. I'd be fine with just authors' organizations. Since it's in definitions for Identity in general, and the i= could conceivably identify a specific author, is this a correct change to make? It doesn't seem to be talking specifically about d=. 3. One form of assessment service -- of which the late Goodmail was an example -- can give a priori assessment and then indicate tghe assessment by providing the signature to the message before it is sent. That is, the authoring organization passes the message to the assessment service and the assessment service hands back the signature to be included in the message. (The details can vary, of course, but this describes the basic model.) Hence the signature is somewhat akin to a capability token. [I thought I had explained this processing option a number of times over the years, specifically citing the Goodmail example.] That's a specific example of an ISP along the handling path. The potential for misinterpretation of this is greater than the benefit of explaining this potential usage scenario, especially since assessment has a very specific definition in the DKIM context. I think I'll let Dave reply to this one, since I lack the context. Section 2.9, Common ABNF tokens: Two new tokens are defined based on field-name and dkim-quoted-printable. But where are field-name and dkim-quoted-printable defined? field-name is defined in Section 2.10 DKIM-Quoted-Printable is defined in Section 2.11 Would it be beneficial to rearrange the sections to avoid the forward reference? OK by me. I'll swap the Imported and Common sections. Section 3.2, paragraph 2: dkim-quoted-printable is now defined in section 2.11, not 2.6. Fixed. 6.3 paragraph 5 has changed signing identity to SDID. The signing identity really corresponds to the AUID. That has not been correct for any version of rfc4871bis. The term Signing Identity has no normative value and is now only used in the introductory text. Also note that the Update removed any meaningful semantics for AUID: The AUID comprises a domain name and an optional Local-part. The domain name is the same as that used for the SDID or is a sub-domain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. In fact, the AUID is not part of DKIM's formal output. So the formal specification cannot then direct it be supplied to the assessment engine. Nevertheless, suppose a message with From address j...@marketing.example.com was properly signed with i=marketing.example.com and d=example.com. What the text is telling us is that the mail system SHOULD take pains to ensure that example.com is visible to the user. This is counter to all of the text in the DKIM specification that permits keys for a subdomain to be managed in a parent domain. If these is consensus to eliminate signing for subdomains, there is a lot of other stuff that needs to be removed from the spec, including the i= tag itself, the s flag in the key record, the text in section 3.9, and the security consideration in section 8.13. The Update removed semantics associated with the local part of the AUID, and not the domain-part. If there is not consensus to remove subdomain signing, the wording described here makes it meaningless. This goes to the heart of why I have been arguing that the output of DKIM should be the AUID (or its default value, which is the SDID), and not the SDID itself. Again I think Dave is the better one to reply as he has the context for the debate, but I suggest that the SDID is the only thing that is completely vetted by DKIM, because the AUID doesn't necessarily correspond to anything real (other than the substring matching the SDID). An implementation that wants to cater to a DKIM consumer which wants the AUID is free to do so, and Paragraph 5 of Section 6.3 doesn't proscribe such an action (in fact, OpenDKIM has mechanisms to provide either). It's simply describing a minimal compliant implementation. C.2. Compatibility with
