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(_at_)starnetinc(_dot_)com, and nearly all of the rest
were to
.tw and .cn addresses. So, was jmahler(_at_)starnetinc(_dot_)com 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