----- Original Message -----
From: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
Sent: Sunday, July 30, 2006 12:27 PM
Subject: Re: [ietf-dkim] scenarios
It is easy to state a functional "requirement" but it is often difficult
explain why it is needed or to convince people that it is essential to
The easiest way to handle this is to ensure that every functional
explained in terms of a detailed usage scenario, so that the feasibility
urgency of that usage can be considered by the working group.
Quite. Given the range and scope of the alternatives being discussed,
this sure feels like a green-field design environment.
The range and scope are bounded by DKIM-BASE. DKIM-BASE is whats out
there. Now you got to control the possible unprotected behavior of it.
I worry that we may not even have a very good handle on what is
actually wanted in the field, consequently we risk designing something
that targets engineers as the customer.
Well you need engineers to work it out. Who is the customer any way?
Well, that depends on the hat one wishes to wear. t may be the domain, it
may be the verifier, it may also include the end user. It may also include
the infrastructure for the network guy concern about network abuse. It is
also the administrator and so on. From my standpoint, all parties are
the customer and to increase the acceptability of the DKIM protocol, it
needs to offer value to all parties.
My critical concern is the extremely high potential for abuse at the
receiver. For the legacy market or for the market who does not choose or
slow to support DKIM, what the receiver does not know about DKIM, no harm is
done to them. However, those who begin to support DKIM verification, can
easily see the potential abuse of DKIM-BASE is very high.
If the abuse ratio is high, you might find the system will declare it not
worth the processing overhead (as we did with DomainKeys, the failures on
the incoming DK signed mail was overwhelmingly too high).
But I happen to believe we can control the fundamental parts of DKIM-BASE
using signature authorization controls. Watering them down is not giving to
I think not understanding something does not give those who do, those who
has put in the time to help engineer this all out, from a real production
standpoint, the benefit of the doubt.
The SSP interface is actually quite simple to implement. If we go back to
the old mailing list, most of the concern was about redundant DNS lookups,
atleast that was Jim's stated concern.
Let me know if these interface diagram helps:
Hector Santos, Santronics Software, Inc.
NOTE WELL: This list operates according to