Tag Archive: email


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:.

When adding new bookings to MIDAS (or modifying existing ones) if there’s an email address on record for the client that you’re making/modifying bookings for, then MIDAS will offer a “Send Booking Confirmation?” tick box on the Booking Availability screen, allowing you to send an automated booking confirmation email notification to the client when the bookings are made.

Sometimes, you may wish these booking confirmation notifications to go to multiple recipients in addition to the primary client that the bookings are for.

That’s why MIDAS v4.19 will automatically detect email addresses added to the standard “Booking Notes” field, or any text custom booking fields, and offer these as additional “CC” email addresses for the booking confirmation notification to also be copied to.

Here’s an example to illustrate:

Detect email addresses entered into booking fields

Two email addresses have been added to the “Booking Notes” field for the above booking. When “Check Availability and Book” is clicked, the following “Booking Availability” screen is shown:

Offer additional recipients for booking confirmation notification

Notice how MIDAS has detected these email addresses and offered each as an optional cc recipient for the booking confirmation email to the client.

Please Note: Cloud-hosted editions of MIDAS will detect a maximum of 5 additional email addresses in booking fields when MIDAS is configured to send via an external SMTP server, or a maximum of 2 additional email addresses when configured to send via the Sendmail option. There are no limits imposed in self-hosted editions.

MIDAS can be configured to send outgoing email via SMTP/Sendmail via MIDAS Admin Options → Manage MIDAS → Email. For more information, please refer to the documentation at https://mid.as/help/manage_email_settings

Click here to continue reading about some of the other new & improved features coming in MIDAS v4.19!

MIDAS v4.19 is coming soon! To be notified when it becomes publicly available, please join our mailing list, or to be among the very first to try the v4.19 “Beta”, why not join the Beta Test? (We reward our Beta testers too!)

The first big update of 2018 for our MIDAS web based room booking and resource scheduling system is nearly ready, and includes a number of user-requested features and improvements.

Now, MIDAS has included a “BCC outgoing email to” setting for quite some time now. This setting allows you to enter an e-mail address to which e-mail (excluding generated notifications) sent by your users through MIDAS will be BCC’d (Blind Carbon Copied) to.

It’s a useful setting, as it allows administrators to keep track of outgoing e-mails, or for archiving purposes.

However, the setting has caused confusion for some customers who instead expected this setting to send a copy of EVERY single outgoing email (including system-generated notifications) to the defined email address, rather than its intended use of only BCC’ing emails that are not generated notifications (for example, if a user emails a client through the in-built email function).

Therefore, to add greater flexibility for those customers who have requested it, we’ve expanded the email BCC capabilities of MIDAS for v4.18.

You’ll now be able to select which “types” of outgoing emails from your MIDAS system you’d like to be BCC’d to a pre-defined address:

Choose which types of email to BCC

The types of outgoing email you can choose to be BCC’d include:

  • Generic
  • Bookings:
    • Booking Cancellation
    • Booking Confirmation
    • Booking Reminder
  • Booking Requests:
    • Booking Request Approved
    • Booking Request Approved (with changes)
    • Booking Request Rejected
    • Booking Request Submitted
  • Invoices:
    • Invoice (Cancellation)
    • Invoice (Regular)
    • Invoice Overdue
    • Invoice Reminder
    • Receipt

We do however suggest that you think very carefully as to which types of emails you select to be BCC’d, as for larger MIDAS systems this could result in a significantly higher volume of outgoing email traffic.

For this reason, the extended BCC email options for our “cloud-hosted” customers are limited to only be available if your MIDAS system is configured to send outgoing email via an external SMTP server/relay. If your cloud-hosted MIDAS system is configured to send email via the internal “Sendmail” option, the extended BCC email options will be unavailable to you. This restriction does not apply to self-hosted MIDAS systems.

Click here to continue reading about some of the other new & improved features coming in MIDAS v4.18!

MIDAS v4.18 is coming soon! To be notified when it becomes publicly available, please join our mailing list, or to be among the very first to try the v4.18 “Beta”, why not join the Beta Test? (We reward our Beta testers too!)

With development nearing completion on the next update to our room booking and resource scheduling software, MIDAS, we’re shedding a little light here on our blog on some of the new and improved features to look forward to in v4.13…

When a new booking request or message is received or a new “watch notification” triggered, MIDAS alerts the user by subtly changing the relevant toolbar icon to denote the number of new booking requests or messages requiring your attention. Users can also optionally choose to see a list of these requests/messages each time they login in.

Furthermore, a user can optionally choose to be sent email notifications upon each new booking request, message, or watch notification.

With the upcoming new addition of Desktop Notifications in v4.13, which enables more prominent on-screen alerts to logged in users upon new booking requests, messages,or watch notifications, we’ve added a useful new option to v4.13..

Suppress New Booking Request Email Notifications Suppress New Message/Watch Notification Emails
Suppress new Booking Request email notifications whilst logged in Suppress new Message/Watch notification emails whilst logged in

The new settings will allow a user to suppress receiving such notifications in their email inbox whilst they are currently logged in to MIDAS, so they’ll only be sent during those times they’re away from their computer, laptop, tablet or mobile device, and logged out.

We believe these new per-user setting will help to reduce the number of redundant email notifications from your MIDAS system, but of course, because this setting can easily be toggled on/off by users at any time – if you do still want to receive an email notification on every new request/message, even when you’re logged in you’ll still be able to do so!

MIDAS v4.13 is expected to be made available to Beta Testers in the next few weeks, with a general release shortly after. We’re always looking for additional testers to help test and provide feedback/bug reports on pre-release versions of our software, like v4.13. Becoming a tester is free and no experience is required, and what’s more we’ll reward you for your participation! Find out more about becoming a MIDAS Beta Tester here.

If you would like to be notified when v4.13 is fully released, then why not join our Mailing List?

One of our customers recently contacted us to report a strange issue whereby booking requests made through their MIDAS scheduling system were seemingly vanishing from their system.

The “Booking Request” features of MIDAS, allow people to submit booking “requests” which then require approval by an administrator before becoming a “confirmed” booking.

There are a number of reasons why a booking request may legitimately appear to “vanish” from the system; first of all, another administrative user may have already rejected the original booking request, or the original requestor may have changed their mind and canceled their own request.

When a person makes a booking request, MIDAS automatically send them an email notification containing details of the request they’ve submitted. These email notifications also contain a “booking request cancellation link” allowing them to cancel their request if for whatever reason they’ve changed their mind before their request is approved.

Inspecting the provided “Recent Activity Log” for the customer’s MIDAS system, there was no evidence to suggest that another user had simply rejected the missing booking requests.

There was however evidence that the booking request cancellation links, contained within the notification emails sent to original requestors had been clicked.

The customer was confident that no-one had clicked these cancellation links in their emails.

Now, the “Recent Activity Log” within MIDAS is very useful – not only does it record actions performed within a MIDAS system, it also records the user who performed the action (where applicable), the time/date the action occurred, and the IP address of the device which performed the action.

This allowed us to correlate booking request cancellation link clicks with the IP addresses from which each originated.

Interestingly, the IP addresses could all be traced back to Barracuda Networks, Inc, a company offering security products, including email security and spam filters.

So what was going on?

Once upon a time spam filters could easily detect spam email messages, as spammers tended to the same domains in their spam. As a result, spam filtering software could simply scan the content of an email message, and cross-reference any links contained within against a list of known spamming domains (known as a “blacklist”).

Many spam filters still behave in this way, however, in an attempt to stay one step ahead of the spammers, some spam filtering software/services – such as those provide by Barracuda Networks, Inc, go one step further and actively “click” EVERY link in every email they scan. The purpose behind this is to analyze the content and domain every link points to.

Whilst this will most likely help reduce spam further for the recipient, it can have a number of undesired consequences for users!

For example, if the recipient subscribes to any newsletters/mailing lists which contain a one-click unsubscribe link at the bottom, they will be automatically unsubscribed simply by receiving the email itself, before they even open it – let alone click the unsubscribe link!

The same thing was happening for our customer’s booking request notification emails – the booking request cancellation links were being automatically “clicked” by the spam filtering software/services which were scanning the recipient’s email.

Balancing user convenience vs aggressive mail scanners

We’ve always believed in making things as easy as possible for users – which is why we originally made canceling booking requests as simple as a “one-click” link – click once, and your request is canceled.

However, in light of these recent issues, we’re making a small change for MIDAS v4.12. Canceling a booking request will now unfortunately be a two-step process. Clicking a booking request cancellation link in a notification email will take the requestor to a web page where they will need to then click a confirm button in order to cancel their request.

The introduction of this second confirmation step, whilst less convenient for the end-user, will at least prevent aggressive mail filtering software/services which automatically “click” every link in every email, from automatically canceling booking requests without any human interaction.

The same “two-step” behavior will also be applied for links in booking/invoice reminder emails to suppress future reminders from a MIDAS system.

In the meantime, if you’re running an earlier version of MIDAS, and notice your booking requests being automatically canceled without any intervention, please check and adjust the settings in your mail scanning/filtering software to “whitelist” email from your MIDAS system or prevent the automatic following of links within email.