Murray S. Kucherawy schrieb:
My vote:
a) The erratum I-D [1] is ready to go. Process it.
If there is indeed a requirement to conform to the concept that a protocol
must specify its payload, I believe this is the right way to go. At
present, a new API implementor has no clear indication of what a minimal
DKIM implementation has to provide to be compliant.
That's correct. As a summary of what I've read in the last mails with
inclusion of the experience I made with data collection, evaluation and
publishing in www.dkim-reputation.org:
- the UAID definition in draft-ietf-dkim-rfc4871-errata-02 is suitable;
as far as I can see Jim's proposal of r= was made having a higher
identifier stability in mind. IMHO, concerning stability, with r=
nothing more can be reached as with the definition of the UAID in the
errata document.
Reasons for that: Jim was talking about the indirect transition of
reputation by the referring r= identifier. I think the following trust
hierarchy is correct in principle: "author -> author identifier ->
signing domain -> DNS". I consider the lower part of the hierarchy
"signing domain -> DNS" as the trust anchor in DKIM. I see no
auto+technical+trustworthy means to provide a transition of reputation
beyond this trust anchor --> transition aspect fails. The idea of a 1*r=
: N*identities relation reverses the hierarchy --> not usable. The
result is: r= is conceptual equal to i= (it doesn't really matter if i=
contains d=, it's still opaque). Did I miss something?
- I confirm the rare use of i=; the errata clarifies some
misunderstanding but it won't lead to a broader use 'cause the
advantages of the additional effort to include i= are unclear at the
moment. But: thinking about a higher identifier precision in reputation
systems (I just refer to good signers, bad signers will try to trick the
rep-systems anyway) I'd absolutely appreciate if in the errata doc,
"Section 3.5 The DKIM-Signature Header Field" the sentence "The syntax
is a standard email address where the Local-part MAY be omitted." could
be replaced by "The syntax is a standard email address where the
Local-part SHOULD be set to a user unique value". Coming back to the
last discussion: in my view a reputation system has to deal with
arbitrary UAID values, I am missing the requirement that lead to the
"protocol" discussion (?)
Regards,
Florian
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html