Dealing with Spam being forwarded by your system
By now most users are familiar with "spam." This page talks about steps that everyone who runs a mail system needs to take. They prevent your system from becoming a tool that spammers can use.
Do not think "I'm just a little departmental server. No one will notice me." We've seen attacks on a little departmental server. It took them several days of work to recover.
We have had one case where an ISP disabled all email access from Rutgers because of a single host that was not following the rules. For this reason, we must insist that all system administrators fix their systems. We can give you at most a few days to do so once a problem has started.
If you are not prepared to deal with issues like this, we urge you not to run a mail server. OIT would be happy to handle email for any user or department at Rutgers.
Most Unix workstations have a mail server turned on by default. If you are not prepared to handle these issues, you should disable your mail server and read mail on an OIT system. See disabling sendmail for instructions on doing this.
Unless you disable mail service, there are two things you need to do:
- Configure your mail system so it will not relay mail for non-Rutgers sites
- Know how to deal with attacks
First, let's define relaying. When a mail system gets mail, it checks to see whether the destination address is on your machine. If so, it delivers the mail. If the destination is on another machine, it sends the mail to that machine. That's called relaying.
Normally there's no reason someone outside Rutgers would use your machine as a relay. They can just as well connect directly to the destination machine.
The main reason for relaying is to support PC's. A lot of PC mail software is incapable of dealing with all the complexities of the Internet. So when you send mail, your PC probably wants to connect to a central server and let it do the actual delivery. Technically this is relaying, because the system gets mail from your PC and it's supposed to relay it to a third site.
Unfortunately, Spammers abuse this feature. They connect to your machine, and then send thousands of messages addressed to people at AOL or some other site. Unless you have done something to stop it, your machine will relay the mail. Sometimes they even set it up to make it look like the mail started on your machine. Then you'll get irate complaints from thousands of angry users.
The safest solution is to disable relaying completely. However if people in your department are using POP or IMAP on PC's, they may be using your machine to deliver mail for them. In that case, you should restrict relaying so that you only relay for machines in your department.
Later in this document there are specific instructions on how to control relaying for Mercury. Mercury is widely used at Rutgers for departmental Novell servers. For all other mail systems, see the list of instructions at the MAPS project . They have a description of the issues, and a page summarizing instructions for controlling relaying in just about every mail server known to man.
Controlling relaying for Mercury
Most users are better off not running a mail server. If you are not prepared to deal with issues such the ones discussed in this document, you should make sure that you are not running a mail server.
Unfortunately, most Unix systems run sendmail by default. So if you're using a Unix workstation and you are not prepared to act as a mail administrator, you should disable sendmail, and read mail on another system. You could use either a departmental server, or one of the OIT systems.
For Solaris 2, and other operating systems based on System V, there will be a startup file for sendmail in one of the rcN.d directories. To find it, do the following:ls /etc/rc*d/S*sendmailYou'll see one of more files such as /etc/rc2.d/S88sendmail.
First stop sendmail. To do that run the file with the "stop" option. E.g. if your file is the one just listed, do (as root)/etc/rc2.d/S88sendmail stop
or if that doesn't work, possibly
sh /etc/rc2.d/S88sendmail stop
Now edit the file. Look for the actual sendmail command. It will look something like this:/usr/lib/sendmail -bd -q1h;Remove the -bd. This will cause sendmail to continue running for sending outgoing mail, but not to listen to incoming mail.
Finally, restart sendmail. Use the start option, e.g./etc/rc2.d/S88sendmail start
As of Solaris 9, the sendmail command is parameterized. Instead of changing the command as described above, you will want to change the definition of "MODE". I.e. find the lineMODE="-bd"and change it toMODE=""
Finally, you may need to send email to hostmaster@tdmx requesting them to change your workstation's MX record to point to the system where you plan to read email. Note that this email should normally be sent by your departmental network administrator. Your network administrator should know how to check to see whether the MX is already set properly.
[Hint: do "host XXX", where XXX is the name of the host. It should say "XXX mail is handled by YYY" where YYY is the system on which you read mail. If you don't have host, try "nslookup -query=mx XXX". Look for "mail exchanger = YYY". If you don't have either program, find someone with an account on rci, andromeda or clam and use "host" there.]
Note that disabling sendmail in this way will not keep you from sending mail from your workstation. It will simply prevent you from receiving new mail. However if you continue to send mail from your workstation, you must make certain that you have an MX entry pointing to the machine where you read mail. Otherwise when people respond to your email, you won't get it. You will also need to make sure that your username is the same on your machine and the machine on which you read mail. Otherwise replies won't work. If you can't arrange that, then make sure you don't send mail from your own workstation. Do all of your mail on the system where you read mail.
If you are running a version of Unix based on Berkeley, e.g. SunOS 4.1.x, you will need to find where sendmail is called from /etc/rc* and remove the line that calls sendmail. One approach is to dogrep sendmail /etc/rc*Because of differences in startup files, I can't give specific instructions for this case.
[NOTE: This section hasn't been checked for several years. It may well not apply to current versions of Mercury.]
Mecury 1.40 contains a facility to disable or limit relaying. First make sure you are running 1.40 or later.
For full documentation on the Mercury options, run the program mguide.exe, which is part of the distribution.
Relay control is done by statements in the MERCURY.INI file, in the [MercuryS] section. Here is an example. Note that this is not the whole MERCURY.INI file. It's just the part to control relaying:[MercuryS] Relay: 0 Strict_relay: 1 Allow : 220.127.116.11 Allow : 18.104.22.168
These commands will disable relaying except for systems at Rutgers. 128.6 and 165.230 are the two Rutgers networks. Note that IP addresses at Rutgers will be changing. When they do, you'll need to update this information.
The command "Relay: 0" turns on control of relaying. In theory that's all you need. However in the one case we had, that didn't turn out to be enough. "Strict_relay: 1" restricts relaying so that it is only permitted from IP addresses listed in Allow statements.
You have two choices: either use the example above, or put in Allow statements that just list your department's PC's. It's better to specifically list your department's PC's, since that protects you from badly configured mail servers elsewhere at Rutgers.
If you want to limit relaying to your department's PC's, put in an Allow statement for each machine, or one for your whole network. 0 bytes act as "wildcards". So if your department uses subnet 128.6.4, you can sayAllow : 22.214.171.124
That will allow all addresses starting with 128.6.4. If your subnet starts with 165.230, this isn't perfect. Subnets starting with 165.230 actually include only 64 hosts. Unfortunately Mercury can only deal with 256-host groups. So you'll have to allow the entire 256-host group in which your subnet falls. For example, suppose your subnet is 126.96.36.199. That is a 64-host range from 188.8.131.52 to 184.108.40.206. You'll have to list 220.127.116.11. This includes the other three subnets starting with 165.230.3 also. However it's a fairly good approximation.
For more information, contact
Last updated: Tuesday, 13-Jun-2006 13:16:01 EDT
© 2006 Rutgers, The State University of New Jersey. All rights reserved.