Oh? I thought the DKIM charter specifically declared Reputation out of
scope. Of course, it was written with enough eye winks, one might think one
was making a pass at you. :-)
IMTO, sender rejection is exactly how its going to be used because the of
massive DKIM abuse I predict will happen - purely based on the erroneous
presumption that people are going to accept errant payloads sans scrutiny
and bad actors will use this as a basis to perform blitz attacks. Its
DKIM is based on a "GOOD CITIZEN" model with an intentional neglect and
ignorance of the #1 one problem - bad transactions and failure analysis.
These concerns were described in:
Check out the REJECTION model!
Whatever, it doesn't matter. :-)
----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
To: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
Cc: "John Leslie" <john(_at_)jlc(_dot_)net>; "Frank Ellermann"
Sent: Tuesday, October 31, 2006 3:57 PM
Subject: DKIM and authentication (was: Re: Anything else on the content?)
--On Monday, 30 October, 2006 14:57 -0800 Douglas Otis
One more note supporting the concept of a mechanism for
A DKIM signing-domain should relate to the sending entity to
beuseful at reducing abuse. The entity held accountable by
their IPaddress should receive relevant abuse feedback
validated by the DKIMsignature. Thus the DKIM signature may
typically not match the2822.From or the 2821.MailFrom where an
association mechanism can beused instead. As a DKIM signature
can be replayed, DoS protectionsare found by an association of
the SMTP Client with the DKIMsignature. Messages where the
SMTP-Client/Signing-domain && Signingdomain/MailFrom can not
be associated, then acceptance should be on alimited basis.
The limitation could be rate limiting for example. An
association mechanism also removes any need for private keys
orDNS zones to be exchanged between domains.
While this is interesting as Dave points out it is probably not
the right place to debate it. However, I feel obligated to
point out that you are on a slippery slope relative to the
promises made to the IETF when the DKIM effort was chartered.
Those promises clearly stressed that DKIM was appropriate as a
reputation check by the delivery MTA or target user MUA, but not
as a means of authenticating senders and rejecting mail in
transit. I think the above, in the context of the note that
apparently stimulated it, comes very close to assertion of
precisely that sender authentication and, potentially, rejection