>In sum, I think the SSP-req doc should say "SSP must be published > by DKIM signers, and the format is <this>".
Disagree, dkim base works now. There will be people that will move very slowly into implementation and requiring SSP to be implemented at the same time will slow adoption. 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 Tim Draegen Sent: Thursday, September 21, 2006 3:27 PM To: [EMAIL PROTECTED] Cc: DKIM IETF WG Subject: Re: [ietf-dkim] New issue: What is the purpose of SSP? {3.5} {3.5} Dave Crocker wrote: > Michael Thomas wrote: >> I think that the interesting meta issue here is that DKIM >> verification does not require this; SSP requires this. I hope that >> there isn't confusion about that because the two really are >> severable. > > I am glad you raised this. It encourages the basic question about the > relationship between SSP and DKIM? > > For example, are there reasonable SSP features that do not involve DKIM > at all. (Answer, "I send no mail" is a prime example.) > > Note that "I send no mail" has nothing to do with signing, in which > case, the middle S of SSP is overly constraining. I would like to elaborate on this point. I'm more comfortable with working with use-cases, so I'll present my ideas in such a format: - Mega-ISP wants to deploy DKIM. Someone told them it stops spam, dries up phishing spots, and somehow prevents spy-ware. Whatever, sales guys at work. - Mega-ISP uses my appliance to sign. The on-box helper walks the admin through the necessary steps: 1. Create config tying together selector, domain, streams of email to sign.. admin clicks "done". 2. Sample DNS records (in a number of popular formats) are sent to admin's email account. XXX do we include SSP record for this domain? 3. Admin adds records to DNS. 4. Back on the appliance, admin clicks on "Click to test". Everything checks out, and the admin knowns that stuff is basically up and running (no typos in records, etc). XXX do we test for SSP record? 5. Admin then spends the rest of the afternoon using scripting language of choice to automate the process. Next day, Mega-ISP offers "Premium Email ID Protection" add-on to customers. - Mega-ISP wants my appliance to verify DKIM signatures. 1. Admin clicks on checkbox "I want to verify DKIM signatures". 2. A new filtering bit becomes available, "verified good". 3. Admin delights in the power of writing filters like: A. "if email-is-DKIM-good and sender is PayPal, skip phish-philter" B. "if email-is-DKIM-bad/absent and sender signs all/most email, do the phish-philter" 4. Admin calls me and complains to me that filter 3-B just adds overhead. 5. I convince the admin that my reputation service is doing something useful with DKIM results. Instead of filtering on DKIM-good and whitelisting, perhaps customer wants to participate in reputation sharing. 6. Admin deletes filters and checks "Share DKIM results", These results become a small piece of a much larger picture. No white/black-list is maintained ever again by admin. Although my appliance makes things EZ-mode, I think this use- case scales to the DIYers, too. My main points wrt this effort: a. Signers MUST publish a SSP record. Its easier for me to say "you must publish this record, please do it" if the stone-tablet in IETF-land says so. b. Verifiers should be allowed to function without any need to query an SSP record. In my case, my 3rd-party reputation agents will be doing the tracking of SSP records. For whatever reason, I'll have customers that want to do it themselves, and I'll expose that functionality. In sum, I think the SSP-req doc should say "SSP must be published by DKIM signers, and the format is <this>". I guess some sample scenarios on the verification half can be described, but I think that just adds confusion, and would be mostly wrong anyway. FWIW, =- Tim PS. The "I send no email" thing could be useful. I'd use it to inform network owners that despite the fact that they "send no email", some IP addresses assigned to them are in fact sending mail. Just make "SSP" generic enough to be "SP", and I think we're good to go for at least a few years. _______________________________________________ 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
