The great web developer con

Another day, another dodgy web developer story. The premise:

We would like to offer you a website design for X amount. But to do so, we need to transfer your domain to us.

This tale is a pretty old one but it appears to be flourishing – the lure of a good once-off price for the design and what appears to be a reasonable monthly charge lead many to take up offers like these. But are these actually good offers? Let’s dissect this …

The web developer (let’s call them web devs from now on) is offering 2 products here:

  • website design
  • website hosting

The first is up to the client to determine whether they are getting reasonable value.

The 2nd is where we run into trouble, and for a number of reasons:

  1. web development is the core focus for web developers; web hosting is not
  2. many web development companies either subcontract the hosting to someone else or do it themselves with cheap shared hosting systems and then markup the cost to the client
  3. web devs are not skilled nor have experience with hosting – any issues and you are on your own
  4. run-of-the-mill web devs have little to no security skills
    • the platforms they use may be unsecured or have vulnerabilities
    • they do not offer an update service for your site or plugins
    • they do not scan your website for security issues
  5. web devs often have no care for email but will transfer your domain nonetheless leaving your email in limbo
  6. web devs do not understand site backup and recovery so if you have an issue with your site and need to restore it to a previous copy, you may be in trouble
  7. some web devs lock you into contracts – if you aren’t happy with their hosting, you just have to grin and bear it

Unfortunately, many clients don’t understand the relationship between web development and hosting, the 2 being very different things. They sound the same but have 2 very different skills requirements, with the latter skills requirement being something that web devs generally do not have.

As an example, if a web dev transfers your domain, they may not do the email hosting at all, or if they do, they may not migrate existing email from your old hosting provider. This leaves you managing, and paying for, 2 disparate systems.

Some web devs even go so far as to offer free web hosting. You get what your pay (or don’t pay) for.

The core premise of the requirement to transfer your domain is false. There is generally no specific requirement to move your domain – the web dev can design your website and place it with your existing hosting provider.

You then retain your website and email hosting as is, and save on hosting charges (as would have been paid to the web dev had you moved the domain).

Be careful and circumspect when approached by web devs who want to transfer your domain – it’s generally not required, you’ll likely get a poor and insecure service, and you’ll end up paying more.

Here follows some more reading on the subject:

DMARC: optimising email delivery

Email is a fickle thing …

There are a huge amount of dependencies involved in what seems like a small task – sending an email. What started out as a simple method of exchanging messages has morphed over the years into a cobbled-together monster as needs changed and especially businesses required a more robust and featureful method for exchanging information. Approximately 250 billion emails are sent each day of which around 10-15% are genuine so email is still heavily utilised.

Note only does email have to deal with the underlying ephemeral infrastructure of the internet, but it also has to deal with spam, blacklisting, bad MIME implementations and flaky email servers.

Email delivery is not guaranteed, no matter how much we would like it to be. But we can improve things to the point where email delivery, in- and outbound, will have a higher chance of delivery.

A number of frameworks have been introduced in recent years to provide authentication/identification of email:

  • sender policy framework (SPF) – check if a server is authorised to send email for a domain
  • domain keys identified email (DKIM) – check if emails from a specific domain are authorised using sigital signatures
  • domain message authentication, reporting and compliance (DMARC) – protect domains from email spoofing (this is basically an extension/combination of SPF and DKIM)

These frameworks work to detect domain or email address spoofing attacks. Domains that have published records for these methods are essentially trusted more than domains that do not have these records. In addition, the signature verification method of DKIM means that a domain signature can’t be spoofed. In the combined method, DMARC, organisations have a strong and proven method for protecting their email domains.

So how do these methods work?

SPF

A DNS record of type TXT or SPF is added for the domain in question, and any IP addresses, hostnames or other domains that should be authorised to send email for the domain, are added to this record. When someone receives email indicated as being from your domain, the recipient server can check if the sender server is authorised. There are 3 actions that the recipient server can take:

  • PASS – the email is sent on without adjustment
  • FAIL – the email is blocked
  • SOFTFAIL – the email is accepted but tagged as having failed the check

DKIM

A digital signature (PKI) is added to a DNS TXT record for the domain in question and emails from this domain have the DKIM-Signature header appended. Recipient systems then check this signature header against the one published in the DNS record to confirm its authenticity.

DMARC

Policies are generated and stored in DNS TXT records. These records check if the FROM: field is aligned with SPF or DKIM. Alignment can be strict or relaxed.

In conclusion, and using the above methods, one can prevent their domain from being used in email spoofing attacks; as well, you can also verify senders of email as being authentic. The basis for these checks and preventions are the ownership of a domain by the organisation in question – if you own your domain, only you can add the necessary records to implement these frameworks. In doing so, you are assumed to have a higher trust than others, and there is a better chance of your emails being received.

Anti-spam solutions also take SPF/DKIM/DMARC headers into account when scoring emails for spam, generally adding a negative value to the score thereby improving the chances of delivery and non-tagging as spam.

These frameworks are designed to improve email delivery and in general, they succeed quite well. Make sure you are using 1 or more of these methods with your email domains.