It sure seems like I am having a lot of debates with my co-worker lately about the nature of mail filtering. Why do I say this? Because I had one today. This one is over the issue of trust.
I can’t remember whatever it is we were discussing (I think it was something to do with product planning) and somehow we got onto the issue of how Outlook renders messages to the user. Microsoft Outlook is capable of richly rendering an HTML message – images show up, links embedded, perhaps a cookie is enabled. Other times, such as when a message is in the Junk Mail folder, the message is “flat”, that is, links are disabled, images are not displayed and certainly no cookies show up. The question we have is when should Outlook do such a thing as render the message? Notwithstanding those of you who believe that all HTML should be plain text, this kicked off a debate between myself and my co-worker. We were trying to figure out the best user experience for the average population of computer users, and how email software should figure out when it should take action by default to enhance the email that users see.
My position is that mail should be rendered (automatically, not with the user clicking “Show Images”) if it meets two conditions:
- The message is not marked as spam by a content filter. If a message is spam, it can have malicious links embedded or junk content. If it comes from a user you trust but is marked as spam, that message should not have the content rendered either. The message is a false positive (note that this excludes a safe sender because mail from safe senders should not be marked as spam – it should skip spam filtering).
- The sender of the message can be authenticated. You should only render the messages from people whose identity you can trust. If you have a particular newsletter that you always want to hear from, then if they authenticate their mail using SPF, SenderID or DKIM and one of those checks passes (and none of them fail), then you know who you are communicating with. Trust is explicit because the sender of the mail is providing you an audit trail to come back to them if they start sending abusive content.
Combining these two conditions, you will be in a situation where you can trust the user and trust your spam filter. You are enhancing the end user’s experience and making a best-guess effort to determine that the sender’s content can be trusted.
By contrast, my co-worker has a different point of view. He claims that mail should be richly rendered if it meets the following one condition:
- The message is not marked as spam by a content filter. This is the only condition that is necessary, and it means that trust is implicit. The reason that this is the only condition that is necessary is that if you require something in addition to this, you are saying that you do not trust your filter to make the correct decision. Sure, it gets it right most of the time, but not all of the time. By admitting that you are not getting it right all of the time, this is bad for public relations and that your filter is not up-to-snuff.
I disagreed with this point of view; in fact, I was very surprised that he held it. If my position is correct, then what are the trade-offs? The benefit is that if you do get a false negative, then you will not richly render the message by default. So, if it is phishing, it won’t look like it came from Bank of America or Facebook. The links will be disabled by default. The drawback is the following: most mail that we deliver is not marked as spam. It is also a reality that a large proportion of senders still do not use any authentication technique at all, so we will not be able to richly render the message in advance (SPF/SenderID none, and no DKIM validation). The user sees a flat message for a large number of messages in their inboxes.
If my co-worker is correct, then what is the trade-off? The benefit is that more messages are shown to the end-user with messages rendered richly. It looks better and is more visually aesthetic. But the drawback is that of abuse. The fact is that I live in the real world when it comes to email, not some idealized world where false negatives never occur. That world just doesn’t exist. And in email, anyone can send mail as anyone. Some of these will trickle into the end user’s inbox. When it does, if we render the image richly then we are rendering spam automatically. Since there’s no way to verify who the message came from the end user ends up tricked. By automatically rendering all messages that you don’t mark as spam, you are widening your attack surface.
In my view, trust should be explicit, not implicit. If you think about real life, you don’t trust everyone you meet by default. You have a close inner circle of friends and family whom you trust with various things (keys to the house, financial details) but you certainly do not extend this trust to strangers. You extend trust to people when you have already established a pre-existing relationship, and you validate their identity usually visual indicators (you can see them) or audio indicators (you hear their voice), and so forth. This is similar to email; in lieu of a pre-existing relationship a spam filter scans the content and determines that it is legitimate. But at the same time in real life, a stranger can offer you a lollipop. As we all know from childhood, you shouldn’t take stuff from strangers, in this case a lollipop. And with email, a filtering scan might say that the content is legitimate, but your software shouldn’t promote the message (richly render it) unless it can also establish that it can be traced to an identity. Without that identity, trust must not be extended. Who knows what’s in that lollipop?
That’s how I see it (remember, we are talking about the default action of the mail client, not someone manually clicking to always trust messages from so-and-so). Without reputation, and putting that reputation on the line, anyone can do anything.