On 10/18/10 12:18 PM, Murray S. Kucherawy wrote:
This is no more presumptuous than expecting that MUAs will adapt
to consume the output of DKIM as it stands now.
In another message I indicated that I don't presume either, but
assert that there's no middle ground; they will or they won't. If
they will, informative text is sufficient; if they won't, then we
have to start hardening MTAs to defend against MUA attacks because
that's where header changes and other enforcements are possible
since, by definition, any current annotations are invisible and will
stay that way.
I'm fine with accepting either model, but we have to understand the
implications of picking one. The latter, in particular, involves
some major scope creep.
Should the charter of a security related protocol need to anticipate
minor modifications to a verification process, that appears essential
for ensuring a DKIM signature is not inappropriately associated with an
incorrect From header field?
Rather than expecting changes to a plethora of consumers of DKIM
results, which might be used for sorting or display, ensuring PERMFAIL
occurs whenever replicate From header fields are detected ensures DKIM
will not be complicit in deceiving consumers of its results.
Adding such a check represents a normative change to DKIM, since it can
not be just advisory warnings to DKIM's consumers that suggests when
DKIM results should be ignored.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html