How the ping test works

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

  1. Does your domain has an MX record defined?
  2. Does this MX record point to the correct smtp receiving server defined?
  3. 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
  4. 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)
  5. Have you checked that the host name is configured on your receivers side MTA correctly?
  6. Does the host name match in your MTA configuration with the host name defined under your MX record for your domain?
  7. 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.
  8. 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
  9. 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
  10. 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.

See also


FAQ/HowThePingTestWorks (last edited 2016-05-06 16:51:22 by AlesKastner)