[Bimi] Fwd: bimi Digest, Vol 10, Issue 2
Marcel Bokhorst <marcel@faircode.eu> Fri, 30 July 2021 07:57 UTC
Return-Path: <marcel@bokhorst.biz>
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 2E2C33A20E7 for <bimi@ietfa.amsl.com>; Fri, 30 Jul 2021 00:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=faircode.eu
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 tjYvNXycnz8i for <bimi@ietfa.amsl.com>; Fri, 30 Jul 2021 00:57:54 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 C6B523A20E5 for <bimi@ietf.org>; Fri, 30 Jul 2021 00:57:53 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id l17so11188030ljn.2 for <bimi@ietf.org>; Fri, 30 Jul 2021 00:57:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=faircode.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wIoryagWfGUaaGHvJF4r13XrAI0Voa40Eiuk6bTt0fA=; b=AYdQ66TUSS5I7VTapDU57U+OET3q8D6ZWKocJdY7vPVWop5GG2//XR8sdigkDgvXEf pjoqBZI7G4nEGhHZBZ0LMisEFEzYP4gKRUCbCusF323QJy7TgshkpAB0ikFoHgdrr+nD 21S1bKNcf8H3jysbAT6CLKwDAyjsa6xpdBnk5ZoUuZOPZXJT2dlGrNEtQHhmcisfvh46 PwKmazfwPDJxsucGKtPv1pm6clWR6mobhagGJunPxse9UJ6YvUf/6xF+Smhp/QyIGnUC yHxG7oxqwA+dTyE8J/tGBl0N5scR4LWV8akuqsdWJIHyCkBGPTRishFi6Zxxu5gtsF6H pOUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wIoryagWfGUaaGHvJF4r13XrAI0Voa40Eiuk6bTt0fA=; b=Y6TGfjMCjlebATcvDPC3DaN9lxcFAqLgBuMtClCj0BKXKuGIXPNWTDVNflXH341N8C VCQQtCDF2df6Msz1kyErkIC9nTimvYqwddVUGs34VBQiQgeIXmU7vDv+9WPyOlt52wFC mOOy/0ovuussC6LSpMW1Ype0SqDkAJkCZmmQ1Hr2gkjOOaStecqLt2CYPYCOHnhGAG38 UsjoU10EzAhqPpvfaLcqcuj5LFpJY/EIBiqalPeFYB1NzgrWLpLDpm9kPUps275BE4Vq FQC3YksJKLPvtpdB9Ff6YelQVsBGqLXtLj1WZSsfcGQLIJcCY4jn9YVUk/BX5ByW+HOq 6bcA==
X-Gm-Message-State: AOAM53150YcSQS45ANPpj84HyTnW3fZXerTChM+A5vPPAHiT7gOL2x5h ARtR26ZiCxMv7riZdO7S+NpT21KnT7OynBth2Ee5JAksllI=
X-Google-Smtp-Source: ABdhPJyVwWH1JcMLnQI2DXSu9Cho5Eg2SClwjNIybF0zF0GIQew433jOz8eqENwOmpdQ2io5hr4Vfh7WoHeaALnN1PM=
X-Received: by 2002:a2e:92c6:: with SMTP id k6mr857448ljh.100.1627631870156; Fri, 30 Jul 2021 00:57:50 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.3635.1627587941.6855.bimi@ietf.org>
In-Reply-To: <mailman.3635.1627587941.6855.bimi@ietf.org>
From: Marcel Bokhorst <marcel@faircode.eu>
Date: Fri, 30 Jul 2021 09:57:23 +0200
Message-ID: <CAFLkOerrax+qYyaR_u1SJH6xQH_asxqbzd=rb4AWKwYudZodCw@mail.gmail.com>
To: bimi@ietf.org
Content-Type: multipart/alternative; boundary="00000000000072328305c8529352"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/A_X0Nbp5yEPoGovwQuTPTRw_bUI>
Subject: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2
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: Fri, 30 Jul 2021 08:42:54 -0000
FairEmail will not rely on the BIMI-Location header because this requires support from the email server. Instead, FairEmail will use the logo in the VMC and fallback to the DNS record logo location if needed (logo missing in the VMC, etc). The logo will always be shown, but the verified sender icon (a double check mark before the sender's name) will be shown only when everything checks out. I think it would be a good idea to summarize the steps to follow to fetch/decode/check BIMI because I think it will make it easier for developers to implement BIMI and to do this in the right way. The BIMI TXT record is always being fetched from the top level domain ( example.org). I hope this is correct. An IMAP flag would be nice, but I guess it will take quite some time until all email servers are supporting this. Something like a signed authentication results header would be nice, as long as it can be checked in a simple and efficient way. For example heavy cryptographic operations and looking up DNS records (for certificates, etc) would result in slow downs and increased battery usage when downloading many messages. Currently, the authentication header inserted by the email server is just being trusted, but this relies on either inserting the header by the receiving email server or removing previous headers of intermediate email servers. FairEmail will cache the logo for two weeks, which is the same as for favicons. IMHO this is a reasonable default, preventing logos from being fetched too often and still allowing to change the logo by the sender (which I guess won't happen too often). I hope this clarifies things, else feel free to reply. Marcel Bokhorst (author of FairEmail) ---------- Forwarded message ---------- From: "Brotman, Alex" <Alex_Brotman@comcast.com> To: Trent Adams <tadams=40proofpoint.com@dmarc.ietf.org>, "bimi@ietf.org" < bimi@ietf.org> Cc: Bcc: Date: Thu, 29 Jul 2021 19:45:04 +0000 Subject: Re: [Bimi] Independent BIMI-capable Email Client I do have that app, but I haven’t yet pointed it at a platform utilizing BIMI. I’ll make a note to give it a try. >From below: - They aren't entirely clear on how (or why) to evaluate a logo referenced by the BIMI record and the one retrieved from a VMC. What about the BIMI-Location header instance, if present? (assuming you want to trust that header, etc). After that, I’d probably use the VMC if present. Should we add an evaluation path to the core document? - It's also not all that clear where to retrieve the BIMI logo when the email is sent from a subdomain, and match that up with the DMARC results. I’m not sure I follow the issue here. Is there some example that shows the questionable path? - There's also the question about whether or not an independent client can/should trust the authentication results performed by the mailbox provider when deciding to display the BIMI logo. If you go back to -00 of the core spec, there was an IMAP flag that was meant to be set (Section 8.6). That was removed in -01. I don’t recall the justification, but may have had to do with MUA workload. Seems like the IMAP flag could be reintroduced (POP3 would be an issue though). Or perhaps something akin to a DKIM signature signed by the inbound MTA that could be verified by the MUA. The latter could potentially be reused though? - There is a non-zero addition of processing required by the client to handle BIMI, leading to the question about what impact this may have on a client... and what efficiencies can be introduced with local caching (if any). I’d think at least equivalent to the TTL of the BIMI DNS record, perhaps even up to the expiration of the VMC (though I could understand where a domain holder could refresh their VMC and change logos, etc). I’m sure there’s a better answer somewhere in between. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast *From:* bimi <bimi-bounces@ietf.org> *On Behalf Of *Trent Adams *Sent:* Friday, July 23, 2021 5:36 PM *To:* bimi@ietf.org *Subject:* [Bimi] Independent BIMI-capable Email Client Since Gmail's announcement, more companies are starting to play around with BIMI (no surprise there). And, as expected, the increased attention is helping to put more eyeballs on the experiment. And while some of the major mailbox providers are adding BIMI support to their own mobile clients, I ran into a FOSS project run by a developer in the Netherlands who has already added BIMI to their independent mobile mail client. If you get a chance, I'd suggest taking a look at their FairEmail implementation as they made some interesting choices: https://email.faircode.eu/ <https://urldefense.com/v3/__https:/email.faircode.eu/__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfdsADeC4$> The current Android client package can be downloaded from their GitHub repository: https://github.com/M66B/FairEmail/releases <https://urldefense.com/v3/__https:/github.com/M66B/FairEmail/releases__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHf2gwnAj4$> So far, they've already found some useful results from their experiment. And now we're finally at a point where we can test the architecture (and pressure-test the specifications) beyond the handful of usual suspects. For example, here're a few issues this work as already surfaced when interpreting the specifications [1] [2] [3]: - They aren't entirely clear on how (or why) to evaluate a logo referenced by the BIMI record and the one retrieved from a VMC. - It's also not all that clear where to retrieve the BIMI logo when the email is sent from a subdomain, and match that up with the DMARC results. - There's also the question about whether or not an independent client can/should trust the authentication results performed by the mailbox provider when deciding to display the BIMI logo. - There is a non-zero addition of processing required by the client to handle BIMI, leading to the question about what impact this may have on a client... and what efficiencies can be introduced with local caching (if any). What I found most interesting was how the specifications assume a tight coupling between the client and the mailbox provider. It definitely opens the question of whether it's possible (or recommended) for an independent client to support BIMI even for email received by mailbox providers that don't support it. It's real-world interop testing like this that I hope will highlight issues that need to be discussed as the experiment continues. Also, if anyone would be willing to test the FairEmail client, I'd be keen to hear if you think that the way it leverages BIMI matches your expectations. Also, are there any others out there that might contribute their learnings to the conversation? Anyway, thanks for any feedback you may have. It'll be useful to hash out ideas for improvements and next steps on the list. Cheers, Trent [1] https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfVUyABq4$> [2] https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfIMZn7Z8$> [3] https://datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfQyodXbk$> -- *J. Trent Adams* *Director, Ecosystem Security* *Proofpoint* tadams@proofpoint.com bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi
- [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marcel Bokhorst
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Brotman, Alex
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marcel Bokhorst
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Todd Herr
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marcel Bokhorst
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Jakub Olexa
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Trent Adams
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marc Bradshaw
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Dave Crocker
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marcel Bokhorst
- Re: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2 Marc Bradshaw
- Re: [Bimi] bimi logos from non-giant companies John Levine