We have made some adjustments to the configuration of the mail server on NC027 and as a result the mail queue seems to be clearing, albeit very slowly. We’re continuing to work on this to speed up delivery.
We have made some adjustments to the configuration of the mail server on NC027 and as a result the mail queue seems to be clearing, albeit very slowly. We’re continuing to work on this to speed up delivery.
Server NC027 has a large and growing mail queue, but the server is up. We are investigating and will post updates here.
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: 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.
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!
A few things have become apparent over the last few days, and noting them here might help others who may still be having issues:
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.
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.
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.
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:
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.
The migration has completed. After midnight UTC we will perform the sweep mentioned earlier, and then disable migrated domains on the old server.
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.
Systems at a Glance:
Loc. | System | Status | Ping |
---|---|---|---|
NC023 | Internal | Up? | |
NC028 | Internal | Up? | |
NC031 | Internal | Up? | |
NC033 | Operational | Up? | |
NC034 | Internal | Up? | |
NC035 | Operational | Up? | |
NC036 | Operational | Up? | |
NC040 | Internal | Up? | |
NC041 | Operational | Up? | |
NC042 | Operational | Up? |
Subscriptions:
Search:
Recent Posts:
Archives:
Categories:
Links
Tags:
Resources:
On NinerNet: