That's sound as a good solution. We will test it not in SSL mode to avoid impact on users settings but only working on firewall rules, and running a new istance of SFE listening on different port then the other one dedicated to SMTP AUTH traffic.

On the same server install another copy of SpamFilter, but configure it to listen for SSL traffic on port 465, and implement SMTP AUTH on this second instance. Configure this SpamFilter to reject all emails (for example either by having a non-existent domain in the "Local Domains", or by adding just one non-existent user to the AuthorizedTO whitelist). Then have your users configure their mail clients to use SSL for SMTP Authentication. This will (1) add increased security as their login information will be encrypted, and (2) will allow them to relay without the blacklist cache issues present on the primary server.

To use SSL you will need to configure an SSL certificate in SpamFilter, we have documentation on how to proceed in the manual.

We have implemented SMTP AUTHENTICATION feature using UNIX STyle pswd in order to use SFE as SMTP AUTH relay server.

Here the architecture

Incoming SMTP connection

|

v

SMTP AUTH (SFE3) -> KO -> reject

|

V

OK

|

V

Mail server

|

V

Remote Recipient

Now we are facing this problem: according to general rules of SFE governing potential spammers ips, if an user fails to authenticate himself due to an error entering the password in its outlook client, SFE considers him as a potential spammer and its IP is placed in IP CACHE BLACKLIST (temporary). If it come in error for three times the IP is blacklisted for 60 mins.

That's really good to fight incoming spam, but is really a curse for SMTP relay purposes. Imagine the scenario:

A lan with 200 users. 200 private IPs and 1 public/static IP. Just 1 user fails 3 times to authenticate himself in SMTP AUTH, SFE blacklist such a public IP and 199 users stop to send mail for 1 hour!!!

As workaround we added in Spamfilter.ini, "DoNotAddIPToHoneypot = [public IP]" but this is a weak solution.

We are a service provider and we cannot always know any single potential IP SMTP AUTH traffic will come from.

What can you suggest? On our side we can suggest to avoid temporary blacklisting when using SMTP AUTH feature.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum