[ietf-dkim] Re: Responsibility concerns with DesignatedSigning
dotis at mail-abuse.org
Sun Aug 27 05:04:42 PDT 2006
On Sun, 2006-08-27 at 08:20 +0200, Frank Ellermann wrote:
> Douglas Otis wrote:
> > The problem of look-alikes will only grow worse and is not
> > prevented by taking away everyone's freedom.
> Some of them are receivers, we want a common subset of DKIM
> functions working similarly for receivers supporting SSP, and
> others not supporting SSP. Unilateral delegation is odd.
The word designation was used for a reason. This is not taking anything
away the authority of the signing domain, nor is this being done
unilaterally from the perspective of the 2822.From address domain. A
domain designation does not impact the signature at all. A designated
domain may affect the message's annotation or refusal when this permits
more aggressive exclusivity assertions. In other words, the 2822.From
domain is better protected from fraud when they prefer for economic or
convenience considerations to allow someone else to sign their messages.
> John's comparison with a Turing-complete path registration
> scheme comes to mind: Limited to at most 10 lookups it's in
> practice harmless, and limited to CIDRs + mx (without colon)
> + a (without colon) + include + all it would be perfect.
You should review a draft where this assumption was tested.
Unfortunately, many of the libraries neglect applying even the suggested
limitations, and a notable exception where a reduced limit causes
unpredictable results for some domains.
The straw-man proposal regarding the designation concept is at:
You should note that of the three flags, only two will likely ever be
used at a point in time. There are two categories of listed domains.
a= lists domains where the 2822.From address is assured.
d= lists domains where the 2822.From address is not assured.
Either of these lists could be infinitely extended by using a single
query in the form:
The latter d= list might be used to to mitigate some of the damage
occurring from an assertion of all messages being signed where specific
exceptions are desired.
> But as soon as folks are forced to "emulate include" (because
> the relevant ISP has no policy) things start to get messy as
> far as that's possible within the overall limits. "Emulate
> include" (SPF) is very near to "unilateral delegation" (SSP).
A far safer approach to emulate an SPF mechanism would be to use the
same approach as suggested for the designated domain. The query would
> > One might assume this process also applies a block-list of
> > known problem addresses as a best practice.
> The dnsbl draft is in limbo at the moment, from an "IETF last
> call" POV block-lists might not exist "officially". Maybe we
> could adopt the ASRG draft and publish it as DKIM document (?)
There is ongoing work to provide this service.
> > Sorry, many ISPs may decide to ignore DKIM altogether.
> No problem, a minor point in the security considerations of an
> authentication header field RFC. MUAs might need to know what
> they get.
> > Perhaps the i= syntax should be revisited or something.
> The i= syntax is apparently fine, unless you want a mandatory
> local-part with default postmaster (?). The i= semantics is
> less clear.
There are alternatives to using i=syntax. This could be some added
parameter added to both the key and the signature field making a rather
2822.From address is assured valid.
This would provide clearer semantics and overcome i= syntax limitations
regarding outside domains.
Wietse's concerns with non-matching signatures is solved by treating the
a= list as a d= list member and thereby avoid resulting annotations.
Two distinct annotations would be the preferred solution, however.
Those advocating DKIM should not expect all 2822.From domains will be
signed by the same domain, whether from a mailing-list or a large ISP.
Allow designations to say "this is really still me". Or perhaps "I use
The use of a d= list is not very ideal, where an a= list offers
information valuable to the recipient. This removes the need to ask,
"Is this your new signing domain?"
The issue of reputation is out of scope, but is getting reviewed as a
concern that by adding information, this makes assessing who the actors
are more difficult. Only the signer identity can be verified, and only
the signer can safely be held accountable. Simple. Just as a provider
may allow their users to use their own email-address going through their
service, a designated domain represents an exact analogy to this
More information about the ietf-dkim