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
