We've pre-released to licensed users the new SpamFilter 3.1.3.590.

This version supports user authentication using Active Directory, LDAP, and Unix-style (crypt) password files. The "AUTH LOGIN" feature allows authenticated users to be whitelisted, so they can use SpamFilter to send emails anywhere. Internal users can thus now use SpamFilter as their "Outgoing SMTP Server" as long as they configure their email software for authentication. Authentication of users via RADIUS and via a database will be probably added shortly. (Please note that user authentication is not the same as verifying that an email recipient is a valid user)

SSL over SMTP is also supported, allowing users to send usernames/password encrypted as they authenticate. Documentation on how to use commercial SSL certificates with SpamFilter is available in the readme.html help file in the new download.

This version also has a number of fixes for high traffic sites. The release note since the last update are as follows:

// New to VersionNumber = '3.1.3.590';
{TODO -cFix : Exception occurred during TestForReject: Access violation at address.....}
{TODO -cFix : Exception occurred during AddIPToIPCacheLimbo: List index out of bounds}
{TODO -cFix : Exception occurred during GetConnectionsFromIP: Access violation at address }
{TODO -cNew : If destination SMTP server does not respond causing a "Read Timeout" error, SpamFilter will now queue the message rather than attempting to send an NDR right away}

// New to VersionNumber = '3.1.3.585';
{TODO -cNew : Added support for AUTH LOGIN - authenticating users with a Unix-style password file, Active Directory and LDAP servers}
{TODO -cNew : Changed share mode when saving activity logfile, allowing more read-access to external apps}
{TODO -cNew : Embedded spam-images with invalid characters in filename are now scanned properly}
{TODO -cNew : SpamFilter looks at image header to determine file type, does not rely on extension anymore}
{TODO -cNew : Added X-Rejection-Reason header in blocked and spam-tagged emails}
{TODO -cFix : Exception occurred during TSendMailThread.Run: Access violation at address.....}
{TODO -cFix : Fixed "Exception occurred during ReloadSMTPServer: List index out of bounds (0)" when these occur: "Listen Exception occurred". Would cause SpamFilter to stop accepting new incoming connections}
{TODO -cNew : Added option to immediately disconnect sender when recipient not in AuthorizedTO whitelist, even if bayesian filter is enabled}

// New to VersionNumber = '3.0.2.580';
{TODO -cNew : Added support for .PNG image format in spam-image detection filter}
{TODO -cFix : Some emails with multi-image spam graphics were not detected as spam }



Edited by LogSat

We did not advertise the new functionality that much for this very reason...
Documentation is still being prepared, but as these new features were in high demand, we released this version before the docs were ready.

Do you have any question in particular? In general, there is a new "User Authentication" tab under the Settings, where admins can select the type of authentication to be used.

If an end-user configures their email client to use outgoing SMTP-authentication, they can use SpamFilter as their "Outgoing SMTP Server". SpamFilter will authenticate the user with either Active Directory, LDAP, or a Unix password file. If successful, the user is whitelisted and will be able to send emails thru SpamFilter.

For LDAP, you will need to provide the LDAP server (support for a failover LDAP server is being added), and the the account that SpamFilter will use to bind to LDAP so it can perform searches. The Base DN for your LDAP domain will also need to be provided.

WebGuyz wrote: Any future chance that we will see autowhitelisting of those who we send email to as a way fo cutting down on incoming false positives?

This is an excellent idea...

 

Speaking of performance any chance having the ability to specify location of logfile directory and queue directory?

Thinking of moving these to a ram drive to keep disk drives from getting beat up.

Thanks!

LogSat wrote: This would lead to a potentially huge list of entries, as every outgoing email will have to be checked and added to the list. Having a list of several MBs (or dozens of MBs) in size would greatly affect performance.

I'm doing this currently myself.  I parse exchange logs looking for outbound emails, and store them in a database (with a date last seen).

Then every day I create a list of accounts that should be whitelisted, I only take emails that someone has sent an email to in the last six months.

That way my list stays smaller, if someone has not sent an email to someone in the last six months they just don't get automatically whitelisted.

Please consider this feature.

Instead of rejecting the spam, we would like to redirect to some email id  for each domains listed in allowed list.