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
