As mentioned in the latest posts, there are many possibilities for online communication nowadays. But what do they offer in terms of integrity, confidentiality and – let’s face it – persistence? It can be argued that especially the last part is very questionable. For how long have been instant messengers or social networks in use? Not that long. Especially compared to time-tested electronic mail with its complex ecosystem. This ecosystem can actually form a basis for modern and secure communication.
Using words modern and secure might – and should – raise suspicion. But here at Trustica we are actually developing a new and unique solution for securing it for everyone. Without venturing into any further details, you can always check our Secure Communication section for updates regularly. The end (of insecure communication) is nigh!
There is a myriad of standards covering electronic mail. The message format was first specified in RFC 822[1] in 1982 and since then has been extended with MIME[2] series of standards. To transport the messages over the network, Simple Mail Transport Protocol[3] (SMTP) is typically used. When the users want to check their mailbox and read their messages, they use either Post Office Protocol[4] (POP3) or Internet Message Access Protocol[5] (IMAPv4).
From the user perspective, three „agents“ handle all of this. Mail User Agent (MUA) is the email client used for sending and reading email messages. Mail Transfer Agent is the one responsible for delivering the email to target system – that is these are the agents communicating over the network. And finally a Mail Delivery Agent ensures the message lands in the intended final recipient mailbox. Picture 1 depicts a typical email message processing by each of these agents.
Picture 1: Message traveling from sender to recipient through two MTAs.
On top of these services, further functions can be implemented. Many people do not realize that electronic mail is this complex. They see just their webmail interface and have no idea that it is just a web-based MUA using IMAP backend. Filtering messages using user-defined rules typically takes place either client-side (in MUA) or during the final delivery by MDA. This is very efficient when it comes to spam filtering as it is not necessary to process the message by the recipient’s MUA which can be connected over a slow line.
Spam and virus filtering is another beast. To make it really effective, it is important to cut the unwanted messages as close to the originator as possible. This includes accepting messages by MTA only from authorized MUAs. In the past, this was typically done by running dedicated MTA for each autonomous system but nowadays MUA authentication using the same credentials as for reading incoming messages is mostly used. Then outgoing mail and virus filtering is performed and if the spam score is really high or a known malicious code is found, the message is dropped.
Afterwards, as the message reaches the final MTA, spam and virus filtering is performed by the recipient’s email system and once again if the spam score is really high or a virus has been found, the message is dropped. If the spam score indicates the message might be a spam message but the score is not that bad, the message is marked as „spammy“ with given score and MDA can act appropriately. Typically such message is delivered to „Junk“ (or „Spam“) folder and the user can inspect them if necessary.
Picture 2: more complex scenario of email message path through mail ecosystem – now including spam and virus filtering and delivery filters.
As the connection between two MTAs is – by definition – untrusted, several methods of ensuring only authorized MTA can be an origin of email messages from given domain has been developed. First, each domain can publish its Sender Policy Framework[6] entries in their DNS[7] records. These can specify IP addresses, hostnames or other means of identifying systems which are allowed to send email on behalf of such domain. The policies can be strict or relaxed and it is upon the receiving MTA to use this information for improved protection of its users.
Another approach is the Domain Key Identified Mail[8] (DKIM) which puts designated public key in DNS and signs all emails originating from given domain by appropriate private key. This signature is transparent to message contents as it is added as another email header and does not interfere with the message any other way. Recipient’s MTA can then check for DKIM signature existence and verify it. By combining SPF and DKIM a lot of spam can be stopped but no solution is perfect and not even all these measures can protect against end-user computers infested with malware which is able to use legitimate user credentials to send any messages. That means that classical spam filtering at the originating MTA and receiving MTA/MDA is always necessary as well.
Picture 3: Including DKIM signatures and their verification in the whole process.
What is seemingly missing in this scenario is end-to-end message integrity and confidentiality. It is possible, but it will take some time before we get to it in this series. Definitely stay tuned, more to come next week!
References
1. RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES, Network Working Group, August 13, 1982, available online at https://tools.ietf.org/html/rfc822
2. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, Network Working Group, November 1996, available online at https://tools.ietf.org/html/rfc2045
3. RFC 821: SIMPLE MAIL TRANSFER PROTOCOL, Network Working Group, August, 1982, available online at https://tools.ietf.org/html/rfc821
4. RFC 1081: Post Office Protocol – Version 3, Network Working Group, November 1988, available online at https://tools.ietf.org/html/rfc1081
5. RFC 1730: INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4, Network Working Group, December 1994, available online at https://tools.ietf.org/html/rfc1730
6. RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1, Network Working Group, April 2006, available online at https://tools.ietf.org/html/rfc4408
7. RFC 1035: DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION, Network Working Group, November 1987, available online at https://tools.ietf.org/html/rfc1035
8. RFC 4870: Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys), Network Working Group, May 2007, available online at https://tools.ietf.org/html/rfc4870