NinerNet Communications™
System Status

Server and System Status

Email migration: Update 1

21 August 2015 21:58:35 +0000

Following are the details of the email migration of some clients this weekend. This is a long post, but we’ve broken it down and bolded key points for quicker scanning. You can use your web browser’s “find” feature to look for key words that might help you locate information about any issues you may encounter.

  • WHO: If this migration affects you, you will have received an email about it on 14 August. All remaining email domains hosted on server NC018 are being migrated to server NC027.
  • WHAT: Migration of the remaining email accounts on server NC018 to server NC027.
  • WHERE: In cyberspace, of course.
  • WHEN: The migration will start at 19:00 UTC on Saturday, 22 August. Please check the World Time Server for a conversion to your time zone. We do not have a precise estimate for the duration of the migration, but it will be several hours. During that time email will continue to be delivered, either to the accounts on the old server (NC018) before being transferred to the new server, or to the accounts on the new server (NC027). Updates will continue to be posted here throughout the migration.
  • WHY: Server NC018 has outlived its useful life and needs to be replaced. The new server is an improvement over the old server in every respect.

Things you need to do:

Change the configuration of your email program after 19:00 UTC on 22 August. (Please check the World Time Server for a conversion to your time zone.) Here are links to illustrated guides to configure the most common email programs in use:

(Our thanks to “The Lowdown” / African VSAT Systems for these guides.)

Here is a summary of the main configuration items that need to be changed:

  • Use port 587 for outgoing (SMTP) mail.
  • Use TLS (or SSL if TLS is not present in your email program) for all incoming and outgoing mail.
  • Use SMTP authentication for outgoing mail.
  • Make sure you’re using a sub-domain of the niner.net domain for mail server names:
    • mail27.niner.net for incoming (POP or IMAP) email, and
    • smtp27.niner.net for outgoing (SMTP) email.

And here are the actual settings that we provide to new clients on server NC027:

  • Email address: you@yourdomain.com
  • User name: you@yourdomain.com
  • Password: The correct password on your email account. In the future, if you want to change your password, you can do so through the control panel (administrators only) or through the webmail.
  • Password type: Plain
  • Incoming (POP/IMAP) mail server: mail27.niner.net
  • Incoming mail server port: 995 (POP) or 993 (IMAP)
  • Outgoing (SMTP) mail server: smtp27.niner.net
  • Outgoing mail server port: 587
  • Authentication: Turned on for SMTP
  • Encrypted connection: TLS (if it’s an option in your email program) or SSL (if TLS is not shown as an option). If TLS doesn’t work, please try SSL.

All of the above settings are important and required. None are optional. Your password has not changed from what it was on the old server, so if you’re not sure that you remember your password, please don’t edit it in your email program.

Using the above settings you can configure any email program on any computer, phone or tablet, even ones for which we have not provided unique instructions.

In our experience, 99% of problems clients experience with email are mis-configurations. If you run into a problem, please take a deep breath, then double- and triple-check your configuration — spelling, check/tick boxes, and various other parameters — to be 100% sure that everything is set EXACTLY correctly. When configuring email settings, there is no such thing as “close enough”. All of the settings are there for a reason and need to be set exactly as they are shown in the configuration instructions — with the one exception where some email programs work with TLS set and some with SSL set. Rebooting can work wonders … seriously. When reporting problems to support, please ensure you send us the exact text of any error messages you are seeing. We cannot help you if you just tell us that “it doesn’t work,” as our first response will be to ask you for the exact text of any error messages you see and we could have had that on the first message.

Here are a few additional notes:

  • Mailing lists: Domains with Mailman mailing lists will not be migrated this weekend, but they will in the very near future. Domains with custom mailing lists will be migrated this weekend.
  • Letter case: All email accounts will be set up in lower-case letters. This doesn’t make a difference from an email point of view (messages addressed to BOB@EXAMPLE.COM and bob@example.com will be delivered to the same account), but it does make a difference when trying to log in. If, for example, you set up your account on server NC018 as Bob@example.com, it will be set up as bob@example.com on server NC027. If you try to log in as Bob@example.com, your attempt will fail, so please log in as bob@example.com.
  • Accounts over quota: The contents of accounts that are already over quota on server NC018 will not be transferred.
  • Address books, calendars, notes, etc.: If you have any of these stored in the webmail on server NC018, these will not be transferred. Please ensure that you have local copies of this data to upload to the new server.
  • Changes on server NC018: Please do not add, remove or change any email accounts to, from or on server NC018 after 00:01 (12:01 am) UTC on Saturday, 22 August. (World Time Server.) Any such changes may not be reflected on server NC027.
  • Control panel log-in details: Following the completion of the migration, account contacts will be sent log-in information for the control panel on server NC027.

Based on experience from previous migrations, here are some issues we expect that some clients will experience:

  • Multiple copies of old messages: This has been reported by some users of Outlook. This is an Outlook issue over which we have no control, and it should eventually clear up.
  • Company contacts: If you are not our contact for your company, please deal with the person who is our contact, and we will assist them. If they are unable to help you, they will refer us to you.
  • MTN business customers: Some (not all) MTN business customers have a unique SMTP set-up that requires they use MTN settings for outgoing email, and you may not be able to use our server to send email. If you are an MTN business customer, this may apply to you if you already have an MTN IP address in the outgoing (SMTP) server field in your email program’s settings. If that is the case, it’s probably best to leave your SMTP settings as they are. However, the incoming (POP/IMAP) server settings need to be exactly as described in our configuration documentation (linked to above).
  • iPhone: It seems that the iPhone does not turn on SSL/TLS by default, so you have to go out of your way to find this under “advanced” settings and turn it on. Please also ensure that the port is set correctly for incoming mail: 993 for IMAPS (IMAP over SSL/TLS).
  • Android: Contrary to the iPhone, we’ve had a report from a client using an Android-based phone that port 993 did not work, but 143 did. Try port 993 first if you’re using IMAP, but then try port 143 if port 993 doesn’t work.
  • Eudora: The “Secure Sockets when Sending” field on the “Generic Properties” tab needs to be set to “Required, STARTTLS”, and the “Secure Sockets when Receiving” field on the “Incoming Mail” tab needs to be set to “Required, Alternate Port”.
  • Firewalls: We spent a significant amount of time dealing with a firewall issue with one client, after being assured that the firewall had been opened by the network management company managing their firewall. It turned out that the firewall was not open, or at least not sufficiently for the type of connection that was required. After it was properly configured, email miraculously flowed with no problem. Please check your firewalls!
  • Email-sending applications: Another fairly unique situation was encountered with a client who uses a “localhost” web and mail server installed on their computer to run a reservations system. This was unable to connect to the mail server, and the vendor of the software was also unable to determine the problem with their software.
  • Bouncing email: If some people tell you that their email to you is bouncing, and the bounce message reads as follows — “REJECT ACCESS DENIED. Your email was rejected because the sending mail server does not identify itself correctly. (.local)” — then their mail server (probably Microsoft Exchange) is incorrectly configured. Please send them a link to Email migration: Update 13 and ask them to forward that link to their system administrator for resolution of the issue.
  • Outlook 2003: Outlook 2003 does not support TLS. This is software that is over a decade old, and Microsoft stopped supporting it in 2014. Now would be a good time to upgrade … seriously. However, apparently a 2004 “hotfix” available from Microsoft will add TLS support to Outlook 2003, but we cannot vouch for this personally, nor are we aware of any clients who have used this.

As always, please contact NinerNet support if you have any questions, concerns or problems. Thank-you for your patience as we move your email accounts to a newer, faster, more secure server.

Migration of remaining email accounts on server NC018

14 August 2015 14:20:09 +0000

Over the weekend of 22-23 August 2015 we will be migrating all email accounts still on server NC018 to server NC027. Server NC027 has been our “new” mail server for the last two years, and all new domains have been hosted on it since it was set up in 2013. Server NC018 has outlived its useful life and needs to be replaced. The new server is an improvement over the old server in every respect.

We will be posting additional details here over the next week before the migration. However, you should be aware of the following initial details:

  • From the start of the migration, which we anticipate will take several hours, existing email accounts on server NC018 will no longer be accessible.
  • All new incoming email will be directed to the new server. Accounts on the old server will no longer be accessible after the start of the migration.
  • No incoming email will be lost during the migration, although it may be delayed briefly.
  • We will attempt to migrate the contents of mail boxes to the new server, with the exception of any accounts that are already over quota. However, we strongly recommend that you use your email program to create “local” folders (i.e., folders on your own computer) and drag and drop any messages stored on the server into your local folders, from where you can easily create back-ups.
  • As has always been our webmail policy, any data stored in the webmail other than email will not be migrated. This includes address books, notes, calendars and any other features of the Horde suite that you may be using. Please ensure that you save on your own computer copies of any data you have saved in the webmail application.
  • Except in rare cases, passwords will remain the same. However, there will be a requirement to make a small change to the configuration of your email program for sending email. We will be providing those details.
  • If you are downloading your email using POP, there will be no changes required for your incoming settings. If you are using IMAP, you may need to adjust your setting for folder structure. We will provide details if necessary closer to the migration date.
  • We ask that you do not make any changes through the control panel to email accounts as of the close of business on Friday 21 August. If you do, those changes — e.g., the addition or removal of email accounts or password changes — may not be reflected on the new server.

If you have any questions, please reply to the email you will receive from us with details. Thanks for your patience as we work to improve the service that we provide to you.

Email migration: Update 14

29 October 2013 08:57:36 +0000

This is the last post that we’ll refer to as an “update” regarding the email migration that was largely completed three weeks ago … if only so that we don’t end on number 13. It addresses three issues:

  • Outlook 2003,
  • Anti-spam blacklists, and
  • Mail box quotas.

Outlook 2003: During the migration we learnt that Outlook 2003 does not support TLS. This is software that is over a decade old, and Microsoft will stop supporting it in less than six months. Now would be a good time to upgrade. However, apparently a 2004 “hotfix” available from Microsoft will add TLS support to Outlook 2003, but we cannot vouch for this personally, nor are we aware of any clients who have used this.

The anti-spam blacklists used on the old server were not immediately implemented on the new server. They have been now. The amount of spam you receive should drop significantly as a result.

Finally, we have increased mail box quotas across the board, as we try to keep up with the growing number of people using smart phones and tablets who store significant amounts of mail on the server.

As always, if you have any questions, please contact support and we’ll be happy to assist.

Email migration: Update 13

16 October 2013 10:09:43 +0000

Since the migration of many email accounts to the new server, we’ve had reports of email from some regular correspondents (with email hosted outside of NinerNet) to domains hosted on the new server bouncing back to those senders as undeliverable. All of these reports, so far, are about the same improper configuration of Microsoft Exchange mail servers.

A person sending you an email through a mis-configured mail server will receive a bounce message that includes an explanation for the bounce that looks like this:

you@yourdomain.com
nc027.ninernet.net #554 5.7.1 <senderdomain.local>: Helo command rejected: Go away, bad guy (.local).

The problem is the “senderdomain.local” string. In this case “senderdomain” stands in for an actual name — e.g., something that looks like it might be a domain — followed by “.local”. A properly configured mail server that connects to the public Internet is supposed to advertise a “fully-qualified domain name” (FQDN) through the “HELO” (or “EHLO”) command rather than “something.local”, which is not a real domain. Many mail servers, including ours, reject attempts to deliver mail from improperly configured mail servers advertising a “domain” that does not (or cannot) exist. The reason for this is that much spam comes from machines that are improperly configured in this manner. More technical details about this can be read in the Best Practises for Email and Network Operators – Valid HELO domain article.

Your correspondents will likely think that we are blocking their domain specifically (very likely that we are NOT) or that something is otherwise wrong on our mail server. However, it is the other way around; your correspondents experiencing this problem need to talk to their own IT people, perhaps pointing them to this post, as their mail server needs to be reconfigured correctly.

The article Exchange DNS Configuration for Email Delivery includes a number of helpful hints for the Exchange server administrator about how to properly configure an Exchange server to work correctly on the Internet with respect to domains and DNS. About half way down the page are sections entitled SMTP Banner – Exchange 2003 and SMTP Banner – Exchange 2007 that explain how to set the SMTP banner — i.e., the domain that is advertised by the Exchange server when it connects to another mail server to attempt to deliver email. As mentioned previously, this needs to be a proper domain that is resolvable on the Internet, not something that doesn’t exist like “senderdomain.local”.

Our experience is that when an Exchange server is correctly reconfigured, email from that server starts getting through again immediately, and deliveries to other servers that do not block based on this incorrect behaviour are not affected.

Another possible solution to this problem is for the Exchange server to use a smart host, through which all outbound email is delivered to the public Internet. This has a number of advantages, including not having to reconfigure the SMTP banner and the fact that the server administrator doesn’t have to be concerned about their own IP address being added to a block list if (again as a result of mis-configuration) the server inadvertently becomes the source of spam. NinerNet provides this service (relay server / smart host) for USD30 / CAD36 / ZMW165 per month.

Or you could send Microsoft Exchange Server 2007 For Dummies to the sending domain’s server administrator!


Update, 2022-01-24: The information above applies to any domain or sub-domain used in a mail server’s HELO command, not just the specific nonsense sub-domain “senderdomain.local”. If the maintainer of the sending mail server makes up a sub-domain like “mailserver.mydomain.com”, but doesn’t actually create an A record for “mailserver.mydomain.com”, then the effect will be the same, their email will not get through.

Additionally, these days the error message is different. It is as follows:

450 4.7.1 <mailserver.mydomain.com>: Helo command rejected: Host not found

Mail server admins are still making this mistake today, in 2022!

Email migration: Update 12

10 October 2013 12:41:09 +0000

A few things have become apparent over the last few days, and noting them here might help others who may still be having issues:

  • Outlook: First, we did correct the Outlook instructions on Monday to state that the encryption setting for sending needed to be set to TLS, not SSL. Some people missed that, and it has accounted for the majority of problems with sending email via Outlook.
  • Almost all of the rest of the problems were caused by one or two missed settings or spelling mistakes. We can’t overstress that the settings we have provided need to be set exactly. When configuring email settings, there is no such thing as “close enough”.
  • Eudora: The “Secure Sockets when Sending” field on the “Generic Properties” tab needs to be set to “Required, STARTTLS”, and the “Secure Sockets when Receiving” field on the “Incoming Mail” tab needs to be set to “Required, Alternate Port”.
  • Blackberry: One client was unable to configure their older Blackberry (the operating system on which can’t be upgraded any further past OS5) — even with assistance from their phone company — and ended up buying a new phone and having no problems.
  • iPhone: It seems that the iPhone does not turn on SSL by default, so you have to go out of your way to find this under “advanced” settings and turn it on. Please also ensure that the port is set correctly for incoming mail: 993 for IMAPS (IMAP over SSL).
  • Android: Contrary to the iPhone, we’ve had a report from a client using an Android-based phone that port 993 did not work, but 143 did.
  • Firewalls: We spent a significant amount of time dealing with a firewall issue with one client, after being assured that the firewall had been opened by the network management company managing their firewall. It turned out that the firewall was not open, or at least not sufficiently for the type of connection that was required. After it was properly configured, email miraculously flowed with no problem. Please check your firewalls!
  • Email-sending applications: Another fairly unique situation was encountered with a client who uses a “localhost” web and mail server installed on their computer to run a reservations system. This was unable to connect to the mail server, and the vendor of the software was also unable to determine the problem with their software. We had to provide a workaround for the client in this situation.

If you’re still having issues with sending or receiving email, please double and triple check everything, check the above notes for anything that may apply to you and help you get things working, and then contact us if none of that helps.

Thanks for your patience. As frustrating as this migration has been for some of you due to the exactness of the settings required, your mail is on a better, faster, more secure server that is much closer to many of you than the old server was.

Email migration: Update 11

8 October 2013 10:34:09 +0000

After talking with a client who is a customer of MTN in Zambia, it appears there may be some MTN customers with a unique SMTP set-up that requires them to use MTN settings, not ours. This client was unable to use our settings for SMTP, and had to use an MTN IP address for the outgoing server, with port 25 and no authentication or SSL.

If you’re an MTN customer, this may apply to you if you already have an MTN IP address in the outgoing (SMTP) server field in your email’s settings. If that is the case, it’s probably best to leave your SMTP settings as they are. However, the incoming (POP) server settings need to be as described in our configuration documentation.

Just because you are an MTN customer does not necessarily mean that this applies to you, but it’s something to keep in mind if you are.

Email migration: Update 10

8 October 2013 06:18:09 +0000

The aforementioned sweep of all migrated email accounts on the old server has been completed, and all mail accounts on the old server have been deactivated.

If you are having problems sending email, please double and triple check your email configuration against the instructions you’ve been given. We’ll be making phone calls today to check with clients individually to ensure that everything is working.

Email migration: Update 9

7 October 2013 18:52:22 +0000

Please ensure that you correctly follow the instructions you have received for configuring your email program. All problems we have encountered so far are all related to missing a tick, setting the wrong encryption method, spelling mistakes, etc. These are the correct settings:

  • User name: you@yourdomain.com
  • Password: Your Password
  • Password type: Plain
  • Incoming (POP) mail server: pop27.niner.net
  • Incoming mail server port: 995
  • Outgoing (SMTP) mail server: smtp27.niner.net
  • Outgoing mail server port: 587
  • Authentication: Turned on for SMTP
  • Encrypted connection: TLS (if it’s an option in your email program) or SSL (if TLS is not shown as an option)

All of the above settings are important and required. None are optional. Your password has not changed, so if you’re not sure that you remember your password, please don’t edit it in your email program.

Using the above settings you can configure any email program on any computer, phone or tablet, even ones for which we have not provided unique instructions.

However, if you are having problems, please contact us. We are happy to help.

Please also note that the settings for the old server will stop working early in the morning of Tuesday, 8 October, UTC, so please do your best to get the new settings working today.

Email migration: Update 8

7 October 2013 18:20:24 +0000

The migration has completed. After midnight UTC we will perform the sweep mentioned earlier, and then disable migrated domains on the old server.

Email migration: Update 7

7 October 2013 10:53:23 +0000

One more note, in case it wasn’t made clear earlier. All new email to migrating and migrated domains is being delivered to your accounts on the new server, unless it is sent by someone using the old server. This means that email from contacts not hosted with NinerNet will arrive in your account on the new server. However, email from clients still hosted on the old server — and from people on migrating/migrated domains who are still using old email settings to send email — is being delivered to the accounts on the old server. Avoiding this overlap is why we had hoped to complete this migration on the weekend, but it will be rectified by the sweep we will make at the end of the day today.

As always, we’re here to help if any of this is confusing. Please contact support if you have questions.

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), SHUT DOWN.NC036Shut downUp?
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: