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 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Sunday, April 02, 2006 1:04 PM To: Barry Leiba; [email protected] Subject: Re: [ietf-dkim] Proposal for specifying syntax andsemanticsformultiple signatures ----- Original Message ----- From: "Barry Leiba" <[EMAIL PROTECTED]> > 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
