On Dec 28, 2006, at 4:06 PM, Scott Kitterman wrote:
This seems quite simple to me. If the domain owner doesn't care
about protecting headers, they should not sign them. If they care
about protecting headers from being modified, they should sign them.
The presence of a failed signature shouldn't affect processing.
Treating a failed signature as anything other than no signature
seems a poor practice to me.
The concern is not about meeting a signer's expectation. The current
base draft stipulates known bad signatures should not be removed when
signing a message. A recipient should expect a need to avoid dead
signatures. It might also become common for a signer not to be
"linked" to some header via an arrangement between a contained email-
address domain and the signing domain. Such arrangements involve
sharing private-keys or zone delegation. Such arrangements are
likely expensive and may require mutual coordination between as many
as three entities.
Association by reference is an alternative that can be done
autonomously. This alternative provides the email-address domain
owner greater freedom that also does not require that their providers
hold either their private keys or control a portion of their domain.
What happens when a signature's linkage to an email-address
meaningful to the recipient is not directly asserted due to a
limitation of the signature's syntax? A much higher network overhead
is the result, that might be exploited.
A lack of linkages may occur when DKIM is for abuse reporting aiding
in the defense of outbound IP address space. Expense and support
issues associated with adding originating headers to someone's
message may cause a mode of operation devoid of common-domain
linkages, despite expectations declared in the base draft. When
there is only one email-address the recipient wishes to verify, there
should never be a need to validate more than one signature. By
extending the syntax of the 'i=' parameter, the signer makes the
linkage explicit, even when domain zones or private keys have not
been shared.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
