On Tue, 2006-12-26 at 15:43 -0800, EKR wrote: > > I also discussed this with Lisa, and came to a very different conclusion. > > > > What is being proposed above is that an additional signature be > > generated and validated for every "important" header. That is a huge > > waste of energy, and it will cause massive unnecessary resource usage, > > particularly for recipients who don't care why a signature might not > > have validated. > > I don't know what's being proposed here, but as a technical matter > it's not really the case that you can't individually insulate each > header from breakage without doing a separate signature for each > one. Rather, you could simply include digests for the header value in > the header specification, i.e., > > DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; > c=simple; q=dns/txt; [EMAIL PROTECTED]; > t=1117574938; x=1118006938; > > h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>; > ... > > Again, I'm not offering an opinion on what should or should not be done > here, merely on what's possible.
Insulation is not as important as assuring an association with the signature thereby confirming the role being played. With the current base specification, any email-address domain not within the signing-domain can not explicitly indicate which email-address is associated with the signature. When these domains differ, finding an association must then be trial and error. To avoid a trail and error process, there should there be a means to assert an association that does not demand zone delegation or the exchange of private-keys. To retain the current freedoms of choice for email-addresses, one should consider the situation where the identity within the From header differs from that of the signing-domain. The current 'i=' syntax prevents this association being explicit when these domains differ. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
