The cause of the problem has been pin-pointed to one domain on astro that was under a mail bomb attack to various non-existent users.  The catch-all email account has been set to :fail: to discard all this unwanted email.

By using :fail: mail does not enter the network for processing but instead is rejected at the point of the initial SMTP connection.

What complicated things this time around is that this particular account had also exceeded it’s disk quota.  Mail bounces/delivery were then queued for processing and filtering.

It’s important to disable the catch-all email address for any/all accounts that do not require this facility.  And equally as important to ensure that mail is POP’d / cleared from the server on a regular basis.

Thanks for your patience whilst this issue was addressed.   We’re expecting the server load to remain at it’s normal levels.

We’re also forcing a mail queue run as there were just under 800 emails that were stuck in the delivery queue.  The oldest message was 84 minutes old.

We’ve just rebooted astro (unavailable for 3 minutes) so that we can further track down the cause.

It appears to be mail related.  Either a mail bombing or run away script.  Loads should remain a little more stable but we can expect a slightly slower than normal response to mail and web site requests as we trawl logs.

Another post will be made once more information is available.

Astro is currently experiencing high loads.  This is resulting is some/all services failing.

We’re investigating the cause now, please hold tight.

No further interruptions are expected as a result of the issue experienced earlier today.