Subject: [ietf-dkim] Summarizing the small/non-technical domain owner scenario

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Jul 2006 16:09:44 -0400

Since I brought it up, I'm going to try and summarize the results of the 
discussion/requirements/options for this class of user....

There are a large number of domains that only send mail through shared third 
party services such as ISP or domain host MTAs or shared web servers.  DKIM 
(including base and SSP) should provide for this class of domain to use DKIM 
on par with larger or more technical domains that send mail through dedicated 
resources.  Since these owners of these domains have few technical resources, 
setup and operation should be as simple as is feasible for them.  This is 
particularly true since DNS services are also usually provided by a third 
party that is quite commonly different than the third party providing MTA 
services (often the name registrar).

The simplest option would be for the mail service provider to sign with their 
key and depend on non-standard reputation services and the reputation of the 
mail service provider.  This puts no administrative burden on the domain 
owner, but is dependent on non-standard services and the mail service 
provider's ability to maintain their reputation.  This is not radically 
different that today's situation where these domain owners are dependent on 
mail service provider's ability to keep their IP addresses off of RBLs.  This 
approach places no requirements on the policy protocol, but offers little to 
no advantage to these domain owners from DKIM.

The next most complex option without policy implications would have the mail 
service provider give the public key to the domain owner to publish in their 
domain's DNS.  The mail service provider would sign the message using the 
domain's name rather than their own, making this a first party signature.  As 
long as the key is stable, then while this requires an initial setup in the 
small domain owner's DNS, it should require little maintenance.  A downside 
of this is that it shifts the taking responsibility part DKIM from the mail 
service provider and to the small domain owner.

An alternative approach would be to have the domain owner create the key and 
give it to the mail service provider.  This would be substantially more 
complex for the domain owner and not offer any particular advantages.

The third option (the one with policy implications) would be for the domain 
owner to publish a policy (but no key record) listing the mail service 
provider(s) authorized to sign for them.  This would require a one time 
publishing of a policy record, but no maintenance unless the domain owner 
decided to change providers.  This approach would, if the domain owner wished 
to absorb the practical implications of it, allow small domain owners to 
publish a closed policy record that would allow receivers to determine which 
messages had been authorized with no resort to non-standard reputation 
services.  Additionally, reputation services could, in this approach use a 
combination of the signing domain and the From domain to extract a domain 
specific reputation that might be significantly different than the reputation 
of the signing domain alone.

I don't know for certain which of the options will be the one that is most 
commonly exercised operationally, but I think that we ought to allow for the 
policy based option as a design requirement (with, of course, no guarantee 
that the final design will support all requirements).

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