Category: Tech Insight


In this blog post, we’ll take a look at SPF and why its important in ensuring email from your MIDAS room booking system is reliably delivered.

SPF stands for “Sender Policy Framework” and its purpose is to prevent unauthorized people from forging your e-mail address and pretending to be you. SPF has been around for a number of years now, but in recent times has been growing in popularity as more and more websites and email providers start enforcing it.

As our MIDAS web based room booking systems are capable of sending email on your behalf, it’s important to understand how SPF works and how it can help solve email delivery issues in MIDAS.

Take for instance the following example Scenario:

  • Your MIDAS system is running on domain “A” (i.e. your-organization.mid.as)
  • Your MIDAS system is configured to send emails to appear as though they are sent from an email address belonging to domain “B” (i.e. your-organization.com)
  • An email is sent from your MIDAS system to a recipient with an email address on domain C

In the above example, the receiving mail server for domain C queries the SPF record on domain B to check whether domain A is authorized to send mail on behalf of domain B. If it isn’t the email is rejected.

An SPF record is simply a TXT record in a given domain’s DNS, and a simple example may look similar to this:

v=spf1 +a +mx ~all

The format of an SPF record begins with a version number; the current SPF version is “v = spf1”.
Following the version string, any number of expressions may be included which are evaluated in the order they appear. These consist of an optional “qualifier” (+, -, ~, or ?) and a “mechanism” (all, a, mx, ip4, or include). The first mechanism that is matched in the SPF record determines the result of the entire valuation of the SPF record.

Qualifiers:

QualifierResultDescription
+PassDefines an authorized sender
(If no qualifier is specified, + is assumed)
FailDefines an unauthorized sender
~SoftFailDefines an unauthorized sender
(however it may not notify the sender that their email failed)
?NeutralDefines a sender whose legitimacy isn’t determined
(In such instances, sending is allowed)

Mechanisms:

MechanismApplies if…
allalways
aAn A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
mxAn A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
ip4The specified IPv4 address is the IP address of the sender or of the specified IPv4 subnet which contains it
includeAn additional SPF request for the domain specified in the include statement contains the IP address of the sender

SPF records cannot be over 255 characters in length and cannot include more than ten “include” statements.

Example SPF record:

 v=spf1 +a +ip4:1.2.3.4 -ip4:5.6.7.8 +include:somedomain.com ~all 

In the above example:

  1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
  2. Email delivery will also be allowed if it originated from the specific IP address 1.2.3.4
  3. Email delivery will be rejected if it originated from the IP address 5.6.7.8.
  4. Email delivery will be allowed if it matches the rules defined in the SPF record on “somedomain.com”
  5. All other email sources will be softly rejected (~all)

Bringing it back to MIDAS…

If you run a cloud-hosted MIDAS system at the domain “your-organization.mid.as”, your organization’s own website is “your-organization.com”, and you wish to allow your MIDAS system to send email on behalf of addresses @your-organization.com, then you should setup/modify an SPF record on your-organization.com.

This SPF record would authorize your hosted MIDAS system to send email on behalf of your organization. Failing to correctly set an SPF record for your domain may mean that emails sent from your MIDAS system may not reach recipients.

For our hosted customers, you can simply include “include:_spf.midas.network” in your-organization.com’s SPF record. Your new/modified SPF record may then look similar to this:

v=spf1 +a +mx include:_spf.midas.network ~all

In the above example:

  1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
  2. Email delivery will be allowed if it originated from the same mail server as it was sent (+mx)
  3. Email delivery will be allowed if it matches the rules defined in the SPF record on “_spf.midas.network”. This will allow your hosted MIDAS system to become an authorized sender of email for your domain.
  4. All other email sources will be softly rejected (~all)

Remember, SPF records are simply TXT records within your domain’s DNS. If you’re not sure how to set/modify DNS records for your own domain, you’ll need to defer to the domain’s administrator, registrar, or hosting provider who should be able to assist in making the necessary adjustments to your domain’s DNS record

Further reading from our Knowledgebase:.

In addition to our commitment to regularly bringing exciting new and improved features to our easy-to-use room booking system, MIDAS, we also work hard behind the scenes to constantly improve the overall speed and performance of both our software and infrastructure.

In this article, we’ll take a closer look at some of the performance improvements we’ve introduced over the past year, and some of the performance improvements you can look forward to in the very near future!

Caching and CDN

CDN stands for “Content Delivery Network”, and is a means whereby web content – such as an image – is stored on multiple servers around the world. When the image is requested by a visitor’s web browser, rather than the image being served from a single origin server (which may reside in another country), it is instead served by the nearest/fastest server in the CDN network. The result is significantly improved loading times for content served via a CDN.

Back in May last year (2018) we introduced CDN support for static content for all our cloud-hosted MIDAS customers.

As a result, we quickly saw performance improvements and reduction in load times of customer’s hosted MIDAS systems by up to 67%! You can read more about this in this blog post.

Improved DNS

DNS stands for “Domain Name System”, and can be considered as a “phone book” for the internet. When you enter a website in your browser’s address bar, a DNS system is used to look up the corresponding server on the internet that the URL you’ve entered resolves to, allowing you to then access the site.

This week, we’ve migrated our DNS to a distributed/cloud-based system. Previously, our DNS was provided by our own web servers, so for example, if you wanted to access our blog (blog.mid.as) the DNS system would first have to make contact with mid.as to find out the location of blog.mid.as.

With our new distributed/cloud-based DNS system, DNS is now handled in a similar way to the CDN system outlined above – that is to say that when you enter a URL/sub-domain for any part of our site, the DNS is resolved on a server geographically close to you.

As a result, we’re seeing DNS lookup times for our site up to 5 times faster than previously!

The above images (from dnsperf.com) show how quickly the mid.as domain would resolve from various locations around the world previously (left image) and again now (right image)

XML vs JSON

What and what?! XML stands for eXtensible Markup Language. JSON stands for JavaScript Object Notation. Both are methods for storing and transporting data, with JSON being the newer of these two methods.

As we’ve been developing MIDAS for well over a decade now, XML has been the format we’ve used for the main settings file within our software for the majority of that time (as JSON wasn’t really around a decade ago!). The downside of using the XML format particularly when used in conjunction with Perl (the language which MIDAS is written in) is that it tends to be a little slow and clunky.

That’s why starting with our next software update, v4.22, we’ll dropping the main XML settings file in favor of a JSON settings file instead. In our own benchmark testing, this simple change has resulted in improved load times of ~10ms per request, which may not sound a lot, but is actually quite noticeable.

As a result of this upcoming improvement, self-hosted customers will need to ensure that the JSON Perl module is installed and available on their MIDAS system in order to be able to update to v4.22 when it becomes available. Instructions of how to do this may be found in our How to install Perl modules KB article. Cloud-hosted customers don’t need to worry about this, as we’ve taken care of it!

MIDAS and Internet Explorer 11

Here are MIDAS HQ we love getting feedback from our customers! Whether positive or critical, all feedback is important to us as it helps us to continually develop and improve our MIDAS room booking & resource scheduling software and service to make it the best it can be!

Our customer feedback is overwhelmingly positive, and you can read some of these comments on our website and also on independent review sites such as TrustPilot.

However, in recent times a handful of customers have commented specifically in relation to the user interface (UI) of MIDAS, which a few perceive as now a little “dated”.

We wanted to begin addressing this for our next MIDAS update, v4.20, and so we’ve introduced a number of changes and improvements in this area which you can read about in the following blog post.

However, we also thought it would be useful to explain some of the challenges we’ve faced with regards to the UI over the years.

As you may or may not know, MIDAS has been in continuous active development for well over a decade, and our philosophy has always been to support ALL popular web browsers (Internet Explorer, Mozilla Firefox, Google Chrome, Opera, Apple Safari, and more recently Microsoft Edge).

Room Booking System for Chrome, Firefox, Safari, Opera, and Edge This has been an enormous task over the years, but we feel strongly that our users should have a choice of which web browser they use, with a consistent MIDAS experience between browsers, and not be forced to use one particular browser in order to be able to access and use our MIDAS software.

It’s fair to say that the most difficult web browser to maintain support for over the years continues to be Microsoft’s Internet Explorer series, primarily because it has always lagged way behind all other vendor’s browser offerings in terms of its development, updates, and support for the latest standards (the web has developed and evolved significantly over the years we’ve been developing MIDAS, and Internet Explorer doesn’t keep up!).

To some extent we’ve been “held back” over the years by our decision to continue to support customers who force their uses to use Internet Explorer, however, as of today the only version of Internet Explorer we officially support is 11, having deprecated support for IE10 & 9, IE8, IE7, and IE6 over the past decade.

MIDAS and Internet Explorer 11 Continuing to support MIDAS in IE11 for the very small (and ever decreasing) percentage of our users who continue to use this old browser limits how we can develop MIDAS, particularly in terms of the user interface.

Whilst we would have loved to have dropped IE11 support long ago, Microsoft have committed to providing mainstream support for IE11 until the end of life of the operating systems upon which it is installed – namely, Windows 7, 8 and 10. Windows 7 & 8 have both now reached their EOL (End Of Life) for mainstream support, however Windows 10 is still actively supported by Microsoft and will continue to be for the foreseeable future (for a minimum of at least two years).

That’s why we’ve taken the difficult – but necessary – decision that at some point during 2019 we’ll officially be dropping IE11 support in MIDAS.

This won’t necessarily mean that MIDAS will suddenly cease to function for IE11 users next year, but it does mean that over time new features and new user interface elements and enhancements may not display or even function correctly if you continue to access MIDAS using Internet Explorer 11.

If you’re currently an IE11 user, there is however, plenty of time to switch to a different web browser and there’s plenty of choice when it comes to modern alternative web browsers.

MIDAS will continue to be supported in recent versions of Firefox, Chrome, Safari, Edge, and Opera.

We appreciate that this may affect a very small number of users, but we hope this blog post gives some insight and understanding as to why we’re making this decision and also gives you plenty of time to switch to an alternative, more modern, web browser.

As ever, if you have any questions or concerns over how this may impact you and your organization’s use of MIDAS, please don’t hesitate to contact us and our friendly team will be only too happy to help!

New Content Delivery Network (CDN)

May’s been a busy month here at MIDAS HQ!

Not only have we migrated Certificate Authorities to Let’s Encrypt, but we’re also been testing a new Content Delivery Network (CDN) feature in MIDAS.

To explain what a CDN does, imagine viewing a photograph online. That photograph will be stored on a web server somewhere. If you’re in the UK and the server where the photograph resides is located in Australia, it will take your browser longer to establish a connection and download the image from the other side of the world than it would do if the server was located in the same country as the person viewing the image. Now, we may only be talking of a few fractions of a second longer, but if you’re viewing a webpage containing several photographs, that can soon add up!

A Content Delivery Network vastly improves performance by storing (or “caching”) a copy of the photograph from the source server on multiple servers all around the world. Then, when a viewer requests the photograph, the CDN serves a cached copy of the file from whichever server is geographically closest to the viewer. This greatly improves the load time for the viewer, and also reduces the load on the original server (as the photograph is served from the CDN “cache” instead).

As a CDN “caches” a source file/webpage, it is only suitable for “static” content which doesn’t change frequently (for example, images, Javascript, Cascading Style Sheets, downloads, etc). “Dynamic” content (i.e. content which changes frequently/upon each visit, files must still be served directly from the origin server, rather than via the CDN.

In MIDAS v4.18 we unofficially introduced support for serving static resources from a CDN (CloudFlare), and this has been automatically enabled for all MIDAS trials and for all new cloud-hosted customers since the start of April, whilst we closely monitored its impact and effectiveness.

As our CDN trials proved effective and exceeded our expectations, throughout May we’ve been engaged in a phased roll-out of the CDN for remaining cloud-hosted customers, and we’re pleased to announce that all cloud-hosted MIDAS systems now have CDN support enabled.

We’re currently seeing nearly 90% of all requests for static resources being served directly from CloudFlare’s global CDN network, and performance improvements and reduction in load times of customer’s hosted MIDAS systems of between 13% – 67%!

We’re sure you’ll appreciate these performance improvements, which are all part of our ongoing commitment to provide the best possible service for our customers! …and we’ve more improvements and enhancements in the pipeline too!

Let's EncryptDuring the course of May we’ve been migrating our domain’s security certificates from ones issued by GlobalSign to ones issued instead by Let’s Encrypt.

What Is A Security Certificate?

In essence, a security certificate is what allows you to connect to a website over a secure https connection (instead of traditional, insecure, http). A valid and strong security certificate is what ensures that the connection and traffic between your web browser and the website/service you’re using is encrypted.

What Is A Certificate Authority?

Put simply, a “Certificate Authority” (or CA for short) is an organization responsible for issuing and revoking security certificates for websites. Popular CA’s include Comodo, Symantec, GoDaddy, and GlobalSign to name but a few.

Which Domains Are Affected?

All mid.as domains and *.mid.as sub domains (including our cloud-hosted customer’s domains)

Why Is This Happening?

Our security certificates were due for renewal in June, and as part of our continuous commitment to provide visitors to our site and customers alike with the best possible experience, we took the opportunity to review who provides our security certificates. Let’s Encrypt provide HTTPS certificates to over 70 million domains, and switching to certificates issued by Let’s Encrypt allows us to simplify and automate the management of security certificates across our growing MIDAS network.

Will I Notice Anything Different?

In short, no!

In order to migrate our CA from GlobalSign to Let’s Encrypt, we needed to remove the previous GlobalSign (AlphaSSL) certificate from each *.mid.as domain and install a new Let’s Encrypt certificate in its place. We have being doing this in a phased transition for all *.mid.as domains during the course of May, and we’re pleased to report that this transition to Let’s Encrypt is now fully completed.

Here’s how the old and new certificate issuers now look for our *.mid.as domains:

CA Migration to Let's Encrypt

We’d also like to reassure hosted customers that no domains, URLs, or IP addresses have changed as a result of this CA migration.

If you experience any issues or have any concerns, please don’t hesitate to reach out to us and we’ll be happy to help!

A note for cloud-hosted API users

Whilst unlikely, depending upon your code and development platform/language, you may initially receive a certificate warning/error when mmaking API calls now that the security certificate for your dedicated *.mid.as subdomain has changed, which may prevent your code/app from working temporarily until you accept the new security certificate.

Also, in some rare cases, you may not be able to access the API if your platform/device is listed as incompatible in Let’s Encrypt’s certificate compatibility list.

Finally, please be aware that Let’s Encrypt issues auto-renewing certificates which are valid for fixed periods of 90 days.

[ Back to top ]