TestReceiver Run It

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.

Other Uses

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 innerworkings of SMTP email conversations, the Confidence Factor should be ignored. Use the detailed output levels (see below) to determine the success of your test.

Input Parameters

EmailAddress:
The (recipient) address to test
Output Level:
How much detail to show (see next section)

Output Levels

Score
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).
Matrix
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.
Detail
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).
CertDetail
Shows the above plus details about the SSL connection and the recipient's SSL Certificate.
Debug
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 vailidity 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:

Connect
Indicates we can connect to the server. This shows the server exists, is on, is connected to the Internet, and is listening for connections.
Allowed
Indicates we are allowed to connect to the server. This shows the allows connections from most domains and IP addresses (since it allowed CheckTLS.com to connect).
Can Use
Indicates that most domains and IP addresses can talk to this server (since it allowed CheckTLS.com 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.
SenderOK
Indicates that the server will let most domains and IP addresses send mail to this server (since it let CheckTLS.com 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:

SSL Info (CertDetail)

Shows detailed information about the SSL connection and the SSL certificate being used. This includes the SSL negotiation and the decrypted packets sent and received. Also includes the encoded certificate itself as well as the decoded and parsed fields from it. And 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.

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   4.123.1.3], 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) Run It

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 myname@mydomain.com. This can uncover problems masked by the fall-back and redundancy built into many email systems.

TestReceiverFull has six more input options:

E-mail MX Host:
The specific host to test, typically an MX server
E-mail 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