#tech breakdown

Over the last few months, I’ve received an absurd amount of spam through an email account I’ve maintained since I was a child. I’m sure this is just the result of my email being recycled into the hottest new credential dump on that dark web, but it doesn’t stop the fact that this has been a pain for me to sift through for emails that do actually matter.

Now, this an old Hotmail account, so it is what it is and I don’t expect any particularly special spam protection, but I am somewhat dumbfounded by how little protection there actually is. This spam isn’t clever, it’s not even good. It’s mostly random offers for “free gifts” targeted towards Americans who shop at large American businesses like Costco, Walmart, Marriott Hotels, etc. What it does do though, is make hard to discern emails of actual concern from ones that don’t matter. It could make it difficult for me to see a real alert about an account breach, purchases made to some kind of credit card, or some other malicious activity related to an internet service I use.

I don’t believe that anything was in active danger, but it did leave me thinking about how annoyed I generally am by the structure of email, and how lackluster the tools are to prevent this sort of attack. In my case, most of these emails had no actual sending address. This meant I could use a somewhat hacky workaround via Outlook’s limited rule creation tools to deny emails without content in that field from actually landing in my inbox. But why did it require my intervention to do this? Why doesn’t Outlook automatically deny emails that have incomplete sender information by default?

A brief look at SMTP

SMTP was developed as a close analogue to real mail. As a result, there’s two main requirements: a letter, and an envelope. The “letter” in this context is just the information displayed to you by your email client. Generally, it consists of the following:

A “From” field

A “To” address

The “Subject” line

The content of the email itself

That sounds sensible, right? Well, it would if there weren’t a couple of oversights. See, the “From” field, doesn’t actually need to be a valid email address. That can be whatever you want. Seeing as it’s an analogue to real mail, it’s the envelope that contains all the real information the server uses to direct the mail to its recipient. Its contents look more like this:

Sending address (and return-path)

Receiving address

This is what actually determines the sending address. It’s placed on the envelope and doesn’t have a defined format, nor does it need to match the “From” field, so providing nothing is perfectly acceptable. A return path is required, but it’s more akin to providing the address of the post office that sent the mail rather than exactly who to send it back to.

In traditional snail mail, this works fine because it’s quite difficult to mass-mail letters without some kind of industrial printing press and the cost to send each letter is generally prohibitive. On a computer however…well, there’s no cost, and you only need to write your letter once to send it to a million people as many times as you like. That said, there are legitimate reasons not to have a sending address. If sending on behalf of someone else, the sending address may not necessarily match the “From” field, or a system/service may need to send emails somewhere despite not being able to reply. Even so, I don’t believe there’s a reason to leave that field blank when dealing with internet mailing addresses, even if nothing can be received at it.

Why isn’t this a solved problem?

It is! Sort of. We can’t change SMTP itself as there’s simply too much infrastructure that relies on it and overall, it’s not actually a bad protocol for its intended purpose. Instead, much like an ogre, modern email has layers. These layers add security without disrupting the functionality of the original design, still allowing for SMTP to operate as it did more than 40 years ago.

Spam prevention is a core element of much of this design and the following security layers have been added over the last decade:

SPF Records - A way to check that the envelope was sent by the server in the return path

DKIM - A signature added to the email to verify that it was sent by the address in the “from” field

DMARC - The set of rules on how to handle emails that fail one or both of the prior checks

SPF is a bit like a postage stamp. You know it was sent via an actual postal service rather than someone just stuffing it in your mailbox. Unfortunately SPF easily faked (see here) but still provides a good baseline when used in conjunction with DKIM. The trouble is that without DMARC, SPF and DKIM are just additional information.

DMARC is a co-operative check between the recipient email server and the owner of the sending address that allows receiving mail servers to check back with the supposed “sender” domain on how to handle emails that fail either DKIM or SPF checks.

Of course none of this helps when your email provider simply doesn’t care about DMARC at all. When I said it was “co-operative”, I meant it. A system can do all the work it wants setting up records to instruct recipients on how to tackle unapproved senders, but it all goes to waste if the receiver doesn’t perform the checks it needs to, or simply passes along emails from domains with no configured DMARC records.

I like email. It’s one of those bastions of the internet that make it possible to connect with people no matter where or when they are. It’s worth protecting the ease of use it provides, while bolstering the infrastructure around it to make it more difficult for malicious actors to do with as they please. Your email address is important, and it should be treated as such. As someone who works in a technical field, I get a very direct look at how things like DMARC and DKIM are effective when applied properly. Yet these tools are just not accessible to regular users of email services the same way as they’re accessible to businesses and large organizations and I think that’s inexcusable when so much of our life revolves around it.