With DKIM you still can not prevent an obnoxious sender who is using a
domain that also permits various mail-addresses, unless you want to
block all of yahoo.com for example.
The only thing DKIM "prevents" is detecting invalid uses of a domain
name for a signature.
It is well understood that the granularity of control is the domain and
that such things as reputation pertain to the domain. If a domain is
shared, then the administrator of that domain has to figure out how to
deal with it. It is not dkim's problem.
In other words, I do not understand why you are raising this point, in
this discussion. I suspect it actually has nothing at all to do with
what is being discussed right now. It's an important point, yes, but
not to this discussion.
Since DKIM does not "do" reputation, talking about the limitations of
using DKIM for reputation strikes me entirely out of scope.
Include the opaque-identifier concept, and then you could block the
obnoxious individual independent of the mail-address being used at the
time or the size of the domain. : )
If folks believe that it is essential to have DKIM "do" various
additional services in its initial round, then that ought to be
discussed and agreed to, before trying to specify the engineering
solution, don't you think?
Deal with the replay problem and DKIM allows reputation to be extended
to the domain name rather than just the IP address of the client.
Much of the grief occurs when there is unintended collateral
blocking. When done using the opaque-identifier, then you also have
your desired feature.
get everyone to lay down their guns and we will be on our way to world
peace.
is there some reason these issues cannot be deferred to a later round of
enhancements?
d/
ps. please try to answer this without a) once again repeating the
details of the solution, or b) once again explaining that the solution
is wonderful. I asked why it is essential to have the solution in the
first round.
_______________________________________________
ietf-dkim mailing list
http://dkim.org