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