On Apr 6, 2011, at 4:10 AM, Charles Lindsey wrote:
On Tue, 05 Apr 2011 11:33:10 +0100, Rolf E. Sonneveld
<R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl> wrote:
Ad 2. To give some examples of use profiles:
* of course, the first thing that comes to mind is to use DKIM as
mechanism to build reputation services on. For this use profile
not many restrictions will be required, but restrictions like MUST
NOT or SHOULD NOT use l= can be part of that spec. Such a spec
could also give some guidance re. the use of i=
and lost more examples snipped
It seems to me that we're constantly mixing the possible uses of DKIM
with the core specification of DKIM. By differentiating the two, 4871bis
can be finished and DKIM can start to bear fruit.
Which suggests that future use profiles may need tag hooks to hang their
features on, and so if there is some underused existing tag (such as i=)
already in the spec, then it is better left there to facilitate such
future profiles.
That sounds like a fragile way to extend things - leave a little used feature
around and hope someone who wants something new hijacks that
field in a non-conflicting way instead. (Which may not be what you're
suggesting, but it's an implication I've seen in some comments about i=).
Outside of the information that is needed to validate the DKIM signature
(v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't seem to be any real need for
information to be recorded in the DKIM-Signature field at all. Rather, it can
use the 5322 extensibility to add a header containing the information
that needs to be included (with an understanding that the receiver should
require that header be covered by the DKIM signature).
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html