Thomas, The draft specifications, the official SSP-02, and the additional WG document, DSAP-00, look at this as a way to verify consistency in the signing process. It is more like a "permit" or signature authorization concept than anything else.
I have been researching all this from an product implementation design feasibility standpoint. Original Signing: - Why should add DKIM signing support to our product? - What is it going to offer customers? - How do we sell (document) it to them so that they use it? - Which groups of customers need it? How so? - Where do we add it to our framework? - How does it work with our add-on products, i.e, List Server? Verification: - Where do we do the verification? Transport or post reception? - How does it integrate with existing email protection technology? - How does it tie in to existing authorization submissions? - What is the payoff? Success vs. Failures? - What are the loopholes? Resigning or 3rd party signing: - What are the reasons for resigning? - How does resigning effect the traditional "Do not alter" passthrus? - How does resigning effect the original signing? - How does resigning effect verification process? - What are the loopholes? Etc, etc. As much as I like DKIM with its promising proof of concept, I am not convince its promotion has been handled correctly and it risk being damaged and not widely adopted by incorrectly selling the idea its a transparent Digital Message Signature (DMS) protocol "passthru" concept with vague ideas about assigning responsibility and accountability but short on who IS suppose to interpret these responsibility and accountability ideas, from signer, to verifier to middle ware processes as well. SSP to me is very simple: At a minimum it is about confirming the physical attributes of a domain message with or without a DMS. It is about the detecting the MOST obvious of failures. To me, that is the BEST we can do today. Neither SSP and DKIM-BASE can address - near-domain phishing - Compliant Bad Actors -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Thomas A. Fine" <[EMAIL PROTECTED]> To: <[email protected]>; <[email protected]> Sent: Monday, September 11, 2006 11:04 AM Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION > Wietse Venema wrote: > >Criminals switch strategy, and use look-alike domains to make their > >mail look even more authentic than it does today. > > > >If this is how SSP stops phishing mail, we have achieved nothing. > > I can NOT stop burglaries, but I still have locks on my doors. But > SSP is BETTER than a lock: > > Currently, I can receive mail that looks exactly like it is from > an organization that I do business with, and only through careful > inspection can I determine that something might be amiss. > > With SSP, I can only receive mail that looks ALMOST like it is from one > of my orgs. This is huge. This gives the user layer the ability to > quickly, accurately, and precisely differentiate between fake and > real messages. That's what SSP accomplishes. > > As far as what happens in the user layer, no specification can control > that. We can certainly predict that a significant number of people > will still fall for look-alike domains. But this is vastly different > than people falling for the exact valid email address they were > expecting. What are we here for if we aren't here to fix that? > > tom > _______________________________________________ > 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
