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
