In the Turris project, we are currently improving e-mail communication security. If you use our infrastructure for sending notifications from Turris devices, it also applies to you. It strengthens your protection but may “break” the redirection of messages to another address.
More secure e-mail communication
E-mail is an ancient way of internet communication. Internet users still use it intensively (and will indeed be used for a long time). Thus it has passed through significant development, especially in the security area. It has been necessary because wrong-doers misuse it for many malicious activities like spam, phishing, or unlawful interception. In CZ.NIC, we have always paid attention to security; not otherwise, it has been in the Turris project. We utilize the available possibilities in full measure to further harden the security.
E-mail in the Turris project
Aside from personal e-mail communication, where we use the same solution as the rest of CZ.NIC, we have one specific thing in Turris. Each user of our devices (currently Turris 1.x, Omnia, MOX, and Shield) can configure the system to receive notifications about important events like system updates or reboot requests. Turris OS can send these notifications via our e-mail infrastructure (or via custom mail servers; this mode is out of our field of action, however).
Our significant interest is to have this communication secure and trustworthy. So nobody should impersonate us, for example, send (on our behalf) links to phishing login forms or solely advertisement of a product against baldness.
Therefore we have deployed a large scale of security technologies just at the launching of the e-mail infrastructure. The fundamental thing is the client’s permission to send messages and encrypted communication between a device and the e-mail server (using a secure version of TLS and a secure algorithm). But that is far from enough.
Briefly about technologies
Several technologies have been developed to protect against the unauthorized sending of e-mail messages on behalf of a foreign party (on the domain level) and other unauthorized manipulation. SPF, DKIM, and DMARC are currently the most used ones. Let’s look at them closely.
- SPF (Sender Policy Framework) – Special DNS records define which servers are authorized to send e-mail messages from a domain. Receiving servers can check whether a sending server is listed in those records.
- DKIM (DomainKeys Identified Mail) – The sending server signs message bodies and some headers by its private key. The pertaining public key is published in the DNS. Receiving servers can use the public key to check whether an authorized server has signed a message and its content has not been modified.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) – It utilizes both mentioned technologies. It allows the definition of a policy for incoming messages. Also, an administrator can specify e-mail addresses where reports would be sent.
For those technologies, DNSSEC is necessary (to protect against spoofing of DNS records). It is a sure thing for us.
The receiving server performs all necessary checks if a message is incoming from a domain with those technologies deployed. The message is either accepted, rejected, or dropped. The exact behavior depends on the message itself (whether it is sent legitimately) as well as on the defined policy and the settings of the receiving server.
When legitimate messages do not pass
In an ideal world, a legitimate message always passes, and an illegitimate one is always rejected or dropped. But we do not live in such a perfect world. Thus we meet various cases where either an illegitimate message passes (if the receiving server is too benevolent) or a legitimate message do not pass (that is much worse).
The latter case usually occurs if messages are redirected. You may have an e-mail address that you no longer use but do not want to miss messages that come to it. Thus you set up a redirection. It is incompatible with SPF, though. The e-mails come from servers in the list of authorized servers (and the “from” address remains without changes; therefore, the original domain is checked).
Mailing lists may generate different problems. They indeed replace the original addresses with their ones, but herewith modify some headers and possibly bodies. If the original DKIM signature is kept, the message becomes untrusted and may be rejected or dropped.
What about it?
The most straightforward solution is to not use redirection – nowhere, not only for Turris notifications. Redirection has become problematic due to SPF and DMARC. We recommend using the actual destination address instead of the current one (that uses redirection). If you do not want to show it, you can use a resend tool compatible with SPF, DKIM, and DMARC; a suitable mailing list, for example.
In the case of mailing lists, it is necessary to check everything by the given list software but then work on its behalf, e. g. to use its own DKIM signature instead of the original one.
Higher security has a sense
Although a higher level of security may bring some discomfort and maybe the necessity to change the existing settings, it has definite sense. Nearly everyone has met any form of e-mail misuse, and it probably was not a pleasant meeting. So let the most experiences be enjoyable and the less of them disgusting – also thanks to security technologies.