On 6/24/11 2:43 PM, Steve Atkins wrote: > On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote: >> >> Complaints from John, Dave, and Barry and others is likely and >> understandably out of fatigue. They just want the process to be over. >> We are now hearing there is a vital protocol layering principle at stake >> which even precludes DKIM from making these checks! Really? > While people are tired of you, fatigue is not the issue. > > Rather it's that you either don't appear to accept the fact that very few > people agree with you, rather you continue to bring up exactly the same > issues repeatedly, even though you know you're not going to convince anyone > by that repetition, as they've explained to you in detail, repeatedly why > your concerns are unfounded. That ends up consuming many peoples time to no > good result. > > 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. 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. Does this avoid the "out-of-scope" claim being repeated ad-nauseam? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
