We’re pleased to announce that we now support WebAuthn/FIDO2 security keys as an option for two factor authentication (2FA). Customers have quite reasonably been requesting this feature for some time, but as we’re sure you’ll understand, this type of development work needs to be tackled carefully.

Security keys are physical devices – typically a small USB key – that can securely store digital credentials. When logging into a site, rather than typing a code from an app or sent to your phone via SMS, your browser will talk directly to your key, usually requiring you to tap a button to approve the authentication. Some systems also provide a compatible software token store, such as Apple Keychain (or Windows Hello, but we’ve not tested that).

Aside from being more convenient than typing a code, security keys are far more phishing-resistant than other methods. Convincing forgeries may trick humans into typing 2FA codes into fake sites, but WebAuthn ensures that credentials from a security key are only provided to the site for which they are intended to be used.

To set up security keys on your account, please visit the “Two-factor authentication” page in the control panel.

Use of security keys is entirely optional, and we will continue to support our existing 2FA methods. If you do want to use a hardware security key, you’ll need to purchase one if you’ve not got one already. Most of our staff are using Yubikeys, but any FIDO2 device should work.

We strongly recommend that you have at least two working 2FA methods, and make sure that they’re not tied to the same device; having SMS and TOTP on the same phone won’t help if you lose your phone.

We take account security seriously, and if you lose your access to your 2FA device, we will not reset your access by email alone as this would completely undermine the additional security provided by 2FA. (You can reset your password by email, so this would make email a single factor.)

We also know that many of our customers don’t trust SMS-based 2FA, so if you have chosen not to enable SMS-based 2FA, we won’t reset your 2FA that way either. Getting access to your account after losing all your 2FA methods is slow and tedious. This is a feature, not a bug.

We strongly recommend printing some recovery codes and filing them somewhere safe as a fallback method.

We are committed to providing support delivered by real humans. We know how frustrating it can be to have to fight your way past chatbots and virtual assistants that can’t help you in order to get to a human that can.

In fact, when you contact us, your message will be dealt with not only by a human, but by one of our technical staff who, on other days of the week, will be managing our routers, running our DNS servers, developing our control panel and maintaining all our other infrastructure.

LLMs break processes designed for humans

Modern Large Language Models (LLMs) are very impressive, and we know that many people find them useful in spite of their inherent and well-documented unreliability. One of the downsides of LLMs is their ability to produce large quantities of text that can overwhelm processes that are built to deal with human input. This is being seen in many places, from bug bounty programmes being DoSed by LLM-generated submissions, to schools unable to cope with a huge increase in the volume and size of complaints from parents.

We’ve now started to see this in our support queries. Fortunately, the volume is not yet problematic, but we have had cases where we’ve spent a disproportionate amount of time dealing with LLM-assisted ticket submissions. This includes time spent trying to decipher what the question actually is thanks to LLM-induced obfuscation, and also time spent answering tickets that are just much longer than they would have been had they been written by a human.

Dealing with LLM-generated support queries

Our target is to respond to all support queries within one working day. Providing a 100% human support response on this basis simply doesn’t work if support requests are being generated automatically. Therefore, we have amended this target to exclude queries that we believe have been generated by an LLM; if you submit a support request which we believe has been made harder or more time consuming to answer by the use of an LLM, we may reject it and ask you to resubmit a human-authored request instead.

If you want to use an LLM to help solve your query yourself that’s great. But if that’s unsuccessful, please don’t send us your LLM output as a support query; send us your input – your prompt – instead.

We’ve posted previously about our refreshingly boring approach to domain pricing – we take the price that our supplier charges us, add a little bit more than it costs us to provide the service and sell them on.

We’re pleased to say that we’ve recently crossed the top volume threshold with our biggest domain supplier, meaning that the price that we’re charged for many domains has gone down. So, we’ve run the script, regenerated our price list and have reduced our prices for the vast majority of Generic TLDs (gTLDs) and non-UK Country Code TLDs (ccTLDs). For example, .com domains have dropped in price from £14.50+VAT for one year registration/renewal/transfer to £13.50+VAT.

We’re proud to provide a sustainable, no-nonsense approach to pricing. We don’t mess around with loss-leading first year pricing that needs to be clawed back through inflated renewal pricing or a hard sell on add-on services that you don’t really need.

The new prices apply to renewals and transfers as well as new registrations, and to new and existing customers alike. Our new prices can be viewed at mythic-beasts.com/domains.

Constant pestering to review every online transaction is rapidly overtaking cookie banners as the most annoying feature of the modern internet.

We’re committed to making the internet less annoying. We don’t have a cookie banner on our website – we don’t need one because we don’t track you – and we also won’t hassle you to review us every time you interact with us.

But review sites exist, and we know that many people do look at them, so we’re very grateful to the customers that have left us some truly wonderful reviews on TrustPilot and elsewhere.

Unfortunately, the flipside of not constantly nagging our customers to review us is that the volume of reviews that we receive is relatively low, and a small number of negative reviews can have a big impact on our overall score.

After a five-year run of nothing but 5* reviews on TrustPilot, we recently received a couple of suspiciously similar 1* reviews within the space of a week. The reviews are light on details, and the reviewers have not responded to our request via TrustPilot for more context for the reviews.

Various aspects of the reviews make us believe that these reviews are not from people who have had any genuine experience of Mythic Beasts but have in fact been commissioned by a disgruntled third party. You can see the details, and our response, on our TrustPilot page. You can also see the significant impact that it has on our overall score, which is amplified by the weighting that TrustPilot give to more recent reviews.

We have flagged the reviews and provided TrustPilot with details of why we believe that these reviews cannot be genuine, and why we believe that they are “incentivised”, both of which are against TrustPilot’s Ts&Cs, but despite the reviewers’ refusal to provide any details to validate their reviews, TrustPilot have thus far elected to let the reviews stand and have only provided us with automated or templated responses.

We are now an Accredited .ie Registrar, meaning that we can offer our no-nonsense approach to domain registrations on all .ie domains.

Are you fed up with companies that offer discounted initial registrations followed by inflated renewal prices or a hard sell on extras that you don’t need? Transfer your .ie domain to us today.

Our .ie domain registrations include all of our usual domain registration features including:

• DNS hosting, with easy zone import and export
• Powerful DNS API
• DNSSEC support
• Dynamic DNS support
• No lock-in
• Great support

… and of course, our refreshingly boring pricing.

Residency requirements

.ie domain registrations do require that registrants have a “Connection to Ireland”. Being a resident, or having a registered Irish company immediately ticks this box, but there are other ways to qualify.

We currently handle new domain registrations manually. You can order via our website, and we’ll be in touch with any details needed to prove your connection to Ireland.

Transfers

.ie domain transfers are really fast and simple:

1. Get the auth code from your current registrar.
2. Make sure your domain is unlocked.
3. Go to transfer domain on our website.
4. Enter your domain name.
5. Choose how long you want to renew for (between 1 and 9 years).
6. Enter your auth code.
7. Give us some money.

The domain transfer should complete immediately.

As with most domains, the period that you select when transferring is added to your current expiry date, so the transfer doesn’t really cost anything, you just pay for your renewal early.

Pricing

.ie domains are one of the few TLDs where we do charge less for new registrations than renewals, but that’s only because the .ie registry charges us less.

We charge £15.50+VAT for a one year registration, and £21+VAT for a one year renewal or transfer. There are some decent multi-year discounts available: a ten year registration costs just £101+VAT, and a nine year renewal/transfer costs £123+VAT.

A recent Google support article has quietly announced plans to drop POP3 support from Gmail in January 2026. On the face of it, this is no big deal. For most purposes, POP3 has been pretty much replaced by IMAP anyway, but there’s a more important change buried in the article.

The issue is confused by the fact that Google use the “Gmail” name to refer to two completely different things:

• The Gmail mobile app that lets you read email on your phone and tablet.
• The Gmail web interface that lets you read email in a browser on your computer.

The Gmail mobile app lets you connect to multiple different mailboxes, and will continue to do so, just not with POP3. IMAP is much better for this purpose, as it supports mail folders, and properly supports access from multiple different devices, so the removal of POP3 support here is no big deal. If you use the Gmail app to read mail in a mailbox hosted with Mythic Beasts, it’ll continue to work just fine.

The significant change is this one:

• The option to “Check mail from other accounts” will no longer be available in Gmail on your computer.

“Gmail on your computer” is Google-speak for “the Gmail web interface”. The “Check mail from other accounts” option is a feature that allows you to pull in mail from other mailboxes and drop them straight into your Gmail inbox. It behaves as if you had just forwarded mail from your other address to your Gmail address, but with one crucial difference – it works reliably.

As we discussed in a recent blog article, efforts to make it harder to spoof email have also made it much harder to forward email reliably, and until now, the “check mail from other accounts” feature has been our recommended way to “forward” mail to your Gmail inbox.

Hopefully Google will contact users to tell them about the change, but we are also doing some log analysis and will be contacting customers who appear to be relying on this feature to collect mail from their Mythic Beasts mailboxes.

Customers who are currently using this feature will either need to revert to simply forwarding emails to Gmail — with the associated risk that Gmail may reject some of your legitimate email – or switch to a different webmail platform. And on that last point, we’re working on a refresh of our own webmail platform that we’ll be announcing in the near future.

After careful consideration, we have reluctantly taken the decision that the use of Cloudflare will not be supported on our Web and Email Hosting service. First two clarifications:

• This only applies to our Web and Email Hosting services. It does not, and will not, apply to virtual servers (VPS), dedicated servers or Raspberry Pi servers.
• We have never formally supported or encouraged the use of Cloudflare with our Web and Email service. Until now, we have generally discouraged it, but we’ve tried to accommodate users who chose to use it.

The problem

As we’ve written about previously, we’ve seen a huge increase in the amount of abusive bot traffic hitting our web servers — much of it badly behaved AI scrapers — and frequently the volume of traffic is such that it overwhelms the server, and makes websites unavailable. At times we’ve seen over 95% of traffic coming from AI scrapers. Our Web and Email Hosting service is what’s often referred to as “shared hosting” meaning that we have websites for many customers on a single server. This is a very cost effective way to provide web hosting, but it does mean that any load issues caused by traffic to one website can affect other sites on the same server.

Our primary tool for dealing with abusive traffic is to identify the source of traffic and block the IPs that it’s coming from.

Cloudflare provides a service that seeks to protect websites by blocking abusive traffic. It does this by operating a “reverse proxy”; rather than web traffic arriving directly at the web server, it is instead sent to Cloudflare’s servers. Cloudflare inspects the traffic, filters out the abusive traffic, and then forwards the legitimate traffic to the actual web server. This has the effect that all traffic arriving at the web server appears to come from Cloudflare’s IP addresses, rather than the actual client IPs.

Some of our customers have chosen to front websites hosted on our shared hosting servers with Cloudflare. The problem is that Cloudflare isn’t perfect; it doesn’t succeed in filtering out all abusive traffic. This is particularly true of the free tier that we tend to see used in conjunction with our Web and Email Hosting service.

Unfortunately, when we see a large volume of abusive traffic arriving via Cloudflare, we are faced with a choice: either we block Cloudflare’s IP addresses, knowing that this will take all websites using Cloudflare completely offline, or we accept the traffic, which potentially has an impact on all websites hosted on that server. With the growth in volume of abusive traffic, we are being forced to make this choice increasingly often.

We have now taken the decision that we will treat Cloudflare’s IPs like any other IPs: if we see abusive traffic from them, we will block them. In the future, we may introduce a permanent block, or redirect traffic to a support page on our site that explains why Cloudflare is not supported on the service in order to avoid customers inadvertently using an unsupported configuration, but we will contact customers who appear to be using Cloudflare prior to taking this step.

FAQs

Obviously these questions are not frequently asked as this is the first announcement of this change, but whatever; here are some questions and answers:

What have you got against Cloudflare?

None of this is a criticism of the service that Cloudflare provides. The same would apply to any reverse proxy service placed in front of our servers that prevents us from seeing the actual source IP, thereby removing our ability to effectively filter traffic ourselves.

We do have concerns about any service that breaks the end-to-end encryption of web traffic, but that’s unrelated to this issue. Cloudflare (and any other such service) relies on terminating the TLS connection from the client on their servers, inspecting the traffic, and then making a new secure connection to the target web server.

Why do you think you’re better at this than Cloudflare?

We’re not, but when a particular attack is affecting our ability to provide our web hosting service to hundreds of customers, we’ve got a much stronger incentive to resolve it quickly.

Cloudflare definitely has some very impressive technology, but we suspect that much of it isn’t provided in the free tier of their service. Upgrading to a paid-for tier, or careful configuration of the free tier, might yield better filtering, but in our case, we’re affected by the most permissive configuration; it only takes one customer to point Cloudflare at our server with minimal filtering and we’ve got a mix of legitimate and abusive traffic arriving from the same IPs and we’re back where we started.

Cloudflare includes the client IP address in an HTTP header – why don’t you filter on that?

Filtering based on the source IP address of a TCP/IP connection can be done very efficiently because you only need to look at the packet header. Filtering based on an HTTP header requires accepting the connection, setting up a TLS connection and decrypting the content, and then parsing the headers, which is a significant overhead, and in extreme cases, the load from doing this is prohibitive.

Can I use Cloudflare on my VPS or dedicated server?

Yes, absolutely. The issues described here that make Cloudflare such a problem for our Web and Email Hosting service don’t apply to VPSs and dedicated servers, so if you want to put Cloudflare — or any other reverse proxy — in front of your server, you are free to do so. Of course, dealing with any abusive traffic that slips through is your responsibility.

Can I use Cloudflare on my managed server?

If you have a managed server with us then we will attempt to resolve any load issues caused by abusive traffic as part of this service. Please do not install Cloudflare (or similar) in front of your managed server without discussing it with us first, as it will hamper our ability to respond to any incidents. A special case is our WordPress Shared tier of managed WordPress hosting. As the name suggests, this is implemented on our shared hosting platform, and so we cannot support the use of Cloudflare with this service.

Software-as-a-Service has transformed the way that we use computers. The ability to access services anywhere, on any device, without having to install, manage or upgrade applications has obvious advantages. You can be up-and-running on GitHub, Slack or Box in a matter of minutes, and very often there’s a free entry-level tier that requires no up-front payment at all.

Even when you move into the paid-for tiers, replacing the cycle of licence fees and upgrade fees with a simple ongoing service fee can also be attractive.

But SaaS comes with a major drawback: lock-in.

You’re at the mercy of a single provider, and your only recourse if you’re not happy with the service is a potentially complex and expensive migration to a completely different platform. It may not be easy, or even possible, to export your data from your old provider.

And those “free” entry-level tiers have to be paid for somehow. As your usage increases, costs can quickly become very expensive. Or the unprofitable cheap and free tiers get withdrawn or restricted as the business needs to move its income stream from investors to actual customers.

Self-hosted open source

Open source alternatives to many popular services exist, and the obvious alternative to SaaS is self-hosting: run your own server and install the software yourself. You’re completely in control, your data is on your servers and there’s no risk of lock-in.

But self-hosting loses many of the advantages of SaaS; you’re now responsible for running the servers, applying security patches, maintaining backups, and monitoring for issues.

Managed Open Source Services

At Mythic Beasts, we offer an alternative: MOSS – Managed Open Source Services. With MOSS, you get the convenience of Software as a Service, but without the lock-in. We manage the service, apply security updates, provide 24/7 monitoring and take regular backups, but your data remains under your control: we’ll happily give you full access to all the data on your server at any time.

By using open source software, you’re not tied to a single provider. If you’re not happy with our service you can migrate to another provider, or even switch to self-hosting, without the cost of having to familiarise users with different software.

And if you decide you do want to change software, open source puts you in a much stronger position for planning a migration.

Our pricing structure is straightforward, and tied to what it costs us to provide the service. With no free, entry-level tiers that need to be subsidised by the higher tiers, prices scale with your usage, rather than leveraging your lock-in.

We’ve been hosting exclusively on open source software for nearly 25 years, and provide Managed Open Source Services for a range of applications, including GitLab, Mattermost, and NextCloud. For more information, please see our Managed Applications page, or contact us to discuss your requirements.

Modern email involves a confusing array of different acronyms. Most of these are attempts to fix the problem of email being fundamentally insecure, with no way to authenticate the sender of an email. The remainder are attempts to fix the new problems created by attempting to fix the first problem.

This blog post tries to provide a concise glossary of these different technologies, and the associated DNS records and URLs needed to make them go.

SPF: Sender Policy Framework

Publish a list of servers that are allowed to send mail from your domain.

SPF is published as a DNS TXT record for the domain itself (an apex record), which states which servers are allowed to send mail from your domain. For example:

example.com. IN TXT "v=spf1 include:_spf.mythic-beasts.com ~all"

SPF breaks email forwarding, unless you use SRS. SPF only restricts the “envelope sender”, which is not normally visible to end users.

SRS: Sender Rewriting Scheme

Rewrite sender addresses when forwarding mail in order to avoid failing SPF checks.

SRS is a technique used when forwarding email that replaces the original sender address with an address in your own domain. SRS only affects the envelope sender, which is not normally visible to end users. SRS allows email forwarding to work with SPF.

DKIM: DomainKeys Identified Mail

Digitally sign email envelopes.

Public keys are published in DNS records, allowing recipients to verify that the email is authentic. Public keys are published as TXT records within the _domainkey subdomain. For example:

mythic-beasts-k1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG...."

The first part of the hostname is a unique identifier for the key. The signature is added to the email as a DKIM-Signature header. The header includes a field (the s field) with the name of the key used to sign the message.

DMARC: Domain-based Message Authentication, Reporting and Conformance

Tell recipients to reject email from your domain if it isn’t DKIM signed and doesn’t pass SPF.

DMARC is a mechanism that allows a domain owner to assert that all email sent will pass either DKIM or SPF validation, and if it doesn’t recipients should reject it. Subtly changes SPF behaviour so that it binds the “From” address (which is the one that users usually see) rather than the envelope sender. Breaks email forwarding even with SRS unless messages are DKIM signed. Example DMARC record:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=postmaster@example.com"

ARC: Authenticated Received Chain

Enable mailing lists to forward DKIM-signed emails.

ARC allows a system that forwards mail to provide a digitally-signed summary of the results of SPF, DKIM and DMARC validation at the point thta it was received by the forwarding server. This enables the intermediary system to make changes to the message (such as adding a mailing list footer) that will break the original DKIM signature, but still allow the final receiver to verify its integrity. ARC relies on recipients trusting the intermediary. ARC uses the same DNS-published DomainKeys as DKIM.

DANE: DNS-based Authentication of Named Entities

Publish TLS certificates in DNS, and require TLS when connecting to your servers.

DANE is not specific to email, but it can be used to enforce the use of secure TLS connections when mail servers talk to each other. In the absence of DANE, mail servers will generally try to use TLS if possible, but fall back on an insecure connection if it doesn’t work. By publishing a TLSA DNS record, domains can enforce that TLS is used when delivering mail to the servers listed in its MX records. DANE relies on DNSSEC, and also provides an alternative to Certificate Authority-based authentication of TLS certificates.

MTA-STS: Mail Transfer Agent Strict Transport Security

Require TLS when connecting to your servers by publishing a policy at a well known URL.

MTS-STS allows you to require secure TLS connections when mail servers connect to your server by publishing a machine-readable policy at a well-known URL (https://example.com/.well-known/mta-sts.txt). MTA-STS is an HTTPS-based alternative to the TLS-enforcement part of DANE.

As of yesterday, new support tickets are now being handled in our new support system, which is powered by Request Tracker (RT). Hopefully from the outside, things look exactly as they did before: you email support@mythic-beasts.com, your request gets assigned a ticket number, and you get a timely and helpful response from our non-dedicated support team.

From the inside, this change is pretty daunting. Our support system is absolutely critical to our day-to-day work, and learning a new tool, and adapting all of our customer-facing process to use it is a big change. There are lots of little things like the canned “snippets” that we use when composing replies to common questions, and the processes to be followed when contacting customers in response to automated alerts. Doing this from a clean slate would be hard enough, but we also have to provide continuity for existing tickets, which can remain active for weeks, months or very occasionally, years.

We’ve been tackling the migration as incrementally as possible. Most internal, and certain external tickets have been handled in RT for some weeks now, but yesterday was the day that we flipped the switch on the support@ fire hose.

Our previous system has served us well for the 16 years that we’ve been using it, but it suffers from being closed source. There have been various enhancements that we’d like to have made, but we couldn’t, and ultimately our migration away from it has been forced by the fact that the standalone product is no longer maintained, having been replaced by SaaS version – an option that is out of the question for us.

Of course, not having access to the source code has made migrating away from it harder.

Open Source or bust

We actually evaluated RT a bit over twenty years ago, and decided that it wasn’t right for us, based mostly on some requirements that in hindsight seem a bit odd (RT has also matured a bit since then!) In selecting RT this time, we carried out a thorough evaluation of available ticketing systems, with one absolutely non-negotiable requirement: must be open source and hosted in house. We simply cannot afford for such a critical and hard-to-migrate part of our business to be locked in to closed source software, let alone a SaaS service.

Our primary goal with the new system so far has been to replicate the functionality that we had before, but once it is bedded in, we plan to make further enhancements to improve integration with our other software. Whilst in the short term we hope that you’ll see no change, in the long-term we hope that customers will see improvements to how we handle support.

We’re considering adding Request Tracker to our list of managed applications. Please drop us an email if this is something that you might be interested in.