ietf-dkim
[Top] [All Lists]

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

2006-09-21 13:04:45
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

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