----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Again, I'd like to hear more voices, so that we can figure
where the consensus lies.
I prefer to go with the proverbial Engineering/QA motto:
"Getting it right... the first time."
I think too much has been made of the early adoption of a DKIM-only system
that is obviously premature in its engineering that will most certainly have
a higher cost in implementation and obtaining effective results. We are
talking about what? 5-10? early adopters? which is really just based on the
1-3 source codes (think about that single sourcing), out of what potentially
hundreds of millions of domains in a widely adopted network?
My input is basically to place more consideration on the #1 victims of this
protocol: the receivers. They are the ones that are going to be have to
make some real big decisions on how to best handle a potential "new found"
avalanche of DKIM-signed messages
If we were to consider the TCO of DKIM, it would easy to show how the
current model is more expensive when it fact, it doesn't have to be.
Current model:
TCO(DKIM1) = TCO(HASH-BODY)+ TCO(HASH-HDR) + TCO(SSP)
The order of the processing above is important.
The more optimal model when considering order is:
TCO(DKIM2) = TCO(SSP) + TCO(HASH-HDR) + TCO(HASH-BODY)
There is doubt in my mind:
TCO(DKIM2) <= TCO(DKIM1)
The reasons are straight forward:
- SSP processing offers short circuiting of remaining
processing overhead
- HASH-HDR processing offers short circuiting of remaining
processing overhead
and so on.
So think of the verifiers. Signing is the easiest part.
Get it right. The cost will be much higher later cleaning up the "mess"
later.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html