On th e new 2.7.1.511 build the filter order has been changed, now messages that come from blocked IP's are sent to quarantine, even if there is no associated AuthorizedTo email address. The quarantine database fillup very quickly with dictionary attack addresses.

AuthorizedTo lists are going to be smaller and faster to process than blocked IP or HoneyPot lists.

We feel the AuthorizedTo filter should be the first filter object. If the recipient is not on the AuthorizedTo list it should be rejected 1st. No need to quarantine messages rejected from this filter.

Second, if a message is sent from an IP address listed in the honeypot list to an AuthorizedTo address it should be blocked.

Third, The IP address filter, this is where I block Class "B" and "C" ranges.

Using the new build, phishers are getting messages through even thoud the IP address is on the honeypot list.

Roberto,

We use the IP blacklist to block Class "C" and "B" ranges for example we block 72.11.128.0/19. However we send all messages from these IP addresses to quarantine in the remote possibility that OC3 networks has a legit domain hosted.

With the new build, as soon as a IP from the IP blacklist tried to connect, the message was sent directly to the quarantine. Completely bypassing the authorizedto white list.

Does that make sense? Maybe we were using the IP address block diferently than intended. We use the HoneyPot IP address list to block single IP addresses... Seems to me that IF you use the IP blacklist to reject single IPs you may be duplicating many of the HoneyPot IP's.

I would rather use honeypot addresses and keyword features to build my blocked single IP list and use the IP blacklist to blacklist spammer friendly ISP's like Comcast, RR, OC3 and so on...

I am running v.2.7.1.511 and I experienced the blocking of null emails with the reject empty “Mail From” unchecked.  Here is the scenario:

I set up out-of-office auto responders for a client on our public mail server.  Our auto responder sends from a null address to prevent loops. I sent a test email from our private exchange server to the auto responder and never got a response?  It was trapped in the spam filter as it had to pass from one mail server to another.  It even blocked with our class C IP range white listed. I tested the spamfilter without keywords, MAPS, from emails and IP blacklists and  the auto responses were still blocked.

To confirm the spamfilter was the issue I forced email from our client mail server directly to our private exchange server (bypassed the spam filter) and the auto response arrived.  Can you test this feature?  This is a new issue – our auto response email arrived as expected on the Thanksgiving holiday. 

Otherwise I like v.2.7.1.511. 

Here is one feature request.  Allow us to start up the service to the window of our choice or a window other than the activity log.  When we are under a spam load, the GUI locks up and the desktop interface lags something awful.  I can forget remote  with pc-anywhere and remote desktop is bad as well as the direct desktop.  When under a load I can't always get the spamfilter GUI to switch to the settings tab in a resonable time period because of the lag.

Thanks and Merry Christmas! 

I refuse to be politically correct!