[robb]

Originally Posted by eUK-Martin

Yes, emails were down on the server on Monday and reason for this to happen was only your domain neme.com. Your domain was under an attack and was receiving about 10 mails per second which was forwarded to your catchall address which is not hosted with us. So there was mail traffic in and out which cuased the SMTP queue getting jammed. The only way to stop this was to suspended your domain to get the situation in control. And I very well informed you about the problem when you were on Live Chat with me. Even after this emails were not getting delivered and hence we had to reinstall the Mail server causing further permission problems and it was only solved by Plesk developers which almost took the entire day to get resolved.

I have been given no evidence to support the claim that my domain was under attack. Even if I accept that this is true, I would not expect 10 emails per second to break SMTP. If this truly was the cause, this does not explain why suspending my domain did not solve the problem, why the problem did not stop when the alleged attack did, why EUKHost needed to reinstall the mail server, etc. From our conversation, I understand that the reinstallation of the mail server had set the permissions incorrectly, and that this is what the Plesk developers had to fix. So it seems that this made the situation worse, not better. I was also told that there was a bug in Mail Enable and that this was the root cause. Make your mind up! EUKHost seems to be keen to blame everyone else and not accept any responsibility for their inability to keep the server running smoothly.

Originally Posted by eUK-Martin

That is because you had added those domains on the server but does not host their mails with us. All the mail servers are configured to first check local delivery and then to look for the domain externally. We have to remove your domain from the DOMAIN.TAB file (Manually) to make them deliver externally.

This is quite a normal scenario, and not one that has caused any problems for any other hosting companies I have used over the past 15 years. So I'm rather surprised that this is a problem for EUKHost. But that in itself is not a big issue for me. The issue is two fold:

1. When someone makes manual changes, these get forgotten when something else changes. So when the mail server was reinstalled, the manual changes that were required were lost. This same problem occurred with the server move (below). Any manual configuration changes that had been made to any of my website hosting were lost when my website hosting were moved to a new server. It seems that EUKHost neither copies over the relevant configuration files, nor documents these manual changes, so we have to start again from scratch each time.
2. EUKHost refused to accept there was a problem, telling me the problem was with the destination mailboxes - whereas the problem was that the email wasn't getting anywhere near the destination mailboxes. I had to repeatedly reiterate that I knew this was something that needed to be addressed on Eurofighter to get any action.

Originally Posted by eUK-Martin

I would also like to mention that this requires server wide configuration changes and we do it for FREE and hence do not have any records that we did it for you on a request as a gesture of good will. But the changes were wiped off since we had reinstalled the mail server. And since it was me who had made these changes any one else would take time to recognize the problem as this indeed is not a serve end problem.

I do not consider that anything you need to do to enable my website hosting to work in a normal way is beyond the service I pay for. If your SMTP server is INCORRECTLY trying to deliver email locally, then that is a problem that needs to be fixed. Furthermore, I repeatedly referred the technical support representative to the ticket where you had made the changes, but they still refused to accept the need to do anything.

Originally Posted by eUK-Martin

I can list about 100 reasons for the application pool getting stopped just because the code is not correct. Why would the server stop only your site's application pool that too a period of times a day. If the this was a server end problem then all the 400+ sites hosted should have this problem, atleast once.

I don't know. But since you apparently don't keep application pool logs, we'll never know. But is seems that neither do you notice when an application pool has crashed. Nor do you have anything to automatically restart a crashed application pool. If you did, then downtime could be minimised.

Originally Posted by eUK-Martin

We had sent an email on 27th Nov that we will be moving sites on 1st Dec which was Saturday and not Monday. We started at 1 AM in the morning keeping in mind that if the problem occurs it should be resolved with the weekends.

You're out by a month. The email was sent on Saturday 27th October, and said that the web site hosting would be moved on Sunday 28th October. Just 24 hours notice (and that over a weekend - meaning zero business hours notice) is totally unacceptable.

Worse still...

• Six of my website hosting were missing when the server came back up
• Any sites that used databases had been broken (because of permissions being set incorrectly)
• Sites that came back would then randomly disappear
• The server was up and down like a yo-yo

It wasn't until a week later (Sunday 4 November) that all my website hosting seemed to work OK.

I could go on and on with the problems I've had. I had got the impression that EUKHost was going to take my issues seriously. Now it seems they're only interested in trying to shift the blame...