The public will understand anti-forgery as protecting the identity of the
author. I have never received a message from just a domain.
If we produce a "dog", call it a "dog", and everywhere document "hey, this
is a dog", if the public insists on calling it a "cat" well, what can we do?
What level of engineering skill can overcome something like that?
As this mechanism by itself does not prevent forgery, it is misleading to
describe this as an anti-forgery mechanism.
Well, one needn't (a) assert "this is a solution to forgery" - I'm aware of
nowhere that such a grand claim is asserted or (b) require total prevention
in order to claim that a mechanism makes progress against the problem. One
needn't totally prevent a problem in order to make positive strides against
it. Is this a correct statement?
A reduction in the possible sources of forgery does not assure a
reduction in forgery.
Good point. Ok, I'll take a reduction in "possible sources of forgery" then
please and so will all my domain owner friends. That's fine with us :)
I find this language over-reaching and unrealistic. The signature only
verifies an accountable domain, anything beyond that is conjecture. By
sticking to this language, the group may find themselves chasing after
some holy grail and end up with nothing.
And by ignoring it do we not risk producing a specification that has
practical value only when a valid signature is present thereby ignoring the
interests of domain owners? If this is the goal, fine. In my view, we
needn't chase a holy grail - we need only define a DKIM-specific policy
mechanism - look, we have draft-allman-dkim-ssp as a head-start.
What is wrong with establishing an accountable domain?
Nothing. This is a good thing. Now a question for you: What is wrong with
asking the domain owner who's name is being used in the FROM whether it
allows "accountable domains" or not? Nothing. This is totally logical to
do.
This accountable domain may be bound to other headers within the message
by independent mechanism that are beyond the scope of DKIM.
Should I read your statement as a proposal to strip DKIM of it's SSP related
components? Would we still have DKIM if we did that? I guess we would
because the definition of DKIM will be whatever this group decides it should
be.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org