----- Original Message ----- From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
> The limitations of specifying the relationships between signing- > domains and email-address make SSP impractical. Once SSP is > attempted however, one can expect that compliance will be coerced > where everyone must give up on seeing the email-address be > independent of the signing-domain, and where many things break. You have a very verbose way of saying that a Sender Authorization Framework is the way to go here, a "Chain of Trust" concepts across the board. What I think you fail, no, choose to ignore, no, forget?, whatever, is the issues of compliancy. As a SMTP vendor, how am I going to support backward legacy issues? It really doesn't matter what method is invented, in the end, the issue of backward legacy issues is still a major problematic issue. I see DKIM is a relative simple "addition" that can raise the bar for DOMAINS who want to assure that their DOMAINS are not used outside their authorized SENDER network. SPF is the same idea, DKIM does it differently. The key, which is what I think you realized is strategically competitive to your DNA service ambitions, is that DKIM can work really well by using a lookup concept, not to a REPUTATION system, but to the DOMAIN policy statement. I think you are concern this will reduce the need for reputation systems. I don't think you have anything to fear because it might be required for RELAXED DKIM provisions, but as a independent feature, not dependent feature for DKIM. What I was trying to explain is that if this is the case, and I don't argue against it, is that inevitably, it brings you down to a 821 level. Reputation will trump DKIM and if we want to go down this route, then DKIM is really not necessary. But then we get into the marketability and the asthetics of the "reputation" concept. I don't think it plays very well in the open-standard EMAIL infrastructure. It is very difficult to sell an "add-on" feature that will have any cost associated with it, and even if there isan't a cost or there are plenty of free systems, then you have a dependency issue of waiting for this to happen and you also run into even more reputation problems for the reputation system itself. Case in point: DNSRBL In the beginning, we used your fine MAPS system. But then you went commercial. This created a PR and Marketing problem for us. I didn't have a real problem with it, but now we had to change our software to make it list based so the sysop can define the RBL sites. At first, there was only 1 good free system, relay.osirusoft.com. But then he feel victim in the now famous SORBIG dual attack of bringing down RBL sites and injecting BOUNCE attacks into the network. What did the osirusoft.com do as PAYBACK? He rejected EVERY request. Mail was being lost all over the place. Now we have to find new sites to offer to customers, etc, etc. Today, it has all stabilized with some reliable sites and by default, we offer: CheckRBLSite sbl.spamhaus.org CheckRBLSite list.dsbl.org CheckRBLSite bl.spamcop.net but we had to couple it with a smart site order lookup timing algorithm concept in case any of those are down or are SLOW to react. I don't know the sales business model for MAPS. I'm sure it is successful, but I don't think you can propose this or anything close to it for a standard operation in an open-standard world wide INTERNET mail system. Even then, do you think you are going to convince people like me, including operators that they should abandon DNSRBL lookups. I don't think so. That's my opinion, not necessarily because it doesn't have technical merit, it does, but because it is full of secondary and tertiary issues. Again, just my input on the matter. I think it will hurt the DKIM process if is becomes a basic requirement. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ ietf-dkim mailing list http://dkim.org
