CBL blacklisted but no outgoing spam detected
When this happens, CSF usually notifies me about it and mail queue is usually full since I have only 80 mails per hour limit for each account.
Where should I check next? I can't seem to fix this, /var/log/exim_mainlog don't seems to have relevant logs regarding the said "spam".
And what's frustrating is that I have average 200 mail deliveries per hour with max of 1000 today.
-
Can you explain this another way, I don't understand your actual question. 0 -
I have to agree with Infopro That being said I think I know what you are trying to convey I'm guessing since you cant see it its going out nice and slow usually its the localhost Spam that is hard to see check to see if there are any scripts that are sending out more than usual (only you would know the answer to that) awk '$3 ~ /^cwd/{print $3}' /var/log/exim_mainlog | sort | uniq -c | sed "s|^ *||g" | sort -nr if it is localhost Spam here is another thread to help you detect it H=localhost (User) spammer 0 -
Oh sorry about that, I might have ranted a bit. So here it goes, CBL blacklisted one of my IPs saying it was sending spam. There was no further details on their lookup page which was new for me, just stated that there might be a script/trojan that caused the blacklisting or it may be a false positive which happens for shared hosting servers. I was blacklisted before but CBL page says which domain was it coming from, so it was rather easy to fix. Now, another thing is, CSF was not able to track which domain was spamming. Usually, if there was really a script or relay sending huge amount of emails, it's logged properly and email notifications are sent. Exim also queues messages once they reach the max threshold. The odd thing today is, no CSF notification and no EXIM queues. I have set it to 80 max emails per hour per domain, and hard limit of 200 (which is catched by Exim all of the time when is met). 80 and 200 are small numbers to be considered as SPAM and they were even not met this day. That's why I'm wondering how come CBL blacklisted this IP? I browsed my Mail stats and based the deliveries per hour today, it was max of 600-700. Checked exim logs again for those hour blocks, no relevant "spam" logs. I was wondering if I missed any logs to check and where to further check if possible? Is it really possible that CBL blacklisted this as false positive and where to prevent this (in WHM)? Hope that helps my case. 0 -
I have to agree with Infopro That being said I think I know what you are trying to convey I'm guessing since you cant see it its going out nice and slow usually its the localhost Spam that is hard to see check to see if there are any scripts that are sending out more than usual (only you would know the answer to that) awk '$3 ~ /^cwd/{print $3}' /var/log/exim_mainlog | sort | uniq -c | sed "s|^ *||g" | sort -nr if it is localhost Spam here is another thread to help you detect it H=localhost (User) spammer
Thanks for the tip, no it's not localhost though The result is pretty much normal with max of 800 for a single domain, others are below that with average of 2-6.0 -
Have you tried this ? awk '$3 ~ /^cwd/{print $3}' /var/log/exim_mainlog | sort | uniq -c | sed "s|^ *||g" | sort -nr The above command will show the exact path for mail script. 0 -
I'm having the same problem as iso99. A few days ago my server was listed in CBL and i dont find anything at exim_mainlog. When i run the mentioned command I get the following results: 19573 cwd=/var/spool/exim 1414 cwd=/ 1345 cwd=/etc/csf 173 cwd=/usr/local/cpanel/whostmgr/docroot 71 cwd=/tmp 8 cwd=/root 8 cwd=/home/domain1/public_html/form 6 cwd=/home/domain2/public_html 3 cwd=/var/log 2 cwd=/home/domain3/public_html 2 cwd=/home/domain4/public_html/Comuna 2 cwd=/home/domain5/public_html 1 cwd=/home/domain6/public_html 1 cwd=/home/domain7/public_html can I see if a script is being used to send spam? 0 -
Thanks for the tip, no it's not localhost though
how do you know if you cant find it.0 -
how do you know if you cant find it.
I've used your cmd line and got pretty much the same results as chujanet PS: Recently updated to WHM 54, if that helps0 -
Further details: Exim stats deliveries per hour: 00-01 290 ............... 01-02 245 ............ 02-03 229 ............ 03-04 260 ............. 04-05 280 .............. 05-06 330 ................. 06-07 295 ............... 07-08 304 ................ 08-09 590 ............................... 09-10 836 ............................................ 10-11 969 ................................................... 11-12 833 ........................................... 12-13 699 .................................... 13-14 542 ............................ 14-15 686 .................................... 15-16 625 ................................ 16-17 615 ................................ 17-18 606 ............................... 18-19 442 ....................... 19-20 337 ................. 20-21 331 ................. 21-22 351 .................. 22-23 381 .................... 23-24 446 ....................... All email errors (rejection) where sent remotely R=lookuphost T=remote_smtp 0 -
Hello, CBL team informed me that: " If you are running CPanel, this problem could be caused by CPanel bug #59785, whereby CPanel is unable to send emails associated with the virtual IP address assigned to the sender domain. In other words, CPanel (via exim most likely) is failing to bind to the sender domain's IP address before sending. You will want to turn this feature off until the bug is fixed. This "failure to bind" is the root cause of similar problems with older versions of IMail. This is apparently, in the case of CPanel, fixable in the Exim configuration, but we don't know the details, and CPanel may well clobber such changes next time you patch or upgrade. Note: there is a fairly common belief that the HELO has to match the From: line, otherwise mail server spam filtering will block it. This is mistaken. If it were true, large scale email hosting environments (such as Google, godaddy or mail.com/1and1 etc) would be unable to function. "
Can anyone tell me if you also have this problem in version 54.0.8? how can i fix this issue?0 -
Update: I also emailed CBL and verified that the email accounts were referencing their own domain name for HELO/EHLO instead of the hostname's/reseller's shared IP. I checked the email headers and it was indeed the case. Before, it was: Received: from hostname.server.com (hostname.server.com. [xxx.xxx.xxx.xxx]) but now, it's Received: from domain.name (hostname.server.com. [xxx.xxx.xxx.xxx]) This somehow got messed up on an update and waiting for cPanel ticket for advice. 0 -
No official fix yet but was advised to try the following for now: You might consider adding a script hook at "/scripts/postupdateuserdomains" which checks each domain's reverse DNS record and manually updates "/etc/mailhelo" with the proper entries. One of our analyst has provided such a script at How to script /etc/mailhelo to always match reverse DNS if you care to try this until this behavior is fixed by a future update. Another option would be to manually manage the '/etc/mailhelo' and '/etc/mailips' files which is described here: https://documentation.cpanel.net/display/CKB/How+to+Configure+Exim's+Outgoing+IP+Address#HowtoConfigureExim%27sOutgoingIPAddress-ManuallyconfigureExim%27soutgoingIPaddresses My apologies for the inconvenience cased by the CPANEL-3984 case. When a patch is available the case ID should show up in the change logs: 54 Change Log - Documentation - cPanel Documentation 0 -
Hello :) Internal case CPANEL-3984 is open to address an issue where accounts assigned a shared IP address are added to the /etc/mailips and /etc/mailhelo files when IPv6 is enabled. The current workaround is to disable "Send mail from account"s dedicated IP address" and use the "Reference /etc/mailhelo and /etc/mailips" options explained at: How to Configure Exim's Outgoing IP Address - cPanel Knowledge Base - cPanel Documentation Please monitor our change log for the inclusion of a resolution for this case: 54 Change Log - Documentation - cPanel Documentation Thank you. 0 -
Hello :) Internal case CPANEL-3984 is open to address an issue where accounts assigned a shared IP address are added to the /etc/mailips and /etc/mailhelo files when IPv6 is enabled. The current workaround is to disable "Send mail from account"s dedicated IP address" and use the "Reference /etc/mailhelo and /etc/mailips" options explained at: Thank you.
Thanks for this @cPanelMichael, I've been having my own IP blocked regularly since upgrading to 54. Have applied the above "fix" and will see what happens0 -
Blocked again :( 0 -
Case CPANEL-3984 addresses the issue by turning off IPv6 handling in the /etc/mailips and /etc/mailhelo files for the time being. This resolution is scheduled for inclusion in a future build cPanel version 54, but there's no specific time frame available at this time. I'll update this thread when the case is released to a public build of cPanel. Thank you. 0 -
A resolution for internal case CPANEL-3984 is included in cPanel version 54.0.15. Please let us know if the issue continues on this version of cPanel (It's currently only released to the "Current" build tier). Thank you. 0 -
A resolution for internal case CPANEL-3984 is included in cPanel version 54.0.15.
I see that our servers have now updated to 54.0.15, so I'm curious to know if it's now safe to switch back to the "Send mail from account"s dedicated IP address" setting?0 -
Yes, please do so and let us know of any additional problems. Thank you. 0 -
Yes, please do so and let us know of any additional problems. Thank you.
I went ahead and did that, and so far no issues. Will update you if that changes.0 -
Removed my postupdateuserdomains script. /mailhelo and /mailips are back to normal. 0 -
FYI still broken tested was banned by CBL in 3 days 0 -
FYI still broken tested was banned by CBL in 3 days
Could you verify the specific issue you are facing? We've had a few separate users report an issue on this thread, so I just want to be sure I'm addressing the correct problem. Thank you.0 -
Internal case CPANEL-3984 ( no ipv6 enabled) the CBL banns the main shared IP when Send mail from account"s dedicated IP address when the main shard IP is not the main server ip 0 -
the CBL banns the main shared IP when Send mail from account"s dedicated IP address when the main shard IP is not the main server ip
Could you open a support ticket using the link in my signature so we can take a closer look? I see no outstanding cases that would indicate an issue with the current behavior. Thank you.0 -
ticket 7500957 0
Please sign in to leave a comment.
Comments
26 comments