Customer Services

Home 
About Us 
Products 
Data Centres 
Customer Service 
About 
Contact 
Help & FAQ 
Network Abuse 
Network Status 
Service Guides 
Service Monitoring 
Press Room 
Partner Programme 
Careers 

Unsolicited Bulk Mail



Practically everyone has logged on and received email from people they've never heard of, advertising products they don't want, or services that don't interest them. Although most people now accept that such UBM is a fact of life on the Internet, it is really a recent phenomenon, and has quickly grown to become perhaps the biggest downside (apart from security intrusions) of using the Internet.

A commonly encountered slang term for UBM, when it occurs as email, is 'spam'. Spam is however a trademark of Hormel Foods, and thus UBM has been adopted by members of the LINX as a generic name for unwanted messages.

UBM is nearly always originated in and targeted at the USA. It usually advertises products, services or websites which have a dubious moral or legal status, such as hard-core (and even paedophile) pornography, or make-money-fast scams. Such advertisements would not be accepted by publishers of traditional media such as television, newspapers or magazines, especially given the offensive language used to advertise the pornography.

Probably at least one third of all UBM advertises tools and email-databases for generating UBM, another third pornography, and the rest a mix.

Relaying - How Service Is Stolen

If you have an Internet connection and you operate your own electronic mail gateway (i.e. you don't collect mail from a POP mailbox or UUCP system) which runs the simple mail transfer protocol (SMTP), then your email gateway will probably be visible to practically all users on the Internet (approximately 20 million [late 1998 figures]).

If the mail gateway software is quite old, or has been set up without considering the problem of such theft of service, then it is likely that it will allow anyone anywhere on the Internet to send email through it. Not only will your email gateway accept email from anyone destined to anywhere, it will also expand the list of recipients on the originators' behalf, perhaps allowing a single inbound message to generate outbound messages to a hundred recipients. This amplification allows someone with a very poor or slow (and thus cheap) connection to the Internet to steal the service of a fast high-quality connection.

This theft of resources is commonly termed third-party relaying, because the email gateway is propagating (relaying) email that comes neither from you nor from your ISP, but from a person or organisation with which you have no contract.

The people who abuse such open relays, usually do so from a "disposable" dial-up account (one that is very cheap or a free trial) which they set up specifically for this purpose, usually using faked credentials to make it hard to trace them.

Thus, if your machine is an open relay, someone using a cheap computer and modem can send a flood of email. They target perhaps a hundred thousand (sometimes half a million!) people, spreading their attack across multiple open relays, and only stop once their ISP catches up with them and closes the account. This person can then disappear and take no responsibility for overloading email gateways and blocking leased lines for hours whilst all their junk email is bouncing around. Since the majority of the originators of UBM are not in the UK (most are in the USA), unless you are a large international corporation it is unlikely you could sue for damages.

Why Is My Mail System So Vulnerable?

Historically, the Internet was a sparse network of computers, and there was a significant chance that connectivity between two hosts for exchanging email would be impossible. Thus, in just the same way that PSINet's computers can be used to hold onto your email if you are off-line, all hosts would accept email destined for anyone, as part of an informal mutual support arrangement.

This convention of accepting mail from anybody for anybody is no longer necessary at all, firstly since there is global IP connectivity, and secondly since Mail exchange (MX) records in the domain name service allow for hosts to explicitly direct their mail to appointed hosts when they are offline.

When the Internet became more commercial, this practice of openly providing service to anyone who might need it became exploited, and the floodgates really opened in the mid-nineties. Since then software vendors have struggled to keep up, and even notable companies like Microsoft, IBM and Netscape were still supplying email systems in late 1998 which did not have relay control turned on by default, or didn't have any relay control at all without upgrading or applying patches.

Why Do People Send UBM?

Compare the cost of advertising on the Internet with traditional postal mail advertising. For example, to send out a mail-shot to 10,000 addresses, the costs for each recipient might consist of postage at £0.20 and materials at £0.20. The total cost is therefore £0.40 * 10000 = £4000, and does not include buying a list of mail addresses in the first place!

Apart from the financial contraints, there are also logistical problems, such as complying with legislation, observing approved advertising practices, ensuring the product won't fall afoul of trading standards laws, and handling the undelivered mail.

On the other hand it is possible to send a mailshot ten times that size using a cheap computer with a modem, set up with a free "throwaway" Internet dial-up account, and a few hours online; total cost less than £1000! Apart from the online charges the "investment" can be reused. Even if the "hit" rate for 100,000 email addresses is minuscule, maybe 0.1%, this still equates to sales leads from a hundred people.

At this point such unsolicited bulk advertising might seem like quite a good commercial venture, so PSINet would like to point out that the reason it is cheap is because the true costs are not paid for by the originator. Unsolicited bulk email is specifically barred by PSINet, just as it is contrary to the rules laid down by all reputable ISPs.

Why Should I Prevent It?

Reasons include operating costs, retaliatory action by recipients, damage to reputation, loss of connectivity and potentially blocking of facilities.

  • It Costs You Money.


  • At the very least you should take action for your own benefit, since your machine and its Internet connectivity is being abused by third parties who are not paying for it. It should be noted that since junk mailers send junk email to other people who also send junk email, once discovered, your machine will be targeted by more and more people, often within a matter of days, and thus the traffic will grow almost exponentially up to the capacity of the machine and/or your leased line.

  • You Are Making Enemies.


  • UBM is annoying to the recipients, who are usually on a dial-up connection and therefore their connection is slowed down while they download the mail, they are paying for connection charges to receive it, possibly paying for online time and/or storage space for their POP mailbox, and wasting their computer's disk space in storing the email before they can delete it. If they get a lot of UBM, their real mail may be rejected because they have reached a quota on their POP mailbox.

    Imagine how you'd feel if you had a personal free-phone number, and how annoyed you would be if you had an unsolicited telephone sales call, which thus runs up your own telephone bill. Then, add the fact that you can't hang up the call without losing all other phone calls at the same time! On top of that, there's the insult that the majority of these unsolicited callers would be exhorting you to take up subscriptions to pornography magazines. To carry the analogy through, consider that such telephone callers would target adults and children alike with no discrimination. Hopefully you can now understand why UBM is annoying, frustrating and sometimes very upsetting to its recipients.

  • Costs Of Complaints And Damage To Relationships

    When people receive UBM and email complaints, they will be unsympathetic or even hostile, rather than co-operative - after all, they have now had to bear the costs of going online to complain! The complaints are usually sent to at least two of:

    • The service provider whose customer generated it,
    • The service provider whose customer was unwittingly helping the originator by running an open relay,
    • The owners of the machine which is relaying the UBM,
    • Their own service provider.
    These complaints cost time and money for everyone to process, and the people who have to tackle the problem will rarely find the task to be a particularly satisfying one; this can thus cause a souring of relationships between owners of the abused machine, their software vendor, their consultant, and their ISP.
  • Retaliatory Actions From Victims
    Some people might simply decide to stop the problem themselves by attacking your computers, probably not caring whether they stop at just the computer involved in relaying the UBM.

    There are many programs freely available on the Internet specifically designed to break the security of, or just simply crash, computers. No matter how well your systems are run, there is no such thing as 100% secure software, and now that there may be several hundred thousand people who are very annoyed with you, there are bound to be some who have significant knowledge of security weaknesses in systems like yours.

    Even people with no real skill or knowledge can wreak havoc using these tools, there are ways of flooding your networks with such a large volume of traffic that your Internet connection becomes unusable. One such method is known as "Smurfing" and is difficult if not impractical to stop unless it continues for long periods of time (i.e. more than an hour).

    Some victims will go on to send UBM and forge it as though it came from you, and thus when the email goes astray and generates error messages (usually in the tens of thousands of reports), or people complain, your system will then have to handle the additional load.

  • Loss of Connectivity

    Many operators of mail systems, including ISPs, will observe that your email gateway is a large source of UBM, and may put a block on it so that they refuse all email from it. They may do this by putting an access list on their mail system to refuse mail, or they may make your entire network invisible by filtering your network traffic on their routers, so called "black-holing". An access list on their mail system only stops mail being sent, but black-holing will stop all IP traffic including email, DNS, web, FTP etc.

    If ISPs put blocks on their systems, you may become unable to communicate with your customers and suppliers, and they may not be even able to contact you to tell you, and may assume you are no longer on the Internet at all.

    There are well established methods of black-holing sites and/or networks. The result is very much the same: parts of the Internet cease to recognise that your machine or even your whole network exists. This becomes a problem if your web site becomes invisible to potential customers or your potential customers cannot exchange email with you. There is one black-holing system, the Mail Abuse Prevention System, run in a mature and responsible way. Note that if you do become black-holed by MAPS, there is only one way to be released, and that is to fix the problem. Nobody has succeeded in having a faulty system released through legal or financial leverage - not even Microsoft, who possibly have more financial and legal muscle than you!

    Another commonly used blocking system is the Open Relay Blocking Service (ORBS). This test mail servers that are reported to it, and lists them if they are found to be vulnerable to third-party mail relaying.

  • Problem Grows Daily

    Whilst all this is happening, the problem is getting worse, since your machine's vulnerability will be exploited by an ever-growing number of people. The only let up occurs when the machine or connection has become so slow that none of them can connect to it any more.

    Not only will you have to cope with the original junk email, and the complaints, but also the significant number of undeliverable email and the "bounces" that result, since it is a well-observed fact that the junk-mailers' databases are very poorly maintained.

  • In The Extreme: Action By PSINet
    If you use PSINet's email relays as "smart hosts" to route all your email, and your system is attacked so badly, the volume of email through it could reach such a flood that it threatens to overwhelm PSINet's systems. PSINet would then be forced to block inbound email from your machine in order to protect itself.

    We are very reluctant to take such drastic action, but blocking of customers' mail machines has happened in very rare cases, when all other avenues have been exhausted.

    Ultimately, PSINet has to protect its network performance for the benefits of all customers, as well as preserve its reputation of being a responsible Internet Service Provider.

When Should I Prevent It?

Prevention is always better than cure, since even if you fixed your systems after the first noticeable flood of UBM, you might have lost use of your email system for a day or so, and spent a couple of days fixing the problem and cleaning up the mess. The only good thing that might come out of the problem is you gain the opportunity to check your email system for security and Year2000 compliance as well, since upgrading the system will often solve both problems.

Experience shows that once your machine has been discovered by the junk-mailers and has one large attack routed through it, the growth in UBM can be exponential. The time between the first attack and other junk-mailers taking notice of your machine may be a matter of days or perhaps a week or so.

Since UBM vulnerability can turn into a major crisis within days of it first being noticed, then clearly prevention is better than cure. This is especially important when you don't have someone of appropriate technical skills on site, either because it was set up by a contractor or consultant, or because your technical expert is on holiday or off-sick. If a crisis occurs under such circumstances, it's very likely to cost much more than a slower more measured process of preventing the problem. The costs of hiring in a consultant at a days notice will be extreme, and it is possible that you would have to buy pre-packaged software rather than download patches or free software to fix your system.

I Want To Stop It, What Do I Need To Know?

Hopefully having read this far you'll be convinced that timely action is of the essence. You may need to upgrade your email system's software, but if it will take more than a matter of days, you'll need to find a temporary solution whilst waiting.

There are standard steps you can take, some of which you can do yourself, some of which may require you to call in a consultant. To be able to follow these steps, you'll need to answer some questions.

1 - What Software Are You Running?

An easy way to find out what email software you're running is to "telnet" to the machine's SMTP port. In Unix you would do this (type the bits in bold, where the italics are specific to your system):

% telnet mymachine smtp
Trying 1.2.3.4...
Connected to mymachine.
Escape character is '^]'.
220 mymachine ESMTP Sendmail X.Y.Z/cf ready at Mon, 30 Nov 1998 11:53:07 GMT
quit

This is also possible using the MS Windows telnet program, by setting "port" to 25 in the connect dialog.

The answer above shows the version of sendmail running on the Unix machine being tested. The version information would be put where the italics are, usually something like 8.7.9 and after the '/' comes the version written into sendmail's configuration file.

Another example, a Lotus Notes system:

% telnet lotusmachine smtp
Trying 1.2.3.4...
Connected to lotusmachine.
Escape character is '^]'.
220 lotusmachine Lotus SMTP MTA Service Ready
quit

Another example, a TFS Gateway system:

% telnet tfsmachine smtp
Trying 1.2.3.4...
Connected to tfsmachine.
Escape character is '^]'.
220 tfsmachine is ready. TFS Gateway 3.0
quit

2 - Whose Mail Are You Handling?

Your email gateway needs to recognise insiders vs. outsiders, i.e. who is on your network and who's not on a "trusted" machine, and it needs to know which domains' emails are handled by you. This allows it to tell the difference between incoming email and outgoing email, and so permit mail from anyone inside to go anywhere, permit outsiders to send mail only to insiders, but refuse email from outside addressed to outside.

Firstly you tell your email gateway the network addresses of your own machines, and these machines are allowed to send email to anyone without restriction (other than those you might enforce due to company security policies etc).

Secondly you tell your email gateway the list of domains for which it should receive or relay email. These are your own domains, but you may also need to consider your customers' domains (if you handle email for them e.g. as a backup email exchanger or pop mailbox host).

3 - Who Has The Skills To Fix The Problem?

How you will find the skills to reconfigure or rebuild your email system will depend very much on how the system is being managed at present. We encounter three common situations in which email systems are operated:

  • You are the person who set up the email system and thus know it very well,
  • You run the email system but inherited it from someone else,
  • Or nobody really runs the email system as the person who set it up was a hired-in consultant or has left employment of your company.

For the first scenario, you should be able to tackle any of the problems head-on perhaps with a little help from the hints and resources listed later in this document.

For the second and third scenarios, the hints and resources below should at least give you a head-start in deciding whether to tackle the problem yourself(it might be a simple mouse-click operation) or to pay a consultant to fix it for you. If you have to hire in help, you should be able to get an idea of the scale of the problem and whether a consultant is quoting a fair number of hours to solve it!

Ready To Close the Relay

By now you're armed with the network address(es) of machines you consider "friends", and which domains are "yours". For example, your network might be 5.6.7.32/29, and your domains are company.com and company.co.uk

The fixes are divided up by email software, as needless to say different programs and even different versions have to be configured differently. At this point you should be aware that some software packages cannot be fixed at all, and the only way is to replace them entirely.

Some of the more common mail server packages are described below, with brief instructions on how to secure them against third-party mail relaying. For more detailed information, as well as instructions on how to secure less common software packages, we recommend the following sites:

http://maps.vix.com/tsi/ar-fix.html
http://www.orbs.org/otherresources.html

    Sendmail

    Sendmail is now on version 8.9.2, which has third-party relaying turned off by default, a feature introduced in 8.9.1.

    In considering whether to fix your existing configuration or upgrade to a new version entirely, it is worth considering that versions older than the latest are vulnerable to both security weaknesses and denial-of-service attacks. Also, getting any technical help will be difficult to find with older versions, especially 8.8 and earlier.

    If your version is between 8.7 and 8.9, and you're technically expert with sendmail configuration, it should be possible to control relaying. However, this is not trivial as it will require significant changes to the sendmail.cf configuration file. Anyone who has ever tried to write a .cf file will know that it's somewhat difficult, although if you're lucky your .cf may have been built from M4 macro files (used by more recent versions of Sendmail). Modifying the M4 sources is likely to give better results than changing the .cf itself. The place to find .cf patches is on the spam.abuse.net site listed in the resources.

    If you're going to have to upgrade Sendmail to a newer version, and you don't need some of the special legacy features it has (such as UUCP), then consider Exim which is a "plug-in" replacement for Sendmail. Exim has many major advantages, the main ones being that itsconfiguration file is written in English, and it is trivial to configure it to resist junk email attacks - see below. Another possibility is Qmail, but it isn't quite as friendly to set up as Exim.

    Whether you choose to upgrade Sendmail, or replace it with Qmail or Exim, the chances are that you will need to build the executable binary from sources and so will need a C compiler and associated tools. In theory it should be possible to download, build and install the program in less than a day.

    Exim

    Exim is a "plug-in" replacement for Sendmail and can be set up with practically no effort to prevent attack by junk mailers. However, there are many additional useful features, of which the ones most useful in the context of controlling UBM are the ability to reject email by sender's name or address, and use of the MAPS/RBL service to reject email or add headers to allow subsequent filtering by email clients.

    An example fragment of configuration file which shows these features in use, along with sample rejection lists, is provided by PSINet on our FTP site at ftp://ftp.uk.psi.net/exim. These fragments can be easily combined with the standard configuration file to provide both relay control and filtering.

    Note that it is likely that you will have to build Exim from its C source code and so will need a C compiler, see GNU section in the resource list below.

    Qmail

    Qmail is a "plug-in" replacement for Sendmail and there is a lot (too much?!) documentation on the web site about controlling UBM.

    Note that it is likely that you will have to build Qmail from its C source code and so will need a C compiler, see GNU section in the resource list below.

    Microsoft NT Exchange

    With recent versions, turning off third-party relaying is a point and click exercise, followed by a restart. The Microsoft Support Website has the full details, but basically the problem can only be solved if you're running Exchange Server 5.5 with service pack 1 (or greater), if you have an earlier version, you will have to upgrade.

    The fix to be applied is made using the Exchange Server Internet Mail Service, opening the properties for 'Routing' page. If you have the required version this page will have an additional button called [Routing Restrictions]. There are three options to control relaying of email, the second option is likely to yield the best results:

    • require authentication
    • limit by originator's IP network(s)
    • limit by server interface address

    This last option is for multi-homed servers or firewalls. Unless you're running a firewall (in which case ensure you protect the internal interface, as this is will be the open relay), then IP forwarding ("routing") should be turned off for this option. There is also the option of putting a block to stop specific networks from sending email to you, which may be useful for blocking dialups or hosts which persistently send unwanted email to you.

Useful Resources

These links are provided on the basis that they have at some time or another been useful to customers or our ourselves...
The mention of specific products and/or references to specific web sites does not mean that PSINet vouches for the accuracy or effectiveness of the products or advice contained therein. Also, we probably can't supply or sell any products mentioned, and as far as the author knows there is no financial connection between PSINet and any companies or organisations listed here. If you do have success with any of them, or can suggest any others, we'd be pleased to hear from you.

http://spam.abuse.net

    This is a central collection of junk email control and reporting facilities. The specific page for MTAs covers a wide range of systems. Claus Aßmann's information has been found to be the most useful for fixing older incarnations of Sendmail.

ORCA.BC.CA Dial-up User List

    This is a list of dial-ups, so if you find that you get a large quantity of junk from one particular ISP's dial-up customers, you might be able to find their network numbers here.

Mail Abuse Protection System

    This was discussed earlier in this document, suffice to say it is a register of email systems which are open relays and whose operators have been given every chance to fix their systems and failed to do so.

Open Relay Blocking Service

    ORBS is an alternative to the MAPS/RBL project, though much more informal, as any open relay can be added without giving the owners of the blocked email machine much notice.

    This is probably the most restrictive of the mail blocking systems, as it will list servers just for being vulnerable to attack - even if they haven't actually been used to send large quantities of UCE.

MailShield

    This is a commercial product and was bought by one customer when their antique but uniquely-configured email server was being abused, thus they couldn't simply upgrade to a newer sendmail.

    Quote: MailShield is a software plug-in for your current mail server, adding powerful filtering, rejection and programmability features to your existing setup.

GNU

    A variety of tools are available here, most significantly the C compiler which may be needed to build Sendmail, Exim or Qmail.

Spamcop

    An online "spam" checking and reporting service. This is very useful if you are the recipient of unwanted commercial email.

If you have comments about this document, or would like to contribute to it, please send them to webmaster@uk.psi.com.

back

 




[ Print the page]
Home | Contact | Help | Feedback




Copyright © PSINet Europe All rights reserved.
Disclaimer | Credits