SpamBlocker 3.2.6-RC now ready for testing

nobaloney

NoBaloney Internet Svcs - In Memoriam †
Joined
Jun 16, 2003
Messages
26,113
Location
California
SpamBlocker3, Release Candidate 6, is now ready for testing.

Note there have been significant changes to this RC, which was created with more community input than any previous version.

It's important that when installing this Release Candidate you read all the notes in the main file marked in all capital letters with the word EDIT.

The main change in this version is probably the option to default to all domains use SpamBlocker Technology unless excluded, or to default to no domains use SpamBlocker Technology unless included.

This is the last Release Candidate for which we will accept new features. I've asked for help in implementing BATV and DKIM. However no new features will be considered after 12:01 AM 23 May, 2010.

Jeff
 
Hello Jeff

Ill give this one a test today.
Im running the RC5 on a litle server with not much traffic, seams to work well for the moment.

Great job your doing !

Sky
 
All seams ok.

Only one catch in your file : i found 2 time this string ///...///
Im not sure what this is for, i just commented that out and all works ok know.

Sky
 
Thanks for letting me know. I use those marks for placeholders while I edit; I simply forgot to remove them :(.

I just uploaded a corrected file. The datestamp on the corrected file is:

19-may-2010 11:26

Jeff
 
This is the last Release Candidate for which we will accept new features. I've asked for help in implementing BATV and DKIM. However no new features will be considered after 12:01 AM 23 May, 2010.

May be a bit late, but been a long time since coming here...
Great thing to undergo BATV / DKIM i fully applause...
If i could add some suggestions due to some 4 years SB / Exim / DA usage, i'd ask following : (some may be answered already, i will catchup 6 months of unread posts tomorrow)

- Exim Conf plugin in DA, allowing interactiv modifications on a deny / allow lists of emails common to all clients. This could allow our clients to add deny adresses or whitelisted adresses in SB conf, dynamically (and yes i know, a whitelisted for one can be a blacklisted for the other - It may be necessary to have a admin validation mecanism ..)

- A public page, (example : spam.php) that would allow human false positives to interact with exim SB, in case an email should be blocked. This could allow a certain remoteness in allowing blocked legitimate users to bypass "for a limited time : 30 minutes in ie, listing blocks and other problems faced against exim.) Lately i have had approximately, 10 false positives a day on over 150 000 emails blocked... It gets too repetetive to have them added manually, i'd love a certain automation...

I'd love your return jeff on these ...

Tdldp
 
If i could add some suggestions due to some 4 years SB / Exim / DA usage, i'd ask following : (some may be answered already, i will catchup 6 months of unread posts tomorrow)
You make two good suggestions, but neither of them have anything to do with the SpamBlocker Technology exim.conf file.

I write the file. Perhaps DirectAdmin Staff decides to implement it (I hope so) once it comes out of beta.

Then perhaps someone decides to write, either to give away freely or to sell, one or more plugins as you suggest.

We get approximately 20 unblock requests per year, so it's never been worth it for me to write the automation.

Jeff
 
Jeff,

You may want to consider some of the fine tuning performance adjustments I have made over the last several years. Pick and choose as you wish. Makes for a very smooth, reliable and PCI compliant daemon.

smtp_banner = "SMTP"
smtp_max_unknown_commands = 1
smtp_receive_timeout = 5m
message_body_visible = 2000
print_topbitchars = true
smtp_accept_max_nonmail = 5
smtp_accept_max_per_host = 10
smtp_accept_max_per_connection = 10

recipients_max = 30
recipients_max_reject = true

local_from_check = false

# This creates 62 subdirs in /var/spool/exim/input to allow for better disk
# performance
split_spool_directory

# Lets you set how many SMTP calls are handled
# This allows many more TCP connections in wait state
smtp_connect_backlog = 50
# When we start just queueing
smtp_accept_queue = 100
# We will not accpet more than 150 incoming SMTP calls at once
smtp_accept_max = 150

# size limitations
message_size_limit = 10M

# We don't need to bounce more than 10K back to a user
return_size_limit = 10K


BigWil
 
Another piece for consideration ....

# define ACLs
{after helo}
acl_smtp_vrfy = acl_check_vrfy

{after acl helo}
acl_check_vrfy:
deny message = VRFY not allowed - it assists spammers.
 
You may want to consider some of the fine tuning performance adjustments I have made over the last several years. Pick and choose as you wish. Makes for a very smooth, reliable and PCI compliant daemon.
Some good suggestions, Will. To aid me in making a decision please post a line or two for each of these, telling why you feel it's a good setting.

More below...
smtp_banner = "SMTP"
smtp_max_unknown_commands = 1
smtp_receive_timeout = 5m
message_body_visible = 2000
print_topbitchars = true
smtp_accept_max_nonmail = 5
smtp_accept_max_per_host = 10
smtp_accept_max_per_connection = 10
recipients_max = 30
I've been known to send more than 30 recipients in one email. Not often, but occasionally. So I'm not sure I want to do this.
recipients_max_reject = true

local_from_check = false

# This creates 62 subdirs in /var/spool/exim/input to allow for better disk
# performance
split_spool_directory
What does it do with the big one currently there when the change is first made?
# Lets you set how many SMTP calls are handled
# This allows many more TCP connections in wait state
smtp_connect_backlog = 50
# When we start just queueing
smtp_accept_queue = 100
# We will not accpet more than 150 incoming SMTP calls at once
smtp_accept_max = 150

# size limitations
message_size_limit = 10M
My belief is that on a shared server this is going to result in support calls when clients send huge attachments. I know they shouldn't, but ... :)
# We don't need to bounce more than 10K back to a user
return_size_limit = 10K
Jeff
 
# RC 3,2,5 11-APR-2010
# Mailer-Daemon messages must be for us
accept senders = :
domains = +relay_domains
I mentioned this problem earlier, but this block is too early in the ACL. It should be placed after the RBLs to make sure you don't accept spam.
 
Another piece for consideration ....

# define ACLs
{after helo}
acl_smtp_vrfy = acl_check_vrfy

{after acl helo}
acl_check_vrfy:
deny message = VRFY not allowed - it assists spammers.
This could be shortened like this
Code:
acl_smtp_vrfy = deny
It would be hypocritical to do that while having this enabled in the Exim config ;)
Code:
require verify = sender
 
I mentioned this problem earlier, but this block is too early in the ACL. It should be placed after the RBLs to make sure you don't accept spam.
Please post exactly where you think I should put it, either by creating a diff file against my published RC, or by giving me a line number according to my published RC.

Thanks.

Jeff
 
This could be shortened like this
Code:
acl_smtp_vrfy = deny
It would be hypocritical to do that while having this enabled in the Exim config ;)
Code:
require verify = sender
Be conservative in what you send, be liberal in what you accept.

This is generally attributed to Internet pioneer Jon Postel though what he said was actually slightly different: See Wikipedia Article.

Jeff
 
spamcheck_director

I know I'm a little late to this party but I would consider adding:
{!def:authenticated_id} \

In the if statement for this director to prevent authenticated SMTP connections from being SA scanned. While people's email accounts get hijacked all the time you'd likely notice the load increase by a spammer quickly.

Josh
 
Be conservative in what you send, be liberal in what you accept.
Exactly and it's the opposite of what these rules do
1) Exim only accept emails from senders that it can verify
2) It doesn't allow a remote server to check if an account exist on the server
 
I know I'm a little late to this party but I would consider adding:
{!def:authenticated_id} \

In the if statement for this director to prevent authenticated SMTP connections from being SA scanned. While people's email accounts get hijacked all the time you'd likely notice the load increase by a spammer quickly.

Josh
Checking messages sent by authenticated users of the server can greatly help build better filters. Imho, you don't only need spam, but also clean content to build a good filter.
 
Checking messages sent by authenticated users of the server can greatly help build better filters. Imho, you don't only need spam, but also clean content to build a good filter.

I agree, but most of that can come from incoming messages anyway. We've seen a large amount of CPU time being devoted to spamd on local to local emails. Implementing the outgoing email rate limiting per the DA KB article will accomplish the anti-spam portion of outgoing email.
 
Also, you can probably remove cbl.abuseat.org as its part of PBL which is part of zen.spamhaus.org. You also may want to consider adding the barracudacentral reputation blocklist.

On our setup, spamcop and spamhaus capture 90% of the RBL blocks and Barracuda an additional 8-9%.

Josh
 
Back
Top