UUNET SPAM mini-faq (To be extensively revised.) $Id: uunet.faq.txt,v 1.85 1999/07/15 08:36:07 dhesi Exp $ This mini-faq is available at this URL: http://www.rahul.net/dhesi/uunet.faq.txt Each question is preceded by a [TEXT LABEL] to make it easy to refer people to that specific question. [NOTES] Note 1: This FAQ is about email spam. It does not address Usenet spam. Note 2: 'UUNET' is really a conglomeration of companies in various countries. This FAQ is only about the original UUNET, which began in the USA and whose headquarters remain in the USA. You can recognize the non-USA UUNET companies by the domain names they use, which are of the form .uu.net, e.g., de.uu.net, uk.uu.net. The non-USA UUNET companies have been generally been strongly anti-spam and have always taken steps to keep spam problems under control. It's the USA-based UUNET that is the culprit under discussion. [PUBLICITY] Q. Why is it significant that UUNET shields its spamming customers from adverse publicity? A. By shielding spamming customers, UUNET makes it hard for us to tell which specific UUNET customers generate most of the spam. It's quite possible that some organizations that have developed a reputation for being "good" to the net (e.g., Earthlink) have this reputation only because their own machines don't relay spam. We cannot tell, however, if Earthlink users originate huge amounts of spam that is either direct-to-MX or relayed through third parties. Or consider the possibility that almost all the UUNET spam comes from MSN. But we can't verify this, so MSN is protected from bad publicity. (We don't know if Earthlink or MSN are being bad. These names are mentioned here only as examples of UUNET customers about whom UUNET prevents us from knowing more.) [RESELLERS] Q. But the spam is not really sent by UUNET customers. It's sent by the users of 'resellers', is it not? A. The relationship between the UUNET customer originating the spam and the specific individual who was logged in is irrelevant. UUNET provides access to its terminal servers to specific organizations (who are UUNET customers), and these organizations then authorize specific individuals to actually log in. From UUNET's perspective, it doesn't matter whatever the individual who is logged in and sending spam is an employee of the UUNET customer, or a customer of the customer, or a friend of the customer, or the uncle of the customer. The spamming organization is the UUNET customer. [CONTRACT] Q. Isn't UUNET prevented by its contract from identifying which organizations are sending which spam? A. First: UUNET has had plenty of time (almost two years of ongoing spam) to change its contracts, so you can be sure that whatever the contracts say is what UUNET's management has decided to make them say. Second, I am told that most of UUNET's contracts DO NOT promise to protect any spamming customer from publicity. [MOTIVE] Q. What is UUNET's motive in shielding spamming customers? A. We do not know what the actual reasoning is that is used internally within UUNET to justify its current policies. But we can intelligently speculate. We know that most of UUNET's customers (who use UUNET's dial-up hosts) are ISPs, and we also know that ISPs love good publicity. Therefore it's safe to assume that the UUNET customers who do not want to be identified are the ones who expect bad publicity rather than good publicity. We can therefore conclude that UUNET's policy of shielding customers from publicity is directed mostly towards those UUNET customers who are doing net-unfriendly things, such as spamming and mail-bombing. We therefore conclude that UUNET's policy to shield spamming customers is intended to keep such customers happy and to help ensure they remain satisfied UUNET customers. [SHIELDALL] Q. Is it fair to say that 'UUNET shields spammers'? Isn't it more correct to say that 'UUNET shields all UUNET customers'? A. Both appear to be correct. In fact we can say three different things: 1. UUNET shields all customers 2. UUNET shields non-spamming customers 3. UUNET shields spamming customers From the perspective of those receiving UUNET spam, the only important one is 3, which is why this mini-faq focuses on that. Let's also consider some analogous questions about a hypothetical pro-spam provider called XXX. The reader should think about what suitable answers might be, and how they illustrate the point. Q. Is it fair to say that "XXX provides connectivity to spammers"? Isn't it more correct to say that "XXX provides connectivity to all XXX customers, both spammers and non-spammers"? Q. Is it fair to say that "XXX hosts spam-advertized web sites"? Isn't it more correct to say that "XXX hosts both spam-advertized and non-spam-advertized web sites"? Q. Is it fair to say that "XXX provides connectivity to mailbombers"? Isn't it more correct to say that "XXX provides connectivity to all XXX customers, whether or not they are mailbombers"? [SUBPOENA] Q. I am told that if UUNET is presented with a subpoena requiring it to provide information about a spammer's identity, UUNET will do so. Doesn't this mean that UUNET doesn't really shield spammers? A. All this means is that UUNET's management does not want to end up in jail for contempt of court. [NOMOTIVATION] Q. What sort of motivation do UUNET customers, the ones that UUNET calls "resellers", have for keeping spam under control? A. None so far as we can tell. UUNET ferociously protects the identities of not only individual spammers and mailbombers but also their ISPs (who are UUNET customers called "resellers" by UUNET), so there is no public pressure on these UUNET customers to keep spam under control. Spam victims do not know who these UUNET customers are. And it appears that UUNET as a matter of de facto policy will never disconnect a customer, if that customer is classified as a "reseller", for causing or allowing excessive amounts of spam. Therefore any pressure that UUNET applies on such a customer (if indeed there is any such pressure, which is doubtful), has no teeth. [BIGIF] Q. Isn't it true that *IF* UUNET did not have a spam problem, then its policy of shielding customers would be a good one. A. If UUNET did not have a spam problem, and if UUNET did not have other problems such as mailbombings originating from within UUNET, then nobody except UUNET customers would care about whether or not UUNET shielded its customers. But UUNET does have a spam problem, and those who are the victims of UUNET spam do care. Thus UUNET's policy of shielding its spamming customers is a bad policy. [CANT] Q. I have seen people say that it is technically hard for UUNET to provide any information about which of its customers the spam is coming from. Wouldn't it be better if UUNET spent it resources elsewhere, e.g., in stopping the spam? A. UUNET already has a system in place that takes as input the headers of a spam message, and produces as output information about the UUNET customer responsible for the spam. It's really a policy issue that UUNET won't give us that information. [WHATSPAM] Q. Are you sure UUNET has a spam problem? There are people who say that UUNET originates very little spam. A. The amount of UUNET spam that you see will vary with time and with where you are on the Internet. Depending on the sort of spam blocking done by your service provider and/or your upstream providers, you may see more or less spam. The amount of spam you get will also depend on where your email address is available. If you monitor postings in the newsgroup news.admin.net-abuse.email, you will notice many complaints about UUNET spam from many different people. Over the last two years UUNET stands out as a consistent source of large volumes of spam. No other single service provider has been as significant and sustained a source of spam as UUNET has been and for so long a time. Different service providers have had spam problems on and off, but none has been as consistently bad and as unapologetic. The only other big provider that even came close was AGIS. But AGIS never tried to provide anonymity to its spamming customers, and AGIS eventually reached a turning-point and instituted very effective anti-spam measures. The AGIS CEO himself offered an apology for AGIS's spam problems. No representative of UUNET has ever offered anything even close to an apology. So far as we can tell, UUNET's stand on the issue is that there is nothing wrong with what UUNET is doing. In recent months people have sometimes reported a decrease in UUNET spam. However, it's not clear if this decrease is because of anything that UUNET has done. As more and more sites on the Internet block incoming connections from UUNET's dial-up netblocks, UUNET's spamming users are able to send less and less spam. At some point in time, if the entire Internet blocks all incoming connections from UUNET's netblocks, the incidence of UUNET spam will become very low. This will not indicate any reform within UUNET. We can get some insight into the way UUNET operates by considering what happened when UUNET was subjected to an active UDP (Usenet Death Penalty). After the UDP was imposed, UUNET quickly took steps to decrease the amount of Usenet spam from UUNET, but at the same time it issued press releases that essentially (a) denied that UUNET was responsible for allowing spam, (b) denied that UUNET was reacting to the UDP and (c) tried to paint those imposing the UDP as the bad guys and UUNET as the victim. No apology was ever offered by UUNET. UUNET described the UDP as "Misinformed Group Disrupts UUNET News Service" and said it was going to "turn the matter over to the appropriate law enforcement authorities." [ISPHOP] Q. I am told that UUNET has many ISP customers. If a spammer's account at one such ISP customer of UUNET is cancelled, the spammer can get an account at a different ISP customer of UUNET. Thus a spammer can hop from ISP to ISP and continue using UUNET's dial-up hosts for spamming. Is it really fair to blame UUNET for this? A. It's a clever defense to claim that spammers are hopping from ISP to ISP, thus making UUNET out as some sort of victim. However, there is no evidence that ISP customers of UUNET cancel spamming accounts with any speed. They certainly have no market-based incentive to do so. Since the public cannot identify which of UUNET's ISP customers are harboring spammers, there is no pressure on these ISPs to cancel any spamming accounts. (See also the keyword NOMOTIVATION elsewhere in this faq.) But suppose we assume, only for the sake of argument, that UUNET's ISP customers do cancel spamming accounts. Not because of the pressure of bad publicity, since there is none, but purely out of the goodness of their hearts. This doesn't let UUNET off the hook at all. UUNET has known for a long time now (at least two years, perhaps more) that such ISP-hopping is possible. UUNET has had plenty of time to take steps to make sure that once an ISP customer of UUNET cancels a spamming account, that account-holder (based on his credit card or contact information) will be denied access to all UUNET equipment through any ISP. It's technically quite easy, almost trivial, to maintain a database that allows such blocking. If UUNET does not do such blocking, it must be because UUNET's management has decided to not do it. [CORPORATE] Q. Isn't it possible that folks within UUNET are working hard to fight spam, but are inhibited from doing so by corporate policies? Or that UUNET's lawyers won't let UUNET take effective action? A. Not only is it possible, but it's very likely, that there are people within UUNET who want to solve the spam issue and are prevented from doing so by corporate policy. In every big company you will find people with many different opinions. Thus, it's easy to believe that UUNET employs some people who are opposed to spam, and others who are solely concerned with making sure that UUNET's income not be reduced. And many in between. Given these varied opinions, we cannot judge UUNET's stance on spam from the opinions of any one individual. We must ultimately judge UUNET's by the actions of UUNET as a corporation. And UUNET's actions are very clear: A sustained spam output, a focus on protecting spammers from adverse publicity, a refusal to provide any cooperation to the victims of UUNET spam. Hence, when we consider UUNET as a corporation, we must classify it as strongly pro-spam. The likely presence of some anti-spam individuals within UUNET does not change this. Even if somebody could prove that 100% of all UUNET employees are anti-spam (although this is extremely unlikely), it would not change the final conclusion: UUNET is pro-spam because its actions are pro-spam. [BIAS] Q. Aren't you a little biased? A. I am biased against anybody who sends large volumes of spam in my direction and refuses to do anything about it. The more the spam, the greater my bias. Add a few mailbombings, such as those that UUNET has sent my way, and the bias becomes even stronger. Add a blatant refusal to provide any cooperation in tracking down the culprits of spammings, header forgeries, and mailbombings, and yes, you can say I am a little biased. However, my bias does not necessarily mean that anything in this document is incorrect or unfair. All the information presented here is the best available to me. Speculation is labelled as such, and presented only when sufficient facts are not available. [ABUSE@] [Update: As of early July 1999 UUNET is accepting abuse reports at abuse@uu.net. We have not yet verified that UUNET does anything useful with them. More details will be added if and when they become available.] Q. Why does UUNET bounce and discard abuse reports sent to abuse@uu.net? A. Our best guess is that this is intended to decrease the load on UUNET of processing abuse reports and to keep their numbers down. When an abuse report is sent to abuse@uu.net, it is discarded, but it results in an automatic reply to the sender asking him to send the abuse report again to a different address. The automatic reply is formatted to make it hard for the sender to actually re-send the abuse report. Until some months ago, the automatic reply did not clearly say that the abuse report had been discarded, so senders would have been led to believe that their abuse report would be processed. Under public pressure John Bradshaw, who directs UUNET's department which processes abuse reports, updated the automatic message to say that the abuse report had been discarded. However, the automatic reply still does not include the original text of the abuse report that has been discarded. As a result the person receiving the automatic bounce will need to retrieve his original abuse report and re-send it. If the person did not save a copy of his original abuse report, that abuse report will never reach UUNET. It's a safe estimate that the majority of abuse reports sent to abuse@uu.net will never be seen by anybody at UUNET. (We actually suspect that the majority of abuse reports sent to *any* address within UUNET will never be seen by anybody at UUNET. Certainly, experiments with sending simple easy-to-answer inquiries addressed to various abuse-related addresses within UUNET resulted in no response. Readers should try such experiments themselves.) UUNET's official stance, as nearly as can be told from John Bradshaw's Usenet postings, is that it is very difficult to process abuse reports sent to abuse@uu.net, because UUNET staff would then have to sort them into reports about Usenet abuse and reports about email abuse. It appears that UUNET is reluctant to hire enough staff to do this. We estimate, though we are not able to verify this, that UUNET spends more on having its floors cleaned than on personnel to handle abuse reports. UUNET has been silent about the possibility of writing a relatively simple program that would automatically classify abuse reports as being about Usenet abuse or email abuse according as the string 'Path:' is present or absent in an abuse report. This is apparently a problem that only UUNET, and no other ISP in the world, has found impossible to solve. Update: We have heard Bradshawesque noises that the policy is about to change, and that UUNET might begin accepting abuse reports at abuse@uu.net. Q. But isn't it true that you can send abuse reports to @abuse.net and they will get routed to the right address? And if so, why complain about UUNET using nonstandard abuse addresses? A. Although abuse.net does provide a useful mail forwarding service, it cannot fully compensate for UUNET's vagaries. You see, the problem is that UUNET requires a number of different abuse-reporting addresses, one for each type of abuse being reported. The most common types of net abuse that people report are (a) email spam and (b) misbehavior or spam on Usenet. UUNET requires two different abuse-reporting addresses for these abuse reports: abuse-mail@uu.net and abuse-news@uu.net. The abuse.net forwarding service will not be able to correctly forward to the right address based on the type of abuse you are reporting. All abuse reports sent to uu.net@abuse.net will be treated as if they were reporting email spam. If you report Usenet spam to UUNET via abuse.net, your abuse report will go to the wrong address and will almost certainly be ignored. That you should even have to resort to a third-party forwarding service demonstrates that UUNET does not attempt to be a good net citizen. The folks who run UUNET know perfectly well that all abuse reports are by default sent to an abuse@ address. Knowing this, they still do not properly use such an address. Q. Is it such a big problem that UUNET requires nonstandard abuse- reporting addresses? Don't most experienced Internet users know this? A. Those who routinely get UUNET spam, and routinely report it, and also read UUNET's auto-bounced reply carefully, probably know this by now. It's not clear that they would have known until recently, because UUNET's autoreply did not clearly state, in the past, that an abuse report sent to abuse@uu.net had been discarded. And people new to the Internet, who have trouble just figuring out where to send an abuse report in the first place, will likely not know to send it to a nonstandard email address. When they get UUNET's autobounced reply they do not know what it's all about. Many Internet users have trouble even figuring out plain bounced mail complete with the original message and its headers. We should not expect them to decipher a cryptic autobounce message that does NOT include the original abuse report. Even if with great effort users figure out where to send an abuse report, the important point remains that UUNET has deliberately set up a system that makes it hard for users to do so. This is just one more fact we need to add to our entire picture of UUNET as a pro-spam company. [STAFF} Q. Is it really fair to expect UUNET to have enough staff to handle all abuse reports? A. This question is best addressed by turning it around: Is it really fair for UUNET to send so much spam that its staff cannot cope with the resulting abuse reports? [REALLYBIG] Q. UUNET is big. Shouldn't we be more accommodating? Big companies act slowly. A. The bigger a company, the more resources it has. A company that is a hundred times as big as another has a hundred times as many resources. And bigger companies have greater economies of scale, which means they actually have more resources, in proportion, than smaller ones. Furthermore, it's a myth that "big companies act slowly". The real truth is that big companies don't like to say "no", so when you ask them to do something they don't want to do, they seem to react slowly -- because they are simply stalling you. Big companies act quickly when it's in their interest to do so. My own experience shows that UUNET acts quickly when UUNET itself is the object of a mailbombing, but UUNET acts slowly or not at all when somebody else is being attacked. I verified this when my machines were subjected to a series of mailbombings. My emailed complaints to UUNET resulted in no response. However, when I made my mail software reflect the mailbombs back towards UUNET's own email addresses, UUNET reacted VERY QUICKLY and told me in no uncertain terms that if I continued to do so all mail from my machines to UUNET would be blocked. See also the section on RADIUS. [RADIUS] Q. Since UUNET must rely on its reseller customers to disable spamming accounts, isn't it understandable that this could take some time? A. UUNET could block spamming accounts within seconds if it decided to. When a dial-up user logs into one of UUNET's terminal servers, the login and password strings typed by the user first go to a computer system running RADIUS software. RADIUS is a standard protocol for parsing login and password strings and allowing or disallowing logins. UUNET's RADIUS software sends on the login and password information to UUNET's reseller customer's own RADIUS server, waits for a reply, and then allows or disallows the login based on that reply. UUNET could easily set up its RADIUS servers to instantly deny access to accounts that have been observed to be spamming. For reasons that are not clear (but which we can try to guess) it's a policy decision on part of UUNET that even known spammers will not be immediately denied access to UUNET's terminal servers. Only if and when a specific UUNET customer programs his own RADIUS server will a spamming login be blocked. If a UUNET customer does not block a spamming login, that account will continue to spam away. Let's take a real example. A company called TCPS, Inc. sent vast amount of email spam almost daily for about six months through UUNET's terminal servers. During those six months TCPS used approximately 80 different dial-up accounts at various UUNET customers. Thus each of those 80 accounts sent junk email for about 2.25 days, assuming TCPS spammed from only one account at a time. After six months of spamming, TCPS was finally persuaded to stop, because UUNET filed a lawsuit. Had UUNET blocked each of these 80 accounts wihin 15 minutes after it began spamming, and had UUNET made sure that TCPS was given no more accounts, that company would have spammed for a total of LESS THAN ONE DAY. Calculations above are approximate, but illustrate the basic point: By having a policy of not immediately blocking spamming accounts, UUNET makes it easier for spammers to use UUNET's resources for spamming. [BLOCKING] Q. Why don't people just block incoming mail from UUNET? A. At one time there was a risk that people would do exactly that. UUNET's practice was to provide relay hosts, called by names such as relay1.uu.net, relay2.uu.net, etc., that would accept and relay mail for UUNET's customers. This service was very useful to UUNET's spamming customers, who could send vast amounts of spam through these relay hosts. Even though this facility was useful to UUNET's spamming customers, it was also potentially a place where UUNET could automatically detect spam and quickly and efficiently disable the spamming accounts that were sending spam. (Look for the keyword RADIUS to read about how UUNET could quickly disable a spamming account, if it decided to do so.) So far as we can ascertain, UUNET at no time attempted to automatically detect spam passing through its relay*.uu.net hosts. Instead, UUNET decided to simply disallow customers from relaying through its relay*.uu.net hosts. Why did UUNET pass up an opportunity to automatically detect spam and disable spamming accounts? Let's examine the situation. Allowing spam to pass through a small number of hosts made these hosts subject to being blocked from sending mail to other sites on the Internet. Had the relay*.uu.net hosts continued to relay spam, it was very likely that sites all over the Internet would have begun to refuse all incoming mail from the relay*.uu.net hosts. Equally importantly, UUNET was running the risk of being added to the MAPS RBL, a list of pro-spam hosts and networks, that many sites on the Internet use to automatically block incoming email. If UUNET's relay hosts had been added to the MAPS RBL, much UUNET email, including both spam email and non-spam email, would have been blocked from reaching other sites. UUNET's customers, including both spamming customers and non-spamming customers, would have been furious. UUNET would have lost income due to its customers leaving for other service providers. We do not know specifically why UUNET decided to disable its relay hosts. But we can guess that doing so resulted in the following advantages for UUNET: 1. UUNET's spamming customers now had to relay their spam through third-party servers, thus eliminating UUNET's own machines as a target of mail blocks. 2. UUNET's machines no longer were loaded down processing and relaying spam. The load was transferred to innocent third parties. 3. The MAPS RBL no longer had a host to block, unless it blocked a large number of innocent hosts that were being exploited by UUNET's spamming customers. 4. Many anti-spam people declared UUNET's closing of its relays to be an anti-spam step, giving UUNET PR value that it did not truly deserve. 5. UUNET no longer had to answer questions about why it was not automatically detecting spam on its relay hosts. Thus we see that by closing its relays, UUNET gained many advantages and lost little or nothing. UUNET did lose the opportunity to automatically detect spam and disable spamming accounts, but it was a loss only if UUNET's management *wanted* to do this. We have no reason to believe that they did. Going back to the original question "Why don't people just block incoming mail from UUNET?", the answer now becomes obvious: Because UUNET's spam is sent relayed through a large number of SMTP servers all over the Internet. These SMTP servers belong to innocent parties whose machines are being exploited by UUNET's spamming customers. It's not always practical to block email from these users without also blocking legitimate email from them. However, many sites do block all email from SMTP servers that are open to relaying mail from third parties, including UUNET's spamming customers. There is a computerized list called the ORBS that may be used for this. The use of ORBS does cut down incoming spam, including UUNET spam. Due to the risk of collateral damage to innocent users, the use of ORBS is controversial and is not a satisfactory substitute for UUNET ceasing its pro-spam activities. [PORT25] [Update: As of July 1999, UUNET appears to be doing a substantial amount of port 25 filtering. However we are still seeing many reports of direct-to-MX spam from UUNET's dial-up ports, which indicates that port 25 filtering is not being completely done. John Bradshaw's original estimate, that port 25 filtering would be completely implemented by the end of April 1999, was not even close.] Q. What is this 'port 25 filtering' that I hear about? How will it affect UUNET's spam? A. Currently UUNET allows its customers to connect to arbitrary SMTP ports anywhere on the Internet. (But see Update above.) The SMTP port by convention is always TCP port 25. A provider that allows connections to only its own SMTP servers is said to be doing 'port 25 filtering'. Recently UUNET has claimed to be doing partial port 25 filtering. Most ISPs do not do port 25 filtering. There are some technical issues that make it hard or undesirable. (See Technical Addendum near the end of this document.) If UUNET were to properly and completely implement port 25 filtering, all SMTP connections made by UUNET's customers would go into a small set of SMTP servers, allowing the automatic detection and suppression of email spam. If past experience is any guide, UUNET's attempts at port 25 filtering will take a very long time -- perhaps several years. And should the completion of port 25 filtering actually come about, the question would remain of whether UUNET would then actually monitor the SMTP servers and take any steps to detect and suppress spam. If not, the port 25 filtering would end up being a waste of effort. We predict that if UUNET does implement port 25 filtering, UUNET will *NOT* require email to be relayed through UUNET's own SMTP servers. If UUNET's spamming customers relayed mail through UUNET's own servers, UUNET would risk being blocked by other sites and being added to the MAPS RBL, and UUNET would also have to to justify why it does not automatically detect spam through its own servers and immediately disable spamming accounts. Please see the discussion in the section on [BLOCKING]. Q. Is it really fair to expect UUNET to do port 25 filtering, when ISPs generally don't do it? A. Realistically, nobody is expecting UUNET to do port 25 filtering any time soon in any substantial manner. Such a step would be quite out of character for UUNET. We can also answer the question of whether we *want* UUNET to do port 25 filtering. The answer is: We don't care. What we want UUNET to do is stop sending spam. If port 25 filtering is the way UUNET implements this, then UUNET can do port 25 filtering. If UUNET chooses some other methods to cause UUNET spam to cease, that would be ok too. The point really is that UUNET should find *some* mechanism(s) to cease its spam. So a better question would be: "Is it really fair to expect UUNET to fix its spam problem?" The answer is: Yes, it's fair. UUNET has shifted the cost of net-abuse for far too long to the victims of UUNET spam. By keeping its own spam-fighting costs low, and by providing anonymity to spam-friendly ISPs, UUNET is able to keep its prices lower and attract more customers, and thus get an unfair advantage over other providers who work much harder to prevent spam and be good to the net. This is not fair to the good guys. Over the last two years, *ALL* of UUNET's competitors can be considered to be good guys when compared to UUNET. [OPINIONS] Q. Regardless, this so-called 'faq' presents YOUR opinions, doesn't it? What do you say about that? A. Whose opinions should I present, if not my own? Regardless, if you look around on the World Wide Web, you will find plenty of other people who agree that UUNET is spam-friendly. As an example, try searching the web search engines for the phrase 'uunet spam'. [WHATTODO] Q. What can we do about UUNET? A. So far as can be told, UUNET is oblivious to the usual spam-reporting mechanisms, and is oblivious to the idea of civic responsibility or the good of the net. For UUNET to reform, it must become clear to UUNET's management that being pro-spam will be more costly than being anti-spam. This is unfortunately not the case at this time. To make it so, all victims of UUNET spam should resolve to provide as little money to UUNET as possible. Take all reasonable steps to buy connectivity elsewhere. Talk to your service provider and ask him to minimize the amount of business that he gives to UUNET. Talk the language that UUNET will understand -- the language of money. [TIME-AND-HALF] Q. Suppose, just suppose, that the unlikely happens and UUNET does reform. What next? Will you delete this mini-faq? A. At some point UUNET's current pro-spam approach will reach a point of diminishing returns. At that point it will no longer be cost-effective for UUNET to continue ignoring the spam problem. At that point UUNET will begin to institute anti-spam measures. When that happens, we should realize that corporate behavior relating to spam can be broadly sorted into three categories: 1. A company that never allows spam. 2. A company that allows spam for long enough to gain market share and grow, and then stops allowing spam to get good PR. 3. A company that always allows spam. It's important that we encourage type 1 behavior most of all, i.e., we should give companies an incentive to never be spam-friendly in the first place. For this reason, we must not immediately wipe the slate clean when a company that is spam-friendly reforms and becomes anti-spam. Otherwise many companies would prefer to be of type 2. They would reap the benefits of being pro-spam, then become anti-spam when the timing was right. We recommend to the reader that he treat a company as being pro-spam for (a) as long as the company is pro-spam, and then (b) for half as much time again after the company ceases its pro-spam activities. For example, if a company is pro-spam for one year, then becomes anti-spam, it should be treated as if it had been pro-spam for 18 months. Thus, the slate does eventually get wiped clean, but not on the day that a company reforms, but some time afterwards. This will help ensure that companies are discouraged from setting a convenient schedule, first reaping the benefits of being pro-spam, then conveniently becoming anti-spam when they think they need the good publicity of being anti-spam. UUNET is currently of type 3 (allowing spam) but may become of type 2 at some point (allowing spam for long enough to benefit from it, then disallowing spam to get good PR). At that point, the slate should be wiped clean using the time-and-half formula. It's therefore recommended that readers of this faq avoid doing business with UUNET (a) now and (b) for half as long again as UUNET was pro-spam, if UUNET should become anti-spam in the future. Individual readers can adjust the formula to their liking. If a company is so pro-spam that it never leaves your mailbox alone, you could decide to not do business with that company for three times as long as it remains pro-spam. As an example, if UUNET hammered away at your mailbox for three years, and then became anti-spam, you could decide to not do business with UUNET for those three years, and for six more years after that. Feel free to adjust this up or down depending on how forgiving you are. You might also want to make an adjustment depending on whether or not the UUNET CEO ever offers an apology for UUNET's pro-spam years. This mini-faq is likely to be permanent. But it will be revised to reflect any major changes in UUNET's spam-related policies, as they become known. [REBUTTALS] Q. Where can I find points of view opposing yours? Why should I believe this mini-faq? A. If you search the newsgroup news.admin.net-abuse.email, you will find occasional attempted rebuttals in response to this mini-faq. But these have so far always been blanket assertions of disagreement unsupported with any specific reasoned arguments. We don't know of any web site with any published document that tries to refute this mini-faq. A good reason to believe this mini-faq is the general absence of any credible rebuttals. The reader is invited to do searches on Usenet and the web and look for such rebuttals, in case any should become known in the future. It's remotely possible that somebody, somewhere, has information that could prove this mini-faq to be grossly erroneous. If so, we assume that such information is highly confidential and cannot be revealed without jeopardizing the future of humanity (or some such thing). [DAMAGE] Q. Even if we agree that UUNET is pro-spam, has been sending spam, etc., isn't this all much ado about nothing? Other than people sometimes having to delete an occasional message from their mailboxes, what real damage has UUNET caused? A. The author of this FAQ estimates that UUNET has caused him a total or about US$15,000 worth of real financial damage, due to (a) Lost manpower dealing with junk from UUNET, dealing with repeated mailbombings from UUNET, and dealing with angry spam victims who received forged junk email from UUNET's network that showed the author's domains in the sending address; (b) Real dollar cost of needed hardware upgrades to properly cope with the above. This estimate does not include the vast amount of inconvenience caused to users who end up downloading un-needed junk email. Q. A total of $15,000, that's it? A. That's not the world-wide total. The world-wide aggregate damage caused by UUNET could easily be tens of millions or hundreds of millions of dollars. It's quite hard to estimate exactly. Only UUNET, having access to its own equipment and being able to estimate its own spam traffic, could accurately make such estimates. Q. Has UUNET published any estimates of how much damage it has caused? A. Not to our knowledge. Q. Has UUNET offered to compensate anybody for this damage? A. Not to our knowledge. Q. Has UUNET admitted causing this damage? A. Not to our knowledge. Q. Has UUNET denied causing this damage? A. Not to our knowledge. Q. Has UUNET apologized for this damage? A. Not to our knowledge. [LEGAL] Q. Aren't you afraid UUNET might sue you for writing this mini-faq? A. This mini-faq resides within the United States, where truth is an absolute defense to charges of libel. UUNET would have to show that this document contains deliberate falsehoods. That would be hard to do, since all information presented here is the best available. If UUNET filed a frivolous lawsuit it could end up being countersued and perhaps losing the countersuit. UUNET's lawyers are probably not stupid enough to take that risk. ================================== TECHNICAL ADDENDUM Selected technical topics are discussed below. TECHNICAL DISCUSSION: PORT 25 FILTERING Port 25 filtering involves adding filters to terminal servers such that dial-up users will be able to make SMTP connections only to selected SMTP servers. Filters can be permanent, or they can be keyed on the username. The latter type of filter can allow filters to be set up for specific users, or specific classes of users, so each user can access his preferred SMTP server. Q. Why do most ISPs not do port 25 filtering? A. Let's look at the advantages and disadvantages. Disadvantages: - Higher administrative overhead. - A small fraction of legitimate users might object to not being able to connect to arbitrary SMTP servers. - Spamming customers will leave, decreasing the ISP's income. Advantages: - Greater monitoring of email spam Clearly, the balance of the advantages and disadvantages will vary with each ISP's goals and priorities. Two types of ISPs will not want to implement port 25 filtering at all: - ISPs who control spam by other means and do not need port 25 filters - ISPs who do not want to control spam Q. Why would any user object to port 25 filtering? A. Some power users like to monitor the progress of outgoing mail, and they can do so better if they send mail directly to the destination SMTP server, instead of sending mail via their ISP's SMTP server. Others want to run mailing lists on their own machine, and do not want to load down their ISP's SMTP server by sending high volumes of traffic through it. (This includes both legitimate customers and spammers.) It used to be that users liked to connect to remote SMTP servers and use VRFY and EXPN commands to check validity of email addresses. However, most SMTP servers disallow these commands these days, so this is no longer a good reason for not implementing port 25 filtering. Q. Is there any way of implementing port 25 filtering without users being aware of it? A. There is a method called 'transparent proxying' that is in use on the Internet for directing web traffic into local proxy servers. It's done by programming the local router to silently reroute all packets directed towards remote web servers to a local machine. The local machine then sends on the web query to the actual web server, gets back the response, and returns the response to the user. In most cases the user is unaware that his web connection did not actually go to the remote web server, but only to the local proxy server. A similar mechanism could be used for SMTP. This would allow the best of both worlds: Users would be able to connect to remote SMTP servers, or so they would think; but the local SMTP proxy would be able to monitor SMTP traffic and automatically detect attempts at sending spam. == END ==