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
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 Tim Draegen
Sent: Thursday, September 21, 2006 3:27 PM
To: dcrocker(_at_)bbiw(_dot_)net
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