Whilst we would all like to believe that email is inherently secure, unfortunately, by design it's not.
When the original architects of the Internet designed a messaging system, they based it off of standard postal mail - something which is evident by many of the terms we see in use, such as envelope and address. As a result email inherited many of the fatal security flaws of the postal system.
Specifically: The inherent trust in people, and that people are who they say they are. The reason why email is more abused compared to traditional mail is simply a function of cost.
It may thus come as a surprise to many, that just because an email says it comes from support@iewc.co.za does not really mean it was sent by support@iewc.co.za? This is very similar to someone randomly calling you and informing you they are phoning you from bank X. How do you really know that this statement rings true? The same thing with a letter through traditional postal mail - how do you know you can trust the return address on the back of the envelope, or even the signature at the bottom of the letter?
Whilst a lot of SPAM comes in the form of marketing emails, which are sent by legitimate senders, we are also seeing loads and loads of SCAMs and Malware where parties send emails on behalf of others, relying on the co-operative trust nature of The Internet to hopefully deliver these emails to the recipients (This is often referred to as a "spray and pray" strategy).
When email was developed it was developed with simplicity in mind. So any server could (and pretty much still can) connect to any other server and with a very simple statement say "I am looking to deliver an email to you from support@iewc.co.za, this message is intended for the following addresses that you host".
Even from the beginning it should have been known that this is a bad idea. Someone was bound to abuse this trust. Given that the principles on which email was based was normal mail delivered via the postal service, we can't be too surprised at this though, since even traditional mail has this concept of trust - with the difference that in comparison with email it's extremely expensive to send. Which goes to say that given that it costs around R 6.70 to have the South African Post Office deliver a mail it costs fractions of cents for scammers to send email.
For obvious reasons, scammers are looking for the cheapest possible way to deliver their "spray and pray" type scams (they send to millions of people in the hopes of catching a few). Typical things you'll see are notices to respond to an alternative email address, for example "please rather contact me on my personal email address of xyz@example.com because some random excuse". Or click on a link portraying to be for company X, but in reality the link points to a domain that has nothing to do with company X. For example, you'll receive an email claiming to be from IEWC, and you need to refresh or confirm your email password today still or you're going to lose access to your email, and then the link goes to example.com/somewhere/else (note that example.com isn't iewc.co.za - and in 90% of these cases the email's From: won't even be @iewc.co.za).
More recently we've been seeing what we at IEWC refer to as the porno-bitcoin-scam. You will receive an email (from your own email address usually, this is part of the false "proof of access" to your system) claiming that the hacker has been observing you pleasuring yourself by watching some untasteful stuff, and since you don't need to contact the hacker in order to deposit bitcoin (usually to the value of around R25'000 or $2'000) into their wallet, no way is given to contact the hacker. A simple look at the email headers will reveal that all of this is absolute nonsense.
We need to verify that senders are who they claim to be. For starters. As part of this journey two technologies have come to the forefront. Namely SPF (Or "Sender Policy Framework") and DKIM ("DomainKeys Identified Email").
Why two? Well, consider traditional mail again, on the one side of the envelope is the recipient's name and address, on the other side is what we call the return address, to where the postal service will return the mail in case it cannot be delivered to the recipient. Inside the envelope the sender can sign the email with a separate name if they so choose. It could even be addressed to someone completely different.
A good use-case of this would be for Steve at IEWC to send a mail to his friend Bob at company X. The return address would be that of IEWC, and probably contain his name there too, but inside the envelope Steve could simply have placed a letter that was originally address to himself by IEWC's CEO, and now when this arrives at Bob, Bob can know two things, and only these two things, with absolute certainty:
Given this example we can already see there are no less than four addresses involved:
As such, the following things we think we know, we actually don't:
Simply put, traditional mail suffers the exact same problems as email, with the difference that it's an extremely expensive (in comparison with email) mechanism to propagate scams and dangerous emails containing for example malware.
The fix is obvious: Make it more expensive to send email. The question remains, how expensive is expensive enough?
Various attempts has been made in the forms of technologies like hashcash (which is in a way a predecessor to what is now known as cryptocurrency), and suggestions has even been made to store email on the sending servers rather than the receiving, but in the case of scams and malware this can be generated on the fly so really doesn't help.
Instead we do two things:
DKIM (which covers the signing, 2 above) and SPF (which covers the sending authority, 1 above) are the two technologies that have come to the forefront to achieve this.
Neither of these technologies, or even the combination thereof, stops SPAM dead in it's tracks. But it does force the sender to reveal (to a degree) their true identity. This then allows us to clamp down on individual domains that send spam, and eventually, force spammers to register hundreds and hopefully thousands of domains, each one with a certain associated cost, both in terms of registration fees as well as infrastructure costs. This will hopefully start clamping down on a lot of SPAM.
DKIM aims to verify the content inside the email using a cryptographic scheme. This is analogous to signing a letter with your "unique" signature. The difference is that a cryptographic signature is significantly harder to forge than a pen-on-paper signature.
How is this achieved? The really short and simplified version is that a domain owner publishes a set of records in DNS (Domain Name System) which states which public keys can be used to verify the authenticity of an email for emails containing a From: header for that domain.
For example, for iewc.co.za we have granted authority to our voice-over-IP servers to send email with a From: header for iewc.co.za using the selectors morpheus and r2d2. As part of the DKIM signature, the used selector is also put into the email headers. Let's say morpheus was selected, the receiving mail server can now go back to the DNS system, and ask the question "what's the public key for the provided selector?" and based on the answer this can be used to verify if the letter (inside the envelope) has been tampered with in any way. An example of such a record would be:
morpheus._domainkey.iewc.co.za descriptive text "v=DKIM1; k=rsa; \
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnjsbmMD5yqShPIAc\
o6MUCLhXFJynBEmROo4dL7kjn7CXjQ4qRgGRT4hekFt229iebM33tUHt0Ndtwt\
4jRmDHW5kl03KfAhxrl/+YKY+69y76aVwZBaxRgae5yplQYKt6d0jqr8fV5Ygi\
5y3x35h53tFzU/ylWGXB08zUq5hY3BQg5j9ueYmSQ8wEPuEsO6yeB"
"tJiCBY/nDGK/zOj0sGLy4ZMuaMZfOrLVIUBtUhaboMnKHfhwL7kgtgsNXI6Qi\
kP4tnyCfJOK+e5PCAAI+mkQ8XOGv3LAeOeeheVRx+eat99n2LRUXYe4iU6TwCG\
Edf7rfQpCPd2YgUrsq3cJhh+nQIDAQAB"
This represents an RSA public key, similar to what is found in the certificates used by https:// connections, and which is used to verify that the servers we think we're connected to when browsing to, for example our online banking systems, are in fact those systems.
Using this private key associated with this public key, a message digest (a form of fingerprint) is created, and then signed using the private key, resulting in a message signature. Using the public key this signature can be verified, giving a very high degree of certainty that the message has not been tampered with in transit.
And since only the domain owner can publish public keys for the domain, any server that has a working private key with a published public key is by implication authorised to send messages on behalf of the domain.
Sender Policy Framework (SPF) provides a way to indicate which servers are permitted to send on behalf of a specific domain. This is specific to the envelope sender, following our analogy with traditional mail, the return address.
Whilst the majority of users never actually see this, it's important to protect this address as well in order to prevent what is referred to as "back-scatter spam". This happens when for example someone injects email into the email system purporting to be sending from your domain (return address) but signing it as someone else.
When the eventual recipient rejects the contemplated message, then the return message (more commonly known as a bounce) will be returned to the sender in the return-path, which may not be the person that actually sent the message.
This adds as much to the administrative burden of filtering your email, and generally is just painful to work through as bounces are more likely to pass through things like spam filters because they tend to "look" similar.
The author is of the opinion that some parties also applies SPF to the domain in the From: header of an email if it lacks a DKIM signature. This is technically incorrect but could help to eliminate a certain class of SCAM emails, at the cost of breaking some email forwarding schemes (mailing lists, old email address forwarding to a new one) if the original sender didn't sign their email with DKIM.
SPF helps to protect your domain from being spoofed in the return-path (return address), and thus reduces the likelihood of your domain receiving pointless and annoying back-scatter spam.
DKIM helps to protect the integrity of sent email by cryptographically signing the email, which protects it from in-transit tampering, and also prevents other parties from sending email on behalf of a domain that is protected by DKIM.
All of this of course assumes that the recipient's mail provider checks and enforces the policies published by the sending domains (return path and from address).
IEWC has already ensured that DKIM is deployed for all it's clients hosted on it's mail platform, as well as those using Google Mail through IEWC. We've also ensured that all relevant SPF records, including DMARC records to allow for automated reporting of failures are correctly in place.
We are slowly moving into a world where all email will be required to pass both SPF and DKIM checks. If you need or want more information on this subject, you're welcome to engage with us by way of email to support@iewc.co.za.