Rolf E. Sonneveld wrote:
On 5/1/11 6:55 AM, Dave CROCKER wrote:
[...]
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for
the
specification to suggest dealing with it.
You mean 5322.From?
And how should we read par. 3.2.2 of RFC4686 if it is out of scope for
DKIM to deal with it?
....
Although 5322.From is not mentioned here, how can DKIM provide any level
of defense against fraudulent use of origin addresses, if d= is the one
and only mandatory output of the verification process?
Or should we declare this paragraph obsolete?
/rolf
I think Dave can make it more easier for policy advocates to better
understand his statement:
"DKIM has nothing to do with the rfc5321.From field"
by explaining it terms of Protocol Consistency using what is already
defined in the "Requirements for a DKIM Signing Practices Protocol"
(RFC5017) section 5.3, item #10:
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
In short, if there is a Trust Assessment logic at the Verifier and it
sees a valid signature signed by a trusted domain, then 1st party
policies MUST NOT (according to item #1) apply.
No one disputed this. The problems was:
1) Allowing 1st parties to declare it allows 3rd parties to take over,
2) Dealing with anonymous fraudulent abuse streams,
Until there is universal trust assessment coverage in greater numbers,
verifiers will be dealing with a lot of uncertified or unknown signers.
Nonetheless, none of this should exclude the idea of an ODID identity.
Its there, it exist, its in the mandatory RFC5311.From and we should
allow Local Policies continue to dictate how it will evaluate the
blasting of DKIM signed mail on this system. Until SDID can be useful
with a payoff, verifiers will need a fall back with ODID.
--
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