It seems that the need for MX, DKIM, SPF, and DMARC records for modern email setups were just not enough acronyms (and setup tasks) for some folks, resulting in the creation of yet-another-acronym — BIMI, or, Brand Indicators for Message Identification. The goal of BIMI is to “provide a mechanism for mail senders to publish a validated logotype that mail receivers can display with the senders’ messages.” You can read about the rationale for BIMI and the preliminary RFC for crafting BIMI DNS TXT records over a few caffeinated beverages. I’ll try to TL;DR the high points below.
The idea behind BIMI is to provide a visual indicator of the brand associated with a mail message; i.e. you’ll have an image to look at somewhere in the mail list display and/or mail message display of your mail client if it supports BIMI. This visual indicator is merely an image URL association with a brand mail domain through the use of a new special-prefix DNS TXT record. Mail intermediaries and mail clients are only supposed to allow presentation of BIMI-record provided images after verifying that the email domain itself conforms to the DMARC standard (which you should be using if you’re an organization/brand and shame on you if you’re not by now). In fact, the goal of BIMI is to help ensure:
- the organization is legitimate
- the domain names are controlled by the organization
- the organization has current rights to display the indicator
When BIMI validation is being performed, the party requesting validation is currently authorized to do so by the organization and is who they say they are.
If you’re having flashbacks to the lost era of when SSL certificates were supposed to have similar integrity assertions, you’re not alone (thanks, LE).
What’s Really Going On?
I’m not part of any working group associated with BIMI, I just measure and study the internet for a living. As someone who is as likely to use alpine to peruse mail as I am a thick email client or (heaven forbid) web client, BIMI will be of little value to me since I’m not really going to see said images anyway.
Reading through all the BIMI (and associated) RFCs, email security & email marketing vendor blogs/papers, and general RFC commentators, BIMI isn’t solving any problem that well-armored DMARC configurations aren’t already solving. It appears to be driven mainly by brand marketing wonks who just want to shove brand logos in front of you and have one more way to track you.
Yep, tracking email perusals (even if it’s just a list view) will be one of the benefits (to brands and marketing firms) and is most assuredly a non-stated primary goal of this standard. To help illustrate this, let’s look at the BIMI record for one of the most notorious tracking brands on the planet, Verizon (in this case, Verizon Wireless). When you receive a BIMI-“enhanced” email from verizonwireless.com
the infrastructure handling the email receipt will look for and process the BIMI header that was sent along for the ride and eventually query a TXT record for default._bimi.verizonwireless.com
(or whatever the sender has specified instead of default
— more on that in a bit). In this case the response will be:
v=BIMI1; l=https://ecrm.e.verizonwireless.com/AC/Global/Bling/Images/checkmark/verizon.svg;
which means the image they want displayed is at that URL. Your client will have to fetch that during an interactive session, so your IP address — at a minimum — will be leaked when that fetch happens.
Brands can specify something other than the default.
selector with the email, so they could easily customize that to be a unique identifier which will “be you” and know when you’ve at least looked at said email in a list view (provided that’s how your email client will show it) if not in the email proper. Since this is a “high integrity” visual component of the message, it’s likely not going to be subject to the “do not load external images/content” rules you have setup (you do view emails with images turned off initially, right?).
So, this is likely just one more way the IETF RFC system is being abused by large corporations to continue to erode our privacy (and get their horribly designed logos in our faces).
Let’s see who are the early adopters of BIMI.
BIMI Through the Alexa Looking Glass
Amazon had stopped updating the Alexa Top 1m sites for a while but it’s been back for quite some time so we can use it to see how many sites in the top 1m have BIMI records.
We’ll use the {zdnsr} package (also on GitLab, SourceHut, BitBucket, and GitUgh) to perform a million default._bimi
prefix queries and see how many valid BIMI TXT record responses we get.
library(zdnsr) # hrbrmstr/zdnsr on social coding sites
library(stringi)
library(urltools)
library(tidyverse)
refresh_publc_nameservers_list() # get a current list of active nameservers we can use
# read in the top1m
top1m <- read_csv("~/data/top-1m.csv", col_names = c("rank", "domain")) # http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
# fire off a million queries, storing good results where we can pick them up later
zdns_query(
entities = sprintf("%s.%s", "default._bimi", top1m$domain),
query_type = "TXT",
num_nameservers = 500,
output_file = "~/data/top1m-bimi.json",
)
# ~10-30m later depending on your system/network/randomly chosen resolvers
bmi <- jsonlite::stream_in(file("~/data/top1m-bimi.json")) # using jsonlite vs ndjson since i don't want a "flat" structure
idx <- which(lengths(bmi$data$answers) > 0) # find all the ones with non-0 results
# start making a tidy data structure
tibble(
answer = bmi$data$answers[idx]
) %>%
unnest(answer) %>%
filter(grepl("^v=BIM", answer)) %>% # only want BIMI records, more on this in a bit
mutate(
l = stri_match_first_regex(answer, "l=([^;]+)")[,2], # get the image link
l_dom = domain(l) # get the image domain
) %>%
bind_cols(
suffix_extract(.$name) # so we can get the apex domain below
) %>%
mutate(
name_apex = glue::glue("{domain}.{suffix}"),
name_stripped = stri_replace_first_regex(
name, "^default\\._bimi\\.", ""
)
) %>%
select(name, name_stripped, name_apex, l, l_dom, answer) -> bimi_df
Here’s what we get:
bimi_df
## # A tibble: 321 x 6
## name name_stripped name_apex l l_dom answer
## <chr> <chr> <glue> <chr> <chr> <chr>
## 1 default._… ebay.com ebay.com https://ir.ebaystatic.com/p… ir.ebaystatic.com v=BIMI1; l=https://ir.ebayst…
## 2 default._… linkedin.com linkedin.… https://media.licdn.com/med… media.licdn.com v=BIMI1; l=https://media.lic…
## 3 default._… wish.com wish.com https://wish.com/static/img… wish.com v=BIMI1; l=https://wish.com/…
## 4 default._… dropbox.com dropbox.c… https://cfl.dropboxstatic.c… cfl.dropboxstatic.… v=BIMI1; l=https://cfl.dropb…
## 5 default._… spotify.com spotify.c… https://message-editor.scdn… message-editor.scd… v=BIMI1; l=https://message-e…
## 6 default._… ebay.co.uk ebay.co.uk https://ir.ebaystatic.com/p… ir.ebaystatic.com v=BIMI1; l=https://ir.ebayst…
## 7 default._… asos.com asos.com https://content.asos-media.… content.asos-media… v=BIMI1; l=https://content.a…
## 8 default._… wix.com wix.com https://valimail-app-prod-u… valimail-app-prod-… v=BIMI1; l=https://valimail-…
## 9 default._… cnn.com cnn.com https://amplify.valimail.co… amplify.valimail.c… v=BIMI1; l=https://amplify.v…
## 10 default._… salesforce.com salesforc… https://c1.sfdcstatic.com/c… c1.sfdcstatic.com v=BIMI1; l=https://c1.sfdcst…
## # … with 311 more rows
I should re-run this mass query since it usually takes 3-4 runs to get a fully comprehensive set of results (I should also really use work’s infrastructure to do the lookups against the authoritative nameservers for each organization like we do for our FDNS studies, but this was a spur-of-the-moment project idea to see if we should add BIMI to our studies and my servers are “free” whereas AWS nodes most certainly are not).
To account for the aforementioned “comprehensiveness” issues, we’ll round up the total from 310 to 400 (the average difference between 1 and 4 bulk queries is more like 5% than 20% but I’m in a generous mood), so 0.04% of the domains in the Alexa Top 1m have BIMI records. Not all of those domains are going to have MX records but it’s safe to say less than 1% of the brands on the Alexa Top 1m have been early BIMI adopters. This is not surprising since it’s not really a fully baked standard and no real clients support it yet (AOL doesn’t count, apologies to the Oathers). Google claims to be “on board” with BIMI, so once they adopt it, we should see that percentage go up.
Tracking isn’t limited to a tricked out dynamic DNS configuration that customizes selectors for each recipient. Since many brands use third party services for all things email, those clearinghouses are set to get some great data on you if these preliminary results are any indicator:
count(bimi_df, l_dom, sort=TRUE)
## # A tibble: 255 x 2
## l_dom n
## <chr> <int>
## 1 irepo.primecp.com 13
## 2 www.letakomat.sk 9
## 3 valimail-app-prod-us-west-2-auth-manager-assets.s3.us-west-2.amazonaws.com 8
## 4 static.mailkit.eu 7
## 5 astatic.ccmbg.com 5
## 6 def0a2r1nm3zw.cloudfront.net 4
## 7 static.be2.com 4
## 8 www.christin-medium.com 4
## 9 amplify.valimail.com 3
## 10 bimi-host.250ok.com 3
## # … with 245 more rows
The above code counted how many BIMI URLs are hosted at a particular domain and the top 5 are all involved in turning you into the product for other brands.
Speaking of brands, these are the logos of the early adopters which I made by generating some HTML from an R script and screen capturing the browser result:
FIN
The data from the successful BIMI results of the mass DNS query is at https://rud.is/dl/2020-02-21-bimi-responses.json.gz. Knowing there are results to be had, I’ll be setting up a regular (proper) mass-query of the Top 1m and see how things evolve over time and possibly get it on the work docket. We may just do a mass BIMI prefix query against all FDNS apex domains just to see a broader scale result, so stay tuned.
Drop note if you discover any more insights from the data (there are a few in there I’m saving for a future post) or your own BIMI inquiries; also drop a note if you have a good defense for BIMI other than marketing and tracking.
4 Comments
Good post!
I like the script you’ve put together to collect BIMI logos from the Alexa list. Great idea.
Question about tracking:
If the TTL (time to live) on a BIMI logo is 1hr and Yahoo wants to serve up the same logo to lots of ppl all day long, wouldn’t they just cache the image locally and serve it up to each individual who happens to login to their webmail?
It seems that you’re assuming that every time someone opens their Yahoo inbox all the logos will be loaded right then by requesting them from the link in the dns record.
I understand there is still tracking either way, but, as I understand it, the only impression data they’ll get is how often Yahoo (and other mailbox providers) refresh the logo, which will be pretty close to the TTL. So with my original numbers, Yahoo (not the individual user) will request the logo every 1hr. This does not sound like very detailed impression tracking for marketing. Would it be a privacy problem for any user?
On the issue of the IETF RFC system being abused: a Birds-of-a-feather session on BIMI at IETF 104 (Spring 2019). Based on the strong reaction of those present, I would be very surprised if IETF ever publishes an RFC on BIMI, even as an informational individual submission. There would be great pushback.
Hey there – Just curious, does the library still work? Been trying to get this ZDNSR installed and havent been able to get that package to install on any of my machines or setups. Just wanted to run this on the latest domains to see how BIMI support has evolved.
The pkg expects
zdns
to be onPATH
(and I have little incentive to modify it to suit other use cases). I suggest copying or linking thezdns
binary to aPATH
your R session knows about if you want the pkg to install and work.One Trackback/Pingback
[…] by data_admin [This article was first published on R – rud.is, and kindly contributed to R-bloggers]. (You can report issue about the content on this page […]