Subject: [ietf-dkim] Service model options for an ISP

From: Mark Delany <[email-masked]>
Date: Fri, 14 Apr 2006 02:49:30 +0000

On Thu, Apr 13, 2006 at 11:40:21PM +0000, Mark Delany allegedly wrote:
> On Thu, Apr 13, 2006 at 07:10:06PM -0400, [email-masked] allegedly wrote:
> > Jim,
> > So if they use our mta's The signatures would in fact be from cox.com as
> 
> Correct. By signing as cox.com you are accepting responsibility for

Well, that's the short version. The long version is that there are
lots of options.

If we start with the presumption that you're talking about a customer
who has their own domain, the range of options are:

1. Do nothing - assume they will or will not sign as they see
   fit. Your SUBMIT server merely relays the mail closer to the
   destination.

2. Detect whether the submitted email is signed and only sign with
   your domain if there is no verifiable signature. As mentioned
   before, this means that your domain accepts responsibility for the
   email rather than your customer's domain.

3. Arbitrarily sign with your domain. If the submitter has also
   signed, this delves into the multiple signature issue which as does
   not yet have semantic clarity from this group. As with 2. your
   domain is considered responsible for the traffic.

4. If you offer a managed service - that is, you host their DNS,
   perhaps host their MX, etc. - you could also offer the service of
   signing for their domain since you can generate and add the
   Selector to their DNS. To my mind this is the best service model.

   Clearly you'd want to authenticate their submissions, but how you
   do that is a matter between you and your customer.

5. If the customer trusts you, they might supply a private key to
   match a Selector so that you can sign the submissions on their
   behalf.

Mark.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Apr 2006 06:12:19 -0700

>    match a Selector so that you can sign the submissions on their

It's easier than that. The customer merely needs to put a public
key that the esp's signer is using already into their selector,
and then the esp can sign as the customer's domain. This is yet
another manifestation of the "outsourced business" functionality.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Fri, 14 Apr 2006 13:08:20 -0700

> another manifestation of the "outsourced business" functionality.
Agreed.

Yet another option, even if you don't host the domain's DNS, they can
still delegate the _domainkey subdomain back to you.  This gives you the
ability to sign messages on their behalf, and also take care of key
management (rollover, etc.) without any action on the domain's part.

-Jim