Imagine your phone is ringing — it is your friend on the screen. You grab your phone, you answer. Surprisingly, it is not your friend you hear, but instead the delicate sound of a voice recording advertising the newest cutting-edge house appliance of which you don’t even care at all.
Impossible? Well, luckily in this case yes, unless we are facing a pretty well-versed phone-hacker.
On the other hand, when talking about email, this is far away from being impossible. It is indeed quite simple to send an email on behalf of barack@whitehouse.gov to all of your friends — or at least, it was. As a matter of fact, the SMTP does not provide an authentication mechanism, therefore everyone is able to send emails on behalf of.. everyone you could ever imagine!
Of course, with the increasing amount of sent-emails — and more importantly the increasing amount of spam reports including phishing — a solution was overdue. It was during the early 2000’s that debate was engaged and lead in 2006 to the release of SPF, as well of DKIM, later next year.
SPF = Sender Policy Framework
Sadly, our phone-call analogies will stop right here, right now :-).
When sending an email, what we look at first in order to identify who the sender is, remains the email address represented in the FROM: field. This email address is composed of 2 main parts: the first is the part after the @ sign — the domain name. The second is the left-from-the-@ part, which is the user’s name. SPF is a technology conceived to identify servers which are entitled to send an email on behalf of the domain (aka: the right side of the email address).
Let’s imagine this scenario using the domain name ‘example.net’. example.net is a major on-line-payment website, therefore, it comes to evidence that they do not want unauthorized emails being sent on its behalf. This would have a rather negative impact on their reputation. With this in mind, the website decides to create an SPF record on its DNS server. Here below an example (Again, it is all made up!):
example.net. IN TXT “v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all”
So, what does this data show us? It shows that servers with an IP address 198.51.100.123 along with all the IP addresses in the block 192.0.2.0/24 are entitled to send emails on behalf of example.net. The ‘A’ character means that all IP addresses on the A records are also entitled to send emails on behalf of this domain name. On the other hand, the “-all” character repre-sents all the other IP addresses which should be rejected (“SPF=FAIL”).
Nonetheless, it is important to keep in mind that an email failing to successfully comply the SPF test will not be automatically considered as SPAM. Besides, any given domain name having an properly-configured SPF record will be less likely to be targeted by spammers.
DKIM = DomainKeys Identified Mail
DKIM merges this 2 technologies. One, developped by Yahoo! (DomainKeys), and the other one, developed by Cisco (Identified Internet Mail). While an SPF record works by matching a domain name to the sending-IP address, DKIM works by associating the domain name to a message through cryptographic authentication. The verification of the signature is performed through an en-crypted key found on the DNS record. By doing so, DKIM empowers you to verify if a message has been modified during its path through the many SMPT servers, as well as to ensure that the content will be safely delivered to the recipient.
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Just as SPF, DKIM is not engaging spam-fighting actions. However, it
cleans up reputation to the eye’s of email-recipient servers. Filters
should be focusing as well on the non-signed messages by applying more
stringent filters.
Here below an example of a DKIM signature represented on an email header:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
DMARC = Domain-based Message Authentication, Reporting and Conformance
DMARC nails its place between SPF and DKIM, aiming not to replace them, but to merge them by rendering them more efficient.
DMARC services can be split into 2 main categories:
First, is to indicate Webmails and ISPs of what to do with a massage that did not pass authentication (whether to let it through, delete it, spam-report it, etc).
Second is to to provide senders with message-authentication failure data feedback.
DMARC was designed by the big ones in the emailing arena (Return Path, Gmail, AOL, Microsoft, …) in order to fight more efficiently the increasing-phishing activity we face today. It is because of this, that well-known companies such as PayPal, Facebook ou LinkedIn have been attached to this project.
Good to know.
I am aware of the technicality of the topic, so please feel free to ask for further details on the comments. I will be more than pleased to answer to your questions. Moreover, it is likely that a more detailed article regarding these technologies will be published in the future.
