TLS over SMTP – How to protect your email from prying eyes on the internet

Those who have worked with email servers should know what SMTP is but many do not understand what TLS has to do with it. It is even more amazing how many people don’t realize that e-mail is worse then a postcard written in pencil. It is in clear text easy to read, modify, and pretend to be someone else to get what you want.

My last post on DMARC, SPF, and DKIM would help protect many people from receiving emails pretending to be from your domain, sometimes called email spoofing or phishing. This post will focus on options to keep those prying eyes from seeing emails sent from your domain by encrypting the connections between the receiving and sending domain email gateways using TLS.

Think of TLS to SMTP as what SSl or HTTPS is to HTTP. Except one difference, TLS can happen on the same port as SMTP. So how do we ensure that the receiver does not revert back to cleartext? Well we create policies to cover the receivers we want to send mail to to ensure they are forced to receive using TLS or the email fails.

So the first thing to do is to check if TLS is enabled on your SMTP server. Best and quickest way to do this is to use the SMTP testing tool at mxtoolbox.com. You can check yours and anyone you what to send emails too.

Next if you don’t have TLS, you can generate a self-signed or better yet get a inexpensive Public CA signed SSL certificate from RapidSSL. Then setup your gateway or exchange server to use TLS for its interfaces and mailflows.

Now who do you ensure that mail is sent TLS, and if it can’t be sent TLS and you still want it to get your message through securely? Here is where one could create another smart-host or gateway, that also acts as a secure ad-hoc webmail server as needed. If the server can connect via TLS it send that message through also letting the sender know that it was delivered, and possibly read securely and letting the receiver know that they are receiving a secure mail via TLS.

If for some reason TLS fails the message is hosted on the webmail server, and a registration and seporate notification that a secure email is awaiting the receiver on the senders web server. The user registers somehow and picks up the message. The sender is then notified that the message has been received.

There are probably products out there that do this. They are expensive, but this is not really rocket science. I’ll post back if I find an easy open source solution to this problem.

But if you just enable TLS you are making huge strides to protecting your sensitive emails, and even consumer email such as Google Gmail defaults to TLS.

Advertisements

How to fight SPAM, Phishing and Protect Your Brand Name – beyond blacklists

Sounds a little off topic, but I was amazed at the glazed eyes from Marketing when I tell them their e-mails might be marked as spam by some of the most popular consumer email hosters. Basically when they use try to use an email service and send as a SPF, DKIM, and DMARC configured domain, their e-mails are rejected. At this point some of you might be wondering what I’m talking about. Basically these standards are used to help receiving email gateways verify that the email actually came from the legitimate sending gateway via DNS records and signing keys. It also allows the sender to have some say on how the receiving organization should respond to offending e-mails, such as let them through or to reject them. The topic sounds more complex then it is but I will show you the steps to get started and share some of the tools that helped me to incorporate DMARC, SPF, and DKIM in less then a day.

Lets start with DMARC. You can find more information on DMARC here http://www.dmarc.org. I recommend starting with DMARC in a testing mode as it will tell all receiving domains to send you DMARC reports on al e-mail that appears to be coming from your domain. These reports are mainly XML files but you can also request some of the domains to send you a copy of the actual offedning e-mail. Reading XML files can be fun but these files can be hudge depending on the volume of emails, so I recommend using a service such as http://dmarcian.com which is cheap or free. This service will break these reports down into actionable data. After you create an account with dmarcian, they will give you an e-mail address. You can use this e-mail address in you DNS TXT record. If you want to receive the forensics e-mails be sure to create an e-mail on the domain you are monitoring so you can have these sent to you.

You will need to create a DNS TXT DMARC record for your domain. This record will not be an A record but a TXT one named _dmarc.yourdomain.com. for example in the Godaddy DNS Manager you will create a record _dmarc under the TXT section. in the value your will enter the following

v=DMARC1; p=none; pct=5; rua=mailto:Yourcode@tdf1noj0@ag.dmarcian.com; ruf=mailto:dmarc-ruf@yourdomain.com;

v= is the version
p= tells the receiver to take no action at this time, that this domain is in testing (it is recommended to start here)
pct= the percent of messages to apply the rule to, you can start this number small and work your way up. It is best practice as you change “p=” to a stronger policy that you start pct= to a lower value and work your way up to 100 a week or so at a time. This will help you to lock down your domain emails while still avoiding as many false positives as you can.

rua= the e-mail dmarcian created for you, this will allow them to create reports based on the hundreds and thousands of emails being sent. This is mainly just IP, pass, fail , and domain informaiton no actual emails.

ruf= the mailbox you created this should be on the same domain, unless you create a special third-party record on the receiving agagate domain.

After you set this up wait a week collect data, log into DMARCIAN.com and see who else is sending e-mails as you, what countries they are coming from. Could they be targeting your customers or members? Or is it a vendor that does business on behalf of you. This is the type of informaiton that will protect you from loosing mail and monitoring your efforts along the way.

The next step is to create a simple SPF record. This Sender Polcy Framework DNS record or SPF is used to identify all the IPs that are allow to send e-mails as your domain, and what to do with those that are not on the list. The trick here is the same start with your sending e-mail gateways, if you have just one or two list just their IP addresses. The main limit here is the size of the TXT record and staying under 10 DNS queries. You can have multiple SPF records included and chain them together. You can even include records from another domain. Start simple first.

Before you post your record goto http://www.kitterman.com/spf/validate.html, and in the bottom form called Test an SPF record you will enter in the IP address of the sending email gateway, SPF record, and a test email such as test@yourdomain.com. This e-mail does not need to exist it will just check your record and see if it passes or fails.

The SPF record is also a TXT type DNS record, it has no name. This means in some DNS managers you give it the name of @

If you have a domain that should not send e-mail your should use this spf record:

v=spf1 -all

This tells receivers to reject all e-mails from this domain. Don’t use it on your sending domains instead use:

v=spf1 ip4:123.123.123.11 ip4:123.123.123.10 include:icpbounce.com ~all

You can use ip4 for IPv4 addresses and ip6 for IPv6 addresses, you can also use mx to include all your mx records but recommend using IPs when ever possible to avoid the DNS limitations. includes are handy if you send e-mails through other vendors as your domain. That way their SPF record is simply included into your record. They have to have an SPF record for this to work. Once you have an SPF record wait a little bit and use the SPF surveyor tool in DMARCIAN.com to get some feedback about your record.

Also you can test your record by sending an e-mail from check-auth@verifier.port25.com you should get a reply with the SPF section passing.

You will want to monitor your DMARCIAN account to ensure you are covering your vendors and yourself who send as your domain. This may require some investigation of domains and IPs. I recommend using robtex.com to get all of this in one tool. or just doing a Whois. Sometimes multiple domains will be associated to the same IP.

What you will notice DKIM is failing at this point. So what is DKIM. Well my friend, DKIM builds on domainkey as a way for email gateways to sign e-mail with a private key as it is sent out, then the receiving domain can compair the signature and ensure the email was not modified by checking the public key published in the sending domains DNS. Sounds simple now lets get started.

If you use an e-mail spam appliance that supports DKIM have it create a DKIM key pair I recommend 1024 bit size, I found the larger keys did not work for me. If you don’t have a gateway and just have exchange, I recommend building a linux server to act as your gateway or smarthost. Such as dkimproxy.sourceforge.net. Follow the instructions for creating the key and applying to your mailflow.

At this point when you send your check e-mail it should still fail but you’ll notice that it is signed. You now need to pubish your DKIM public key to your DNS. You will need to copy the “public” key from your gateway. You will create a TXT record called yourselector._domainkey.yourdomain.com. You will have a DKIM key publish for each gateway you are authorizing to send keys as you. in the value you will enter in the DKIM key as produced by your gateway.
Something like: v=DKIM1; p=;

Also be sure to create a TXT DNS record called _domainkey.yourdomain.com with the value of: t=y; this will tell everyone that you are in testing, and to still accept unsigned messages. You can change or remove this value as you are more confident that all email is being signed. Wait a little then check your DKIM key on DMACIAN.com, they have a link to a tool that will make sure the public key is valid. Send a few test e-mails. Kepp in mind it can take some time for DNS records to change or kick in.

Now you should see your messages pass DMARC, SPF, and DKIM. You may see others that need assistance, such as vendors you work with. So the easy part is to slowly rasie your policy until your at 100 percent, and are telling everyone to reject those other spam or phishing e-mails. You will need to ensure that you maintain your records and work with your new vendors. As this is controlled in DNS, you can even change your policies temporarly on the fly just keep in mind DNS propegation.

Thank you for reading hope you find this useful.

_