----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
Any decisions about the quality of the message or the goodness of the
source are made by the verifier, POSSIBLY using the information provided
by DKIM as input, but not directly resulting from DKIM.
So you are creating a functionl specification and mandate, to mold local
policy on how to NOT handle the new found unchecked DKIM junk? You got to
be kidding that you will control this market.
In particular, any attempt to include that sort of information in DKIM
is explicitly out of scope for this working group.
I thought we have moved on to SSP? SSP is not out of scope. Correct? I am
referring to SSP to help answer many of these questions being raised,
including this thread about nth signatures and ambiguious mandate on how it
should be "Intepreted!"
It is a moot point what a nth signature means if a nth signer was not
authorized by the domain owner to resign it. For some reason, that isn't an
This DKIM-only simplicity is an extremely harmful mandate to impose on
verifiers, specifically vendors who such as us who need to implement this
stuff and convince customers this stuff has any value or payoff.
I am not just making this up, you know? I am not trying to be ANTI-DKIM,
you know? I want it to work too.
My concern is that we will have a growth DKIM-only systems out there
creating a deluge of high volume invalid, fraudulent DKIM messages with no
controls in place and because of this weak and neglectful half-baked
incremental design approach, we will have two markets to deal with:
- the DKIM-only market with tons of fraud
- DKIM market with some unknown augmented technology only privy to
a few here that isn't here yet.
You guys are mandating a technology that is quite frankly, infested with
flaws. You want to tell us what it means, with what seems to me a careless
attitude or lack of a clear vision (intentionally made vague I suppose) for:
- determining how to clearly implement it,
- what scalability issues will come from it,
- and completely ignore the all error and worst case scenarios.
Where is the error analysis in all this? None!
Where is the system engineering in all this? None!
Sorry, I don't have any misunderstanding of what you or Dave expect DKIM to
be. I understand very clearly what "yall" trying to do. But it is flawed
and dangerous and you have no evidence nor shown any proof to the contrary
to suggest a DKIM-ONLY implementation is going to be safe in a widely
adopted network. I see no consideration in handling predictable scenarios
of being bombarded with DKIM signed mail - good or bad.
I put together some diagrams of a highly efficient DKIM/SSP verifier system
that protects the DKIM DOMAIN owner from exploited usage of domains. It is
based around SSP - a simple consideration that resolves many of the current
Hopefully this will make some sense.
Hector Santos, Santronics Software, Inc.
NOTE WELL: This list operates according to