On Sun, 7 Mar 2004, Vernon Schryver wrote: > (Recent example technical issues: > SMTP-TLS does not imply commericial PKI, except in the sense that > commercial PKI is the only working(?) model of large scale key > distribution. > No law, standard, or anything else prohibits an SMTP relay from using > the same authenticator on output that it used on input for a message.) Sorry to inject specifics into a meta discussion, but the above is technically wrong. Mathematical reality imposes some prohibitions. All the realy has is the certificate and the public key. It will not be able to reuse that without the private key, and it won't be very likely to compute the private key. So the relay can't use the authenticator given by the client for exactly the same reasons that you can't have a transparent https proxy. If such a proxy were transparent, it would be able to pose a man-in-the middle attack. SMTP-TLS has a role to prevent snooping the message during some transfers. The most significant threat to SMTP snooping comes from the users' shared LAN or shared cable connection. TLS is especially useful during such initial transfers to the relay, which has more controlled access to the internet. However, this has no anti-spam benefit. The authenticator certificates (TLS can be anonymous, but we'll assume for sake of argument that they aren't anonymous) would be given out by the ISPs just like regular user accounts. We already know that spammers/abusers will use stolen or disposable user accounts. PKI isn't an anti-spam solution, except for very small groups who leverage the non-scalability and lack of widespread use of PKI to their benefit. But in those cases, it isn't the PKI that is operative, it is the non-scalability that is operative. Simply by creating a "secret" header, which only their small group knows, they obtain the same solution, which has the same scaling properties. That is, if the "secret" is widely known, then spammers may learn it. Similarly, if every residential ISP gives certificates to every user, then spam will come signed by those certificates, either disposable or stolen. A comparable solution is to setup a private network that doesn't connect to the internet. But we don't see online services disconnecting from the internet, or just blocking all email from the internet. While disconnecting from the internet would perhaps block a lot of spam, it isn't what the users want or purchased. Indeed, if the online service is large enough, it will still have a spam/abuse problem. As I've said before, the problem is essentially identical to that of covert or sneaky channels in Information Theory. But I have some hopes that nearly all spam/abuse is sent by a relatively few miscreant script kiddies. I see that the first CAN-SPAM civil case has been filed. This will certainly be interesting. I expect that once these script kiddies have been caught and properly punished, that the spam/abuse problem will be reduced to the "norm" of other anti-social behaviors, and that things will drop back to less than 1% of mail being abusive. But the question of punishment is partly upto the technical community. If we keep giving script kiddies jobs and promotions in spite of abusive behavior, then we'll keep giving positive reinforcement to the script kiddie behavior pattern. The best thing we can do is make sure that such activity is career limiting. It is no different from the accounting scandals and insider trading scandals. If the participants are hired back into responsible positions with pay raises, then there will be no incentive to have honest executives or auditors. Nearly all of the spam abusers that I've caught have been IT people or administrators who work (or worked) for ISPs. Some have been caught and fired. Others have been caught (or abuse traced to a ISPs non-customer network--where a call to said ISP results in a yell to someone to "knock it off"), and their activities essentially ignored so long as they stopped. That is really the wrong message, and the abuse will no doubt continue. In most such cases, they just stop temporarilly, and when they think the "heat is off", they start doing something else abusive. P.S. I said last week that we get relay abuse whenever I defend the uses of open relays. Well, on schedule, we had two relay abuse attempts this weekend from Tiawanese proxies (haven't had a relay abuse attempt for some time). Something over 20,000 messages from the first one, and I haven't looked at the report for the second, but I'd guess its about the same. All abuse was blocked. It is always interesting to review the recipient list of such abuse. A funny thing about this case is that the very first recipient was a jmahler@xxxxxxxxxxxxxx, and nearly all of the rest were to .tw and .cn addresses. So, was jmahler@xxxxxxxxxxxxxx the abuser? or just a known target of the abuser? Perhaps it is just a bogus address that would tell the abuser (if at starnetinc.com) that the relay abuse was successful. Admins at starnet would get a bounce or a log entry if we try to deliver the message and the address isn't valid. I've also had some previous conflict with Starnet admins regarding the uses of open relays, and we've had abuse originating directly from starnet after/during that conflict, so it is quite possible that it is a starnet admin. Googling this address turned up nothing. If it is a real user, they don't post to any indexed mailing lists. Though, I suppose I should also google "jmahler at starnetinc dot com" (Another stupid anti-spam tactic; like web robots can't parse that into an email address). Without logs of the proxy, we can't tell where it came from. But we do know that the abusers are listening to the IETF list. They are probably employed by companies that participate in the IETF. We also know that such abuse isn't commercial, as some naively assume. The solution to a social problem is basically social: Companies have to fire abusers, and make sure that abuse is a career-limiting move, just like was for dishonest auditors. --Dean