North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Economics of SPAM [Was: Micorsoft's Sender ID Authentication......?]
[email protected] wrote:
On Thu, 09 Jun 2005 17:40:55 PDT, Matt Ghali said:So you see, the reputation has nothing to do with your mom, and everything to do with the controlling entity, her ISP. Which makes the whole address-based sender reputation scheme almost workable, if you ignore the scaling issues.
Exactly. Everyone in the SPAMwar has to be aware that SPAM can't be stopped until its transaction costs approach that of the cheapest other advertising method. That can be snailmail spam, telephone terror^Wmarketing, whatever, you name it. SPAMmers will do whatever is economically feasible to send their SPAM. If this includes commanding zonbie armies they will. If it includes hacking real mailserver with good reputation they will. If it includes buying IP space they will. You have to manage to lower the reputation of that host within a very short amount of time to increase the transaction costs sufficiently for the spammer to make the effort worthwhile. On the other hand you make the life for the hacked mail server miserable. And if you let the reputation of a host bounce back to fast spammers will use it by schedule. Spam for two hours today and again in two days and again and again. The current Internet email system is an open system because SMTP was built that way. Note that there can't be any other 'rewrite' of SMTP that fixes the SPAM problem and remains open at the same time. It follows that all the chatter that SMTP is broken is false and misguided unless you want a closed system controlled by one entitiy. Everything that can be done to keep the SPAM problem in check (fixing is impossible by definition): 1a) must be simple so that many million server administrators can understand it. 1b) must scale to millions of legitimate mail servers. 1c) must not break common functionality for users. With high probability there is no one (complex) system fulfilling all of these point at the same time. In all likelyhood it can only be achieved by a combination of simple systems/mechanisms each tailored to deal with a specific part of the problem. This kind of approach not only scales on the deployment side but also on the time line. Spammers adopt and will change strategy as they have done many times in the past. The options we have are: 2a) forward DNS based information (reverse MX information). 2b) reverse DNS based information. 2c) blacklisting. 2d) whitelisting. 2e) cryptographic signatures. Each of them can contribute to a different part of the problem and none of them can fix the entire one. IETF MARID tried to stuff too many things into one of the above systems and failed. Each of them has its own unique advantages and disadvantages and tackles the problem on a different layer and is under different administrative control. Now create a specific (sub)problem description, select the approriate option from above and specify a *simple* and easily understandable mechanism to make use of it. -- Andre [Info: I'm one of the authors of qmail-ldap which is a large-scale clustered mail server software used by ISPs as Speakeasy.net in the US and India's Rediff among others]