Michael Thomas wrote: >> Generally I agree, but does saying "verification is undefined" satisfy those >> concerned that this is a security vulnerability? The example of >> double-From: shows verification succeeds. It's the interpretation of those >> results that is the problem. > > These are two separate questions, I think. I'm only commenting on whether > DKIM should be the SMTP police.
I don't think so, but it should inspect its own protocol requirements and within those requirements is its crown jewel - 5322.FROM, the only header that is required binding. Now lets consider if its wasn't a requirement, would it matter then? I think it greatly matters to the MUA participants. Note, the 5322.Subject is also a victim here, but its optional and its security threat is not even close that what a multiple 5322.From reveals. So I think it warrants adding a check for that too. But not as much as the From. The point is DKIM took on the job of providing a mail integrity and authentication work and raised the about what is expected. Included in that job is protecting its primary header - 5322.From. Keep in mind that not protecting it will also hurt ADSP which I already showed that implementation may look for the first one as well. In the spoofed Obama message, this is the authentication results generated here: Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; It picked up the wrong one. So we have TWO protocols that are affected by this. The irony in all this is that this Multiple 5322.From could be used to solve the MLM 3rd party issue. :) The verifier MUST check for invalid 5322.From messages if only because its part of the DKIM and ADSP formula and mechanics. Anyway, I hope the right decision is made and address it before it widely discovered and becomes a problem. Even without DKIM, MTA should be more aware about this and deal with it. But only DKIM can close the loophole for legacy operations. -- 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