Re: [Bimi] (non)desire for bimi

Thede Loder <thede@skyelogicworks.com> Mon, 18 February 2019 16:31 UTC

Return-Path: <thede@skyelogicworks.com>
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 F0D3D130F2D for <bimi@ietfa.amsl.com>; Mon, 18 Feb 2019 08:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com
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 m-U-kLhLP97r for <bimi@ietfa.amsl.com>; Mon, 18 Feb 2019 08:31:07 -0800 (PST)
Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5291E1277D2 for <bimi@ietf.org>; Mon, 18 Feb 2019 08:31:07 -0800 (PST)
Received: by mail-yw1-xc41.google.com with SMTP id n12so6635918ywn.13 for <bimi@ietf.org>; Mon, 18 Feb 2019 08:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IU/AotxQk7o8GZn+fZKVYjL24uyJ8fiPQFDWlZ6Q6bE=; b=uq2JSbiv9o4Ynx5IsvuyZkygqqgDHCQO993+dYqngOBkbO8YK1GelpZTNDqVhhDUN/ /FAhyAyvaMuFD4lARV8ERBgfo108q/luTq/OxGGMD5cbZkHTSXZvgbaJF/iRDagi+Hy5 JQMwy6pGQZZApkITbRDS5FC7Z1aMdrpm+Y96k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IU/AotxQk7o8GZn+fZKVYjL24uyJ8fiPQFDWlZ6Q6bE=; b=rHFzrzGSTSYprjEUw2vl+MwAYVwc1pxW8aDw04knRdEgDRO0bGZKCs+BdzW7LibRkg Xd6Tgc6yPE3n99AcCYRcrAfXo850fRsoHJ9cldrUXreT6EbXRwUv1vnOqi+7mJlg9pKt 0LMiOyzGlZzkSOOqR15yblkVweCpO1U+k4szYEgJKrrHW5+ik4ueQtqByagLZBJK2pWh FVBX4fUvkAAYyk5YQtdfk+G5WA3G7S9zba9NrDFhzp439P7Eu73kSkJtsvhPEAqVIJiJ 5nMN4nZM5sv0D+Qr6/mhTsUmNPAqOMBcy2XY266nw2ry6FQzsRb7wj8HWYeCYnUqhsCE s9xQ==
X-Gm-Message-State: AHQUAuaQcuTvvmzbHOGsFWKI0Fwdx04+P8TFF7Kyx18lMnQn1XAeiMa+ 6edbDk4I27WTNG1TBSrA/35+We8ZB3Y=
X-Google-Smtp-Source: AHgI3IaCDAT+iq1LGqB+Cc7gGlGD0mIyN5aAtCD3u7YGjNIwVTCY/zCF6s7ZKdIKJwY0lvaxwOPfGw==
X-Received: by 2002:a81:6c17:: with SMTP id h23mr19290947ywc.250.1550507466220; Mon, 18 Feb 2019 08:31:06 -0800 (PST)
Received: from ?IPv6:2620::690:7822:d07c:b578:21eb:1ff9? ([2620:0:690:7822:d07c:b578:21eb:1ff9]) by smtp.gmail.com with ESMTPSA id t136sm7045699ywe.101.2019.02.18.08.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 08:31:05 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Thede Loder <thede@skyelogicworks.com>
In-Reply-To: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie>
Date: Mon, 18 Feb 2019 11:31:04 -0500
Cc: "bimi@ietf.org" <bimi@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com>
References: <aa919aeb-caa1-6494-259d-a553b238c268@cs.tcd.ie> <BL0PR11MB3107712FFFD2D92E911B909DA9670@BL0PR11MB3107.namprd11.prod.outlook.com> <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Terry Zink <tzink@terryzink.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/07xhHD6xVrfzHFg-Keh7F2ipNkQ>
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: Mon, 18 Feb 2019 16:31:10 -0000

> On Feb 14, 2019, at 13:44, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> On 14/02/2019 17:08, Terry Zink wrote:
>> 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.

Hi Stephen, 

Knowing your personal dislike of HTML-based email, and also that ~1 billion  
people read HTML email messages each day, many of whom like seeing 
graphics, tables, and other mark up, would you have proposed back when 
it was being considered for standardiation that it should never be developed 
or standardized?  


> 
>>> 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.

Your fear is justifiable.  

One can imagine future anti-spam or anti-fraud systems.  They could  
include message scoring functions that assign messages 
from domains lacking authentication setup (or which do not have a valid 
VM Cert) lower scores.  And one can also imagine that this scoring 
strategy will have a larger negative impact on deliverability if too few 
other post-delivery derived reputation signals are available for a given 
sender.  In other words, low volume and newly registered domains.  

While potentially raising the costs differentially to prohibative levels 
for some of the “bad guys”, cost is also raised for those who were not 
causing harm under the original system design; the ‘good actors’ have 
increased costs to continue to to get what they had before.  

An analogy here from the offline world: “Because criminals abused 
ID-less open flying previously the norm for air travel, a system was 
implemented in which everyone must now present IDs at airports; 
if fliers do not have IDs they have to bear the costs of going out and 
getting them, whether or not they were a good actor or a bad actor.  “  


I think the relevant question is: 

If BIMI adoption contributes to a shift in the norms and certain costs 
associated with effectively using applicable existing media, on the 
balance, have we made these media better for the actors we care 
about?  


>> 
>> 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.

Tracking is a concern and my personal take is that I’d like to see it 
become either impractical or completely transparent (or both)?.   
Can someone from the Authindicators Working Group comment on
Stephen’s interpretation?   Stephen, can you point us to a section?  


> 
>> 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.

This is certainly a valid position, and thank you for stating it.  This is 
in part what having a dialogue is about.