[ietf-dkim] The URL to my paper describing the DKIM policy options
jon at callas.org
Thu Jul 27 15:31:26 PDT 2006
> 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.
The DKIM signature is a statement by the administrative domain that
it accepts responsibility for the message. It doesn't say anything
One of the features of DKIM is that your domain is standing up for
you, the end user. You're just a user.
Now then, there are some issues that do affect you. Some
administrative domains (pick any big one: Yahoo!, AOL, Gmail,
Wanadoo, etc.) will be large enough that statistical effects happen.
For example, if you get enough users in a domain, statistically, at
least one will be a bad actor. That will tend to lower the reputation
etc. of the domain.
Some small domains (I'm sending from one) are unlikely to have bad
actors. Note that I said unlikely. It's still possible, even if I am
the only user in my domain that I'll get hacked and some malware will
send something untoward. That has consequences.
> This is really an internal ISP operational problem (they need to
> sort out who
> is allowed to use what identities on their servers), but the
> protocol and
> associated guidance need to make that clear.
How is it not clear now?
More information about the ietf-dkim