Addressing Email Bounce Issues on Hetzner: A Detailed Migration from Spamhaus to Barracuda DNSBL

After months of frustration with SpamAssassin failing to work with Spamhaus—despite installing a DQS key, the necessary plugins, and configuring the sh.cf file for SpamAssassin-DQS—I finally found a reliable solution. My Hetzner-hosted mail servers were experiencing severe email bounces and misconfigurations when using Spamhaus. In my exhaustive search for a stable alternative, I turned to Barracuda DNSBL. Now, with my CWP-managed Postfix server and ClamAV integration, Barracuda DNSBL is working flawlessly. This guide explains the entire process in detail.

The Problem: SpamAssassin and Spamhaus Headaches

I originally relied on Spamhaus for DNS-based spam filtering. However, a number of issues arose:

• DQS Key and Plugin Issues:
  Even after installing the necessary DQS key and plugins for SpamAssassin-DQS, the integration with Spamhaus continued to fail. Despite following all recommended procedures, SpamAssassin refused to honor the sh.cf configuration dedicated to SpamAssassin-DQS.
• Email Bounce Crisis:
  As highlighted in Spamhaus’ resource hub, querying legacy DNSBLs via Hetzner resulted in all emails being bounced. This created a complete headache for mail delivery and management.

After exhausting every potential fix without success, I decided to replace Spamhaus with Barracuda DNSBL—a change that finally brought stability and effective spam blocking.

Why I Chose Barracuda DNSBL

Barracuda DNSBL offered several advantages over my previous setup:

• Reliable and Fast Responses:
  Barracuda DNSBL responds quickly during DNS queries, ensuring that spam sources are identified in real-time.
• Simplified Operation:
  Instead of marking or modifying email headers, Barracuda works by rejecting emails outright during the SMTP transaction. This method prevents spam from even entering the mail queue.
• Seamless Integration:
  It integrates perfectly with Postfix on my server managed by CWP and fortified with ClamAV for virus scanning—providing a robust, multi-layered defense against spam and malware.

Step-by-Step Guide to Configuring Barracuda DNSBL with Postfix

1. Backup Your Existing Configuration

Before making any changes, it’s essential to back up your current Postfix configuration files:

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.bak
sudo cp /etc/postfix/master.cf /etc/postfix/master.cf.bak

2. Edit the Postfix main.cf File

Open the main configuration file where mail filtering rules are defined:

sudo nano /etc/postfix/main.cf

3. Update smtpd_recipient_restrictions

Locate the smtpd_recipient_restrictions directive. If multiple entries exist, merge them into one unified block to avoid conflicts. Add the Barracuda DNSBL rule as follows:

smtpd_recipient_restrictions =
    check_policy_service inet:127.0.0.1:10031,
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_rbl_client b.barracudacentral.org,
    reject_unauth_destination,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain

Note: The line reject_rbl_client b.barracudacentral.org is crucial—it ensures that any SMTP connection from an IP address listed on Barracuda is immediately rejected.

4. Save Changes and Reload Postfix

After saving your changes, reload Postfix to activate the new settings:

sudo postfix reload

Then, monitor the mail logs to confirm that the configuration has been applied without errors:

sudo tail -f /var/log/mail.log

Testing the Barracuda DNSBL Setup

A. Simulating an SMTP Session with Telnet

To verify that your configuration is working, you can simulate a spam email using Telnet:

1. Connect to Your Mail Server: telnet your.mailserver.domain 25
2. Simulate the SMTP Session: HELO spamdomain.com MAIL FROM:<spam@example.com> RCPT TO:<recipient@yourdomain.com> DATA Subject: Test Spam Email This is a test email to simulate spam. . QUIT

If Barracuda DNSBL is triggered, the SMTP session will be rejected during the RCPT TO stage, confirming that the DNSBL query is being executed.

B. Verifying DNSBL Query with dig

To further confirm that Barracuda DNSBL is active, use the dig command to query its DNS record. This test checks if your server’s DNS resolver can reach Barracuda.

Example 1: Checking a Spam IP

For a suspected spam IP—say, 203.0.113.45—you perform a reverse lookup. The query must be done in reverse order:

dig +short 45.113.0.203.b.barracudacentral.org

Sample Response for a Spam IP:

127.0.0.2

A non-empty response (typically in the 127.0.0.x range) indicates the IP is listed as a spam source.

Example 2: Checking a Clean IP

For an IP that is not flagged as spam (for example, 198.51.100.23), the query should return no results:

dig +short 23.100.51.198.b.barracudacentral.org

Sample Response for a Clean IP:

;; connection timed out; no servers could be reached

Or it might simply return an empty output, indicating that the IP is not listed.

These tests confirm that:

• Your server’s DNS resolver is functioning correctly.
• Barracuda DNSBL is reachable, ensuring that spam-check queries will be processed during SMTP transactions.

C. Checking Mail Logs

Since Barracuda DNSBL blocks emails during the SMTP transaction (without modifying email headers), verification is done through mail log entries. Monitor your logs:

sudo tail -f /var/log/mail.log

Look for entries referencing reject_rbl_client or directly mentioning Barracuda. These logs confirm that the DNSBL check is active and has blocked an email based on the sender’s IP.

Additional Relevant Details

• Integration with CWP and ClamAV:
  My server is managed via CWP (Control Web Panel) and leverages ClamAV for virus scanning. Barracuda DNSBL works seamlessly with these tools to create a comprehensive defense against both spam and malware.
• No Email Header Modifications:
  Unlike some spam filters that mark emails with additional headers, Barracuda DNSBL simply rejects the connection if the sender’s IP is listed. If an email is delivered, it means the sender has passed the DNSBL check.
• Performance and Reliability:
  By rejecting spam during the SMTP session, Barracuda DNSBL reduces the load on your mail server. This immediate blocking prevents unwanted messages from entering your mail queue, ensuring a smoother and more efficient mail delivery process.

Conclusion

After enduring persistent issues with SpamAssassin and Spamhaus on my Hetzner-hosted mail servers—despite employing a DQS key, the appropriate plugins, and sh.cf configuration—I finally found relief by switching to Barracuda DNSBL. With this new configuration integrated into Postfix on my CWP-managed server, and with ClamAV providing additional protection, spam is now effectively blocked at the SMTP level before it even reaches the inbox.

To Recap:

• I backed up and edited the Postfix main.cf file.
• I consolidated SMTP restrictions and added the Barracuda DNSBL rule.
• I tested the configuration using Telnet and verified DNS responses with the dig command.
• I confirmed the functionality by monitoring mail logs for DNSBL rejection entries.

If you’re experiencing similar issues or email bounce problems, consider switching to Barracuda DNSBL. This comprehensive guide should serve as a valuable reference for setting up and verifying your mail server’s spam protection.