NinerNet Communications™
Blog

Corporate Blog

WHOIS contact form blocked

1 January 2026 03:50:32 +0000

For some time now the main registrar we use has been masking domain ownership in the WHOIS and providing a default email address for all registrants on the domain-contact.org domain. They provide a contact form on that domain as well. However, spammers have been using that form to spam because, apparently, Centralnic doesn’t care to protect registrants from spam and therefore protect it from automated submissions.

So we are adding domain-contact.org to the spam filter. This will send all email from that domain to the quarantine.

If, for some bizarre reason, you count on contact from that form — which, in thirty years, we think nobody ever does or has — please contact us to advise us, or know that you need to check your quarantine on a regular basis.

Some people can’t even run nameservers, Weebly for example

28 December 2025 20:17:13 +0000

One of our clients decided to host their website on Weebly. Our experience has been to let people follow the instructions on the websites of people like Weebly, Wix, WordPress.com, etc., to use their nameservers under a number of understandings:

  • Such web-building websites claim that they need the ability to change the IP address of the user’s website at short and/or unannounced notice, and giving them control of the nameservers allows them to do this to minimise downtime, and
  • They give the client control over their nameservers under a control panel, so that the clients can add and manage nameserver records at will.

Unfortunately, as of this month (December 2025), Weebly’s nameserver controls were not working. Nameservers are used for a number of routine and esoteric purposes; you can, for example, create a TXT record that says, “Hello world!”, which does nothing but say hello! 🙂 One of the suppliers of a few of our clients actually does this on one of their domains, if you can believe that:

user@machine:~$ dig +short txt resrequest.co.za
“Hello world!”
user@machine:~$

They don’t even create a TXT record that does anything useful, like direct users to the TXT record of resrequest.COM for useful information about a secondary domain that they use in certain circumstances.

Anyway, one of the more routine reasons to create any kind of record is to show certain information to other users (which include people and machines) for the purposes of authentication, which is why some organisations have you create TXT records like “google-site-verification=y0se7y0r7ygncCNYW0RE09T078989c90nmt89cnsygf”. But if you have no control over your DNS — which was the case with our client — you can’t create such a record, and so you can’t authenticate yourself with Google. In our case the client couldn’t create two CNAME records which are required by the email system to authenticate your domain. The Weebly control panel seems to provide this functionality, but it doesn’t work; the records you create do not exist in the DNS, and they don’t even appear in the control panel. Since the domain was created through the Weebly system, access to configure the domain wasn’t available through the registrar, so we had to transfer it immediately to take control so that we could create the necessary CNAMEs. Now the domain does not use Weebly’s nameservers, which means that their website could be down one day if Weebly chooses to change its IP address, but their email was down for a week or two because they couldn’t create the two necessary CNAMEs.

So it depends what’s more important to you: your website or your email. Weebly has demonstrated their incompetence not only by having a control panel that doesn’t work, but by their support personnel giving our client an absolutely BS excuse that reminded me of another client being told years go that something he was trying to do wouldn’t work because “the Internet was down”! The Internet was down! The whole Internet! My god. In this case the client was told that something completely unrelated (the DNS) was broken because someone sent a plain-text email. I can’t even connect the dots on that one because the dots are all over the place; there is no way that sending a plain-text (or even HTML-formatted email) can affect the DNS, as the two systems are not connected, related or affected by the information in one system affecting the other. Maybe the information was relayed to me incorrectly, but to me this sounds exactly like someone trying to baffle the client with BS.

So, in the future, we will advise clients using Weebly not to use their nameservers, but to use ours, where they have working control over the DNS for their domain.

We have, once again, blocked all email from a Centralnic domain sold as a ccTLD

19 December 2025 06:25:00 +0000

Previously we blocked sa.com and za.com, but we are now blocking us.com as well. This means that any email from @spammer.us.com will be blocked. We were inundated with spam from us.com sub-domains recently, and we won’t put up with it any more.

Sorry, not sorry.

Email auto-forwarding: DON’T DO IT!

23 November 2025 12:14:16 +0000

Email is a tough business. Some of our biggest competitors have got out of it. We’re rapidly heading for a time when there will only be one, two, maybe three email providers in this world. I don’t tell you this in the wee hours of a Sunday morning to get your sympathy or to announce a price increase as of Monday morning. One of the more difficult parts of email is the part that many people find the easiest: Forwarding.

Why is it difficult?

As we stated recently, during a certain time frame recently 80% of the mail received by our mail server was spam. 80%! And that was only the messages that were caught by our spam filter! Imagine if 80% of your email was spam. Well, it probably was during that time frame; if it wasn’t, other people were probably above average, meaning that more than 80% of their email was spam. If you we’re getting less than 80%, you are probably following some of the tips we provided in our “Why do I get so much spam?” post last year.

Forwarding has been a major concern of ours for years, and we have advocated against it for almost as long. It’s not just us; our relay provider (SMTP2GO) forbids it in their Terms of Service. This means that if you are “auto-forwarding” your email, you are helping us break the Terms of Service of our agreement with one of our critical suppliers, which will mean that one day none of your email will go out. This is what we have been warning about for years.

What is “auto-forwarding”?

“Auto-forwarding”, a term that was new to me five years ago even though the practice was not, is when you configure your email account to forward all (or almost all) of your email to a third domain, usually a free webmail provider. It might only be “almost all” if you have a filter in place to forward only certain messages, but in all case you are automatically forwarding your email, 24/7, without taking a moment to determine whether or not the message is spam. And if 80% of your messages are spam, then 80% of what you forward is also spam, and you (and we) look like the sender of that spam to the other mail server.

This is not good.

Some of you might have noticed that you’re receiving a lot less email lately. That’s because you have auto-forwarding in place. SMTP2GO will not forward email that is from a sender not authorised/verified in their system. And since spammers/phishers aren’t one of their verified senders, their messages bounce. This is good, right? So why are you writing a long blog post that tells us we’re getting less spam now?

Ah, there’s the rub. Neither are some (most) of your business and personal contacts in their list of verified senders, so their messages bounce too. Now the news is not so good.

The solution

So what’s the solution? Stop forwarding your email! No, seriously, it’s just that simple. There are other ways to achieve what you want to achieve. I’m not going to start listing them all and telling you how to achieve what you believe you are achieving, but if you’re not sure, just ask!

At the risk of signing off in a predictable manner that has become familiar to anyone watching the news these days, “Thank-you for your attention to this matter.” No seriously, thank you. If you’re auto-forwarding your email, we need you to stop doing it for your own benefit, as we’ve been saying for years.

Using the mail server control panel to manage your email

28 July 2025 02:21:47 +0000

Back when NinerNet started in this business in 1996, we had to do everything for our clients, and I do mean everything. I’m not going to list “everything” because you’ll stop reading, but one example is creating an email account. This was because control panels hadn’t been invented yet.

Now we have control panels, but because it seems that email “just works”, people don’t take the time to look at their control panels to determine why things “just work”. Let’s leave aside the mail service providers that “just don’t work”, as illustrated in our last post.

One thing that isn’t quite 100% automated yet, because humans are still needed, is reading the minds of email senders. Incoming spam is pretty close to 100% automated thanks to programs like SpamAssassin and blacklists. Handling incoming email is close to 100% automated because the onus is on the senders to do something to ensure that their messages are not seen as spam. It’s not a big secret that, for example, this subject indicates that the message it contains is probably spam: “GET RISH QUICK!!! MILIONS WHILE YOU SLEEP!!!!!” So guess what? You don’t receive messages with that subject because they’re caught and deleted by spam filters. (Yes, those spelling mistakes are intentional.) If you use a bulk mail service provider to send mass emails to your clients, as you should if you do send them, they try to educate you on what markers will trigger spam filters, and they also usually provide some sort of testing platform that will analyse your message to determine whether or not it might be caught by a spam filter.

But two things blow me away:

  • When clients send emails to themselves, and
  • When those emails are marked as spam so they never arrive.

Now, it does occur to me that maybe their using our system to test their email to see if it will be considered spam. But really, the examples we’ve seen are definitely not that! Most of the time they’re sending themselves a file that is attached. Why?! They obviously already have the file, so why are they sending it to themselves?!

The problem is that we don’t know if the client knows why they didn’t receive the message they sent themselves. Have they assumed that NinerNet “lost” it? I sure hope not, because we know exactly where it is and why it wasn’t delivered. And if the client logs into their control panel and looks at their “quarantined” messages, they’ll know as well!

Here’s an example of a message that a client has been sending themselves continually for about a week now:

Self-spam.

Self-spam.

Here’s the plain-text view:

Content type: Spam
Internal reference code for the message is 01478-17/tLRgpsMsQL9j

First upstream SMTP client IP address: [160.242.61.xxx]:37436

Received trace: ESMTPSA://[160.242.61.xxx]:37436

Return-Path: <xxxx@xxxxxxhydraulics.com>
From: wade <xxxx@xxxxxxhydraulics.com>
The message has been quarantined as: tLRgpsMsQL9j

The message WAS NOT relayed to:
<xxxx@xxxxxxhydraulics.com>:
250 2.7.0 ok, discarded, id=01478-17 - spam

Spam scanner report:
Spam detection software, running on the system "nc036.ninernet.net",
has identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: [...]

Content analysis details: (4.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME
0.0 HTML_MESSAGE BODY: HTML included in message
1.7 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words
0.8 MPART_ALT_DIFF BODY: HTML and text parts are different
0.5 MISSING_MID Missing Message-Id: header
1.8 MISSING_SUBJECT Missing Subject: header
2.3 EMPTY_MESSAGE Message appears to have no textual parts
0.0 TO_NO_BRKTS_HTML_IMG To: lacks brackets and HTML and one image

Let’s analyse each of these points on which the email message was scored for spam. Let me say first of all that negative scores are good, so we won’t waste our time with those. I’m also going to focus on only the scores above 1:

1.7 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words
* If your message is just an image it probably won’t get through. You need to add text so that the spam filter believes you’re explaining/describing the image.

1.8 MISSING_SUBJECT Missing Subject: header
* Use a freaking subject! If you’re really just sending a message to yourself, mash some keys in the subject line! It doesn’t matter what they are.

2.3 EMPTY_MESSAGE Message appears to have no textual parts
* Again, if only you yourself are going to see the message, mash some random keys in the body of your message.

Messages with a spam score over 3.5 are considered spam, and this message consistently receives the above score of 4.3. If this person would just do one of the things above — mash some keys in either the subject or body (or both!) — he/she would get his or her message. And yet, I get a copy of this spam report every time he/she tries. It’s frustrating, for me and (I assume) for the sender that never receives a copy of their message!

Of course, in line with the subject of this post, the sender can also log into the control panel, navigate to their quarantine, mark the message they sent to themself and “release” it.

Continual problems with South African ISPs and mail service providers (Afrihost and Xneelo)

27 July 2025 23:36:22 +0000

I’ve just spent about seven hours writing a long, detailed and evidence-based reply to a client who just receives nothing but BS, delay tactics and obfuscation from a South African mail service provider named Afrihost. (Please see here for the details of the never-ending Xneelo debacle, which is similar.) I am posting this here so that I can at least get some mileage out of this waste of seven hours of my life, on a Sunday.

Names and addresses have been changed or redacted to protect the guilty.

Hi Bob,

Thanks for your email. You only sent one side of a supposed email
exchange with Afrihost; there was no "back-and-forth" so I see no
evidence, namely domains (besides your own domains, which are only one
side of the equation, and hotmail.com), IP addresses, dates, times and
(most importantly) bounce messages. In particular I see no evidence --
no *proof* -- on Afrihost's side that what they are saying is true.
Anybody can say and claim anything they want, but it's pointless if
they don't back it up with evidence.

Unlike in politics, everything I have said in the past about email and
everything I will say in the future (including below) is technical and
backed up by hard evidence. Lying to paying clients is a complete waste
of time and will not end well, but it seems that the support
departments of bigger companies like Afrihost are schooled in BS and
delay tactics, rather than providing actual support or admitting fault
and actually fixing their broken systems.

This email is long (I won't apologise) because email is complicated and
this message is based on the work that Afrihost won't do to address
your one puny complaint because they have a lots of other complaining
customers to BS with their lies. The hours (about six so far today just
to answer your email full of Afrihost lies) of work *I* have to do to
give you a full and honest answer and explanation is something that
doesn't increase their share price, so they won't do it. But my efforts
seem to be worthless because everyone seems to believe BS these days
rather than concrete proof.

Here is my actual evidence / hard proof:

* https://multirbl.valli.org/lookup/ucebox.co.za.html
* This is a domain-based list of mail servers that are in blacklists,
and this is a search based on ucebox.co.za, which shows their domain in
one blacklist.

* https://multirbl.valli.org/lookup/smtp.ucebox.co.za.html
* This is the same as above, but with the alleged name of their sending
(SMTP) server (definitions below) provided in the Afrihost message
below, and the results show that their SMTP server is in the same
blacklist.

* https://multirbl.valli.org/lookup/197.242.159.57.html
* The sub-domain smtp.ucebox.co.za resolves to twelve different IP
addresses. This is a search for one of those IP addresses, and that IP
address is in five blacklists!

* https://multirbl.valli.org/lookup/41.76.215.28.html
* Like the search above, this is a search for another of their twelve
IP addresses -- both this one and the one above are random choices because
I'm not repeating the search twelve times when the results for *two* of
them are bad enough. This IP address is in six blacklists!

A quick glance shows that the blacklists all seem to be the same (which
is not surprising), so they are not in a total of 13 blacklists, just
the greatest number of 6. In comparison, NinerNet's mail server is in
three:

https://multirbl.valli.org/lookup/178.62.195.26.html

The point is not to compare numbers and say that our number is smaller
and so we're better; the point is to say that we're aware of the
problem, and the information we have provided on our blogs (
https://blog.niner.net/tag/email and https://status.niner.net/tag/mail
) goes towards explaining certain things.

In there we explain our presence in two of the blacklists (Ascams and
UCEPROTECT), which cover every single one of the IP addresses owned by
our data centre; it is *not* because our mail server has done anything
to be in that blacklist. The only full remedy to that problem is for us
to move our mail server to another data centre with another company,
which is not something that we can do on a whim and without
considerable forethought and planning, but which we *will* be doing on
the next move. What we do to overcome this problem is to redirect all
email to certain domains through our secondary SMTP server; problem
solved. It's impossible for us to know in advance what those
destination domains are, but as soon as one is reported by one of our
clients we direct all future messages to that domain through our
secondary SMTP server. Problem *immediately* and *fully* solved. (By
the way, hotmail.com is one of those domains, which is why you'll
receive this via our secondary outbound/SMTP mail server.)

The third blacklist (Polspam) is a Polish blacklist. It's a bit more
complicated to determine why we're on that list, but my *educated* (I
emphasise) guess is that we're on it for the exact same reason we're on
the other two blacklists, because all of our data centre's IP addresses
are blacklisted.

Have you asked Afrihost why they are on at least six blacklists and
what they're doing about it? I believe the answer to that question is
"no", and even if you asked you will *not* get an answer, or you will
be told in relatively polite terms that you don't know anything about
email and that they are perfect and NinerNet is the problem ... the
aforementioned BS. This is similar to the issue with another South
African ISP, which we have documented exhaustively at:

status.niner.net/2024/01/19/email-messages-from-xneelo-formerly-hetzner-south-africa-senders-blocked

We don't get into these arguments with non-South African ISPs and mail
service providers, so I'm forced to come to the conclusion that South
African's don't give a damn.

Definitions:

* Blacklist (also "blocklist" for those that want to be politically
correct): A list of servers -- usually based on their IP addresses, not
domains -- that have sent spam or malware in the recent past. The full
definition is broader than that (as I've partially explained above) but
if you want a longer explanation than this already long email I suggest
you use an Internet search engine I refer to below. Blacklists exist to
remove servers from the email system that have shown problematic
behaviour in the *recent* past so that legitimate receiving mail
servers -- such as NinerNet's -- don't have to process "junk" email,
and legitimate email receivers -- such as you -- don't have to read and
process junk email.

* BS: This is about as profane as I will get in communications with a
client, although in situations like this it's getting more and more
difficult not to turn the air blue. It's an adjective, a noun, a verb
and probably various other parts of speech. If you're unclear on the
meaning, that's what Internet search engines are for.

* SMTP: Simple Mail Transfer Protocol. This protocol is how mail
servers communicate with one another, and the term "SMTP" is also used
as an adjective.

* Various other colour lists: They exist, but neither Afrihost's
domains nor IP addresses are in any, so I won't get into what they are
and are not.

I took a look at [YOUR WEBSITE]. I note that
(assuming that's you) you're involved in "Compliance & Business
Solutions", and that, "[You] believe that great businesses are built on
strong systems, clear strategy, and full compliance." Email is all
about "compliance" with "standards" which, as benign as that word
sounds, are actually the non-negotiable "rules" that have to be
followed to get an email message from point A to point B. Afrihost have
made all sorts of claims in the email you forwarded to me, but they
have not told you how you can check on those claims. On the other hand,
NinerNet has shown you all the third-party evidence that backs up the
claims I've made.

I will address some of the things they have said:

* "We’ve confirmed that the messages from [YOUR EXTERNALLY HOSTED EMAIL
ADDRESS] are successfully sent and accepted by the outbound mail relay
(smtp.ucebox.co.za) with a 250 OK response, indicating successful handoff.":

* While I'm willing to accept that someone has made a mistake in their
rush to get to the next complaint from one of their customers and I
don't want to be pedantic, an "outbound mail relay" does not "accept"
email messages (as far as this issue is concerned), it offers/sends
them. The "250 OK response" is what they see in the logs on their mail
server, but since they didn't actually provide the specific lines of
the logs (with dates and times) NinerNet has absolutely no way of
correlating their claims against the corresponding lines in the logs of
our mail server. This is how auditing works, as you would very well
know from the list of qualifications on your website.

* "Additionally, the same emails are being successfully delivered to
[HOTMAIL ADDRESS], which confirms there’s no issue on our end
with sending or authentication (SPF, DKIM, and DMARC all pass":

* Again, NinerNet is not Hotmail and doesn't know how Hotmail servers
work. It does *not* confirm *anything* other than the fact that Hotmail
and NinerNet handle email from blacklisted IP addresses differently. And
they didn't tell you how to confirm that their claims that their "SPF,
DKIM, and DMARC" all pass. I took a quick look at some of their public
DNS records -- did I mention how many hours I've already spent on this
reply? -- and at least one of them are broken. It's not a significant
one, but if they can't get one of them right how and why should I or
you assume that they got the rest of them right?!

* "You may check if there is [sic] any server-side filters or rules
that might be rejecting, flagging, or silently discarding these
messages. if not, you may whitelist the domain at the [YOUR DOMAIN]
side and check again.":

* This is a good idea. I have checked whatever blacklists you might
have in place through the control panel on the mail server and you
don't seem to be blocking anything relevant, but you will have to log
into the webmail to see if there are any filters in place there that
could be causing a problem. I have looked for ucebox.co.za and the IP
addresses that smtp.ucebox.co.za uses in our server-wide blacklists,
and they are not there. That means that if email from their servers to
our server are bouncing -- that hasn't explicitly been stated -- then
they're bouncing because of the blacklists their servers are in. This
means that the blacklists are working as intended and as advertised,
which I consider to be a good thing.

While in the control panel I had a look at the logs of email you've
received at [YOUR DOMAIN], and I note four recent email messages
successfully received from [YOUR EXTERNALLY HOSTED EMAIL ADDRESS]:

* RE: Bank confirmation letter, Lease agreement and Invoices.
* 2025-07-26 11:44:09 CAT

* TEST
* 2025-07-27 12:23:03 CAT

* Last Test
* 2025-07-27 12:23:15 CAT

* test new
* 2025-07-27 17:08:37 CAT

Those were all successfully received, which makes me wonder why I have
spent six hours writing this email. For that reason I will end this
message here and claim, like Afrihost, that there is no problem.

Craig

On Sun, 2025-07-27 at 15:07 +0000, [NINERNET CLIENT] wrote:
> Hi Craig,
>
> Trust you are well? Please see below emails and my back-and-forth
> exchange with Afrihost. None of my emails from my [EXTERNALLY HOSTED DOMAIN]
> domain is being received by our [NINERNET-HOSTED DOMAIN]. are you able to check
> into it please?
>
> Thanks and Regards,
>
> [NINERNET CLIENT]
> [PHONE NUMBER]
>
>
>
> From: Afrihost <hosting@afrihost.com>
> Sent: 27 July 2025 16:59
> To: [NINERNET AND AFRIHOST CLIENT]
> Subject: [#PXQ-982-73116]: blocked emails
>
> Hello there.
>
> Following up on the issue regarding non-delivery of emails to
> [NINERNET CLIENT]:
>
> We’ve confirmed that the messages from [AFRIHOST-HOSTED EMAIL ADDRESS]
> are successfully sent and accepted by the outbound mail relay
> (smtp.ucebox.co.za) with a 250 OK response, indicating successful
> handoff.
>
> Additionally, the same emails are being successfully delivered to
> [CLIENT'S HOTMAIL ADDRESS], which confirms there’s no issue on our end
> with sending or authentication (SPF, DKIM, and DMARC all pass
>
> You may check if there is any server-side filters or rules that might
> be rejecting, flagging, or silently discarding these messages. if not
> , you may whitelist the domain at the [CLIENT'S DOMAIN] side and check
> again.
>
> Regards,
> Sreehari RS
> Check out some of our hosting tutorials by going to the following
> link:
> https://answers.afrihost.com/video-hosting

--
NinerNet Communications | Craig Hartnett
* https://www.niner.net | [EMAIL ADDRESS]
Phone: +1 604 630 1772 | +260 96 209 8871 | 1 855 NINERNET

We do not have these discussions with our clients about ISPs and mail service providers in Europe, North America, South America, Asia or Oceania. Incompetence seems to be concentrated in South Africa.

Our new rates

16 February 2025 22:43:33 +0000

We sent the following information to our existing clients on 14 February 2025:

As we advised on 29 November 2024, we have a new retail rate system. These rates are already in effect for new clients, and they go into effect today for existing clients. Invoices issued this month will use the new rates.

Our rates page will be updated next week, but here is a summary of the changes:

  • Web hosting: Hosting a website will now cost only US$10/C$15 per month, down from up to US$40 per month. (More on exchange rates in a moment, especially for you Canadians.) As we said in November, this will cover websites of all sizes that we currently host. If a company with a website the size and complexity required by the likes of Google or Microsoft shows up, this will not apply, and we will quote on their specific needs. Aliasing additional domains to the same website will be done at no additional charge.
  • DNS/nameserver hosting: NinerNet will provide DNS hosting for US$20/C$30 per year per domain, which is the same as our current rate. Almost all of our clients have only one domain. If a client has two domains (for example) aliased to the same email and/or web hosting we will offer significant discounts. So if someone has example.com and example.net pointing to the same website and/or the same email accounts, they will not both be US$20 but the second will be discounted.
  • Email hosting: We will no longer offer “bundles” of email accounts: if you want one email account, you will pay for one email account; if you want a thousand email accounts, you will pay for a thousand. No longer do you have to upgrade to the next package if you want to go from five email accounts to six. Email accounts will be US$4/C$6 each per month and will include 25 GB of disk space — room for about 3.6 million average-sized email messages that don’t contain any attachments like cat videos. 🙂 Of course, some of your emails will contain cat videos, not to mention product catalogues, company videos, etc. That’s OK!; you’re allowed to send and receive those. For managing the amount of space you use on the server we have long recommended an archiving scheme. If you choose not to use an archiving scheme like that, that’s OK, you’re allowed to do that too, and when your email account grows to exceed the 25 GB we include, then we’ll start invoicing you for the additional space you need at the same rate of US$5/C$7.50 per 100 MB per month in 100 MB increments. You can use the mail server control panel to determine how much space each of your email accounts are using.

Other things you should know:

  • Currency exchange rates: Our rates are based on the US dollar. This is because, as you know, international commerce is largely based on that currency, and American companies have largely cornered the market on providing top-of-the line IT services like data centres. (Largely, not totally.) For currencies like the Canadian dollar the exchange rate has generally remained fairly stable; for the Zambian kwacha this has not been the case, and we revised our kwacha rates quarterly, sometimes putting prices up, sometimes taking them down. Zambians are used to this but Canadians are not. However, due to the unpredictable economic landscape between the US and Canada these days (bad timing on our part!), the value of the Canadian dollar in US dollars has taken a dive. This has resulted in our Canadian-dollar rates increasing. Our current exchange rate of 1.5 will not remain that way for years though, as we’ll keep an eye on it and adjust it if necessary, but likely not more than once a year. When we start to accept payment in kwachas again, we’ll likely go back to quarterly revisions, while the US dollar rates on which other currencies’ rates are calculated will remain the same barring any major changes.
  • Do I need to pay something different even if my hosting is not expiring for a few months?: No, if you have already paid for hosting and have an expiry date in the future, your rates and your hosting will not change until your next invoice.
  • Can I continue to be invoiced annually?: This will likely depend on the nature of your account. For many clients you will continue to be invoiced annually if you had previously chosen to be. If you have managed your account in a more fluid fashion, changing the quotas of your email accounts with some regularity and adding and removing accounts more often, then you will likely be invoiced quarterly. This will actually affect very few clients, but it will affect some.
  • Will the disk quotas of individual accounts be managed and charged for separately?: No, entire domains will be assigned a disk space quota based on the number of email accounts they need. So if a client needs 10 email accounts, their domain will be assigned a quota of 250 GB (10 x 25 GB). If you want to assign a small quota of 10 GB to one account and a quota of 50 GB to another, you can. This would mean one or more accounts could use more disk space than other accounts and not incur greater charges.

We look forward a new rate system that more fairly charges based on actual usage, and doesn’t railroad clients into accepting bigger packages just because they need one more email account. We emphasise once again that most clients will not see their total invoices change, and some will even see their charges decrease. We remain open to any feedback on the new system. Thank-you.

Microsoft issue update, and our invoices are very late this month

30 June 2024 23:58:21 +0000

Due to a number of factors this month, our invoices are about as late as they have ever been, for those of you who are being invoiced this month.

As is often the case when things don’t go right, there wasn’t any single factor that caused this; it was the result of a number of factors, not the least of which was the considerable amount of time we spent dealing with the block of our mail server implemented by Microsoft. You know how important working email is to you, and it is not lost on us how important email is to you and therefore our business. So we literally dropped almost everything (including this month’s invoicing!) to deal with and mitigate the problem caused by Microsoft. In fact, on 28 June (Friday) we updated our blog post about this at:

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

You’ll find the update at the bottom of the post with Friday’s date on it in bold. The situation now is essentially that we are back to where we were before Microsoft started bouncing mail to domains they host on 20 June; in other words, to use the term used by some of you, the situation is “resolved”, and we’re back to dealing with individual bounces as necessary. Email bounces sometimes; it’s a fact of life. It’s the email system’s feedback loop to ensure that you know what has happened to an email you send if it wasn’t delivered as you expect. No news is generally good news, as that means your message was delivered, and now you’re waiting for the human on the other end to reply.

Also in the last two weeks we’ve had to address situations with two clients that were expecting different outcomes on issues they had brought to our attention; one of them has been dealt with as far as we can at this point, and the other will be dealt with right after our invoices go out shortly. We apologise to both clients who had to deal with the fact that we couldn’t give them as much attention as quickly as we usually do when clients need us. As of a couple of hours from now, everything will be back to normal, and we thank those clients and all of you expecting invoices on 15 June for your patience.

The date on our invoices will be 28 June (the most recent business day this month), and the suggested pay-by date is 19 July. However, if you are being invoiced this month please pay close attention to the expiry dates of your services and/or domains, as if they are before 19 July you do either need to pay your invoice before the earliest expiry date noted on your invoice, or contact us to make arrangements to ensure that we are aware that you will pay your invoice so that we renew your domains or services so that they stay online. Those of you who are again scheduled to be invoiced on 15 July will see your June balance carried forward, if you haven’t paid your June invoice yet, but since we don’t charge interest on unpaid balances this will not negatively affect anyone.

We apologise for making you do so much reading lately, and I can assure you that we work very hard to ensure that our systems run as close to 100%, 100% of the time as possible. We’ll never reach 100%, 100% of the time — nobody does, even Microsoft and Gmail — but the closer we can come to that goal, the easier your life is and the easier our life is.

Thank-you, as always, for your patience during troubling times. If you have any questions or feedback, please do contact NinerNet support.

Adventures in blocking spam

7 May 2024 06:42:30 +0000

As we’ve said outright and intimated over the years, the battle against spam is never-ending.

One thing we have noticed in the last year or so is that a huge amount of spam comes from certain TLDs (top-level domains), but blocking entire TLDs is a bit radical. We have generally avoided doing so, but the time has come to block the following two alternative TLDs:

  • sa.com, and
  • za.com

These are simply two regular domains, but they are owned by CentralNIC (now “Team Internet” because they can’t make up their minds about how they want to be known) who market them as TLDs — just as NinerNet markets the zam.co domain as an alternative TLD (actually, SLD, second-level domain) for Zambia. Therefore, you can buy the sub-domain your-name.sa.com and your-name.za.com. CentralNIC doesn’t seem to make even a cursory attempt to stop spammers from using their domains to spam, so we now block all messages sent from all addresses on those two “pseudo” TLDs — e.g., spammer1@spammer1.sa.com and spammer2@spammer2.za.com. We’re considering blocking the .top TLD as well, for the same reason, but we haven’t yet. You can certainly block entire TLDs from reaching your email addresses as well, if you feel this rather extreme move will benefit your domain.

If you happen to correspond with a legitimate correspondent on one of those alternative TLDs, please contact NinerNet support and we will work with you to address the problem you will now have communicating with them.

Thanks for your attention to this matter.

Email DNS settings

28 February 2024 06:27:08 +0000

A little earlier this month several of our clients with websites contacted us as a result of being sent an email message by their website designer/manager with the subject, “Updating sending DNS for newsletters”. This is as a result of the fact that Yahoo and Gmail recently decided to start enforcing email rules that the rest of us have been following for many years, but since those two providers have a huge share of the market, when they sneeze the rest of us catch a cold.

The fact is that all domains we host are already configured to follow all the rules to ensure that your messages are securely received by destination mail servers, so you and we are already in compliance with the rules that Gmail and Yahoo have just finally woken up to.

The only difference of which some of our clients need to be aware comes up when they’re using a mass-email provider to send out mass emails. As we have long advised, even though that particular post is from only last year, we strongly suggest that mass emails be sent using a service provider that specialises in that service; NinerNet does not. Yes, we have an option in our mail server’s control panel to create mailing lists, but doing so is inadvisable unless you’re just creating a very small list of your own employees, or maybe a few of your customers … with “few” in this case being defined as only a few dozen, definitely fewer than 100. If you have more than one hundred, which we certainly hope you do, then please use a company like Mailchimp. (They’re just one example; we don’t have any sort of deal with them.) Getting many emails out to many recipients successfully is not for the faint of heart; it’s a time-consuming process involving staying on top of all of the rules to avoid spam filters that enforce those rules and deem messages as spam if they are not following all the rules. And it’s especially time-consuming to prevent spam from being sent out using those services!

To follow the instructions that your mass-email provider provides you will need to log into and check the DNS settings for your domain in the nameserver control panel, and either add the records they suggest or modify the ones that already exist. For example, your domain already has an SPF record, so you will need to modify the existing record while keeping the information that the existing record already contains. If the instructions you’re following don’t make it clear how to do that, please contact NinerNet support and we will assist you.

Thanks.

NinerNet home page

Subscriptions:

RSS icon. RSS

General Information:

This is the corporate blog of NinerNet Communications. It's where we post announcements, inform and educate our clients, and discuss issues related to the Internet (web and email) hosting business and all it entails. This includes concomitant industries and activities such as domain registration, SSL/TLS certificates, online back-up, virtual private servers (VPS), cloud hosting, etc. Please visit our main website for more information about us.

Search:

 

Recent Posts:

Archives:

Categories:

Tags:

accounts receivable apple billing branding cira contact information domain registration domain registry of canada domain renewals domains domain sales dot-ca domains dot-zm domains down time droc email encryption facebook google happy hosting customers hosting transfer icann invoices iphone kwacha maintenance paying your bill paying your invoice quarterly kwacha rate review rates registrar transfers reputation scams search engine optimisation search engine optimization security seo service hours spam ssl ssl/tls support transparency wordpress zamnet

Resources:

On NinerNet: