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.

If the issue persists, could you please zip us the following so we can take a look:

• 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:

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".

The SMTP trace capture is at this point very important to see what is happening. As you said there are many different IPs sending these emails. You can try entering:

1*

in the Debug View's "IP to monitor". This will capture traffic from any IP that start with a "1", so it won't capture *everything* (which would likely cause performance issue with SpamFilter) but it should capture enough traffic to eventually catch one connection that did the SMTP AUTH command. Could you please email us the contents of that output when you captured some of it?

If you'd like and you prefer to perform a real packet capture with WireShark for a few minutes, we can also analyze the WireShark .pcap file to troubleshoot the problem. Just make sure to save the original raw data when saving with Wireshark, and not just the text output.

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).

I have an updated while we debug your logs. The only account that is used to send emails using SMTP AUTH is the "a.dan______@______.___". That account is indeed being logged after the "User authenticated with AUTH LOGIN: a.dan________@_____". I had missed that as the spammers are sending multiple emails in a single connection, and only the first one of the series will log the AUTH username, leaving all the others empty.

Have you restarted SpamFilter after removing that account from your Unix password file? I ask as the user only needs to authenticate once during an SMTP session. Once authenticated at the beginning of it, they don't need to authenticate again untile they disconnect and then re-connect. For example there was an SMTP session that lasted over 4 hours:

that resulted in a *lot* of emails sent from that authenticated user (always the same). If you close and restart SpamFilter after changing the Unix password file you would force everyone to reconnect and thus re-authenticate immediately.

The files in the queue are always in pair. One with either a nnnnnnn.tmp or a with a nnnnnnn.~tmp extension, and one with nnnnnnn.tmp.rcpt extension. The .tmp contains the message itself, and the .tmp.rcpt contains the to/from email addresses.

If you just delete the .tmp.rcpt file, SpamFilter will cleanup after itself next time the queue is processed by removing the orphaned .tmp file. If possible however you should delete both files to prevent SpamFilter from doing extra work and possibly slowing it down while processing those orphaned files.

Do you have any SMTP or packet captures you'd like for us to analyze to see how this issue occurred?

SMTP AUTH is one of the commands that can be transmitted over SMTP, so there are no configuration settings like timeouts or SSL that can be configured just for that.

SSL can certainly be enabled for SpamFilter, but you would not be able for example to force SMTP AUTH to use the SSL port you configured. SMTP AUTH would still be available on the non-SSL port.

I'll update the post shortly to confirm or not whether the SMTP AUTH whitelisting will bypass the BL IP checking - I'm not certain at the moment without testing this in the lab. This has never been an issue in the past so it's not a common question.

We'll wait for your debug report as I'm hoping it will have the info we need to determine what is happening.

Sure - I had sent you a private message on the forum a few days ago with the password and URL for our cloud area. I just re-sent it to you. If you check your profile here on the form account you should be able to see the PM notifications.

No issues had been found. A user appeared to have their SMTP password compromised, and a spammer was using that account to relay email. They kept an open/connected SMTP session which was using to send the spam. Deleting the user from the Unix passed file will prevent the user from performing further SMTP AUTH logins, but the current SMTP session is not disconnected, so they kept spamming for a while. There were also tens of thousands of emails in the SpamFilter queue, so the outbound traffic actually continued (emptying the queue) even after the spammer was unable to login any further.

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 :-)

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