[ietf-dkim] The mystery of third party signatures
doug.mtview at gmail.com
Tue Oct 6 15:38:37 PDT 2009
On 10/6/09 1:46 PM, Michael Thomas wrote:
> On 10/06/2009 10:30 AM, Bill.Oxley at cox.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.
More information about the ietf-dkim