BIMI

Back in 2000 I was working on a Vignette Story Server implementation of soccer/football websites for most of the Premier League, Division 1, 2 and 3 clubs. One requirement that came my way was to generate a graphic of the starting line up of each team for each match, complete with numbered shirts overlaid in the correct formation. The web design team mocked me up a 3D pitch in Adobe Illustrator which they exported to, then brand new, SVG file format. My bit of Java would import the formation, overlay and rasterize using Apache Batik to a GIF file that we could store on Vignette.

The rasterization step was only necessary because the browsers of the time couldn’t handle native SVG. It will only be a couple of years, I told my colleagues, before you can ditch that Java code. In fact, it was eleven years before Microsoft added SVG support to IE 9 by which time I would imagine every club had ditched Story Server.

I was reminded of this last week as we pushed our implementation of Brand Indicators for Message Identification (BIMI) live. I’ll get to why in a minute but a quick segue into what BIMI is if you’re unaware:

The fundamental protocols for email date back to the early Eighties when all senders could be trusted and traffic volume was low. As email popularity increased so did attacks by bad actors. Over time, a number of optional protocols emerged to reduce attacks and abuse. The key ones, from a BIMI perspective, are:

• Sender Policy Framework (SPF) which tells recipient email systems which servers are permitted to send e-mail for a specific domain
• Domain Keys Identified Mail (DKIM) which digitally signs e-mail headers to permit the recipient system to validate the e-mail is not a forgery
• Domain-based Message Authentication, Reporting and Conformance (DMARC) which tells recipient systems what to do with the email if the first two standards are not met as well as how to report issues.

BIMI provides a way to attach a organization’s logo to their domain name such that a recipient system can display their logo alongside emails from that domain. The goal here is to increase confidence in the recipient that the e-mail really is from the sender and not a fake.

Technically this is achieved by placing a new DNS TXT record in the sending domain that references the logo. To prevent forgery, the logo can be verified by a third party, such as Entrust, who matches the registered trademark of the organization to the logo and validates the identity of the organization, signing the DNS record so it cannot be altered.

In practice, the logo must be validated and signed for it to render in Gmail (see example for Progressive Insurance above). Further, the sending organization must have implemented DMARC: a good motivator to get that done.

Having gone through this end-to-end, BIMI is the simple bit. As long as your trademark matches what you wish to render, BIMI is just paperwork and a couple of DNS records. By contrast, the journey to full DMARC compliance takes time as you work through all the sources of e-mail in your org you never knew about.

So that’s BIMI. Where do Microsoft fit in? Well, somewhat like SVG, they have a competing standard. A VML if you will: successfully sign up your business for Bing Pages and they will render your logo in Outlook.

Trouble is, Bing Pages is really positioned for consumer rather than business facing brands. From the FAQ:

If you have a public Twitter account, a public social media profile with at least 100 followers, and have made a post on one of the accounts in the past 30 days, you may apply for a Bing Page. Some types of social media presences that are best suited for Bing Pages include influencers, bloggers, brands, small businesses, musicians, artists, athletes, and websites, among others.

So, here’s hoping that Microsoft will take less than eleven years to implement BIMI. In the meantime, Kudos to Yahoo, Google and others for getting this done and helping to reduce the risk of business email compromise.