Julian Mehnle wrote: > Hector Santos wrote: > >> It has been observed by implementations that is it possible to replay >> a message with a 2nd 5322.From header at the top which wouldn't break >> the DKIM signature validity, but would often be displayed by MUAs to >> display the new 5322.From display rather than the signature bound >> 5322.From header.
> No. The trick is to list From twice in h=. This ensures more From > headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. > Perhaps this could be mentioned in the spec with a specific reference to > the From header, but in general terms the spec is pretty clear about how > to prevent the addition of a header field. If you referring having duplicate from: in h= mitigate this issue, see above. As I proposed, the semantics must include an exception clause for the Verifier and Signer signing 5322.From binding logic as described in section 5.4 to address this. It also needs to recommend that MTAs do RFC5322 validating as well - but you are not going to find this in the wild unless the MTA is DKIM compliant and is aware of this situation. It has to be documented in 4871bis for DKIM standardization to make implementations now and the future aware of it and deal with it. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
