Hector Santos:
From: "Wietse Venema"
Apologies. Let me phrase this better.
None of these loopholes would exist if signatures could vouch only
for rfc822.from domains that match the signature's d= domain (*).
Third party signatures are part of the problem. Making them "work
right" requires additional complexity. Complexity leads to error,
vulnerability and exploitation.
Wietse, you won't find me arguing this point! :-) That's been my position
for the past 18+ months (*).
Now we just need convince everyone else who is bent on allowing open ended
3rd party signatures (2822.From != signing domain). If we allow them, then
we just can't ignore the exploitation. We need would some "kind" of control.
Thanks for the opportunity to explain my point more clearly.
By themselves, nothing is wrong with third-party (i.e. 2822.From
domain != d= domain) signatures. The problem is the mistaken belief
that signatures make statements about 2822.From addresses. This
leads to complexities such as "what domain can sign my mail". Your
"control" is a solution for a problem that doesn't need not exist.
Even in the case of a first-party signature (2822.From matches d=
domain), the 2822.From is not of primary importance. It is the
signing domain that comes first; the signature is the basis of any
rating that one might assign to an email message.
I favor first-party signatures mainly because they avoid reputation
cross-talk: when an ISP uses the same shared signing domain for
multiple author domains, bad actors can negatively affect the email
reputation of innocent author domains. With first-party signatures
the damage would be more confined to the bad actor's author domains.
Both first-party and shared-party signature approaches present
scalability challenges. With first-party signatures, there is a
technical problem of deciding what signing domain and key to use.
With shared-party signatures, there is a non-technical problem of
preventing bad actors from messing up everyone elses reputation.
As a technical person, I prefer to tackle the technical problem.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html