James A. Donald wrote: > > In order for [DKIM] to actually be any use, the > > recipient needs to verify the signature and do > > something on the basis of that signature - > > presumably whitelist email that genuinely comes from > > well known domains. > > > > Unfortunately, the MTA cannot reliably do something > > - if it drops unsigned mail that is fairly > > disastrous, and the MUA cannot reliably check > > signatures, since the MTA is apt to mess the > > signatures up.
Anne & Lynn Wheeler wrote: > so what if an isp only signs email where the origin > address is the same as the claimed email "from" > address. > > then email that claims to be from such an isp, that > isn't signed, might assumed to be impersonation. Then you get into the same problem as with SPF. Obviously the problem can be solved, it is not even hard to solve, but the solutions we have now do not actually work. > ISPs could do ingress filtering where they only > process incoming email from their customers ... There are lots of excellent, and reasonably simple solutions, that work if everyone alters their behavior except for a few wicked malefactors, and all software is fixed up so that it works with the new solutions, but the solutions that are actually under way right now do not work well when there is a mix of old and new software, and old and new practices. In order to get to the end state where email is secure, each step along the path has to be in the interests of the individual making the change. It is easy to imagine an end state that is better than what we have now. The trouble is that part way to the end state also has to be better than what we have now. We need a solution that is good for the individual to implement right now, and also solves the problem if most people implements it - has increasing network effects. > ISPs could also start to quarentine unsigned email > that claims to have originated from ISPs that are > known to sign email. But, in practice, domains cannot control the behavior of people who legitimately use that email domain name, so people do not in practice follow the sender policy framework. If an ISP drops mail that violates another ISP's sender policy framework, it is intolerable, because most of the mail dropped will be legitimate. Filtering has to be done client side, where the client can judge what is good for him, what works for him. The solution is for the recipient MTA to add all the authenticity information that it can get into the mail headers, and for the client side filtering software to pay attention to these MTA headers - but that is not the solution we have. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]