Mailsploit, a set of vulnerabilities in mail clients revolving around a failure to sanitize the sender display name of an injected null byte, has been a hot topic lately. These discussions put me in a mood to complain about every other silly thing that mail user agents (MUAs) don’t do.
It seems that everyone is so desperate for the mail to keep flowing that nobody bothers to take responsibility for the file being a properly formatted RFC 5322 internet message. This is absolutely mind-boggling. Email is your front door; it is usually open by default to any sending domain or user, and non-enterprise users have no access to more sophisticated email analysis engines or malspam filters.
I’ve given gushy talks about how great DMARC is for protecting one’s domain, but the reality is that even a simple nickname impersonation attack would cruise right by the average user and never show up on your daily aggregate DMARC report. It doesn’t even need to have a fancy null byte injection — just set your display name to potus@whitehouse.gov or the name of the CFO of your target organization. If you find a Google group on the domain in question that accepts outside mail, it will even reflect the envelope sending information as being from the target domain.
Due to all these problems, I propose MUAs not honor display names unless the user has the sender email address saved in their contacts. I would also display the full envelope From address next to the body From address by default. Consider flagging the message as spam if the display name is itself an email address which does not match the accompanying sender email address in the remainder of the From field. A From field that exceeds some sane character maximum should also be flagged as a likely injection attempt in the vein of Mailsploit.
DKIM implementations are also a bit sloppy, in that I can easily insert malicious versions of already-signed fields as long as I leave the originals which correctly pass verification. This article has great screenshots to show how Gmail displays mail like this. A somewhat clunky workaround is allowed for in the RFC, which says that the same field can be signed multiple times, even if it only appears once, and any additional values for that header will be interpreted as blank. It follows that one could prevent one’s own messages from being replayed by signing all required fields once more than they are present at send time (“oversigning,” as it is termed in opendkim). If anyone attempts to replay the signed fields in the future, the values will not be blank and thus the verification will fail.
However, that safeguard should not even be necessary because most of these fields are illegal to have more than once, such as Subject, Message-ID, and From. MIME fields exhibiting similar strange behavior, such as multiple boundary break definitions in Content-Type, are also obviously suspect and candidates for better preemptive screening.
If one sought to profile mail from a particular address, several fields provide information about the ways the message was sent and moved through the internet. The Message-ID gives us clues as to what program generated and sent the mail. Trace fields or envelope information could reveal an unusual relay. A sudden appearance of a Sender field indicating an unusual mailbox delegation should also raise alarms.
This is all without addressing the problem of email being a postcard visible to all carriers unless the message is an encrypted blob before it transits any network, because TLS downgrade attacks are still the norm. S/MIME is widely supported by mail clients on desktop and web, but is clunky and relies on a hierarchical PKI. I would skip dealing with MIME and use OpenPGP for encryption, which relies on a web of trust. Web-based email folks can use a browser extension like Mailvelope, but desktop clients have plugins for PGP as well. The most important thing that encryption provides is trust that, as long as the sender didn’t lose control of their private key, it’s really who it claims to be. The ideal would be having all entities with whom you want to exchange email use either PGP or S/MIME.
In short, MUAs need to concentrate more on how users add contacts and trusted paths of communicating with them. Making PGP and S/MIME easier is the best way to go, but a user-friendly way to display more information about the sender plus a simple historical analysis engine would also be a huge gain in this area. Trust less, verify more.
