On Tuesday 01 August 2006 05:12, Stephen Farrell wrote: > Scott Kitterman wrote: > >> Message from A, signed by A and B; does SSP matter? (I hope not.) > > > > In my book it's the same as A signed by A. The only concern I would have > > is if B added content, what to do about that, I'm not sure. I expect > > that's probably a question for receiver policy and unlikely to be > > standardized. > > > >> Message from A, signed by C; SSP says nothing about C. > > > > Yes. Then how to treat this would be a question of what A's SSP says (is > > the list exclusive or not) and the receiver policy. > > I still don't understand why we care if someone adds a signature and > does nothing else. > > If B adds a signature covering a header not covered by A's signature, > then I can imagine that the verifier might want to treat that header > differently from those signed by A. But ignore that for now - if both > A and B sign exactly the same headers+content, then what bad thing > can happen? (That would cause A to want a countermeasure.) > Agreed, but in the multiple signature case my caveat was limited to the case of the second signer adding content. If B adds a signature, but does not modify the content of the message, then I don't think the verifier would treat them differently.
As I read the later case, the only signature present (C's) is not one that is included in A's SSP. In this case we have a message with a signature that is outside the scope what A has said is authorized (or not included in A's authoritative list). If A is a high profile phishing target and signs all of it's mail, then it would be useful (I think) for receivers to recognize that the message has been signed by someone other than who A said it would. I believe it's that distinction that gives DKIM the potential to be a useful (not a panacea, but useful) anti-phishing technology without having to layer a non-standard reputation system on top of it. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
