Dave CROCKER wrote: > > On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote: >> The fundamental problem with the current situation is that the >> authenticated identity is not displayed and the displayed identity >> is not authenticated. > > > Forgive my pursuing it in this fashion, but I'd class that as a first > derivative, rather than fundamental. (But, then, first derivatives are > important.) > > Fundamental is that DKIM is not trying to authenticate the message and it is > not > trying to authenticate any identity such as From: > > It is merely trying to affix a /separate/ identifier, with a claim that its > being affixed is valid, but not that it relates to any other aspect of the > message. In other words, it is trying to identify message streams, rather > than > "validate" messages or authors.
We get that Dave. But the message 'stream' must originate from somewhere and there is an originating signature that starts the stream and as long as the binding is with the 5322.From, you can not separate the two as much as you wish you. I hate repeating it so don't get made at me, but the ideal is not representing the reality. If you wish to completely separate the "message author" then 4871bis must change the required 5322.From binding from MUST to SHOULD|MAY. Only then will you begin to get what you are looking for. Until then, you will always continue to have this thorn of the side of "confused people." You can't have a strong technical requirement by nullify by "words." You must remove the technical requirement first. IMO what has confused people is this dilemma - a technical requirement vs words that conflict with it. I think it would be a mistake to break that technical required 5322.bind and I personally believe ultimately, policy will prevail in some form or another. Some policies will be relaxed or not declared at all for any signer to take over a stream, and some policies will like to have control over the stream interference by spoofers or unauthorized signers. -- 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
