[ietf-dkim] linkage between "originator" and "handling agent"
ietf-dkim at kitterman.com
Wed Aug 17 07:18:54 PDT 2005
Douglas Otis wrote:
> On Aug 15, 2005, at 6:09 PM, Dave Crocker wrote:
>> Equally I am wondering whether it is not distracting from the core DKIM
>> authentication work to emphasize this particular requirement prior to
>> deployment of a signing/validating mechanism.
>> In other words, it is starting to look as if the mechanism for enforcing
>> originator/handling linkages needs separate focus from techniques for
>> performing authentication.
> There are two ways to look at DKIM goals-
> 1- A mechanism that provides an accountable domain for the message.
> A number of features are available as a product of the accountable domain.
> a) reputation accrual
> b) directed abuse reporting
> c) IP address independent basis for message acceptance
None of which relate to preventing forgery.
> 2- A mechanism that is able to optionally constrain the use the From-
> a) debunk spoofed messages
I don't think debunk really captures it. I think we are after a
mechanism to allow receivers to determine if the sending domain (yes, I
know that's an amorphous term) is willing to state the the message is
> A natural outcome of any method that provides a strong message
> identifier would be related to reputation. Whether this feature is
> expressed in terms of abuse prevention or not, this will be a principle
> use. As a result, there should be considerations given how this may be
> abused by miscreants. This being a goal or not, when DKIM is expressed
> independently from the optional domain-assertions, it becomes difficult
> to distance the DKIM mechanism from this aspect of email handling.
> Once there is an accountable domain established for a message, as an
> option, some want to bind the accountable domain with the From- domain.
> This is not directly a product of DKIM, but rather that of a
> domain-wide assertion. There are several who embrace a concept of
> constraining the use of their domain name through domain-wide
> assertions. This has been a common theme. There is more than one
> email related application where such assertions could be applied, which
> suggests this should be kept separate, as it also tends to be
> expensive, at least initially.
Certainly it _could_ be kept separate. I expect that doing so would
sharply constrain the value of DKIM as a complete product.
> To clarify basic elements involved in DKIM, versus expressing domain-
> wide assertions, these two efforts should be independent. This would
> ensure a flexible language is used to express these two highly
> independent functions.
I'm sure it isn't affecting the views anyone is promoting here, since we
are all acting as individuals and not as representatives of any
particular corporate interest, but it does occur to me that perhaps such
an approach might make DKIM dependent on reputation products to have
value to receivers.
One might, I suppose, make the arguement that the policy linkage between
the sending domain and the DKIM signing domain is really a form of a
very narrow reputation service. So, on that note, you might be right,
but then where's the value in DKIM signatures alone? Is it sufficient
to merit a working group? Is it sufficient to garner deployment?
Perhaps if we proceed down this path, what we really ought to be doing
is including reputation protocol that will leverage off of DKIM
signature within the scope of the planned working group. Not that I'm
suggesting we should proceed down this path.
> Alas, I suspect a major reason for resisting the splitting of these
> efforts is that some domain owners have had bad experiences with
> reputation services. Without including the domain-wide assertion, DKIM
> really only supports an aspect of this dark side.
I can't speak for anyone else, but that's not the case for me. I would
say that I'm in favor of DKIM defining a protocol that has substantial
marginal utility on it's own merits. There may be added benifits
associated with combining it with other approaches, but that should be
I do think that DKIM needs to decide if it's just some random signed
identifier or if it has a relationship to reducing forgery. Some have
indicated they see sufficient value in the signed identifier. I don't.
More information about the ietf-dkim