The new found unchecked DKIM junk will always be with us.
DKIM base is not about determining acceptance policy, its about
identification of where the mail was handled last. SSP is an
authentication methodology, not part of the base.
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Sunday, April 02, 2006 1:04 PM
To: Barry Leiba; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Proposal for specifying syntax
andsemanticsformultiple signatures
----- 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.
<chair>
In particular, any attempt to include that sort of information in DKIM
is explicitly out of scope for this working group.
</chair>
Barry
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
important consideration.
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
signing questions.
See
http://www.winserver.com/public/ssp/ssp.htm
Hopefully this will make some sense.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html