How the ping test works

(This article is mainly valid for new accounts or new domains. E-mail ping test is also used for adding new email address to an existing account, see this article.)

The CAcert system uses two methods to build the list of possible email addresses for sending the ping test mail for the domain verifications:

Build the Email address list

  1. Whois email address lookup
    • Whois Lookup of email addresses searches the whois database for possible email addresses of registrant, tech-c and admin-c. If multiple Email addresses exists, it will be unified
  2. defaul set of email alias + testdomain
    • To the results of the Whois Lookup email address list, additional 5 default alias names at test domain will be added. The default alias names are:

      • Alias

        Service

        Reference

        root

        hostmaster

        DNS

        [RFC1033-RFC1035], [RFC2142]

        postmaster

        SMTP

        [RFC821], [RFC822]

        admin

        webmaster

        HTTP

        [RFC 2068] 

 Sample:  testdomain.tld

 Whois testdomain.tld
   will result in:   administrator@provider.tld

 So the resulting list to send ping test mails to will be:

  * administrator@provider.tld  -> address from the Whois lookup
  * root@testdomain.tld         -> 1st default alias
  * hostmaster@testdomain.tld   -> 2nd default alias 
  * postmaster@testdomain.tld   -> 3rd default alias
  * admin@testdomain.tld        -> 4th default alias
  * webmaster@testdomain.tld    -> 5th default alias

Users selection of one Email address to send the test ping email to

At least one of above email addresses _must_ be activated to succeed on the email ping test and to verify a domain. This means: an internet gateways MTA (MX record or A record for the domain) has to accept the delivery of a test ping email for the selected email alias (at least postmaster@ has to be in a good working order and active by internet RFC's).

The user now has to select one of these addresses build from the system, he will use for the CAcert system to send the test ping email to.

Additional Infos

Typical configuration problems on the receivers side

I did not receive the confirmation email; I use any public email server

(E. g. outlook.com, gmail.com)

  1. Does the DNS of your domain contain a proper MX record defined ?
  2. Does the DNS of your domain contain a txt record containing SPF with at least mx ?
    • Example: "v=spf1 mx ~all"
  3. Does your MX record point to a properly defined smtp server ?
  4. Does the public email server use greylisting ?
    • Retry sending email about 2-20 minutes later.
  5. Is the greylisting on that public email server misconfigured with the wrong response code 5.x.x instead of 4.x.x?
    • Greylisting has to answer with a 4.x.x smtp response code (temporarily not available, retry later)

(The owner of the public server is responsible for the remaining points 6-13 below.)

I did not receive the confirmation email; I use the cloud solution MS Office 365 Outlook

  1. Does the DNS of your domain include an MX record defined for Outlook 365 ?

    • Example: "<your_domain.TLD> MX preference = 10, mail exchanger = <your_domain-TLD>.mail.protection.outlook.com"

  2. Does the DNS of your domain include a txt record SPF containing include for Outlook 365 ?

    • Example: "v=spf1 ip4:<Your fixed IPv4 address in Internet> include:spf.protection.outlook.com -all"

  3. Does your MX record point to a properly defined smtp server Outlook 365 ?
  4. Does the MX record pointed smtp server Outlook 365 greylisting enabled ?
    • Retry sending email about 2-20 minutes later.

(Microsoft is responsible for the remaining points 5-13 below.)

I did not receive the confirmation email; I have my own email server

  1. Does the DNS of your domain include an MX record defined ?
  2. Does the DNS of your domain contain a txt record containing SPF with at least mx ?
    • Example: "v=spf1 mx ~all"
  3. Does this MX record point to the correctly defined smtp receiving server ?
  4. Has your e-mail server a fixed IP address in the public Internet ?
  5. Is the backward translation of that IP address equal to your e-mail server's FQDN ?
  6. Do you have greylisting enabled on your MX server ?
    • retry sending email about 2-5 minutes later, dependent on the retry interval set on your gateway server
  7. Is your enabled greylisting on receiving side misconfigured with the wrong response code 5.x.x instead of 4.x.x?
    • Greylisting has to answer with a 4.x.x smtp response code (temporarily not available, retry later)
  8. Have you checked that the host name is configured on your receivers side MTA correctly?
  9. Does the host name match in your MTA configuration with the host name defined under your MX record for your domain?
  10. Is the selected mail alias configured under your MTA configuration? and/or is the returns alias defined in your MTA configuration as acceptable receiver?

    • Mail loops back solution 

       Sample:  yoursubdomain.testdomain.tld

 Whois yoursubdomain.testdomain.tld  refers to Whois testdomain.tld
   will result in:   administrator@provider.tld
   administrator@provider.tld is not an option to you

 So the resulting list to send ping test mails to will be:

  * root@yoursubdomain.testdomain.tld         -> 1st default alias
  * hostmaster@yoursubdomain.testdomain.tld   -> 2nd default alias 
  * postmaster@yoursubdomain.testdomain.tld   -> 3rd default alias
  * admin@yoursubdomain.testdomain.tld        -> 4th default alias
  * webmaster@yoursubdomain.testdomain.tld    -> 5th default alias

  where an individual MX record is set for yoursubdomain.testdomain.tld

  Other email alias doesn't work.

  Solution: Create an email alias from the list above.
  11. Does exist a Whois record for your domain in question?
    • By default there exist no own whois records on subdomains
    • Then your choice is limited to the alias list of 5 "known" alias names (see above) 
      •  Sample:  yoursubdomain.testdomain.tld

 Whois yoursubdomain.testdomain.tld  refers to Whois testdomain.tld
   will result in:   administrator@provider.tld

 So the resulting list to send ping test mails to will be:

  * administrator@provider.tld                -> address from the Whois lookup
  * root@yoursubdomain.testdomain.tld         -> 1st default alias
  * hostmaster@yoursubdomain.testdomain.tld   -> 2nd default alias 
  * postmaster@yoursubdomain.testdomain.tld   -> 3rd default alias
  * admin@yoursubdomain.testdomain.tld        -> 4th default alias
  * webmaster@yoursubdomain.testdomain.tld    -> 5th default alias

  where an individual MX record is set for yoursubdomain.testdomain.tld
  12. Does your DNS has a link-locale IPv6-adress?

    • domain.tld has address <a.b.c.d> (IPv4 address)

    • domain.tld has IPv6 address fe80::224:21ff:fe21:aad5
    • ("fe80…"), this relates to an IPv4-localhost-adress (127.0.0.1). This address is unroutable.
    • CAcert uses IPv6 and cannot reach the link-locale IPv6 adress
    • increase of problem reports with misconfigured ipv6 dns definitions
      • error message: "Failed to make a connection to the mail server"
      • obvious "either fix ipv6 or disable it"
        • (from a users report) That appears to be the problem. stoping and restarting the interface solved the problem, Now all I have to do is work out why my IPv6 setup failed in the first place
    • Ask yourself the question: do you have IPv6 configured in your DNS setup?
    • If the answer is YES, please double check your IPv6 settings or follow the previous proposal
  13. Are you using DNSSEC?
    • One known problem is:
    • If the domain is listed at the registry level as being secured by DNSSEC, yet fails to include the required matching key(s) in the zone file for the domain itself. With a DNSSEC-enabled resolver like we are using at CAcert, such domains are totally unreachable, and for good reason: DNSSEC classifies such a misconfigured (or hacked?) domain as bogus.

    • The problem is if you do not use a DNSSSEC resolver yourself, you will not notice anything wrong. Only by validating the domain at a service like http://dnscheck.sidn.nl/ you will see this particular problem.

Using TLS 1.2 for the Ping email

CAcert installed the secure transfer protocol TLS 1.2 used also for Ping email since February 2019. This protocol allows to establish an encrypted connection for message transfers following the SMTP protocol. An encrypted connection can be successfully built, as long as the receiver's mail server also supports TLS 1.2 protocol (all public mail servers nowadays, RFC 5246). TLS 1.2 has less strict requiremens to peers as the previous versions of TLS protocol. So the Ping email passes, although the recipient's server refuses unsecured connections. Moreover, there is no need of strict check of the "well known" CA's roots on both sides of the transfer.

See also

FAQ/HowThePingTestWorks (last edited 2019-03-06 11:04:14 by AlesKastner)