How to Stop Spam Bombing: Focusing on Email Server Configuration

Spam bombing, also known as email bombing, is a malicious attack where a victim is flooded with an overwhelming amount of spam emails. This can bury important emails, render email accounts unusable, and even be a precursor to other attacks. This article will focus specifically on configuring your email server to mitigate spam bombing, providing practical examples and configurations to bolster your defenses.

• Rate Limiting: A First Line of Defense
• Strengthening Authentication: SPF, DKIM, and DMARC
• Greylisting: Delaying the Inevitable (and Catching Spam)
• Advanced Filtering with SpamAssassin and ClamAV
• Monitoring and Logging for Early Detection

Rate Limiting: A First Line of Defense

Rate limiting is a crucial technique to prevent a single source from overwhelming your email server with a barrage of spam. By restricting the number of emails a particular IP address or sender can send within a given time frame, you can effectively slow down or even halt a spam bombing attack. Most modern Mail Transfer Agents (MTAs) like Postfix and Exim offer built-in rate limiting capabilities. Let’s explore how to implement rate limiting using Postfix, a widely used MTA. Postfix offers several mechanisms for rate limiting, including connection limits, sender limits, and recipient limits. Connection Limits Connection limits restrict the number of simultaneous connections a single IP address can establish with your server. This can prevent spammers from quickly establishing multiple connections to send spam. Example: Limiting simultaneous connections in Postfix

smtpd_client_connection_rate_limit = 5

This setting in your /etc/postfix/main.cf file limits each client IP address to a maximum of 5 simultaneous connections. After applying this change, you must restart Postfix for the changes to take effect.

sudo systemctl restart postfix

Expected Result: Any IP address attempting to establish more than 5 simultaneous connections will be temporarily blocked. Sender and Recipient Limits Sender and recipient limits control the number of emails a sender can send and the number of emails that can be sent to a specific recipient within a given timeframe. These are powerful tools to combat spam. Example: Limiting sender and recipient rates in Postfix

smtpd_client_message_rate_limit = 50
smtpd_client_recipient_rate_limit = 50

These settings, added to /etc/postfix/main.cf, limit each client IP address to 50 messages per minute and 50 recipients per minute, respectively. A client exceeding these limits will be temporarily throttled. Again, restart Postfix after making these changes:

sudo systemctl restart postfix

Expected Result: A client exceeding the message or recipient rate limit will encounter temporary delivery failures, preventing them from overwhelming your server. Another valuable technique is to use Postfix’s access control lists (ACLs) to implement more granular rate limiting based on sender domain or email address. This is done using the check_sender_access restriction. Example: Rate limiting based on sender domain First, create a file, for example, /etc/postfix/sender_rate_limits, with the following content:

example.com     REJECT You are sending too much mail from this domain.
.example.net    REJECT You are sending too much mail from this subdomain.

This file defines that any email originating from the example.com domain or any subdomain of example.net will be rejected with the specified message if they exceed the default rate limits. The dot before example.net indicates that all subdomains of example.net are affected. Next, add the following line to your /etc/postfix/main.cf file:

smtpd_sender_restrictions =
    permit_mynetworks,
    reject_sender_login_mismatch,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/sender_rate_limits,
    permit

Finally, create the hash database file from the text file and restart Postfix:

sudo postmap hash:/etc/postfix/sender_rate_limits
sudo systemctl restart postfix

Expected Result: Senders from the specified domains or subdomains exceeding the rate limits will receive a rejection message, effectively preventing them from sending large volumes of email.

Strengthening Authentication: SPF, DKIM, and DMARC

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) are essential email authentication protocols that help verify the legitimacy of email senders. Implementing these protocols significantly reduces the effectiveness of spam bombing and phishing attacks by making it harder for spammers to spoof your domain or legitimate senders. SPF: Verifying Sender IP Addresses SPF allows you to specify which mail servers are authorized to send emails on behalf of your domain. When a receiving mail server receives an email claiming to be from your domain, it checks the SPF record published in your DNS to verify if the sending server’s IP address is authorized. Example: Creating an SPF record An SPF record is a TXT record in your DNS zone file. Here’s an example:

yourdomain.com.  TXT  "v=spf1 a mx ip4:192.0.2.0/24 include:thirdparty.com -all"

Let’s break down this record:

• v=spf1: Specifies the SPF version.
• a: Authorizes the IP address(es) of the hosts listed in the A record for yourdomain.com.
• mx: Authorizes the IP address(es) of the hosts listed in the MX record for yourdomain.com.
• ip4:192.0.2.0/24: Authorizes all IP addresses within the 192.0.2.0/24 CIDR block.
• include:thirdparty.com: Includes the SPF record of thirdparty.com, authorizing any servers listed in their SPF record. This is useful for third-party email providers.
• -all: Specifies a hard fail for any emails originating from servers not listed in the SPF record. Other options include ~all (soft fail) and ?all (neutral). Using -all provides the strongest protection against spoofing.

Expected Result: Receiving mail servers will check the SPF record of yourdomain.com. Emails originating from unauthorized servers will be flagged as potential spam or rejected outright, depending on the receiving server’s configuration. DKIM: Adding a Digital Signature DKIM adds a digital signature to your outgoing emails, allowing receiving servers to verify that the email has not been tampered with during transit and that it truly originated from your domain. This signature is generated using a private key and verified using a public key published in your DNS. Example: Implementing DKIM with OpenDKIM (Postfix) First, install OpenDKIM:

sudo apt update
sudo apt install opendkim opendkim-tools

Next, generate a DKIM key pair:

opendkim-genkey -t -d yourdomain.com -s mail

This command generates two files: mail.private (the private key) and mail.txt (containing the public key). The -d option specifies your domain, and the -s option specifies the selector (mail in this case). The selector is used to distinguish between multiple DKIM keys for the same domain. Move the private key to the OpenDKIM keys directory and set appropriate permissions:

sudo mv mail.private /etc/opendkim/keys/
sudo chown opendkim:opendkim /etc/opendkim/keys/mail.private
sudo chmod 600 /etc/opendkim/keys/mail.private

Add the following DNS record to your domain, using the content of the mail.txt file:

mail._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmB... (rest of the public key) ...AQAB"

Configure OpenDKIM by editing /etc/opendkim.conf. Important settings include:

Domain                  yourdomain.com
KeyFile                 /etc/opendkim/keys/mail.private
Selector                mail
Socket                  inet:8891@localhost

Configure Postfix to use OpenDKIM by adding the following lines to /etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891

Restart OpenDKIM and Postfix:

sudo systemctl restart opendkim
sudo systemctl restart postfix

Expected Result: Outgoing emails from yourdomain.com will now be signed with a DKIM signature. Receiving mail servers can verify this signature to ensure the email’s authenticity. DMARC: Defining Policy for Unauthenticated Emails DMARC builds upon SPF and DKIM by allowing you to specify how receiving mail servers should handle emails that fail SPF and/or DKIM checks. You can instruct them to reject, quarantine, or simply report such emails. DMARC also provides reporting mechanisms, allowing you to receive feedback on how your domain is being used. Example: Creating a DMARC record A DMARC record is a TXT record named _dmarc in your DNS zone file. Here’s an example:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=s; aspf=s;"

Let’s break down this record:

• v=DMARC1: Specifies the DMARC version.
• p=reject: Instructs receiving servers to reject emails that fail SPF and DKIM checks. Other options include quarantine (move to spam folder) and none (no action, only report). Starting with none is recommended to monitor the impact before enforcing stricter policies.
• rua=mailto:dmarc-reports@yourdomain.com: Specifies the email address to which aggregate reports should be sent. These reports provide summarized information about DMARC validation results.
• ruf=mailto:dmarc-forensic@yourdomain.com: Specifies the email address to which forensic reports (failure samples) should be sent. These reports provide detailed information about individual emails that failed DMARC validation.
• adkim=s: Specifies strict DKIM alignment. The DKIM domain must exactly match the domain in the “From:” header. “r” would specify relaxed alignment, where subdomains are allowed.
• aspf=s: Specifies strict SPF alignment. The SPF domain must exactly match the domain in the “From:” header. “r” would specify relaxed alignment, where subdomains are allowed.

Expected Result: Receiving mail servers will check the DMARC record of yourdomain.com. Emails failing SPF and DKIM checks will be handled according to the specified policy (reject, quarantine, or none). You will receive aggregate and forensic reports, providing valuable insights into your email authentication performance and potential abuse. Expert Tip: Start with a DMARC policy of p=none and monitor the reports for a few weeks to identify any legitimate email sources that are not properly authenticated. Adjust your SPF and DKIM records accordingly before moving to a stricter policy like p=quarantine or p=reject.

Greylisting: Delaying the Inevitable (and Catching Spam)

Greylisting is a spam filtering technique that temporarily rejects emails from unknown senders. The receiving server sends a temporary failure message (a 4xx SMTP error code) to the sending server. Legitimate mail servers will typically retry delivery after a short delay, while spammers, often using botnets with transient IP addresses, are less likely to retry. This delay helps to filter out a significant portion of spam. How Greylisting Works:

• First Attempt: When an email arrives from a sender (identified by the sender’s IP address, sender email address, and recipient email address) that the server hasn’t seen before, the server temporarily rejects the email with a 4xx error.
• Temporary Failure: The sending server receives the temporary failure message and, if it’s a legitimate server, queues the email for retry.
• Retry: After a delay (typically a few minutes to a few hours), the sending server retries sending the email.
• Acceptance: The receiving server now recognizes the sender and accepts the email.

Example: Implementing Greylisting with Postgrey (Postfix) Postgrey is a popular greylisting implementation for Postfix. First, install Postgrey:

sudo apt update
sudo apt install postgrey

Configure Postfix to use Postgrey by adding the following lines to /etc/postfix/main.cf:

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10023,
    permit

This configuration instructs Postfix to query the Postgrey service (running on localhost port 10023) for each recipient. By default, Postgrey greylists all new senders. You can customize the greylisting behavior by editing the /etc/postgrey/postgrey_whitelist_clients and /etc/postgrey/postgrey_whitelist_recipients files. For example, to whitelist a specific IP address, add it to /etc/postgrey/postgrey_whitelist_clients:

192.0.2.10    OK

Similarly, to whitelist a specific recipient, add it to /etc/postgrey/postgrey_whitelist_recipients:

user@yourdomain.com   OK

Restart Postgrey and Postfix:

sudo systemctl restart postgrey
sudo systemctl restart postfix

Expected Result: Emails from unknown senders will be temporarily rejected. Legitimate senders will retry and their emails will eventually be delivered. Spammers are less likely to retry, reducing the amount of spam you receive. Important Considerations:

• Delay: Greylisting introduces a delay in email delivery, typically between a few minutes and a few hours. This delay can be frustrating for users expecting immediate delivery.
• Legitimate Senders: Some legitimate senders might not retry after a temporary failure, resulting in lost emails. Whitelisting these senders is crucial.
• Configuration: Proper configuration of greylisting parameters (retry intervals, whitelist entries) is essential to balance spam reduction with email delivery speed.

Advanced Filtering with SpamAssassin and ClamAV

While rate limiting and authentication protocols provide a strong foundation for spam prevention, advanced filtering tools like SpamAssassin and ClamAV offer more sophisticated analysis of email content and attachments to identify and block spam and malware. SpamAssassin: Content Analysis and Heuristic Scoring SpamAssassin is a powerful spam filter that uses a variety of techniques, including header analysis, body content analysis, URIBL (Uniform Resource Identifier Blacklist) checks, and Bayesian filtering, to assign a spam score to each email. Emails exceeding a certain threshold are classified as spam and can be rejected, quarantined, or tagged. Example: Implementing SpamAssassin with Postfix First, install SpamAssassin:

sudo apt update
sudo apt install spamassassin

Start the SpamAssassin daemon:

sudo systemctl start spamassassin

Configure Postfix to use SpamAssassin by adding the following lines to /etc/postfix/master.cf:

spamassassin  unix  -       n       n       -       -       pipe
  flags=Rq user=debian-spamd argv=/usr/bin/spamc -e  /usr/sbin/sendmail -oi -f $sender $recipient

Then, add a filter to your /etc/postfix/main.cf file:

content_filter = spamassassin:

Finally, add the following restriction to your smtpd_recipient_restrictions in /etc/postfix/main.cf:

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    permit

Restart Postfix:

sudo systemctl restart postfix

Expected Result: Incoming emails will be scanned by SpamAssassin. Emails exceeding the default spam score threshold (typically 5.0) will be marked as spam. You can configure SpamAssassin to modify the email headers (e.g., add a “X-Spam-Flag: YES” header) or to reject the email outright. Customizing SpamAssassin:

• Configuration Files: SpamAssassin’s configuration files are located in /etc/spamassassin. The main configuration file is /etc/spamassassin/local.cf.
• Score Threshold: You can adjust the spam score threshold by setting the required_score option in local.cf. For example, required_score 4.0 sets the threshold to 4.0.
• Bayesian Filtering: SpamAssassin uses Bayesian filtering to learn from spam and ham (non-spam) emails. You can train the Bayesian filter by feeding it examples of spam and ham using the sa-learn command.
• Rules: SpamAssassin uses a set of rules to identify spam. You can add custom rules to local.cf to target specific types of spam.

ClamAV: Virus Scanning of Email Attachments ClamAV is an open-source antivirus engine that can scan email attachments for viruses and malware. Integrating ClamAV with your email server provides an additional layer of security, preventing infected attachments from reaching your users. Example: Implementing ClamAV with Postfix First, install ClamAV and ClamAV-Daemon:

sudo apt update
sudo apt install clamav clamav-daemon

Start and enable the ClamAV daemon:

sudo systemctl start clamav-freshclam
sudo systemctl enable clamav-freshclam
sudo systemctl start clamav-daemon
sudo systemctl enable clamav-daemon

Configure Postfix to use ClamAV by installing clamav-milter:

sudo apt install clamav-milter

Edit /etc/clamav/clamav-milter.conf and ensure the following settings are correct:

# Run as user clamav
User clamav
# Allow e-mails to pass if clamd is down
# or returns an error
# ( Turned off by default. See man clamav-milter.conf )
# ExitOnClamdError Yes

# Always block the e-mail if an error occurs.
ExitOnClamdError Yes

# Do not log clean files
LogClean No

# Define the relay domain
RelayLocalDomain yourdomain.com

# Define the internal network
RelayLocalNet 127.0.0.1

# Run in background?
# (default: no)
Foreground no

Configure Postfix by adding the following to `/etc/postfix/main.cf`:

smtpd_milters = inet:127.0.0.1:10025
non_smtpd_milters = inet:127.0.0.1:10025
milter_default_action = accept

Restart ClamAV-milter and Postfix:

sudo systemctl restart clamav-milter
sudo systemctl restart postfix

Expected Result: Incoming email attachments will be scanned by ClamAV. If a virus or malware is detected, the email will be rejected or quarantined, preventing the infected attachment from reaching your users. Important Considerations:

• Resource Usage: SpamAssassin and ClamAV can be resource-intensive, especially when processing large emails or attachments. Ensure your server has sufficient resources to handle the load.
• False Positives: Advanced filtering tools can sometimes generate false positives, incorrectly identifying legitimate emails as spam or malware. Regularly monitor your spam and quarantine folders to identify and release any false positives.
• Regular Updates: Keep SpamAssassin’s rules and ClamAV’s virus signatures up-to-date to ensure they can effectively detect the latest threats. ClamAV’s freshclam tool automatically downloads signature updates.

Monitoring and Logging for Early Detection

Effective monitoring and logging are crucial for detecting and responding to spam bombing attacks. By continuously monitoring your email server logs, you can identify suspicious activity, such as sudden spikes in email volume, unusual sender patterns, and increased bounce rates. Analyzing Email Server Logs Email server logs contain valuable information about email activity, including sender IP addresses, recipient addresses, timestamps, and delivery status. Analyzing these logs can help you identify the source and characteristics of a spam bombing attack. Example: Analyzing Postfix logs Postfix logs its activity to the system log, typically /var/log/mail.log or /var/log/maillog. You can use command-line tools like grep, awk, and sed to extract specific information from these logs. To find all emails rejected due to rate limiting, you can use the following command:

grep "rate limit" /var/log/mail.log

This command searches the /var/log/mail.log file for lines containing the phrase “rate limit.” The output will show you the IP addresses and timestamps of the senders who exceeded the rate limits. To find all emails that were rejected by SpamAssassin, you can use the following command:

grep "SpamAssassin" /var/log/mail.log | grep "reject"

This command searches the /var/log/mail.log file for lines containing “SpamAssassin” and “reject,” indicating that SpamAssassin rejected the email. To count the number of emails received from a specific IP address, you can use the following command:

grep "from=user@example.com" /var/log/mail.log | wc -l

Replace user@example.com with the email address you want to investigate. The wc -l command counts the number of lines matching the search criteria, giving you the total number of emails received from that sender. Setting Up Monitoring Alerts Manually analyzing logs can be time-consuming and inefficient. Setting up automated monitoring alerts allows you to be notified immediately when suspicious activity is detected. Several tools can be used for monitoring and alerting, including:

• Fail2Ban: Fail2Ban monitors log files for failed login attempts and other suspicious activity and automatically blocks the offending IP addresses using firewall rules. While primarily used for SSH brute-force attacks, it can also be configured to monitor email server logs for spam-related patterns.
• Logwatch: Logwatch is a log analysis tool that summarizes log activity and sends reports via email. You can configure Logwatch to monitor your email server logs and alert you to any unusual activity, such as a sudden increase in spam volume or a high number of rejected emails.
• Nagios/Icinga: Nagios and Icinga are comprehensive monitoring systems that can monitor a wide range of server metrics, including email server performance, queue length, and spam volume. You can configure Nagios/Icinga to send alerts when any of these metrics exceed predefined thresholds.

Example: Using Fail2Ban to block spamming IP addresses First, create a filter file (e.g., /etc/fail2ban/filter.d/postfix-spam.conf) with the following content:

[Definition]
failregex = reject: RCPT from .*\[\]: 554 5.7.1 .* Access denied - Invalid HELO name \
            Client host rejected: cannot find your hostname
ignoreregex =