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