An interesting question might be, how would you implement this for an MUA using IMAP without inbox style exposure...
You'd probably have to do it through your contacts server, ie CardDav. Server side, you could collect all of the avatars and populate them per-user into their Contacts data. That might have annoying aspects to the size of their contact data and the sync size, though you could automate population and pruning from the user's mailbox to their contacts data to somewhat control that. Otherwise, you could expand IMAP metadata with it, but there'd have to be some work to standardize that. Or create an X-face style header that's just added locally by the MDA. Are there that many IMAP based mail clients which feature contact avatars? Purely client-side versions would be challenged with the "high reputation" aspect of not just fetching any given one. I guess you could prompt the user, kind of the equivalent of "always load images from this sender", control the avatar and the images with the same per-sender flag. Brandon On Wed, Jul 22, 2020 at 5:06 PM Brandon Long <bl...@google.com> wrote: > > > On Wed, Jul 22, 2020 at 4:46 PM Jim Popovitch via mailop < > mailop@mailop.org> wrote: > >> On Wed, 2020-07-22 at 11:56 -0700, Marcel Becker via mailop wrote: >> > >> > On Wed, Jul 22, 2020 at 11:35 AM Jim Popovitch via mailop < >> mailop@mailop.org> wrote: >> > > On Wed, 2020-07-22 at 14:49 +0200, Sidsel Jensen via mailop wrote: >> > > > but if the effect is that it will drive up the adoption rate for >> DMARC then I am clapping my hands. >> > > >> > > "Once verified, the BIMI file tells the email service where to find >> the >> > > sender’s logo and the email service pulls that logo into the inbox." >> > > >> > > >> > > I don't think this is anything about DMARC, this is about inbox >> > > tracking. >> > >> > Um. No. >> > 1: DMARC is required for BIMI. >> >> Good, DMARC is good, but we don't need yet another standard to get DKIM >> and SPF into the wider use. >> >> > 2: A proper setup will proxy and cache the logo. eg: for us all you can >> track through BIMI is if our logo service is alive and well... >> >> I hope you understand that most providers don't care if your logo >> service is alive and well. Surely we don't need a spec for that. >> > > Once upon a time, there was the X-Face header... I guess we could have > updated that for some modern version > and sent it with every message. For better or worse, a lot of mail > clients these days include an avatar > for the author, and acquiring that avatar can be complicated. For the > larger mailbox services, there was usually > a proprietary way to set that avatar... iirc, for Gmail that meant > creating a G+ account for the email address > and setting the account profile photo. Obviously, a standardized way to > specify avatars across clients is > better than proprietary methods... but that leads to a bunch of other > questions when it comes to > validation and preventing "abuse" of the avatar... whether or not BIMI is > a great answer to that is probably > still TBD. > > >> Whether you understand it or not, if a proxy or cache fetches your logo, >> you can get very valuable data about inbox hit rate data, eg tracking. >> > > I think this highly depends on your MUA and it's model. If Gmail fetches > and > caches the images, and there's no method in BIMI for "per user" images, > then > tracking BIMI images is nothing more useful than "gmail received my > message." > > If the fetching comes from the individual client running locally on some > personal > computer or mobile devices, the tracking level would be higher... at least > on the > "first" hit, assuming they did any caching at the client level. > > This is all based on my assumptions about how this is all implemented, I > haven't read the spec yet. > > Brandon >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
