ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New issue: What is the purpose of SSP? {3.5} {3.5}

2006-09-21 12:31:54
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

<Prev in Thread] Current Thread [Next in Thread>