From nobody Wed Apr 7 13:56:14 2021 Return-Path: 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 90ED83A297E for ; Wed, 7 Apr 2021 13:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=comcast.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 I1HYHDWlAgop for ; Wed, 7 Apr 2021 13:56:08 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480213A297F for ; Wed, 7 Apr 2021 13:56:08 -0700 (PDT) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 137KqF7e008816 for ; Wed, 7 Apr 2021 16:56:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=nmj1akwnB02gy45/MGAB1kNxZvum82lUxQHsOa8p3s8=; b=nMaBlNdE1XvIM+hsOTMyu91UXiJnnj3hqS9lyzJ2qPJzTDERZOZ+MZEIcZJQdOepsay5 lBpqhCou4XsG4sDJiY6Q42Tu+f1E9fniICuS/5Brbthg53jufL9GCJBTTlLa2wtIr3Dk 1FLDIJBnqDOJinaS64SX1udaf20NHBZ2BWIWdw/y6aFQUPTv62ql6HQ5/1I7klsd79ga mnYMH38H7acqORnjebL9wOXcJYM830JpoN/AzR+EpukEsevv8KUBo8Ygh7HbCLkNZfc+ OdNL7XKiwS/BqQaxE+ALFrfKa//j6a3idX13d4O9wMbJVLuvSfox7eMnScmG10WKrDSL pg== Received: from pacdcex50.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 37sk0nrmv9-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 07 Apr 2021 16:56:07 -0400 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX50.cable.comcast.com (24.40.2.149) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 7 Apr 2021 16:56:06 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 7 Apr 2021 16:56:06 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.104) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 7 Apr 2021 16:55:40 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3458.namprd11.prod.outlook.com (2603:10b6:208:6a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.29; Wed, 7 Apr 2021 20:55:39 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4020.017; Wed, 7 Apr 2021 20:55:39 +0000 From: "Brotman, Alex" To: "BIMI (IETF) (bimi@ietf.org)" Thread-Topic: Guidance Document - Refactor input Thread-Index: Adcr8F041vqA26wUTEisW5zvmDHd0g== Date: Wed, 7 Apr 2021 20:55:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:6d64:8f71:58f8:6034] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 261676b0-4841-49b1-e3b9-08d8fa078042 x-ms-traffictypediagnostic: BL0PR11MB3458: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x6c0SBVasMAVJfXymvrYGO4GxKHzYKpcq9d+clXo3Bw5aM7nooPQ1Vju6TsoJ2jgHq5EIdeWhfcAS2Gwot4UolNwe20xjaNdVBFgBzPfCznaZDYDkKhyuNDChLQorY87j99qavZ4ipNe5w4QBmMWoeh4SGuSe65higrNmcF0nC6a4hoWC63/4erfyzy2pNridT+SOW24lyyvbsSjI4SskSoB5I6yvE1RJWUwPwOyr+QB2cWzaCryy62lPFGJJnTjMgiSKItRpXb/yGXZkRxqT5/p7rOc6S+qiXMrQJjQ2jLI4LDebsRkuNlmctPk0iKvc1fT76MXMknvF7Qj7pRlFWQG2e8V4lW5NVv/huMPsb+YNx8u0tu+M1nG8G/TB9l1XFlMdZ56QIYOtFtnXq9aOLvXpoFVgLaqb7A+8StpWQ//jOq4okEdfpnvvLwosignE5WWhnV2gyMPzFGPfQ17qaNjjHkP6J8pqU3nbLJ53IWmR3O6OblA0deGA0Ysowfs9ye8GsQb2SQ/5FUQ0UPtC5jeL/sufppehwU5U4GwEBu8t5qVPVCe5VZziws9lbT1NmhUkBZepEerYvo+eAxbfrkQvCFOUEqf/zz5oelO15zBUkP8UtdF18IlPvOUfz2SoVPtd1N6LHKD7P0WPxoJDXXQMNtBm4EBWW7SvHop3WU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(366004)(136003)(376002)(66556008)(83380400001)(66946007)(76116006)(66476007)(7696005)(55016002)(6916009)(9686003)(66446008)(64756008)(86362001)(6506007)(2906002)(316002)(478600001)(8676002)(5660300002)(38100700001)(52536014)(71200400001)(33656002)(186003)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?6AcXzTFLEoZdIQwqs1a9jyptrNP1pejU260/J22j+YBY9Z/S+2EjkoDw+ivP?= =?us-ascii?Q?ZkUUjxmsZEtxkvW6T5Czo2z2CsbvkuWT0+xqeKzhHAQ0n/c1MFleEjicujj3?= =?us-ascii?Q?rGJGT8LrGDP54WWWcOQCcJHbyfUtjlg/kc8n6sxwH0UISnO4TXHn34rJbApP?= =?us-ascii?Q?cJWfAT6xQNpgghSxo1EKVICXgxQQT+jUXtmCtlLKQ/p3UQqMbynagsuO6fZF?= =?us-ascii?Q?pIDbn5Lu0CQUEASjXT4vAhCzAtyG6ym6EsTONjsJNLbv8MmlTvJzFUUjWXHD?= =?us-ascii?Q?UTJkMdLJpsFnMQORzGXQ0yEKnY8ZHepypDZhkxoX4bhhShcgkARvzH7iq198?= =?us-ascii?Q?5gn3f0BwW26MtgYQeS5h8Dhik8ErKcJ21kjo3ZiaRcgVQLCmrfeyRicJYuHr?= =?us-ascii?Q?uP/jQKtjY5edletjWH6AGJe2lvyGo5MWKzE7LpXoTWXwHG8HcgP9xw4lF0bn?= =?us-ascii?Q?rG4CQEVlSOkC7P4Aat/+iwQ8d0ZPZMPewMqKIJrsY+rinGBhg+vQ8RSXHJm0?= =?us-ascii?Q?Kp0olgvb9GguIkgeBCHcf/v52IqvpuiKyJj8OAwfkjODHp92yYcK60zCxOeL?= =?us-ascii?Q?BvSK0fGNTNiuZxwjhYeeSjkaB1hQEmNrW5Oa/TZDs259hRAyrhpRkBB3yJHc?= =?us-ascii?Q?lkjpiZhORTwGSF4V/UZLg3DPA3PeCyvS7GVrgmYTAewIOp2E8iJLCPeHZEBf?= =?us-ascii?Q?GorMiMfSyGZGzzjepiBopq8h5dy3LHqnJuVJX0kaOZWsCKPnAqcRNkrQcS7m?= =?us-ascii?Q?oMqEJLGRd0h6wJJ0qY1eRJLnkIC899BMZp5vXeC83r5avJYKEY8sxIFf6mB7?= =?us-ascii?Q?dfpROdTNlohScXGbmUBpnBDHS98zp6SnJemYS3i+M28xkAkPcBURw5IO1PFP?= =?us-ascii?Q?RPuxNiXaD5LDB9JQ9kc7MU0cZCk+Su/pHLYFvlx9ATUq9cfq0FBtNIB7rkxP?= =?us-ascii?Q?PTzbAq+RhoQ1jcjmfMwTAZWuBLoQaU3JJaLneAzHsCB7vyFuspBcaCT9C/eL?= =?us-ascii?Q?YnjxNrLce+ijen1wH3lTaNB9CxMd3mXWf3rlac2Pxam5E16naGugKK69gwgi?= =?us-ascii?Q?d/dB8mwivHmI4UAb3SmDkVmzGOSs3fy5v37Hvgo8lBj6zf11n4jeDYLMRynx?= =?us-ascii?Q?fMsLEY18VZ19wZPa/COIQ6EKjQYZf4WRYvQKCrv+O6cfviWOanrsSZjlNm5m?= =?us-ascii?Q?NEYDClqQ2OtOdCC2XjcFHORwdqf+kY/5bJS6hiUSun2EU0JVzx+NayMIrLcu?= =?us-ascii?Q?TyNVOUzzG7DMf2lMdAk05pTvBRTsXw77pUFCOJe72NUlXt89fjoN8/G1b/g1?= =?us-ascii?Q?kfplcC+XirOHl82xayYOxVQqah1lxNDIUgSwRfOWSI2n5a0QLJ4NBLEyWVtH?= =?us-ascii?Q?zKK/E7o=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YqKzcphprmP8Ldu/SKmW6V7RtKPDy1nLuk0sGJeDyMCxVMkjbroJWoaQjoxGwGqcE41MrN1aoioyjHlgwNIfRIig8fOLD2xvhVMz+z1DLK/3+bmFs6/+euRfjxFPh8lez5kDOVKw6fY1ref60DtbUwXk6a4SshcaTyogNhCCoHuxlrv4k313t5y9eytZwnXCzY9s6WcWBHQVcKmBufPw8waitlxXT3t4VDzcNoxO2f6fqv+WEOY/gN3LsUu6/uDkbYUCl9lhEnUanNOb2hZ5wDof8/n0bFTSd3yXrg168EIggQ87VBOrrGVXt+ZrogEtPxwX1knpdVT2hy/RQx88hw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uzl4FmC7Dtu1NXXneDa0hg55Qqe7fLh4zUN+Y8e/n4g=; b=CtFTGVpZKbmYA2VB+6S6b3Ozade5pTStHW3g+IiRc+EnWSCIx7t2Is2rEMmiFeLQGNpC8dXefVJ54JMZICQuWkNTWtGv7zvU0gxd+5d9/N6NC4Im3ZWz/W62bc9pkTzIUPmL6NV/MbGOTwUYEa6+ScrTPmw/X3d6blfrHj8GIaGT1hQ89w00NN0mjut0GjoOq84YPVy3MdVU1p9beqrZ/RYxKQDxG45Wgqeie5Kzj2pCevKFgfo5+eW1w7JY++pSJ6yDQ/DExfJPJXF090avdoNKKhC268WoZWOZi4LOAkWV3CDaqTBN3mTIb5wYucAGQg7An8mvuXXyocyjC0O5ew== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 261676b0-4841-49b1-e3b9-08d8fa078042 x-ms-exchange-crosstenant-originalarrivaltime: 07 Apr 2021 20:55:39.5768 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: Zfkf6HFHFZv0VqHWjK8tuslfaUVPA2l+xcmTthZfORGwmoKq2a/Iw/212Z/uQrBeOE+HBN8IGgDr1GSvRnBvnmp1U5hnogGnmdpieQU5w+s= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3458 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-GUID: scRNtxoZzklnDrEPgJ-VndKkjyEx2xZQ X-Proofpoint-ORIG-GUID: scRNtxoZzklnDrEPgJ-VndKkjyEx2xZQ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-07_10:2021-04-07, 2021-04-07 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Bimi] Guidance Document - Refactor input X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 20:56:13 -0000 Hello folks, We're looking to refactor the existing Receiver Guidance document to be mor= e general purpose. We thought we'd reach out to others on the list to see = what areas they believe we should touch on. We wanted the new iteration of= the document to be something that can be referenced by all parties involve= d with BIMI such as Receivers, Senders, ESPs, Logo Designers, MUA authors, = and so on. We do intend to move over some of the existing content, so tho= se have been included below. We started a rough outline of sections to cover, and we'd welcome feedback.= Thanks for any input you could provide. # Abstract # Introduction # Goals for BIMI # Should you implement BIMI? ## As a Receivers ## As a Brands # Terms # Sections covered below (definitions of each group) ## Receivers ### Site implementation ### Validation of a BIMI message #### Additional requirements ### Retrieval of image files #### TTL for cached images ### VMC Root of Trust ## Senders/ESPs ### DMARC for Customers ## Brands ### Obtaining a VMC ### Logo Hosting Considerations #### CDN Considerations ## MVAs ## Logo Designers ### Known Issues ### Adherence to SVG P/S ### Tools and Caveats ## MUA Creators ### Image Dispay # Privacy Concerns # FAQ -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Thu Apr 8 09:50:40 2021 Return-Path: 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 3B8DD3A11CA for ; Thu, 8 Apr 2021 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=trendlineinteractive.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 cJaaOptkMYH0 for ; Thu, 8 Apr 2021 09:50:34 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 808BB3A11C4 for ; Thu, 8 Apr 2021 09:50:34 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id e10so1354817pls.6 for ; Thu, 08 Apr 2021 09:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trendlineinteractive.com; s=k1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oGQgM5hyE1RESoXaDHU6cDwgs/6y2p7C4QzMrKNvnxU=; b=W5+oTQhYqJHxpG+cP/ltUXWbnHFl8qaJamgmIfKx+F5ndh7obzHKYCZiQfNl0gJ5+L 1ToQn5oESx1HngR4UTZ3aitBFwH3ljuc+/rXpEpw5Gt7y6gwSjSHqYQVAIToIgSgj7pF bW8pj3fQSKGAlsN3F2mvcV+xIseZ+tR0plYDGEfBPanPoASNzZ9bY+q1HWStnCmwz7yw oiXYiV5w4xSLWxeUoDCEEYbImctZBhT2SpfgHKq8xi3iOd9F0t1xqyF6PUuLwvK/uoYK dYiF77F0scbUVdYCILwcKAl09eLMYuAkIO7510o22llvXbPlp5IXy4vkoX8g0+BaJ+j3 3mWg== 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:cc; bh=oGQgM5hyE1RESoXaDHU6cDwgs/6y2p7C4QzMrKNvnxU=; b=VJqrAtmBMZPc6s841e6KwDoAfnFzTYPxuONT0E4poEG3l2tkkJ9ptePrKs2h9W7vPb 3ShCZNz6USIr0aAmzNfGSjQq6IU9ccoACUwKA0JxUSOVCrYvCWg7HCYu2WF0ivB/C9aO 0EDuIClnS81Lvn4mQCkb7OKc74Ru9lNuinuOAdmDavZ8SOUiKGjxiVlhESb3BRuaBavO hGBRpmDsLog17qzx4Fh4GZspbrXJyfKLXRNIPag0tt9aX31kV3gzWpJp+LpdIQ3tiBDJ iAWDaNHVh54Qkq9I7J9ua900O35w6agqxC2NNIb8pq9krtF979TB+fvPtL7lkN3HZPkt 8xRg== X-Gm-Message-State: AOAM5327yNB2d9BC2WWK3gjOQ1LqL3w5sTo+5pjf3ct3B0FBSfScgEhC er2h7zuSlwP9OfmQARzWNYEWm2rsSSUKi75FxqYcg9a/BXekOHTg X-Google-Smtp-Source: ABdhPJzE1VvritBP2PxcqnQBfYB1W3XvqETVIMr9DirWUcWQ0Tqq9lgaN6TLs9gfLI7ERZJHjoky9J7giDDfwHubcCU= X-Received: by 2002:a17:90b:88c:: with SMTP id bj12mr7705543pjb.177.1617900632864; Thu, 08 Apr 2021 09:50:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zack Aab Date: Thu, 8 Apr 2021 12:49:56 -0400 Message-ID: To: "Brotman, Alex" Cc: "BIMI (IETF) (bimi@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000811e1405bf78d828" Archived-At: Subject: Re: [Bimi] Guidance Document - Refactor input X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 16:50:39 -0000 --000000000000811e1405bf78d828 Content-Type: text/plain; charset="UTF-8" $0.02 worth: The info is already there in various places, but since BIMI might require some organizations to add brand new code, an explicit "example mail agent workflows" section that is simply all of the BIMI-related actions (*what* action, not *how*) taken by the MTA, MUA, etc., would probably be helpful. I also think something along the lines of the "minimum implementations" section in the DMARC RFC https://tools.ietf.org/html/rfc7489#section-8 would be valuable. *Zack Aab* (He/Him) Senior Consultant, Trendline Interactive *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729> | *W* trendlinei.com On Wed, Apr 7, 2021 at 4:56 PM Brotman, Alex wrote: > Hello folks, > > We're looking to refactor the existing Receiver Guidance document to be > more general purpose. We thought we'd reach out to others on the list to > see what areas they believe we should touch on. We wanted the new > iteration of the document to be something that can be referenced by all > parties involved with BIMI such as Receivers, Senders, ESPs, Logo > Designers, MUA authors, and so on. We do intend to move over some of the > existing content, so those have been included below. > > We started a rough outline of sections to cover, and we'd welcome > feedback. Thanks for any input you could provide. > > > # Abstract > # Introduction > # Goals for BIMI > # Should you implement BIMI? > ## As a Receivers > ## As a Brands > # Terms > # Sections covered below (definitions of each group) > ## Receivers > ### Site implementation > ### Validation of a BIMI message > #### Additional requirements > ### Retrieval of image files > #### TTL for cached images > ### VMC Root of Trust > ## Senders/ESPs > ### DMARC for Customers > ## Brands > ### Obtaining a VMC > ### Logo Hosting Considerations > #### CDN Considerations > ## MVAs > ## Logo Designers > ### Known Issues > ### Adherence to SVG P/S > ### Tools and Caveats > ## MUA Creators > ### Image Dispay > # Privacy Concerns > # FAQ > > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > -- > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi > --000000000000811e1405bf78d828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
$0.02 worth:
The info is already there in various place= s, but since BIMI might require some organizations to add brand new code, a= n explicit "example mail agent workflows" section that is simply = all of the BIMI-related actions (what action, not how) taken = by the MTA, MUA, etc., would probably be helpful.
I also think somethin= g along the lines of the "minimum implementations" section in the= DMARC RFC https:= //tools.ietf.org/html/rfc7489#section-8 would be valuable.

Zac= k Aab (He/Him)
Senior Consultant, Trendline Interactive
O = +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com

<= br>
On Wed,= Apr 7, 2021 at 4:56 PM Brotman, Alex <Alex_Brotman=3D40comcast.com@dmarc.ietf.org> wrote:
Hello folks,

We're looking to refactor the existing Receiver Guidance document to be= more general purpose.=C2=A0 We thought we'd reach out to others on the= list to see what areas they believe we should touch on.=C2=A0 We wanted th= e new iteration of the document to be something that can be referenced by a= ll parties involved with BIMI such as Receivers, Senders, ESPs, Logo Design= ers, MUA authors, and so on.=C2=A0 =C2=A0We do intend to move over some of = the existing content, so those have been included below.

We started a rough outline of sections to cover, and we'd welcome feedb= ack.=C2=A0 Thanks for any input you could provide.


# Abstract
# Introduction
# Goals for BIMI
# Should you implement BIMI?
## As a Receivers
## As a Brands
# Terms
# Sections covered below (definitions of each group)
## Receivers
### Site implementation
### Validation of a BIMI message
#### Additional requirements
### Retrieval of image files
#### TTL for cached images
### VMC Root of Trust
## Senders/ESPs
### DMARC for Customers
## Brands
### Obtaining a VMC
### Logo Hosting Considerations
#### CDN Considerations
## MVAs
## Logo Designers
### Known Issues
### Adherence to SVG P/S
### Tools and Caveats
## MUA Creators
### Image Dispay
# Privacy Concerns
# FAQ


--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi
--000000000000811e1405bf78d828-- From nobody Thu Apr 8 17:36:21 2021 Return-Path: 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 547683A239B for ; Thu, 8 Apr 2021 17:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=comcast.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 YfOWpP9oOqfQ for ; Thu, 8 Apr 2021 17:36:14 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC303A239D for ; Thu, 8 Apr 2021 17:36:14 -0700 (PDT) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1390QEVW023014; Thu, 8 Apr 2021 20:36:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=1CRR2KtTdfmcAR+1vnJQxkxdSXCBvhfbqBNegEqeK0Y=; b=AZr+HqD1s191JlaAeRHVdCKFIyV8XKMht9YVEvlZ0ZSWvYDHdAlR7SyfBiDCg+yvMaoa shwtWqxYP6p6GTJACAv2XIha0JQjL9YUgAkIpYPxFFE36u9siEUKgbyNDuIZV0QaW2DE JMArBMOXSiw3UJlGTS8Yg3YqaJRJyPp433QqRFS3uK5i3NbGSZEFpbwo6NSHd5IErMvc 85OF2De3690YxPgAZgBJTJ60wiZYKa2SrXSvJKlzp+SAWGDCaavfRj6Ahv4TSACF2v/D TPcadJ9krQnCRFUPSR3IEGPFhF+5JMQ3Xb4CprVEck6bB9j0Fs5sEencgrmEIFuPdG4d Og== Received: from pacdcex50.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 37sk0kag1n-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Apr 2021 20:36:13 -0400 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX50.cable.comcast.com (24.40.2.149) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Apr 2021 20:36:10 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Apr 2021 20:36:10 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Apr 2021 20:35:40 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4463.namprd11.prod.outlook.com (2603:10b6:208:190::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.32; Fri, 9 Apr 2021 00:35:38 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4020.017; Fri, 9 Apr 2021 00:35:38 +0000 From: "Brotman, Alex" To: Zack Aab CC: "BIMI (IETF) (bimi@ietf.org)" Thread-Topic: [Bimi] Guidance Document - Refactor input Thread-Index: Adcr8F041vqA26wUTEisW5zvmDHd0gAptcUAABAcH9k= Date: Fri, 9 Apr 2021 00:35:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: trendlineinteractive.com; dkim=none (message not signed) header.d=none;trendlineinteractive.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380::c7df] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a348985a-b201-4a76-eb67-08d8faef65e9 x-ms-traffictypediagnostic: MN2PR11MB4463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SxLHB3t2cQ/YSl6D7Scw4ApQ02e28XPDpzRVEEgulrr3GawnsUofiKSEcxsv9LIx9qvK0IMzSctNYe2R9kkrm321cPVqbqV8pkxf+QrokHvp5g4jQAEEH+ohS1G5ZYPa2l6X7daDosuLW/SNm0AOJ/bBnZCgn8kRmXnLoVekFJxEUYK8ugDGn6yOFQwP+BC2xTlV43SUJoUJTMQjxay/Jg1lC/28y8z46RjlsHho2y48ViAiqBZFrdOBio0jGcGvUOqE6uBtopZtV9KdIm21eOss5RL5f2OpNR37ODc8QOFPfi7L5ToBO+vKrhspmQwQtBvdQAisM+EPjsrg6E/kmiJy6Nw4iN5y+Hs8BSsIwAwS3mcLTVRpSvk1tGZds/chGJ1Zul4Cw1LPmMVu2Ymjc/e7rEP6tEqfW0KpOlexylIyBBbOjtNaKIGMBdEhZiQo+2kbqskoEYLDnpMjKtcQdV2MBACKQHt+BZz3HZkesSoirRa2KoUCh3F0tZInKMY8AIk2tpp+jDvPSWOffqLfX6RPj6+E6/D/tllYWb8aquqnHhLpngSIwifc5f4oojrYehHsLHOLsicXB/Hb9UmXTMntc5PWXsJ3pUsoP+bQljnTgtFMMQRd4HWhMr/JL5zsBp7+K5IXhTU58shbFXlYroYCwEMjhY9nQ12c30b0Fnla6QU6bR4a5FCi/c2dfqgQiPfKwL8FU5OsoaxuRzAK1hP6osPJ/whMkNmD2/xb0Y8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(66476007)(71200400001)(76116006)(66946007)(6506007)(66556008)(53546011)(64756008)(186003)(66446008)(966005)(478600001)(2906002)(38100700001)(86362001)(7696005)(6916009)(5660300002)(316002)(8936002)(4326008)(8676002)(33656002)(52536014)(83380400001)(55016002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?y+/XS6C2JArwHs4uD9+5KXqlhimXm/kLjTwDMYCO3IoU/odhFJCjCC17gKX0?= =?us-ascii?Q?kP4Ked3/A8oV5X9sxaHw3pokWQkwnRu2BvuGrYeBVpup0xo7Pv9qkxo0aTdU?= =?us-ascii?Q?2WSM1H7Zk6/LvtSnfpCIPm1Kf7zmZcpUiK8hCBfl0SpB+s49CwQ8YYx1U6cI?= =?us-ascii?Q?b9ihykpmxvEJ82JXRtSgBYqqd4enzOBFXjvMwmSu3h6fnFIktsDBVNSsyyxW?= =?us-ascii?Q?t11h0P8G07ZEvFKshwclSdb9dE805djTj0zaBFq1L+IGnuxrzlOoiu4vZBpM?= =?us-ascii?Q?Ke9iH77oBPi4jV60nVlJW+f7glCllFXZTOgxt67hX3LNaMuj7yuiwGJSBgEP?= =?us-ascii?Q?7hRzw+0c64AfSZWrJF+72fLqdFSETH7rVmA1FrouS5E2NurlQWCcE9TdoJM8?= =?us-ascii?Q?KBcLYfeXBV+03muwFCoS17b3ViThGla8d7BjQ6jFh5smssvaH57xq6A7gb/+?= =?us-ascii?Q?+wpKWsDsukK/oGXJW+l4NkhwEwjC3jyLv3iLT82pqvpmb23SiBIFARng9B/4?= =?us-ascii?Q?0Oe8Ddba7cbjqMiULHKT26S1Zb0MsmtA7eiKpytFNAbNpLYNAs3UJOxpGGRl?= =?us-ascii?Q?GB/KP/oOiNU4yDm76OBWyYOYRKDgvKdLAVWdy7a7oN8l8VMnKS26huUsS8XT?= =?us-ascii?Q?MQoC/DamavYSi64PEtFWfJ64Ru6g0oZM8jT3AjOTUZ9Oh3Yd60PaBF6RWBN4?= =?us-ascii?Q?OyUUFRZaLG+i+E7bjmMbsixM09JAylytyyoGygxjf1puvsl6xC7sENKBNgLb?= =?us-ascii?Q?fy/16nV4dM95x+v3MOGPqssD8AbGk9CoY6bmL6AuVQ19U2TI3AkCUFuEVHY1?= =?us-ascii?Q?Rfjjlxy/RgGu4Hy5+1QI9ZmoZr4XzPZk9XxK0JFF9zn9N/k1CdJTE/dUdByA?= =?us-ascii?Q?n4C4skyXoW3/s4r7w5J9irCISkKcxjwsdiQSenY8/RWmjy/M7PDWfdYzJ+rX?= =?us-ascii?Q?p89TvZtbJ/fe2Qsq2tCkSTxPtNxLKmJXJXCjJMe6DOeO4Sw4edJo+jXyV4jM?= =?us-ascii?Q?5C9m12uuLmgnSqNqpOpVgrKAuaejxbpx+JJrrVa6DRLNF5Fl8srwkDYkgpTQ?= =?us-ascii?Q?W2yV9WxaeX5Zhg/Jdh+pTidmHuCVEnLKCMOyemMdtQY6yYkDabVamaL4WD0v?= =?us-ascii?Q?rdWe3i62Zl+0px+hdiujnG6lYV2alYDYnqfpoMN++Y7IS/vnwSALGjuP805A?= =?us-ascii?Q?n4PxeAp1PR+4hPOb80sevmiKtZowgvXYZUAGUiIYJ+HgSI5CJkxoT5nwER30?= =?us-ascii?Q?osKFdbvpsIIfQDW42dEgy8SjWdRmh/KauHI5bD4zTUUc0d+XTgrgOfwkfT62?= =?us-ascii?Q?3HFQDeaOjwDNUETnK4upCzqzGxs9m+UxkBD+6aCcoPs6mQ=3D=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFH+Y7P3C2IAF+1FQ/gAQlmfi40w9NIHC4gFDgnwEaN4YN9JO5JHMPbA+14UmxXWP7NC3+6AlQRxUBJHbEcLmhhf7MQNU/w7s/dNhI6WAGT4cLNj4e4j2+piWV6MVeXgJ9hfauPQl5Ho5LMjxDyi0ea0xgO3ysqnQOeEmLqW4dqpUBagK5coB3ctFiV2FMmw2u9su06LA7nNXdnXGsElljgAULiPP0lLY70w24pSVSt9ZLCpaJgSGamToSz6fHQ9dKNRQlmw78lUm8R+mopFZlS3Pjr7FPT0rQmvkPeo7DQlYsOcbcV1wlezjWvXyl0H9LSVk44j9IyMbsPpzBGdRw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ericKL8JQN4cu6UxRdF8VgAbsPHHgz1zmY978hwbNfc=; b=OJFzRagaU94Uewrg0JSd6BbIHYa+/zOOp1niJ4NPrzmwnnaWNUi25HvHsS5OTZGZN666IrMdAu0UpReCHfLkxitoseahn82QGVTT5DOaH7l+6E+EcZTytmP//PU+Sn8z328Pad9GtiLkkqIykyvcxjnUm16CVUZKRtAWOjpndjO2T3qYOf9EMlkHu7+S+0+juHfyvKb/bI0fVr4ZnExLlkQ5m4fFp2PK2AHiVmIQXUAH+7rUrc7U5jhRFKJJldHb8GV25obLn3daoeXAiriI5GPCu0LtLbk/3eGdAWVruROYVF0jTgHJGrsS48oBcNVMH0vBDRq68Ge8w+P+edl3AA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: a348985a-b201-4a76-eb67-08d8faef65e9 x-ms-exchange-crosstenant-originalarrivaltime: 09 Apr 2021 00:35:38.5682 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: oEJotqt8SDgrsk6ugkwTpcddWyc2nKq7p+tuDci6WW6rNIzEnQYX8tdE3BqTzYfrFO+p15HmD0dKUKSKm/Jq3ZSx/XRxM9zldZmpg8RwZ44= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4463 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-GUID: nD9_P71RbLL5XuIoTXsRMM4zy-BFrHXk X-Proofpoint-ORIG-GUID: nD9_P71RbLL5XuIoTXsRMM4zy-BFrHXk X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-08_12:2021-04-08, 2021-04-08 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Bimi] Guidance Document - Refactor input X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 00:36:19 -0000 That's reasonable to have somewhere. You're suggesting something akin to a= flowchart, correct? Would you be looking for this to include configuratio= n from the brand side of things? -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 ________________________________________ From: Zack Aab Sent: Thursday, April 8, 2021 12:49 PM To: Brotman, Alex Cc: BIMI (IETF) (bimi@ietf.org) Subject: Re: [Bimi] Guidance Document - Refactor input $0.02 worth: The info is already there in various places, but since BIMI might require s= ome organizations to add brand new code, an explicit "example mail agent wo= rkflows" section that is simply all of the BIMI-related actions (what actio= n, not how) taken by the MTA, MUA, etc., would probably be helpful. I also think something along the lines of the "minimum implementations" sec= tion in the DMARC RFC https://tools.ietf.org/html/rfc7489#section-8 would be valuable. Zack Aab (He/Him) Senior Consultant, Trendline Interactive O +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com On Wed, Apr 7, 2021 at 4:56 PM Brotman, Alex > wrote: Hello folks, We're looking to refactor the existing Receiver Guidance document to be mor= e general purpose. We thought we'd reach out to others on the list to see = what areas they believe we should touch on. We wanted the new iteration of= the document to be something that can be referenced by all parties involve= d with BIMI such as Receivers, Senders, ESPs, Logo Designers, MUA authors, = and so on. We do intend to move over some of the existing content, so tho= se have been included below. We started a rough outline of sections to cover, and we'd welcome feedback.= Thanks for any input you could provide. # Abstract # Introduction # Goals for BIMI # Should you implement BIMI? ## As a Receivers ## As a Brands # Terms # Sections covered below (definitions of each group) ## Receivers ### Site implementation ### Validation of a BIMI message #### Additional requirements ### Retrieval of image files #### TTL for cached images ### VMC Root of Trust ## Senders/ESPs ### DMARC for Customers ## Brands ### Obtaining a VMC ### Logo Hosting Considerations #### CDN Considerations ## MVAs ## Logo Designers ### Known Issues ### Adherence to SVG P/S ### Tools and Caveats ## MUA Creators ### Image Dispay # Privacy Concerns # FAQ -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast -- bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi From nobody Fri Apr 9 06:27:33 2021 Return-Path: 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 AD7CA3A0FDC for ; Fri, 9 Apr 2021 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=trendlineinteractive.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 0bHp1ZbFkbfM for ; Fri, 9 Apr 2021 06:27:26 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 BC4FB3A08D4 for ; Fri, 9 Apr 2021 06:27:26 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id 7so2751349plb.7 for ; Fri, 09 Apr 2021 06:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trendlineinteractive.com; s=k1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=acbriA4lg/XXxN84eu+rpV3Z1+btkXDunKe07EmLsAE=; b=YmyVqno2lySX24PG3ds+iHAcBQq348KBXOEIOWx1lUYMfu5i9bsvw7fcFK/2McAdCJ 2MDj/VxnUiao2ggDEnxgoRIKRkgYpq23lRDhCbzqXAeLeYk9Vmcnqzt9uHTrYhuxE2CN G66M10v3hCqtPyLBSl5e5vZ9GW/56V57f9BBJ9vTic9WolvZkLSPsMfW/6CeOLPd7NQx GCs5j7GsJ8Gf/JEx8//mOuXzl/hLmb3oPoOCiZg0IL4pcQ991h9uTS1ygPei3vfh44+T MW+JM5CSNtDVA6y4aj9+EtCFqA5WDyUF4iVQWlsDs8+eh4YgMmdcyHeEagZspp0114r5 0JkA== 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:cc; bh=acbriA4lg/XXxN84eu+rpV3Z1+btkXDunKe07EmLsAE=; b=A+zRuNxmDZaPZy/9409jnXMR0CulMrQzoWIgZmxeGnv+M6ERsEruQC/CfwLizMWN5F hIaHeb9POebtvrGSODo6/okcRz9PVpp9w143XEYjiZhgLoRaMSDt2kIxbMGT1B/C4nqe vNV481G0U2XHWmEJ6UT9hHFkFdq6+Plic6nRXojFWToqL4fEItPlk0kQY4YohyQNBgOT 2sdJS+bcX7Fw+VPm0r6Pw7g9/iwW7l1XNGsuclZ4oYVo1gBEJR8/z8uyYWeQGRhutcdH MNZ/A+9aCM8qpF/Xk9dlj5Q3M/IGiOistFNl9A0z457AXbfHqvg9HLiHx5eIeneLrd3S RY1g== X-Gm-Message-State: AOAM530OhKCGYIDYu7Wazkqa8fH4YHdqP+OoxsdWNcSBQBq2E/ep3x7f 6QopcZmYUSffwHGD/Q8HX1N/1f+lw5hz1cPJSoK8Aw== X-Google-Smtp-Source: ABdhPJyCe+sJucUsBaaeeu83H2uvEneL83E7ExtJhRyD4PX0oxmPaUApzxSrMHt0OhLNLZHk0/kkEBTwkBuyJXHfTEQ= X-Received: by 2002:a17:902:8bcb:b029:e6:a4a1:9d7e with SMTP id r11-20020a1709028bcbb02900e6a4a19d7emr12696327plo.25.1617974844772; Fri, 09 Apr 2021 06:27:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zack Aab Date: Fri, 9 Apr 2021 09:26:47 -0400 Message-ID: To: "Brotman, Alex" Cc: "BIMI (IETF) (bimi@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000e0e75905bf8a1f69" Archived-At: Subject: Re: [Bimi] Guidance Document - Refactor input X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:27:32 -0000 --000000000000e0e75905bf8a1f69 Content-Type: text/plain; charset="UTF-8" Yes, I was thinking of something that simply shows each BIMI-related event in an email's life. Essentially so a sender or receiver who is developing from scratch knows they haven't missed any crucial step. I don't know if everyone would consider the reward worth the work, so I'm definitely open to opinions/discussion. *Zack Aab* (He/Him) Senior Consultant, Trendline Interactive *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729> | *W* trendlinei.com On Thu, Apr 8, 2021 at 8:36 PM Brotman, Alex wrote: > That's reasonable to have somewhere. You're suggesting something akin to > a flowchart, correct? Would you be looking for this to include > configuration from the brand side of things? > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > ________________________________________ > From: Zack Aab > Sent: Thursday, April 8, 2021 12:49 PM > To: Brotman, Alex > Cc: BIMI (IETF) (bimi@ietf.org) > Subject: Re: [Bimi] Guidance Document - Refactor input > > $0.02 worth: > The info is already there in various places, but since BIMI might require > some organizations to add brand new code, an explicit "example mail agent > workflows" section that is simply all of the BIMI-related actions (what > action, not how) taken by the MTA, MUA, etc., would probably be helpful. > I also think something along the lines of the "minimum implementations" > section in the DMARC RFC https://tools.ietf.org/html/rfc7489#section-8< > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7489*section-8__;Iw!!CQl3mcHX2A!X3UO3VkKSbc6MN2ESm5qWFWS7YvvuDK8-92NiYNMCl72P3FkuRQSG5qLcA3aL5hmV7eX$> > would be valuable. > > Zack Aab (He/Him) > Senior Consultant, Trendline Interactive > O +1 (512) 717-4097 | C +1 (404) > 317-6729 | W trendlinei.com< > https://urldefense.com/v3/__https://www.trendlineinteractive.com/__;!!CQl3mcHX2A!X3UO3VkKSbc6MN2ESm5qWFWS7YvvuDK8-92NiYNMCl72P3FkuRQSG5qLcA3aL_o0FRg0$ > > > > > On Wed, Apr 7, 2021 at 4:56 PM Brotman, Alex 40comcast.com@dmarc.ietf.org> wrote: > Hello folks, > > We're looking to refactor the existing Receiver Guidance document to be > more general purpose. We thought we'd reach out to others on the list to > see what areas they believe we should touch on. We wanted the new > iteration of the document to be something that can be referenced by all > parties involved with BIMI such as Receivers, Senders, ESPs, Logo > Designers, MUA authors, and so on. We do intend to move over some of the > existing content, so those have been included below. > > We started a rough outline of sections to cover, and we'd welcome > feedback. Thanks for any input you could provide. > > > # Abstract > # Introduction > # Goals for BIMI > # Should you implement BIMI? > ## As a Receivers > ## As a Brands > # Terms > # Sections covered below (definitions of each group) > ## Receivers > ### Site implementation > ### Validation of a BIMI message > #### Additional requirements > ### Retrieval of image files > #### TTL for cached images > ### VMC Root of Trust > ## Senders/ESPs > ### DMARC for Customers > ## Brands > ### Obtaining a VMC > ### Logo Hosting Considerations > #### CDN Considerations > ## MVAs > ## Logo Designers > ### Known Issues > ### Adherence to SVG P/S > ### Tools and Caveats > ## MUA Creators > ### Image Dispay > # Privacy Concerns > # FAQ > > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > -- > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi< > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!X3UO3VkKSbc6MN2ESm5qWFWS7YvvuDK8-92NiYNMCl72P3FkuRQSG5qLcA3aL0Fw-o8d$ > > > --000000000000e0e75905bf8a1f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I was thinking of something that=C2=A0simply shows ea= ch BIMI-related event in an email's life.=C2=A0 Essentially so a sender= or receiver who is developing=C2=A0from scratch knows they haven't mis= sed any crucial step.=C2=A0 I don't know if everyone would consider the= reward worth the work, so I'm definitely open to opinions/discussion.<= br clear=3D"all">
Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097 | C +1 (404) 317= -6729 | W trendlinei.com


On Thu, Apr = 8, 2021 at 8:36 PM Brotman, Alex <Alex_Brotman@comcast.com> wrote:
That's reasonable to have somewhere.=C2= =A0 You're suggesting something akin to a flowchart, correct?=C2=A0 Wou= ld you be looking for this to include configuration from the brand side of = things?

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364

________________________________________
From: Zack Aab <zack@trendlineinteractive.com>
Sent: Thursday, April 8, 2021 12:49 PM
To: Brotman, Alex
Cc: BIMI (IETF) (bimi@ie= tf.org)
Subject: Re: [Bimi] Guidance Document - Refactor input

$0.02 worth:
The info is already there in various places, but since BIMI might require s= ome organizations to add brand new code, an explicit "example mail age= nt workflows" section that is simply all of the BIMI-related actions (= what action, not how) taken by the MTA, MUA, etc., would probably be helpfu= l.
I also think something along the lines of the "minimum implementations= " section in the DMARC RFC https://tools.ietf.org/= html/rfc7489#section-8<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7= 489*section-8__;Iw!!CQl3mcHX2A!X3UO3VkKSbc6MN2ESm5qWFWS7YvvuDK8-92NiYNMCl72= P3FkuRQSG5qLcA3aL5hmV7eX$> would be valuable.

Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097<tel:+15127174097> | C +1 (404) 317-6729<tel:+1= 4043176729> | W trendlinei.com<https://urldefense.com/v3/__https://www.trendlineinteractive.co= m/__;!!CQl3mcHX2A!X3UO3VkKSbc6MN2ESm5qWFWS7YvvuDK8-92NiYNMCl72P3FkuRQSG5qLc= A3aL_o0FRg0$>


On Wed, Apr 7, 2021 at 4:56 PM Brotman, Alex <Alex_Brotman=3D40comcast.com@dmarc.= ietf.org<mailto:40comcast.com@dmarc.ietf.org>> wrote:
Hello folks,

We're looking to refactor the existing Receiver Guidance document to be= more general purpose.=C2=A0 We thought we'd reach out to others on the= list to see what areas they believe we should touch on.=C2=A0 We wanted th= e new iteration of the document to be something that can be referenced by a= ll parties involved with BIMI such as Receivers, Senders, ESPs, Logo Design= ers, MUA authors, and so on.=C2=A0 =C2=A0We do intend to move over some of = the existing content, so those have been included below.

We started a rough outline of sections to cover, and we'd welcome feedb= ack.=C2=A0 Thanks for any input you could provide.


# Abstract
# Introduction
# Goals for BIMI
# Should you implement BIMI?
## As a Receivers
## As a Brands
# Terms
# Sections covered below (definitions of each group)
## Receivers
### Site implementation
### Validation of a BIMI message
#### Additional requirements
### Retrieval of image files
#### TTL for cached images
### VMC Root of Trust
## Senders/ESPs
### DMARC for Customers
## Brands
### Obtaining a VMC
### Logo Hosting Considerations
#### CDN Considerations
## MVAs
## Logo Designers
### Known Issues
### Adherence to SVG P/S
### Tools and Caveats
## MUA Creators
### Image Dispay
# Privacy Concerns
# FAQ


--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

--
bimi mailing list
bimi@ietf.org<mai= lto:bimi@ietf.org>= ;
https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/_= _https://www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!X3UO3VkKSbc6MN2E= Sm5qWFWS7YvvuDK8-92NiYNMCl72P3FkuRQSG5qLcA3aL0Fw-o8d$>
--000000000000e0e75905bf8a1f69-- From nobody Wed Apr 28 13:07:23 2021 Return-Path: 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 BF69F3A1E5E for ; Wed, 28 Apr 2021 13:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=trendlineinteractive.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 0rb1fNVSLOoY for ; Wed, 28 Apr 2021 13:07:17 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 001673A1E5D for ; Wed, 28 Apr 2021 13:07:16 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id s22so24432008pgk.6 for ; Wed, 28 Apr 2021 13:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trendlineinteractive.com; s=k1; h=mime-version:from:date:message-id:subject:to; bh=fSBWjJZod+RZThld3xSJ4+72k55gdtlwo2FRGoXph4Y=; b=J7JBMHeFDYd0lVI4Co/iW8EsdsNIvJdHAC+x/i3GUD57EM6nrgjbroDRJf4nAlOn6r IVtJxbjIQFTGu83b1xrQZgZunXra68to5Hbm2zbyT3KMG/2xL3a9ld0IVaDeRLjs4Ee0 I81VN8LljeD34JDLbpxFjq0S00B3KMsAlgxXTujuWb0Sl1zpNhi1srySMBMxMbPZApFv ahW7lHarcygmatZnuXWIYO3PreRDJ33B9ChKI0xlDq4e2BEmUOxg89qoN/6QM6DWr3vF gLQVdxYvcEBSuSP0s41dsUbbDuHPljnkGe3qybXsQjK6JnqL/6ctykfJpzvXE3Hq0fFJ CXNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fSBWjJZod+RZThld3xSJ4+72k55gdtlwo2FRGoXph4Y=; b=sQf4ZXr8/60gUaMAmXDZw4tghINw/LCAnnO9zUNgDOluf6tEBqWXn+kSdC2dja3jV1 1db+hObvOMD7l3jal+DESmv0rcbgH17uZGBUd5QyD292dYwYC52Oq+0j63rzWB6/tkmu 1rxrLUnDg4kfsLb+wSAxFSQ7w9Ox226n57GRAjeiWZvzHEZrPB4V3rhzfyJNW0UMrO2p tZRRKcSgwAfiF1pXI110WdR9SIxImFCUk2hE5OW4AMeEJ6RUNw1xSH2KZjXdSTBUTmft psxsSsVMYHLIv2leRYBpfa/o4qtLsbX6P5437TluT2z23Sf7aeBReSbdyDcn1L2Qa5cR z7dg== X-Gm-Message-State: AOAM532eezaJ77hu0CIY+JoHaJKZBmH2NHqTfCNXtFoeeDtB0JsZT4k+ Vv+W0/HmdJNhJFtyQcKiHjqnb4xnyt3+brNUKQT+xWtjZKCegg== X-Google-Smtp-Source: ABdhPJye+9IPGqOqACp3gKePNUw8FInntoF+mOvNVhIbOQRdqCyGyd8/x+0NNiJZGtXwJloF/54D0Sk8LP5aXkHk9sg= X-Received: by 2002:aa7:9af7:0:b029:264:b19e:ac9c with SMTP id y23-20020aa79af70000b0290264b19eac9cmr29554795pfp.59.1619640434925; Wed, 28 Apr 2021 13:07:14 -0700 (PDT) MIME-Version: 1.0 From: Zack Aab Date: Wed, 28 Apr 2021 16:06:39 -0400 Message-ID: To: "BIMI (IETF) (bimi@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000c9c77005c10dec48" Archived-At: Subject: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 20:07:22 -0000 --000000000000c9c77005c10dec48 Content-Type: text/plain; charset="UTF-8" I was reading section 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi. BUT What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF? It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely. *Zack Aab* (He/Him) Senior Consultant, Trendline Interactive *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729> | *W* trendlinei.com --000000000000c9c77005c10dec48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was reading section 5.4 of the document and it's pre= tty clear what to do if the selector header (BIMI-selector) is not included= in the DMARC-aligned DKIM signature: treat it as if there is no selector h= eader and move on to default._bimi.
BUT
What if the DKIM signature in= cludes the BIMI-selector header but doesn't pass validation AND DMARC s= till passes via SPF?
It seems to me (given DKIM's normal use - a bro= ken signature should be treated as not having a signature) that the receive= r should treat the BIMI-selector header as unsigned and move on to default.= _bimi, but it's not actually stated one way or the other, so the respon= se from the receiver could be to stop BIMI validation entirely.

Zac= k Aab (He/Him)
Senior Consultant, Trendline Interactive
O = +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com
--000000000000c9c77005c10dec48-- From nobody Wed Apr 28 23:26:54 2021 Return-Path: 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 8D7943A322B for ; Wed, 28 Apr 2021 23:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailkit.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 g9wSmxBVR5aI for ; Wed, 28 Apr 2021 23:26:47 -0700 (PDT) Received: from mail.mailkit.eu (mail.mailkit.eu [185.136.200.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F533A3228 for ; Wed, 28 Apr 2021 23:26:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mailkit.eu (Postfix) with ESMTP id B78ED204A5 for ; Thu, 29 Apr 2021 08:26:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailkit.eu Received: from mail.mailkit.eu ([127.0.0.1]) by localhost (mail.mailkit.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScKJe8JPz9Sr for ; Thu, 29 Apr 2021 08:26:32 +0200 (CEST) To: bimi@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailkit.com; s=mk-2; t=1619677592; bh=JuWNk2/xlfLcRe9X3eAIHTPbW84CizTKQvXQkpdcy+Q=; h=To:References:From:Subject:Date:In-Reply-To; b=n4t34n9aqiJhAYWLxYHftuSxdxyNt6/FRE24kHiJ6oXNj0BInwZgOJ3t2TELuM+GV 39ObmBkEZsOWPcT/wbVJWaf0I4JtUh5X9gyvwYe52TYHOvzE+mf28+KNZwkym7zuww jAR9XZHqSn8GwWCth3DTG9aaSr+O2Jzx69TYS6j71iikD4wL1xrtipH0nQc07k+iyl DrOIITx50zdDSEpPnvnBzJyNMK8uzdeiH3QUrb7SW4nJVnntcB6SOTdpGMfiIPF7mq 5VCwXTz9huN5mgCThHLsxCUqXw6A+eagl3JiT0nj0zzLgqnuiZjKDJRs3rOIW9BGlZ V2rJdSIUlQyxA== References: From: Jakub Olexa Organization: Mailkit Message-ID: Date: Thu, 29 Apr 2021 08:26:33 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7893EA18D64CE97F5585BD5" Content-Language: en-US Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 06:26:53 -0000 This is a multi-part message in MIME format. --------------E7893EA18D64CE97F5585BD5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, In my opinion if DKIM fails to validate the message content the MBP=20 should not display the BIMI at all (no matter why the DKIM failed). The=20 reasoning for this is that SPFs validate shared infrastructures (OL365,=20 GSuite, etc) and as such domains can be spoofed while DKIM authenticates = the actual content. BIMI logos being displayed on the message list (see=20 Yahoo mail app) they become sort of a "From" indicator from the users=20 perspective and over time will become sort of a trust indicator. BIMI=20 should make every effort on the standard level to discourage any use of=20 BIMI that failed a critical validation of the message body as that alone = could be an abuse vector. If a phishing operation targets businesses that are using shared=20 infrastructures and have BIMI, they could achieve quite a significant=20 success if the messages get highlighted with a logo while failing DKIM.=20 This would undermine BIMI in a major way and DKIM as well. Jakub Olexa Founder & CEO E-mail: jakub@mailkit.com Tel: +420 777 744 440 Mailkit - Closing the circle between Deliverability and Engagement=20 On 28.04.2021 22:06, Zack Aab wrote: > I was reading section 5.4 of the document and it's pretty clear what=20 > to do if the selector header (BIMI-selector) is not included in the=20 > DMARC-aligned DKIM signature: treat it as if there is no selector=20 > header and move on to default._bimi. > BUT > What if the DKIM signature includes the BIMI-selector header but=20 > doesn't pass validation AND DMARC still passes via SPF? > It seems to me (given DKIM's normal use - a broken signature should be = > treated as not having a signature) that the receiver should treat the=20 > BIMI-selector header as unsigned and move on to default._bimi, but=20 > it's not actually stated one way or the other, so the response from=20 > the receiver could be to stop BIMI validation entirely. > > *Zack Aab* (He/Him) > Senior Consultant, Trendline Interactive > *O* +1 (512) 717-4097 | *C* +1 (404) 317-6729=20 > | *W* trendlinei.com=20 > > --------------E7893EA18D64CE97F5585BD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

In my opinion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector.

If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.

Jakub Olexa
= Founder & CEO
= E-mail: jakub= @mailkit.com
= Tel: +420 777 744 440

Mailkit - Closing the circle between Deliverability and Engagement

On 28.04.2021 22:06, Zack Aab wrote:
I was reading section 5.4 of the document and it's= pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi.
BUT
What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF?
It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely.

Zack Aa= b (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.c= om

--------------E7893EA18D64CE97F5585BD5-- From nobody Wed Apr 28 23:56:29 2021 Return-Path: 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 F258A3A32F3 for ; Wed, 28 Apr 2021 23:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=marcbradshaw.net header.b=X1HmKa70; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZP+OC3HP 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 oqsjMq8NVfVh for ; Wed, 28 Apr 2021 23:56:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFA43A32F0 for ; Wed, 28 Apr 2021 23:56:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 27B095C00CE for ; Thu, 29 Apr 2021 02:56:19 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Thu, 29 Apr 2021 02:56:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=lUiGzoc qAHLAtMocRArexwIbhIgCRYSp6nO/5Xt24+8=; b=X1HmKa70fYNymVusEDFjPUc lEiTm0SPB1QpNQ/J2zOorDCtJLqqI9e+IziqrOR2mQjxXL/BIsZqvMvUMQZlr1pO 05ILe6D8ia4LZR18Wyh1gSt4vSVzPqDKCWOCOuKgLsjVWLQRI8p3fx8C417GzfNZ qIUbl9vMfTV4e9Cw8RSNy2p85jLuxgspqTlxmYsK6X8uoi4N8ZqaAzVSomn0ryob MyJRYUquS+PZYvTZ4pu/rRMkw4nbl69q1EJXyQmowtSv+UVoh+ct0uq/cEsyS+is 40USxfvJK7u9OD3K8Z3DL4kvExIpWJ1+jnEIJplXO5d3xU/oM/43MkSUzktz2JQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lUiGzo cqAHLAtMocRArexwIbhIgCRYSp6nO/5Xt24+8=; b=ZP+OC3HP2OwhBv5hs0FVnD llG0VDrzhDpNe0WVk0R138h4pDMd7ValBi0DgpyczYAISA4tRbBdqcr10rCpPLsq nSUXBd9YhwKP5TQ9RGVHCIGxS4D8GMLMte3GAgBLopzcsm/Qe4Oz/rOFmPjAuD6B EREnpArypoU8TQmDAUs7Z4IHRekdZyuGCDQdmoxMF5nShn+9SOgoRhOCm/PWvQy6 S6Akh0mvTGN04nLZKiEO/fA2FvVkjeHueDCCOeK6n12QQ1RUbYbVbg1fFqSx9UF5 4uc1vnwZv74fWVpJliIpyWoM9BiUWno6tvJjB9HwK2HivCQC+zO37ZepU+Rd6oyQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvfedgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtkfhmghffohhmrghinhculd eftddmnecujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhep fdforghrtgcuuehrrggushhhrgiffdcuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrd hnvghtqeenucggtffrrghtthgvrhhnpefhfeeukeffvdduvdfftdeiffdvuefhvdfhleet udfhtefhtdelheejffefhfeileenucffohhmrghinhepmhgrihhlkhhithdrtghomhdpth hrvghnughlihhnvghinhhtvghrrggtthhivhgvrdgtohhmpdhivghtfhdrohhrghdpmhgr rhgtsghrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhgtsehmrghrtggsrhgr ughshhgrfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9EF5B4E00A6; Thu, 29 Apr 2021 02:56:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> In-Reply-To: References: Date: Thu, 29 Apr 2021 16:55:57 +1000 From: "Marc Bradshaw" To: bimi@ietf.org Content-Type: multipart/alternative; boundary=1d10dea3329042ef998db96de9fe1744 Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 06:56:28 -0000 --1d10dea3329042ef998db96de9fe1744 Content-Type: text/plain Hi, Opinion: This feels like a discussion outside the scope of BIMI, SPF forgery is a known issue ref the recent Multipass attack at a well known vendor. There is a related note in the "Unsigned BIMI-Selector Header" section of the spec. We do see senders with p=reject who rely entirely on SPF and do not DKIM sign at all, I would argue that the problem being described here is more about vulnerabilities in some shared infrastructure platforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take place in the DMARC group, and that BIMI should take the DMARC result as is as much as is possible, without imposing additional constraints over what constitutes a valid DMARC pass or fail. MBPs are, of course, free to implement whatever additional constraints they see fit, but I don't feel that this one belongs in BIMI. On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote: > Hi, > In my opinion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector. > If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well. > Jakub Olexa > Founder & CEO > E-mail: jakub@mailkit.com > Tel: +420 777 744 440 > > Mailkit - Closing the circle between Deliverability and Engagement > On 28.04.2021 22:06, Zack Aab wrote: >> I was reading section 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi. >> BUT >> What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF? >> It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely. >> >> >> *Zack Aab* (He/Him) >> Senior Consultant, Trendline Interactive >> *O* +1 (512) 717-4097 | *C* +1 (404) 317-6729 | *W* trendlinei.com > -- > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --1d10dea3329042ef998db96de9fe1744 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,

Opinion: This feels like a discussion outside the scop= e of BIMI, SPF forgery is a known issue ref the recent Multipass attack = at a well known vendor. There is a related note in the "Unsigned BIMI-Se= lector Header" section of the spec.
We do see senders with= p=3Dreject who rely entirely on SPF and do not DKIM sign at all, I woul= d argue that the problem being described here is more about vulnerabilit= ies in some shared infrastructure platforms and not about how BIMI shoul= d be implemented. At the very least, I would expect that discussion to t= ake place in the DMARC group, and that BIMI should take the DMARC result= as is as much as is possible, without imposing additional constraints o= ver what constitutes a valid DMARC pass or fail.
MBPs are,= of course, free to implement whatever additional constraints they see f= it, but I don't feel that this one belongs in BIMI.

On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:

Hi,

In my opin= ion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector.

If a phishing operation = targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.

Jakub Olexa
F= ounder & CEO

Mailkit - Closing the ci= rcle between Deliverability and Engagement

On 28.04.2021 22:06, Zack Aab wrote:
<= blockquote type=3D"cite" cite=3D"mid:CAFOdbD3VAt1dXNtJwHbzUpmKTXULDwN6C_= brPJUwoVYhsrvsDQ@mail.gmail.com">
I was reading sec= tion 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as= if there is no selector header and move on to default._bimi.
=
BUT
What if the DKIM signature includes the B= IMI-selector header but doesn't pass validation AND DMARC still passes via SPF?
It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to= default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely.


Zack Aab (He/Him)
Senior Consultant, Tre= ndline Interactive
O +1 (512) 717-4097 | C +1 (404= ) 317-6729 | W trendlinei.com=
-- 
= bimi mailing list
<= br>

--

  Marc Bradshaw
  marcbradshaw.net = | @marcbradshaw

--1d10dea3329042ef998db96de9fe1744-- From nobody Thu Apr 29 08:19:55 2021 Return-Path: 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 ED1863A28C4; Thu, 29 Apr 2021 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=comcast.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 Ot8noRG54VjV; Thu, 29 Apr 2021 08:19:47 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C12A3A28BA; Thu, 29 Apr 2021 08:19:43 -0700 (PDT) Received: from pps.filterd (m0156895.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13TEu37R013392; Thu, 29 Apr 2021 11:19:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=qJwjDLWbIXQynqvLH0KllkvczGGqPE6X8yTd9h6JwhI=; b=0q0ZRD1CgPJGfngVlujeEsZzrwD+/qdf/TWxFhauPGQdEJWTaw6CmWJMfXCZiRE6pa1R 2fkL0UxjjXHb/gAcWa2aYbZvjGTDRID4Z/LHINTOwZjGSWkiARSXZ/zPs/8LGoDPquZt aNbMuEiJH5iTcub/5DWTCblv6QWUfpJLUyD772G7PbupCK0smJRIe6xuo31BOtenljIz eVKouOS1sekGH+cYLHWy6SPRJNLgM+RRfpKNwm9Ig8lLkKhzQFPjGR/6NO1FieXvYnbT R6geGibXLclCu6XjuQZdvOmZqH5EvdX+N+K6E5HmEmItZUvQ49QX6OaC8jzkLBfXW8w1 wg== Received: from pacdcex52.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 387syv242q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 29 Apr 2021 11:19:42 -0400 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX52.cable.comcast.com (24.40.2.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Apr 2021 11:19:41 -0400 Received: from pacdcexedge02.cable.comcast.com (68.87.38.198) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 29 Apr 2021 11:19:41 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174) by webmail.comcast.com (68.87.38.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 29 Apr 2021 11:19:30 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4079.namprd11.prod.outlook.com (2603:10b6:208:153::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Thu, 29 Apr 2021 15:19:29 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4065.026; Thu, 29 Apr 2021 15:19:29 +0000 From: "Brotman, Alex" To: Marc Bradshaw , "bimi@ietf.org" Thread-Topic: [Bimi] What if DKIM doesn't validate the selector header. Thread-Index: AQHXPGot2EFOFQevBUCnzjvUFuXuvqrLCF2AgAAIN4CAAInsgA== Date: Thu, 29 Apr 2021 15:19:28 +0000 Message-ID: References: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> In-Reply-To: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:103:e60:d4cf:b01f:4858:77b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c02f8cba-9e91-49ff-a704-08d90b222ecb x-ms-traffictypediagnostic: MN2PR11MB4079: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nz4wlPgm0my5za8BBhW+9HAO6p48nz3KkUPQyKZwtSdQ5SeAMS2ehl2W1DCXufbc3j+vwQBRYMs0q3SRkx6bZRwMZ1+luZvL3jp1qNzt1rESOXReBeyFm2TPp7VKERwSO90o7eYPUCa0UA1tRkTwQFFIZLfBc24+fsoYlSFy/KC3mVgsDhovmyrz4dkZWHqvGUTubqBW4GNmpqcRpodt8i6AJqaZTNZEz4tOwn591CDWAKdnCq/gY/h8fvkiCc0x554uRT62ZMG95p6ONP3Hmp8MjDfMOHK0zUOl4oYCPq487eA4MS/+oLXCPUSCQx0foSaANi3ram/vmEuHeL1AwsSMMcMMRWLpu+a36f5HgpTpHtSnNR4t01Z0Kkr65g2FVHBhyjrBB26myhmhpCWqg29tz5biHvq1zYMIdS2dOZgKNLOI0YeoD7OnXvmVQ3o3tIHraOn3OrPn7snWHyzR60iKoyMJbMpbNndn9AfaDyS1tFhooKZBtEmXwzKkTWNk1AF/71mbGR5OXTFkt2U62QZxNYMnE7OVBxamos7rNLvbkrS7sIUSOWKZ9zlzy184B+LV5RGwa2q0laKo0fDvekOLgD46p67HMg55XB4G88NzL9mM1EPdgvIdwOTmAKv444nLfosV/JUFArSAEOupwLjcQvExxi1AH3hF8rsDii5U65TM7GVzuq1QNqCXEIJ9 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(5660300002)(83380400001)(110136005)(52536014)(966005)(8936002)(6506007)(86362001)(71200400001)(15650500001)(38100700002)(66556008)(478600001)(2906002)(166002)(76116006)(122000001)(66946007)(9686003)(8676002)(186003)(64756008)(7696005)(66476007)(66446008)(55016002)(53546011)(33656002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?PmiD+ucsmXc36iLJPuTgRHRMBkSvAQ50G0mQvoyIsqryZPtzSuKX7Zs2oaFj?= =?us-ascii?Q?xvq6BqTxAYN/XIX8aKvhrEaJgzbDAcDL9WZX0SqpwouTToxJXZ04T3Rwe3oH?= =?us-ascii?Q?+W+Agha8FDbuY9UC1O7UtPefVwJj/8C5zhFrIvnDwccYMQi3o0iJdIyEHgvW?= =?us-ascii?Q?EJOfc6zmWceifGPB4pZay5NlV3ySyZ4HMoFsd9ICl9g6gBExaI7vxyJ90Eko?= =?us-ascii?Q?Af7GgoEdG0tDhFOEzJBBEdrQxh8sC2vgTIzHqgJx9nhMgGnDufikbjQOqwrm?= =?us-ascii?Q?iNUBs4FOUGB4gjRx94bhdJ3+h+HJDEI8r/0uuJK+zhYGVruWSxZvnA7GJ6gN?= =?us-ascii?Q?GCwyXj16vvxKxNphV4FJeqQYEWg+5BfneiN0F1yopI7aEcBUDgaxIhq3rBuG?= =?us-ascii?Q?CHvUb4gr9o1L/VSzqYIQaSNYTKY8H8/2sno6k22Ko6i+k48Kgv3X8XLpe/uY?= =?us-ascii?Q?xOM5U2ovI1JVuD2LYHk3QMlIMraN3A0QXpR1VxBIFie1XFBbpM7CszgMjnhj?= =?us-ascii?Q?MPAFTjUAtaNQvIP1tSlCRoapzGPr1tys/vw3VE6+rkIEGv5J+wC8w5gBsYw7?= =?us-ascii?Q?nm2rxNVNcG+zFDXXhYIRr6NT3sd3GgJ2PZ5LkruOCjX9DvaaOX3PzVImcTAw?= =?us-ascii?Q?AE02da6DMxnA1Yp5TajGfYODosx5OF7BSzRZ7FhO/20pr6rVvTnuWv0RwS+t?= =?us-ascii?Q?diDo7BDDEL3f0nT8XqnNsyr0aIGYxhfa42/gxn+B2brBTI6nybtpFNf+ZnJ6?= =?us-ascii?Q?QqHGGZGn0C6PQggeUKCJvumrZkh1d0bcsEI/QVWnaOyrYVhr8TS1FPIxtAZE?= =?us-ascii?Q?glQSyBamZAHQBxo42fnfvMBz/d/6w2EUqibqH0XyO6QObVn3oIWQrv0SYieH?= =?us-ascii?Q?PpNdc4roKRpqs3XaKKCP7V8uvdKfC21Yz43bZSAy1qcPGpcvDRX9KdTb5fHE?= =?us-ascii?Q?CdNruU+5gJ72+W0g3dOV8cEhFKZ0CjGEnp+5A0p28zfASPDiHfvWsqhcE2x6?= =?us-ascii?Q?18q5tkFPtgWVoFI9oGeV2t3iGwcb84D0gfS6ewsZ5m8j/SxbtqT1cajnLpKy?= =?us-ascii?Q?t9SqLdWTTH1ik4seXYhOKVhbUjcHA6dd6hEuRAPSM8byX9GpS8pwoTdy4808?= =?us-ascii?Q?HF6Df6/caDKlmtdYud1QV9hpCuho43SG1wQ34vVcn7YZYLuYwuEnfudOntoA?= =?us-ascii?Q?0JpLfLHOsMvCmZlkVLZ2VDfPTG5Vsdcil+jF0wAub7Zyw27jCJk/u2GMxXXy?= =?us-ascii?Q?ryq69BUYemhwUcXqELOsvWT6nALeLIZaGbkp8JSHR5ZUDF1O4lZzKn8E/WeL?= =?us-ascii?Q?szw1iHZeKU3o9RC+bMG2GKNMeSImGbUCcU+7KJomRJ/hyzu6nkp8pzTIR4uq?= =?us-ascii?Q?tYkvPsQ=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MyZN4AkCmHRcbmedgiMVCG7WwVQNN/eavkd8kK1GDZ2Vt5alSDgjPGKLDpQH2Pll8Byl/p9hvXlow/kvdCMmCeS9/jhSZle3YWDtOkV3+DMNvE8Xpahc/CnPiuF3XUO8mXQRPeP1RYN0KT0KRIBljVA/8hwD2t/tLqICbfhjCPHsSAmRabxGe6NaFGPfCVtasB1idfH/3lfkNY+Z5NrSCeoNOm6uY71xgB+I/BdwhowCPzy69BNz4CZ3Fr/b3JZhKBBgYhhmmGEX05hDVxTIygZ+G1W/cqzTn+xlaq4XNbvVDKi8b5zykuCsmHOMvduoFlRZLpbXT4HZHP0pfFVRwA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BLWs3naeQHy9hwJcr3QBPk7dCPB3hTAUvZYf6EqyyJU=; b=S6kbnG05PCVeZrpLKmBcerPMp6STvpvZo/uTmU5EtSqUN1Hd5MoaCMI5HBrcMBV+mdDfUn0JFlWotyTp6Ck/0oZQSOvTvoh6egT3MrlPkRhdqmGRZspd9rUs0eRSVJX/UK78aGkFAQe3bDloACj624reSRMBItGOkZpSRop2cElw8IV5IM+o13+jTp8vIJ9osjiyS+Xg8msgAt7B1PP6FcKSWquRy4BwhbQ3c8GXRKZ5Z6fz24R9Wyo1eiSETrZg9/i0VbPpUTe4P2NcnHXk25uTZXVsE0SdR/ymTPS0RmpBugyky2McZ1eUtRNQnxSSl3vYlO2tcirHErbSKZf8bw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: c02f8cba-9e91-49ff-a704-08d90b222ecb x-ms-exchange-crosstenant-originalarrivaltime: 29 Apr 2021 15:19:28.9449 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: sqfS7g2rgv5bgGTSrbAVDW7m5jiCyp0k+dODs+FryOT2YsgtlmZtWiYj9QQikmtMGILs3OfH16D1KJ8yLD6nOA0L210dVZMCoBP7e7nJ/Os= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4079 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB435116DF2780EF22D5E5DC21F75F9MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-GUID: D-afBrDogqMkZ9Uo7FjQO5FXDFI182z2 X-Proofpoint-ORIG-GUID: D-afBrDogqMkZ9Uo7FjQO5FXDFI182z2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-29_07:2021-04-28, 2021-04-29 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 15:19:53 -0000 --_000_MN2PR11MB435116DF2780EF22D5E5DC21F75F9MN2PR11MB4351namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not entirely sure that answers the original question. I don't think th= e OP is an attempt to second guess DMARC. Seems more a question about shoul= d a receiver go to default._bimi (or something else) if the selector is spe= cified but seems unusable (either not signed or signature fails). If we be= lieve the sections A.1/A.5 covers this scenario, perhaps we just need a lit= tle embellishment on this scenario below to be more explicit. And yes, loc= al policy can impact this. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: bimi On Behalf Of Marc Bradshaw Sent: Thursday, April 29, 2021 2:56 AM To: bimi@ietf.org Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. Hi, Opinion: This feels like a discussion outside the scope of BIMI, SPF forger= y is a known issue ref the recent Multipass attack at a well known vendor. = There is a related note in the "Unsigned BIMI-Selector Header" section of t= he spec. We do see senders with p=3Dreject who rely entirely on SPF and do not DKIM = sign at all, I would argue that the problem being described here is more ab= out vulnerabilities in some shared infrastructure platforms and not about h= ow BIMI should be implemented. At the very least, I would expect that discu= ssion to take place in the DMARC group, and that BIMI should take the DMARC= result as is as much as is possible, without imposing additional constrain= ts over what constitutes a valid DMARC pass or fail. MBPs are, of course, free to implement whatever additional constraints they= see fit, but I don't feel that this one belongs in BIMI. On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote: Hi, In my opinion if DKIM fails to validate the message content the MBP should = not display the BIMI at all (no matter why the DKIM failed). The reasoning = for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) = and as such domains can be spoofed while DKIM authenticates the actual cont= ent. BIMI logos being displayed on the message list (see Yahoo mail app) th= ey become sort of a "From" indicator from the users perspective and over ti= me will become sort of a trust indicator. BIMI should make every effort on = the standard level to discourage any use of BIMI that failed a critical val= idation of the message body as that alone could be an abuse vector. If a phishing operation targets businesses that are using shared infrastruc= tures and have BIMI, they could achieve quite a significant success if the = messages get highlighted with a logo while failing DKIM. This would undermi= ne BIMI in a major way and DKIM as well. Jakub Olexa Founder & CEO E-mail: jakub@mailkit.com Tel: +420 777 744 440 Mailkit - Closing the circle between Deliverability and Engagement On 28.04.2021 22:06, Zack Aab wrote: I was reading section 5.4 of the document and it's pretty clear what to do = if the selector header (BIMI-selector) is not included in the DMARC-aligned= DKIM signature: treat it as if there is no selector header and move on to = default._bimi. BUT What if the DKIM signature includes the BIMI-selector header but doesn't pa= ss validation AND DMARC still passes via SPF? It seems to me (given DKIM's normal use - a broken signature should be trea= ted as not having a signature) that the receiver should treat the BIMI-sele= ctor header as unsigned and move on to default._bimi, but it's not actually= stated one way or the other, so the response from the receiver could be to= stop BIMI validation entirely. Zack Aab (He/Him) Senior Consultant, Trendline Interactive O +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com -- bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi -- [https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=3D44= &d=3D404] Marc Bradshaw marcbradshaw.net | @marcbradshaw --_000_MN2PR11MB435116DF2780EF22D5E5DC21F75F9MN2PR11MB4351namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not entirely sure that answers the origina= l question.  I don’t think the OP is an attempt to second guess = DMARC. Seems more a question about should a receiver go to default._bimi (o= r something else) if the selector is specified but seems unusable (either not signed or signature fails).  If we believe= the sections A.1/A.5 covers this scenario, perhaps we just need a little e= mbellishment on this scenario below to be more explicit.  And yes, loc= al policy can impact this.

 

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy=

Comcast

 

From: bimi <bimi-bounces@ietf.org> O= n Behalf Of Marc Bradshaw
Sent: Thursday, April 29, 2021 2:56 AM
To: bimi@ietf.org
Subject: Re: [Bimi] What if DKIM doesn't validate the selector heade= r.

 

Hi,

 

Opinion: This feels like a discussion outside the sc= ope of BIMI, SPF forgery is a known issue ref the recent Multipass attack a= t a well known vendor. There is a related note in the "Unsigned BIMI-S= elector Header" section of the spec.

We do see senders with p=3Dreject who rely entirely = on SPF and do not DKIM sign at all, I would argue that the problem being de= scribed here is more about vulnerabilities in some shared infrastructure pl= atforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take = place in the DMARC group, and that BIMI should take the DMARC result as is = as much as is possible, without imposing additional constraints over what c= onstitutes a valid DMARC pass or fail.

MBPs are, of course, free to implement whatever addi= tional constraints they see fit, but I don't feel that this one belongs in = BIMI.

 

On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:<= o:p>

Hi,

In my opinion if DKIM fails to validate the message content the MBP shou= ld not display the BIMI at all (no matter why the DKIM failed). The reasoni= ng for this is that SPFs validate shared infrastructures (OL365, GSuite, et= c) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on= the message list (see Yahoo mail app) they become sort of a "From&quo= t; indicator from the users perspective and over time will become sort of a= trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical= validation of the message body as that alone could be an abuse vector.

If a phishing operation targets businesses that are using shared infrast= ructures and have BIMI, they could achieve quite a significant success if t= he messages get highlighted with a logo while failing DKIM. This would unde= rmine BIMI in a major way and DKIM as well.

On 28.04.2021 22:06, Zack Aab wrote:

I was reading section 5.4 of the document and it's p= retty clear what to do if the selector header (BIMI-selector) is not includ= ed in the DMARC-aligned DKIM signature: treat it as if there is no selector= header and move on to default._bimi.

BUT

What if the DKIM signature includes the BIMI-selecto= r header but doesn't pass validation AND DMARC still passes via SPF?

It seems to me (given DKIM's normal use - a broken s= ignature should be treated as not having a signature) that the receiver sho= uld treat the BIMI-selector header as unsigned and move on to default._bimi= , but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI = validation entirely.

 

 

Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com<= /o:p>

-- 

bimi mailing list

 

 

--

<= o:p>

  Marc Bradshaw

 

 

--_000_MN2PR11MB435116DF2780EF22D5E5DC21F75F9MN2PR11MB4351namp_-- From nobody Thu Apr 29 08:46:37 2021 Return-Path: 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 44BCB3A409D for ; Thu, 29 Apr 2021 08:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=trendlineinteractive.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 l9oD3u69--vr for ; Thu, 29 Apr 2021 08:46:30 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 12AA43A4096 for ; Thu, 29 Apr 2021 08:46:29 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id u14-20020a17090a1f0eb029014e38011b09so75866pja.5 for ; Thu, 29 Apr 2021 08:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trendlineinteractive.com; s=k1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lAqxqzO2kPvmVjqA/dGBBAU7GUnBdDxWPyrnc0zD2ZM=; b=KhXFjxftWTFbzWZswhVcnnf+Sp06WYLedFERilC/fKkvddp6hnehmQOl/Q8oUJyy/j dRt1LtWQMVQAS0ZvH3Pf5rLHU6Imcba9fZsX7GssOdaHX7Z4H3qAVbjkx45ExoyXCi3i A6Uhz51A73esPk4hUAbtj1W1CM9ObQQ/u13UPLot+fwJSd4RJIShWKvIVYUGNOWFuhO3 qDYI6ky6nkc7tWvpig+9tU3lirLhiDnHbk4LT824PwnkVa7L055EujlYQa/Ks/1fTmeG TeNVi1RkbMTWeJQ6+TSGLZ4hmOHdgQ789FfvahoQqfR42WgcIhuttm3jskOseeHJ4wyH JR5Q== 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:cc; bh=lAqxqzO2kPvmVjqA/dGBBAU7GUnBdDxWPyrnc0zD2ZM=; b=fADg2CbXFN9/GUCSoL+hl547QSxuW6ZtApSSqNj9O/l42xMEhHTF24k9A7khDHzBTb TB/8JqF8lLJLpDtq6dFmH1UJgFblARh/NugxveCPARXHV0UsbxZn3yZ/c3YdeeZdEv4q PxhwZ1z3zhQpXZwmr0RWHr7hnsTiQRkAnoU8oPD6jEd5IHy94NwXTpywFkdrRzuxblEa IoVLdBSjTMwMpuuBGAY9z/ahGtztUkS0AheqkpI+3JEym/afs1qUGi3B56E/+v02Pt27 6OO89nz8bxCyx6RTm3ENjJsbyWuIcgTs/u7fmBNnwAA80IAPtiAlMzILAGlDCl0Q6vFp eHCw== X-Gm-Message-State: AOAM531DPA8+x9e1rghDJ/+EOetdREH6EQBVtMdP4/JfXTml0J9XY9W6 dwDoq/8KhhmdG/Ywl5XLMxlpPS/KwN01hGlbhFHZYIoLjCA8kaBC X-Google-Smtp-Source: ABdhPJwF1h70LqZ7zdrYmyPWJZ8NIkz0OPQRonXxblV6g16aWwH+5UIo7WoYh3FIQ3+yKoMoxHcb5oHreNUzMUP/SGk= X-Received: by 2002:a17:90a:7783:: with SMTP id v3mr10264709pjk.177.1619711187367; Thu, 29 Apr 2021 08:46:27 -0700 (PDT) MIME-Version: 1.0 References: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> In-Reply-To: From: Zack Aab Date: Thu, 29 Apr 2021 11:45:51 -0400 Message-ID: To: "Brotman, Alex" Cc: Marc Bradshaw , "bimi@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6733b05c11e65eb" Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 15:46:36 -0000 --000000000000f6733b05c11e65eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, >Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails). This is it exactly. Maybe I missed something, but as written there is no suggested or required action if the receiver sees that the BIMI-selector is DKIM signed but that DKIM fails to validate. This can probably be covered with one line in section 5.4, it's just a question of "should the receiver skip to default._bimi. or skip BIMI entirely?" Thanks! *Zack Aab* (He/Him) Senior Consultant, Trendline Interactive *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729> | *W* trendlinei.com On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex wrote: > I=E2=80=99m not entirely sure that answers the original question. I don= =E2=80=99t think > the OP is an attempt to second guess DMARC. Seems more a question about > should a receiver go to default._bimi (or something else) if the selector > is specified but seems unusable (either not signed or signature fails). = If > we believe the sections A.1/A.5 covers this scenario, perhaps we just nee= d > a little embellishment on this scenario below to be more explicit. And > yes, local policy can impact this. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* bimi *On Behalf Of * Marc Bradshaw > *Sent:* Thursday, April 29, 2021 2:56 AM > *To:* bimi@ietf.org > *Subject:* Re: [Bimi] What if DKIM doesn't validate the selector header. > > > > Hi, > > > > Opinion: This feels like a discussion outside the scope of BIMI, SPF > forgery is a known issue ref the recent Multipass attack at a well known > vendor. There is a related note in the "Unsigned BIMI-Selector Header" > section of the spec. > > We do see senders with p=3Dreject who rely entirely on SPF and do not DKI= M > sign at all, I would argue that the problem being described here is more > about vulnerabilities in some shared infrastructure platforms and not abo= ut > how BIMI should be implemented. At the very least, I would expect that > discussion to take place in the DMARC group, and that BIMI should take th= e > DMARC result as is as much as is possible, without imposing additional > constraints over what constitutes a valid DMARC pass or fail. > > MBPs are, of course, free to implement whatever additional constraints > they see fit, but I don't feel that this one belongs in BIMI. > > > > On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote: > > Hi, > > In my opinion if DKIM fails to validate the message content the MBP shoul= d > not display the BIMI at all (no matter why the DKIM failed). The reasonin= g > for this is that SPFs validate shared infrastructures (OL365, GSuite, etc= ) > and as such domains can be spoofed while DKIM authenticates the actual > content. BIMI logos being displayed on the message list (see Yahoo mail > app) they become sort of a "From" indicator from the users perspective an= d > over time will become sort of a trust indicator. BIMI should make every > effort on the standard level to discourage any use of BIMI that failed a > critical validation of the message body as that alone could be an abuse > vector. > > If a phishing operation targets businesses that are using shared > infrastructures and have BIMI, they could achieve quite a significant > success if the messages get highlighted with a logo while failing DKIM. > This would undermine BIMI in a major way and DKIM as well. > > Jakub Olexa > > Founder & CEO > > E-mail: jakub@mailkit.com > > Tel: +420 777 744 440 <+420777744440> > > > > *Mailkit - *Closing the circle between Deliverability and Engagement > > > On 28.04.2021 22:06, Zack Aab wrote: > > I was reading section 5.4 of the document and it's pretty clear what to d= o > if the selector header (BIMI-selector) is not included in the DMARC-align= ed > DKIM signature: treat it as if there is no selector header and move on to > default._bimi. > > BUT > > What if the DKIM signature includes the BIMI-selector header but doesn't > pass validation AND DMARC still passes via SPF? > > It seems to me (given DKIM's normal use - a broken signature should be > treated as not having a signature) that the receiver should treat the > BIMI-selector header as unsigned and move on to default._bimi, but it's n= ot > actually stated one way or the other, so the response from the receiver > could be to stop BIMI validation entirely. > > > > > > *Zack Aab* (He/Him) > Senior Consultant, Trendline Interactive > *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 > <+14043176729> | *W* trendlinei.com > > > -- > > bimi mailing list > > bimi@ietf.org > > https://www.ietf.org/mailman/listinfo/bimi > > > > > > > -- > > Marc Bradshaw > > marcbradshaw.net > > | @marcbradshaw > > > > > > -- > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi > --000000000000f6733b05c11e65eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
>Seems more a question about should a receiver = go to default._bimi (or something else) if the selector is specified but se= ems unusable (either not signed or signature fails).
This is it e= xactly.=C2=A0 Maybe I missed something, but as written there is no suggeste= d or required action if the receiver sees that the BIMI-selector is DKIM si= gned but that DKIM fails to validate.=C2=A0 This can probably be covered wi= th one line in section 5.4, it's just a question of "should the re= ceiver skip to default._bimi. or skip BIMI entirely?"
Thanks= !
= Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097 |= C +1 (404) 317-672= 9 | W trendlinei.com


=
On Thu, Ap= r 29, 2021 at 11:19 AM Brotman, Alex <Alex_Brotman=3D40comcast.com@dmarc.ietf.org> wrote:

I=E2=80=99m not entirely sure that answers the origi= nal question.=C2=A0 I don=E2=80=99t think the OP is an attempt to second gu= ess DMARC. Seems more a question about should a receiver go to default._bim= i (or something else) if the selector is specified but seems unusable (either not signed or signature fails).=C2=A0 If we believe= the sections A.1/A.5 covers this scenario, perhaps we just need a little e= mbellishment on this scenario below to be more explicit.=C2=A0 And yes, loc= al policy can impact this.

=C2=A0

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast

=C2=A0

From: bimi <bimi-bounces@ietf.org> On Behalf Of = Marc Bradshaw
Sent: Thursday, April 29, 2021 2:56 AM
To: bimi@ietf.org=
Subject: Re: [Bimi] What if DKIM doesn't validate the selector h= eader.

=C2=A0

Hi,

=C2=A0

Opinion: This feels like a discussion outside the sc= ope of BIMI, SPF forgery is a known issue ref the recent Multipass attack a= t a well known vendor. There is a related note in the "Unsigned BIMI-S= elector Header" section of the spec.

We do see senders with p=3Dreject who rely entirely = on SPF and do not DKIM sign at all, I would argue that the problem being de= scribed here is more about vulnerabilities in some shared infrastructure pl= atforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take = place in the DMARC group, and that BIMI should take the DMARC result as is = as much as is possible, without imposing additional constraints over what c= onstitutes a valid DMARC pass or fail.

MBPs are, of course, free to implement whatever addi= tional constraints they see fit, but I don't feel that this one belongs= in BIMI.

=C2=A0

On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:<= u>

Hi,

In my opinion if DKIM fails to validate the message content the MBP shou= ld not display the BIMI at all (no matter why the DKIM failed). The reasoni= ng for this is that SPFs validate shared infrastructures (OL365, GSuite, et= c) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on= the message list (see Yahoo mail app) they become sort of a "From&quo= t; indicator from the users perspective and over time will become sort of a= trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical= validation of the message body as that alone could be an abuse vector.<= /u>

If a phishing operation targets businesses that are using shared infrast= ructures and have BIMI, they could achieve quite a significant success if t= he messages get highlighted with a logo while failing DKIM. This would unde= rmine BIMI in a major way and DKIM as well.

On 28.04.2021 22:06, Zack Aab wrote:

I was reading section 5.4 of the document and it'= ;s pretty clear what to do if the selector header (BIMI-selector) is not in= cluded in the DMARC-aligned DKIM signature: treat it as if there is no sele= ctor header and move on to default._bimi.

BUT

What if the DKIM signature includes the BIMI-selecto= r header but doesn't pass validation AND DMARC still passes via SPF?=

It seems to me (given DKIM's normal use - a brok= en signature should be treated as not having a signature) that the receiver= should treat the BIMI-selector header as unsigned and move on to default._= bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI = validation entirely.

=C2=A0

=C2=A0

<= span style=3D"font-size:7.5pt;font-family:Verdana,sans-serif">Zack Aab (He/Him)
Senior Consultant, Trendlin= e Interactive
O +1 (512) 7= 17-4097 | C +1 (404) 317-6729 | W trendlinei.com=

--=C2=A0

bimi mailing list

=C2=A0

=C2=A0

--

=C2=A0 Marc Bradshaw

=C2=A0=C2=A0marcbradshaw.net= |=C2=A0@marcbradshaw

=C2=A0

=C2=A0

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi
--000000000000f6733b05c11e65eb-- From nobody Thu Apr 29 18:34:27 2021 Return-Path: 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 E27843A1BCA for ; Thu, 29 Apr 2021 18:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=marcbradshaw.net header.b=ipxsMoA7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kdxQkI6z 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 nx6qv26Vnalo for ; Thu, 29 Apr 2021 18:34:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF1C3A1BC9 for ; Thu, 29 Apr 2021 18:34:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1920AA03 for ; Thu, 29 Apr 2021 21:34:20 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Thu, 29 Apr 2021 21:34:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=8nLrCNm lh3uFwz1jwvBXlEWMz2wIKAZG+kjC2VZX4FQ=; b=ipxsMoA7pOMijV4WXQys9qq pgmS4kWTdr0EVeKxxkk0l7XDaCjVPqPpKrbdFY4GLpu9AvDK37pppUQw035OlRIJ aKBwIBofbnaCnaAIylFCxHQ1BmskxyGD0FKv0fKrkNDgFNd9Ze1hGaBb834IMNUT pLzhaSuO8IBR5im8gKWq/RuUQfFD76PszJn5mRucITpsZZSMRE3OpbBj0pzbTVCc kRSqXsRLE4cpUHgYxv3yv3wumAVI/DMy4iz+uOnhRnpT/fXUur3f3KYFZq0lXisu dkg4b6liuxbmLT1F0ByKu6XUgDZ0WJXbTY6NXg+QYRi1N25H1FrpcBhdITqS6Kg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8nLrCN mlh3uFwz1jwvBXlEWMz2wIKAZG+kjC2VZX4FQ=; b=kdxQkI6zxW4kcDTYYJdtnx THrYqTltjgr+iIxOoZdY6fAUNJc+MYzNEK6KvHAluoc5XxyWlXXH64P54gFAHKc+ GzeRZqdxheY3Au+RJCPduCT03xTDI1KF7BEcueYX08l6ONBddskecR/R+MUSfnbE BuyOnadjlSe54HQ6MKXLNWVY3m50ljAr3pA4xIuQ07N8qb3lhluM+MIgP+HvDotk yD0JvahKI++p5F43G1ZqSvxaFqY9cyX0cBl98/y79GGSvuHHjT1/53u71yFHqzde /axYL/dRR3o7ABvo/WH3R/WmA6Z+AgVxYVIxWDANF5rIo68cWY+i97RvuGOlNa8A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvhedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthfkmhhgffhomhgrihhnucdlfe dtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedf ofgrrhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnh gvtheqnecuggftrfgrthhtvghrnhepveejhfehhfekkeeffffghedutdffgfdtteejfeff iedtheevudegveetieefudevnecuffhomhgrihhnpehtrhgvnhgulhhinhgvihhnthgvrh grtghtihhvvgdrtghomhdpuhhrlhguvghfvghnshgvrdgtohhmpdhivghtfhdrohhrghdp mhgrrhgtsghrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhgtsehmrghrtggs rhgrughshhgrfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5A7FE4E00AF; Thu, 29 Apr 2021 21:34:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <769bc0c8-9b1a-4f55-acea-8e3c1e95b6b5@beta.fastmail.com> In-Reply-To: References: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> Date: Fri, 30 Apr 2021 11:33:59 +1000 From: "Marc Bradshaw" To: bimi@ietf.org Content-Type: multipart/alternative; boundary=1138bee4e03e4abc821b7738c203f675 Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 01:34:27 -0000 --1138bee4e03e4abc821b7738c203f675 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I see what you are saying, this is the section... If present, the BIMI-Selector header SHOULD be included in the DMARC-ali= gned DKIM signature used to confirm authenticity of the message. If it is no= t included in the DMARC-compliant DKIM signature, the header SHOULD be ign= ored. In the absence of a clear statement of what should happen if the BIMI-Se= lector is included in a failing DKIM signature I had read (and implement= ed) this as ignoring this header unless it has a valid DKIM signature, b= ut not considering a failed signature as a blocker if DMARC passes for s= ome other reason, either SPF, or the presence of a second passing DKIM s= ignature for the same domain. I propose the modification of this section to state that failing DKIM si= gnatures SHOULD be ignored, but BIMI processing SHOULD continue. The use of SHOULD in this section was intended to cover the cases where = MBPs did not implement this check, however I would be happy to make thes= e checks a MUST, what is the opinion of the group? On Fri, 30 Apr 2021, at 1:45 AM, Zack Aab wrote: > Hi, > >Seems more a question about should a receiver go to default._bimi (or= something else) if the selector is specified but seems unusable (either= not signed or signature fails). > This is it exactly. Maybe I missed something, but as written there is= no suggested or required action if the receiver sees that the BIMI-sele= ctor is DKIM signed but that DKIM fails to validate. This can probably = be covered with one line in section 5.4, it's just a question of "should= the receiver skip to default._bimi. or skip BIMI entirely?" > Thanks! > *Zack Aab* (He/Him) > Senior Consultant, Trendline Interactive > *O* +1 (512) 717-4097 | *C* +1 (404) 317-6729 | *W* trendlinei.com >=20 >=20 > On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex wrote: >> I=E2=80=99m not entirely sure that answers the original question. I = don=E2=80=99t think the OP is an attempt to second guess DMARC. Seems mo= re a question about should a receiver go to default._bimi (or something = else) if the selector is specified but seems unusable (either not signed= or signature fails). If we believe the sections A.1/A.5 covers this sc= enario, perhaps we just need a little embellishment on this scenario bel= ow to be more explicit. And yes, local policy can impact this.____ >> __ __ >> --____ >> Alex Brotman____ >> Sr. Engineer, Anti-Abuse & Messaging Policy____ >> Comcast____ >> __ __ >> *From:* bimi *On Behalf Of * Marc Bradshaw >> *Sent:* Thursday, April 29, 2021 2:56 AM >> *To:* bimi@ietf.org >> *Subject:* Re: [Bimi] What if DKIM doesn't validate the selector head= er.____ >> __ __ >> Hi,____ >> __ __ >> Opinion: This feels like a discussion outside the scope of BIMI, SPF = forgery is a known issue ref the recent Multipass attack at a well known= vendor. There is a related note in the "Unsigned BIMI-Selector Header" = section of the spec.____ >> We do see senders with p=3Dreject who rely entirely on SPF and do not= DKIM sign at all, I would argue that the problem being described here i= s more about vulnerabilities in some shared infrastructure platforms and= not about how BIMI should be implemented. At the very least, I would ex= pect that discussion to take place in the DMARC group, and that BIMI sho= uld take the DMARC result as is as much as is possible, without imposing= additional constraints over what constitutes a valid DMARC pass or fail= .____ >> MBPs are, of course, free to implement whatever additional constraint= s they see fit, but I don't feel that this one belongs in BIMI.____ >> __ __ >> On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:____ >>> Hi,____ >>> In my opinion if DKIM fails to validate the message content the MBP = should not display the BIMI at all (no matter why the DKIM failed). The = reasoning for this is that SPFs validate shared infrastructures (OL365, = GSuite, etc) and as such domains can be spoofed while DKIM authenticates= the actual content. BIMI logos being displayed on the message list (see= Yahoo mail app) they become sort of a "From" indicator from the users p= erspective and over time will become sort of a trust indicator. BIMI sho= uld make every effort on the standard level to discourage any use of BIM= I that failed a critical validation of the message body as that alone co= uld be an abuse vector.____ >>> If a phishing operation targets businesses that are using shared inf= rastructures and have BIMI, they could achieve quite a significant succe= ss if the messages get highlighted with a logo while failing DKIM. This = would undermine BIMI in a major way and DKIM as well.____ >>> Jakub Olexa____ >>> Founder & CEO____ >>> E-mail: jakub@mailkit.com____ >>> Tel: +420 777 744 440 __ __ >>> __ __ >>> *Mailkit - *Closing the circle between Deliverability and Engagement= ___= _ >>> On 28.04.2021 22:06, Zack Aab wrote:____ >>>> I was reading section 5.4 of the document and it's pretty clear wha= t to do if the selector header (BIMI-selector) is not included in the DM= ARC-aligned DKIM signature: treat it as if there is no selector header a= nd move on to default._bimi.____ >>>> BUT____ >>>> What if the DKIM signature includes the BIMI-selector header but do= esn't pass validation AND DMARC still passes via SPF?____ >>>> It seems to me (given DKIM's normal use - a broken signature should= be treated as not having a signature) that the receiver should treat th= e BIMI-selector header as unsigned and move on to default._bimi, but it'= s not actually stated one way or the other, so the response from the rec= eiver could be to stop BIMI validation entirely.____ >>>> __ __ >>>> __ __ >>>> *Zack Aab* (He/Him) >>>> Senior Consultant, Trendline Interactive >>>> *O* +1 (512) 717-4097 | *C* +1 (404) 317-6729 | *W* trendlinei.com ____ >>> -- ____ >>> bimi mailing list____ >>> bimi@ietf.org ____ >>> https://www.ietf.org/mailman/listinfo/bimi ____ >>> __ __ >> __ __ >> --____ >> ____ >> Marc Bradshaw____ >> marcbradshaw.net | @marcbradshaw ____ >> __ __ >> __ __ >> --=20 >> bimi mailing list >> bimi@ietf.org >> https://www.ietf.org/mailman/listinfo/bimi > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi >=20 -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --1138bee4e03e4abc821b7738c203f675 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I see what you are saying, this is the section...
<= /div>

If present, the BIMI-Selector header SHOULD be = included in the DMARC-aligned
DKIM signature used to confi= rm authenticity of the message.  If it is not
include= d in the DMARC-compliant DKIM signature, the header SHOULD be ignored.

In the absence of a clear statement of what = should happen if the BIMI-Selector is included in a failing DKIM signatu= re I had read (and implemented) this as ignoring this header unless it h= as a valid DKIM signature, but not considering a failed signature as a b= locker if DMARC passes for some other reason, either SPF, or the presenc= e of a second passing DKIM signature for the same domain.
=
I propose the modification of this section to state that = failing DKIM signatures SHOULD be ignored, but BIMI processing SHOULD co= ntinue.
The use of SHOULD in this section was intended to = cover the cases where MBPs did not implement this check, however I would= be happy to make these checks a MUST, what is the opinion of the group?=

On Fri, 30 Apr 2021, at 1:45 AM, Zack Aab = wrote:
Hi,
>Seems more a question about should a re= ceiver go to default._bimi (or something else) if the selector is specif= ied but seems unusable (either not signed or signature fails).
=
This is it exactly.  Maybe I missed something, but as written = there is no suggested or required action if the receiver sees that the B= IMI-selector is DKIM signed but that DKIM fails to validate.  This = can probably be covered with one line in section 5.4, it's just a questi= on of "should the receiver skip to default._bimi. or skip BIMI entirely?= "
Thanks!
Zack Aab= (He/Him)
Senior Consultant, Trendline Interactive
O +1= (512) 717-4097 | C +1 (404) 317-6729 | W trendlinei.com

=

On Thu, Apr 29, 2021 at 11:19 AM Brotman, = Alex <Alex_Brotman=3D= 40comcast.com@dmarc.ietf.org> wrote:

I=E2=80=99m not entirely= sure that answers the original question.  I don=E2=80=99t think th= e OP is an attempt to second guess DMARC. Seems more a question about sh= ould a receiver go to default._bimi (or something else) if the selector = is specified but seems unusable (either not signed or signature fails).  If we beli= eve the sections A.1/A.5 covers this scenario, perhaps we just need a li= ttle embellishment on this scenario below to be more explicit.  And= yes, local policy can impact this.

 

--<= u>

Alex Brotman

Sr. Engineer, Anti-Abuse & Messag= ing Policy

Comcast=

 
<= /p>

From:<= /b> bimi <= bimi-bounces@ietf.org> On Behalf Of Marc Bradshaw
Sent: Thursday, April 29, 2021 2:56 AM
Subject: Re: [Bimi] What if DKIM doesn't vali= date the selector header.

 

Hi,

<= u> 

Opinion:= This feels like a discussion outside the scope of BIMI, SPF forgery is = a known issue ref the recent Multipass attack at a well known vendor. Th= ere is a related note in the "Unsigned BIMI-Selector Header" section of = the spec.

We d= o see senders with p=3Dreject who rely entirely on SPF and do not DKIM s= ign at all, I would argue that the problem being described here is more = about vulnerabilities in some shared infrastructure platforms and not ab= out how BIMI should be implemented. At the very least, I would expect that discussion to ta= ke place in the DMARC group, and that BIMI should take the DMARC result = as is as much as is possible, without imposing additional constraints ov= er what constitutes a valid DMARC pass or fail.

MBPs ar= e, of course, free to implement whatever additional constraints they see= fit, but I don't feel that this one belongs in BIMI.
<= /p>

 

On Thu, 29 Apr 2021, at 4:26 PM, Jakub = Olexa wrote:

Hi,

In my opinion if DKIM fails to validate the messa= ge content the MBP should not display the BIMI at all (no matter why the= DKIM failed). The reasoning for this is that SPFs validate shared infra= structures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed= on the message list (see Yahoo mail app) they become sort of a "From" i= ndicator from the users perspective and over time will become sort of a = trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a criti= cal validation of the message body as that alone could be an abuse vecto= r.

If a phishing operation targets businesses th= at are using shared infrastructures and have BIMI, they could achieve qu= ite a significant success if the messages get highlighted with a logo wh= ile failing DKIM. This would undermine BIMI in a major way and DKIM as well.

On 28.04.2021 22:06, Zack Aab wrote:

I was reading section 5.4 of the document and= it's pretty clear what to do if the selector header (BIMI-selector) is = not included in the DMARC-aligned DKIM signature: treat it as if there i= s no selector header and move on to default._bimi.

=

BUT

What if the DKIM signature includes the BIMI-= selector header but doesn't pass validation AND DMARC still passes via S= PF?

It seems t= o me (given DKIM's normal use - a broken signature should be treated as = not having a signature) that the receiver should treat the BIMI-selector= header as unsigned and move on to default._bimi, but it's not actually = stated one way or the other, so the response from the receiver could be to stop BI= MI validation entirely.

 

 

Zack Aab= <= span class=3D"size" style=3D"font-size:7.5pt;"> (He/Him) Senior Consultant, = Trendline Interactive
O +1 (512) 717-4097 | C +1 (404) 317-6729 | W trendlin= ei.com

-- 

bimi mailing list<= u>

 
=

 

--

=


  Marc Bradshaw

 <= br>

 

--
bimi mailing list<= br>
-- 
bimi mailing list
=


--

=
  Marc Bradshaw
  marcbradshaw.ne= t | @marcbradshaw<= /a>


--1138bee4e03e4abc821b7738c203f675-- From nobody Thu Apr 29 23:44:35 2021 Return-Path: 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 25B533A16BE for ; Thu, 29 Apr 2021 23:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailkit.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 WZoUDcobP5LA for ; Thu, 29 Apr 2021 23:44:28 -0700 (PDT) Received: from mail.mailkit.eu (mail.mailkit.eu [185.136.200.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5213A16BB for ; Thu, 29 Apr 2021 23:44:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mailkit.eu (Postfix) with ESMTP id 9FE212055F for ; Fri, 30 Apr 2021 08:44:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailkit.eu Received: from mail.mailkit.eu ([127.0.0.1]) by localhost (mail.mailkit.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeY18z_DXoe0 for ; Fri, 30 Apr 2021 08:44:21 +0200 (CEST) To: bimi@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailkit.com; s=mk-2; t=1619765060; bh=gIHgDp+err1GhKCBisNKZ+DIQQ+V4i+12OO5kHn8Q8I=; h=To:References:From:Subject:Date:In-Reply-To; b=G/TQuKKPYEb7K5KLDLDjurwzfaoaxbBW7AhH3XiRez+rY7mSjG3WtTB73gIiCLgk5 FuHyqmjqVg/gCcqvgUVuTU2EJxq0UHyzLWNgucuyXJhyerx8RIeM7aYWVEJ4putn6R aPtrM9nYWHhxwH57/NEKdNvgV/9iJ5F3ZKVp/LeaFFaC6+zvNf4JiXmCQ12jIaxqZc DMrW5Ok1zp/fPm3XA8m/+ixZW3tOKfrCITfunUf1U7BF1vAtH52avnXH7bUHHaHmCb 8Xar8Phnu4TBv5ZlqW/RYHPFNEpNH3dVdQ36hi0ai9Ysbo51hEq/3YMedMIgBCjcUM gqApqquQHULVA== References: <152a93bd-754a-45d3-af84-b58d385d997a@beta.fastmail.com> <769bc0c8-9b1a-4f55-acea-8e3c1e95b6b5@beta.fastmail.com> From: Jakub Olexa Organization: Mailkit Message-ID: Date: Fri, 30 Apr 2021 08:44:20 +0200 MIME-Version: 1.0 In-Reply-To: <769bc0c8-9b1a-4f55-acea-8e3c1e95b6b5@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------FA31E81BF4DBC33AB02FB7D3" Content-Language: en-US Archived-At: Subject: Re: [Bimi] What if DKIM doesn't validate the selector header. X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 06:44:34 -0000 This is a multi-part message in MIME format. --------------FA31E81BF4DBC33AB02FB7D3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable If the logic relies only on DMARC authenticating rather than DKIM pass=20 then what is the abuse risk if the BIMI-Selector header is unsigned? You = trust the source domain, the BIMI record comes from that "trusted=20 source" and there was a clear intent from the sender for a specific=20 selector. I'd suggest a binary choice here - either MUST or no signature = requirement for the selector at all. Jakub Olexa Founder & CEO E-mail: jakub@mailkit.com Tel: +420 777 744 440 Mailkit - Closing the circle between Deliverability and Engagement=20 On 30.04.2021 3:33, Marc Bradshaw wrote: > Hi, > > I see what you are saying, this is the section... > > If present, the BIMI-Selector header SHOULD be included in the=20 > DMARC-aligned > DKIM signature used to confirm authenticity of the message. If it is no= t > included in the DMARC-compliant DKIM signature, the header SHOULD be=20 > ignored. > > In the absence of a clear statement of what should happen if the=20 > BIMI-Selector is included in a failing DKIM signature I had read (and=20 > implemented) this as ignoring this header unless it has a valid DKIM=20 > signature, but not considering a failed signature as a blocker if=20 > DMARC passes for some other reason, either SPF, or the presence of a=20 > second passing DKIM signature for the same domain. > > I propose the modification of this section to state that failing DKIM=20 > signatures SHOULD be ignored, but BIMI processing SHOULD continue. > The use of SHOULD in this section was intended to cover the cases=20 > where MBPs did not implement this check, however I would be happy to=20 > make these checks a MUST, what is the opinion of the group? > > On Fri, 30 Apr 2021, at 1:45 AM, Zack Aab wrote: >> Hi, >> >Seems more a question about should a receiver go to default._bimi=20 >> (or something else) if the selector is specified but seems unusable=20 >> (either not signed or signature fails). >> This is it exactly.=C2=A0 Maybe I missed something, but as written the= re=20 >> is no suggested or required action if the receiver sees that the=20 >> BIMI-selector is DKIM signed but that DKIM fails to validate.=C2=A0 Th= is=20 >> can probably be covered with one line in section 5.4, it's just a=20 >> question of "should the receiver skip to default._bimi. or skip BIMI=20 >> entirely?" >> Thanks! >> *Zack Aab* (He/Him) >> Senior Consultant, Trendline Interactive >> *O* +1 (512) 717-4097 | *C* +1 (404) 317-6729=20 >> | *W* trendlinei.com=20 >> >> >> >> On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex=20 >> > > wrote: >> >> I=E2=80=99m not entirely sure that answers the original question.=C2= =A0 I >> don=E2=80=99t think the OP is an attempt to second guess DMARC. Se= ems >> more a question about should a receiver go to default._bimi (or >> something else) if the selector is specified but seems unusable >> (either not signed or signature fails).=C2=A0 If we believe the >> sections A.1/A.5 covers this scenario, perhaps we just need a >> little embellishment on this scenario below to be more explicit.=C2= =A0 >> And yes, local policy can impact this. >> >> >> -- >> >> Alex Brotman >> >> Sr. Engineer, Anti-Abuse & Messaging Policy >> >> Comcast >> >> >> *From:* bimi > > *On Behalf Of * Marc Bradshaw >> *Sent:* Thursday, April 29, 2021 2:56 AM >> *To:* bimi@ietf.org >> *Subject:* Re: [Bimi] What if DKIM doesn't validate the selector >> header. >> >> >> Hi, >> >> >> Opinion: This feels like a discussion outside the scope of BIMI, >> SPF forgery is a known issue ref the recent Multipass attack at a >> well known vendor. There is a related note in the "Unsigned >> BIMI-Selector Header" section of the spec. >> >> We do see senders with p=3Dreject who rely entirely on SPF and do >> not DKIM sign at all, I would argue that the problem being >> described here is more about vulnerabilities in some shared >> infrastructure platforms and not about how BIMI should be >> implemented. At the very least, I would expect that discussion to >> take place in the DMARC group, and that BIMI should take the >> DMARC result as is as much as is possible, without imposing >> additional constraints over what constitutes a valid DMARC pass >> or fail. >> >> MBPs are, of course, free to implement whatever additional >> constraints they see fit, but I don't feel that this one belongs >> in BIMI. >> >> >> On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote: >> >> Hi, >> >> In my opinion if DKIM fails to validate the message content >> the MBP should not display the BIMI at all (no matter why the >> DKIM failed). The reasoning for this is that SPFs validate >> shared infrastructures (OL365, GSuite, etc) and as such >> domains can be spoofed while DKIM authenticates the actual >> content. BIMI logos being displayed on the message list (see >> Yahoo mail app) they become sort of a "From" indicator from >> the users perspective and over time will become sort of a >> trust indicator. BIMI should make every effort on the >> standard level to discourage any use of BIMI that failed a >> critical validation of the message body as that alone could >> be an abuse vector. >> >> If a phishing operation targets businesses that are using >> shared infrastructures and have BIMI, they could achieve >> quite a significant success if the messages get highlighted >> with a logo while failing DKIM. This would undermine BIMI in >> a major way and DKIM as well. >> >> Jakub Olexa >> >> Founder & CEO >> >> E-mail: jakub@mailkit.com >> >> Tel: +420 777 744 440 >> >> >> *Mailkit - *Closing the circle between Deliverability and >> Engagement >> >> >> On 28.04.2021 22:06, Zack Aab wrote: >> >> I was reading section 5.4 of the document and it's pretty >> clear what to do if the selector header (BIMI-selector) >> is not included in the DMARC-aligned DKIM signature: >> treat it as if there is no selector header and move on to >> default._bimi. >> >> BUT >> >> What if the DKIM signature includes the BIMI-selector >> header but doesn't pass validation AND DMARC still passes >> via SPF? >> >> It seems to me (given DKIM's normal use - a broken >> signature should be treated as not having a signature) >> that the receiver should treat the BIMI-selector header >> as unsigned and move on to default._bimi, but it's not >> actually stated one way or the other, so the response >> from the receiver could be to stop BIMI validation entirel= y. >> >> >> >> *Zack Aab*(He/Him) >> Senior Consultant, Trendline Interactive >> *O* +1 (512) 717-4097 | *C* +1 (404) >> 317-6729 | *W* trendlinei.com >> >> >> --=20 >> >> bimi mailing list >> >> bimi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bimi >> >> >> >> >> -- >> >> >> =09 >> >> =C2=A0 Marc Bradshaw >> >> marcbradshaw.net >> >> | @marcbradshaw >> >> >> >> >> --=20 >> bimi mailing list >> bimi@ietf.org >> https://www.ietf.org/mailman/listinfo/bimi >> >> >> --=20 >> bimi mailing list >> bimi@ietf.org >> https://www.ietf.org/mailman/listinfo/bimi=20 >> >> > > -- > > =09 > =C2=A0 Marc Bradshaw > marcbradshaw.net | @marcbradshaw=20 > > > > > --------------FA31E81BF4DBC33AB02FB7D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

If the logic relies only on DMARC authenticating rather than DKIM pass then what is the abuse risk if the BIMI-Selector header is unsigned? You trust the source domain, the BIMI record comes from that "trusted source" and there was a clear intent from the sender for a specific selector. I'd suggest a binary choice here - either MUST or no signature requirement for the selector at all.

Jakub Olexa
= Founder & CEO
= E-mail: jakub= @mailkit.com
= Tel: +420 777 744 440

Mailkit - Closing the circle between Deliverability and Engagement

On 30.04.2021 3:33, Marc Bradshaw wrote: