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
(again,
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 of
scenario, there is no way to externally distinguish between mail actually
sent by the vanity domain owner and mail sent by another customer of
isp.example.com
The DKIM signature is a statement by the administrative domain that
it accepts responsibility for the message. It doesn't say anything
about you.
One of the features of DKIM is that your domain is standing up for
you, the end user. You're just a user.
As I said, the issue here is the small domain holder sending through a large
ISP server.
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.
Sure, but if you send mail through your ISP's mail server you certainly want
to make sure their other customers can't do the same with your domain name.
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?
I'm not sure yet. At this point we're just talking about requirements and if
this type of requirement is covered through policy or not.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html