NinerNet Communications™
Blog

Corporate Blog

Spam and virus filtering on the mail server

11 October 2018 15:15:22 +0000

Over the last five months we’ve been monitoring the effectiveness of the anti-spam systems on server NC036 with a view to setting the point at which emails are considered by the system to be spam. We have slowly lowered the cut-off point from the default of 6.2 to 3.0, and have found that at 3.0 the rate of legitimate email caught in the filter rises sharply. Therefore we have now set the default, server-wide level at 3.5. At this point we’re blocking about one thousand to fifteen hundred spams a day, and anywhere from a handful to a few dozen viruses a month.

You can set a different cut-off point for spam to your domain(s) as follows:

  1. Log into the mail server control panel.
  2. Click “Domains & Accounts”.
  3. Click the domain you want to manage.
  4. Click “Spam Policy”.
  5. Enter a different number in the “Classify mail as spam when score is >=” field.
  6. Click the green “Save changes” button.

In short, the lower you set the score the more spam is caught, but the greater the likelihood of legitimate email being classified as spam. Conversely, the higher the score you set the less spam will be caught and the lower the likelihood of legitimate email being classified as spam.

You can also manage other aspects of the spam filter on this page, but we recommend that you do not. The server-wide defaults are to enable all four checks (spam, virus, bad headers and banned files) and to quarantine spam and viruses. If you want to allow any of those four classes of undesirable emails through on your domain that’s your call, but you take full responsibility for the results. The results include everything from annoyance to compromised machines, devices and accounts. NinerNet does charge for time spent recovering and cleaning up compromised accounts.

Please note that the spam and virus filters monitor both incoming and outgoing email.

We strongly recommend, now that we have finished our evaluation, that you conduct your own evaluation of the situation with undesirable email on your own domain or domains. Once logged into the mail server control panel, please navigate to System -> Quarantined Mails. There you will find spam and virus emails to and from your domain(s) for approximately the last week. As mentioned above, if you find that too many legitimate emails are being classified as spam, you have two options: 1) Increase the score at which messages are considered spam, and/or 2) Whitelist any legitimate senders or domains that consistently receive high scores. To whitelist a “sender” (a single email address) or a domain or a domain and all of its sub-domains, follow these instructions:

  1. Log into the mail server control panel.
  2. Click “Domains & Accounts”.
  3. Click the domain you want to manage.
  4. Click “White/Blacklist”.
  5. Follow the instructions on the right of the page to add records to the appropriate whitelist, incoming or outgoing.

Please note that it might be tempting to add something like @yourdomain.com to the outgoing whitelist (thereby whitelisting all addresses on your domain), but we strongly advise you not to. If you do, and a machine on your network is infected with a virus or is compromised and starts spamming, the system will follow your instructions and let it all through. Please see above about our fees for cleaning up after a mess like this. The emails will likely be blocked on the receiving server anyway, and your domain possibly blacklisted. You don’t want you domain (or our mail server) blacklisted, so not whitelisting all of your users is a defence against getting your domain (and our mail server) blacklisted.

Something else to note is that it’s fairly pointless to blacklist spammers and virus senders. If you blacklist bob@example.com because he sent a virus that the virus scanner caught, you’ll also block the legitimate email he sends once he cleans up his machine and sends you an email to apologise. Similarly, spammers rarely use the same email address or domain more than a few times, so you’ll just be filling your blacklist with a lot of crap. Of course, if a persistent spammer keeps getting through the spam filter, then go ahead and blacklist them if they’re actually using the same email address or domain.

Please monitor your quarantine on a regular basis so that you notice trends and compensate for them. With our evaluation ended we will only occasionally monitor the quarantine to make human judgement calls about letting some emails through, as we have been doing over the last five months.

It is worth noting here a couple of points. One is that no spam filter is perfect. During our evaluation we have seen spam come in that was scored less than 3.5, and so will make it through the filter now that we have settled on a cut-off of 3.5. Another is that some legitimate email from senders hosted on this server — i.e., you and your colleagues and employees — has been scored above 3.5 and so has been (or will be) quarantined instead of being delivered to the sender’s mail server. This is why you need to keep an eye on the quarantine for the domains under your account, and if necessary release legitimate emails for delivery. This is how you release emails:

  1. Log into the mail server control panel.
  2. Navigate to System -> Quarantined Mails.
  3. Select the legitimate email or emails.
  4. At the bottom of the page select “release selected” from the “Choose Action” drop-down list.
  5. Click the green “Apply” button.

The emails will then disappear from the quarantine and will be delivered to the recipients. You may also select one of the other three “release” options if you want to release the email and add the sender to your whitelist if their email is consistently being scored highly. As mentioned above, it’s generally a waste of time to select one of the blacklisting options; there’s also no need to manually delete items from the quarantine, as they are rotated out after about a week.

With respect to your own emails being marked as spam, there are some glaring spam markers that we’ve seen commonly used that you and your colleagues and employees can avoid by following these suggestions:

  • Don’t use blank subjects.
  • Don’t use ALL CAPITALS subjects. If you do, keep in mind that your method of trying to get the recipient’s attention might fail completely if your message is blocked as spam.
  • Avoid using very short subjects.
  • Avoid using “Dear xxxx” in your salutations. Email is a less formal mode of communication than letters, and opening an email with “Dear” is a classic spam marker and will give your email enough extra points that it could push it over the cut-off score, especially when combined with other spam markers listed here.
    • Update: Thanks to a client for pointing out that “Dear Bob” or “Dear Mrs. Smith” are not scored as badly as generic salutations such as “Dear sir”, “Dear madam”, “Dear investor”, “Dear home owner”, “Dear winner”, “Dear beneficiary”, “Dear friend”, “Dear you@example.com”, etc.
  • Don’t send blank emails with only an attachment.

Please note that we don’t read your email. This data is gleaned from the spam reports and the reasons that certain messages were blocked because they were classified as spam.

This spam filter is much better than what we had on the old email server, and now you have access to the information it contains and control over how it works. If you have any questions or concerns, please contact NinerNet support. Thank-you.

Configuring our servers against “POODLE”, SSL/TLS, and email security

24 October 2014 15:52:19 +0000

The maintenance to protect against the “POODLE” exploit has been finished, as we’ve noted on our status blog. While I’d like this to be a short post stating just that, like the maintenance itself, there is more to it than meets the eye.

What was anticipated to take about an hour during a scheduled weekend maintenance window ended up taking much longer as we waded through the pros and cons of configuring some or all services to disable SSL version 3. (Of course, very few people know about and can prepare for these things in advance.) First, there was some debate in information security circles about just how serious this issue was/is, how quickly it needed to be addressed, and by whom. In short, some took it more seriously than others, but there was general agreement that other issues (Heartbleed and Shellshock, for example) were much bigger. Those that didn’t feel it was that serious had their reasons, but we’re not in business to gamble with your security.

While this is a vulnerability in a protocol (SSL version 3) that is (or has been) used to secure different types of connections, the main area of concern was with HTTPS connections — i.e., web browsing. To my knowledge, the only known exploit of this protocol vulnerability uses JavaScript, and only over HTTPS connections. In other words, there is currently no known issue with using SSLv3 to secure non-HTTPS connections — e.g., email.

To that end SSLv3 will still work on some of our mail servers. How this is handled — if your email program can’t use TLS — differs between email programs, with some email clients failing silently and establishing a non-secure connection instead, and some failing completely to connect. We expect that most email programs using our existing suggested configurations will continue to work across all of our servers. However, while we have not had any reports of issues from clients, one of the reasons this took longer than anticipated was the surprising number of current or recent email clients that stopped working when we disabled SSLv3 on the mail servers. Connections by email clients configured to use SSLv3 still work on server NC018, while on NC027 they will fail silently as described above. This is related to the differing behaviour of the software running these two mail servers.

All web servers (including control panels) were configured to deny SSLv3 connections by Monday this week. Web browser developers seem to have kept up with and done a better job implementing TLS in current versions than some email client developers. As we’ve stated several times previously, Outlook 2003 should be relegated to the past, along with Microsoft Internet Explorer version 6. The latter uses only SSL (and has TLS disabled) by default. Microsoft, of all people, have actually had an active campaign to discourage the use of MSIE 6 since 2009 with their ie6countdown.com website; according to that website, only 3.3% of users worldwide are still using MSIE 6, and about three quarters of them are in China. Put it this way, using MSIE 6 today is like trying to drive a Model T Ford on modern roads among modern cars, expecting to go as fast as modern cars and to be serviced by modern mechanics. In short, using certain software today is simply a bad idea, even if it still appears to some people to work.

Another thing I’d like to address here is the difference between SSL (secure sockets layer) and TLS (transport layer security) … or, more correctly, the perceived difference. There is no difference. They are essentially the same thing. For all intents and purposes, the lay person can consider TLS version 1.0 to be SSL version 4.0. That’s not true from a technical standpoint, but as someone who deals every day with clients who just want their computers to work and are more concerned about the intricacies of their trucking business (for example), they do the same thing: encrypt your Internet connections. TLS, as the successor to SSL, is newer and better (as the “SSL version 4.0” comparison above makes clear), and you should use TLS in preference to SSL any time you have a choice.

Finally, a word about email security. It has become more and more clear to me over the years that the trend in software development is to hide things from the average user. There is a point to which this is good; after all, if you had to type in all of the commands that your email program (for example) uses to connect to the mail server to download or send your email, you might as well write a letter with a quill and ink and send it via carrier pigeon. However, if your email program is going to fail silently and send your message in the clear — i.e., over an unencrypted connection — that’s something you probably want to know about if you thought you were using an encrypted connection. But this is not something you will read about in glossy brochures extolling the virtues of this email program or that. The fact is, most people will never be aware of such an issue, and those that have the most to fear — for example, people living in or reporting on dictatorships — will only realise they have a problem when there is that ominous knock at the door that reveals their communications have been compromised.

For this reason it is not enough to rely on your email service provider — not even NinerNet Communications — to secure your communications if you are, for example, an activist in a police state or a reporter with confidential sources. No, you have to take that responsibility on yourself by encrypting the actual messages you send before you send them. How to do this is certainly beyond the scope of this post, and even if you were to do it it may not be necessary for all of your communications. But going to this extent to protect yourself in this way takes extra time and effort and may require additional software on your computer, but at the end of the day you need to determine for yourself the pros and cons in your own cost-benefit analysis.

SSL version 3 “POODLE” vulnerability

17 October 2014 05:21:12 +0000

The latest in a series of recent vulnerabilities discovered in software commonly used on servers hosting websites and email (among other services) has reared its head. “POODLE” (conveniently discovered by the clever rhymers at Google) is a catchy name for a vulnerability found in a two-decade-old cryptographic protocol used to encrypt network connections. SSL — the secure sockets layer protocol — has become a household word over the years, and those three letters are still now used by many to refer generically to secure connections, even though SSL version 3.0 (published in 1996) was superseded by TLS (transport layer security) version 1.0 fifteen years ago (in 1999).

All of this introductory information is not intended to trivialise the problem, of course, but to give some background and illustrate how it can take a long time for new standards to be adopted, and old ones to be abandoned. Often, old standards live on simply because “if it ain’t broke, don’t fix it” … and now (well, three days ago) we find that the last version of SSL — version 3.0 — is indeed “broke”.

As such we will be re-configuring all of our servers still configured to allow SSL 3.0 connections to use TLS exclusively. This will require reconfiguring and restarting web servers, FTP servers and various email services. While we anticipate the work on all servers taking about an hour, interruptions in service — if there are any — should be brief and last only a few seconds at a time as services are restarted.

Of particular interest — due to a couple of recent support requests related to our newer mail server on NC027 — is that Microsoft Outlook 2003 users will likely no longer be able to connect securely to the mail servers on NC018 and NC023 (the relay server), as Outlook 2003 does not have support for TLS. 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. It should be noted that Microsoft stopped supporting Outlook 2003 earlier this year. It is obsolete software.

It is of interest to me personally that my favourite email program of all time — Eudora — will weather this storm and continue to flourish, as it does support TLS. However, sadly, even Eudora will eventually succumb to the ravages of time and the march of technology. In fact, I strongly suspect it only supports TLS version 1.0, and I have noticed that Google actively discourages connections from old email clients such as Eudora, probably because they likely suggest using an email client that supports at least TLS version 1.1. The latest version of TLS is 1.2, already six years old itself.

So, we will be using our weekend maintenance window to perform this maintenance. However, instead of starting at the usual time, this maintenance will begin at 21:00 UTC on Saturday, 18 October and, as stated above, should take roughly one hour. Please consult our status blog for updates on this maintenance, and please contact support if you have any questions or concerns.

“Shellshock” software bug

26 September 2014 14:17:06 +0000

You may have heard in the media about the so-called Shellshock security issue that affects a software package present on most Internet servers worldwide called “bash”. All of our servers run bash; it is a very basic building block on almost all UNIX- and Linux-based servers, which run most services on the Internet that you access every day. Bash can be loosely compared to the “command line” available on Windows-based computers.

Upon checking, we determined that the version of bash running on all of our servers was vulnerable to exploits aimed at the bug. All were immediately patched, and are no longer vulnerable. We continue to monitor security bulletins from the vendors of the operating systems we use for possible further patches related to newly-discovered vulnerabilities, should they materialise.

NinerNet takes keeping our servers updated and secure seriously. If you have any questions about this in general or this bug in particular, please contact us. Thank-you.

OpenSSL “Heartbleed” bug

9 April 2014 20:36:32 +0000

You may have read or heard reports in the media about a software bug in a widely-used program called OpenSSL used to secure SSL connections with and between servers.

While our servers do use OpenSSL, we have checked all of our systems and none of them are vulnerable to this bug.

If you have any questions or concerns, please let us know by contacting support.

Connection problems for Airtel customers

30 June 2011 10:22:28 +0000

One of our Zambian clients is having some severe connectivity issues with Airtel, and two other clients have reported similar issues. The problem is that, while connected to the Internet, the IP address assigned to the customer’s phone keeps changing every few seconds. This wreaks havoc with any systems that the Airtel customer is trying to connect to that require, for security reasons, that the phone’s IP address remain constant throughout the session. This also applies if you are using an Airtel “stick” plugged into your computer.

This is most often relevant, for our clients, when trying to use either regular email or webmail. In the former instance, if the IP address assigned to your phone (or “stick”) by Airtel keeps changing every few seconds, you will likely be unable to send email, or you may get lucky and be able to send email every few tries. In the case of webmail, you will find that you will be logged out of the system constantly, often while you are actually trying to log in. This can also happen when trying to log into the control panel or any other service hosted by NinerNet that requires you to log in.

This problem exists, as noted above, with any system that requires that your IP address remain the same during a session. A “session” is the time between when you log into (using a user name and password) a website or other Internet-based service, and when you log out. Many web- and Internet-based systems require your IP address to remain constant throughout a session to prevent someone taking over your session and pretending to be you, thereby being able to log into whatever account you were logged into at the time they managed to hijack your session.

You can check your IP address by pointing your web browser to www.niner.net/go/ip. If you refresh the page every few seconds and your IP address keeps changing, then you will have the problems described above.

If you are having this problem, please contact Airtel and explain that your IP address is apparently changing every few seconds, and that this is preventing your from logging into Internet-based services. Please also let us know that you have done this, so that we can track this issue to resolution. Airtel have, apparently, been reasonably responsive on this issue with the NinerNet client mentioned above, but the issue has been going on since last week and has still not been resolved.

We apologise that your experience with NinerNet is affected by this issue. However, the problem is caused by Airtel, and the IP-based security on our systems and on many other systems used by other companies is there for a reason. It’s a very common form of security, and any connection systems provided by companies like Airtel simply must take this into consideration.

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 that that entails. This includes such concomitant industries and activities such a domain registration, SSL 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 facebook google happy hosting customers hosting transfer icann internet registry of canada invoices iphone iroc kwacha maintenance new services paying your bill paying your invoice quarterly kwacha rate review rates registrant transfers registrar transfers reputation scams search engine optimisation search engine optimization security seo service hours spam support testimonials transparency verisign

Resources:

Couldn't connect: Access denied for user 'ninernet_x_site'@'localhost' (using password: YES)