("TestReceiver") looks forward at the receiving end of an Internet eMail transfer to test the software, server, or appliance that receives email. These include unix sendmail or a sendmail-like product (Postfix, Qmail), Microsoft Exchange, or a router or security device with email capability (Barracuda, Pix).
TestReceiver does not actually send an email. It just makes sure that if it did, the email would be secure.
TestReceiver outputs a Confidence Factor for the tested email address. The Confidence Factor is a zero to 121 (or more) measure of how confident we are that an email to the address would be sent securely. It measures only that TLS will be used to receive email; it does not consider whether or not the email address is valid.
It measures the number, preference, and quality of all the MX hosts for the address. It looks at the strength of encryption (SSL version(s) and cipher(s)). It looks at the certificate(s) and their signatures.
The Confidence Factor has these "breakpoints":
- no encryption
- unreachable (i.e. not tested)
- bad encryption (SSL v2 v3)
- very weak encryption (TLS v1)
- weak encryption (TLS v1.1)
- good encryption (TLS v1.2)
- strong encryption (TLS v1.3)
A CF of 50 typically means we could not connect to any email servers, so we could not test anything, and so we give the address a 50-50 chance of success.
Generally, if your Confidence Factor℠ is 90 or better, your email has the necessary encryption required by most security standards.
But if your Confidence Factor℠ is less than 90, your email needs work. This is the right place to start. See Solve Secure Email Problems.
The Quick option under More Options does a quick "yes" or "no" test. It takes a quick measure of just the one server that a message from you will probably go to. For small email systems this is their only server (MX host), but for large email systems it could be just one of tens of servers.
A Confidence QFactor differs from our rigorous Confidence Factor because the Confidence Factor in three ways:
- systemic rigor
- speed (potentially)
The Confidence Factor does a rigorous test of an entire email system. The Confidence QFactor does a quick look at just one host.
The QFactor picks the one host it thinks will be used right at this moment, while the full Factor test, by looking at everything, is a better measure of the long term security and maturity of an email system.
The Quick option sets these parameters:
- STOPAFTER = EHLO2
- stop as soon as we know encryption will work
- CHECKOCSP = off
- speed up the test by not checking for revoked certificates (they don't affect encryption)
- TIMEOUT = 11
- 99% of systems that are going to answer do it in 11 seconds or less
- IGNORENOCONNECT = on
- ignore any host that doesn't answer
- MXHOSTLIMIT = 1
- take the first host that answers
Focus on specific aspects of email, and work in real-time with no-wait-for-cache using settings in More Options.Additional Information (lots of it)
Depending on the Output Format selected (see below), the test also shows information about MX hosts, SMTP stages, SMTP commands and responses, details about the certificates and ciphers used, and even the contents of each packet.
- eMail Target
- The (recipient) address to test
- Output Format
- How much detail to show (see next section)
- Shows just the Confidence Factor for this address.
- Shows the above plus a matrix showing each test step for each Mail eXchanger (MX). See "Understanding the Output" below for info about the steps.
- The levels below can all display test results in real-time as the test is running (subject to browser buffering). Each step is timed so you can see where your system is spending all its time. See the Show Test Progress setting under More Options (click on the plus sign to open More Options).
- Shows the above plus each SMTP message sent to and from the email server. Test details are displayed real-time as the test is running (subject to browser buffering).
- Shows the above plus summary information about the certificates used. Also shows certificate revocations by CRL (Certificate Revocation List and/or by OCSP (Online Certificate Status Protocol).
- Shows the above plus details about the recipient's SSL Certificate.
- Shows the above plus details about the SSL connection.
- Only shows the traffic between the two ends. Does not tease out any information like the above Detail levels, nor does it show the Matrix or the Confidence Factor. Note: this output is only useful for the most hard-core debugging, which should be using a packet analyzer instead.
- Probes the first MX and shows extensive information about protocols, ciphers, and vulnerabilities using testssl.sh. CheckTLS does not vouch for testssl.sh results, nor do we support or answer questions about it. testssl.sh is provided here "as is".
Understanding the Output
Confidence Factor (Score)
This proprietary score rates what we feel are the chances that an email sent to the tested address right now would go securely. It ranges from 0 (no chance) to 90-plus (pretty sure thing). It takes into account the order and strength of each Mail eXchanger (MX) listed for the recipient's domain, and the strength, precision, and validity of the recipient's SSL certificates.
MX/Steps Matrix (Matrix)
This matrix lists, for each MX, the MX preference and the steps TestReceiver took in proofing the server. Each step shows OK/FAIL and how long (milliseconds) the step took to complete. See the Wikipedia MX_record article for info on MX servers.
The steps are in order:
- Indicates we can connect to the server. This shows the server exists, is on, is connected to the Internet, and is listening for connections.
- Indicates we are allowed to connect to the server. This shows the server allows connections from most domains and IP addresses (since it allowed CheckTLS to connect).
- Indicates that most domains and IP addresses can talk to this server (since it allowed CheckTLS to "say hello" with the SMTP HELO/EHLO command).
- Indicates that the server says it can do TLS.
- Indicates that the server's SSL Certificate is good. Currently this means the cert's: hostname matches the server, encryption is good, authorization chain is valid, and it's not self signed. Note: this is a very stringent test, and most senders will still send even if these requirements are not met.
- Indicates that the server does, in fact, do TLS. This shows that we were able to turn on encryption for everything going to and from the server.
- Indicates that the server will let most domains and IP addresses send mail to this server (since it let CheckTLS start an email from the @checktls.com domain).
- Indicates that the server will accept mail for the tested email address. This means the address is probably valid. This is only reported if you entered an email address rather than just a domain.
- Indicates that we were able to start an email to the tested address. This is only reported if you selected Send Email under More Options.
- Indicates that we were able to finish the email to the tested address. This means the email was sent, although it still could get caught in a SPAM filter. This is only reported if you selected Send Email under More Options.
SMTP Messages (Detail)
This shows the RFC 2821 SMTP commands from the sender and responses from the receiver. Each command or response is time stamped in milliseconds since the start of the test. Important parts of the conversation are highlighted, and some information about the SSL certificate being used is included. For example:
|seconds||test stage and result|
|[000.001]||Connected to server|
|[000.084]||<--||220 www4.checktls.com ESMTP Sendmail 8.14.7/8.14.7; Sun, 19 Mar 2017 12:52:02 -0400|
|[000.084]||We are allowed to connect|
|[000.085]||<--||250-www4.checktls.com Hello www4.checktls.com [10.18.112.126], pleased to meet you
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
|[000.085]||We can use this server|
|[000.085]||TLS is an option on this server|
|[000.086]||<--||220 2.0.0 Ready to start TLS|
|[000.086]||STARTTLS command works on this server|
|[000.106]||SSLVersion in use: TLSv1.2|
|[000.106]||Cipher in use: AES256-SHA256|
|[000.106]||Connection converted to SSL|
Certificate 1 of 4 in chain: subject= /OU=Domain Control Validated/CN=*.checktls.com issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
Certificate 2 of 4 in chain: subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
Certificate 3 of 4 in chain: subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
Certificate 4 of 4 in chain: subject= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
|[000.378]||Cert VALIDATED: ok|
|[000.378]||Cert Hostname VERIFIED (mail4.checktls.com = *.checktls.com)|
|[000.380]||<~~||250-www4.checktls.com Hello www4.checktls.com [10.18.112.126], pleased to meet you
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
|[000.380]||TLS successfully started on this server|
|[000.385]||<~~||250 2.1.0 <email@example.com>... Sender ok|
|[000.386]||Sender is OK|
|[000.467]||<~~||250 2.1.5 <firstname.lastname@example.org>... Recipient ok|
|[000.467]||Recipient OK, email address proofed|
|[000.468]||<~~||221 2.0.0 www4.checktls.com closing connection|
Cert Info (CertDetail)
Shows detailed information about the Public Key Certificate being used, and any Intermediate Certificates. It shows the encoded certificate itself as well as the decoded and parsed fields from it. If the remote server sent a certificate chain (used to verify/sign the remote server's certificate), those certificates and their fields are also shown.
SSL Info (SSLDetail)
Shows detailed information about the SSL connection. This includes the SSL negotiation and the decrypted packets sent and received.
Raw Traffic (Debug)
Debug output runs a different program internally and does not "watch" the test the way all the other levels do. It does not determine success or failure nor any of the timings, so it does not output the Confidence Factor nor the Matrix. It does not highlight important events in the traffic, nor does it decode certificates. The output is just the unparsed and unformatted, albeit decrypted, data traffic between the two email servers. For example:
CONNECTED(00000003) read from 0x833bbd0 [0x833dd58] (4096 bytes => 85 (0x55)) 0000 - 32 32 30 20 77 77 77 32-2e 63 68 65 63 6b 74 6c 220 www2.checktl 0010 - 73 2e 63 6f 6d 20 45 53-4d 54 50 20 53 65 6e 64 s.com ESMTP Send 0020 - 6d 61 69 6c 20 38 2e 31-34 2e 34 2f 38 2e 31 34 mail 8.14.4/8.14 0030 - 2e 34 3b 20 54 75 65 2c-20 31 30 20 4d 61 79 20 .4; Tue, 10 May 0040 - 32 30 31 31 20 30 39 3a-31 32 3a 35 38 20 2d 30 2011 09:12:58 -0 0050 - 34 30 30 0d 0a 400.. write to 0x833bbd0 [0x833ed60] (25 bytes => 25 (0x19)) 0000 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69 EHLO openssl.cli 0010 - 65 6e 74 2e 6e 65 74 0d-0a ent.net.. read from 0x833bbd0 [0x833dd58] (4096 bytes => 204 (0xCC)) 0000 - 32 35 30 2d 77 77 77 32-2e 63 68 65 63 6b 74 6c 250-www2.checktl 0010 - 73 2e 63 6f 6d 20 48 65-6c 6c 6f 20 77 77 77 31 s.com Hello www1 0020 - 2e 63 68 65 63 6b 74 6c-73 2e 63 6f 6d 20 5b 32 .checktls.com [2 0030 - 34 2e 31 32 33 2e 31 2e-33 5d 2c 20 70 6c 65 61 220.127.116.11], plea 0040 - 73 65 64 20 74 6f 20 6d-65 65 74 20 79 6f 75 0d sed to meet you. 0050 - 0a 32 35 30 2d 45 4e 48-41 4e 43 45 44 53 54 41 .250-ENHANCEDSTA 0060 - 54 55 53 43 4f 44 45 53-0d 0a 32 35 30 2d 50 49 TUSCODES..250-PI 0070 - 50 45 4c 49 4e 49 4e 47-0d 0a 32 35 30 2d 38 42 PELINING..250-8B 0080 - 49 54 4d 49 4d 45 0d 0a-32 35 30 2d 53 49 5a 45 ITMIME..250-SIZE 0090 - 0d 0a 32 35 30 2d 44 53-4e 0d 0a 32 35 30 2d 45 ..250-DSN..250-E 00a0 - 54 52 4e 0d 0a 32 35 30-2d 53 54 41 52 54 54 4c TRN..250-STARTTL 00b0 - 53 0d 0a 32 35 30 2d 44-45 4c 49 56 45 52 42 59 S..250-DELIVERBY 00c0 - 0d 0a 32 35 30 20 48 45-4c 50 0d 0a ..250 HELP..
Test From Your IP Address
CheckTLS can route your tests through your own IP address space. Use your connectivity, reliability, and reputation to run your tests. See the SOCKS parameter under the expandable More Options section of ("TestReceiver").
You will have to run a SOCKS (see https://en.wikipedia.org/wiki/SOCKS) proxy, but SOCKS proxies are safe, light weight, mature, and easy to setup. You can control access to the proxy by our IP range and/or user/password authentication. Or you can subscribe to a commercial SOCKS service (google “SOCKS5”). We recommend socks-relay.sourceforge.io. It is free and the source code is available for you to audit.
Contact Us with any questions or for help with using this feature.
TestReceiver More Options
These additional input fields are documented in the expandable Instruction/Info section at the top of the TestReceiver screen. See the expandable section titled More Options.
Check The Latest EMail Security Enhancements
Everything available with IPv4 addresses is available with IPv6.
Individual MX Hosts
Test individual servers. It can target a specific MX server but feed it the regular domain address, for example testing mx3.mydomain.com with an email addressed to email@example.com. This can uncover problems masked by the fall-back and redundancy built into many email systems.
Limit MX Hosts
Limit the number of mail exchanger (MX) hosts by preference or by number. Some large email systems list tens of email exchange hosts. You can limit to the first X or % (number or percent) of MX entries in preference order, or the first X or % hosts (in preference and then alphabetical order).
Turn off DNS (Domain Name System) Cache
Turn off DNS caching so all lookups (MX, A/AAAA, MTA-STS, DANE, etc.) are made in real time to the SOA for the domain. Tell CheckTLS to use a different SOA, not the "real" one. Unique to CheckTLS, these let you try email DNS changes immediately without breaking your production servers or waiting for DNS changes to propagate through the Internet.
Protocols, Ciphers, Authorities, Name Matching, Client Certificates
Choose which SSL protocols and ciphers are allowed, and what Certificate Authorities are acceptable, and how to match hostnames. Send client certificates to servers that request or require one. These options allow very detailed testing of email receivers.
Test services that do not need a STARTTLS. TestReceiver will connect and immediately negotiate an SSL session. For example, "Direct TLS" and a short "SMTP Timeput" can be used to test a web server. Put the server address in MX Host, 443 in MX Port, check Direct TLS, and put 3 in the SMTP Timeout.
Try forcing an email server that does not offer TLS to use it anyway.
TestReceiver can test non-standard email systems, or specific portions of an email system, or private email systems. Testing custom/private email systems requires them to be reachable from the Internet, but it can use non-standard SMTP ports (i.e. other than port 25) and/or it can authenticate into private systems.
With higher Output Format (see below), TestReceiver provides visibility into any SMTP session. It was designed to test if email can be received securely, but because it continues testing even if TLS fails, it can also show the inner workings of non-TLS email servers.
When using TestReceiver "off-label", for example to verify email addresses or open up the inner workings of SMTP email conversations, the Confidence Factor should be ignored. Use the detailed Output Format (see below) to determine the success of your test.