Just 10 lines of python 3 code show email's biggest problem:
import smtplib
from email.mime.text import MIMEText
msg = MIMEText('Just wanted to show you https://hacker.com/')
msg['Subject'] = 'Victim - let me show you iPhone 8'
msg['From'] = 'Tim Cook Apple CEO <[email protected]>'
msg['To'] = '[email protected]'
with smtplib.SMTP_SSL(host='your-smtp.com') as smtp:
smtp.login('[email protected]', 'password')
smtp.send_message(msg)
Email was originally designed for messages to be stores and forwarded multiple times before they got the their destination. Servers would just have to trust that the From
header was correct. For many years, there was no real way to verify that you really got the email the person that the From
header states.
In 2005, some smart people came up with SPF (sender policy framework). It is a special TXT record that you put on your domain. When the mail mail server for victim.sam.today
gets a message from Tim Cook, it will look up the SPF record for apple.com
, and check if the SPF record allows that server to send messages for that domain.
But what if the server is not authorized? That's entirely up to the mail server - but usually it is just used as a spam signal. So your fake messages get delivered, and if you are lucky they don't even get marked as spam.
It wouldn't be the internet without competing specs. In 2004 DKIM, or domain key identified mail, started development. It works very simply on a conceptual level; you generate a public/private key pair on your server, and put the public key in a special TXT record. Then for every mail you send, you use your private key to generate a signature which you include in the message. The receiving server can choose to validate this signature. But what do they do if the validation fails? Maybe use it as a spam signal?
So we have 2 competing specs for validating the emails. They both have a carrot, but no stick.
Enter DMARC - another system built on top of DKIM & SPF. DMARC is again another TXT record you add to your domain. But it tells to the receiving mail server what to do with the SPF and DKIM information. The 3 options are to do nothing, quarantine the failing messages or reject failing messages. Receiving servers will also generate statistics about what mail passed and failed. Finally, this is something that gives the "stick" to SPF and DKIM.
So this sounds great overall for the email ecosystem. Nobody will get spam messages from pretending to be Tim Cook. Or so I though. Take a look at the deployment status of some big domains:
yahoo.com
, yahoomail.com
, google.com
, stripe.com
, quora.com
, airbnb.com,
facebook.com,
instagram.com,
medium.com` - very good and secureamazon.com
, microsoft.com
, uber.com
, snapchat.com
gmail.com
, outlook.com
, apple.com
, github.com
- these have no securitySo I can still fake being Tim Cook, or maybe even from GitHub.
Some companies might be using legacy software to send emails, such as old web apps, bad email marketing services, etc. That seems quite intuitive - these are things you use to send email, therefore they need to use DKIM/SPF.
But many programmers still use emails without DMARC, even on there personal domains. This is beacuse it means you can't post on mailing lists. All those LKML flame wars you can't join because of DKIM; what a catastrophe.
And the reason is simple. Mailing lists change messages. Some add footers with an unsubscribe button. Others add a list name to the subject line. Some change the reply-to address. Overall, changing the email message means that the DKIM signature is broken. If you use DMARC in reject mode, that means the message won't get delivered, due to the broken signature.
Additionally, since DMARC enforces SPF, the mailing list server can't send mails on your behalf. Only your email server can do that.
So this means that mailing lists need to change. Google employees can't post on LKML, because of DKIM. Maybe some users of old mailman installations need to look at a upgrade:
Good news is that there is a solution, but it breaks from tradition. Mailing lists need to change the From
address from the original sender to one that they control. Then it is all good - they can continue to rewrite the subject lines and the footers as much as they want. They can just resign the message - since it is their From address and their DKIM key.
Google Groups is doing it already for senders who have the "reject" DMARC policy. Modern mailing list replacement software like Discourse do it correctly too. Even good old Mailman can be configured correctly. Now is the time to care!
I hope you enjoyed this article. Contact me if you have any thoughts or questions.
© 2015—2024 Sam Parkinson