SpamBlocker Version 3.1-RC Now Ready for Testing

nobaloney

NoBaloney Internet Svcs - In Memoriam †
Joined
Jun 16, 2003
Messages
26,113
Location
California
SpamBlocker Version 3.1-RC is now ready for testing.

This exim.conf file is a product of NoBaloney Internet Services, and is neither distributed by nor supported by DirectAdmin or their staff. All support issues should be posted on this thread and will receive prompt consideration.

Be sure to keep a copy of your old exim.conf file, in the event you must revert.

If you're maintaining your own local blocklists and whitelists, then please make sure you understand these notes (from notes published within the new file):
Code:
# If you have a prepopulated bad_sender_hosts file and if
# it's populated with listings which consist of IP#s, then those
# listings must be moved out of the bad_sender_hosts file and
# into the bad_sender_hosts_ip file.
# 
# If you have a prepopulated whitelist_hosts file and if it's
# populated with listings which consist of IP#s, then those
# listings must be moved out of the whitelist_hosts file and
# into the whitelist_hosts_ip file.

While sections of this file may look similar to those in previous versions, including those in Version 3-beta, it's effectively a complete rewrite. We've taken notes for several months now, and every line in the file was scrutinized carefully.

There's not a definitive changes file yet, but some changes are:

We've removed sorbs blocklists and added several others.

We've added a whitelist of official ISP mail servers. No more accidental blocking of servers belonging to gmail, hotmail, verizon, etc.

We no longer refer to the example.com domain. If you don't intend to offer whitelisting of any false positives, then you can use the error messages as-is.

We've noticed a huge reduction in spam. Please let us know in this thread if you've been as lucky.

The URL is the same as for previous Versions:

http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/

Note: Remember that the file requires a lot of customizations before you use it. Be sure to read the MUST-READ-FIRST.txt file.

There's no new ReadMe-SpamBlocker.3.2.txt file yet, but the previous ReadMe file (ReadMe-SpamBlocker.3.1.txt) is still helpful.

Note that the previous version has been renamed ARCHIVE and is no longer available for download.

Note that there is no guarantee there won't be changes between this RC version, any newer RC versions which we may publish, and the final release version, so you shouldn't make a major effort to try this file on lots of servers.

However, should you wish to do the required edits and run it on one or two servers, we think you'll be pleased.

Please let us know.

Thanks.

Jeff
 
As soon as I installed it on a server I can see a large number of spams being blocked. I appreciate your work on this. Hats off!!
 
Have a quick feedback. Everything seems to work fine, except for these problems:

1) I can't seem to use SSL for SMTP on port 465. I get the error --> (input sent without waiting for greeting). Switching it to TLS on port 465 works fine. TLS on port 25 doesn't work as it complains that the server doesn't start TLS (maybe that is my configuration problem)
2) I use IMAP with thunderbird. Sending emails from my personal laptop works fine when I start thunderbird. After few minutes when I sent emails it is rejected saying: HELO should be fully qualified domain name. However, if I restart thunderbird and try to send the email it goes off. Maybe it is something to do with popb4smtp?
 
A lot of my users are reporting the same error "HELO should be fully qualified domain name." Is there any fix for this?

Keefe
 
Code:
  # Helo should be FQDN
  deny hosts   = !+relay_hosts 
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821
       condition =  ${if !match\
                     {$sender_helo_name}\
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\
                     {yes}{no}}

  accept

This is what is causing problems. How do we bypass this for authenticated users? I see that popb4smtp relay_hosts are bypassed but apparently not people using SMTP auth.
 
I think I may have fixed this by changing the following:

Code:
  # Helo should be FQDN
  deny hosts   = !+relay_hosts [COLOR="Red"]: !+auth_relay_hosts [/COLOR]
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821 
       condition =  ${if !match\ 
                     {$sender_helo_name}\ 
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\ 
                     {yes}{no}} 

  accept
 
I think I may have fixed this by changing the following:

Code:
  # Helo should be FQDN
  deny hosts   = !+relay_hosts [COLOR="Red"]: !+auth_relay_hosts [/COLOR]
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821 
       condition =  ${if !match\ 
                     {$sender_helo_name}\ 
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\ 
                     {yes}{no}} 

  accept

Works like charm! thanks
 
Thanks, everything. This is exactly the kind of feedback I've been hoping for. I've made the fix on the download page.

Jeff
 
I think I may have fixed this by changing the following:

Code:
  # Helo should be FQDN
  deny hosts   = !+relay_hosts [COLOR="Red"]: !+auth_relay_hosts [/COLOR]
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821 
       condition =  ${if !match\ 
                     {$sender_helo_name}\ 
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\ 
                     {yes}{no}} 

  accept

Since I made this change, none of the emails were blocked for this reason - HELO should be Fully Qualified Domain Name. I once again see spams flowing in.

I just tried removing : !+auth_relay_hosts, I can immediately see a lot of emails being blocked.

2009-08-03 17:37:01 H=(hotlink-f78f062) [41.129.8.252] rejected EHLO or HELO hotlink-f78f062: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821
2009-08-03 17:37:02 H=(187.62.125.66) [187.62.125.66] rejected EHLO or HELO 187.62.125.66: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821
2009-08-03 17:37:28 H=host161-145-static.23-87-b.business.telecomitalia.it (homegate) [87.23.145.161] rejected EHLO or HELO homegate: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821
2009-08-03 17:37:29 H=host161-145-static.23-87-b.business.telecomitalia.it (homegate) [87.23.145.161] rejected EHLO or HELO homegate: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821
2009-08-03 17:37:47 H=(PQKUZYWS) [124.132.73.25] rejected EHLO or HELO pqkuzyws: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821
2009-08-03 17:37:48 H=(PSEPQNQFFL) [124.132.73.25] rejected EHLO or HELO psepqnqffl: HELO should be Fully Qualified Domain Name Host.Domain.Tld See RFC821

So, I think the above is not the actual solution to this problem.
 
When I add any domain into whitelist_domains, I see this in the logs:

Code:
failed to expand ACL string "$sender_host address whitelisted in local whitelist": unknown variable name "sender_host"
 
When I add any domain into whitelist_domains, I see this in the logs:

Code:
failed to expand ACL string "$sender_host address whitelisted in local whitelist": unknown variable name "sender_host"

It looks like adding anything in the whitelist_* files triggers this error and prevents some emails from arriving.
 
Since I made this change, none of the emails were blocked for this reason - HELO should be Fully Qualified Domain Name. I once again see spams flowing in.

I just tried removing : !+auth_relay_hosts, I can immediately see a lot of emails being blocked.

So, I think the above is not the actual solution to this problem.

I've just checked my logs today, and I agree, it's not the solution. It's an immediate workaround, because it disables the problematic code. I'm looking at other solutions, and the RC remains an RC until I've figured it out.

Jeff
 
It looks like adding anything in the whitelist_* files triggers this error and prevents some emails from arriving.
Please check your exim.conf file and replace any occurrance of:
Code:
sender_host address
(note space) with
Code:
sender_host_address
(underscore instead of space)

It appears to be a typo in some of the logging code; it should use the underscore instead of the space in all occurrances. It shouldn't be causing any delivery issue; just logging issues, so no need to update the RC for just this.

Please test and let me know.

Thanks.

Jeff
 
I had the same problem in exim.conf RC 3.2 with senders being notified that emails were being delayed. This is a sample message the sender would receive.

"Subject: Message Delivery Delay

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

<[email protected]>

The reason for the problem:
4.1.0 - Unknown address error 451-'Temporary local problem - please try later'"



The exim logs showed this


2009-08-08 15:02:57 H=idcmail-mo1so.shaw.ca [24.71.223.10] F=<[email protected]> temporarily rejected RCPT <[email protected]>: failed to expand ACL string "$sender_host address whitelisted in local whitelist": unknown variable name "sender_host"
2009-08-08 15:02:58 H=idcmail-mo1so.shaw.ca [24.71.223.10] incomplete transaction (RSET) from <[email protected]>

Once I made the last suggested change to exim.conf it works and delivers the email immediately.
 
Last edited:
I noticed that spamblocker doesn't block any of the test spam messages from dnsreport.com.

Code:
DNSstuff Mail Server Test Center - Anti-Spam Test
Sent by "techwarepc" at Tue Sep 1 20:19:07 2009
This is a test message that was sent to you because you or someone you know visited the DNSstuff Mail Server Test Center and ran an anti-spam test against this email address.
This email message contains a forged received header with with a blacklisted IP Address.
If you received this message without a spam warning or notification, we recommend you perform the following steps:
1.	Contact your email administrator.
2.	If you are the email administrator, review your current anti-spam settings, and insure that the latest updates are applied and that your spam filtering software is enabled.
3.	If the issue is still not resolved or you need additional assistance, please reply to this email and a DNSstuff sales team member will contact you.
If you received this message in error or if you require assistance, please reply to this email.
 
I also doesn't block the virused message:

Code:
DNSstuff Mail Server Test Center - Anti-Virus Test
Sent by "techwarepc" at Tue Sep 1 20:20:50 2009 
This is a test message that was sent to you because you or someone that you know visited the DNSstuff Mail Server Test Center and ran an anti-virus test against this email address.
The attached file is designed to trigger virus scanners, but is not an actual virus and will not do any harm.
If this email was received without the attachment being removed, your anti-virus software may be absent, out of date, or disabled.
We recommend you take the following steps in that case:
1.	Contact your email administrator.
2.	If you are the email administrator, review your current anti-virus settings, insure that the latest updates are applied and that your anti-virus software is enabled.
3.	If the problem is not yet resolved, contact your anti-virus vendor.
4.	If this still does not resolve the issue or you need additional assistance, please reply to this email and a DNSstuff sales team member will contact you.
For more information about the EICAR test file, please visit http://www.eicar.org/anti_virus_test_file.htm
If you received this message in error or if you require assistance, please reply to this email.
This email contains the EICAR test signature attached as a .BIN Attachment
 
Back
Top