On 10/6/09 1:46 PM, Michael Thomas wrote: > On 10/06/2009 10:30 AM, [email protected] wrote: >> C) I can sell the ability to do 3rd party DKIM signing for those companies >> who are described in A) > > If you're getting paid for signing somebody else's traffic, doesn't > it make sense that the service can do some hand holding to get their > DNS set up correctly? In fact, if you're handling their DNS too > -- which seems likely on average -- what exactly is the problem?
Your option of helping each customer publish a public key or a CNAME reference to a public key in their DNS also requires ongoing maintenance when keys roll over. It would also mean messages signed by third-party DKIM providers will appear "as if" signed by their customer's domain rather than by an authorized provider's domain. In addition, for each of these messages, specific selectors and domains need to be inserted into each customer's message. A simple and static hashed "authentication" record could be applied by customers at their leisure _without_ modifying how third-party DKIM providers sign their customer's email. Use of a hashed authentication record allows all messages to receive the same signature, where there would be no transitioning concerns with respect to when a customer's DNS server synchronized with that of the provider's key references. Extracting cost for this service could occur when allowing customers the use of their own domain in From headers. After that, no hand holding or DNS publication coordination would be required. Another benefit could include an easy ability to authorize mailing-lists that modify messages. Such authorizations could be added and removed without affecting the operation of the outbound MTA or the mailing list. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
