On Thu, 26 Feb 2004, Robert G. Brown wrote: > Why in the world does anyone think that digital signature maps with > several orders of magnitude more entities to track, more complexity, and > hence more opportunities for spoofing and finagling are going to succeed > where simple DNS hostname lookup has failed? The reason is a little clearer when one considers that the main proponents of this idea have businesses or business plans to sell services for running the necessary infrastructure. As Bill Gates proved, the quickest way to astronomical wealth is to sell something very cheap to nearly everyone on the planet. Since then, many people have been trying to come up with similar schemes. Few have succeeded. > IMO a "no anonymous mail" rule (no mail accepted anywhere from > unregistered hosts) coupled with pretty stiff fines and legal penalties > for spam would associate accountability and penalty and cause an > immediate and drastic reduction of the problem. Holding ISPs (and > providers of open relays and proxies) liable for the fines of their > clients if they bolt or "have no assets" would give ISPs a very strong > incentive to police their clients. Obviously, the two would have to > come about together -- it is less useful to have fines and penalties > when the originating hosts have unregistered IP numbers that change > every two days and are nearly impossible to trace. There are reasons to have "anonymous email" as well as reasons to operate open relays**. Many ISPs operate open relays, and while the number of open relays continues to grow--few are open by mistake--the number of "spammers" abusing open relays continues to decline. Last May, the FTC reported that only 5% of spam involves open relays. Recently, I had a hard time finding an open relay abuse example in my current spamfolder. I'd says its now even less than 5%. Open relays provide no benefits to spammers that they don't already have. We also have email senders that only send mail, but don't receive mail. This type of mail is indistinguisable from anonymous email, because there is no way to "verify" the sender. But there are also reasons to have license-plate anonymous email as well, where the message isn't truly anonymous, but unless it is part of a criminal act, no one can find out the identity. It is a mistake to assume that only people use email. Below are two recent messages on the subject of Verizon "testing" whether an email sender receives email. This "test" isn't helping Verizon filter spam. In both the case I was responding to, and the case that Randy Bush was responding to, the people were experiencing problems with temporary SMTP error messages, and wondering what the problem was. On Sat, 21 Feb 2004, Dean Anderson wrote: > > Verizon is trying to do a "sender verification test". This is a dumb > idea whose time didn't come. But no matter. > > Here is a message from Randy Bush on the subject. I frequently disagree > with Randy, but in this case, I think he has the right idea. > > --Dean > > > ================= > > > I think he's saying that they were unable to perform the > > validation hence the 450. If the validation was successful, > > they'd return a 200 series code, if it was unsuccessful, they > > would return a 500 series code. > > nice words, but crap. due to needs to spool mail for sites in > countries with very poor connectivity, mail spool time here is > quite long. if verizon and others seem unable to decide in weeks, > why should i pay the penalty? > > but, i guess the problem is easily solved with exim config. i have > set it so that if it can not deliver to verizon in say one hour, it > dumps the mail. > > verizon.net * F,1h,5m > > life is simple, except for verizon users i guess. > > randy > > On Sat, 21 Feb 2004, Dean Anderson wrote: > Shouldn't reply to my own message. But in case it isn't clear, the > reason this is a bad idea is: > > 1) Performance. Verizon's mail server has essentially doubled its load. > If a mail server or nameserver (theirs or yours) is slow, it will cause > a temporary failure, as you saw. If their nameserver is slow, or one > fails, it will cause a performance knee with a storm of increasing defer > retries which will quickly bring the server to its knees. > > 2) Many sites monitor "NOQUEUE" connections, and automatically blacklist > those IP addresses which make too many NOQUEUE connections. A lot of > "testing" by Verizon will automatically get them blacklisted. > > 3) There is no guarantee that a from: address receives email. This is a > feature that spammers certainly exploit, but there is are legitimate > reasons for this: many machine email senders send mail and never receive > mail. Any mail for those robots will be rejected. So the premise of the > test (that every sender can be verified) is invalid. Of course, any one > stupid enough to violate 1 and 2 above, will certainly be unable to > grasp the subtlety of this. > > --Dean > > I think that this is fairly unlikely to come to pass, as lawmakers are > as likely as not to be spammers of a sort in their own right, soliciting > campaign contributions, distributing political "newsletters", using > email in a variety of edgy, mass distribution ways. OTOH, they also get > spammed, as do their families, so one never knows -- some states are > slowly moving to control spam in law. Actually, the CAN-SPAM act supercedes all state laws on the subject. States have no or very little say in spam legislation. > In the meantime, instead of burning a huge amount of human time and > energy just DISCUSSING the issue of universal keysigned mail (let alone > the hassle of implementing it for just one site), perhaps we can each > (in the words of Candide) "tend our own garden" and use one of the many > excellent filtering mechanisms already available, while teaching our > users to do the same. If the proposal meets this much resistance and > "why bother" attitude here, imagine the resistance it will meet at the > ISP level and out in the real world, where time spent implementing > ANYTHING is pure money and maintenance time down the drain. > > rgb > > ** The reasons for running open relays are obvious from the definition of an open relay--An open relay is any relay which provides unauthenticated service to anyone outside of the assigned IP address space. There are a lot of people and computers outside of our assigned IP address space who want to purchase some services from us. There are quite a lot of people or things who can't use SMTP AUTH either because their software doesn't support the protocol, or because we don't have per-user accounts for them. Those who don't have per-user accounts or don't receive email can't use POP before SMTP, so they need open relay. There are quite a lot of people and electronic agents that can't use SMTP AUTH. There are also quite a lot of people and electronic agents that can't use POP before SMTP. We have leased line customers with many offices that buy connectivity from us and from other providers for some offices, yet use our relays. (They want our HA services for their main office, but we are too expensive for their outlying offices) We have leased line customers who have outsourced their email boxes to another provider that doen't provide SMTP relay service outside their IP Address space. For them, we relay for the domain of the other provider (RMX can never work). Others get leased access from us, but dialup from someone else, and don't want to change configuration. We have customers that run their own mailservers, but want backup relay service from us. Others that are consultants, and are often in the clients office on the clients DHCP, and don't want to change configuration. Etc, etc, etc. Having run open relays since 1996 (and before, but they weren't "my" servers until 1996), I am very familiar with the abuse of open relays. Though I didn't experience any open relay abuse before 1997, and then only after telling some radicals that there were good reasons to run open relays, it was my business interest to find out who was behind that abuse. The abuse of open relays is mainly done by radical antispammers attempting to mail bomb people. Real spammers never abused our relays--Not in 8 years of operations. But we have tracked down a number of open relay abusers. Our abusers were either 1) people not sending spam, but not having permission to use our relays either, or 2) radical antispammers (sometimes admins at other ISPs) who were either trying to get us to close our relays, or trying to abuse someone else. In one case, an abuse admin at Verio was fired for repeatedly abusing our relays, and posted his story to the spam-l list, blaming me for his termination. When we blocked the open relay blacklists from scanning, our abuse dropped off dramatically. I did tests with submitting different IP addresses to different blacklists, and logging the abuse and SMTP connections to each of the addresses, and then "closing" the relay and having it "retested", and then measuring the number of connections. The abuse rate was directly related to the "advertisement" of the address by the blacklist. I concluded that the open relay blacklists were promoting the abuse of open relays. We still get periodic abuse of our relays. Generally, after I post a message like this, the abuse rate will spike. We detect and block nearly all of this abuse. Radical antispammers/open relay abusers never seem to consider that relay use is probably logged, and that analysis of the logs can reveal a great many things. Indeed, it was the tracking of relay abuse, and the failure to find real spammers in the abuse of our relays contrasted with the finding of antispammers performing the abuse that first suggested to me that radical anti-spammers may be behind much spam abuse. The present decline of open relay abuse in the face of increasing numbers of open relays also suggests a link to anti-spammers formerly conducting the abuse but now becoming disinterested in doing so. It seems that the radicals think that by conducting abuse, they can get people motivated to close relays, ban spam, etc. But in fact, the statistics of spam show other things. CAN-SPAM is not blocking any spam, but is enabling the real spammers to be distinguished from the fake spammers. Whatever the fake spammers do, their activities will be revealed. If they quit, and real spammers don't quit, we will see a reduction in spam that will be attributed to the fake spammers. If they don't quit, we have the tools to find them. The really funny/odd thing about open relay abuse, is that it was only radical antispammers (or the misled/uninformed) who believed that open relays were involved in spam or useful to spammers. The radicals believed that by mailbombing people they thought were spammers, they were somehow helping fight spam. The "proof" of open relay abuse was mostly, if not entirely, just the efforts of other radicals anti-spammers. Real spammers appear never to have shared the antispammer viewpoint on open relays. If they did, it was for a very short time. MAPS RSS tried to publish "proof" of spam sent through open relays, but examination of our logs revealed that the "spam" they published about one of our relays was only sent to 4 MAPS-associated people. Dave Rand and Paul Vixie were two of them. Even that wasn't a genuine spam. It was just a spam-like event staged by anti-spammers. Fake spam by fake spammers. Most of the people who thought (or still think) that SMTP AUTH or POP before SMTP were anti-spam solutions had limited experiences with email services, and those experiences were generally limited to residential (dialup/cable/dsl) ISP services or small companies that run their own mail server and only provide accounts to their employees. These people often put their spam solutions in the context of "only people use email, and if we could identify the people, we could exclude spammers". The fallacy is exposed by the fact that email isn't only used by people and that in a civil context, you can't be certain of the identity of the other party. So you ask, where did the notions about open relay abuse come from and is there any truth to them? If fact, there were problems with _anonymous_ relays, which are different from open relays. Sometime between 1993, when the _anonymous_ relay problem was fixed, and 1997, when I first encountered people talking about closing open relays, the radicals seem to have lost track of the difference. As I explain below, this problem has nothing to do with open-ness, but rather a misplaced trust in reverse DNS in 1986. Subject : Re: A historical perspective on draft-ietf-dnsop-inaddr-required-04.txt ----- Message Text ----- On Wed, 2 Apr 2003, Dean Anderson wrote: > > Here is a message from Rob Austein to the TCP-IP mailing list from 1986, > which puts a historical perspective on things. Rob is responding to a > message from gds@xxxxxxxxxxxxxxxxxx Given this was in 1986, the > spam.itsc.sri.com hostname was well ahead of its time. > > Rob knew then that "the silly net" wouldn't have reverse working all the > time, but thought this was broken. Apparently, he was under the > impression then that reverse was not optional, but could be "broken". > > More significantly (in retrospect), Rob advocates that one shouldn't put > numeric addresses in Received headers. Of course, Rob wasn't the only > person with this viewpoint. It is unfair to place this solely on Rob's > shoulders. Although not clear from this message, he is accompanied in > this viewpoint by many then, and who still share this view today. > > To the later chagrin of so many people, Rob's viewpoint was implemented > in Sendmail. It is unfortunate because we later learned by hard > experience that if one used a machine without Reverse, or if reverse > were configured to return misleading results, then one could send > completely anonymous and untraceable email through a mail relay. It had > nothing to do with the openness of the relay, though that was the early > "fix". Of course, even "closed" relays could be abused, and it would be > impossible to identify the user of the relay. The anonymous spam relay > exploit was the result of misplaced trust placed in reverse, and the > fact that an IP address wasn't put in the Received: header. It had > nothing to do with the openness of the relay. Some say this ability to > anonymously abuse relays caused spam. Eventually, this behavior was > changed in Sendmail and other MTA's in the early '90s. Since then, it > has been impossible to send anonymous email through an open or closed > relay. This fact has not stopped people from promoting myths about open > relays, however. > > It is really historically interesting that 17 years later, after so many > obvious faults, failures, exploits, and even spam caused by misplaced > trust in reverse DNS, that the same people are still promoting the same > ideas. It is a historical irony that some of the most vocal and ardent > proponents of Reverse DNS want to use it to prevent spam. > > --Dean > > > Message from Rob Austein (SRA@xxxxxxxxxxxxxx) > Wed, 1 Oct 1986 16:00 EDT > ============== > > Date: Tuesday, 30 September 1986 13:29-EDT > From: The lost Bostonian <gds@xxxxxxxxxxxxxxxxx> > To: header-people@xxxxxxxxxxxxxx, tcp-ip@xxxxxxxxxxxx > > > If it is true that all IP implementations enable a server program to > determine the IP address of its peer, then the HELO command, and its > response could be eliminated, which would save us a few bytes. > > > You are assuming that it is always possible to translate addresses to > names and vice versa. Unfortunately, there are some people out in the > world running domain nameservers who are totally clueless about what > they are doing, and there are others who have the misfortune to be > stuck behind a losing gateway or otherwise be unreachable much of the > time. Do you really want to make it impossible to receive mail from > some host because a third party is broken? Or have to put numeric > addresses into the Recieved headers? > > > The answer is to fix the silly net, not throw away features to save > two IP packets. > > > --Rob > > ==================== > > > >