How to stop Spam in Sendmail

Posted on 8:36 PM by Bharathvn

Spam
The scourge of the Information Age is unsolicited mail, or spam. Spam makes up a large part of email traffic, and the existing techniques of fighting it do not always produce the results desired.

Thus, one of ways to fight unwanted mail is to prohibit incoming mail from servers found guilty of sourcing spam messages. But spammers keep finding new ways to get around the prohibitions, including using public or zombied servers.

If your server has been zombied and is used to send spam, this exposes you to the following dangers:

Extra traffic expenses if you pay by volume

Extra processor workload because spam mailings are usually carried out on a mass scale and consume a lot of the processor time, thereby loading the communication link

Moreover, your server may be entered on a spam blacklist, resulting in all your outgoing correspondence being filtered out and not reaching the recipients. The latter can be viewed as a successful DoS attack against your mail service.

Blocking Incoming Spam
Unsolicited incoming mail has the following undesired consequences:

It incurs extra traffic expenses, as already mentioned.

The attention of your workers or network users is distracted by the irrelevant mail.

Spam messages are often bulky, requiring additional disk space for storing them.

There are many more ways to fight spam than those described here. But those described are sufficient for you to start taking steps against electronic junk mail.

Filtering Servers
The sendmail program has an option to filter out servers, from which the spam is received. The best way of doing this is to add a prohibiting directive to the sendmail.mc file. The problem is, however, that this directive has a different format for different sendmail versions.

Thus, for version 8.10 it looks like the following:

FEATURE(dnssbl, 'spam.domain.com',
'550 Mail not accepted from this domain')dnl

For version 8.11, it looks like this:

HACK('check_dnsbl', 'spam.domain.com', ", 'general', 'reason')dnl

In both directives, the spam.domain.com item has to be replaced with the name of the domain whose mailings you want to block. This method is ineffective, because often quite innocent servers would be on the receiving end of such prohibitions.

Once, my software sales server was placed on a spam list. Those were the times when a server could become blacklisted deservedly or for no reason. When I would mail the registration keys to the people who bought my software, about 10% of the messages would be returned marked as spam. This kept some of my customers from using the software they bought. This went on for a month until spam blacklists were judged to be ineffective.

Filtering Messages
More precise filtering involves blocking messages by their contents. A special program analyzes all information passing through the server and looks for typical signs of spam mailings. If a message is judged to be spam, it is deleted.

This method is the most effective; however, it is difficult to tell by the text of a letter whether it is spam. Hackers are constantly looking for new ways to circumvent such filters, so the percentage of filtered out spam is not high. The program can be configured to delete all messages, in which "buy," "sell," and other words typical for spam occur. However, there is a chance that this filter will delete some of your good mail.

I will not be recommending any specific spam-filtering programs, because I don't know any that would offer an ideal solution. But if you decide to use such a program, you may as well take a look at SpamAssassin (spamassassin.apache.org). It implements many checks to effectively detect undesirable messages.

In addition, you can modify the value of the MaxRcptsPerMessage parameter of the sendmail server, which sets the maximum number of message recipients. More than 100 recipients is a good indication of a spam message. It is not, however, always so, because mailing lists in some organizations can have 1,000 employees. In this case, important messages can be lost. To prevent this, the mail program should be configured to send messages in batches of no more than 20 recipients at a time.

Blocking Spam Remailing
When configuring your mail server, you should make it unavailable to be used by hackers for mailing spam. The following configuration settings will make using your server for mass mailings ineffective:

By default, SMTP does not require authorization, so any user can connect to the server and send mail. This can be prevented by doing one of the following:

Configure the firewall to prohibit from connecting to the SMTP port those users who do not belong to your network. This defense is used most often by providers and administrators of private and corporate networks. You should have no problems implementing this method, because I have considered it several times in this book.

Allow mail to be sent only within a certain period (e.g., 10 minutes) after receiving mail by POP3. This allows the server to authorize the client when the mail is checked and to use the obtained authorization data for creating a firewall or some other permission to access SMTP. When this permission is active, mail can be sent from the authorized IP address.

Use SMTP authorization. The original mail-sending protocol did not contain the user-authentication requirement, so not all servers support this feature. But sendmail and other powerful mail programs offer an SMTP user-authentication feature.

In addition, you should disallow a large number of messages to be sent from the same IP address. In this respect, 20 messages is an acceptable number. A user should not be able to send more than 20 letters within 10 minutes.

Disallow the mailing of letters to a large number of recipients listed in the CC field.

There also are other methods, but those just described ought to be enough.

The more recent sendmail versions by default permit remailing of messages only from the computers specified in the /etc/mail/access file. The contents of the file are shown in Listing 8.2.

Listing 8.2: The /etc/mail/access file


# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file).
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# By default, we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY





You can place the following directives into this file to allow mailings only from the local network computer or from the server:

localhost RELAY
your_domain.com RELAY

This method is effective only when the integrity of the local network's computers and servers has not been compromised. But if hackers obtain access to the network, they can mail any sort of spam from user accounts. This is something that cannot be avoided. If there is at least some sort of permission, hackers can take advantage of it, so your task is to make it difficult for them.

It is not always possible to prohibit mailings; therefore, you have to resort to other methods — for example, making users check their POP3 mailbox before mailing messages. This can be implemented with the help of the Pop-before-SMTP service (popbsmtp.sourceforge.net). The service checks the /var/log/maillog message log file and allows mail to be sent only if it finds that there was a successful POP3 authorization within a certain period.

The POP3 authorization method, however, has one significant shortcoming: If there is an anonymous proxy server or a masking firewall in the route, via which the letters arrive, packets will arrive with a different IP address. This means that all users connected using the same proxy or firewall are automatically considered authorized. Consequently, a search in the log by the IP address will not provide 100% protection.

The most preferable is the SMTP authorization method (SMTP AUTH), described in RFC 2554. The sendmail service supports this extension starting with version 8.10.

If you decide to use SMTP AUTH, make sure that the user's mail clients are configured to authenticate at the server.