r0nmlt

This already happened on the 13/08/2014 and jje gave a little bit of a clean-up to /var and all returned normal, but now /var is full again resulting in mail failure again.

actually the fact that /var is full is most probably the cause that mail seems to be not working lately!!!

When trying to send a text only email from webmail I am getting: Message not sent. Server replied: Connection refused 111 Can't open SMTP stream If I try to send an email with attatchment through webmail I get: 451 Error While Writing Spool File

Same here. I use my hosting account to forward email to my ISP, but that ain't working today.

Now it is working flawlessly as usual. It was only this time that it happened. I don't think we can replicate the behavior and therefore I dont think tracing what happened is possible.

No I never got them. They all came through now. This inflow now stopped but it kept on going for about 3-4 days. Say from the 14/05 - 17/05.

It started off yesterday (probably whilst the updates were being done). I am getting really old mail delivered to my mailbox! This is the header of one such email: Return-Path: <****@macm.org.mt> Delivered-To: ****@internet.vodafone.com.mt Received: from stevie.heliohost.org (stevie.heliohost.org [65.19.143.2]) by mail.internet.vodafone.com.mt (Postfix) with ESMTP id 1F9B83F7418 for <****@internet.vodafone.com.mt>; Thu, 15 May 2014 02:10:28 +0200 (CEST) Received: from outmail48.go.net.mt ([80.93.157.48] helo=outmail29.go.net.mt) by stevie.heliohost.org with esmtp (Exim 4.69) (envelope-from <info@macm.org.mt>) id 1WTZCy-0007r1-5A for ****@fcs.com.mt; Fri, 28 Mar 2014 09:00:19 -0700 Received: from [172.20.1.72] (helo=fender72.go.net.mt) by outmail29.go.net.mt with esmtp (Exim 4.72) (envelope-from <****@macm.org.mt>) id 1WTYXp-0001z9-Pp for ****@fcs.com.mt; Fri, 28 Mar 2014 16:18:09 +0100 Received: from [78.133.92.74] (helo=server) by fender72.go.net.mt with esmtp (Exim 4.72) (envelope-from <info@macm.org.mt>) id 1WTYYl-0004T7-Ts for ****@fcs.com.mt; Fri, 28 Mar 2014 16:19:19 +0100 Message-ID: <20140328.HHZOBWEQMMBEWARD@macm.org.mt> From: "Malta Association of Credit Management" <****@macm.org.mt> To: "Ronald Cordina" <****@fcs.com.mt> Reply-To: "MACM" <****@macm.org.mt> Subject: ******************************************** Date: Fri, 28 Mar 2014 16:18:01 +0100 Importance: Normal List-Unsubscribe: <mailto:****@macm.org.mt?subject=unsubscribe> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_643_1245_93883802.12639804" EM-Campaign: {FF393377-E404-44FE-BB82-0A67BF6F7525} EM-Task: 695 X-Spam-Status: No, score=1.1 X-Spam-Score: 11 X-Spam-Bar: + X-Ham-Report: Spam detection software, running on the system "stevie.heliohost.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Subject: MACM Dishonoured Cheques Report Dear Ronald Cordina Kindly find attached an Excel Worksheet, containing the list of all the Dishonoured Cheques reported today. Copies of these cheques have been received by the MACM Secretariat. For the benefit of the members reporting Dishonoured Cheques, the Secretariat is issuing the Dishonoured Cheques Report in this format. However, full details can be found from the Members Area on the MACM Website. [...] Content analysis details: (1.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 NO_DNS_FOR_FROM DNS: Envelope sender has no MX or A DNS records 0.6 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_FONT_SIZE_LARGE BODY: HTML font size is large -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 1.4 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Flag: NO X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - stevie.heliohost.org X-AntiAbuse: Original Domain - fcs.com.mt X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - macm.org.mt X-Get-Message-Sender-Via: stevie.heliohost.org: mailgid no entry from get_relayhosts_entry X-Source: X-Source-Args: X-Source-Dir: ---------------------------------- What do you think is going on??? Is there a way to ping the queues in future so emails don't get stuck like this? Ron.

Thanks a lor and sorry for the hassle i caused.

Did you get my email krydos?

Ok will do. The reports only came from one email: [censored] which I will be sending you confirmation of ownership soon. Would it be possible to redact all email addresses mentioned in this thread after the thread is closed? Thanks for your patience and excuse me for putting you through all this.

When I saw your post I was taken aback and shocked cause the only explanation coming to mind, knowing that I am not behind the spam, was that my account was hijacked. Believe me if you want, but I am not a spammer and I will try and show you this, through the emails if you grant some time. If you had a good look at the emails you would have realised that the spam is not originating from my account but merely forwarded. Call me naive yes, cause I reported these spam emails myself as being spam, but I never would have thought that he.net would have blamed my domain and heliohost, and thereby punishing ME, YOU and the other users without looking at the emails in detail. So let me explain: The service I was getting from your servers was to have a catchall account on my domain (fcs.com.mt) and all emails would then be directed to this 2 accounts, namely: [censored] & [censored] Lately I had been receiving loads of SPAM mail (expcially from some OZ dieting) so I decided to report this guy to hotmail! If you take a look at the emails they all follow the same trends: All emails were reported by: "X-HmXmrOriginalRecipient: [censored]" That is still ME. I was reporting the SPAM mail but not heliohost!!! Whoever is in charge of these systems at he.net should look more carefully. You too jumped to the conclusion that I am spamming but please look at the emails in detail and you realise that those emails are originating elsewhere, addressed to my domain and forwarded to my hotmail account and my vodafone account as per my setup forwards. Email (1): "To: [censored]" Email (2): "To: [censored]" Email (3): "To: [censored]" Email (4): "To: [censored]" Email (5): "To: [censored]" Email (6): "To: [censored]" Email (7): "To: [censored]" Email (8): "To: [censored]" Email (9): "To: [censored]" Email (10): "To: [censored]" The routing taking place showing that heliohost.org is NOT the originator but a forwarder to HOTMAIL.. TO MY HOTMAIL ACCOUNT that I set up in the FORWARDS!! Email (1)(2)(3) "Received: from nobody by server.definedhosting.com " "Received: from server.definedhosting.com by stevie.heliohost.org " "Received: from stevie.heliohost.org by BAY0-MC3-F9.Bay0.hotmail.com " Email (4) "Received: from [89.123.48.132] by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by BAY0-MC2-F28.Bay0.hotmail.com" Email (5) "Received: from [83.240.254.169] by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by SNT0-MC4-F36.Snt0.hotmail.com" Email (6) "Received: from 89-97-122-127.ip17.fastwebnet.it ([89.97.122.127]) by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by BAY0-MC1-F24.Bay0.hotmail.com" Email (7) "Received: from [86.35.150.126] by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by SNT0-MC4-F27.Snt0.hotmail.com" Email (8) "Received: from [2.179.209.70] by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by SNT0-MC4-F37.Snt0.hotmail.com" Email (9) "Received: from 213.37.216.63.dyn.user.ono.com ([213.37.216.63]) by stevie.heliohost.org with esmtp (Exim 4.69)" "Received: from stevie.heliohost.org ([65.19.143.2]) by BAY0-MC1-F19.Bay0.hotmail.com" Email (10) "Received: from stevie.heliohost.org ([65.19.143.2]) by BAY0-MC2-F15.Bay0.hotmail.com" "Received: from 70.15.86.39.res-cmts.sewb.ptd.net ([70.15.86.39]) by stevie.heliohost.org with esmtp (Exim 4.69)" Even the X-antiabuse says it: Email (1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.definedhosting.com X-AntiAbuse: Original Domain - fcs.com.mt X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - server.definedhosting.com X-Get-Message-Sender-Via: server.definedhosting.com: uid via acl_c_vhost_owner from authenticated_id: nobody from /only user confirmed/virtual account not confirmed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - stevie.heliohost.org X-AntiAbuse: Original Domain - fcs.com.mt X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - server.definedhosting.com I'm not going to paste all 10 x-antiabuse as I think I made my point. Again I must stress I am not the spammer though I must admit I am the one who effectively black listed heliohost as I reported emails being forwarded by my account as spam BUT, and this is the pivotal point, I did not expect he.net to blame heliohost but the ORIGINATING host. Now kindly share your final views with me. I will accept any decisions you may take but I need to know where I stand as I cannot drag this any longer. Sincerely.

Thanks much appreciated. Awaiting posts from admins then.

I cannot understand this. I use this account just to forward all emails to my domain to hotmail and my ISP. Can you please tell me how the mail was sent? I barely ever use heliohost SMTP and heliohost originating emails would have an X-abuse header. Would it be possible to get hold of one of these emails? My site is a simple html with a picture and no scripts so i dont think thats how the emails were sent and my password is not easy so honestly i cannot see how spam is originating from my account. i am trying to get to the bottom of this for.my own good and the admins. Thanks in advance.

Login: fcsltd Server: stevie Domain: fcs.com.mt

Bump

Can I know what is causing this as I only use the A/C to forward mail and the home page is plain HTML with no links.

a. fcsltd b. stevie c. fcs.com.mt

What's up with sending emails on stevie? Tried everything; even telnetting to stevie.heliohost.org port 25 but I keep getting:  421 Unexpected failure, please try later Obviously incoming mail is not being delivered as stevie will be refuse connection.

Hotmail has blacklisted Stevie during this last week. I have also seen an abandoned post about yahoo doing the same thing. Emails being sent out of stevie.heliohost.org (65.19.143.2), are being refused by hotmail servers, irrelevant of the content of the emails. Return mail headers are: Return-path: <> Envelope-to: ***@fcs.com.mt Delivery-date: Sat, 02 Feb 2013 01:03:38 -0800 Received: from mailnull by stevie.heliohost.org with local (Exim 4.69) id 1U1Z10-0002pb-V2 for ***@fcs.com.mt; Sat, 02 Feb 2013 01:03:38 -0800 X-Failed-Recipients: ***@hotmail.com Auto-Submitted: auto-replied From: Mail Delivery System <Mailer-Daemon@stevie.heliohost.org> To: ***@fcs.com.mt Subject: Mail delivery failed: returning message to sender Message-Id: <E1U1Z10-0002pb-V2@stevie.heliohost.org> Date: Sat, 02 Feb 2013 01:03:37 -0800 Returned mail content: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: ***@hotmail.com SMTP error from remote mail server after MAIL FROM:<***@fcs.com.mt> SIZE=1837: host mx2.hotmail.com [65.55.92.184]: 550 SC-001 (SNT0-MC4-F9) Unfortunately, messages from 65.19.143.2 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. Original message content: Return-path: <***@fcs.com.mt> Received: from [***] (helo=***) by stevie.heliohost.org with esmtpa (Exim 4.69) (envelope-from <***@fcs.com.mt>) id 1U1Z0z-0002o2-NF for ***@hotmail.com; Sat, 02 Feb 2013 01:03:37 -0800 From: "***" <***@fcs.com.mt> To: <***@hotmail.com> Subject: *** Date: Sat, 2 Feb 2013 10:03:30 +0100 Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAGlGG9itEwdAnk8tyq41bGbihQAAEAAAAFUVZ5RrjAtPsiz+MFBHyngBAAAAAA==@fcs.com.mt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4BJCugoA+/KYsRTba6t67sbSS0Eg== Content-Language: en-gb Disposition-Notification-To: "***" ***@fcs.com.mt

any news regarding stevie?

I will refrain from doing that in the future, but somebody else did now! Most probably other users of heliohost are experiencing the same problems and they followed the link in the bounced email and clicked unlist. Now for the domains sending out the spam part. I have checked the email message header of stevie and this should have: X-AntiAbuse: Original Domain - fcs.com.mt (or something similar). I presume that this trojan cannot alter/fake/omit this right? If this is correct I will ask them to provide the domain names and if they do consent I will post them here.

Problem back to haunt us. If you check http://cbl.abuseat.org/lookup.cgi?ip=65.19.143.2 it is shown as being listed again. Can I do something from my end???

ok i found the culprit to the problem http://cbl.abuseat.org/lookup.cgi?ip=65.19.143.2 IP Address 65.19.143.2 is listed in the CBL. It appears to be infected with a spam sending trojan or proxy. It was last detected at 2012-09-29 12:00 GMT (+/- 30 minutes), approximately 2 days, 18 hours, 30 minutes ago. It has been relisted following a previous removal at 2011-10-21 01:53 GMT (347 days, 4 hours, 27 minutes ago) This IP is infected with the DarkMailer/YellSOFT DirectMailer or other similar trojan. This involves perl or PHP scripts being uploaded to web servers resulting in the sending of large quantities of spam email (usually pharmacy pill spams). PAY VERY CLOSE ATTENTION TO THE FOLLOWING Darkmailer infects web hosting environments. ONLY the hosting company can fix these infections properly. If you are not the administrator of this hosting environment, there is probably nothing you can do to fix this infection, you MUST refer this listing to them. The hosting administrator has to do the fix. This is a checklist of the four things the administrator needs to do before delisting. There is more detailed information about each of these later. NEW A lot of the darkmailer spam we see involves spoofing/phishing/forging linkedin, facebook and other similar sites. Several correspondents noted: It creates a folder in /tmp called .state, owned by apache. The folder is a self contained holy terror of spam til you catch it. It hogs resources so you cant ssh in to fix the issue, but doesn't compromise anything else. Once you kill the process and delete the folder,it goes away. I think it stems from a joomla vulnerability. Check your FTP logs to find uploads of Darkmailer scripts. Forward to us a copy of the FTP log records that you find. These logs will often be in /var/log/messages, but this depends on your system configuration. Identify, kill and remove all Darkmailer scripts currently on the web server. NOTE: Many Darkmailer operators cause the Darkmailer scripts to be removed either after they're used, or even during their use. If you cannot find the scripts, this does NOT mean that the CBL is in error in this listing NOR does it mean that you are not presently vulnerable to anotherDarkmailer infection. Change the passwords of every userid identified as performing FTP uploads, and warn these users that their passwords had been compromised by a keylogger infection. They need to run anti-virus software on their computers. NEW WARNING: we're getting indications that once initially compromised by FTP, the attackers are uploading alternate file transfer programs that do not rely on the user's password. See below under "r57shell" Implement port 25 blocking so that only your mail server software userid can make outbound port 25 connections from this machine. Darkmailer/DirectMailer Background This detection is that of a spammer who has broken into your web server (usually) via cracked or keylogged FTP credentials. Once they've logged in via FTP, they install perl scripts that do the spamming. These perl scripts are usually installed in a cgi-bin directory, and present (usually) a Russian language spam control panel that the spammer can use to blast out large quantities of spam (most often illegal Pharmaceutical drugs or replica watches). See, for example, Darkmailer in Wikipedia and this thread in the CPanel Forum. CPanel and Plesk installations on Linux are the usual targets of this attack, but the reality is that ANY web server on ANY operating system capable of running Perl CGIs and permitting uploads is susceptible to this problem. We've seen it on Solaris or FreeBSD, we've seen it on Windows, we've seen it uploaded with FrontPage, we've seen it under many different web server packages. You can often identify this (on UNIX/Linux systems) by doing "ps" (process status) and finding many (often 10 or more) long-running processes named ".cgi", ".php" or ".pl" that are owned by the same user as your web server instance. As an example, one infectee saw 25 copies of a "dm.cgi" program running under his Apache server's userid. But this will only help if the script is currently running. Another approach is running the command "netstat -nap" as root. Lines like this (with random program names rather than your MTA software) shows the Darkmailer software in operation: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 1 192.168.2.2:58246 212.69.102.240:25 SYN_SENT 12614/b.pl tcp 0 0 192.168.2.2:35843 209.85.201.27:25 ESTABLISHED 7996/ciwhcnsb.pl tcp 0 0 192.168.2.2:53051 81.13.48.2:25 TIME_WAIT - tcp 0 0 192.168.2.2:53623 77.243.121.126:25 TIME_WAIT - tcp 0 0 192.168.2.2:57816 217.13.210.81:25 TIME_WAIT - tcp 0 1 192.168.2.2:50531 217.16.16.81:25 SYN_SENT 12270/nxhbo.pl tcp 0 0 192.168.2.2:52437 217 begin_of_the_skype_highlighting FREE 52437 217 end_of_the_skype_highlighting.198.11.26:25 TIME_WAIT - tcp 0 1 192.168.2.2:50140 195.64.222.2:25 SYN_SENT 9273/yzezihd.pl Foreign addresses that end with ":25" indicate _outbound_ email connections. TIME_WAIT means the connection has been shutdown, but other states indicate active outbound connections. You may not be able to find the program names (eg: b.pl, ciwhcnsb.pl, nxhbo.pl etc) on your file system, because they deleted themselves immediately after starting. But you will be able to find the process via "ps" based on process id (PID). Again, this ONLY works if you catch it while it is running. See the next paragraph: The spammers run this spamware in several different ways. The first way is that the spammer simply uploads the software and runs it at will. You will sometimes be able to find these in the cgi-bin directory. The second way is that they upload the software, run it, and then delete it (perhaps when it's STILL running). You won't be able to find the files in the cgi-bin. Either way if you don't secure your system, the spammer can just do it again at any time. Checking FTP logs/Securing Users Normally, web hosting environments log FTP uploads, often in /var/logs/syslog, /var/log/messages or some similar file. For example, this is some logs an administrator found from a Darkmailer infection - notice how it ws deleted after every upload: Mar 4 04:02:11 enam pure-ftpd: (example@117.41.229.131) [NOTICE] /home2/example//public_html/rocker/dark.cgi uploaded (74627 bytes, 126.66KB/sec) Mar 4 05:03:54 enam pure-ftpd: (example@117.41.229.131) [NOTICE] Deleted dark.cgi Mar 4 07:04:42 enam pure-ftpd: (example@117.41.229.131) [NOTICE] /home2/example//rocker/dark.cgi uploaded (74627 bytes, 122.25KB/sec) Mar 4 07:11:43 enam pure-ftpd: (example@117.41.229.131) [NOTICE] Deleted dark.cgi Assuming you're running some flavor of UNIX, simply grep the log file for "ftp", "cgi", "\.pl" or "php" and see if you can identify such log records. The CGI scripts are usually around 74K bytes in size. There is frequently also an upload of small test script (around 1-2K) called "test.pl" that the spammer uses to test whether the big script will work. Sometimes the spammer uploads the files under different names and renames them by FTP to an executable suffix (like ".cgi" or ".php" etc). So your grep may only find the rename commands. We are providing Law Enforcement with whatever intelligence we can find about where these come from, so, please forward such log records to us - the timestamps (tell us what timezone you are in) and IP addresses are the most important. It's not always FTP that is used to upload these scripts. Eg: scftp, rsync, rcp, server-side FrontPage extensions etc. We have reports of the scripts being uploaded via a Joomla vulnerability. Check their logs, and disable any access that you/your customers do not really need. The account used ("example" in the above example) will tell you which users' passwords have been compromised. Reset their passwords and warn them that their computer is probably compromised with a spam trojan and they should run anti-virus software to find it. Unfortunately, anti-virus software has fallen FAR behind in being able to find such things, so, the user telling you that A-V didn't find an infection doesn't prove anything. Such users should reformat their computers and reinstall from trusted media. It's possible that SOME of these users are the spammer, so you may be tempted to terminate their account. Don't do that - once you configure your firewall correctly, it doesn't matter. If they aren't the spammer, they'll continue to be your customer and will be unaffected by the firewall change. If they are the spammer, they'll leave on their own because the firewall prevents them spamming. Finding and removing the Darkmailer scripts If you find the FTP (or other) logs, that will tell you where the scripts were placed. You will still need to scan the cgi-bin and other directories to find any other copies. Remember that these files are usually around 74K in size, so that will help you find them quicker. Remove them if they still exist. Securing your server from future Darkmailer infections You MUST configure your web server to prevent DarkMailer/DirectMailer infections being able to spam the Internet. Once you've done this correctly, it doesn't matter whether the spammer can still upload this malware, they can't spam with it, so they'll leave you alone. There are a variety of ways to do this. In short, you're implementing a firewall restriction that only permits root and the mail server userid to make outbound port 25 (email) connections. You can either do it yourself with a software firewall, or, use third party software to do the same thing. configserver.com has a variety of products and services that can deal with this issue. Note that the CBL has no connection whatsoever with ConfigServer. If you know of other software packages that can deal with Darkmailer please let us know and we'll mention them here. The most commonly used ConfigServer product appears to be ConfigServer Security and Firewall (CSF) and it's FREE. The feature you want to turn on is "CSF SMTP_BLOCK" which, as far as we can tell, does exactly the firewall restrictions we describe above. Another product that ConfigServer offers is ConfigServer eXploit Scanner (CXS). This software is not free ($75 regular price, currently $50). This software monitors FTP uploads in real-time, will automatically detect Darkmailer and other malicious downloads, and remove them. Most Cpanel implementations already have something called "SMTP Tweak" (aka "WHM SMTP Tweak") available. It apparently doesn't do the firewall configuration we describe, but it wouldn't hurt to turn it on too. If necessary, you can implement the firewall restrictions yourself without using any extra software. iptables -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mail -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mailman -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable You may need to add or change the "-m owner ... ACCEPT" to be consistent with your mail server. Eg: you'll need different entries for Qmail. You will also have to ensure that these iptables commands are executed every time the system reboots, perhaps by an init script. If you're using cPanel and APF, APF by default will wipe out iptables rules you enter manually leaving the server vulnerable. If you are using APF, you should make the above change via APF and that will take care of reissuing the commands upon reboot or reset. Note: in some virtual hosting environments, the above commands will return error messages. This generally means that the host (not virtually hosted) operating system does not support the iptables kernel modules. If you do get such errors, make sure that the base operating system has the iptables module fully installed. r57shell Infestations In one case, it turned out to be a file called "info.php" in the user's images directory. Info.php turned out to be a modified copy of the "r57shell" PHP script which provides a backdoor through which an attacker can do virtually anything on your web server. Thus, even though you have changed the passwords, the spammer could still upload the spamming scripts at will - this was found by noticing invocations of the PHP file in the web server logs from the same IP address the original FTP connections came from. You will need to search for such files as well, and we recommend preventing the execution of scripts (.php, .pl, .cgi, etc) in directories that do not need it. Eg: only the cgi-bin directory should permit execution. Nullamatix has a discussion on some simple ways to find r57shell. It is known that Symantec EndPoint Protection can detect the original r57shell. The index.php file described above was a modified r57shell, and SEP doesn't detect it. A handful of AV detectors detect it as Backdoor.PHP.Rst!, but this doesn't help on Linux/UNIX. Note in particular, ClamAV not detect the "info.php" variant mentioned above. If you don't need PHP capabilities in your web server, turn it off. Or consider enabling it only for specific hostings that need it. WARNING: If you continually delist 65.19.143.2 without fixing the problem, the CBL will eventually stop allowing the delisting of 65.19.143.2. If you have resolved the problem shown above and delisted the IP yourself, there is no need to contact us. Click on this link to delist 65.19.143.2. So I clicked the link to delist and I think it worked, but to the base problem. Is this problem coming from my domain or from someone using/abusing heliohost?

My cpanel username is fcsltd, my domain is fcs.com.mt and the server i am on is stevie. I mainly use this services as a mailhosting, therefore any email being sent to @fcs.com.mt will be forwarded to 2 accounts. One being hotmail (as backup) and the other my local ISP. This forwarding stopped working last Saturday. I tried sending emails from heliohost webmail. Nothing is getting to destination. I tried sending to hotmail and to my local ISP (vodafone.com.mt) as sometimes it occurred that vodafone blocks emails from stevie, but hotmail never did. This time, nothing is arriving at destination and nothing is being returned with error. The wait is more than 24 hours .. so its not a matter of a normal queue. To be honest I haven't got an email since Saturday!!! Ron.

Is it just me or is mail not being sent out???