NinerNet Communications™
System Status

Server and System Status

NC036: Update 7

21 March 2026 02:31:38 +0000

Updates will now be sequentially numbered.

We’ve marked server NC036 as “degraded”, because that’s what it is. Email within the group of clients for which we are responsible works. With the outside world, it doesn’t.

Our live monitoring indicates that our uptime is 99.998%, but as we’ve indicated before, this is not 100% accurate. Even AI is “accurately inaccurate”.

You still have access to your account(s) on the server. Please do with that information what you consider to be best for your business.

NC036: A luta continua

21 March 2026 00:21:36 +0000

We implemented the permanent fix yesterday. However, the result seems to be the same: NO EMAIL.

I half expected that this would reveal to me that I had made a stupid mistake, and all this palaver was for nothing. That would have been supremely uncomfortable, but at least we’d all be online. But we’re not.

I know you, our clients, have struggled for the last two days. So have we, there is no doubt. I literally feel your pain.

We have two options at this point, but I want to make clear at the outset that your data — your 5.1 million emails, 2.9 terabytes — are safe. Additionally, I am still alive, which could be a positive or a negative for you, depending on how you view the situation.

Option one, and the option I’d prefer under normal circumstances, is to start fresh with a new mail server, and even just verbalising that fills me with that feeling you get at the beginning of a footrace. You don’t know if you’ll come first, or 101st, but goddam, you’re going to race your heart out.

Option two, to put it succinctly, is to know when to quit. It’s not the end I envisioned when I was supposed to hand over the business and our name in May last year, but nothing lasts forever.

Already I hear most of you leaning towards option two. I don’t blame you. Just get out of the way, Craig, and let me get my email and entrust it to someone with a bigger marketing budget.

If I choose option one, it’s going to take at least a week … and that’s being optimistic. So you will not be able to send or receive email for all of next week, and if everything works, you’ll be online by Monday, 30 March 2026 … I hope.

If I choose option two, that would be like giving the order to “abandon ship”; you don’t want to be in the cold water, but the only other option is even less palatable.

I’ve decided, after much soul searching and personal conversations today, to take option one.

Who knows what NinerNet will look like in a week or a month. However, I know what’s most important for me, and that is that you have your access to the 5.1 million emails you have entrusted to us. You will have access to them, and what you do with them will be up to you.

We will, as always, be communicative, and post updates here. We’re not ignoring your emails — which we ironically continue to receive — but our focus must be and is on keeping everyone as informed as possible.

NC036: Further update

20 March 2026 13:34:40 +0000

We continue to receive reports of continued problems from a very few clients.

We essentially addressed the problem on the evening (UTC) of 19 March. We have yet to put in place a permanent fix. The permanent fix is to attach a secondary volume, and move some back-ups onto the secondary volume, to free up space on the primary hard drive to store and process email. We have not done this yet.

However, we have freed up a huge amount of space, so the server is comfortably handling all the email thrown at it. This is the temporary fix.

The reported problems seem to focus on two areas:

  • Bounced email, and
  • Expected but not received emails.

We have been working on the mail server non-stop for about 21 hour now. We have rebooted the server once (in the morning UTC) and restarted applications a few times. During that time foreign mail servers may have been disconnected in the middle of trying to deliver an email, resulting in their bouncing the email with an error that refers to “losing the connection while receiving the initial server greeting”. Given how often this would have happened (not very much) we’re surprised to see this bounce, but it’s obviously happened. We can only expect these events to lessen as things return to normal.

We ourselves have noticed that emails from external/foreign sources have not been arriving lately. We can only expect that these emails are delayed, and we expect to receive them again in the next 24 hours. Please be patient.

If you check your domain at mxtoolbox.com you will find that it should comply with all or most requirement to have your email delivered. Not complying with every requirement is not necessarily a bad thing.

We expect to have the permanent fix in place within the next 12 hours, but the temporary fix is more than enough to keep the email flowing. Thank-you.

NC036: Most email flowing normally

20 March 2026 07:45:21 +0000

It seems, from monitoring our own company email, that email is flowing normally. However, tests I have done to my personal email address are still delayed. This doesn’t really make sense, as our server is not blocking any inbound email. We’re still working on the permanent fix, but in the meantime there is plenty of disk space to take in the biggest of emails.

NC036: Webmail works

19 March 2026 23:00:40 +0000

We have rebooted the mail server, so the webmail is working again. We don’t know how long that was generating an error, but it wasn’t reported by anyone until a few minutes ago.

NC036: Progress update

19 March 2026 18:15:15 +0000

This seems to be a disk space issue. We have freed up enough space that backlogged email has been released. There should be no problems sending and receiving email now, but we are still working to implement a permanent fix. Apologies for the interruption.

We will have further updates as we implement the permanent fix.

NC036: Mail server issues

19 March 2026 16:48:26 +0000

We have been informed that some clients (probably all) are encountering issues with the mail server. We are looking into the cause now.

NC036: Messages bouncing to fnbzambia.co.zm

26 November 2025 23:20:30 +0000

We have had an ongoing problem with email messages sent to fnbzambia.co.zm over the last few weeks. This is despite our best efforts and the fact that 99% of the rest of our email is handled smoothly.

After asking an FNB client to liaise with FNB over the problem (because they don’t have a working “postmaster” address), we received an email through them from FNB showing that they don’t know how the Internet works. They went to the trouble of telling them that their web server was in multiple blacklist, despite the fact that we obviously send our email through a mail server.

We also found out that the company through which we send some of our mail had some DNS problems a few weeks ago, which explains why some email to fnbzambia.co.zm was bounced.

So we have removed the block that we had instituted on emails to some fnbzambia.co.zm addresses under the assumption that they will now get through. This included an email address to which clients had to send invoices to prove something or another that has to be proved.

Hopefully the problem has now been resolved.

NC036: New DNS entries needed for domains NOT hosted with us

20 November 2025 05:41:07 +0000

If any messages you are sending through us result in a bounce messages that reads as follows:

From header sender domain not verified (DOMAIN.COM)
On your Sending > Verified Senders page
verify the sender domain or email to be allowed to send.

This means you are not hosting your DNS with us.

You need to go to your DNS provider and add the following two CNAME records so that your messages get through:

em460536.DOMAIN.COM
s2g-return.niner.net

s460536._domainkey.DOMAIN.COM
s2g-dkim.niner.net

Of course, DOMAIN.COM must be your actual domain.

If you rely on forwarding any messages to another domain, your senders will likely get the same bounce message. The solution is to stop the forwarding.

Please let us know when you have added the two new records, and we will complete the process.


Updated, 2025-11-21: Added word to title to clarify (because if the domain was hosted with us we’d have the power to change it) and added a missing underscore to the record you need to add. Sorry for that!

NC036: Post-mortem following mail server issue in early June, and explanation of late invoicing

7 July 2025 07:12:58 +0000

As predicted immediately after the June mail server issue (that started on 11 June UTC), problems continued and new problems cropped up, delaying this post-mortem. The two primary results of this were that a relatively simple issue on the mail server that would normally have been addressed before it was even noticed by anyone was not addressed when it should have been, and the second was that our invoices that should have been sent on 15 June have still not gone out in early July! (It’s not unusual for our invoices to go out a couple of days late, but over half a month late is extreme.)

The primary issue on the mail server was that the disk drive that stores our clients’ email was about to fill up. This is a relatively routine occurrence that is addressed with the data centre and on the server in literally minutes in a two-step process: We buy new disk space in our data centre control panel, and then we configure the mail server to use that disk space.

Concurrent with the mail server issue, following fairly routine maintenance on my desktop machine, I could no longer log into it. This was traced to a configuration choice I had made in the maintenance that resulted in the main drive on my machine filling up; instead of the free space on the drive being overwritten with 1’s and 0’s or random data and being classed as free space, it was overwritten with data that looked like real data that could not be overwritten, deleted or re-classed as empty free space. The result was that the installation drive was full and I could not log in. This denied me access to data on my computer, namely a key that I need to log into the mail server to complete the second step listed in the previous paragraph. Very early on 13 June (UTC) I was able to access the encrypted drive on which the key was stored, log into the mail server and reconfigure it to use the additional space, and the problem on the mail server was fully resolved literally seconds later.

While that addressed the problem on the mail server, that, however, was the last time I was able to access the encrypted drive.

While I had access to the encrypted drive I stupidly saved files to it that I had been saving on flash drives. This wasn’t really “stupid”; it was a completely reasonable decision as the hard drive has far more space than the growing collection of flash drives I was using temporarily, and I had access to the encrypted drive and didn’t expect to lose access. As it turns out, since I no longer have access to the encrypted hard drive and the files that I saved to it were not included in a daily back-up that is run when I log into the machine, they now seem to be lost forever. Those files, while important at the time, do not include any vital business files.

A little earlier than planned I started the replacement of the now-just-outdated operating system on my work machine. For reasons I still can’t explain, the new operating system was so incredibly slow that I could make a sandwich and a cup of tea between clicks. (That’s a lot of sandwiches in an eight-sixteen-hour work day!) Several days were spent troubleshooting that issue when it suddenly, for absolutely no reason and without any action on my part, started working properly. The next priority was, since I could no longer access the encrypted drive, recovering backed-up files from the most recent daily back-up. I started with recovering vital business files and was able to immediately contact delinquent clients who apparently don’t pay their invoices until they receive a reminder. Then I started restoring all of the remaining files, meaning I could move forward with June’s invoicing. However, the restoration failed part way through, so I have had to give up and start our billing before the middle of July comes!

Our invoices will be dated 30 June 2025, which I realise is a bit disingenuous, but it keeps them dated in June. The more important dates for invoices are the dates on which your services expire; you can pay your invoice as late as you want (keeping in mind what we have said often in the recent past about waiting until the last minute), but you just need to pay it before your service, domain or certificate expires.

As always, we do sincerely apologise for the disruption that has been caused. What we have learned from this are the following:

  • Keep back-up copies of certain data — i.e., server keys and invoicing records — in places that are more instantly accessible than where all of our other data is backed up en masse,
  • Implement alternative ways of logging into servers where they are available,
  • Implement a data-recovery process that is far quicker than the standard data-recovery process that our current back-up system employs, and
  • Figure out why and how the LUKS encryption with which our hard drive was encrypted failed, and ensure it never happens again.

The third item is already in progress, as we make a second attempt to recover our backed-up data; the fourth will have to happen over an extended period in the future with no goal date and no guarantee of success, but in the meantime the data we recover from our back-ups — that are intact and in place — will be saved in unencrypted form. (Technically this goes against the first point in the “data storage and transmission” section of our privacy policy, but if we cannot access our data, there’s no point in it being encrypted!) The first item will be implemented as part of getting our daily back-ups up and running again, and the second will be implemented where it can be at our earliest convenience.

Thank-you again for your noting this information that we take to ensure that we learn from our experiences where our existing systems have failed. Please advise if you have any questions or suggestions.


Update, 2025-07-09: Contrary to what was stated above about June invoices, we have decided not to send invoices in June — if that wasn’t blatantly obvious, now that it is July — and well be sending June and July’s invoices in July. Please see our post about this on our corporate blog, especially if you have any products or services scheduled to expire soon in July. Thank-you.

NinerNet home page

Systems at a Glance:


Loc.SystemStatusPing
Server NC023, London, United Kingdom (Relay server), INTERNAL.NC023InternalUp?
Server NC028, Vancouver, Canada (Monitoring server), INTERNAL.NC028InternalUp?
Server NC031, New York, United States of America (Web server), INTERNAL.NC031InternalUp?
Server NC033, Toronto, Canada (Primary nameserver), OPERATIONAL.NC033OperationalUp?
Server NC034, Lusaka, Zambia (Phone server), INTERNAL.NC034InternalUp?
Server NC035, Sydney, Australia (Secondary nameserver), OPERATIONAL.NC035OperationalUp?
Server NC036, Amsterdam, Netherlands (Mail server), DEGRADED.NC036DegradedUp?
Server NC040, Toronto, Canada (Web server), INTERNAL.NC040InternalUp?
Server NC041, New York, United States of America (Web server), OPERATIONAL.NC041OperationalUp?
Server NC042, Seattle, United States of America (Status website), OPERATIONAL.NC042OperationalUp?

Subscriptions:

RSS icon. RSS

Twitter icon. Twitter

Search:

 

Recent Posts:

Archives:

Categories:

Links

Tags:

.co.zm domains .com.zm domains .zam.co domains back-up bounce messages browser warnings connection issues control panel database dns dos attack dot-zm domains down time email email delivery error messages ftp hardware imap mail mailing lists mail relay mail server microsoft migration nameservers network networking performance php phplist pop reboot shaw shaw communications inc. smtp spam spamassassin ssl ssl certificate tls tls certificate viruses webmail web server

Resources:

On NinerNet: