I tested via telnet the SMTP AUTH on both of your SpamFilter servers, and incorrect passwords are being correctly rejected. Are you certain that you have removed the affected user(s) from the same Unix passed file that SpamFilter is configured to use? The path to that file is in the "Settings - User Authentication" tab in SpamFilter, and appears when selecting the "Unix Passwd File" tab.

• SpamFilter's activity logfile for today

• Your SpamFilter.ini and the PASSWD Unix password files

• The \SpamFilter\Domains directory structure (if the files containing any of your blacklists/whitelists are outside that directory tree, please include those as well.

If the zipped file is over 8MB in size, please try to upload the file to our repository at:

https://cloud.logsat.com/public.php?service=files&t=ec1a5cd65f702ae7d9cacfe951fe063a

I'll provide you the password for the above URL via a separate PM.

In the meantime, if most of these AUTH LOGIN attempts are originating from a single IP of a specific subnet, you could also go to the "Settings - Debug View" tab in SpamFilter. There you can enter an IP or a subnet over which you can capture some of the SMTP traffic. If you can capture some of the successful SMTP AUTH events there, we would be able to see what the spammer is doing to gain access to the user's account(s). If you do that, could you please also include the output from that capture in the zip file? 

We received the files. The strange thing in the logs is that the username being used to authenticate is not being logged. It should appear right after the entry "User authenticated with AUTH LOGIN".

If the forwarding attempt was disconnected, the messages should be queued in the \SpamFilter\queue folder, and SpamFilter will retry sending them every 20-60 minutes (depending on your retry settings).

Hi,

Thanks a lot for your reply.

Hi,

We've confirmed that the users who login with SMTP AUTH will be whitelisted bypassing any BL IP checking.

Sorry,

Was there any resolution to this. We use Unix SMTP Auth and are interested if there is any problem with it.

Is there any way to kill a session short of restarting SFI? What settings in global options would force these type spam attacks to have to authenticate more often.

We monitor the SFI log and if we see anyone sending more then 100 emails in 2 minutes we remove that email address from the auth password file, but in a case like this a lot of spam would still would get thru. We need to have them try to authenticate more frequently so they would stopped.

Would be good to have some limits but doesn't help a lot if it starts at 2am and you wake up to find yahoo.com and gmail.com will no longer accept emails from you because of the thousands of spams that been pushed.

Been working on a more automated solution since a lot of these attacks occur in the wee hours of the morning.

Have a vb script that runs continuously in a loop with a 60 second delay. It reads in the SFI log file and uses Dictionary component to keep track of IP's and Senders addresses and number of emails sent.

If a user sends more then 150 emails in 1 minute we read in the password file and remove the authenticated email address.

We then use MS firewall CLI commands in our script to block that IP immediately. These 2 steps nip the spamming in the bud. if a valid customer happens to send more then 150 emails in 1 minute then we just apologize and unblock his IP and add his email address back in the password file.

The speed in which spammers can pump out spam is incredible and manual methods are too slow.

if you could find a way to automatically limit an IP when it get detected sending thousands of emails in a short period then the world would beat a path to your door :-)