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 100 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. As long as "TLS Negotiated" is OK (see output steps below), the score will be 100, even if the last two steps FAIL.
Depending on the output level 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.
With higher output levels (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 levels (see below) to determine the success of your test.
- The (recipient) address to test
- Output Level
- How much detail to show (see next section)
- Shows the Confidence Factor for this address. A Confidence Factor is our proprietary score which rates the chances of successfully delivering email securely (e.g. with TLS) to this address. It ranges from 0 (no chance) to 100 (sure thing).
- Shows the above plus a matrix showing each test step for for each Mail eXchanger (MX). See "Understanding the Output" below for info about the steps.
- 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 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.
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 100 (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 allows connections from most domains and IP addresses (since it allowed CheckTLS to connect).
- Can Use
- 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).
- TLS Advertised
- Indicates that the server says it can do TLS.
- TLS Negotiated
- Indicates that the server does, in fact, do TLS.
- Cert OK
- 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 will let most domains and IP addresses send mail to this server (since it let CheckTLS start an email from the @checktls.com domain).
- Recipient OK
- Indicates that the server will accept mail for the tested email address. This means the address is probably valid.
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 <firstname.lastname@example.org>... Sender ok|
|[000.386]||Sender is OK|
|[000.467]||<~~||250 2.1.5 <email@example.com>... 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 18.104.22.168], 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..
Custom/Private Systems (TestReceiverFull)
TestReceiverFull targets the TestReceiver test to non-standard email systems, to specific portions of an email system, or to private email systems. Testing custom/private email systems requires them to be reachable from the Internet, but TestReceiverFull can target non-standard SMTP ports (i.e. other than port 25) and/or it can authenticate into private systems. The tests run by TestReceiverFull and the report options and output are the same as with TestReceiver.
It allows controlled testing of individual MX 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 firstname.lastname@example.org. This can uncover problems masked by the fall-back and redundancy built into many email systems.
TestReceiverFull has six more input options:
- eMail MX Host:
- The specific host to test, typically an MX server
- eMail Port:
- The TCP port on which the email server is listening
- AUTH Type:
- Which AUTH mechanism to use (plain, login, CRAM-MD5, NTLM)
- AUTH User:
- The userid for authentication
- AUTH Pass:
- The password for authentication
- SMTP TimeOut:
- How long (in seconds, default 30) to wait for the SMTP server to respond to a command