One place for hosting & domains

      Domain

      How to Choose the Right Domain Name


      Which is harder: Naming your kid or choosing a domain? 

      Sure, your bambino is stuck with the moniker you choose until they can get a judge to change it, but you won’t need to reinvent the wheel to come up with something to call them. You can look to historical figures, literary characters, or even your favorite TV show for inspiration. 

      However, when it comes to a domain, you’ve got to make sure your digital baby is truly unique. No repeats allowed.

      So what makes a good domain name? 

      Generally speaking, you’ll want something memorable, brandable, and easy for people to type and pronounce. It’s also smart to avoid anything too long or overly specific. By following a few simple guidelines, you can pick out a name that helps to drive more traffic your way. 

      In this guide, I’ll explain why your domain name matters and share 11 factors to consider when making this decision. I’ll also discuss the best places to register a domain and how you can get a free one along with your web hosting. Let’s get started!

      Your Great Idea Starts with a Domain Name

      Don’t let someone else register your dream URL. Search DreamHost’s 400+ TLDs to find the perfect match for your website.

      Why Your Domain Name Matters

      Your domain name is as much a part of your brand as your business name or logo. Even if you’ve nailed your branding in every other respect, if there’s something about your domain name that puts potential customers off, they’ll likely go elsewhere.

      The opposite is also true. If your web address is accurate and as fun to say as it is to use, people will be eager to check it out and share it. First impressions matter, and sometimes your domain is the initial experience people will have of your brand. 

      It’s also not easy to change your domain name after your site is online. You can do it, but it can be time-consuming and does have consequences. It can lead to a loss of traffic and unnecessary downtime. In other words, life will be a lot easier if you take your time now and come up with a name you love.

      11 Important Factors to Consider When Choosing a Domain Name

      As with most big business decisions, you’ll find plenty of opinions about how to select the right domain name. To make it easier, let’s take a look at eleven key points to consider.

      1. Choose Your Top-Level Domain Extension Carefully

      A Top Level Domain (TLD) is the piece of your domain that comes after the site’s name. The most common TLDs are .com, .net, and .org.

      There are plenty of newer TLD options, but it’s usually best to keep it old school and stick to .com if possible. It’s been around the longest and is the most popular, so people are very familiar with it.

      Of course, it’s possible you won’t be able to secure a decent domain name with a .com TLD since many are already taken. However, it’s not the end of the world if you have to use an alternative.

      Alternative TLD options.

      You’ll find tons of available options that can add personality to your web address. Just make sure that whatever you select makes sense for your website and audience.

      2. Incorporate Keywords Strategically

      Keywords aren’t just for content. Search engines use your domain name to understand what your site is about and help determine search rankings. So it’s essential to include keywords where possible. 

      The keywords you choose for your domain name should be relevant to your website. It’s much more important to represent your content accurately than to add keywords for their own sake. If you’re stuck for ideas, you can give Google Keyword Planner a try.

      The Google Keyword Planner home page.

      This free tool lets you explore keywords by search volume and other factors to identify terms people actually use. Don’t get too carried away, though. Using too many keywords, especially popular ones, can make your site seem boring and maybe even a little untrustworthy.

      3. Make Sure Your Domain Is Easy to Pronounce and Spell

      You probably want your domain name to be memorable. However, if you’re thinking of going the Elon Musk baby-naming route, don’t. No matter how cool it looks spelled out, there will come a time when you’ll have to give someone your website or email address verbally.

      Word-of-mouth is still powerful advertising. What’s more, it only works when people can actually pronounce your domain. This also makes the name easier to remember, increasing the odds that people will visit and pass the site along to their networks.

      4. Avoid Hyphens

      Using hyphens may seem like a creative way to get the domain name you want. Unfortunately, they’re tough to express verbally. They also make the domain more difficult to type. Some people will likely forget about them entirely and end up on someone else’s website.

      Generally, when you’re brainstorming domain name ideas, try to avoid anything that isn’t a letter. That includes replacing letters with numbers. Those kinds of touches make the name a lot easier for people to misremember and mistype.

      5. Avoid Using Doubled Letters

      Using doubled letters in a domain name is practically asking for typos. Doubled letters are hard to read and even harder to type correctly.

      If mistakes happen often enough, you may end up with someone typosquatting and stealing your traffic. Plus, having to spend even a few seconds longer than necessary trying to figure out how to spell your domain is an unnecessary distraction.

      6. Keep Your Domain Name Short

      There are several reasons short domain names work better. First, shorter names are easier to remember and type. Therefore, they are beneficial for branding purposes.

      Also, an overly long domain name is yet another way to look suspicious. If you don’t use too many keywords and make your name easy to pronounce, on the other hand, your domain will probably be short naturally.

      7. Stay Unique and Brandable

      A unique domain name can help your business stand out and potentially help you avoid legal trouble. It can also contribute to your marketing efforts, so you’ll want it to be brandable. 

      StitchFix is an excellent example of a unique, brandable name.

      The StitchFix homepage.

      StitchFix checks all the boxes when it comes to marketable domain names. It’s fun to say, doesn’t have any inherent meaning, and is easy to remember and spell.

      8. Pick a Domain Name That’s Flexible

      Your domain name is one area where you don’t want to paint yourself into a box. While you should be specific enough to attract an audience, you don’t want to be so precise that there’s no room for your website to grow. 

      For example, “shutter.photography” might be perfect for a photography blog. However, if you decide to write about other art forms as well, you’ll be stuck with an inaccurate domain name. So it’s smart to consider upfront how your site or business may expand over time.

      9. Do Your Domain Name Research

      Once you’ve narrowed your search down to a few candidates, you can use a research tool to determine if it’s available.

      DreamHost’s domain name research tool.

      However, just because the domain name is available doesn’t mean someone else doesn’t have a valid claim to it. To be safe, you’ll want to perform a trademark search before making your choice.

      It’s also best to make sure you can secure appropriate social media handles. If you can’t get an exact match, try finding something that makes sense with your domain name.

      10. Don’t Get Analysis Paralysis

      Chances are that if you want a domain name, someone else probably wants it too. If you’re sure about your choice, go ahead and buy the domain.

      This is especially recommended if it’s reasonably inexpensive. Plus, if you come up with something better later on, you can always let the registration lapse. You don’t want to end up in a dispute because you didn’t act fast.

      11. Protect Your Brand With Multiple Domains

      Have you ever heard: “If the shoe fits, buy it in every color?” Well, if the domain name fits, buy it in every TLD.

      Even if you manage to snag a coveted .com address, you might consider purchasing other options and setting up redirects. You can even go a step further and buy common misspellings of your domain name.

      Additional domain name suggestions using different TLDs.

      This is a smart strategy to apply to social media as well. Even if you don’t think you’ll use Twitter, you might want to grab a decent handle if one is available. You’ll be ready if you ever decide to tweet, and you’ll prevent anyone else from taking that username.

      Picking the Best Place to Register Your Domain

      Once you’ve picked out a domain name, you need to choose a domain registrar, which is the company where you’ll purchase it. When shopping around for a registrar, here are a few things to keep an eye on:

      • Domain transfers. Check out the registrar’s transfer policy. If it’s complicated or expensive, keep looking.
      • Pricing. Some companies offer lower prices for the first year and then increase them when it’s time for renewal. You may even be locked into a multi-year contract.
      • Expiration policy. You don’t buy a domain so much as rent it. If you forget to renew the lease, someone else can take it from you. Look for a registrar that offers automatic renewals and a grace period.
      • Domain privacy protection. As a website owner, you’re required to add your personal information to a public database. Domain privacy protection hides your primary contact information to help keep your identity secure.
      • Subdomains. You don’t have to register subdomains separately. However, you’ll want to ensure that your registrar makes it easy to add subdomains to your site.

      There are plenty of registrars you can use. However, sometimes it makes sense to register your domain through your hosting provider.

      How to Get a Free Domain With Your Web Hosting

      Some web hosts offer a free domain name when you sign up for a hosting plan. You may have to pay for renewal at the end of the first year, but it’s not typically expensive. You also won’t have to worry about migrating your domain if you register it through your hosting provider.

      At DreamHost, we offer a free domain name when you sign up for one of our Shared or DreamPress hosting plans. Once you’ve selected the right option for you, just click on Register a new domain.

      DreamHost’s free domain with annual web hosting.

      You’ll be prompted to search for your desired domain name. Simply add your domain to your cart and complete the checkout process!

      So Many Potential Domain Names . . .

      There’s a lot to think about when choosing a domain name. After all, it’s one of the first major decisions you’ll make when establishing your online presence. Putting some time and care into this selection can help set the stage for success down the road.

      Fortunately, there’s lots of information you can rely on to help you make your choice. Keeping your domain name short, pronounceable, and easy to remember will get you off to a strong start. Once you have a name in mind, you can follow our suggestions for choosing a registrar and getting a free domain with your web hosting provider.

      Have you settled on the perfect domain name for your website? Get a free private domain registration when you sign up with DreamHost!



      Source link

      Apache Configuration Error AH00558: Could not reliably determine the server’s fully qualified domain name



      Part of the Series:
      Common Apache Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.

      Introduction

      An Apache AH00558: Could not reliably determine the server's fully qualified domain name message is generated when Apache is not configured with a global ServerName directive. The message is mainly for informational purposes, and an AH00558 error will not prevent Apache from running correctly.

      In this tutorial you will learn how to detect an AH00558 message using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set a ServerName directive to resolve the message.

      If you have already determined that your Apache server is affected by an AH00558 message and you would like to skip the troubleshooting steps, the Setting a Global ServerName Directive step at the end of this tutorial explains how to resolve the message.

      Troubleshooting Using systemctl

      The first step when you are troubleshooting an AH00558: Could not reliably determine the server's fully qualified domain name message is to check Apache’s status using systemctl. The output from systemctl will in many cases contain all the information that you need to resolve the message.

      On Ubuntu and Debian-derived Linux distributions, run the following to check Apache’s status:

      Ubuntu and Debian Systems

      • sudo systemctl status apache2.service -l --no-pager

      On CentOS Fedora, and RedHat-derived systems, use this command to examine Apache’s status:

      CentOS and Fedora Systems

      • sudo systemctl status httpd.service -l --no-pager

      The -l flag will ensure that systemctl outputs the entire contents of a line, instead of substituting in ellipses () for long lines. The --no-pager flag will output the entire log to your screen without invoking a tool like less that only shows a screen of content at a time.

      You should receive output that is similar to the following:

      Output

      ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Wed 2020-07-29 14:30:03 UTC; 33min ago Process: 34 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS) Main PID: 46 (apache2) Tasks: 55 (limit: 2344) CGroup: /system.slice/apache2.service ├─46 /usr/sbin/apache2 -k start ├─47 /usr/sbin/apache2 -k start └─48 /usr/sbin/apache2 -k start Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server... Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.

      The highlighted line that contains the AH00558 message is the important one. Essentially, it informs you that Apache couldn’t find a valid ServerName directive in its configuration file, so it will use the first IP address it detects. In this example, it’s the server’s public IP address: 172.17.02. If you are troubleshooting an AH00558 message, the IP address that is detected may be different, or it may be a human readable DNS name.

      If your systemctl output contains an auto-detected value of any IP address or hostname, skip to the last section of this tutorial, Setting a Global ServerName Directive to resolve the issue. In that section you will configure Apache with a safe default ServerName value using the IP address for localhost: 127.0.0.1.

      If your systemctl output does not indicate a value that you can use for the ServerName directive, the next section of this tutorial explains how to examine the systemd logs using journalctl to locate an AH00558 message.

      Troubleshooting Using journalctl

      To examine the systemd logs for Apache you will use the journalctl command. When invoking journalctl, there are two specific flags that will help you locate specific messages if there is a large volume of log entries.

      The first flag that you will add to the journalctl invocation is the --since today flag. It will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors.

      The second flag that you will use is the same --no-pager option that you used with systemctl, which will output the entire log to your screen at once.

      On Ubuntu and Debian-derived systems, run the following command:

      • sudo journalctl -u apache2.service --since today --no-pager

      On CentOS, Fedora, and RedHat-derived systems, use this command to inspect the logs:

      • sudo journalctl -u httpd.service --since today --no-pager

      If your Apache server is generating an AH00558 message, look through the journalctl command output for lines like the following:

      Output

      -- Logs begin at Wed 2020-07-29 14:30:02 UTC, end at Wed 2020-07-29 14:45:03 UTC. -- . . . Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server... Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.

      The second line of output is the AH00558 message. The line includes the server’s public IP address, which is the address that Apache automatically detects and sets as a default at runtime. With this message as confirmation of an AH00558 error, you can proceed to the Setting a Global ServerName Directive to resolve the issue.

      Otherwise, the next section explains how to diagnose an AH00558 error message using the apachectl command.

      Troubleshooting using apachectl

      An AH00558: Could not reliably determine the server's fully qualified domain name error can be detected using Apache’s apachectl utility. With apachectl you can catch messages like these before reloading or restarting Apache, and you can avoid having to search through systemctl and journalctl logs to locate errors.

      To check your Apache configuration for an AH00558 message, run the following command:

      • sudo apachectl configtest

      You should receive output like the following if your server is affected by an AH00558 error message:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message Syntax OK

      As with the previous sections in this tutorial that used systemctl and journalctl to locate AH00558 messages, the line that contains the AH00558 message, highlighted in the previous example, is the important one. Again note that the IP address 172.17.0.2 in this example may be different on your server.

      The next section of this tutorial explains how to set the ServerName directive to resolve AH00558 error messages.

      Setting a Global ServerName Directive

      To resolve an AH00558: Could not reliably determine the server's fully qualified domain name error message, you will need to add a ServerName directive to your Apache configuration. Apache uses the ServerName directive to map incoming HTTP requests to an IP address or DNS hostname using VirtualHost directives in order to handle requests for multiple sites using a single server.

      The error message notes that a global ServerName directive should also be set. Doing so will ensure that Apache can gracefully handle incoming requests that do not map to a VirtualHost without generating additional errors.

      For maximum compatibility with various Apache configurations, use the value of 127.0.0.1 for your global ServerName directive. You can use a different IP address or DNS name that corresponds to your server’s configuration if you need to, but it is safest to use 127.0.0.1.

      On Ubuntu and Debian-derived systems, open the /etc/apache2/apache2.conf file with root privileges using nano or your preferred text editor:

      • sudo nano /etc/apache2/apache2.conf

      Add a line containing ServerName 127.0.0.1 to the end of the file:

      /etc/apache2/apache2.conf

      . . .
      # Include the virtual host configurations:
      IncludeOptional sites-enabled/*.conf
      
      # vim: syntax=apache ts=4 sw=4 sts=4 sr noet
      ServerName 127.0.0.1
      

      On CentOS, Fedora, and RedHat-derived systems, open the /etc/httpd/conf/httpd.conf file with root privileges using nano or your preferred text editor:

      • sudo nano /etc/httpd/conf/httpd.conf

      Add the ServerName 127.0.0.1 line to the end of the file:

      /etc/httpd/conf/httpd.conf

      . . .
      # Supplemental configuration
      #
      # Load config files in the "/etc/httpd/conf.d" directory, if any.
      IncludeOptional conf.d/*.conf
      ServerName 127.0.0.1
      

      Save and close the file when you are finished. If you used nano, do so by pressing CTRL + X, Y, and then ENTER.

      Once you have added the ServerName directive to your configuration, run apachectl to test that the configuration is valid.

      • sudo apachectl configtest

      A successful apachectl configtest invocation should result in output like this:

      Output

      Syntax OK

      You can now restart Apache using the appropriate systemctl restart command for your Linux distribution.

      On Ubuntu and Debian-derived systems, run the following:

      • sudo systemctl restart apache2.service

      On CentOS, Fedora, and RedHat-derived systems use this command to restart Apache:

      • sudo systemctl restart httpd.service

      After you restart Apache, the AH00558 error message will no longer appear in your logs. You can confirm the messages are silenced by running any of the three systemctl, journalctl, or apachectl commands that are demonstrated in this tutorial.

      Conclusion

      In this tutorial you learned about AH00558: Could not reliably determine the server's fully qualified domain name error messages. While these messages do not prevent Apache from running, they can be resolved by setting a global ServerName directive.

      You learned how to search for AH00558 error messages using the systemctl, journalctl, and apachectl commands. Finally, you learned how to edit your Apache configuration on various Linux distributions to silence the messages.

      If you would like to learn more about how Apache uses ServerName directives, the Apache documentation about Name-Based Virtual Hosts explains the directive in more detail.



      Source link

      How To Configure MTA-STS and TLS Reporting for Your Domain Using Apache on Ubuntu 18.04


      The author selected Electronic Frontier Foundation Inc to receive a donation as part of the Write for DOnations program.

      Introduction

      Mail Transport Agent Strict Transport Security (MTA-STS) is a new internet standard that allows you to enable strict force-TLS for email sent between supported email providers. It is similar to HTTP Strict Transport Security (HSTS), where a force-TLS policy is set and then cached for a specified amount of time, reducing the risk of man-in-the-middle or downgrade attacks.

      MTA-STS is complemented by SMTP TLS Reporting (TLSRPT), which gives you insight into which emails are successfully delivered over TLS, and which aren’t. TLSRPT is similar to DMARC reporting, but for TLS.

      The primary reason for implementing MTA-STS for your domain is to ensure that confidential email that is sent to you is transmitted securely over TLS. Other methods for requiring TLS for email communications are still susceptible to man-in-the-middle attacks, as the initial connection is unencrypted. MTA-STS ensures that the initial incoming connection is using TLS by default, which greatly reduces the risk of these attacks.

      An example use case for MTA-STS and TLS Reporting is to help create a secure customer service email system for your business. Customers may send support tickets via email that contain confidential personal information, which needs a secure TLS connection. MTA-STS provides that secure connection, and TLSRPT will deliver daily reports identifying any emails that weren’t sent securely—giving crucial insight into any ongoing or previous attacks against your email system.

      In this tutorial, you will learn how to configure MTA-STS and TLSRPT for your domain name, and then interpret your first TLS Report. While this tutorial covers the steps for using Apache on Ubuntu 18.04 with a Let’s Encrypt certificate, the MTA-STS/TLSRPT configuration will also work on alternatives, such as Nginx on Debian.

      Prerequisites

      Before you begin this guide, you’ll need:

      Once you have these ready, log in to your server as your non-root user to begin.

      Note: Once you have completed the implementation steps for MTA-STS and TLSRPT, you may have to wait up to 24 hours to receive your first TLS Report. This is because most email providers send reports once per day. You may resume the tutorial from Step 5 once you’ve received your first report.

      Step 1 — Creating an MTA-STS Policy File

      MTA-STS is enabled and configured using a plain text configuration file that you host on your website. Supported mail servers will then automatically connect to your website to retrieve the file, which causes MTA-STS to be enabled. In this first step you’ll understand the available options for this file and choose the most appropriate for your file.

      Firstly, open a new text file in your home directory so that you have somewhere to write down your desired configuration:

      We will first go over an example, and then you will write your own configuration file.

      Following is an example of an MTA-STS configuration file:

      Example MTA-STS Configuration File

      version: STSv1
      mode: enforce
      mx: mail1.your-domain
      mx: mail2.your-domain
      max_age: 604800
      

      This example configuration file specifies that all email delivered to mail1.your-domain and mail2.your-domain from supported providers must be delivered over a valid TLS connection. If a valid TLS connection cannot be established with your mail server (for example, if the certificate has expired or is self-signed), the email will not be delivered.

      This will make it much more challenging for an attacker to intercept and snoop on/modify your email in a situation like a man-in-the-middle attack. This is because having MTA-STS enabled properly only allows email to be transmitted over a valid TLS connection, which requires a valid TLS certificate. It would be hard for an attacker to acquire such a certificate, as doing so usually requires privileged access to your domain name and/or website.

      As shown in the example earlier in this step, the configuration file consists of a number of key/value pairs:

      • version:

        • Purpose: To specify the version of the MTA-STS specification to use.
        • Accepted Values: Currently the only accepted value is STSv1.
        • Example: version: STSv1
      • mode:

        • Purpose: Specify which mode MTA-STS should be enabled in.
        • Accepted Values:
          • enforce: Force all incoming email from supported providers to use valid TLS.
          • testing: Report-only mode. email will not be blocked, but TLSRPT reports are still sent.
          • none: Disable MTA-STS.
        • Example: mode: enforce
      • mx:

        • Purpose: To specify which mail servers are allowed to handle email for your domain. This should match the servers specified in your mx records.
        • Accepted Values: Fully-qualified domain name of a mail server, or a wildcard host. Multiple mx: values must be used to specify multiple mail servers.
        • Example: mx: mail1.your-domain, mx: mail2.your-domain, mx: *.example.org
      • max_age:

        • Purpose: To specify the maximum lifetime of the MTA-STS policy, in seconds.
        • Accepted Values: Any positive integer up to 31557600.
        • Example: max_age: 604800 (1 week)

      You can also view the official specification for the key/value pairs in Section 3.2 of the MTA-STS RFC.

      Warning: Enabling MTA-STS in enforce mode could unexpectedly cause some email not to be delivered to you. Instead, it is recommended to use mode: testing and a low max_age: value at first, in order to ensure that everything is working correctly before turning on MTA-STS fully.

      Using the example file earlier in the step, as well as the preceding key/value pair examples, write your desired MTA-STS policy file and save it to the file that you created at the start of the step.

      The following example file is ideal for testing MTA-STS, as it will not cause any emails to be unexpectedly blocked, and has a max_age of only 1 day, meaning that if you decide to disable it, the configuration will expire quickly. Note that some email providers will only send TLSRPT reports if the max_age is greater than 1 day, which is why 86401 seconds is a good choice (1 day and 1 second).

      Example Test MTA-STS Configuration File

      version: STSv1
      mode: testing
      mx: mail1.your-domain
      mx: mail2.your-domain
      max_age: 86401
      

      In this step you created your desired MTA-STS configuration file and saved it to your home area. In the next step, you will configure an Apache web server to serve the file in the correct format.

      Step 2 — Configuring Apache to Serve Your MTA-STS Policy File

      In this step, you’ll configure an Apache virtual host to serve your MTA-STS configuration file, and then add a DNS record to allow the site to be accessed from a subdomain.

      In order for your MTA-STS configuration file to be automatically discovered by mail servers, it must be served at exactly the right path: https://mta-sts.your-domain/.well-known/mta-sts.txt. You must use the mta-sts subdomain over HTTPS and the /.well-known/mta-sts.txt path, otherwise your configuration will not work.

      This can be achieved by creating a new Apache virtual host for the mta-sts subdomain, which will serve the MTA-STS policy file. This step builds upon the base configuration that you’ll have set up in the prerequisite step How to Install the Apache Web Server on Ubuntu 18.04.

      Firstly, create a directory for your virtual host:

      • sudo mkdir /var/www/mta-sts

      If you’re hosting multiple different domains on your web server, it is recommended to use a different MTA-STS virtual host for each, for example /var/www/mta-sts-site1 and /var/www/mta-sts-site2.

      Next, you need to create the .well-known directory, which is where your MTA-STS configuration file will be stored. .well-known is a standardized directory for ‘well-known’ files, such as TLS certificate validation files, security.txt, and more.

      • sudo mkdir /var/www/mta-sts/.well-known

      Now you can move the MTA-STS policy file that you created in Step 1 into the web server directory that you just created:

      • sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

      You can check that the file was copied correctly if you wish:

      • cat /var/www/mta-sts/.well-known/mta-sts.txt

      This will output the contents of the file that you created in Step 1.

      In order for Apache to serve the file, you’ll need to configure the new virtual host and enable it. MTA-STS only works over HTTPS, so you’ll use port 443 (HTTPS) exclusively, rather than using port 80 (HTTP) as well.

      Firstly, create a new virtual host configuration file:

      • sudo nano /etc/apache2/sites-available/mta-sts.conf

      Like with the virtual host directory, if you are hosting multiple different domains on the same web server, it is recommended to use a different virtual host name for each.

      Then, copy the following sample configuration into the file, and populate the variables where required:

      ~/etc/apache2/sites-available/mta-sts.conf

      <IfModule mod_ssl.c>
      <VirtualHost your-server-ipv4-address:443 [your-server-ipv6-address]:443>
          ServerName mta-sts.your-domain
          DocumentRoot /var/www/mta-sts
      
          ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href="https://your-domain" rel="noopener">https://your-domain</a> instead."
      
          RewriteEngine On
          RewriteOptions IgnoreInherit
          RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]
      
          SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
          SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
          Include /etc/letsencrypt/options-ssl-apache.conf
      </VirtualHost>
      </IfModule>
      

      This configuration will create the mta-sts virtual host, which will be served at mta-sts.your-domain. It will also redirect all requests, except for those to the mta-sts.txt file itself, to a custom 403 Forbidden error page, with a friendly explanation of what the subdomain site is for. This is to help ensure that any visitors who accidentally come across your MTA-STS site aren’t inadvertently confused.

      Currently, a self-signed TLS certificate is used. This is not ideal, as a fully valid/trusted certificate is required for MTA-STS to work correctly. In Step 3, you will acquire a TLS certificate using Let’s Encrypt.

      Next, ensure that the required Apache modules are enabled:

      After that, enable the new virtual host:

      Then, run a syntax check of the Apache configuration files, to ensure that there aren’t any unexpected errors:

      • sudo apachectl configtest

      When the test passes with no errors, you can restart Apache to fully enable the new virtual host:

      • sudo service apache2 restart

      Now that the Apache virtual host has been set up and configured, you need to create the required DNS record(s) to allow it to be accessed using the fully-qualified domain name mta-sts.your-domain.

      The way that this is done depends on the DNS hosting provider that you use. However, if you use DigitalOcean as your DNS provider, simply navigate to your project, followed by clicking on your domain.

      Finally, add the required DNS records for the mta-sts subdomain. If your Droplet only uses IPv4, create an A record for mta-sts, pointing to your-server-ipv4-address. If you use IPv6 as well, create an AAAA record pointing to your-server-ipv6-address.

      A screenshot of the DigitalOcean DNS control panel, showing an example DNS record for mta-sts pointing to an IPv4 address.

      In this step, you created and configured a new Apache virtual host for your MTA-STS subdomain, then added the required DNS record(s) to allow it to be accessed easily. In the next step, you will acquire a trusted Let’s Encrypt certificate for your MTA-STS subdomain.

      Step 3 — Acquiring a Let’s Encrypt Certificate for Your MTA-STS Subdomain

      In this step, you’ll acquire a TLS certificate from Let’s Encrypt, to allow your mta-sts.your-domain site to be served correctly over HTTPS.

      In order to do this, you’ll use certbot, which you set up as part of the prerequisite step How To Secure Apache with Let’s Encrypt on Ubuntu 18.04.

      Firstly, run certbot to issue a certificate for your mta-sts subdomain using the Apache plugin verification method:

      • sudo certbot --apache -d mta-sts.your-domain

      This will automatically issue a trusted certificate and install it on your Apache web server. When the Certbot wizard asks about configuring a HTTP -> HTTPS redirect, select 'No’, as this is not required for MTA-STS.

      To finish, test your new virtual host to ensure that it is working correctly. Use a web browser to visit https://mta-sts.your-domain/.well-known/mta-sts.txt, or use a command-line tool such as curl:

      • curl https://mta-sts.your-domain/.well-known/mta-sts.txt

      This will output the MTA-STS policy file that you created in Step 1:

      Output

      version: STSv1 mode: testing mx: mail1.your-domain mx: mail2.your-domain max_age: 86401

      If an error occurs, ensure that the virtual host configuration from Step 2 is correct, and that you have added a DNS record for the mta-sts subdomain.

      In this step, you issued a Let’s Encrypt TLS certificate for your mta-sts subdomain, and tested that it’s working. Next, you’ll set some DNS TXT records to fully enable MTA-STS and TLSRPT.

      Step 4 — Configuring the DNS Records Required to Enable MTA-STS and TLSRPT

      In this step, you’ll configure two DNS TXT records, which will fully enable the MTA-STS policy that you have already created, and also enable TLS Reporting (TLSRPT).

      These DNS records can be configured using any DNS hosting provider, but in this example, DigitalOcean is used as the provider.

      Firstly, log on to your DigitalOcean control panel and navigate to your project, followed by clicking on your domain.

      You then need to add the following two TXT records:

      _mta-sts.your-domain IN TXT "v=STSv1; id=id-value"
      _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=reporting-address"
      

      id-value is a string used to identify the version of your MTA-STS policy in place. If you update your policy, you’ll need to also update the id value to ensure that the new version is detected by mail providers. It is recommended to use the current date stamp as the id, for example 20190811231231 (23:12:31 on 11th Aug 2019).

      reporting-address is the address where your TLS reports will be sent to. This can be either an email address prefixed with mailto:, or a web URI, for example for an API that collects reports. The reporting address doesn’t have to be an address on your-domain. You may use a completely different domain if you wish.

      For example, the following two sample records are both valid:

      _mta-sts.your-domain IN TXT "v=STSv1; id=20190811231231"
      _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@your-domain"
      

      Adjust the variables as required, and set these DNS TXT records in your DigitalOcean control panel (or whichever DNS provider you’re using):

      A screenshot of the DigitalOcean control panel, showing the _mta-sts DNS TXT record being set.

      A screenshot of the DigitalOcean control panel, showing the _smtp._tls DNS TXT record being set.

      Once these DNS records have been set and have propagated, MTA-STS will be enabled with the policy that you created in Step 1, and will begin to receive TLSRPT reports at the address that you specified.

      In this step, you configured the DNS records required for MTA-STS to be enabled. Next, you will receive and then interpret your first TLSRPT report.

      Step 5 — Interpreting Your First TLSRPT Report

      Now that you’ve enabled MTA-STS and TLSRPT (TLS Reporting) for your domain, you will begin to receive reports from supported email providers. These reports will show the number of emails that were or were not successfully delivered over TLS, and the reasons for any errors.

      Different email providers send their reports at different times; for example, Google Mail sends their reports daily at around 10:00 UTC.

      Depending on how you configured the TLSRPT DNS record in Step 5, you will either receive your reports via email, or via a web API. This tutorial focuses on the email method, as that is the most common configuration.

      If you’ve just completed the rest of this tutorial, wait until you receive your first report, then you can resume.

      Your daily TLSRPT report via email will usually have a subject line similar to the following:

      Report Domain: your-domain Submitter: google.com Report-ID: <2019.08.10T00.00.00Z+your-domain@google.com>
      

      This email will have an attachment in .gz format, which is a Gzip compressed archive, with a file name similar to the following:

      google.com!your-domain!1565222400!1565308799!001.json.gz
      

      For the rest of this tutorial this file will be referred to as report.json.gz.

      Save this file to your local machine, and extract it using whichever tool you prefer.

      If you’re using a Debian-based Linux system, you will be able to run the gzip -d command to decompress the archive:

      This will result in a JSON file called report.json.

      Next, you can view the report either directly as the raw JSON string, or use your favorite JSON prettifier to put it into a more readable format. In this example, jq will be used, but you could also use Python’s json.tool if you wish.

      Note: If you don’t have jq installed, you can install it using apt install jq. Or, for other operating systems use the necessary installation instructions from jq.

      This will output something similar to the following:

      Prettified report.json

      { "organization-name": "Google Inc.", "date-range": { "start-datetime": "2019-08-10T00:00:00Z", "end-datetime": "2019-08-10T23:59:59Z" }, "contact-info": "smtp-tls-reporting@google.com", "report-id": "2019-08-10T00:00:00Z_your-domain", "policies": [ { "policy": { "policy-type": "sts", "policy-string": [ "version: STSv1", "mode: testing", "mx: mail1.your-domain", "mx: mail2.your-domain", "max_age: 86401" ], "policy-domain": "your-domain" }, "summary": { "total-successful-session-count": 230, "total-failure-session-count": 0 } } ] }

      The report shows the provider that generated the report and the reporting period, as well as the MTA-STS policy that was applied. However, the main section that you’ll be interested in is summary, specifically the successful and failed session counts.

      This sample report shows that 230 emails were successfully delivered over TLS from the mail provider that generated the report, and 0 email deliveries failed to establish a proper TLS connection.

      In the event that there is a failure—for example, if a TLS certificate expires or there is an attacker on the network—the failure mode will be documented in the report. Some examples of failure modes are:

      • starttls-not-supported: If the receiving mail server doesn’t support STARTTLS.
      • certificate-expired: If a certificate has expired.
      • certificate-not-trusted: If a self-signed or other non-trusted certificate is used.

      In this final step, you received and then interpreted your first TLSRPT report.

      Conclusion

      In this article you set up and configured MTA-STS and TLS Reporting for your domain, and interpreted your first TLSRPT report.

      Once MTA-STS has been enabled and working stably for a while, it is recommended to adjust the policy, increasing the max_age value, and eventually switching it to enforce mode once you are sure that all email from supported providers is being delivered successfully over TLS.

      Finally, if you’d like to learn more about the MTA-STS and TLSRPT specifications, you can review the RFCs for both of them:



      Source link