Preventing Spams and Relays
The Internet has been around since the 1970s with people using it mainly for electronic mail (e-mail). This is still true even today as we see increasing numbers of multimedia-based applications on the Internet. People still use e-mail more than web browsers and file transfer programs. The reason is simple—it is a low-cost yet effective method for communicating with others all over the world. More and more people are getting onto the Internet, and the first thing they do is get an e-mail address.
Realizing this, certain individuals and even organizations have taken the opportunity to send unsolicited e-mail to Internet users. Most of this mail is commercial advertising. They send thousands of copies of the same message to a list of e-mail addresses obtained from either Usenet postings or companies' home pages. Such action is called spamming.
The consequence of spam is that the receiver ends up paying for the cost of the e-mail, since the ISP (Internet Service Provider) usually charges on the basis of connect time and downloading mail takes time. At companies where each employee has an e-mail address and the company has a fixed line for e-mail, that line can become quite expensive if it is targeted by spammers.
To hide their identity, spammers usually send from a forged e-mail address and use mail servers that have not been configured to prevent such activities. Relaying, as it is usually called, will cause the targeted e-mail server to send mail on behalf of the spammer to hundreds or even thousands of users. Spamming can seriously affect the performance of the mail server and cause massive bandwidth loss for the company affected. Not only will the mail server's performance be affected, but recipients of the spam will be given the impression that the company is in business with the spammer.
For more information on this, visit the number one anti-spam site on the Internet at http://spam.abuse.net/.
My company was recently the target of a spammer who used our mail server as a relay. The spammer was using an account from a well-known service provider, and my guess is that it was probably a trial account. I had not installed any preventions against such attacks and was thus targeted. When I discovered the attack, I dropped all my current work and began searching for a solution. I started by looking at the Sendmail home page (http://www.sendmail.org/). It had links that led to more tools and tips for spam prevention. I chose to implement the solution based on the smtpd package from Obtuse Systems Corporation for the following reasons:
smptd is a small package with only two executable files to manage and one configuration file to tweak.
It works nicely with my mail server (Sendmail v8.8.8).
The configuration file is very flexible and easy to configure.
As of this writing, the smtpd package is at version 2.0 and can be obtained from ftp://ftp.obtuse.com/pub/smtpd/smtpd-2.0.tar.gz.
smtpd works with other MTAs (Mail Transport Agent), but I have been using only Sendmail. The latest Sendmail can be retrieved from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.9.1.tar.gz.
Note that you must have a working MTA before installing smtpd. It acts only as a mail proxy, storing and forwarding mail to other MTAs for the actual delivery.
Briefly, here's how smtpd works: the smtpd daemon runs and accepts mail instead of your regular mail server. It accepts mail from the Internet as well as your own domain. smtpd can be configured to reject mail based on several criteria:
IP address of the sender
Host name or domain of sender
E-mail address of sender
E-mail address of receiver
Based on the configuration file, the mail is either rejected or accepted and spooled. The second program, smtpfwdd, will do the actual forwarding of the spooled mail to the MTA (Sendmail in this case).
Once you've obtained the package, unarchive the files to a directory. Assuming the files are to be put in the directory /usr/src/smtpd-2.0, do the following:
cd /usr/src tar xvzf ~/smtpd-2.0.tar.gz cd smtpd-2.0
Now, by typing ls, you'll see many files and subdirectories. Be sure to read README and INSTALL as these files contain valuable information on the installation of the mail proxy.
To compile the package, do the following:
Choose a user and group for running the smtpd daemon. Your choice must be defined as a trusted user in the sendmail.cf file. I chose to use the user daemon. If you are not sure what to use as trusted user, check the /etc/sendmail.cf file for lines like this:
# Trusted users # Troot Tdaemon TuucpIn this example, the trusted users are root, daemon and uucp. Do not use root. smtpd works without any root privileges; thus, it is more secure to run it as some other user.
Create a directory in which smtpd can store spooled mail before smtpfwdd processes it. Change permissions and also the user/group of that directory so only that user has full rights to it. If you put it in the /home/smtpd/spool directory, execute these commands:
mkdir /home/smtpd mkdir /home/smtpd/spool chown -R daemon.daemon /home/smtpd chmod 700 /home/smtpd ls -lad /home/smtpdThe output from ls will look like this:
drwx------ 3 daemon daemon 1024 Mar 26 01:34 /home/smtpd/
Edit the Makefile in the source directory to reflect your choice. The changes we need to make for our example are as follows:
SMTP_USER = daemon SMTP_GROUP = daemon SPOOLDIR = /home/smtpd SPOOLSUBDIR = /spool EHLO_KLUDGE=1 JUNIPER_SUPPORT=0 #LD_LIBS=-lresolv CHECK_IDENT = 0EHLO_KLUDGE is needed to fix a bug in Netscape Communicator. JUNIPER_SUPPORT is set to 0 unless you're using Obtuse's Firewall Kernel. LD_LIBS is commented out, as my Linux distribution does not require the external library libresolv. CHECK_IDENT has been set to 0 to disable IDENT checking. I personally do not believe in IDENT checks—they take time and do not return any useful information.
By default, the Makefile has been configured to be compiled on Linux, so no other changes need to be made.
In the source directory, type make to compile smtpd and smtpfwdd.
Once the compilation is finished, you will find two executable files in the directory. Copy them to another location in your PATH. To copy them to the /usr/local/sbin directory, type:
cp smtpd /usr/local/sbin cp smtpfwdd /usr/local/sbin
Create a few subdirectories under the /home/smtpd/ directory by typing:
cd /home/smtpd mkdir etc usr mkdir usr/lib mkdir usr/lib/zoneinfoBecause smtpd does a chroot to the directory /home/smtpd, we need to copy (or make symbolic links) into this directory some files that are required for the proper execution of smtpd/smtpfwdd. The files and the directory in which each should be located are:
/etc/resolv.conf -> /home/smtpd/etc/resolv.conf
/usr/lib/zoneinfo/localtime -> /home/smtpd/usr/lib/zoneinfo/localtime
The file resolv.conf is needed so that smtpd can do DNS queries (look up IP addresses of hosts). The file localtime has your time zone setting and is required to put the proper time stamp on e-mail. The location of localtime may be different on your system, so you'll have to find the exact path and create a duplicate under the /home/smtpd directory.
Configure smtpd and smtpfwdd to replace the running mail server.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script