NinerNet Communications™
System Status

Server and System Status

NC036: Evaluating the effectiveness of being listed in the UCEPROTECT whitelist

19 July 2024 03:57:16 +0000

Just about a month ago we became aware of the problem with delivering email to Microsoft-hosted domains. At that time, one of the actions we took was to pay to have our mail server’s IP address listed in the UCEPROTECT whitelist that effectively removed our IP address from a huge list of blacklisted IP addresses that are only listed because of the lackadaisical approach of our data centre (Digital Ocean) to removing spammers from their network of data centres.

We weren’t certain at the time that this action would achieve anything and, to be frank, we have no concrete evidence to believe that our doing so has had the desired effect. We think there is strong evidence that it has, but there is no way we can determine that definitively. The strong evidence is that we have had very few problems with mail to Microsoft-hosted domains since a couple of days after the problem started on 20 June.

Our subscription to this whitelist expires on Monday the 22nd. To test the effectiveness of this subscription we are going to allow it to lapse. If we see a sudden uptick in email messages to Microsoft-hosted domains bouncing then we’ll take that as evidence that the subscription is working, and we’ll immediately renew it. In that case, messages you send to such domains will bounce temporarily, so please forward those bounce messages to NinerNet support and we will immediately divert future messages to those domains via our secondary outbound mail servers. This is a temporary and planned test; if these bounces happen it is not evidence that our systems are failing for any reason. If they don’t bounce then we will have learned that our paying for the listing is a waste of money.

The purpose of this message is to let you know of this test in advance. We expect that if messages start bouncing again and we renew the subscription, everything will be back to normal within about 24 hours, and immediately for domains we add to our mail server configuration to have messages go out via our secondary mail server. That said, we have also found that retrying if you get a bounce in this situation sometimes succeeds! It’s bizarre.

Thank-you for your continued patience with issues like this thrown at us by massive providers that don’t care about you, people who choose to host with their competitors.

NC036: Significant issue with delivery of email to Microsoft-hosted domains

21 June 2024 03:51:33 +0000

Yesterday, 20 June 2024, multiple clients began contacting us to report that email they were sending to certain domains was bouncing. We responded as usual by routing messages to the problem domains via our secondary SMTP server. In other words, this wasn’t an unusual experience, and we mitigated it immediately as we always do.

However, it very quickly became apparent that all of the problem destination domains in these multiple reports were hosted by a single hosting provider: Microsoft … or Outlook, or Hotmail, or however they’d like to be known today.

As we’ve said to our clients for many years, fighting spam is a never-ending battle. It’s a big issue for hosting companies big and small; however, the power of small hosting companies like NinerNet to deal with massive companies like Microsoft, Gmail, Yahoo, etc., is almost non-existent. Actually, it’s not almost non-existent, it is totally non-existent. For many years NinerNet has been (and still is) a member of or participant in the Outlook.com “Smart Network Data Services” system. This was supposed to give small providers like NinerNet access to the decision makers at Microsoft (the so-called postmaster[s]) so that we could work out issues together as if we were all grown-ups. However, it has never actually worked that way. Instead, the big hosting providers listed above treat companies like NinerNet with disdain. After all, we’re competitors, and every client who hosts with NinerNet takes away revenue from the big boys.

The rest of this blog post is lengthy, and goes into a fair bit of detail. The summary is that a huge email hosting provider (Microsoft) has suddenly made sending email to them very difficult for us, but NinerNet has done and is doing everything we can to provide a working service to our clientele.

Today we find we’re in a situation where one of the biggest email hosting companies in the world — owned and run by Microsoft — is refusing email from companies like NinerNet. This is anti-competitive, which you wouldn’t expect from a company headquartered in a country where the competitive marketplace is supposed to trump (pardon the pun) everything else.

The bounce messages generated by the failed deliveries offer a “delisting” service, purely because Microsoft seems to actually realise that they have acted with a very heavy hand in this instance. However, when we tried for the third time to get our mail server’s IP address delisted, the automated response we got was that, “The IP address in question is not currently blocked in our system.” This is interesting.

What we believe has happened here is that Microsoft are using a blacklist that includes every single one of the IP addresses owned by the company where a number of our servers (including our primary mail server) are physically located, and have been located for about eight years. This company is Digital Ocean. Why are all of Digital Ocean’s IP addresses blacklisted? Good question. The summary seems to be that Digital Ocean has no interest in dedicating resources to keeping spammers off of their servers. This results in their telling their customers (like NinerNet) that they should send all email out via third parties. This is a ridiculous and expensive requirement, of course, because that is not how the Internet was designed several decades ago, and it’s not how NinerNet operates or has ever operated. When this requirement was forced on us by another data centre company many years ago (Interland), we refused and moved our business elsewhere. For sometime now we have known that the data centre for our next mail server would not be a Digital Ocean data centre but, strangely enough, Microsoft didn’t give us any notice of this change in their practices. And as you know if you’ve been a NinerNet client for any length of time, moving email hosting to a new server is no small undertaking.

The result of Digital Ocean doing nothing to keep spammers out of their data centres is that their IP addresses (including ours) have been elevated from UCEPROTECT Level 0, to Level 1, to Level 2 and finally (over time) to Level 3. UCEPROTECT describes Level 3 as listing the “IP Space of the worst ASNs”. (An ASN is a “Autonomous System Number”, “an identifier for a collection of IP networks and routers under the control of one entity”. [Wikipedia.]) So NinerNet’s mail server is in a blacklist, not because of something we or one of our clients have done (or not done), but because Digital Ocean fails to do anything to keep spammers off of their systems.

For sometime we have known about the fact that UCEPROTECT has a system by which companies like NinerNet, who have no track record of providing safe harbour to spammers, can have their IP address(es) whitelisted, so that we are essentially excluded from the Level 3 blacklisting of all Digital Ocean IP addresses. Previously we chose not to do this because of the added expense, and we preferred to spend money on other ways (described in the first paragraph of this post) of mitigating this problem. However, we have broken down and paid a fee to UCEPROTECT to have our IP address whitelisted.

Therefore, if we are correct in deducing the cause of the current problem, we expect that email to domains hosted by Microsoft will be delivered without hindrance starting by about 04:18 UTC today, 21 June 2024.


Update, 2024-06-22: We thought that our having paid for an exception to the UCEPROTECT blacklist had solved the problem. And it does seem to have solved the problem, for the most part. However, very oddly, messages to only some Microsoft-hosted domains are still being blocked with the exact same bounce message that directs senders to their article, “External senders – Use the delist portal to remove yourself from the blocked senders list and address 5.7.511 Access denied errors” at http://go.microsoft.com/fwlink/?LinkID=526655, which redirects to https://learn.microsoft.com/en-gb/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself?redirectedfrom=MSDN. (The 5.7.511 error in the title does not appear to apply to the messages bounced from our server, as those errors are 5.7.1.) However, every time we try to have our mail server’s IP address delisted, the response we receive is, “The IP address in question is not currently blocked in our system.” So why are messages being blocked?!

This seems to be a ridiculous game of cat-and-mouse that Microsoft are playing instead of being open with people about what they are doing, and companies like NinerNet cannot do anything to counter that. It makes absolutely no sense, and doesn’t serve Microsoft, their customers, or NinerNet or our customers.

So in these circumstances, if you’re still having messages to Microsoft-hosted domains bounced — you will know if you see references to Outlook(.com) and Microsoft(.com) in the bounce message — please forward the bounce message(s) to NinerNet support and we will add the problem domains to the mail server configuration that redirects messages sent to those domains via our secondary SMTP server. This is the same procedure that we followed previously, but we were hoping to avoid that procedure by buying our way out of the UCEPROTECT blacklist. However, at least now the number of Microsoft-hosted domains that we have to add to our mail server configuration should be far less than previously.

Again, we apologise to you, our clients, for this non-consensual position in which Microsoft has put us and many small hosting companies around the world.

Update, 2024-06-28: Over the last week we have added a grand total of 21 domains to our mail server’s configuration to redirect outgoing messages to them via our secondary mail server. In that time we have learned that there is no consistency to the problem. Sometimes mails that are blocked are delivered five minutes later if the sender retries, without our adding that domain to our mail server’s configuration. And delivery succeeds to some Microsoft-hosted domains consistently without any intervention by us. There’s nothing more frustrating than an inconsistent problem that is not possible to troubleshoot.

So at this point it seems that we are back to the point we were at before this incident started. Here is a summary of what has transpired:

  • All emails to Microsoft-hosted domains started bouncing.
  • We paid to be removed from a blacklist that we thought might be the cause.
  • This seemed to help to some extent, but over the course of the next few days we added 21 destination domains to our mail server’s configuration to direct messages to those domains via our secondary mail server.
  • We are still exploring alternative ways of automatically determining the MX record of destination domains and automatically redirecting mail to Microsoft-hosted domains via our secondary mail server.
  • We are also still looking for ways to contact Microsoft to determine the cause of this issue, but we hold out little hope of doing that.
  • This server will be replaced in the near term. To that end we will be looking for a data centre where we won’t run into the issue of all of their IP addresses being blacklisted as is the case where our primary mail server is currently located on a Digital Ocean IP address.

As always, if you have mail you send bounced by Microsoft, please forward the bounce message to support and we will add the destination domain to our mail server’s configuration. We appreciate your patience and continued patronage.

Virus update 3

12 August 2020 05:41:35 +0000

As we approach a week with this issue, we are forced to make a decision. We continue to evaluate a number of options, and we’ll implement more than one, but the bottom line for us is a usable email system for our clients, or at least the vast majority of you.

In order to allow the vast majority of our clients to carry on business as usual, at 04:15 UTC today, 12 August 2020, we removed the attachment restriction we put in place late last week. According to reports, this will result in difficulty for one, or possibly two clients who have been overwhelmed recently by spam email that contained these attachments. On the other hand, we have heard those clients that have told us that their businesses have been stalled by these restrictions.

However, that isn’t the last or only action we have taken or will take on this matter. These are others:

  • The lack of speed with which our anti-virus vendor (ClamAV) has picked up this virus means we will be looking at options for either internal or external secondary virus scanning of our incoming and outgoing email streams. If this was something we already had in place, this disruption would have been hardly noticed by more than a few clients. This is the priority with which we are currently seized.
  • We continue to look into ways to apply certain restrictions to some domains and not others in a virtual-hosting environment.
  • Virus samples have been submitted to ClamAV and we anticipate that they will add the recently received viruses to their virus-detection database in due course.
  • We will make an offer to the client most affected by this virus outbreak to move their hosting to a virtual private server of their own.
  • We have blocked several thousand IP addresses that have been the sources of the problem attachments over the last week, and we will block more.
  • Server NC036 is approaching its scheduled replacement time frame. Had our plans been further along when this happened we’d have executed them immediately. However, there are always potential issues when implementing half-baked plans too far ahead of schedule, so we didn’t.

There are potential issues that you need to be aware of:

  • Some anti-virus scanners, not the least of which is ClamAV, are not detecting some of the recent viruses we have seen. You must ensure that you have anti-virus software installed on all of your machines and devices, and you must ensure that this software is automatically updated at least daily. Please remember that the responsibility for the safety of your computer(s) and your data is ultimately yours.
  • You and your employees need to be aware of the risks of opening attachments, and need to be aware of how to evaluate that risk. The risks are to both your machines and devices, and to your organisation and employees.

What have we learned from this experience? Other than our surprise at the degree to which some businesses rely significantly on Microsoft Word documents flying around the Internet, we have learned that the anti-virus vendor on which we have relied without issue for about a decade is not, in fact, infallible. We need, and will obtain, redundancy in this area.

Something else we have decided to act on is SPF (Sender Policy Framework) records. All domains we host have SPF records that tell all mail servers on the Internet that they should accept email only from our servers. The records have all ended with “~all”, but this weekend we will update all records to read “-all”. The difference is that the old records with the tilde (~) allowed receiving servers to act with some leeway, a so-called softfail; the hyphen (-) will enforce that all mail received from domains we host must come from our servers, or any others that are designated in the domain’s SPF record. What will this accomplish? One of the things we have seen is the domain of one of our clients being extensively and aggressively “spoofed”. This is when emails are sent purporting to come from a domain other than their real origin. SPF is designed to prevent this, but the directive with the tilde allows leeway that, it seems, can be too easily abused.

If you believe this may be an issue for you, or if you have any questions at all, please contact NinerNet support and we will assist.

Thank-you very much for your patience.

Virus update

10 August 2020 09:53:46 +0000

After three updates to the virus database on NC036 since Thursday we expected that the anti-virus scanner would detect and block the trojan that is currently overwhelming some of our clients. However, that is not the case.

For that reason we are once again blocking the attachments that are the cause of this problem. We sincerely apologise for this situation.

Again though, if you need to send a blocked attachment type, you can still do so if you compress the file into a .zip document. Your correspondents can also do the same.

If you are getting an error message when trying to send email, the first thing you need to do is check to see if you have attached a file to your message. If you have, and it is one of Microsoft’s typical Word documents, please remove it, compress it, attach the compressed .zip file, and then send that attachment.

If you have any questions or concerns, please contact NinerNet support. Thank-you.

Zero-day virus getting through the mail server

6 August 2020 13:39:04 +0000

Within the last four hours we have been made aware of a trojan that is getting through our anti-virus scanner undetected. Once we were able to determine the file types that were attached to the emails, we blocked those kinds of attachments from being delivered to the server. Doing so also resulted in our being able to compile a list of sources of the offending messages, and we have been busy blocking email from scores of IP addresses.

Although we do scan both inbound and outbound email in real time for viruses, we do very strongly recommend that you have an anti-virus program installed on your local computers so that if anything does get through, it will protect your machines. Please remember that unsolicited attachments from unknown senders are extremely risky for you to open; even attachments from known senders are risky; please contact the sender through some other method — e.g., a quick phone call or text message — to confirm that they sent it and that it is safe to open. Even then you should first ensure your anti-virus software has been updated, save the file to your hard drive, and then manually scan it for viruses. Only if you have carried out all of the above should you consider opening the file.

Please remember that the responsibility for the safety of your computer and your data is ultimately yours.

We expect that the anti-virus vendor will update their virus signatures in due course. Until then we will be blocking all attachments that look the same as this particular outbreak. If you have a correspondent who needs to get a blocked attachment through, please tell them to compress the file and send that attachment instead.

If you have any questions, please contact NinerNet support. Thank-you.

NC036: Mail server blocked by Microsoft

14 December 2018 05:33:38 +0000

We are aware that the IP address of server NC036 (the primary mail server) has again been blocked by Microsoft’s various mail services, variously known as Outlook.com, MSN, Hotmail, Live.com, etc.

Although we are a member of their Smart Network Data Services programme and Junk Mail Reporting Program, which are supposed to allow us to proactively prevent these kinds of issues, we have been unable to use the service as advertised, or at least as we understand it’s supposed to work. We will continue to attempt to have this server’s IP address removed from their blacklist, and report here when we have success.

In the meantime, outgoing mail to their primary domains (hotmail.ca, hotmail.com, hotmail.co.uk, live.com, msn.com and outlook.com) is being routed through our relay server. If you receive a bounce message that reads similarly the one below to an email you’ve sent, it is probably for a private domain hosted by Microsoft of which we are not aware. Please contact us and we will add it to the list of domains for which email is routed through our relay server:

host 901e3cd0af6f44ab11b5a5e8a49da3.pamx1.hotmail.com[104.47.0.33] said: 550
5.7.1 Unfortunately, messages from [178.62.195.26] weren’t sent. Please
contact your Internet service provider since part of their network is on
our block list (S3140). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors.
[HE1EUR01FT033.eop-EUR01.prod.protection.outlook.com] (in reply to MAIL
FROM command)

Please remember that all email you send through our mail server must be to recipients with whom you already have a business or personal relationship, and all mass email must be explicitly requested — i.e., Confirmed opt-in (COI) or Double opt-in (DOI) email.

Thanks for your cooperation, and our apologies for this inconvenience.

NC036: Migration update 25 — Final

18 June 2018 08:54:43 +0000

The migration of all email accounts from server NC027 to server NC036 is complete. In fact, it was successfully completed at 04:00 UTC on 4 June. What followed over the next few days was an unprecedented avalanche of misinformation and red herrings that resulted in our moving the new server to another data centre (a move that took ten times longer than the previous move from the data centre where NC027 was located) where the same “problems” experienced by only some of our clients magically reappeared.

We planned the migration to have absolutely no impact on existing email configurations. We did this by pointing legacy sub-domains of the niner.net domain that named server NC027 — e.g., smtp27.niner.net — to server NC036. At the conclusion of the migration these sub-domains were indeed pointing to the new server. In other words, on Monday morning (4 June) email programs would have thought they were still downloading mail from the same server, not realising (or needing to realise) that they were in fact downloading from a new server.

However, it turned out that a significant minority of email programs were somehow misconfigured with settings that worked on the old server, but stopped working when connecting to the new server. Those clients who were using the correct settings experienced no disruption at all, and when those clients with incorrect settings corrected them on the morning of Monday the 11th, the problems were fixed instantly.

Over the rest of that week (11-15 June) we helped a few clients with some issues unique to how they use email, especially where those practices clashed with current best practices for email transmission. We also dealt with some issues of senders whose mail servers were behaving improperly, causing their emails to be blocked because they looked like spammers. This notably affected email from the ZRA, but their emails are once again flowing unimpeded.

We’re monitoring the spam filtering on the new server. Any message that the server identifies as spam will have the subject of the message prefixed to add “[SPAM]“. You can use this to configure your email program or the webmail to deal with spam automatically, by filtering it into your “junk” folder or deleting it entirely. We recommend filtering to the junk folder so that you can catch the occasional legitimate message that is misclassified as spam.

Finally, in recognition of the fact that the emergency migration of the server to a new data centre on 6 June disrupted all clients’ email, and the fact that those clients with misconfigured email programs experienced a week of disruption before the issue was identified, we will be applying a one-week (quarter month) credit to the accounts of all clients hosted on server NC036. We apologise for the difficulties caused, and will apply what was learned this time to future migrations.

Thank-you, as always, for your custom and patience.

NC036: Migration update 23 — SMTP AUTH is required for users under this sender domain

11 June 2018 09:38:23 +0000

There are two reasons why you may be getting the above error in response to messages you’ve sent to addresses on domains hosted by NinerNet, likely your own domain:

  • It may be because you’re sending from an address on a domain that we host, but instead of sending your email through our SMTP server (smtp.niner.net) you’re sending through another SMTP server, possibly that of an ISP or another email service provider. In some cases this can happen because of a situation similar to that described in the sixth bullet point of our post “NC036: Migration update 20 — Solutions“, where you’ve sent the email through a third party, perhaps an ISP, or an email account you have with another provider.
  • If you’re using some cloud-hosted application that tries to send email to you as you (or another user on your own domain), then that email looks like spam to the mail server, because lots of spammers mistakenly try to get their email through by sending their spam from your email address to your email address, or from another address on your own domain to you.

The solutions are, respectively (and respectfully):

  • Configure your email program to use smtp.niner.net to send email from any domain that we host. If you’re following the configuration instructions we send you, then that is the case by default, and always has been.
  • Have the provider of the cloud service send those emails from an address — even a “no-reply” address — on their own domain, or use SMTP AUTH to send the email through smtp.niner.net from an address on your own domain, just as you or any other human with an address on your domain would.

NC036: Migration update 22 — A word about forwarding email

11 June 2018 08:36:59 +0000

Over the years we’ve noticed that a certain percentage of our clients are in the habit of forwarding all of their email to external free webmail services — e.g., Yahoo, Hotmail, Gmail, etc. Why do we even notice this? Well, because these free services often delay your email, and so it queues on our server for anywhere between minutes and days. There are complicated reasons for this, but once you realise that you’re not the only one forwarding your email, you can see how these free webmail services might decide to limit the number of messages that they accept from our servers. This is especially noticeable when (not if) a few spams get through and (ironically) the receivers — the very NinerNet clients who have configured their email accounts here to forward to their free webmail provider — complain to the free webmail provider about the spam by clicking the convenient “this is spam” button. The free provider then responds by blocking or limiting mail from our server, making the reporting of the spam by the NinerNet client self-defeating!

Among other reasons, what people who do this are running into here is introducing multiple points of failure. If a message arrives on the NinerNet mail server, it’s made it! It has arrived where it was intended by the sender to be delivered. But now you’ve told our server to forward it somewhere else. It’s like telling a runner at the finish line that he has to do the same race again. And the runner might not make it the second time, just as your email might not make it into your Gmail account.

Right now there are a few dozen emails queued on our server waiting to be accepted by these free email services. Given that some of them have been queued for several days, most of them will likely bounce back to the senders within the next few hours. There is nothing unusual about this; we see it all the time, and it has little (if anything) to do with the mail server migration.

If webmail is your preferred way of accessing your email, we do (obviously) provide webmail on your own domain. (And non-Gmail webmail these days is way better than it used to be!) If you prefer the webmail offered by your free provider of choice, that’s fine, as long as you’re aware of the inherent risks of delayed and bounced email if you choose to forward everything.

If you’d like to discuss alternatives to forwarding your email, let us know and we can provide options to you or address any concerns you may have.

NC036: Migration update 14 — Microsoft blocks

6 June 2018 15:43:33 +0000

It seems that Microsoft blocks every IP address on the Internet by default, except those for which mail server administrators like NinerNet have to beg repeatedly to have removed. Our requests keep being ignored, despite the fact that we are members of both their Smart Network Data Service (SNDS) and their Junk Mail Reporting Program (JMRP), but we will keep trying.

Currently this means that we route Microsoft’s main domains — hotmail.com, outlook.com, msn.com and live.com — through our relay server which is not blacklisted as it pre-dates their aggressive blocking practices. However, if you send email to a non-Microsoft domain hosted by Outlook/Office365, you will almost certainly receive a bounce message that looks like this (if the domain you sent to hosted by Microsoft is “exampledomain.com”):

Remote-MTA: dns; exampledomain-com.mail.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.606 Access denied, banned sending IP
    [178.62.195.26]. To request removal from this list please visit
    https://sender.office.com/ and follow the directions. For more information
    please go to  http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609)

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), OPERATIONAL.NC036OperationalUp?
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: