--On 4 October 2010 23:15:05 -0400 Hector Santos <hsantos(_at_)isdg(_dot_)net>
wrote:
Murray S. Kucherawy wrote:
The term "third-party" was removed because DKIM itself
doesn't say anything about a binding between "d=" and anything
else in the message. That concept is first presented in ADSP.
Since the implementation report is only about DKIM itself, not
ADSP, discussing author vs. third party is actually irrelevant.
-1
It is extremely relevant.
The data is there. The numbers can be calculated from the sample size
(~500k) and the proportions. They're nowhere near the numbers ("Originator
signatures: 1.2 billion Third-party signatures: 184 million") that you
quoted in another email, which also don't match the proportions that you
quoted. Where did 1.2 billion come from?
"Third party" is somewhat of a leap from "the domains don't match". For
example, if the from header is in the domain "example.com" and we see
"d=foo.example.com", is that really a third party signature? Perhaps some
clarity of whether subdomains were permitted to match would be useful.*
Oh, and are you thinking this is about implementation of ADSP? I think it's
supposed to be about implementation of DKIM, so that DKIM can be
progressed. Please don't let a misunderstanding hold that process up.
Its an implementation data report about observed operations and
consistent per chapter itemized goals:
2. Collect data on the deployment, interoperability, and
effectiveness of the base DKIM protocol, with consideration
toward updating the working group's informational documents.
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.
The empirical data is on par with #2, #3 and thus #4. It provides
the field testing and engineering insights and information people need
to progress with DKIM in a better way without blinders.
I don't get you guys, doing this to push a standard. If you think
this is kolsher - its not.
* It would be interesting to know what proportions of author addresses were
subdomains of the d= value, and vice-versa. Even to know if the domains
share common whois registrations (like foo.example.com and bar.example.com)
would be nice, though harder to do. Having said all that, I have my own log
files that I could analyze, so I'll shut up.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html