Re: [ietf-dkim] Protecting messages, not MUAs, MTAs, or anything else

> 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, ...
This is getting awfully overcomplicated. One of the key differences 
between DKIM and predecessors such as S/MIME is that it can reasonably 
operate as a layer between MTA and MTA or MTA and MUA, without requiring 
integration into either.  When we were working out relaxed 
canonicalization, it is my distinct recollection that our goal was to 
allow only changes that would make only insignficant changes to the 
message rendering in MUAs. Hence we didn't allow adding arbitrary white 
space since that would let bad guys reformat mail as ASCII art.
What I'm proposing, and am part way through implementing, is just to 
disallow a few more situations that are likely to make a large difference 
to the rendered appearance.  My current plan is to have the verifier fail 
if there are both signed and unsigned instances of any of the headers that 
are supposed to occur only once.  That's it.  If a signer wants to sign 
two Subject: headers, that's fine so long as the verifier sees the same 
two Subject: headers and no more--the message the user sees is the one the 
signer signed.
Note that this design is not in the least idiot-proof, but if a signer 
uses a normal set of options (by which I mean following the advice in 
4871), it means that if someone renders a message with a valid signature, 
it'll look like what the signer signed.
In the absence of a signature, mail systems will continue to do whatever 
they do now.  Their behavior when a message has two Subject: lines is 
pretty random, but I don't really care, since it hasn't been a problem so 
far.  What this prevents is signature based whitelisting, either absolute 
whitelisting or spam filter positive scoring, of a message that's not what 
the signer signed.
So, uh, can we agree that Jim's SHOULD language to tell people to do this 
is a good idea?
R's,
John

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html