ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] The mystery of third party signatures

2009-10-06 18:41:58
On 10/6/09 1:46 PM, Michael Thomas wrote:
On 10/06/2009 10:30 AM, Bill(_dot_)Oxley(_at_)cox(_dot_)com 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