Re: [Bimi] (non)desire for bimi

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 14 February 2019 18:54 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: bimi@ietfa.amsl.com
Delivered-To: bimi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38F12426A for <bimi@ietfa.amsl.com>; Thu, 14 Feb 2019 10:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTCbL8bF9Oh8 for <bimi@ietfa.amsl.com>; Thu, 14 Feb 2019 10:54:18 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACD71200ED for <bimi@ietf.org>; Thu, 14 Feb 2019 10:54:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D65ECBE38; Thu, 14 Feb 2019 18:44:44 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1qbxMlt3KaW; Thu, 14 Feb 2019 18:44:43 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0761BE20; Thu, 14 Feb 2019 18:44:42 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550169882; bh=WjaJQt3X9Tthl7xRwYpScjXi/oqXolrzAmWC0rH5CHI=; h=To:References:From:Subject:Date:In-Reply-To:From; b=yFemC4+W6KReaM7SULKzhDt0FVBNUslqyeTRjEaZxj4d7AqzdmM7hLwzXiOTtxTWZ qW3WPq6ksPMYKo5NBJXchBPO9CZSNO+2YF/M3aZT/JcISJ2u3OHrzE25YbdDRQJ4aX eNJiKZRRXuYut0WugchqUT0uglJ3/2YXYE8YGt8U=
To: Terry Zink <tzink=40terryzink.com@dmarc.ietf.org>, "bimi@ietf.org" <bimi@ietf.org>
References: <aa919aeb-caa1-6494-259d-a553b238c268@cs.tcd.ie> <BL0PR11MB3107712FFFD2D92E911B909DA9670@BL0PR11MB3107.namprd11.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie>
Date: Thu, 14 Feb 2019 18:44:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <BL0PR11MB3107712FFFD2D92E911B909DA9670@BL0PR11MB3107.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="t9wpQ5V5bYySZWvkKB8HfSQQyxqYM5JvC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/76kbJpl1b_89ZYj0i6pT3c1zCtA>
Subject: Re: [Bimi] (non)desire for bimi
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Brand Indicators for Message Identification <bimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bimi>, <mailto:bimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bimi/>
List-Post: <mailto:bimi@ietf.org>
List-Help: <mailto:bimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bimi>, <mailto:bimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 18:54:21 -0000

Hi Terry,

(I agree with both John and Dave's points upthread so will try
not repeat those, but I'm happy to elaborate if it's useful.)

On 14/02/2019 17:08, Terry Zink wrote:
> Thanks for your comments, Stephen. Here are my thoughts.
> 
>> I'd be interested in some kind of verifiable backup for that "clear
>> demand" claim
> 
> To me, it seems intuitively obvious. For example, in the Office 365
> web interface, I see logos from several different companies in the
> list view and the sender photo when I open the message - Amazon,
> Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is
> displayed via Microsoft's Brand Cards program). My old Yahoo Mail
> interface has something similar. For a while, Gmail showed a company
> logo pulled from its Google+ page.
> 
> How does this not show demand? Isn't this an example of web mail
> providers wanting to enhance the user experience, and companies
> happily obliging, and me as a user being pleased?
>
> I am not representative of the entire space, but I really *like*
> those sender photos.

Right. And nor am I representative in my dislike of such.

> 
>> I use the Internet. I do not want logos added to mail headers that
>> increase the attack surface of my MUAs, (and MS/MTAs), that likely
>> enable additional tracking of mail users, including me, and where
>> mobile device and web MUAs are unlikely to offer me an option to 
>> turn all that off, even if some desktop MUAs might (eventually), at
>> the risk of making messages harder to comprehend.
> 
> I'm not sure I understand this comment. 

I'm not sure which bit of my para above you mean. If it's the last
point - I often get mail now where substantive parts of the mail
are only present in HTML and I don't render that in my latop MUA,
which forces me to occasionally delve into the raw message to
find out what some correspondent means. The desire for dancing
kittens in HTML body parts does sometimes make emails less
comprehensible. I reckon incorporating images as per bimi would
have a similar effect.

> The logos are not added to
> mail headers, but instead headers point to a location where the logo
> can be picked up and then shown to the end user. What's the
> difference between the sender/brand providing an authoritative source
> (DNS record that points to a CDN) vs Office 365/Yahoo pulling from
> their own internal database?

Aside from John and Dave's points another difference is that I
don't need to care about the latter, (as I don't use 'em)
whereas where bimi a standard that got deployed then my MUA may
add such (from my POV) broken-ness.

>> I also just do not want to see your logos, thanks.
> 
> Again, I am not sure I understand this comment.

John answered that I think.

> Logos are everywhere. Most large companies have Facebook and Twitter
> pages, and they all have logos. You see logos painted on the sides of
> walls, on stores, on TV, in newspapers, on web pages, as favicons,
> etc.
> 
> Are you saying these are all fine but in the sender photo it isn't?
> What's the fundamental difference between seeing a company's logo in
> the sender photo vs seeing it in the body of an email? Is it just a
> matter of turning of HTML and preventing those from loading?

I don't see sender photos and do not render HTML, except on
mobile device MUAs where I do not get that choice, which is,
for me, negative. Were bimi standardised it is entirely
unclear to me how various MUAs might handle it. But I very
much doubt that mobile device MUAs would provide that level
of user-control for bimi as they do not for bodies. And all
of us here are likely far more capable of configuring things
than most users.

>> As someone who sends email (not as a bulk sender) from various
>> domains that I operate, I do not want to pay €€€ to someone for an
>> additional cert, nor for an "approved" logo, in order to increase
>> the chances that my mail gets delivered.
> 
> Nobody is going to make you buy a cert, nobody is going to make you
> buy a logo, and so forth. It's up to you.
> 
> BIMI is an add-on; it augments the default experience, the lack of it
> doesn't downgrade the default experience.

Perhaps. Nonetheless there is at least one large mail service
that sends all mail from some domains I operate (that have never
sent spam and that have had stable IP addresses for years, DKIM
etc all good) to /dev/null and who won't respond to any form of
poking to try get that fixed despite a number of attempts. And
that provider is used (as MX) by people with whom I do need to
correspond, so I'm forced to use a different mail a/c to mail
those folks.

Yes I do indeed fear that bimi could and would be (ab)used by
some services to do more such dis-service. ISTM that damages
the mail environment rather than enhances it.

>> I also do not want to have to check if someone else has abused a
>> logo I may use in some CT log. I do not want to have to process
>> additional headers in my MTAs nor retrieve and store your logos in
>> some new image store. I do not want to have to deal with any of the
>> new problems that'll arise when any of that breaks.
> 
> Again, I'm unclear about the context of this statement. Nobody is
> going to make you as a sender, brand, or receiver send with BIMI.

I'm afraid that continues to be a concern of mine. (As an aside,
I am not a "brand" and have no ambition to become one:-)

> Nobody is going to make you retrieve logos from a store, nobody is
> going to make you verify any log, nobody is going to make you process
> additional headers.

In fact, my reading of bimi is that it does attempt to force a
receiving MTA/MS to actively download the image(s) and replace
the URL with one pointing at the MS (or nearby) - not doing so
would expose users of the MUAs using that MS to tracking once
those MUAs de-reference bimi URLs from the sender.

> Instead, it's about enhancing the email experience for those
> motivated to do so. And, BIMI provides a way to do this.

I realise that's your/the proponents position. Mine is that
bimi is only a negative.

Cheers,
S.

> 
> --Terry
> 
> ________________________________ From: bimi <bimi-bounces@ietf.org>
> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie> Sent:
> Thursday, February 14, 2019 2:57 AM To: bimi@ietf.org Subject: [Bimi]
> (non)desire for bimi
> 
> 
> (Sorry for not replying in-thread but I just subscribed to the list,
> and this perhaps also deserves a separate thread.)
> 
>>>> * Internet users want it - clear demand
>>> 
>>> That claim keeps being made but I've never seen any serious 
>>> documentation for it.
>> 
>> Marketing people want it -- that may not be documented but I have 
>> sufficient anecdotes to hand to believe it be the main driver
>> here.
> 
> I'd be interested in some kind of verifiable backup for that "clear
> demand" claim - I'm unaware that such exists, other than perhaps as
> Richard says for marketing purposes, and ISTM those purposes are
> amply met already via mail bodies.
> 
> Meanwhile...
> 
> I use the Internet. I do not want logos added to mail headers that
> increase the attack surface of my MUAs, (and MS/MTAs), that likely
> enable additional tracking of mail users, including me, and where
> mobile device and web MUAs are unlikely to offer me an option to turn
> all that off, even if some desktop MUAs might (eventually), at the
> risk of making messages harder to comprehend.
> 
> I also just do not want to see your logos, thanks. Imposing those on
> me would decrease the utility of mail. And regardless of what PKI
> were built I would not treat bimi'd messages any better, more likely 
> I'd consider them badly.
> 
> As someone who sends email (not as a bulk sender) from various
> domains that I operate, I do not want to pay €€€ to someone for an
> additional cert, nor for an "approved" logo, in order to increase
> the chances that my mail gets delivered. Things in that respect are
> bad enough, and this proposal seems to me likely to only worsen the
> situation for those who operate small domains, presumably to the
> benefit of those who operate large mail infrastructures and CAs who
> issue certs for money.
> 
> I also do not want to have to check if someone else has abused a logo
> I may use in some CT log. I do not want to have to process additional
> headers in my MTAs nor retrieve and store your logos in some new 
> image store. I do not want to have to deal with any of the new
> problems that'll arise when any of that breaks.
> 
> So: No thanks, from me. Personally, as a mail user I only see
> downsides to this whole idea.
> 
> Thanks, S.
> 
>