Determining spam source

[abaks]

Hi,

How can I determine spam source? My exim is sending lot's of spam to russian servers and I cannot localize why. In /var/log/exim_mainlog I see only rejected connections from these servers but I can't see which of my clients (I suppose the source is inside and I'm not open relay) is doing this all mess. Please help.

 

[cPanelTristan]

Please check WHM > Mail Queue Manager for one of the messages and paste the contents of the message here for the headers.

 

[k-planethost]

place limits for the domains how many emails can send per hour.
disable "Antirelayd" in "WHM >> Main >> Service Configuration >> Service Manager" in order to avoid abuse of "POP before SMTP" authentication.
One of the best ways to find an account that is sending spam is to use suPHP as the PHP handler instead of DSO. This will run all PHP scripts as the cPanel
account user, instead of as the Apache user nobody. If a PHP script is sending spam, this will make it relatively easy to find which account is responsible. Also, you may want to run EasyApache with the "MailHeaders" option selected for PHP in Step #6, "Exhaustive Options List."
There are a few options in Tweak Settings that would need to be setup. The first is "Track email origin via X-Source email headers", the second is "Prevent “nobody” from sending mail", and the third is "Add X-PopBeforeSMTP header for mail sent via POP-before-SMTP". Enable those options and you'll then be able to see the source of messages being sent through PHP.
check mail queue an re layers on whm

check accounts with cxs or maldet or clamav for viruses

 

[minosjl]

hi,

I have a question about suphp.I was thought the suphp is more secure that dso handler , why suphp promotes spamming , can you explain a little but about that....

 

[k-planethost]

it is more secure than dso handler
suPHP provides an additional layer of protection on servers. It causes php scripts to run under the account username instead of the user ‘nobody’ which is the user that apache/php would run under on a server that is not running suPHP. This feature allows us to more easily track any potential security breaches that come in via insecure php script(s) that a user is running. if you recompile apache with mail headers especially.
suPHP also does away with the requirement of using 777 permissions on directories/files that need write permission. In fact if a directory and/or file has the permission set to (CHMOD) 777 and it is access via a browser, then an internal server error 500 will be generated. The highest level of permissions that a user can use on a suPHP enabled server is 755. This permission setting is sufficient enough for any directories/files that needs to be written to.
i dont think that suphp promote spamming since with this you can catch spammer more easily if you know how to monitor your box..
of course there are various methods to secure a server exept from suphp thats the beginning

 

[minosjl]

thanks buddy