On Jun 17, 2009, at 2:24 PM, Murray S. Kucherawy wrote:
You have generalize ASSESSORS to have two minimum inputs:
BOOLEAN (DKIM verification result)
STRING (DKIM D= value)
Correct.
1) Why?
There is use in specifying an API here. Every other protocol we've
named so far as examples have an API, whether de facto from lots of
experience, or implicit from the spec that defines it the protocol,
or something actually explicit defining the API. There's no
evidence that this is a bad idea.
This has already been defined by RFC 4871 as the i= value, and when
that is not available, this defaults to @<d= value>.
The i= information is intended to provide guidance for annotating
messages, whereas the d= value simply indicates where the key is
published. A modification to RFC 4871 that has the i= parameter
routinely excluded from assessment then fails to offer the intended
guidance AND fails to fully consider the source of the message. The
described use of your API even suggests that by offering i= value
guidance, that the related message might become discarded. There is
ample evidence that discarding accepted email is deleterious, and in
general, a bad idea. The fact that users will not see discarded
messages does not make this any better. Some of the loudest
complaints stem from missing messages.
2) How does a DKIM implementation generalize the fixed prototype to
satisfy newer ASSESSOR that require different input? You are going
to need some protocol that defines the input requirements for the
specific and different assessor.
Yep, and nothing that's been said so far precludes this idea.
Defining a minimum does not also automatically define a maximum or
establish other constraints.
Yes it does curtail the alternative. By limiting assessments to just
the d= value, and then suggesting that the i= values can be used for
subsequent discard, creates a significant impediment to even offering
the intended information.
In addition, by not assessing the intended "on-behalf-of" identifier,
the i= value may overlook deceptive sources that might have been
replayed and impractical to recall. A service that offers an
assessment of the i= value will ensure the information used to
annotate a message is not from known deceptive or abusive sources. If
the service wishes to ignore a portion of the the i= value, it can.
But ignoring a portion of the i= value has a potential for creating
inter-operability issues. The imaginary inter-operability issue
becomes real with this change. :^(
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html