Spamming Issues and Topics

Everyone is complaining about spamming, it seems, and there is good cause. The resources of your company or institution are now being used without your permission by others for financial gain, to offend your user community, or even to cause damage to your organization's image. Your actions in providing Internet access for your organization were simply intended to make it possible to make legitimate use of the Internet and the facilities it offers.

However, many people who are complaining about spamming aren't aware that spamming is just one of several types of e-mail abuses that are occurring. Further, it can be difficult to get help in resolving your e-mail problems if they are generalized simply as spamming when they are in fact something else. The following discussion is intended to talk about internet mail abuses, clarify some of the terms used to describe them, and explain -- to some extent -- what can and cannot be done about these abuses.

Note:
VM TCP/IP development will continue to address mail spamming and other issues associated with the misuse of e-mail systems on an ongoing basis. For information about mechanisms available to help you address spamming problems in your environment, consult the appropriate TCP/IP Planning and Customization publication for the level of TCP/IP for VM used in your environment.

Note also that some mechanisms for addressing spamming issues were originally introduced in TCP/IP Function Level 310 via APAR support (Reference Information).

The descriptions that follow define some of the terms that will be used throughout this discussion. Hopefully, these definitions will also clarify some terms which are often misused when e-mail problems are described.

Spamming

Spamming is the act of sending mail to a large number of e-mail addressees, and is often compared to the term "junk mail" used to describe similar activities performed via postal services. However, there is another activity that is labelled as spamming. This is when a single host is flooded with mail in an attempt to cause inconvenience and expense. This aspect will be discussed further under the Denial of Service topic.

Spam

Spam is used to refer to a single or multiple pieces of mail that are perceived by the recipients to be unsolicited, unwanted, and generated as a result of spamming.

Spoofing

The act of connecting to a mail transfer agent (SMTP is one example) and falsifying the information you are required to provide, in order to cause mail to appear to have come from someone other than yourself.

Mail Forwarding

The process of receiving and sending on mail that is directed to your mail server but is ultimately destined to somewhere other than your own site.

Host

A computer connected to a network, which provides an access method to that network. A host provides end-user services and can be a client, a server, or a client and server simultaneously.

Note that when a connection is made on the internet, it is usually from one host to another. Specific user information is not provided as part of the connection in many transactions, such as web activity (although a web browser may provide it if this information is solicited).

Postmaster

The person (or persons) responsible for ensuring the mail system at a site is working. A postmaster may be the person who installed the product that handles the mail, or someone that has very little experience with computers and computer mail. Experience has shown the postmaster can be most anyone.

Spamming is an activity usually used to solicit business. It is a mass mailing of information to a large number of recipients, some of whom may be interested in receiving the particular piece of mail. With regard to mass mailings, there varying degrees of concern as to whether the mail reaches the appropriate recipients, or as many recipients as possible.

There are companies that exist solely to perform mass e-mail mailings on the behalf of their customers. There are also companies whose business it is to create mailing lists that these bulk e-mail advertisers use. Some generate as many e-mail addresses as possible; others attempt to generate address lists that have a particular market focus. When people use their web browsers, information can be collected which ties the person doing the browsing to the information they were browsing. Many sites sell this information to advertisers, knowing the advertisers hope to contact people that have expressed an interest in similar products or services by way of the sites they have visited.

When you address spamming problems, it's important to consider that one person in your environment may consider a piece of mail to be spam, while this same mail may be considered valuable to someone else. There are no explicit rules that determine what is and is not spam. Also, a person who gets an objectionable piece of mail may have been the only target of that piece of mail.

For example, consider the case when a user points his web browser to a site whose content is unknown. Some time later, this site sells that user's e-mail address to another site which has similar offerings, and this other site then sends a piece of mail to that user. Is this mail spam, or is this intelligent marketing? If the e-mail was for a product the user wanted, and he got the mail because he visited a competitor's site, he might appreciate the intelligence of this marketing. However, if a piece of mail is sent to every one of 10 million hosts that used an Internet search engine on a particular day, it would be hard to say that mail would not be spam, even though there may be a few people interested in the content of the mail.

Help! I've Been Spammed. What Can I Do?

Presented below are a number of actions users and postmasters can take when they attempt to solve problems that arise from the proliferation of bulk e-mail advertising. These actions reflect varying degrees of time and investment. Note that the ordering of these actions is not intended to imply any weighting or preference of one action over another.

Complain to the local postmaster

If a user is receiving mail he doesn't want to be bothered with, he can lodge a complaint with the postmaster of his local mail system. Without this action, the postmaster may not be aware that a problem exists.

Complain to the postmaster of originating site

This is most appropriately done by the local postmaster, as a spokesperson for the local mail system as a whole. This approach can be effective if there the abuse of the mail system is isolated, and is performed by a user on the originating system. Postmasters are generally responsible for policing their own domain and denying e-mail and other Internet rights to users who violate rules established for their site. However, if the remote site is in the business of sending the e-mail associated with complaints, you can probably anticipate the level of cooperation that will be extended to you.

Attempt to prevent incoming mail

Preventing mail from being delivered is tricky, and is prone with various pitfalls. The most significant problem is usually establishing the criteria that determines whether you want to handle, or not handle, a piece of mail. Another significant problem is assessing the effect your actions will have on the Internet community when you decide to not deliver mail.

One way to control access to your mail facility is to locate it behind a firewall. The advantage of this approach is that you can completely insulate your local network from the outside network. Whatever rules you implement to allow access through the firewall can be applied to your whole family of internet applications. One disadvantage to using a firewall is the expense to create and support it.

Another way to control access to your mail facility is to take advantage of any configuration options it may provide to deny or limit mail service. As you might expect, this capability varies widely among products.

Attempt to filter incoming mail by content

Another technique to reduce the volume of e-mail experienced by user at a site is to implement a method of scanning the mail content and discarding the mail rather than causing it to be delivered to the intended recipient.

Always try to keep in mind that the mail you do not want to receive may not be coming from the host that is (directly) providing the mail. For example, if host N.M.NET is in the business of sending bulk e-mail, host A.B.COM may decide to never let 9.10.11.12 connect to his system. If the e-mailer decides to bounce his mail off X.Y.EDU, however, we would have to prevent 5.6.7.8 from connecting to our host to prevent the mail from arriving. The use of this third party for delivery is called "mail forwarding". EMail processing of this type makes it impossible for postmasters to control bulk e-mailing by preventing offending hosts from connecting to their host.

Spoofing is the practice of attempting to falsify the origin of a piece of mail. When the sender of the mail, the client, connects to a mail transfer agent (such as SMTP) he is required to provide his mail domain (n.m.net). There is nothing in the protocol that addresses what actions a mail transfer agent should take when the provided domain information is not correct. However, such an agent can verify the client providing the mail is who he claims to be. Other than including that information in the piece of mail, there is little else the protocol specifications allow at this time.

Just as there are bulk e-mailers, there are hosts that offer "anonymous" mailing facilities. In these hosts, mail is received and manipulated so that part of the header information is excluded when the mail is sent onward. In this manner, a full return path to the mail originator is not present within the mail itself. This is a direct violation of the specification, but the users of this facility are not concerned with this point. Their reason for remaining anonymous may be that they are violating Internet courtesy and decency tenets, so do not wish to have others discover their identity.

There is little that can be done about spoofing. When you are the victim of being spoofed -- from the point of view that someone sent a piece of mail that appeared to come from your host, but didn't -- there is nothing you could have done to prevent it.

For example, assume your domain is A.B.COM. Someone at N.M.NET wants to send a piece of inflammatory mail to a user a X.Y.EDU. He merely connects to the mailer at N.M.NET and falsifies who he is and who the mail is from. If the mail transfer program at N.M.NET does not check the connecting client and insert factual information about that client in the e-mail, it can appear that the mail originated at A.B.COM. When the user at X.Y.EDU complains to his postmaster and gives him the piece of offending mail, the postmaster will contact the postmaster at A.B.COM with the complaint. You may know that this mail did not originate with you site via logs and such, but your time has already been wasted and your sites image is sullied. Furthermore, you don't even know where the mail came from. Unless EACH and EVERY host on the Internet prevents spoofing, you can not stop it from occurring, mostly because your site's resources were never used to create the spoofed piece of mail.

Mail forwarding is a routine operation with regard to e-mail processing. The Internet mail system has always been based on the concept that the ultimate destination for a piece of mail may not be operational, but the mail must not get lost. Furthermore, it is a normal situation to have many final destinations for mail be hosts that are not publicly known to the Internet community. To accomplish this, most mail transfer agents operate on the principles of "store and forward " and "mail gateways".

With "store and forward" processing, a piece of mail that's delivered to the local host is received and the client is informed that the mail has been saved. The local host then attempts to deliver the piece of mail, either locally if appropriate, or by determining the next mail transfer agent that is offering to accept mail for the recipient(s).

Mail gateways provide a post office-like facility where all mail for a particular group of users is funneled to a single mail system. Then, either users contact that system on an individual basis to obtain their mail, or the mail system knows where to next send the mail, so that the designated recipient will receive it.

Before the use of name server MX (mail exchange) records became widespread, it was often necessary to provide a list hosts in order to deliver one's mail. Mail was passed from one host in this list to the next (that is, to the next "hop"), until it was delivered to the intended recipient. This method of mail processing was called "source routing", and was necessary because not all hosts were known within the Internet domain. Thus, mail had to get to a host close enough to the mail's next hop, in order for the host name for that hop to be recognized as a valid host. Any number of hops may have been necessary.

Today, the need to specify routing hops during mail delivery is minimal. If all Internet environments were maintained in an up-to-date manner, there would be no need for source routing, and the capability would be useful only for testing. However, some Internet hosts make use of this delivery technique in order to circumvent processing that other hosts may be using in order to limit their activities.

A Mail Forwarding Example

Assume the organization at A.B.COM is tired of getting all sorts of "junk" mail from the N.M.NET host. They modify their system so that it will not accept any mail from N.M.NET by prohibiting a connection from 9.10.11.12. N.M.NET can get around this by sending the mail destined for A.B.COM through the host X.Y.EDU. X.Y.EDU is now being used (or possibly, abused) as a mail relay. This can be accomplished using one of two different forms of mail addressing techniques, source routes and the "%-hack".

In either case, X.Y.EDU resources are being used to process mail that is not destined for itself. A.B.COM is unable to stop the mail from arriving, since they still want to receive mail from X.Y.EDU. Most likely, neither A.B.COM nor X.Y.EDU are pleased with the mail being generated by N.M.NET. In fact, the organization at X.Y.EDU may not even be aware that mail is being forwarded through their host; they may only be comprised of this if the postmaster at A.B.COM contacts them and ask them not to allow the forwarding to continue.

X.Y.EDU now has the need to stop mail forwarding. It is unlikely, however, that they want to stop all mail forwarding. They may have hosts inside their intranet that need to route mail through X.Y.EDU and need X.Y.EDU to route mail on to them. This means there may be any number of rules that X.Y.EDU may want (or need) to use to control who can forward mail.

The mailings by N.M.NET will not be thwarted until every host on the Internet has implemented controls to avoid being the target of its mail-forwarding activities. In this case, the most that a single site can do is to regain control of which Internet hosts will be allowed to forward mail through it.

Denial of service attacks are the result of malicious overloading of your system or exploitation of known defects in the software you are running. There are a number of general kinds of attacks.

One method is when an outside party attempts to crash all, or part of, of your system by exploiting a software defect. These attacks are more often seen in the Unix world, only because information about defects in the Unix world seem to be more widely distributed, not because of any inherent weakness. Keeping your software up-to-date is usually the best defense, but can, on occasion, open your system up to attacks introduced by revised code.

Flooding mail to a single host/user is an attack often called spamming. It is usually done in retaliation to spamming or other slanderous activities by another party, and has even been reported as an attempt to destroy a business by destroying their ability to operate via the Internet. Often, a user who is tired of receiving junk mail from N.M.NET decides he will return 100,000 copies of the piece of just received junk mail.