-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Friday, October 15, 2010 11:39 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
So anything that circumvents "what you see is what they sent" I think
is in scope for DKIM to eliminate or mitigate.
We either believe MUAs suffer from inertia and won't in any reasonable
timeframe be able to show the good vs. bad parts of a message, or we think this
work can provoke such evolution. So let's look at those two possibilities
specifically.
If we claim MUAs will grow to embrace DKIM, then by definition they will be
able to show the parts of the message that were covered by the signature hashes
and those that were not. For the double-From case, this would mean one of them
(the "good" one) is rendered differently than the other (the "bad" one). If
that's the case, DKIM doesn't need to worry about it beyond providing advice
for MUAs that they should do so because they're already going to do that.
There's no need for normative language in this case.
If on the other hand we believe they won't change in a reasonable timeframe,
then we appear to be asserting that is incumbent on a complete/safe/useful DKIM
verifier to take corrective action so that the MUA's DKIM-ignorance can't be
exploited. That means a DKIM implementation has to be integrated into the MTA
enough that it can cause alteration or removal of suspect header fields or even
block message delivery entirely. Merely detecting that an incoming message is
malformed (e.g. two From: fields, whether or not either was signed) and
refusing to verify it is insufficient, because that has the net effect of
setting a bit that the MUA likely won't even check, whether that's the Boolean
result of a library function or an Authentication-Results field that few people
are actually seeing or checking. So adding these enforcement requirements with
an essentially invisible impact when errors are found adds dull teeth and
useless complexity to the document. Instead, this makes D!
KIM verification a required MTA function even though we specifically said we
were trying to create a layer that had no such capabilities (as reflected in
RFC4871, Section 1). That makes it bigger than what this group was ever scoped
to do. Maybe that means in retrospect that our scope was too small, but that's
a different issue.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html