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