Mandatory TLS

Internet email, like the Internet itself, is designed to be robust and to work around problems. With email that means sending email in plain text if anything goes wrong with encryption. Today, unfortunately, that can be against policy, contract obligations, and might be illegal.

Email systems have responded with "Mandatory" (also called "Forced" or "Required") TLS. These systems let you maintain a list of domains that HAVE TO use encryption. If anything goes wrong with encryption, the email message will either wait and retry later or bounce back to the sender.

There are also in-line hardware devices and on-line services through which you can route your email to make sure everything is secure. These all cost money and increase the complexity of your email system.

Mandatory TLS Is Not Commonly Used

Almost no one uses Mandatory TLS for their regular email. Use the CheckTLS Mandatory TLS tests off the //email menu to check both your and your trading partner's emails. The tests will all fail, meaning Mandatory TLS is not in use.

Instead of Mandatory TLS for all email, companies use one or both of:

Selective Mandatory TLS is a feature of most modern email systems and is enabled from point "A" to point "B". You keep a list of domains on your email server to which it will NOT send email unless TLS is working. All your email to a domain on this list will fail if anything goes wrong with TLS. This forces TLS to be used for all email between you (point "A") and that trading partner (point "B").

Selective Mandatory TLS has its issues: maintaining the list of domains, noticing if a domain is failing, and notifying the domain that their email is broken (hint: you cannot email them). When Mandatory TLS is widely used, it creates support issues (which CheckTLS can help alleviate).

Verified TLS℠ does not have the issues that Selective Mandatory TLS does. The process finds and notifies you, and possibly your trading partner, of failures without breaking email in general.

Testing Mandatory or Forced TLS

Mandatory TLS, whether required for all email, some email domains, or used with Verified TLS℠ is not "set it and forget it". As with any addition to a process, things can and do go wrong. These Mandatory TLS settings, devices, and services are no exception. And all of these options require on-going maintenance: keeping the list of domains up-to-date in your email Mandatory TLS settings, or hardware and software maintenance on in-line devices, or managing the on-line service.

Your security policies should include regularly testing that they are working as expected. To test Mandatory TLS, you need an email system that does not work right: one where encryption fails, so you can be sure your "have to have" TLS stops the email message from sending or receiving.

In addition to the normal email tests, CheckTLS provides two "Mandatory" TLS tests. These simulate TLS failures and, like our other test, watch what your system(s) do.

Just the same as with normal secure email, we can quickly and easily make sure Mandatory encryption measures are working and continue to work. You can test almost everything about email with CheckTLS.

TestMandatoryReceiver

Makes sure that the receiver will ONLY accept an email if it is sent securely. It makes sure the receiver will NOT accept an unprotected email.

While email security is mostly the responsibility of the sender, in a high security and/or privacy situation the receiver too has a responsibility to make sure the sender meets security requirements. RFC 3207, the Internet standard for TLS email, states "A publicly-referenced SMTP server MUST NOT require use of [TLS] in order to deliver mail locally." This implies that security conscious organizations have a normal email receiver for normal email (e.g. sales@bigco.com) and a "TLS only" receiver for secure email (e.g. patient-records@secure.bigco.com).

//email/testMandatoryTo: does the same testing as //email/testTo:, but it does not accept the receiver's invitation to use TLS. Instead, it tries to trick the receiver into receiving the email insecurely. //email/testMandatoryTo: is looking for the email transfer to fail, meaning the receiver will not receive email without protection. If the receiver accepts the email, the test fails; if the receiver rejects the email, the test succeeds.

Note: this test is only useful for sites that have setup "Mandatory TLS" to receive email from one or more domains. You must list CheckTLS.com in your list of "Mandatory TLS" domains before running the test.

TestMandatorySender

Makes sure that the sender will ONLY send an email if can be sent securely. It makes sure the sender will NOT send an unprotected email. RFC 3207, the Internet standard for TLS email, says the sender "must decide whether or not" to send email if the receiver will not do TLS. In high security and/or privacy situations there is no decision: the sender can never send insecure email.

//email/testMandatoryFrom: does the same testing as //email/testFrom:, but it does not offer, nor does it accept, TLS. Instead, it tries to trick the sender into sending the email insecurely. //email/testMandatoryFrom: is looking for the email transfer to fail, meaning the sender will not send email without protection. If the sender does send the email, the test fails; if the sender refuses to send the email, the test succeeds.

Using //email/testMandatoryFrom: is similar to //email/testFrom:, except the address you send to is test@TestSenderAssureTLS.CheckTLS.com. A correctly configured sender will eventually give up without sending the mail and either bounce it or queue it to retry later. //email/testMandatoryFrom: does wait up to 30 minutes in case the sender tries to send the message again, so it can "accept" it and prevent it from trying over and over and eventually bouncing it back to you. It simply throws the second attempt away.

Note: this test is only useful for sites that have setup "Mandatory TLS" to send mail to one or more domains. You should add "TestSenderAssureTLS.CheckTLS.com" to your list of "Mandatory TLS" domains before running the test. You should also add CheckTLS.com domain to your regular list of allowed domains so the returned report is not inadvertently marked as spam. See Basic Sender Test for how to use this test and the test code provided.