[ietf-dkim] The URL to my paper describing the DKIM policy
ietf-dkim at kitterman.com
Thu Jul 27 19:23:00 PDT 2006
On Thu, 27 Jul 2006 16:15:03 -0700 Jim Fenton <fenton at cisco.com> wrote:
>Scott Kitterman wrote:
>> On Thursday 27 July 2006 18:31, Jon Callas wrote:
>>>> If I use isp.example.com and they sign messages with my name and a
>>>> key (theirs
>>>> or mine, doesn't matter) and they also sign messages actually sent
>>>> by joe
>>>> spammer (another one of their customers) with my name and a key
>>>> theirs or mine), then it sucks to be me. That's the problem.
>>> No, it doesn't suck to be you. The first letter of DKIM stands for
>>> "Domain." It sucks to be example.com.
>> To clarify, by me, I meant my domain. The problem is that in this type
>> scenario, there is no way to externally distinguish between mail
>> sent by the vanity domain owner and mail sent by another customer of
>I guess this means that isp.example.com is not worthy of your delegation
>of signing authority to them, and you should shop elsewhere (find a more
>reliable ISP, or sign your own messages). I think the ISPs will get it
>right fairly quickly if they lose business as a result of not
>authenticating mail submission properly (or otherwise fixing whatever
>mechanism allowed Joe Spammer's message through).
Yes. What I want as a small domain owner is the ability to publish a
policy record that say that for mail sent (for some definition of sent that
we will probably have to argue about later) from my domain, the domain(s)
authorized to sign are ...
If/when I switch providers I can change the list. This is the simplest
approach I can think of to put small domain owners on the same footing as
domains running dedicates MTAs. I think from the perspective of the domain
owner it is easier than managing public keys in DNS.
For many small domains, signing themselves will be completely out of reach
due to cost and lack of expertise.
More information about the ietf-dkim