Murray S. Kucherawy wrote:
-----Original Message-----
cases. And we're telling verifiers that when you add DKIM, that
tolerance might now be unwise.
Concur here as well. "Be liberal in what you accept, be strict in what you
send" has some very clear intent behind it.
I don't see how this applies because its about being less tolerant.
See below.
Here is my reworded text. I would not give the "How to Exploit." Let
the bad guy figure it out. �No blaming anyone.
-1; I like the wording that's there.
Concur; -1 on the change. I furthermore submit that we are compelled to
describe the known "attack", as that's precisely what we are supposed to
include in Security Considerations.
Sure, but only when you work out all the security issues and due to
time and the rush to rubber stamp this bis, it hasn't completely been
done.
The text statement is not complete because the issue is not only when
mail is not compliant but when a receiver system is indeed compliant
but not by DKIM. Only one solution was provided.
I showed this in the message:
http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html
indicating how ready systems can be RFC5322 checking ready but somehow
with DKIM this is bypassed.
Only DKIM can check for DKIM requirements and this is not stated in
the text.
There is no verifier statement. (Note to those who have written me
off list about the lack of verifier statement; please just don't tell
just me - post your opinion here too!)
The TEXT should include something like:
A verifier can be resistant to these exploits by invalidating
messages with multiple From: header violations.
The current text is a first good effort, got lost on blaming others,
but itself for lack of proper verifying its messages.
Why?
Because if this was discovered during the WG TA efforts, rest assured
we would have the 5322.From Exception Trapping Logic added to the
verification and signing logic.
Add it correctly so we can be done with this please.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html