[ietf-dkim] Working group last call on draft-ietf-dkim-rfc4871bis
Thus begins working group last call on the DKIM-base update, draft-ietf-dkim-rfc4871bis-01: http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis The working group last call will run through Friday, 22 October, 2010. This is the version of the specification that will be advanced to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. There is one outstanding discussion on the -01 version: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014608.html Please comment specifically on that, stating whether you agree with the proposed change or prefer leaving the text as it is. Remember that a change will NOT be made without support, so if you like the change it's important to say so. Because this is moving the existing specification along the standards track, substantive changes are explicitly out of scope unless someone uncovers a serious error in the protocol. In scope are clarifications and editorial issues. So: everyone please review draft-ietf-dkim-rfc4871bis-01, and comment here by 22 October. Thanks. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On Sun, 03 Oct 2010 07:13:55 +0100, Michael Deutschmann mich...@talamasca.ocis.net wrote: And there's the rub. The problem is that a major threat we anticipate, is that should a means be added to append a footer without breaking the signature, bad guys will find short legitimate messages and replay them with a footer containing spam. I would suppose that an added footer will usually take the form of an extra part with Disposition: inline in a multipart/mixed. Insofar as this is not the current convention it ought to be (if only so that users can filter out those annoying footers). In that case, the clean solution, in lieu of the little-used 'l=...', would be to have some mechanism for speciffying exactly which parts/atachments of a messsage had been included in the signature. Whether it is now too late to add such a fundamental enhancement to DKIM is an interesting question, even though it might enable various useful possibilities. But at least it ought to be looked into. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DSN with signature replay
I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address. But it kept several headers from the original message in the DSN message headers: DKIM-Signature: Organization: X-Mailer: What logic is there to this? Of course, the signature was invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
I'm catching up to the list here, so I'm answering these in the order I see. Someone else may have covered some points and I apologize if it has been beaten to death. comments below: On Fri, Oct 1, 2010 at 5:40 PM, MH Michael Hammer (5304) mham...@ag.com wrote: To pick on you a little, if a domain owner uses your approach to authorize signing by an ESP1, what is the stable identifier we are talking about? Is it specific to this customer or is it shared across customers? Does the domain owner understand potential impacts on their reputation (assuming domain based reputation systems ever get off the ground in our lifetime)? We are advising our clients to create a sub-domain for DKIM identifiers. Something they control. Something not tied to their From:. For those that have multiple streams, we'd recommend creating DKIM identifiers for each stream. Using DKIM as it was intended. What happens when the domain owner dumps ESP1 and goes to ESP2? Do they lose whatever (We assume fantastic) reputation they had? Do they go to square 1 or are they borrowing/renting reputation from ESP2? If they are borrowing/renting reputation from ESP2, how do they know that ESP2 isn't using their domains good reputation to help other not so good senders at ESP2? Diluting the badness so to speak. There are of course bad ways to implement things. Some ESPs use shared IPs for new clients in order to meet the sending rates clients ask for on day one. We do not have that strategy. Client's go through a warming phase with IPs dedicated to them. With DKIM, they will either come with their own identifier and be able to continue business as usual or start with a new DKIM identifier. I'd advise against using an e-Dialog DKIM identifier. I'm assuming this desire for 3rd party signing to have the same weight as 1st party signing is somehow related to deliverability and not abuse. Abusers can be 1st party signers. So I don't understand why there is a distinction being made between 1st and 3rd party. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Very odd. It might be the same software, but what I am seeing is the bouncer doing: 1) Copies the original headers minus Received trace headers, 2) Change From: to the mailer daemon address 3) Change To: to the return path address 3) Adds headers for DSN mime parts. The only reason I am seeing this because we are signing mail now and I'm seeing the new invalid signature logging with these type of bounces. -- HLS Hector Santos wrote: Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
On 10/4/10 11:00 AM, Jeff Macdonald wrote: On Fri, Oct 1, 2010 at 5:40 PM, MH Michael Hammer (5304) mham...@ag.com wrote: To pick on you a little, if a domain owner uses your approach to authorize signing by an ESP1, what is the stable identifier we are talking about? Is it specific to this customer or is it shared across customers? Does the domain owner understand potential impacts on their reputation (assuming domain based reputation systems ever get off the ground in our lifetime)? We are advising our clients to create a sub-domain for DKIM identifiers. Something they control. Something not tied to their From:. For those that have multiple streams, we'd recommend creating DKIM identifiers for each stream. Using DKIM as it was intended. Only when signed by the same domain (Author Domain) matched exactly with the From email address domain can ADSP policy apply. Retaining customers when your domain is heavily phished means having non-complaint messages rejected becomes a greater concern. What happens when the domain owner dumps ESP1 and goes to ESP2? Do they lose whatever (We assume fantastic) reputation they had? Do they go to square 1 or are they borrowing/renting reputation from ESP2? If they are borrowing/renting reputation from ESP2, how do they know that ESP2 isn't using their domains good reputation to help other not so good senders at ESP2? Diluting the badness so to speak. This assumes reputation assignment ignores who registered the parent domain. There are of course bad ways to implement things. Some ESPs use shared IPs for new clients in order to meet the sending rates clients ask for on day one. We do not have that strategy. Client's go through a warming phase with IPs dedicated to them. With DKIM, they will either come with their own identifier and be able to continue business as usual or start with a new DKIM identifier. I'd advise against using an e-Dialog DKIM identifier. This also ignores the ability of bad actors to send themselves signed messages they can then be redistribute because DKIM is not _required_ to capture the SMTP RCPT TO. Any expectation of such would cause many messages to be lost. I'm assuming this desire for 3rd party signing to have the same weight as 1st party signing is somehow related to deliverability and not abuse. Abusers can be 1st party signers. So I don't understand why there is a distinction being made between 1st and 3rd party. The difference relates to compliance related with signing practices. With replay ability, DKIM is not easily leveraged as a basis for reputation. Reputation will likely need something developed along the lines of public keys or certificates offered by SMTP clients, because these services can track where messages are sent. Where messages are sent is often the basis for identifying what is abusive. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
Dave CROCKER wrote: On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote: The fundamental problem with the current situation is that the authenticated identity is not displayed and the displayed identity is not authenticated. Forgive my pursuing it in this fashion, but I'd class that as a first derivative, rather than fundamental. (But, then, first derivatives are important.) Fundamental is that DKIM is not trying to authenticate the message and it is not trying to authenticate any identity such as From: It is merely trying to affix a /separate/ identifier, with a claim that its being affixed is valid, but not that it relates to any other aspect of the message. In other words, it is trying to identify message streams, rather than validate messages or authors. The fact that DKIM uses underlying crypto algorithms keeps confusing people into wanting to use it the way OpenPGP or S/MIME are designed to be used. Ain't gonna work. d/ But DKIM does indeed bind an identifier (d=) to a message cryptographically in a way that allows an MTA to use the reputation of the owner of the (yes, separate) identifier when evaluating the spamminess of a message. The d= domain is the authenticated identifier to which I was referring. ADSP and the related third-party extensions try to create a binding between d= and From: but either break applications such as MLMs or create a provisioning problem where domain owners need to explicitly configure the third-parties that are allowed to sign their mail. These mechanisms are motivated by the fact that MUAs typically display the From: field and users tend to give credence to the identifier in this field when evaluating phishing messages. My point is that, rather than trying to authenticate this field with DKIM + ADSP, we should be encouraging MUAs to display the d= value and let the user independently evaluate the reputation of the signing domain and decide whether or not it was appropriate for the domain to sign mail with the given From: line. I can trust a message From: paypal.com but signed with d=mipassoc.org not because paypal.com has somehow authorized mipassoc.org but because I subscribe to the dkim mailing list and I know the context in which the message is being delivered. I would similarly know that my friend Joe has a vanity domain but uses google apps for his mail, and expect to see a d=gmail.com DKIM signature on mails from him. If this changes for some reason, I might call Joe and ask him if he changed providers. Even if the MUA doesn't display the d= domain directly, I can imagine they might implement security tools similar in spirit to some of the CA validation extensions for browsers that are available to warn the user in case the CA of a given website changes countries (see http://files.cloudprivacy.net/ssl-mitm.pdf). -Pete ___ 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-02.txt
This version makes minor editorial corrections to AOL's data, adds Gmail's data, updates OpenDKIM's data, and applies feedback recently sent to the list. I propose a WGLC on this at the chairs' discretion. I don't have any additional data pending to add, and it sounds like the AD is already happy with the information that's currently there. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. 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-implementation-report-02.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-02.txt Pages : 17 Date: 2010-10-04 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-02.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-02.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
I wrote it, and it looks ready to go. From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine [jo...@iecc.com] Sent: Monday, October 04, 2010 2:06 PM To: Barry Leiba Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-03.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-03.txt Pages : 29 Date: 2010-10-04 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-03.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-03.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Monday, October 04, 2010 5:06 PM To: Barry Leiba Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim- implementation-report to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. I've reviewed it and agree that it looks ready to go. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
This version consolidates all of the minor corrections submitted to date, as well as the more substantive things that appeared to have consensus. It did not include the suggestion to add a few points about MUA improvements that would help in the area of DKIM deployment and MLMs. I'd like to revisit the idea of adding a paragraph or two about this in an informative appendix. Do the participants feel this would be a bad or dangerous idea? The main point would be to lobby MUA developers to begin showing the identity authenticated by DKIM (the AUID or the SDID or both), as Daniel suggested. I think this is probably something we'd like to see in general and this is as good a place as any to say so. I also did not convert the status from Informational to BCP, and carefully avoided the standard IETF normative words. There appears to be some dissent about the sum and substance of this document if it were to move to the stronger level. My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft. However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. Feedback welcome. -MSK ___ 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-02.txt
Murray S. Kucherawy wrote: This version makes minor editorial corrections to AOL's data, adds Gmail's data, updates OpenDKIM's data, and applies feedback recently sent to the list. I propose a WGLC on this at the chairs' discretion. I don't have any additional data pending to add, and it sounds like the AD is already happy with the information that's currently there. Wow! SMUDGING OF DATA by removing one of the most significant data points: Author vs. Third-Party: 73% of the signatures observed were author signatures, meaning the d= value in the signature matched the domain found in the From: header field. The remainder, therefore, were third-party signatures. Originator signatures: 1.2 billion Third-party signatures: 184 million Unbelievable! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
Barry Leiba wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have only one comment. The removal of very significant data points from this last revision: Author vs. Third-Party: 73% of the signatures observed were author signatures, meaning the d= value in the signature matched the domain found in the From: header field. The remainder, therefore, were third-party signatures. Originator signatures: 1.2 billion Third-party signatures: 184 million This is signification information. Why was it removed? Why hide this significant fact? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. For example: From: phis...@badguy.com-- injected, replayed, shown by MUA DKIM-Signature: d=signer.com ...; From: sig...@address.com-- hash bound to signature The MUA will display the injected 5322.From header and the signature is still valid because it only signed the bottom one and verifiers also use this header to validate the signature. A review of the the 4871 specification shows this statement in section 5.4 which can explains how this is possible: 5.4. Determine the Header Fields to Sign ... Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. There needs to be a special consideration where: 1) Verifiers and MDAs consider checking for violating RFC5322 messages with multiple 5322.From headers and rejected it, or 1) hash verification should be done for all 5322.From fields and not just the last one as the above paragraph implies. 2) signing should be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have should to display only the first 5322.From header found. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On 10/04/2010 02:09 PM, Murray S. Kucherawy wrote: I wrote it, and it looks ready to go. Dear g*d, it's the mailing list equivalent of people pressing the like button on their own posts :) Mike From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine [jo...@iecc.com] Sent: Monday, October 04, 2010 2:06 PM To: Barry Leiba Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On Oct 4, 2010, at 5:06 PM, John R. Levine wrote: to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. +1 Regarding Hector's complaint, I think a separate usage report focused on 1st/3rd party signing practices may be appropriate -- but I don't think it makes sense to hold up the advancement of the DKIM base spec for that. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
I would be curious also but would be happy with a 73% of the signatures were author signatures meaning the d= value in the signature matched the domain found in the From:header field and let the reader draw their own conclusions On Oct 4, 2010, at 6:02 PM, Hector Santos wrote: Barry Leiba wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have only one comment. The removal of very significant data points from this last revision: Author vs. Third-Party: 73% of the signatures observed were author signatures, meaning the d= value in the signature matched the domain found in the From: header field. The remainder, therefore, were third-party signatures. Originator signatures: 1.2 billion Third-party signatures: 184 million This is signification information. Why was it removed? Why hide this significant fact? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of J.D. Falk Sent: Monday, October 04, 2010 4:41 PM To: DKIM List Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report Regarding Hector's complaint, I think a separate usage report focused on 1st/3rd party signing practices may be appropriate -- but I don't think it makes sense to hold up the advancement of the DKIM base spec for that. Actually the data are still there. It was just reworded, as per Jeff's suggestion: Identities: 73.8% of the signatures observed included a d= value matching the domain in the From: field. ...so this is a non-issue. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
Murray S. Kucherawy wrote: Actually the data are still there. It was just reworded, as per Jeff's suggestion: Identities: 73.8% of the signatures observed included a d= value matching the domain in the From: field. ...so this is a non-issue. Sure it is. Was it 78.9% for all implementations? AOL and GOOGLE, the 2006 Interoperability Event participants, your OpenDKIM network of implementators? Or was it just for AOL 78.9% In fact, one can take a swag that google's data is 100% third party because it was there reception analysis - unless one suggest google allows others to sign as GMAIL to send to their servers? Stop skewing DATA - its unethical. We might not be smart but we are not STUPID. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
We are not holding up the dkim spec, we are wanting a datapoint to be kept in the draft-ietf-dkim-implementation-report On Oct 4, 2010, at 7:40 PM, J.D. Falk wrote: On Oct 4, 2010, at 5:06 PM, John R. Levine wrote: to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. +1 Regarding Hector's complaint, I think a separate usage report focused on 1st/3rd party signing practices may be appropriate -- but I don't think it makes sense to hold up the advancement of the DKIM base spec for that. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
