On Jun 24, 2011, at 4:04 PM, Douglas Otis wrote: > On 6/24/11 2:43 PM, Steve Atkins wrote: >> Your current argument is of the form: >> >> Doug: X is bad, and could theoretically lead to end-user confusion in >> one particular obscure replay scenario, given a carefully chosen set of >> assumptions about MUA user interface design. >> >> World: Yes, X is bad, but it's out of scope for the DKIM protocol, as >> it's nothing to do with DKIM, rather it's a violation of 5322. >> >> World: Spam filters and MTAs should certainly consider it, though. >> >> World: Heck, DKIM *implementations* probably should, even though it's >> not part of the DKIM protocol - other than "DKIM applies to email, and data >> streams with X are not email". >> >> Doug: If it's not in the DKIM protocol, then "we" are telling the entire >> world that they MUST NOT pay attention to X anywhere in their mail handling >> process... >> >> World: Uhm... what? No, we're not. That's just rid.... >> >> Doug: .... and that makes DKIM worthless! >> >> World: Uhm... what? No, that's not what we said. >> >> Repeat, ad- nauseam and beyond. > Steve and Dave, > > Allow me to bring up a few new (albeit related) issues then. > > ADSP (RFC5617) depends upon DKIM's output. ADSP failed to consider a > pre-pended header threat. When present, this unchecked threat means the > Author Address is undefined. Those trusting ADSP results are placed at > risk due to a lack of assurance pre-pended header fields were excluded.
I think this is just a restatement of your previous concern, rather than a new issue. It seems out of scope for this thread, though, as this thread is discussing DKIM, while you're talking about an ADSP issue. Perhaps bringing it up in it's own thread (with ADSP in the subject line) would let people who are interested in the ADSP specific aspects pay attention to them. > Message Header Field for Indicating Message Authentication Status > (RFC5451) also depends upon DKIM's output. This specification also > failed to consider a pre-pended header threat. When present, this > specification lacks signaling to indicate whether signed singleton > header field replicates were excluded and of course the header.from is > undefined. Those trusting an Authentication-Results header field are > placed at risk due to the lack of assurances that pre-pended header > fields were excluded. This is just a restatement of your previous concern, it is not a new issue. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
