Ensuring high deliverability in email is no walk in the park. As a high-volume sender of email, there are many things to take in consideration, especially with cybercriminals keeping a fast pace in innovation.
Make no mistake, deliverability is of highest importance to anyone sending email, let alone the high volume senders. When you get the information from your servers that a certain percent of sent emails were accepted by the receiving servers you still have no idea what happened after that. No confirmation of emails actually reaching inbox means they might just as well be laying in the spam folder. The SMTP transaction is logged as ”250 OK” as long as the server didn’t reject the email. To make matters even worse, different ISP’s may treat email differently, putting more responsibility on the sender to do their homework as neat as possible.
Pay attention to encryption, as it no longer is as security measure only for the selected few, but becoming the standard. TLS/SSL and DANE are your friends and will keep your information private.
Be protective of your IP addresses reputation, they can make or break your deliverability. ISP’s acts as proxies for recipients, meaning they will take reputation very seriously. Take in consideration that sending unsolicited email may harm your IP reputation, and authenticating your email with SPF, DKIM, and DMARC will help keep out scammers who are most often ahead of ISP’s and senders technology.
It’s been an exciting year in email security and infrastructure, and the Halon team has tried to cover some of the interesting stuff we’ve come across. In case you missed any of it, these are our top posts on email, security, tech and encryption. If you have questions around any of it, just shoot us an email!
Trends come and go but fashion is always in style. 20 years of emails shows that it is a consistent way of communication, despite a relatively standstill in development. While the world sings their praise for new and sexy messaging services like Slack, gets rid of stationary phones, and transfer customer communication to Facebook chat bots, the B2B world still rely steadily on email. After three days of WebSummit in Lisbon, Portugal, I am even more convinced than before.
Email is still an effective marketing channel.
Nobody likes newsletters that doesn’t contain news neither relevant information. But the stuff in your inbox that makes you stop, look and click is still a golden ticket for the companies that send them. First and foremost because you have asked of them, and also because you can measure everything that happens with the email from the moment you hit the send-button. Email is also the most universal carrier of B2B communications, such as partnership discussions and sales letters.
Email is however taken for granted.
Both sender and receiver believes firmly in that what leaves one end will reach the other. But that is unfortunately not always the case. And service providers should go to greater lengths to assure their customers that they actually can trust the deliverability of their precious emails.
Email is what we do when all else fail.
What happens when you haven’t logged on to your message service in a week? When an event organiser want to make sure that you get the info they already sent out by push notifications? You get an email, because that is the worlds most decentralised form of communication and a universal fall-back. What if it doesn’t work, and even worse, what if you never find out? You can put demands on your email service provider. Whether it is a telco, an ISP, a hosting company or an email marketing platform, you can demand;
Never delete or quarantine a message silently, always inform the sender if a message isn’t delivered to your inbox.
Use DMARC so that the sender address can be trusted.
Google’s recent announcement that they’ll be adding encryption (TLS) and authentication (DKIM/DMARC) status icons to Gmail is a great initiative.
What they do
In addition to being displayed for received email, the encryption indicator works when composing email as well. It’s however not updated in realtime, and seems to be cached per domain. For example, a warning is displayed “@cox.net”, but not for “@coxhomesecurity.com”, despite pointing to the same MX. We haven’t been able to verify how long it takes for the warning to display; after setting up a new (non-TLS) domain one day ago and sending numerous email to it from different Gmail accounts, the warning is nowhere to be seen. We presume that the sessions of sent email are being used is material, since we didn’t record any additional probes/callouts to our test server.
I fully appreciate Google’s rationale behind displaying a red broken lock icon when TLS is absent, rather than a green lock when it is used; I just wished they addressed the shortcomings of non-authenticated TLS and took a stance on how we could move on to proper email encryption.
As I discussed in a recent blog, TLS is widely deployed for email, but virtually no-one is doing verification (checking authenticity). In the case of a web browser, TLS without verification triggers a warning (such as a red lock). It might be confusing for users that a similar symbol in Gmail indicates something different. In my opinion, there should have been at least an explaination or comment that non-authenticated (opportunistic) TLS doesn’t protect against active attacks (eavesdropping, downgrade, etc).
The main issue, of course, is that there’s currently no widely deployed mechanism for SMTP TLS name verification. This stems from the fact that email is security-agnostic (unlike the web, where you type “https://”) and that the DNS MX structure makes normal CA-based name verification ambiguous.
What they could do
The most promising technology right now for proper, verified encryption (TLS) is probably DANE, which builds on DNSSEC. It’s already implemented in Postfix (the second most popular email server) and (of course) Halon. Furthermore, many European providers and operators have either deployed, or is planning to deploy, DANE. It even serves as a cornerstone for Trusted Email Services initiative.
While its dependency on DNSSEC is likely hampering adoption, I’m encouraged by its strong community support. It feels like widespread email encryption is finally within reach!
DANE does not only challenge the certificate authority (CA) system, but also has the potential to revolutionize email security; namely making encrypted email delivery the norm. Halon Security’s mission is to bring DANE to the world of email and to help maintain data privacy and security on a global scale.
The DNS-based Authentication of Named Entities (DANE) is a proposed standard that binds X.509 certificates to DNS names using Domain Name System Security Extensions (DNSSEC).
Even today (2016), email is being transmitted unencrypted, with very few exceptions. The fact that many servers use TLS doesn’t do much more than create a false sense of security; while it prevents passive wiretapping, the opportunistic TLS mode that is being used today doesn’t protect your email transmissions from active attacks. DANE is currently the most promising piece of technology that might change all that. Despite being (primarily) a DNSSEC-based trust scheme for X.509 certificates, it also provides the means to know if a domain supports encrypted email transfer. That last part is very important; it’s what has been missing all these years.
Public-key cryptography is a fundamental component that makes the modern Internet work the way it does. One of the most widely known encryption protocols is TLS (formerly SSL), used for web browsing, instant messaging, and much more.
Email however, despite being “the go-to form of communication in the Business world” with a constantly growing user base, hasn’t changed much over the years, and is generally not encrypted.
The state of email encryption
Before we start talking about DANE, let’s first look at the differences between transport and end-to-end encryption;
Transport encryption works on domain level (an organization) and protects the email transfer. It is similar to HTTPS, used when browsing secure websites.
End-to-end encryption works on the individual level (a person) and protects the content of the email for its entire lifetime. The two most popular standards are S/MIME and PGP, but none of them have achieved widespread adoption.
While I would certainly love to see widely deployed end-to-end email encryption in the future, having transport security in place would be a very good start. When visiting your bank’s website, it’s surely encrypted. Still, when sending them an email, the transport from your email server to theirs, likely isn’t. Why is that? Since email transfer (SMTP) supports TLS, why not use a PKI such as the CA system, like we do for the web? Unfortunately, there’s no standard defining a way for the sending server to know whether to use encryption or not. For the web, you type https://, and there’s simply no equivalent for email. Until DANE.
Is the general consensus that DANE should replace CAs all together? As always there are arguments for and against. While a hierarchal system is preferable, the transfer of control and responsibility to the DNS system’s owners (governments, DNS admins) is a topic much discussion. There’s also work to improve the CA system with supplementary techniques such as keypinning and added perspective. Nevertheless, DANE stands strong to improve the security in many areas, such as email.
Most of our customers can start sending email with DANE right away, by simply changing TLS mode to dane. We recommend that you use the built-in DNS resolver Unbound with DNSSEC enabled, instead of relying on an external DNS server’s AD-bit. In the logs you can identify DANE-verified connections by
Connecting to [2001:1900:2254:206a::19:1]:25 (DNSSEC)
X.509: /OU=Domain Control Validated/OU=Gandi Standard SSL/CN=mx1.freebsd.org issued by…
DANE: validated successfully
Connection is now using TLS
If you or your customers’ domains are DNSSEC signed, you should look into receiving email with DANE as well. In theory, it’s no more difficult than publishing your SMTP servers’ certificate signatures as TLSA records in your DNS using the same name as the MX points at, but prefixed with _25._tcp, for example:
mx1.freebsd.org. IN A 188.8.131.52
_25._tcp.mx1.freebsd.org. IN TLSA 3 0 1 2B73BB905F…
We have been pioneering email security in our scriptable SMTP server for a long time; being early adopters of DMARC, DNSSEC and much more. If you’re curious, go ahead and download the software from our website.
Halon is a flexible security and operations platform for in-transit email. It enables companies that build and operate large-scale
email services to offer competitive features by rapid implementation, and to lower costs of maintenance through
reliable deployment and reduced complexity.