SPF and DKIM – What is it and why block the failures?

Email is inherently flawed.

Email is built on trust. Yes, trust, and many hacked-together solutions, such as SPF and DKIM, are slapped on top of it. That doesn’t mean those systems are bad, though; just that they are “added on” and not a core part of email.

In the early days of email, you connected to the mail server where you wanted to deliver a message, told the server who you were and to whom to deliver the message, and then the contents of your message. That was it – you delivered an email. The astute among you may have already realized the problem and have probably experienced it yourself: spoofing.

Spoofing is when an email’s “from” header is forged to look like it came from someone it did not. We’ve all received emails addressed from us to us that we didn’t send – and that’s an example of spoofing.

Email is built on trust – trust that the sender is who they claim to be. How do you really know, though? How can you be sure that the email from your bank is really from your bank and not someone pretending to be your bank to steal your information?

Continue reading “SPF and DKIM – What is it and why block the failures?”

Migrating email made easy – IMAPSync

We offer full-service migrations for our clients, including email migration, so if you’re a client, don’t hesitate to ask us for help! For those who aren’t our clients or wish to perform email migrations themselves, we offer a public IMAPSync installation at https://imapsync.net/.

Using IMAPSync.net

Once you have navigated to our IMAPSync you will see the web form for performing IMAP migrations. To perform a migration, you will need at minimum:

  • The login for the source and destination servers (usually the email address).
  • The password for the email account on both servers (this may be different for each).
  • The IMAP Server name for the source and destination servers.

To test the details without performing a migration, you can check the box “Just verbose, no real sync” towards the middle of the form.

Once you have entered the details of both email accounts for the source and destination mailboxes, all you need to do is click “Sync or resync!” and the process will run. During the migration, you will see details of the run in the log at the bottom of the page.

Using IMAPSync on the command line

If you are an MDDHosting customer, we make the imapsync binary available to you via SSH/Terminal. The process will require the same details as above, but the big differences are that you will be running it from your service with us and that there is no easy-to-fill form to get it started.

Continue reading “Migrating email made easy – IMAPSync”

Hosting Resource Series – CPU Cores

CPU

Most web hosting providers offer resource limits on their services. Understanding these resource limits can help you make an informed decision when purchasing or upgrading a hosting service.

Layman Explanation – “The Car Analogy”

I often like to use what I call “The Car Analogy” to explain CPU cores. I use a car to represent a CPU core and people being transported to represent website visits.

Single CPU Core:

Imagine for a moment that you have one car instead of one CPU core. One individual car (CPU core) can move people (website visits) from one location to another, and it is designed and intended for this purpose.

Let us also imagine that the car will always move as fast as it is capable of doing. You do, after all, want to get where you’re going as quickly as you can, right? Your one car can only move people so fast, and it can go no faster.

Continue reading “Hosting Resource Series – CPU Cores”

Enhancements to the CloudStarter Plan: More Power at No Extra Cost

At MDDHosting, our mission has always been anchored in serving our customers with excellence. In line with this commitment, we’re eager to share some exciting news regarding our CloudStarter plan, which many of our valued clients are currently using.

Background

When we introduced the CloudStarter plan, it was designed to cater to lightweight websites. However, as the digital landscape evolved, so did the aspirations of our customers. We observed an increasing number of users leveraging the CloudStarter plan for more resource-intensive platforms, such as multiple WordPress installations and advanced Node.JS applications.

Introducing the Upgrade

To ensure that our users continue to enjoy a seamless online experience, we’re rolling out significant enhancements to the CloudStarter plan:

  • CPU Core Allocation: Now at a full 100%, up from the previous 50% allocation.
  • RAM: Doubled to 1GB (1024MB) from the earlier 512MB.

What makes this even more exciting? This substantial boost in resources comes at absolutely no additional cost to our current CloudStarter customers.

A Note on Grandfathering

It’s important to mention that while the CloudStarter plan is no longer available for new subscribers, current users need not worry. If you’re on this plan, you can choose to continue using it for as long as you desire, benefiting from the very enhancements we’re announcing today.

What You Need to Do

Absolutely nothing! The improvements will be applied automatically to all existing CloudStarter accounts. Should you have any questions or need further information, our dedicated support team is always on standby to assist.

In Conclusion

Your trust, feedback, and loyalty have been instrumental in driving these positive changes. We’re thrilled to be a part of your online journey and are committed to offering you the best hosting experience.

Thank you for being a valued member of the MDDHosting family. Stay tuned for more updates and improvements in the future!

Understanding TTFB: Why Lower TTFB Isn’t Always Better

TTFB: 62ms

Time to First Byte (TTFB) is a metric used to measure the responsiveness of a web server. It is the time taken for the server to send the first byte of data to the client. While a lower TTFB is generally desirable, it’s not always the best indicator of overall website performance. In this blog post, we will explore the relationship between TTFB and PHP output buffering, and discuss how optimizing for a low TTFB can sometimes be misleading.

TTFB and PHP Output Buffering

TTFB can be influenced by various factors, such as network latency, server processing time, and PHP output buffering. PHP output buffering is a technique where the server buffers the output of a script before sending it to the client. This can help improve performance by allowing the server to send larger chunks of data at once, rather than sending small bits of data as they become available. Additionally, output buffering can be beneficial when running a site built with plugins from various developers, such as is common with WordPress. In these situations, different plugins may send headers at different times, and without output buffering, this can cause errors as the server is only allowed to return response headers once.

However, focusing on a low TTFB can lead to a false sense of optimization. For example, you can artificially deflate TTFB by sending a single byte of data immediately before doing any significant processing and flushing the output buffer. This will result in a lower TTFB, but the overall load time for the user remains the same. In other words, a low TTFB doesn’t always equate to a better user experience.

Continue reading “Understanding TTFB: Why Lower TTFB Isn’t Always Better”