Problems with hotmail/outlook because of senderscore

ViAdCk

Verified User
Joined
Feb 14, 2005
Messages
300
Hello,

One of our servers is having problems sending to hotmail/outlook, all emails sent from this IP are being put in the junk folder. As usual, microsoft's support is totally useless.

It appears the server got a low sender score since the 19th of january on senderscore.org. When I run a report on the IP, it appears that the server has sent email to many unknown users and there appears a list of sending domains which aren't hosted on the server or our network at all.

I have been looking for these domains (kn2.dk, kluthgmbh.de, klook.de and a long etc.) in the exim logs and I only found one coincidence:

Code:
mainlog-20180121:2018-01-19 13:22:50 H=(server.hostname.com) [127.0.0.1] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
mainlog-20180121:2018-01-19 13:22:50 H=(server.hostname.com) [127.0.0.1] incomplete transaction (QUIT) from <[email protected]>
rejectlog-20180121:2018-01-19 13:22:50 H=(server.hostname.com) [127.0.0.1] F=<[email protected]> rejected RCPT <[email protected]>: authentication required

When I search the senderscore database for kncp.de (or any other of the aforementioned domains), it appears this domain is related to various mail servers with high sending volumes.

There's something strange going on here but I can't find any relevant information in the exim logs besides the information posted above.

Does anyone have any suggestions or experience with something similar? Any idea what could be going on?

Thanks in advance for your time!

Regards
 
BTW, we are subscribed to microsoft's SNDS in order to monitor our IP space and see the following:

https://imgur.com/a/ANFvV

Something happened on the 19th but we can't find any relevant information in the exim logs.
 
Try other logs like /var/log/messages and /var/log/maillog logs, depending on what your OS is using. The php mail() function which are used by scripts, are not going via Exim, so won't appear in exim logs.
I'm think this might be a script.

Next to that, install CSF/LFD firewall which can also warn you about high volume e-mail going out.
 
Mails sent with php scripts always appear in the exim logs on our servers (we work with cloudlinux 6 & 7). I checked the messages and maillog logs though and there is no relevant information at all.

CSF/LFD is installed on this server and didn't send any kind of alert. All users on this server have a maximum daily limit of 1000 sent emails and no user reached their limit on that day neither.

I appreciate your input but I'm afraid something else is going on here..
 
Only mail that is sent via the mail() api will appear in the exim logs, since that typically defaults to using the sendmail api. But if the script creates it own smtp calls and connects to remote server's port 25 directly like exim does, then it won't show in any logs. This goes for any scripts (perl, python, php, etc) that may be executing on your system. Spammers like to install scripts like this, since they can go unnoticed for long periods of time. You can use something like lsof or "netstat -ap|grep smtp" to see if you have any other processes are trying to connect to other systems to send spam.
 
Only mail that is sent via the mail() api will appear in the exim logs, since that typically defaults to using the sendmail api. But if the script creates it own smtp calls and connects to remote server's port 25 directly like exim does, then it won't show in any logs. This goes for any scripts (perl, python, php, etc) that may be executing on your system. Spammers like to install scripts like this, since they can go unnoticed for long periods of time. You can use something like lsof or "netstat -ap|grep smtp" to see if you have any other processes are trying to connect to other systems to send spam.

Thanks for your input but I don't know if I understand correctly what you're trying to say. If this spam script is connecting to an external mail server to send spam, shouldn't that mail server be blacklisted instead of ours?
 
Thanks for your input but I don't know if I understand correctly what you're trying to say. If this spam script is connecting to an external mail server to send spam, shouldn't that mail server be blacklisted instead of ours?

No, think of the script imitating your exim, it will connect to the remote MX server and pretend to be the sending SMTP server. All it needs to do is send the appropriate TCP commands to the remote server and it may/may not be accepted by the receiving SMTP server, since it really is spam.
 
No, think of the script imitating your exim, it will connect to the remote MX server and pretend to be the sending SMTP server. All it needs to do is send the appropriate TCP commands to the remote server and it may/may not be accepted by the receiving SMTP server, since it really is spam.

Ok thanks understood :)

Is there no way to log or track this kind of fraudulent traffic after it happened? I executed your suggestion "netstat -ap|grep smtp" but am not seeing anything suspicious.

Thanks again!
 
I had once that some hackers managed to install their own mailserver, you won't find any "smtp" when doing a grep and you won't find anything in your logs.

This happened to me once when hackers managed to run a mail daemon via a hacked wordpress account (or leak script of the WP installation).
I found out by checking mail port daemons.
Try to see what daemons are running. In my case with:
Code:
lsof -i:25
or other known mail ports or even better... just check all daemons with "lsof -i" to see if there's something unknown like a bot in between the default daemons which should be running.
Unless you tried that already.
 
Last edited:
I had once that some hackers managed to install their own mailserver, you won't find any "smtp" when doing a grep and you won't find anything in your logs.

This happened to me once when hackers managed to run a mail daemon via a hacked wordpress account (or leak script of the WP installation).
If found out by checking mail port daemons.
Try to see what daemons are running. In my case with:
Code:
lsof -i:25
or other known mail ports or even better... just check all daemons with "lsof -i" to see if there's something unknown like a bot in between the default daemons which should be running.
Unless you tried that already.

It will only show something if there is a connection being done at that moment. I would do a ps and look for things being executed out of some users directories. There really shouldn't be any. I doubt you can find any trace after the fact, since most spamming scripts want to be as stealthy as possible and will try to leave the smallest footprint it can. You might find "smtp" in the grep of netstat if port 25 is defined /etc/services and you aren't using the -n flag to netstat.
 
It will only show something if there is a connection being done at that moment.
No that is not correct. You only will detect something send when a connection is being done at the moment, but it will always state listening daemons even if no connection is present, so with lsof -i:25 it will state what is listening to that port.
If there's a bot, it almost certainly will also listen to the port to detect commands of malicious users.

Only enabling SMTP_BLOCK is not enough.
If you have SMTP_ALLOWLOCAL = "1" then scripts are still able to bypass.
To detect maybe malicious scripts or force php scripts to use smtp, you also have to set SMTP_ALLOWLOCAL = "0" in csf too.

I suppose this should have prevented this from happening and prevent it in the future in case it happens again?
Probably, I thought this was enabled by default, but can be mistaken, it's one of the things I always instantly check, but in my case I allow php mail so I have smtp_allowlocal set to 1.
 
Last edited:
But if I understand correctly, with SMTP_BLOCK=1 and SMTP_ALLOWLOCAL =1 this wouldn't have happened because it would force the script to use the local mail server which would have been logged by exim.

Am I correct in this?
 
Correct, at least via port 25 and if sendmail is indeed logged like Toml said, then yes, this wouldn't have happened or at least it would have been logged.
 
Back
Top