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