From nobody Tue Jun 2 09:44:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483CE3A0CA0 for ; Tue, 2 Jun 2020 09:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu 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 FZ7iA6tJgLCs for ; Tue, 2 Jun 2020 09:44:32 -0700 (PDT) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 49D403A0C99 for ; Tue, 2 Jun 2020 09:44:31 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QBB00DCZ566N5A0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 02 Jun 2020 11:44:30 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.2.163616, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.5.19.5740000, SenderIP=[104.47.70.102] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gs611JAcFb+uGTc/oMzpF+tzbE7xqXQ6hOsB7bIiL8mtXVsf2xpceyTUbKOjNiVwFy4pZk/Ar3XM7/7aIxV+YYCuz7YMp/5O28p4lCTaMoRk99P23jzfy2EVOpweFqRWqXhliVVcfFAE/RTT9d2xFEHmLhgEHzMNnB4bYdAC6L5lqZ6JSwEpCDa+VtF+4rdim3kY5Tv/aG9v0tcrSau3Wgss6vtobLQ48UkS7hB1eMlLTn3XvPTdS9MvPYIfOg9GAgofKmbXpQCTqg1KZ9QUiBTOy4SL5MRIJCGPVGsD4v35tV3AOaq3SAhHkvV4+d4WGmGtdCR3Y6b818saymimSg== 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=uP1AFNKpbRwHu1Zx6sh8VQzGvkjSadqAr3A/O7sZhrw=; b=OXTrG3aeyzN8xpYcrueNDkbSQ4CyVyhgzdJbtBzDbi1FtZXx81/lU3YvtyyK5Ds7yR27L3yIBOIg/DlD6OwrVXcSlFrSSVnuDZDLp8iKHcTuuKcbYgcSBAKceG8UZa36eFe2yIGrkHThJ+LmEJzwu6S7wBZjdIErbY97vjEE4C3FlfTuxi7Ky2rlyCj3yCRJUoRKik5YMPZvBLqnZdQH73feme5v4empFGEj/42d5X/dEWXC4zBf573ydR7l0OyL7XMOIU1ATT0GHj6sekWngzfL25bZ6byKXdQBN+MSgHThDqE5JKzeSfTx70sqhOoZTACMCf3rWp7SzukB2xdldQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uP1AFNKpbRwHu1Zx6sh8VQzGvkjSadqAr3A/O7sZhrw=; b=TTwkhWNVfz/8s/WnEmc+5aOg5uNSzqFt/OabZs0V8MCPrnqS1eJ2iA9nGQLy6/eRrxtjJmm2DzXaUwukfB9gK2Bk2iH8ytoPV/wPA/32PjbfUaayvSNRHHfWZeHnbGqg9c4KPYRaGaBhrP4vjilPxo6RUj7fFScMjGNRQiKw6l4= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR0601MB3718.namprd06.prod.outlook.com (2603:10b6:4:77::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.25; Tue, 2 Jun 2020 16:44:29 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::85c:984b:d5ea:b2a4]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::85c:984b:d5ea:b2a4%6]) with mapi id 15.20.3066.018; Tue, 2 Jun 2020 16:44:29 +0000 From: Jesse Thompson To: "dmarc@ietf.org" Thread-topic: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields Thread-index: AQHWOPpmfzKSzdFoG0WHtc/gNTjvSg== Date: Tue, 2 Jun 2020 16:44:28 +0000 Message-id: Accept-Language: en-US, es-MX, en-GB Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [47.12.96.133] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e9a34a5f-3064-44d0-05a2-08d8071437d9 x-ms-traffictypediagnostic: DM5PR0601MB3718: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0422860ED4 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MIjjLnaFepExU+5kcywAIrbNxj1LybInM9ysRwsbXYjBEuusamtI4X2m1y2wMLfriJ+hvHP0y9wAhkfJsQQNyxjMOYiNwvN1F8fHVDhKQIgjeZwSfoFAGwX7bfVTIwgk56islqNv4GuLU8bJznXt9XWiOQCIjIBBqmAznKx93JA3gwMp8VfcBoDSyDGvLygkw0Lt7HD97KOjsRoW7+ZocBVTl45BFbFZwcHEDvJyNAI173fO0kwzT1SSSk0GuILG/zaDVzmyN7y85Ss3xlGo1SO80zA9br5F6+lsoU6O7n7AyyHyHzZCYXJrss5+Zyfp X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(376002)(346002)(396003)(366004)(55016002)(66446008)(66556008)(76116006)(8936002)(8676002)(66946007)(66476007)(33656002)(52536014)(786003)(5660300002)(64756008)(9686003)(316002)(478600001)(44832011)(75432002)(66574014)(71200400001)(6506007)(83380400001)(7696005)(86362001)(186003)(2906002)(6916009)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nhNZz0+vYLXScOuGHO5rOaGB4hJhz+iW8SiqzZWxX0mqYCA7+5VTVMbolOL/RjVpYS6TvJ19/RjrVRYxs7zgvnQ6aGWamEEYXrBwkcCm6tIKMH0cLKEIXtFSCAjeyC9AUZODvo5Hy3nFbdNMjKIxxVUNSv2Ffq7ZnkKHKGsmq55fhqfc5XnMay+HWS8VgEKNrunS13k6V1mQN2dd+sTyWVvz7oE6O+UgWajDneT9N5OhCiN0il3NoYQybcORypTYN0p7u9vpKmGt+DJ6vWXHvfJWFqPAnKh6Afgs63BOWp1Sf/tTVPtYw1L6/Mi7XDdUFasddCHriuGkiGM7081uL9B8cog8gbTNFcPnj0s8EGIs96yifksb5EfO00seZc/5ktDVYrBbKIE108rnzIfmqfSBFypm+UhiJ9K/A9CNkXx0TI0YVRQpONzVMSHBE5KFvRAQxaUeeySpeIS9wD4FW2vmh/X7q1b5hMBPJ8g7HFE= x-ms-exchange-transport-forked: True Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable MIME-version: 1.0 X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: e9a34a5f-3064-44d0-05a2-08d8071437d9 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2020 16:44:28.9815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bKORspFrZ3VxrZ/UpoEOULwzLkVr9DAQlDqfVoOHv1c8Zgc8IFaDYXKUn4GlFXK9MJoMhBfClm15bfPMNb63kA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0601MB3718 Archived-At: Subject: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 16:44:34 -0000 I'm relaying these DMARC questions/concerns on behalf of an email admin at = another university.=A0 I quickly searched this list's archives for the Send= er header vs DMARC alignment issue and don't see much aside from a conversa= tion in May 2015.=A0 Is it worth further discussion and/or an issue in Trac= ? I think I know the answer to the second concern, but I'll defer to peopl= e more adept at explaining the nuance.=0A= =0A= See below...=0A= =0A= Thanks,=0A= Jesse Thompson=0A= UW-Madison=0A= =0A= "=0A= I don't see on the list of issues the most fundamental problem of=A0DMARC, = namely that it conflicts with RFC 5322 on the use of the From and Sender he= ader fields [1] and possibly with RFC 6326 as to the significance of DKIM f= ail [2].=A0 The former is the more serious problem. Making=A0DMARC=A0alignm= ent part of a standard for Internet messages requires a revision of RFC 532= 2. I'd love to see this resolved.=0A= =0A= [1]=0A= The "From:" field specifies the author(s) of the message,=0A= that is, the mailbox(es) of the person(s) or system(s) responsible=0A= for the writing of the message. The "Sender:" field specifies the=0A= mailbox of the agent responsible for the actual transmission of the=0A= message.=0A= =0A= [2]=0A= signature verification failure does not force rejection of the message;=0A= "= From nobody Tue Jun 2 10:01:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D703A0CAB for ; Tue, 2 Jun 2020 10:01:01 -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, FREEMAIL_FROM=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=gmail.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 GiVvLu3R3y-e for ; Tue, 2 Jun 2020 10:00:59 -0700 (PDT) Received: from mail-oo1-xc42.google.com (mail-oo1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (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 48F7E3A0CA7 for ; Tue, 2 Jun 2020 10:00:59 -0700 (PDT) Received: by mail-oo1-xc42.google.com with SMTP id z145so788143ooa.13 for ; Tue, 02 Jun 2020 10:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=5CHJpzI6n+Pk74xsntZhypva6/PNlCMUShU6d6N/uSo=; b=scmBMCPMHuHVae+qPw4ZkY/7mV0qGQsb71cmOecGGl28ynJjIHxdNNZRvwgiQwMSl7 tzASvNvusa6fbgUNNOpiOAsDbXbKSZjQO9VsG1VLJDuZv7Of0ERy2ol9kdCqnOmSk5aG 8EfbfnnH4VIGfvo0l492bejGv0/lC1w7jVKzBUHaId3wO1+4p2UUrR2FGsmAtDJt1QOy 01CdvlkcIEfCbq/fNwFgfoAlXFTwXfqiGHCC38tom7flq/eWizt9UV9TBv/p1Btn8F4s Df9QQBVacgx8RtRaKKTLwC9LU2w/w+dkK0AyKHr3txdyT2vhC9UFuc+4IEtJ5+Whp7pn hhig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5CHJpzI6n+Pk74xsntZhypva6/PNlCMUShU6d6N/uSo=; b=aDv6NfoAoEnMx6kZSta8ZutQK1gGjmlszyvpE3TZ1yVEUhZuCuRavhvcvy9Edzja5Q 5LhBHYIA4IddL+fj1Z2V98M6JVdnQOxkNTIpewWl+XIwWwI1gvWNYopA6rWIgymSxWiZ cJt2ctZPpmFpFbGQwm4CaOy6h+SWhlbHe408qbaYkCIFsCYkLHR2muTdHkaDJjT4zGp/ 43uikFOqo2cyib9e1ZIKRNbBffDWtlo+Yd9Y2lqVgixgKNIRbteZJQRRwsHNBAzMHwN0 L0LCw0K4S6qWSBDdVwx1xZXK0glAHtE6LmEUZKAXBOuL5xurkSJlAJoWIFk4XobEALss ADpA== X-Gm-Message-State: AOAM531xZLH982vtyOqGzSxFUM2NSpm9nI5naM6gzhvth2mYUx8Tfh8u zySeuMGdt7M9oB1OgXkko62zBN62 X-Google-Smtp-Source: ABdhPJzIqSpoGIAqQ3GqaA5QCz/iqok3feQkcOx+ThvIQ43KfKT6hFdjy5j+hxAlKdHLFTDSMm5wQQ== X-Received: by 2002:a4a:bf14:: with SMTP id r20mr21312597oop.18.1591117258139; Tue, 02 Jun 2020 10:00:58 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id p205sm813037oih.48.2020.06.02.10.00.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 10:00:57 -0700 (PDT) To: "dmarc@ietf.org" References: From: Dave Crocker Message-ID: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> Date: Tue, 2 Jun 2020 10:00:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 17:01:01 -0000 On 6/2/2020 9:44 AM, Jesse Thompson wrote: > I'm relaying these DMARC questions/concerns on behalf of an email admin at another university.  I quickly searched this list's archives for the Sender header vs DMARC alignment issue and don't see much aside from a conversation in May 2015.  Is it worth further discussion and/or an issue in Trac? I think I know the answer to the second concern, but I'll defer to people more adept at explaining the nuance. > > See below... > > Thanks, > Jesse Thompson > UW-Madison > > " > I don't see on the list of issues the most fundamental problem of DMARC, namely that it conflicts with RFC 5322 on the use of the From and Sender header fields [1] and possibly with RFC 6326 as to the significance of DKIM fail [2].  The former is the more serious problem. Making DMARC alignment part of a standard for Internet messages requires a revision of RFC 5322. I'd love to see this resolved. As one of the folk who created the Sender: construct in RFC 733, I'll suggest that the concern raised here has merit, though dealing with the fact isn't straightforward.  It's an issue I've been wrestling with for a couple of years. In reality, all of the current email anti-abuse authentication methods concern the email operator, not the author. The problem is that, in the message, the only identifier that is reliably present is the rfc5322.From field email address. The underlying design choice in RFC733 -- 45 years ago -- was in making Sender: optional when it's content is the same as the From: field.  It never occurred to us that one of them might need changing along the handling path.  The lesson to future designers is to strongly resist conflating otherwise-independent semantics for "efficiency". DMARC enforcement requires that the DKIM/SPF domain be the same as the author From:.  That is, the folk doing email operations have to be able to sign the DMARC aligned domain. Hence the From: field is now really the Sender: field.  The From: field fixup hacks that are needed by intermediaries, to avoid DMARC-based rejections, makes this fact painfully clear, even as they serve to undermine recipient use of the From field for author-related message management. Given the depth and momentum of DMARC's effects, I don't think it's realistic to try to fix this via changes to the From: field. The only suggestion I've been able to formulate is:  create a new field, such as Author:. (Give it a simple, clean, appropriate name, rather than something like Original-From.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 10:12:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA03A0CE3 for ; Tue, 2 Jun 2020 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7VUsxnAoEiAP for ; Tue, 2 Jun 2020 10:12:06 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 C02C43A0CD6 for ; Tue, 2 Jun 2020 10:12:05 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id c1so2448939vsc.11 for ; Tue, 02 Jun 2020 10:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2abeTZTlV438+1OIRubP2Rf9vvgdpF+4BxYRR6nL7Bw=; b=Iima5ZNZhqiMzLSrzeH6KgHjpWT/qI2zp3AjztkC//Ir4A6VLL7RaM/eqlM82NizpL IWWlE6wvUaeG13zTqayCYwxLaKGoIREFr15+Fh9ckmMGrjvRQhgnneJwMUcztQL6M40S o5U2oqzZHQpSlhGKeOTslCmEfMTYVI2MQ9h7PaSb/j57bRlZuWonmbY4AOTJb3PyBZBI IUHryW9Z+hWcu4ynNBKuP3/HDaiP5nv7PJ8jOCsJaLUazRm919x+ZHurjY7L+mGraaHY 9rQ1xR61MOevXZN4hb1BbRjoAm8XFOUJp95iXrf2IgayxHUhmN6bu962IfQJGcQxM/00 BaMw== 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=2abeTZTlV438+1OIRubP2Rf9vvgdpF+4BxYRR6nL7Bw=; b=dDcctaKRrMM4hUelWv8lAK+epuWwZ8iNItI8Z1Vw5sf1aPRBGVIbx21hofkWhTkY99 JC7hRQgiM0fLkzCVws05CiKpcpC1bacy3OR3u8Aia3L0Xmcmx/x5pIFtxA8H/ZCi1tL3 Dr5ckOjK8MkEFSsNzzEADpzYaFNOTQWRntwPYAcsZoHHmCgYWKYnugV1NuzFeTgQ3kn/ Cl0h6+7+OP120XDk05skzdqASkoCQL0i9ubxGnUHz/5f89AmxKqLL9Zoo2EEcuRlThPG 8vooTCfsG7EYMCp9i7/h+gLZ3nEXw++KNNDtQJXlasfTnDtTpBqtMh9afbDwdQB53qxA 0obg== X-Gm-Message-State: AOAM532YnuG1CDPAfx1QNw3IeQ9Upa26l1EMTF13pGKfr44/+SX+odaR won6XgVViIzGHxnER/ayZDyJdCcMv0Z50aj0pGkQK4A= X-Google-Smtp-Source: ABdhPJygS67ljS6WgcDjPK3IWO7N1NMNvLxMkWnV1q4YXQhpBAk9BsW5tkLrqqQLMZVS9DydiybXWihx3AVEe5GN/x8= X-Received: by 2002:a05:6102:36b:: with SMTP id f11mr5111368vsa.124.1591117924095; Tue, 02 Jun 2020 10:12:04 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> In-Reply-To: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> From: Brandon Long Date: Tue, 2 Jun 2020 10:11:50 -0700 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000aa168a05a71d02a3" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 17:12:15 -0000 --000000000000aa168a05a71d02a3 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 10:01 AM Dave Crocker wrote: > On 6/2/2020 9:44 AM, Jesse Thompson wrote: > > I'm relaying these DMARC questions/concerns on behalf of an email admin > at another university. I quickly searched this list's archives for the > Sender header vs DMARC alignment issue and don't see much aside from a > conversation in May 2015. Is it worth further discussion and/or an issue > in Trac? I think I know the answer to the second concern, but I'll defer > to people more adept at explaining the nuance. > > > > See below... > > > > Thanks, > > Jesse Thompson > > UW-Madison > > > > " > > I don't see on the list of issues the most fundamental problem of DMARC, > namely that it conflicts with RFC 5322 on the use of the From and Sender > header fields [1] and possibly with RFC 6326 as to the significance of DKIM > fail [2]. The former is the more serious problem. Making DMARC alignment > part of a standard for Internet messages requires a revision of RFC 5322. > I'd love to see this resolved. > > > As one of the folk who created the Sender: construct in RFC 733, I'll > suggest that the concern raised here has merit, though dealing with the > fact isn't straightforward. It's an issue I've been wrestling with for > a couple of years. > > In reality, all of the current email anti-abuse authentication methods > concern the email operator, not the author. > > The problem is that, in the message, the only identifier that is > reliably present is the rfc5322.From field email address. > > The underlying design choice in RFC733 -- 45 years ago -- was in making > Sender: optional when it's content is the same as the From: field. It > never occurred to us that one of them might need changing along the > handling path. The lesson to future designers is to strongly resist > conflating otherwise-independent semantics for "efficiency". > > DMARC enforcement requires that the DKIM/SPF domain be the same as the > author From:. That is, the folk doing email operations have to be able > to sign the DMARC aligned domain. > > Hence the From: field is now really the Sender: field. The From: field > fixup hacks that are needed by intermediaries, to avoid DMARC-based > rejections, makes this fact painfully clear, even as they serve to > undermine recipient use of the From field for author-related message > management. > > Given the depth and momentum of DMARC's effects, I don't think it's > realistic to try to fix this via changes to the From: field. > > The only suggestion I've been able to formulate is: create a new field, > such as Author:. > > (Give it a simple, clean, appropriate name, rather than something like > Original-From.) > And if the mail client displays the Author, then we're kind of back to square one with displaying unvalidated data to the user. Which is to say, DMARC is just policy, but what makes it different from the previous policy attempts is that it requires the visible author/operator to be authenticated. There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. At some point, you're going up against the existing mail client design and of course how users act, and of course all of that is messy. The "clean" strictness and mechanical nature of DMARC is ultimately up against the fuzzy ux design and fuzzier humans. On top of that, the author domains basically want to control who can send on their behalf, which is a reasonable goal as well. Brandon --000000000000aa168a05a71d02a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 2, 2020 at 10:01 AM Dave = Crocker <dcrocker@gmail.com>= ; wrote:
On 6/2/= 2020 9:44 AM, Jesse Thompson wrote:
> I'm relaying these DMARC questions/concerns on behalf of an email = admin at another university.=C2=A0 I quickly searched this list's archi= ves for the Sender header vs DMARC alignment issue and don't see much a= side from a conversation in May 2015.=C2=A0 Is it worth further discussion = and/or an issue in Trac?=C2=A0 I think I know the answer to the second conc= ern, but I'll defer to people more adept at explaining the nuance.
>
> See below...
>
> Thanks,
> Jesse Thompson
> UW-Madison
>
> "
> I don't see on the list of issues the most fundamental problem of= =C2=A0DMARC, namely that it conflicts with RFC 5322 on the use of the From = and Sender header fields [1] and possibly with RFC 6326 as to the significa= nce of DKIM fail [2].=C2=A0 The former is the more serious problem. Making= =C2=A0DMARC=C2=A0alignment part of a standard for Internet messages require= s a revision of RFC 5322. I'd love to see this resolved.


As one of the folk who created the Sender: construct in RFC 733, I'll <= br> suggest that the concern raised here has merit, though dealing with the fact isn't straightforward.=C2=A0 It's an issue I've been wrest= ling with for
a couple of years.

In reality, all of the current email anti-abuse authentication methods
concern the email operator, not the author.

The problem is that, in the message, the only identifier that is
reliably present is the rfc5322.From field email address.

The underlying design choice in RFC733 -- 45 years ago -- was in making Sender: optional when it's content is the same as the From: field.=C2= =A0 It
never occurred to us that one of them might need changing along the
handling path.=C2=A0 The lesson to future designers is to strongly resist <= br> conflating otherwise-independent semantics for "efficiency".

DMARC enforcement requires that the DKIM/SPF domain be the same as the
author From:.=C2=A0 That is, the folk doing email operations have to be abl= e
to sign the DMARC aligned domain.

Hence the From: field is now really the Sender: field.=C2=A0 The From: fiel= d
fixup hacks that are needed by intermediaries, to avoid DMARC-based
rejections, makes this fact painfully clear, even as they serve to
undermine recipient use of the From field for author-related message
management.

Given the depth and momentum of DMARC's effects, I don't think it&#= 39;s
realistic to try to fix this via changes to the From: field.

The only suggestion I've been able to formulate is:=C2=A0 create a new = field,
such as Author:.

(Give it a simple, clean, appropriate name, rather than something like
Original-From.)

And if the mail client = displays the Author, then we're kind of back to square one
wi= th displaying unvalidated data to the user.

Which is to say, = DMARC is just policy, but what makes it different from the previous policy = attempts
is that it requires the visible author/operator to be au= thenticated.=C2=A0

There's no reason that DMARC couldn't hav= e included the sender or tried to have some kind of
PRA like spf = v2... but that's not the goal.

At some point, you're going u= p against the existing mail client design and of course
how users= act, and of course all of that is messy.=C2=A0 The "clean" stric= tness and mechanical nature
of DMARC is ultimately up against the= fuzzy ux design and fuzzier humans.

On top of that, the author doma= ins basically want to control who can send on their behalf, which is
<= div>a reasonable goal as well.

Brandon
= --000000000000aa168a05a71d02a3-- From nobody Tue Jun 2 10:35:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59523A0CE5 for ; Tue, 2 Jun 2020 10:35:14 -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, FREEMAIL_FROM=0.001, 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=gmail.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 EOfe0zo3ZLsi for ; Tue, 2 Jun 2020 10:35:13 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 5FDAC3A0CD9 for ; Tue, 2 Jun 2020 10:35:13 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id g10so3727434wmh.4 for ; Tue, 02 Jun 2020 10:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MqzBDHWP8aRQEnSW6FJxPYmJCxZOyPa7lgY6F8gpQzs=; b=qgBjzrUFbZKf0A4i4l1atwHPcDMActaC18jxte33ZaTvbOsJ1tXTtt0qTyDa798g5U pzEpbMJEikwDekaLwkHHutSOOnJoZvOcrWx8sVPkzTRmXPE17FI3h7XAQl3Ag5nGsiA6 DTjH2KleZCwkl0fGmU3vCt8hXMXgqZVpB23uKEVgN0bOw1XvKD/KIQijayUSvVu4Mmnf 4RUmQFS0XlNvpBOO3RYQzlcCL61e+p/dLQZTNLr+kxVBCL4AIiyxlnBwEHc+YeYBk0ej 3nLKjfyP3Kb/iOGqJl3gPknxjfJnFU2xVth4XneVZiK37soUv+CAOUiqAV+xZ4VFj29f hZsA== 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=MqzBDHWP8aRQEnSW6FJxPYmJCxZOyPa7lgY6F8gpQzs=; b=mDmGyFysvZX6DThZe3Nnh0Hi2Lmuz3T/dYHRfY3IqhcpTX5+wnJwoaHThL4q1wWmEE i9Feb97HTsUwQDz/kxQE0/j5wKBrCE2c/UJXaczItitSzhEsqsbFJ+797P/pyl+DnwLj bvd7OcL6l45PiCdhBikq7r+b+mc2OxrVaAAvkR2rLUNIYrXo+Q8z5ktcpF1nruzaAo1x b40W6afhtD9kSVSKLuYIJ0BP/cF7/rcgZeFFWQOZQVqLAk1KTlZaeamEn6QRaI+DKnc0 bbAvLduGLpuv3iOCc7Bcq4GSWgoTTkjxiURZuu5O3D5Paym5TvqjBj1hKyf8AF56T3ud 7EDQ== X-Gm-Message-State: AOAM530wbJ+3eyMcwigfmBOVZDoH9WOEj+BIpsF+S1o9uBx3QgEQCU+3 H74L4poJ6yDul+E3ueSJHzSe1PhEDAG1B167bumPqXOu X-Google-Smtp-Source: ABdhPJxLQctSj9w2GejXytzItIR4OJ1aU3U7ogVAOWYh2Dq4k4ggISC00rXAbowaOW8hXzPkuQivsETqfNCsFJbOQ6k= X-Received: by 2002:a1c:46c3:: with SMTP id t186mr4843440wma.36.1591119311907; Tue, 02 Jun 2020 10:35:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Tue, 2 Jun 2020 13:35:01 -0400 Message-ID: To: Jesse Thompson Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000061b92905a71d5517" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 17:35:15 -0000 --00000000000061b92905a71d5517 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 12:44 PM Jesse Thompson wrote: > I'm relaying these DMARC questions/concerns on behalf of an email admin at > another university. I quickly searched this list's archives for the Sender > header vs DMARC alignment issue and don't see much aside from a > conversation in May 2015. Is it worth further discussion and/or an issue > in Trac? I think I know the answer to the second concern, but I'll defer > to people more adept at explaining the nuance. > > See below... > > Thanks, > Jesse Thompson > UW-Madison > > " > I don't see on the list of issues the most fundamental problem of DMARC, > namely that it conflicts with RFC 5322 on the use of the From and Sender > header fields [1] and possibly with RFC 6326 as to the significance of DKIM > fail [2]. The former is the more serious problem. Making DMARC alignment > part of a standard for Internet messages requires a revision of RFC 5322. > I'd love to see this resolved. > > [1] > The "From:" field specifies the author(s) of the message, > that is, the mailbox(es) of the person(s) or system(s) responsible > for the writing of the message. The "Sender:" field specifies the > mailbox of the agent responsible for the actual transmission of the > message. > > [2] > signature verification failure does not force rejection of the message; > " > We went through this with SenderID and it's use of Sender in PRA. Back in the day I upset the folks at Microsoft responsible for evangelizing SenderID by sending emails to them using their name an email in the From field and myself in the Sender field. My emails would consistently get a neutral rating under SenderID because of how PRA worked. As part of the original DMARC team, the goal was to make clear whether the email was authorized by the domain being used, hence the reliance on SPF and DKIM. These are clearly under the domain owner/administrator's control to the extent they choose to exercise that control. There was much discussion in the community at the time to use thei= field to enable more granular signing. it never gained traction. Because the intent was to protect end users from fake emails purporting to be from (primarily) commercial domains such as financial institutions, greeting card companies, etc., the Sender field was not a significant issue. Also, when the Sender is in the same domain as the From, there is no DMARC issue. Michael Hammer If you really want to enable someone to send on your behalf then a) give them direct access to send from your account; b) give them your private DKIM signing key (which allows them to sign for any account in that domain or c) delegate a subdomain to them so they can generate their own SPF or DKIM records. --00000000000061b92905a71d5517 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 2, 2020 at 12:44 PM Jesse= Thompson <jesse.thompson=3D40wisc.edu@dmarc.ietf.org> wrote:
I'm= relaying these DMARC questions/concerns on behalf of an email admin at ano= ther university.=C2=A0 I quickly searched this list's archives for the = Sender header vs DMARC alignment issue and don't see much aside from a = conversation in May 2015.=C2=A0 Is it worth further discussion and/or an is= sue in Trac?=C2=A0 I think I know the answer to the second concern, but I&#= 39;ll defer to people more adept at explaining the nuance.

See below...

Thanks,
Jesse Thompson
UW-Madison

"
I don't see on the list of issues the most fundamental problem of=C2=A0= DMARC, namely that it conflicts with RFC 5322 on the use of the From and Se= nder header fields [1] and possibly with RFC 6326 as to the significance of= DKIM fail [2].=C2=A0 The former is the more serious problem. Making=C2=A0D= MARC=C2=A0alignment part of a standard for Internet messages requires a rev= ision of RFC 5322. I'd love to see this resolved.

[1]
The "From:" field specifies the author(s) of the message,
=C2=A0 =C2=A0that is, the mailbox(es) of the person(s) or system(s) respons= ible
=C2=A0 =C2=A0for the writing of the message.=C2=A0 The "Sender:" = field specifies the
=C2=A0 =C2=A0mailbox of the agent responsible for the actual transmission o= f the
=C2=A0 =C2=A0message.

[2]
signature verification failure does not force rejection of the message;
"

We went through this with Sender= ID and it's use of Sender in PRA. Back in the day I upset the folks at = Microsoft responsible for evangelizing SenderID by sending emails to them u= sing their name an email in the From field and myself in the Sender field. = My emails would consistently get a neutral rating under SenderID because of= how PRA worked.

As part of the original DMARC team, the goal was to= make clear whether the email was authorized by the domain being used, henc= e the reliance on SPF and DKIM. These are clearly under the domain owner/ad= ministrator's control to the extent they choose to exercise that contro= l. There was much discussion in the community at the time to use thei=3D fi= eld to enable more granular signing. it never gained traction. Because the = intent was to protect end users from fake emails purporting to be from (pri= marily) commercial domains such as financial institutions, greeting card co= mpanies, etc., the Sender field was not a significant issue. Also, when the= Sender is in the same domain as the From, there is no DMARC issue.

Michael Hammer=C2=A0

If you really want to enable = someone to send on your behalf then a) give them direct access to send from= your account; b) give them your private DKIM signing key (which allows the= m to sign for any account in that domain or c) delegate a subdomain to them= so they can generate their own SPF or DKIM records.
--00000000000061b92905a71d5517-- From nobody Tue Jun 2 11:01:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818123A0E71 for ; Tue, 2 Jun 2020 11:01:11 -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, FREEMAIL_FROM=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=gmail.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 Ak36eW4gLYlK for ; Tue, 2 Jun 2020 11:01:09 -0700 (PDT) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 B7CAA3A0E60 for ; Tue, 2 Jun 2020 11:01:09 -0700 (PDT) Received: by mail-oo1-xc33.google.com with SMTP id h7so2335558ooc.9 for ; Tue, 02 Jun 2020 11:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ovwyno++exOVpcIW96uCElhtl5zcQMNgYtmHf8r00CQ=; b=OnTEemph2ljPDcWO7E/OT4p/qkVRfT6REmiiKxursb7UTS4Y9trd4IxVY8URPat+0B Rzvd/UKLeavwg6+5+L5Wco0uNoRq6m5Nv2F0YAlDjwtiJ8AgTlVurYSnAh+9V6edr7HM Fj5Xy64t61rQYbM53xjN4N1dByAkGhY2N2/SnE+jPJgBkiEIMJcQ30fYxauYAqHOX9qs djrfTJy2HS1N9QwjORKkAI1A/lfmg+3GjgTrb5QLm8JMNnxxa36RfH5ZxRGr4JiwvcEC oE1YJcgaqW0g/I5PR4WAQmUoW+TYyIvOIu/oVyx6NrU3gajwUeCOHCJxjhmfYC15lVgS R80A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ovwyno++exOVpcIW96uCElhtl5zcQMNgYtmHf8r00CQ=; b=NOIoe2E6/cAs9EryiAhoE62RKR8Fg2CrV57vpubfo9QjZ9HvN6BBAdcolnOzI0Sng8 jJOJPRB9ST8cBX7szUdN2X7m9GMg8PIB6JAa+ND8GiFV+O1FqRHfVTQhwIBnOlLMAn4a L+tHJkDQth4sm+6ve4sbjq1DMg7cbH4K5qi2Nn2L1jp8qdpTufDXo2zhCYD2eCC+gM2r +LUNcI0rQ8n6F12hVFedNkR0/RJEnW0zC1lAahFv7z+SGdE/SSPbFTjWJKrKyquiMw6T 0lQgjHlOl7oUWFBQHiE/sTOYr59IkXivju94RD9/zTZZGE3EET2nWO3KfoKevQ/FuftX rf1w== X-Gm-Message-State: AOAM533kzKU4imhU+sbYOKs+K7/RKCEkPtMaJcBsGbqQBxT/9Qa05YQ5 iqlZFjZGpCIUF1Zzf0G0SyBFiOJ6 X-Google-Smtp-Source: ABdhPJx5ZyYZPo/bzDLacIb6gus3PTgxz0r+8zjCMOnbudxHflXMQPI0r6zelkpDFnxGKThDnDO/3g== X-Received: by 2002:a4a:b91a:: with SMTP id x26mr21691113ooo.5.1591120867554; Tue, 02 Jun 2020 11:01:07 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id n9sm777862otl.76.2020.06.02.11.01.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 11:01:05 -0700 (PDT) To: Brandon Long Cc: "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> From: Dave Crocker Message-ID: <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> Date: Tue, 2 Jun 2020 11:01:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:01:18 -0000 On 6/2/2020 10:11 AM, Brandon Long wrote: > And if the mail client displays the Author, then we're kind of back to > square one > with displaying unvalidated data to the user. No we aren't. Your comment implies that what is displayed to the user is important in anti-abuse efforts, but there is no data to support that view, and some significant data to support the view that that's wrong.  (cf, the extensive literature review that was done during early BIMI discussions.) What matters is what is done by your filtering engine -- and what is in the message content -- not what is displayed to the user in the From field.  I understand that DMARC has been useful, but I believe this is confusing correlation with causation.  The cause is down in the filtering engine. > There's no reason that DMARC couldn't have included the sender or > tried to have some kind of > PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. > At some point, you're going up against the existing mail client design > and of course > how users act, and of course all of that is messy.  The "clean" > strictness and mechanical nature > of DMARC is ultimately up against the fuzzy ux design and fuzzier humans. DMARC is a triumph of infrastructure operator demands over end-user experience.  it's created a markedly Procrustean email identification environment. The standards and the practice, for 45 years, have permitted certain freedoms in the From: field and DMARC eliminated them. It's easy to be cavalier about this, since some operators run highly controlled environments and have no incentives for paying attention to those who have used those freedoms legitimately, for 45 years. > On top of that, the author domains basically want to control who can > send on their behalf, which is > a reasonable goal as well. That's a rather small subset of domain owners.  While DMARC was original developed for that select community, its vastly broader use results in over-applying that restriction. AGAIN, I'm not suggesting changing DMARC or the current reality for the From: field. RATHER, I'm suggesting making it possible for recipients to regain usefulness of the author information that the From: field was intended to provide but no longer does. FOR THOSE FEW DOMAINS that really want to get strict about who gets to claim to be an author associated with a domain, then do something like add a DMARC option that prohibits use of the Author: field.  (Note that just having DKIM and ARC pre-sign a non-existent Author field accomplishes this, too...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 11:13:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E773A0E79 for ; Tue, 2 Jun 2020 11:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GxWX_G3g3Eg0 for ; Tue, 2 Jun 2020 11:13:04 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D63C3A0E80 for ; Tue, 2 Jun 2020 11:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 89DF2AF367B1; Tue, 2 Jun 2020 13:13:00 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6FprnmOH0F6; Tue, 2 Jun 2020 13:12:58 -0500 (CDT) Received: from [172.16.1.29] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id CD961AF367A0; Tue, 2 Jun 2020 13:12:58 -0500 (CDT) From: "Pete Resnick" To: "Dave Crocker" Cc: "Brandon Long" , dmarc@ietf.org Date: Tue, 02 Jun 2020 13:12:29 -0500 X-Mailer: MailMate (1.13.1r5683) Message-ID: <46CF53B5-A7BD-4BF6-B8FA-AD83F7950B5D@episteme.net> In-Reply-To: <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:13:12 -0000 On 2 Jun 2020, at 13:01, Dave Crocker wrote: >> There's no reason that DMARC couldn't have included the sender or >> tried to have some kind of >> PRA like spf v2... but that's not the goal. > > > But the Sender: field is not reliably present and, of course, DMARC > needs an identifier that is reliably present. Dave, could you explain that? Coding-wise, there's surely no reason that an implementation can't say, "if 5322.sender is present then sender = 5322.sender else sender = 5322.from". So you could say that the identifier of sender is reliably present, since it's taken from 5322.from if 5322.sender isn't present. But maybe I'm missing something. Please explain. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Jun 2 11:29:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85D3A0E99 for ; Tue, 2 Jun 2020 11:29:05 -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, FREEMAIL_FROM=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=gmail.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 MY5b4Iq5TS6z for ; Tue, 2 Jun 2020 11:29:04 -0700 (PDT) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 504903A0EA0 for ; Tue, 2 Jun 2020 11:29:04 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id j189so5420544oih.10 for ; Tue, 02 Jun 2020 11:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=u3fFrLmVNNCjHcznl23kdkgEorBEMSJB8jL++bMp0pI=; b=VBS3Wd0loJeGhlxZiGFe3t4201He1P64Xmj+jMmXqQWBPbKa4xiTPiuERMcY0q98Rh NeSCfbtudex2HgzI7tCbPuz1Zuo2WiLXj5A0OC/uUhxja3KA1a4KdiQVlWSNtkbFgTHP N6L5H6Wygs795DTvCj4D6VW4tynDN/fkJjmSLV/429U1zDaPvgEegjhgpKFElA3IiyGV WZlEamkp+7FbN6EE5LqO17Fj2RRmx/gHaPOUjaKeaEytSfx8EhA6PcwedOPo/S7Aro9Z xUZwzciKfyprgtHuKXmF9td5QlId1mUOrl15eWUHfVaaWzFCKmVVVQe5fYo67yGgfNsn 5kIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=u3fFrLmVNNCjHcznl23kdkgEorBEMSJB8jL++bMp0pI=; b=MiZ6NijRXY6CBf6JorOFulW2xFgfsodJbU/bUy4iO7JqvdA/KkZwJzpfRDjBEn0Ydo 19RgVz5T7UrKnei071qrAJLB/8R25Bt8wk7lWZNV/NdO/RXv2/NXkKQNVlYUw9sfpeZ6 MFAlvZV7zPVcwcLGgTngqMYQGH8pR+El4lfeQ1vbqzBIHVtm5BhQoB4NXncCwVcEVF4U eZwa0DshxnWbW7dLWpSDJStjEjAxkVHGWePa4jD2qJ04mj/TpmdUsBG+frcrY8Pg+I1z ExD6wZVtNvC9nQccJhDY1e+QwoQGOG5k1a9tW0KRKvv8OaMuut+Q9ztMpte6Q5byLdnP fs3g== X-Gm-Message-State: AOAM5332ca/X450HFsxnynL4CAVo4fIwjECfMFDQmYN/vKcVFsezUHO6 GxPMdR58lJjFfud0AXRdOSqqYG3i X-Google-Smtp-Source: ABdhPJwO/muqnHPW01Tetq3DIL5asFWzSZrKLtom5y4Mul1HQlpWUsXvB0oRjF0Ozfa1uD0Wacs4pA== X-Received: by 2002:aca:f255:: with SMTP id q82mr1957167oih.153.1591122543404; Tue, 02 Jun 2020 11:29:03 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id x5sm870611oig.52.2020.06.02.11.29.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 11:29:02 -0700 (PDT) To: Pete Resnick Cc: Brandon Long , dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <46CF53B5-A7BD-4BF6-B8FA-AD83F7950B5D@episteme.net> From: Dave Crocker Message-ID: <124145c8-c29c-142d-b4fe-2880a83dc417@gmail.com> Date: Tue, 2 Jun 2020 11:29:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <46CF53B5-A7BD-4BF6-B8FA-AD83F7950B5D@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:29:06 -0000 On 6/2/2020 11:12 AM, Pete Resnick wrote: > On 2 Jun 2020, at 13:01, Dave Crocker wrote: > >>> There's no reason that DMARC couldn't have included the sender or >>> tried to have some kind of >>> PRA like spf v2... but that's not the goal. >> >> >> But the Sender: field is not reliably present and, of course, DMARC >> needs an identifier that is reliably present. > > Dave, could you explain that? Coding-wise, there's surely no reason > that an implementation can't say, "if 5322.sender is present then > sender = 5322.sender else sender = 5322.from". So you could say that > the identifier of sender is reliably present, since it's taken from > 5322.from if 5322.sender isn't present. But maybe I'm missing > something. Please explain. > Not sure what you are asking.  What I mean is that it isn't always present. If Sender: contains the same address as From:, then Sender does not have to be present, and often/usually isn't. So when someone comes along and changes From: -- such as to hack around the DMARC problem for intermediaries -- the semantic of the Sender information is lost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 12:32:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41C3A0F73 for ; Tue, 2 Jun 2020 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SFEboV5Ps_ol for ; Tue, 2 Jun 2020 12:32:12 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F2F3A0F72 for ; Tue, 2 Jun 2020 12:32:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 057C9AF38861; Tue, 2 Jun 2020 14:32:09 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KErlOaZ08GEF; Tue, 2 Jun 2020 14:32:06 -0500 (CDT) Received: from [172.16.1.29] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 628C2AF38850; Tue, 2 Jun 2020 14:32:06 -0500 (CDT) From: "Pete Resnick" To: "Dave Crocker" Cc: "Brandon Long" , dmarc@ietf.org Date: Tue, 02 Jun 2020 14:32:05 -0500 X-Mailer: MailMate (1.13.1r5683) Message-ID: In-Reply-To: <124145c8-c29c-142d-b4fe-2880a83dc417@gmail.com> References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <46CF53B5-A7BD-4BF6-B8FA-AD83F7950B5D@episteme.net> <124145c8-c29c-142d-b4fe-2880a83dc417@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 19:32:14 -0000 On 2 Jun 2020, at 13:29, Dave Crocker wrote: > On 6/2/2020 11:12 AM, Pete Resnick wrote: >> On 2 Jun 2020, at 13:01, Dave Crocker wrote: >> >>>> There's no reason that DMARC couldn't have included the sender or >>>> tried to have some kind of >>>> PRA like spf v2... but that's not the goal. >>> >>> >>> But the Sender: field is not reliably present and, of course, DMARC >>> needs an identifier that is reliably present. >> >> Dave, could you explain that? Coding-wise, there's surely no reason >> that an implementation can't say, "if 5322.sender is present then >> sender = 5322.sender else sender = 5322.from". So you could say that >> the identifier of sender is reliably present, since it's taken from >> 5322.from if 5322.sender isn't present. But maybe I'm missing >> something. Please explain. >> > > Not sure what you are asking.  What I mean is that it isn't always > present. > > If Sender: contains the same address as From:, then Sender does not > have to be present, and often/usually isn't. Well, that's the field, not its value. > So when someone comes along and changes From: -- such as to hack > around the DMARC problem for intermediaries -- the semantic of the > Sender information is lost. If you do change the From, you should always add a Sender. (Or is your point that implementer's don't, and that's the problem?) What I'm missing is why the lack of an actual Sender: header field is problematic. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Jun 2 12:51:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080613A0F90 for ; Tue, 2 Jun 2020 12:51:06 -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, FREEMAIL_FROM=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=gmail.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 7UVqBhPJZ0qv for ; Tue, 2 Jun 2020 12:51:04 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 D1E013A0F8B for ; Tue, 2 Jun 2020 12:51:04 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id u23so11891984otq.10 for ; Tue, 02 Jun 2020 12:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=d9a0QfrhMZwc3098cEw+o5EFX/jOZ6n9P+Kkn8ZA6Fs=; b=vG+zI5/AaK5XGHC/E44B/hJt6B/2LwJB6QP+5FtREYqc6/Uo5ojFDe/Ab0def//ZY3 vAS1cBPAW/eJ8dfckKKeFahR7OC36s/UmdtzE1YqQH42x7sillTPpp2nZbFNtNM0Pvht l7btZEuc7GFMv+wfEOkLpRUveSy7m24WcHqc6rS69JWthssrda9wRNYelUA2mrfXwW4O aaSRVf3rBwFHSSwF3oX7BvzOjbWFkocaXFZR8943RykVeAzQ/6Fvmby79E8G70judizw AhrLltTo9lq8Runib4fYhIia6DDzk50EPhrbPwoaREecQOba68T4HUwHRP1YnxRE2XQP FLwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=d9a0QfrhMZwc3098cEw+o5EFX/jOZ6n9P+Kkn8ZA6Fs=; b=X6m+moFIwj2WNBQWRZ9YO256Aa8cXOww3IVTAYhH5EemnAprCtvfSRWV2mXl7YEioQ qtgqo4akKlhCzZ3LACciurigcrrDUrgCZr2kXP4SoYrtTTEof5kQduUiGj7NwvQR9JLm H7Wj9g/5CwLYndIUW/D+F+inldYSBA1OToosSw0tz6L1dGt/XjNYDhuhNTzC635D4b96 lKMZk786P5x95cQGRmGHyJYgIOZff/y0IGLohdall2KZP5GpnkDNS2XdhHqwvEhCwFja 6WI6Z4wf0RgDge9EhsfqYTPqKqK22KwlwAKZBBbEYarVXSZeMSc9meQhoal9bLV28wx+ 8w1w== X-Gm-Message-State: AOAM5329edYZrUe4IwSg9oLUcuY4ewh8TzSCDd4MZino44KXX1preqMv F/C3VWTmQODvcc9iASMw92VdgGCX X-Google-Smtp-Source: ABdhPJysDAgawnmfWU2viZLDzEZxVSIj6rkseNx2mP9TyW/q93Wb/tG7cfaxhM70w13+aRmni3/RSg== X-Received: by 2002:a9d:2de6:: with SMTP id g93mr723422otb.28.1591127463935; Tue, 02 Jun 2020 12:51:03 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id c1sm856856otn.81.2020.06.02.12.51.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 12:51:03 -0700 (PDT) To: Pete Resnick Cc: Brandon Long , dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <46CF53B5-A7BD-4BF6-B8FA-AD83F7950B5D@episteme.net> <124145c8-c29c-142d-b4fe-2880a83dc417@gmail.com> From: Dave Crocker Message-ID: Date: Tue, 2 Jun 2020 12:51:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 19:51:06 -0000 On 6/2/2020 12:32 PM, Pete Resnick wrote: > On 2 Jun 2020, at 13:29, Dave Crocker wrote: > >> On 6/2/2020 11:12 AM, Pete Resnick wrote: >>> On 2 Jun 2020, at 13:01, Dave Crocker wrote: >>> >>>>> There's no reason that DMARC couldn't have included the sender or >>>>> tried to have some kind of >>>>> PRA like spf v2... but that's not the goal. >>>> >>>> >>>> But the Sender: field is not reliably present and, of course, DMARC >>>> needs an identifier that is reliably present. >>> >>> Dave, could you explain that? Coding-wise, there's surely no reason >>> that an implementation can't say, "if 5322.sender is present then >>> sender = 5322.sender else sender = 5322.from". So you could say that >>> the identifier of sender is reliably present, since it's taken from >>> 5322.from if 5322.sender isn't present. But maybe I'm missing >>> something. Please explain. >>> >> >> Not sure what you are asking.  What I mean is that it isn't always >> present. >> >> If Sender: contains the same address as From:, then Sender does not >> have to be present, and often/usually isn't. > > Well, that's the field, not its value. > >> So when someone comes along and changes From: -- such as to hack >> around the DMARC problem for intermediaries -- the semantic of the >> Sender information is lost. > > If you do change the From, you should always add a Sender. (Or is your > point that implementer's don't, and that's the problem?) Except that there's nothing that specifies that and I believe it isn't common practice.  Worse, creating that field in mid-stream does not fix the problem that now the author information is lost. The actual requirement is to have the Sender field always be present at the time of original posting, and have DMARC work from the Sender field.  But since none of that is going to happen, I'm looking for a path to providing clean original-author information that is practical. > > What I'm missing is why the lack of an actual Sender: header field is > problematic. Because DMARC should have focused on the Sender field, not the From field, since it is really about the email operator, not the author. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 13:36:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391813A0FCC for ; Tue, 2 Jun 2020 13:36:23 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BRqjLJ71Im5j for ; Tue, 2 Jun 2020 13:36:22 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 E1A673A0FC6 for ; Tue, 2 Jun 2020 13:36:21 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id j13so78302vsn.3 for ; Tue, 02 Jun 2020 13:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dYBxXK4aTf/GMfwdX71CeJPS5M4nzHHGMppXyLnWk90=; b=azzrnGIHwNillh87UbeCNmuELUahYQCO/AgV3zQvsr1vj109sa1d5IEWoBF2ecplTq Nlo2eo83r+0vQpv39BfR7F24DwcsmnjnALwwn1XpuooBIU3IxAtoOD5UUUMGCcIoMO0O dlovLowPIoXdjnBUhw7xi7xFNvJPrMcfEf3KeqQ5Ylu3QQ6Z0rXpV4wHf5AXlwUcNNBa uI2vGGqsVTX7yxSHoWU3kurXiRl5apPLha+n+0kugMFje7Mh9SG41Wjzo9P/itzwnDu7 w3v3bfvEhKrhWfccespRSo4gKFQnW1+QihA3nazUDvmzLimTJrpHlhNwHhQ8bMYc80Mk RcPw== 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=dYBxXK4aTf/GMfwdX71CeJPS5M4nzHHGMppXyLnWk90=; b=RAhLis9aovftMzeptt2kt9p/P7QB5UReWGAAof5EebtMcqhTP4JMhg9saAX+Ks+s9o 6PznoSSWPUUzC+kTn8bY4LKjiJAK9riCafaJVDomr8Pc+GdUI7F5mu3MeEqjj5QfdFDy BdeQqil8+J/CN4pKc9KKrBZXCOhAFVlbk5cPCfhuHcH/lPBsumeJP5ypyzkRdz6cFYVJ tvqBkWymyp/eJUlT5fHLedtbKgufjAluiXR9ojcPNG/mGy9VQ/GieQldug5RfsebkJke p8oeKHO1D3Px18sBZe8x/io2qsZ+M1QLVV9hrjpsgMVvVmpwFhgeO0XZM6qBvHcf13ua s4gg== X-Gm-Message-State: AOAM533uZuh8M0ZMD0kkA4lRN7UYdcWLcOMmq9aXQOx09d2IHC2INAav 9uq9EfHuob3RKAGcpTbtR7djC2IPuaKCcMSwQMc= X-Google-Smtp-Source: ABdhPJzLwJwqFRW+nKGbIn2GZ/G8rgeQUvk2c9YT1Gtbs5GnqUlWd36Lent6dfu5z1VBd/ft4iP0H4epmMqhL2/vjBw= X-Received: by 2002:a67:cc7:: with SMTP id 190mr493548vsm.7.1591130180778; Tue, 02 Jun 2020 13:36:20 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> In-Reply-To: <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> From: "Murray S. Kucherawy" Date: Tue, 2 Jun 2020 13:36:09 -0700 Message-ID: To: Dave Crocker Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000377f4b05a71fdd7a" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:36:23 -0000 --000000000000377f4b05a71fdd7a Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker wrote: > Your comment implies that what is displayed to the user is important in > anti-abuse efforts, but there is no data to support that view, and some > significant data to support the view that that's wrong. (cf, the > extensive literature review that was done during early BIMI discussions.) > That's a curious assertion given all of the energy that's gone into complaining about but never really resolving the "display name" problem over the years. I thought that was a key part of the vector of many successful phishing attacks. I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't you do something about that?" on which to base that. Hasn't M3AAWG at least had something other than anecdata that this is a true source of pain? DMARC is a triumph of infrastructure operator demands over end-user > experience. it's created a markedly Procrustean email identification > environment. > > The standards and the practice, for 45 years, have permitted certain > freedoms in the From: field and DMARC eliminated them. > > It's easy to be cavalier about this, since some operators run highly > controlled environments and have no incentives for paying attention to > those who have used those freedoms legitimately, for 45 years. > No reply here, just felt like citing this again. -MSK --000000000000377f4b05a71fdd7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 2, 2020 at 11:01 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
Your comment implies that what is displayed to the user is = important in
anti-abuse efforts, but there is no data to support that view, and some significant data to support the view that that's wrong.=C2=A0 (cf, the =
extensive literature review that was done during early BIMI discussions.)

That's a curious assertion given all= of the energy that's gone into complaining about but never really reso= lving the "display name" problem over the years.=C2=A0 I thought = that was a key part of the vector of many successful phishing attacks.
<= /div>

I suppose it's possible that operators came up= with this problem and decided it needs solving, with no user complaints li= ke "I was fooled by this fake From, can't you do something about t= hat?" on which to base that.

Hasn't M3AAW= G at least had something other than anecdata that this is a true source of = pain?

DMARC is a triumph of infrastructure operator demands over end-user
experience.=C2=A0 it's created a markedly Procrustean email identificat= ion
environment.

The standards and the practice, for 45 years, have permitted certain
freedoms in the From: field and DMARC eliminated them.

It's easy to be cavalier about this, since some operators run highly controlled environments and have no incentives for paying attention to
those who have used those freedoms legitimately, for 45 years.

No reply here, just felt like citing this again.

-MSK

--000000000000377f4b05a71fdd7a-- From nobody Tue Jun 2 13:46:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9653A0C3E for ; Tue, 2 Jun 2020 13:46:24 -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, FREEMAIL_FROM=0.001, 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=gmail.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 UgLRzc0QAZaY for ; Tue, 2 Jun 2020 13:46:22 -0700 (PDT) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 A46053A0FD7 for ; Tue, 2 Jun 2020 13:46:22 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id o7so21711oti.9 for ; Tue, 02 Jun 2020 13:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Mv9rO886uGzQkhCl3dnaqu2HO+5LXXQ85d/BFwVs3VU=; b=eblswct+ZFd5ocfOUnXMcA02MYC4mkLHQkWMXYWzOXgA9iQKcyWa75u7mryIY/fdfu JKzls0qyi+Ie9l3ebQXaWGBh4hIPLgdR5OkVcBLoTpEd/x8q8+gsco7aOLvP5nXTtfZM v8LHBDgBlSU6m4y9fmAAUwJ6x+VUN6sDCfWJyClyzLu010bwOr0xnrhzwmmNl99mqa5L i5FFmK3Hhjr9uGEBNQnIfWCMDLqfNDVlsLoS/eEpI8gPlPNNuJAVYn/GqZNBd4lrw64D ZFmqSCtwXtn6z3bPtFbWRhF6GyluA0RvMWBRKxKJhZc6IL343XuG9FNof8iOgFBiDxS9 FAbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Mv9rO886uGzQkhCl3dnaqu2HO+5LXXQ85d/BFwVs3VU=; b=ChIbKTWzljHJGA30mpXCSFKiIyEYopFxxfP3/PXeasMj1B4X78X4NYO0b6hSDoq8qP hUz4XWXITewWioDQPaW9UvcvGdQDcwxi9OFZOQJccpc0V3B0TfCisW3BX2sfgcd3hBLH dsBnoR1k4nc35GCZB6svX7t3Rm4jEBMhqBS0Py5XEd27fdLLR5tBb+X4sX0+jkwj3CQp 0glSPV9wh87SRO366QJMuHlHK7Q2vw6fMYZU9S0M12Ltx7f8QOb7F0zarIHAZbvtTfJw f1rOKHLuzFCfjoPAjXCvBB5kcilpdYHb/xhXQ5wjXF+4h/be/i5ej8A1bG8X4J1zmzvY tcOg== X-Gm-Message-State: AOAM531mpU3H2w5dMYr5lYNfXeu63BtgFukhsf2PD0UjDRpNILbdq/7+ MY9faYrhtxGkYsPHzaMrIKBPfYv7 X-Google-Smtp-Source: ABdhPJxOjUm2MitDV+yJ1ed5O1kc9/b9XhMRVntU0uyIgwon6bUvR3Ftv8edOHRHTDc03bU0EOuwuA== X-Received: by 2002:a9d:23a6:: with SMTP id t35mr776113otb.217.1591130780538; Tue, 02 Jun 2020 13:46:20 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id p206sm46542oib.16.2020.06.02.13.46.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 13:46:19 -0700 (PDT) To: "Murray S. Kucherawy" Cc: Brandon Long , "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> From: Dave Crocker Message-ID: Date: Tue, 2 Jun 2020 13:46:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7C7C4E520FC6FEC1AE1FFF5" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:46:24 -0000 This is a multi-part message in MIME format. --------------E7C7C4E520FC6FEC1AE1FFF5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote: > On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker > wrote: > > Your comment implies that what is displayed to the user is > important in > anti-abuse efforts, but there is no data to support that view, and > some > significant data to support the view that that's wrong. (cf, the > extensive literature review that was done during early BIMI > discussions.) > > > That's a curious assertion given all of the energy that's gone into > complaining about but never really resolving the "display name" > problem over the years.  I thought that was a key part of the vector > of many successful phishing attacks. In the world of Internet protocol standards, there is a common problem in discussing anything involving users, failing to distinguish between the mathematics of abuse from the actual effects.  That is, if I lie about the author, that's abuse in an absolute sense.  But that can be quite different from whether that lie has any effect on the recipient. So, yes, lots of people have been upset constantly over the years about all sorts of abusive behaviors.  However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does. And since my notes on this thread seem to be having a difficult time being understood, I'll stress that my reference is specifically to end-user behavior.  There other abuse factors, separate from that, which DMARC apparently correlates usefully with, which is why it apparently really is useful to the filtering engine.  But not the recipient user. > I suppose it's possible that operators came up with this problem and > decided it needs solving, with no user complaints like "I was fooled > by this fake From, can't you do something about that?" on which to > base that. Exactly. > Hasn't M3AAWG at least had something other than anecdata that this is > a true source of pain? No. As I mentioned in the previous note, there was a literature survey done at the start of the BIMI work, and it produced no evidence to support claims of improved end user behavior. The canonical example of this issue was the EV web domain name exercise. > > DMARC is a triumph of infrastructure operator demands over end-user > experience.  it's created a markedly Procrustean email identification > environment. > > The standards and the practice, for 45 years, have permitted certain > freedoms in the From: field and DMARC eliminated them. > > It's easy to be cavalier about this, since some operators run highly > controlled environments and have no incentives for paying > attention to > those who have used those freedoms legitimately, for 45 years. > > > No reply here, just felt like citing this again. ditto. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------E7C7C4E520FC6FEC1AE1FFF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote:
On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker <dcrocker@gmail.com> wrote:
Your comment implies that what is displayed to the user is important in
anti-abuse efforts, but there is no data to support that view, and some
significant data to support the view that that's wrong.  (cf, the
extensive literature review that was done during early BIMI discussions.)

That's a curious assertion given all of the energy that's gone into complaining about but never really resolving the "display name" problem over the years.  I thought that was a key part of the vector of many successful phishing attacks.

In the world of Internet protocol standards, there is a common problem in discussing anything involving users, failing to distinguish between the mathematics of abuse from the actual effects.  That is, if I lie about the author, that's abuse in an absolute sense.  But that can be quite different from whether that lie has any effect on the recipient.

So, yes, lots of people have been upset constantly over the years about all sorts of abusive behaviors.  However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.

And since my notes on this thread seem to be having a difficult time being understood, I'll stress that my reference is specifically to end-user behavior.  There other abuse factors, separate from that, which DMARC apparently correlates usefully with, which is why it apparently really is useful to the filtering engine.  But not the recipient user.


I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't you do something about that?" on which to base that.

Exactly.


Hasn't M3AAWG at least had something other than anecdata that this is a true source of pain?

No.

As I mentioned in the previous note, there was a literature survey done at the start of the BIMI work, and it produced no evidence to support claims of improved end user behavior.

The canonical example of this issue was the EV web domain name exercise.



DMARC is a triumph of infrastructure operator demands over end-user
experience.  it's created a markedly Procrustean email identification
environment.

The standards and the practice, for 45 years, have permitted certain
freedoms in the From: field and DMARC eliminated them.

It's easy to be cavalier about this, since some operators run highly
controlled environments and have no incentives for paying attention to
those who have used those freedoms legitimately, for 45 years.

No reply here, just felt like citing this again.

ditto.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------E7C7C4E520FC6FEC1AE1FFF5-- From nobody Tue Jun 2 14:31:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601DA3A1023 for ; Tue, 2 Jun 2020 14:31: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, 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=valimail.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 b-QRltRfWiQc for ; Tue, 2 Jun 2020 14:31:10 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 15F3D3A1020 for ; Tue, 2 Jun 2020 14:31:10 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id q11so162869wrp.3 for ; Tue, 02 Jun 2020 14:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9mJJbAYWNtSMJOpOnCM2L3d5nz4aSdHAsQRBzf4+p+Q=; b=dLnA3+iLsdleRDrqF+ONM/8sfx/nT6qL+iiVfBpY1BhIYfMpglx4S0OKb53hgqBYTA soHa/CKCkmvQL/+9Df/fitpiXUNVxM3f/hRRxVzA7UMZLz+Pxw8K9MZemzC6KrnhgjsX FHBeWEM3VgnEnEBoDGuH+1hthEZh1BU69ZItwYCyFgzQUerG3OFl7GPAZOdcDrU1Fx2P 35wQcZZRfa5auRDCRSEdUyGS7yd08mZu75Ig68932kmt5X5CFjGXR81ZOySI4q1IMrXb QivXv9/WMlwAGF5g01pPQhPqVdVAAXkPFvf8PWd2cjTRNgXSNvoC/6HlUKAx2/hRXGJA yZEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9mJJbAYWNtSMJOpOnCM2L3d5nz4aSdHAsQRBzf4+p+Q=; b=m+zw3Jbk8vkaarWzI9Ll57epLF0ipxI1+olhPdd7hQx0DduHR/gv5r8RZGmf1RBmlc jCGgmqUKA2xtuH36edIM6KG3L1ziuraZrXBvFbqG/OYAME0WB1RGu5nlquoCG7l9I18l cD69dPpwU+I7ID6PXyO8nk9D+Zbtm4NmjDOn2+7OzOJdL6h9Hut8PCs7WxjyLYS68lZm L7rtmzNzxJLjSpNM8TNg0bU0RTERu0aoiLMIwXkLRvivKmbzjrSyfPBYVYDVWTNVi+Yi 97Vms78rLyh4PeE/zvOZ2SZ3zg4/sL0ZbainGimtRUBj162vZwEvU65oJFWTtWEPT7Bk LHEg== X-Gm-Message-State: AOAM5309iveI9Q5uy/L3d/ZjOHtd3D+vzLnn5Avhr/37RdAfQ8VdnMJD NDfMe/WBFbrEYRGzeSkn5QTb+pSVFK0xXsEplJ1fk50/FnU= X-Google-Smtp-Source: ABdhPJyEZlI8yNQ5LV6rKT7MVrq9X0gtLkrln4ymZuGoOSh8W2Qr3aeiJgzYtEY+12IZD9LzjwFngj22Gndkdsvbdd8= X-Received: by 2002:a5d:4490:: with SMTP id j16mr30409382wrq.276.1591133458226; Tue, 02 Jun 2020 14:30:58 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> In-Reply-To: From: Seth Blank Date: Tue, 2 Jun 2020 14:30:47 -0700 Message-ID: To: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009177dd05a720a095" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:31:12 -0000 --0000000000009177dd05a720a095 Content-Type: text/plain; charset="UTF-8" As an individual: On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > However there appears to be no actual evidence that lying in the From > field affects end user behaviors, and certainly none that lying in the From > field about the domain name does. > There are decades of data that prove just this. On the abuse side, Microsoft, Google, Proofpoint, Mimecast, and others (including Valimail) have all published reams of research reports over the years. On the marketing side, there's another decade or two of data about how properly crafting the From materially impacts open rates on messages, which means user behavior is certainly impacted by what's in the From and display name. There's more data here than can be meaningfully summarized. So to pick one at random about usage of these methods in abuse, read page 11 of this report: https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf And on the marketing side, after a 2 second google search, here's some A/B testing: https://blog.influenceandco.com/how-to-optimize-your-email-open-rate-with-friendly-froms I suppose it's possible that operators came up with this problem and > decided it needs solving, with no user complaints like "I was fooled by > this fake From, can't you do something about that?" on which to base that. > > Exactly. > The history of DMARC is the exact opposite. There was a mountain of phish impersonating well known companies that was defrauding consumers to the tune of hundreds of millions of dollars, and the companies involved got together and asked the major mailbox providers to work with them to determine the appropriate signals needed to prevent the phishing using their domains. DMARC is the result of a multi-year comprehensive data investigation here. > Hasn't M3AAWG at least had something other than anecdata that this is a > true source of pain? > > No. > > As I mentioned in the previous note, there was a literature survey done at > the start of the BIMI work, and it produced no evidence to support claims > of improved end user behavior. > > The canonical example of this issue was the EV web domain name exercise. > Trust indicators that require users take appropriate action are doomed to fail, and as you mentioned the data concurs. See your EV example and the reason that padlock icons are going away. But the flipside is not true. What users see can certainly trick them into doing the wrong thing, especially if they believe they're doing the right thing, and especially if a wide net is cast. This is why CEO-CFO and gift card scams are so prevalent and effective. Again, grabbing a random example from another 2 second google search, a few years ago the FBI said this type of scam resulted in $2.3 billion worth of damages: https://www.fbi.gov/contact-us/field-offices/phoenix/news/press-releases/fbi-warns-of-dramatic-increase-in-business-e-mail-scams Or: https://ottawa.ctvnews.ca/city-treasurer-sends-128-000-to-fraudsters-in-email-phishing-scam-1.4370829 (although it's unclear if DMARC would have solved this attack, the point is that the treasurer thought it was from the mayor). M3AAWG has shared mountains of data that DMARC solves a materially significant problem, and this has been presented on again and again and again. Governments are increasingly mandating it, and more industry organizations are requiring it for all members. This is a source of real pain which goes far beyond anecdotes. Seth (hatless, and trying to understand your comments) --0000000000009177dd05a720a095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual:

On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <dcrocker@gmail.com> wrote:
=20 =20 =20
However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.

There are decades of data that prove just this. On the abuse side, Microso= ft, Google, Proofpoint, Mimecast, and others (including Valimail) have all = published reams of research reports over the years. On the marketing side, = there's another decade or two of data about how properly crafting the F= rom materially impacts open rates on messages, which means user behavior is= certainly impacted by what's in the From and display name.
<= br>
There's more data here than can be meaningfully summarize= d. So to pick one at random about usage of these methods in abuse, read pag= e 11 of this report:=C2=A0https://www.proofpoint.com/site= s/default/files/pfpt-us-tr-q117-threat-report.pdf

<= div>And on the marketing side, after a 2 second google search, here's s= ome A/B testing:=C2=A0https://blog.influenceandco= .com/how-to-optimize-your-email-open-rate-with-friendly-froms

<= div>I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't= you do something about that?" on which to base that.

Exactly.


The history of DM= ARC is the exact opposite. There was a mountain of phish impersonating well= known companies that was defrauding consumers to the tune of hundreds of m= illions of dollars, and the companies involved got together and asked the m= ajor mailbox providers to work with them to determine the appropriate signa= ls needed to prevent the phishing using their domains. DMARC is the result = of a multi-year comprehensive data investigation here.
=C2=A0
<= div>Hasn't M3AAWG at least had something other than anecdata that this is a true source of pain?

No.

As I mentioned in the previous note, there was a literature survey done at the start of the BIMI work, and it produced no evidence to support claims of improved end user behavior.

The canonical example of this issue was the EV web domain name exercise.


Trust indicators = that require users take appropriate action are doomed to fail,=C2=A0and as = you mentioned the data concurs. See your EV example and the reason that pad= lock=C2=A0icons=C2=A0are going away.

But the flips= ide is not true. What users see can certainly trick them into doing the wro= ng thing, especially if they believe they're doing the right thing, and= especially if a wide net is cast. This is why CEO-CFO and gift card scams = are so prevalent and effective. Again, grabbing a random example from anoth= er 2 second google search, a few years ago the FBI said this type of scam r= esulted in $2.3 billion worth of damages:=C2=A0https://www.fbi.gov/contact-us/field-= offices/phoenix/news/press-releases/fbi-warns-of-dramatic-increase-in-busin= ess-e-mail-scams

Or: https://ottawa.ctvnews.ca/city-treasurer-sends-128-000-to-fra= udsters-in-email-phishing-scam-1.4370829 (although it's unclear if = DMARC would have solved this attack, the point is that the treasurer though= t it was from the mayor).=C2=A0

M3AAWG = has shared mountains of data that DMARC solves a materially significant pro= blem, and this has been presented on again and again and again. Governments= are increasingly mandating it, and more industry organizations are requiri= ng=C2=A0it for all members. This is a source of real pain which=C2=A0goes f= ar beyond anecdotes.

Seth (hatless, and trying to = understand your comments)

--0000000000009177dd05a720a095-- From nobody Tue Jun 2 14:42:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0D3A103F for ; Tue, 2 Jun 2020 14:42:45 -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=valimail.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 663voNvRXlGO for ; Tue, 2 Jun 2020 14:42:43 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 BB24C3A1046 for ; Tue, 2 Jun 2020 14:42:42 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id r7so198122wro.1 for ; Tue, 02 Jun 2020 14:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=I5S5g0yN4KUt+aHXkR4cEhr33tcpBZf1U/DtpL0tlUU=; b=H2BXmAVpWT4eVDEl54SRSv2AuMy0VrRUrH8gCfaTXQzKVwAQPQZ+WwreU+4PraSYts qs8va27tmJ6ihT5ikLfgqVoIR0f3XkmtP6r/zcCmicP6SX9/OPwKasuqz3moE4W57JJG EnvICnN43yK9unI5HUYAWljw0eZdSPIRmD1CmhFVY+Zyyywy1QbGXobB2U54m8SZpoL7 5NICN+TXXstfbwZBkQZJC3Nb225wk8gMFSxHFA/xTp1PT59UWFHjmUzLgHeAsyC77ejC fnHlLHIE3MS9XM3JzJin5PcG4Trb+LGwmdrczZ9gD34HjTLyxKntbeE+RDX0zW9tXwHO no2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=I5S5g0yN4KUt+aHXkR4cEhr33tcpBZf1U/DtpL0tlUU=; b=CI1AsNXw4ApVZlGrWSeWlB+Ut60pHKqp3pvS3ZO0babCB9xYsyC0FQCImoNQoervZD JKqhb66l2/4w4CgSPOqC+XjAL0KA+OF0Ql41aEeryeOekc0yWWWKeBFOPN5nWdlBzPCz ourv0xkUXXjReYoVeIDYQas4WMGMwvjRV3U5m/JLMwyX6lGwWhYXioYnIRkFerMC4lEY Z9cm7nI/D9kVXnbw9rjsdyUOm/1vGy5xmAfElj8u0gvXLfwTS28REPuvc2D4MhvSucCx 8CVlBSprfU02y4qNkt47cRRrUHpiFfdh8NBW2Y+7P2hkf5uHDCsiDCS6C/GDkY+MdbIn brkg== X-Gm-Message-State: AOAM531fBeDg02YjADIkNTIjLDciknQg0rnHSIrVSICS9RVahDOSjcOg h1EI9FzrjR+t1LX3AyzYH4zz56oDZ46kwmvWC+JJwg== X-Google-Smtp-Source: ABdhPJzh4ncDvI3a4XCK+IvFTuDLXdXJw1L598Qq+cb0XYhs05KqKNSyjYZqKaXYrf2904KthTHjtMzvA+AGMbRpswg= X-Received: by 2002:adf:f507:: with SMTP id q7mr27401016wro.353.1591134160428; Tue, 02 Jun 2020 14:42:40 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> In-Reply-To: From: Seth Blank Date: Tue, 2 Jun 2020 14:42:29 -0700 Message-ID: To: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c2b5205a720ca0a" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:42:46 -0000 --0000000000006c2b5205a720ca0a Content-Type: text/plain; charset="UTF-8" Also, from literally today: https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more On Tue, Jun 2, 2020 at 2:30 PM Seth Blank wrote: > As an individual: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > >> However there appears to be no actual evidence that lying in the From >> field affects end user behaviors, and certainly none that lying in the From >> field about the domain name does. >> > > There are decades of data that prove just this. On the abuse side, > Microsoft, Google, Proofpoint, Mimecast, and others (including Valimail) > have all published reams of research reports over the years. On the > marketing side, there's another decade or two of data about how properly > crafting the From materially impacts open rates on messages, which means > user behavior is certainly impacted by what's in the From and display name. > > There's more data here than can be meaningfully summarized. So to pick one > at random about usage of these methods in abuse, read page 11 of this > report: > https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf > > And on the marketing side, after a 2 second google search, here's some A/B > testing: > https://blog.influenceandco.com/how-to-optimize-your-email-open-rate-with-friendly-froms > > I suppose it's possible that operators came up with this problem and >> decided it needs solving, with no user complaints like "I was fooled by >> this fake From, can't you do something about that?" on which to base that. >> >> Exactly. >> > > The history of DMARC is the exact opposite. There was a mountain of phish > impersonating well known companies that was defrauding consumers to the > tune of hundreds of millions of dollars, and the companies involved got > together and asked the major mailbox providers to work with them to > determine the appropriate signals needed to prevent the phishing using > their domains. DMARC is the result of a multi-year comprehensive data > investigation here. > > >> Hasn't M3AAWG at least had something other than anecdata that this is a >> true source of pain? >> >> No. >> >> As I mentioned in the previous note, there was a literature survey done >> at the start of the BIMI work, and it produced no evidence to support >> claims of improved end user behavior. >> >> The canonical example of this issue was the EV web domain name exercise. >> > > Trust indicators that require users take appropriate action are doomed to > fail, and as you mentioned the data concurs. See your EV example and the > reason that padlock icons are going away. > > But the flipside is not true. What users see can certainly trick them into > doing the wrong thing, especially if they believe they're doing the right > thing, and especially if a wide net is cast. This is why CEO-CFO and gift > card scams are so prevalent and effective. Again, grabbing a random example > from another 2 second google search, a few years ago the FBI said this type > of scam resulted in $2.3 billion worth of damages: > https://www.fbi.gov/contact-us/field-offices/phoenix/news/press-releases/fbi-warns-of-dramatic-increase-in-business-e-mail-scams > > Or: > https://ottawa.ctvnews.ca/city-treasurer-sends-128-000-to-fraudsters-in-email-phishing-scam-1.4370829 > (although it's unclear if DMARC would have solved this attack, the point is > that the treasurer thought it was from the mayor). > > M3AAWG has shared mountains of data that DMARC solves a materially > significant problem, and this has been presented on again and again and > again. Governments are increasingly mandating it, and more industry > organizations are requiring it for all members. This is a source of real > pain which goes far beyond anecdotes. > > Seth (hatless, and trying to understand your comments) > > --0000000000006c2b5205a720ca0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jun 2, 2020 at 2:30 PM Seth Blank <seth@valimail.com&= gt; wrote:
As an individual:

On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <dcrocker@gmail.com> wrote:
=
=20 =20 =20
However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.

There are decades of data that prove just this. On the abuse side, Microso= ft, Google, Proofpoint, Mimecast, and others (including Valimail) have all = published reams of research reports over the years. On the marketing side, = there's another decade or two of data about how properly crafting the F= rom materially impacts open rates on messages, which means user behavior is= certainly impacted by what's in the From and display name.
<= br>
There's more data here than can be meaningfully summarize= d. So to pick one at random about usage of these methods in abuse, read pag= e 11 of this report:=C2=A0https://www.p= roofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf

And on the marketing side, after a 2 second google se= arch, here's some A/B testing:=C2=A0https://blog.influenceandco.com/how-to-optimize-your-email-open-ra= te-with-friendly-froms

<= div>I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't= you do something about that?" on which to base that.

Exactly.


The history of DM= ARC is the exact opposite. There was a mountain of phish impersonating well= known companies that was defrauding consumers to the tune of hundreds of m= illions of dollars, and the companies involved got together and asked the m= ajor mailbox providers to work with them to determine the appropriate signa= ls needed to prevent the phishing using their domains. DMARC is the result = of a multi-year comprehensive data investigation here.
=C2=A0
<= div>Hasn't M3AAWG at least had something other than anecdata that this is a true source of pain?

No.

As I mentioned in the previous note, there was a literature survey done at the start of the BIMI work, and it produced no evidence to support claims of improved end user behavior.

The canonical example of this issue was the EV web domain name exercise.


Trust indicators = that require users take appropriate action are doomed to fail,=C2=A0and as = you mentioned the data concurs. See your EV example and the reason that pad= lock=C2=A0icons=C2=A0are going away.

But the flips= ide is not true. What users see can certainly trick them into doing the wro= ng thing, especially if they believe they're doing the right thing, and= especially if a wide net is cast. This is why CEO-CFO and gift card scams = are so prevalent and effective. Again, grabbing a random example from anoth= er 2 second google search, a few years ago the FBI said this type of scam r= esulted in $2.3 billion worth of damages:=C2=A0https://www.fbi.gov= /contact-us/field-offices/phoenix/news/press-releases/fbi-warns-of-dramatic= -increase-in-business-e-mail-scams

Or: https://ottawa.ctvnews.ca= /city-treasurer-sends-128-000-to-fraudsters-in-email-phishing-scam-1.437082= 9 (although it's unclear if DMARC would have solved this attack, th= e point is that the treasurer thought it was from the mayor).=C2=A0

M3AAWG has shared mountains of data that DMARC= solves a materially significant problem, and this has been presented on ag= ain and again and again. Governments are increasingly mandating it, and mor= e industry organizations are requiring=C2=A0it for all members. This is a s= ource of real pain which=C2=A0goes far beyond anecdotes.

Seth (hatless, and trying to understand your comments)

--0000000000006c2b5205a720ca0a-- From nobody Tue Jun 2 15:01:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D85F3A1047 for ; Tue, 2 Jun 2020 15:01:08 -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, FREEMAIL_FROM=0.001, 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=gmail.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 MfJaLTZXN_wJ for ; Tue, 2 Jun 2020 15:01:06 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 EFF573A1045 for ; Tue, 2 Jun 2020 15:01:05 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id x202so12961206oix.11 for ; Tue, 02 Jun 2020 15:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2Q8oKDPDv5049u0SeUe2tuTPyyknldTcxGXVVOtB1G4=; b=HOC2cQj76Nx+07tkq/R6ndNdvlwySdZBgamZZ5uPMyEXIt95NwAUZ3JRdLpmlfJABk eNECdvNDBmeU5qAiCoh9buL7J/xlxz+Nopv3ngkqCWU0uTxkV1lvji0o6lMEQopaS8y/ VfsOnMl48phIURz138Y8utYiHN0VVEdlNNDqasN1oZbSTSlnvui1QX/5/E3LErEJYUtD 03CytGEgCO+wCDBcN9lvTvnQb/V+IlSmElVvRlNY0LVxZixx0VSuPs/7g8JDHoDmsdMW 1MQa90bANLPDasQqjb1jCA3hNVSXbiXhNEUQSJFlatPsu3W7+gHQFtMamT/hvg5Sz6Sp aGTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2Q8oKDPDv5049u0SeUe2tuTPyyknldTcxGXVVOtB1G4=; b=ZFvCdTQAnkMri5lzPixpduGo952p5K6GC4GptCepdrxfm1HTNB762nkplZ1D2jKm87 cSo5yzUenlvqnwPlXvPD6vZK8PqNZH37+OVxZYs1hwe2AceGQgSltJYx/5whE26LsgqR 9fyPVRX+jXxCTGcHw6ZuscMv5pGc30JPwxsP1PBkArHA6GlLFSQRYmJJBxDCq3dKmHsY UlYBL4rnJBIdaIz/fMaPQkaUOuXrKZvW8UYA2IqtMm8LynYPPoZuUbeVZsmH/5Vld/iC 4s8QFydrV355Atn0IQVVg+JTCj+engq4LscHF7HSoPoKtn6sBrfYqfpSVRGJsAjqxByn cqBQ== X-Gm-Message-State: AOAM533iiAbSNpTvWvMqu6dxP0piRiRCJALmLfl28rhTiafz+PA8ZkPd eG/8qrdJZE5qN97gWRTN6ppXiKcY X-Google-Smtp-Source: ABdhPJx57tO+z6HokN4gF+1rmgz/gfDG04KoUbzJfrNbM9eI8bXvcliQ/gh/UN/GZYT47uj6K0Dbeg== X-Received: by 2002:a05:6808:8d9:: with SMTP id k25mr3283453oij.179.1591135263653; Tue, 02 Jun 2020 15:01:03 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id a34sm35459otc.60.2020.06.02.15.01.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 15:01:02 -0700 (PDT) To: Seth Blank , "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> From: Dave Crocker Message-ID: <33127379-a381-2d6c-a418-8525ac2d5693@gmail.com> Date: Tue, 2 Jun 2020 15:01:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E185379700A0E98E8C331AF" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 22:01:08 -0000 This is a multi-part message in MIME format. --------------4E185379700A0E98E8C331AF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wow. I'll ask folk to reread my text, here, carefully, since it specified something quite narrow and concrete, but is somehow being taken to have meant something broad and general: > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker > wrote: >> However there appears to be no actual evidence that lying in the From >> field affects end user behaviors, and certainly none that lying in >> the From field about the domain name does. And again, there are all sorts of threats and all sorts of bad behaviors, but the question is whether a particular kind of bad actor behavior affects recipient end-user behavior. And the specific kind is lying about the From: field domain name. Please point to specific research -- not an extended report with lots of varying content. On 6/2/2020 2:30 PM, Seth Blank wrote: > There are decades of data that prove just this. As I said, we did an extensive literature search at the beginning of the BIMI and there was no supporting research. So now let's look at the purported counter-example you provided: > On the abuse side, Microsoft, Google, Proofpoint, Mimecast, and others > (including Valimail) have all published reams of research reports over > the years. On the marketing side, there's another decade or two of > data about how properly crafting the From materially impacts open > rates on messages, which means user behavior is certainly impacted by > what's in the From and display name. > > There's more data here than can be meaningfully summarized. So to pick > one at random about usage of these methods in abuse, read page 11 of > this report: > https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf Doesn't contain the word 'behavior'. Doesn't contain 'from:' Only 'author' is reference to malware creators, not recipients. 'Recipeint' gets a brief sidebar reference to mail pretending to be from a top executive. Another sidebar with the word explains 'spoofing' as impersonation (which, of course, is what it means in the real world, but not in the email abuse world, which has a much broader definition. I'll stop now and note that the reference you gave appears to have nothing to do with the specific behavioral issue I cited. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------4E185379700A0E98E8C331AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Wow. I'll ask folk to reread my text, here, carefully, since it specified something quite narrow and concrete, but is somehow being taken to have meant something broad and general:

On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <dcrocker@gmail.com> wrote:
However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.


And again, there are all sorts of threats and all sorts of bad behaviors, but the question is whether a particular kind of bad actor behavior affects recipient end-user behavior. 

And the specific kind is lying about the From: field domain name. 

Please point to specific research -- not an extended report with lots of varying content.


On 6/2/2020 2:30 PM, Seth Blank wrote:
There are decades of data that prove just this.

As I said, we did an extensive literature search at the beginning of the BIMI and there was no supporting research. 

So now let's look at the purported counter-example you provided:

On the abuse side, Microsoft, Google, Proofpoint, Mimecast, and others (including Valimail) have all published reams of research reports over the years. On the marketing side, there's another decade or two of data about how properly crafting the From materially impacts open rates on messages, which means user behavior is certainly impacted by what's in the From and display name.

There's more data here than can be meaningfully summarized. So to pick one at random about usage of these methods in abuse, read page 11 of this report: https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf

Doesn't contain the word 'behavior'.

Doesn't contain 'from:'

Only 'author' is reference to malware creators, not recipients.

'Recipeint' gets a brief sidebar reference to mail pretending to be from a top executive. Another sidebar with the word explains 'spoofing' as impersonation (which, of course, is what it means in the real world, but not in the email abuse world, which has a much broader definition.

I'll stop now and note that the reference you gave appears to have nothing to do with the specific behavioral issue I cited.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------4E185379700A0E98E8C331AF-- From nobody Tue Jun 2 15:26:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDF3A1095 for ; Tue, 2 Jun 2020 15:26:36 -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 (1024-bit key) header.d=drkurt.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 F5R0odBpOiKh for ; Tue, 2 Jun 2020 15:26:34 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 AC3283A1093 for ; Tue, 2 Jun 2020 15:26:34 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id z2so522585ilq.0 for ; Tue, 02 Jun 2020 15:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mU+u+DDWsGkK2fZF1lXcD9bsPt+SJ5nGWvuq+Isy1RM=; b=WWfS3ec2v/xOSc+KSOi7lf4+BOpv+jpoGwkqat8fkPAiJHsElcyZC9UJ1wYXJi9qJJ QSHDp4klyYWYC2mFRKhjfHnqmgsPeQiaKrw+ca47DVzdDJ3ervPKsxroVJEg7o5Q1LBa hNgUk9OikhlJyoGk5sHWFK5AQPV1RSGbGuekU= 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=mU+u+DDWsGkK2fZF1lXcD9bsPt+SJ5nGWvuq+Isy1RM=; b=biiEkCYSfRjfcaWNpZBUJ+6mzZmrLPlIVrymmn6qe33XQ8bnuJacHQzI/4VvIv3K+S TXsixNrWHNp+/ZhHThPnPjv5THXknsSB0/CAdkgaROPgwNzHJLJNB2bcHxt6+0BG+Xu4 4tUvPd8z/21dif7ZRtImSHmEiyylygdMr8smHnIC0LSzEZMnJ8LYNBfLFY90o+XCP+WP Y8uKhFFzFCppBIbzdYIv7qGkRfwgvLUBMe4KPjw4NUXhOEY2EV5qM+NFLatFAFoaiujB UfWvmkhOgMs2BUlD61ADabEuEv2El7PXFpCMPSilO1Pt+XNNZGlq/gqlmm9DYG6t05TI sVcg== X-Gm-Message-State: AOAM532JK/EUMfdopaCe9k/icm2HoeGi0k7Eo1PUfEkcvOqTW0lkExVz Ho7oodJXVl+5Pfl2P7he655EDY14ms67fLiTMyidQw== X-Google-Smtp-Source: ABdhPJziAgt7T/tyOO37co3ApgxSzQYEzLA4PKRCD2/Cz5037F+uJ5nqkMS+MGnd7N1MzvacTTxGsMAUeT3xVlTP05o= X-Received: by 2002:a05:6e02:d2:: with SMTP id r18mr1341082ilq.263.1591136793581; Tue, 02 Jun 2020 15:26:33 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <33127379-a381-2d6c-a418-8525ac2d5693@gmail.com> In-Reply-To: <33127379-a381-2d6c-a418-8525ac2d5693@gmail.com> From: "Kurt Andersen (b)" Date: Tue, 2 Jun 2020 15:26:12 -0700 Message-ID: To: Dave Crocker Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ef1ab05a7216728" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 22:26:36 -0000 --0000000000005ef1ab05a7216728 Content-Type: text/plain; charset="UTF-8" I'm sorry to pile on but could not restrain myself: https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a&keytype2=tf_ipsecsha I get Dave's point, but at the same time, it is well known that copy tweaks can have significant effects on conversion rates. Whether the specific tweak of the 5322.From header field's SMTP domain from to has an effect separate from any other subterfuges that might be being employed by the miscreant is probably hard to disambiguate, especially since in the real world, it is rare to have bare SMTP addresses in that header field. --Kurt On Tue, Jun 2, 2020 at 3:01 PM Dave Crocker wrote: > Wow. I'll ask folk to reread my text, here, carefully, since it specified > something quite narrow and concrete, but is somehow being taken to have > meant something broad and general: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > > However there appears to be no actual evidence that lying in the From > field affects end user behaviors, and certainly none that lying in the From > field about the domain name does. > > And again, there are all sorts of threats and all sorts of bad behaviors, > but the question is whether a particular kind of bad actor behavior affects > recipient end-user behavior. > --0000000000005ef1ab05a7216728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry to pile on but could not re= strain myself:=C2=A0= https://www.bmj.com/content/327/7429/1459?ijkey=3Dc3677213eca83ff6599127794= fc58c4e0f6de55a&keytype2=3Dtf_ipsecsha

I get Dav= e's point, but at the same time, it is well known that copy tweaks can = have significant effects on conversion rates. Whether the specific tweak of= the 5322.From header field's SMTP domain from <rando-domain> to = <unprotected-by-dmarc-enforcement-domain> has an effect separate from= any other subterfuges that might be being employed by the miscreant is pro= bably hard to disambiguate, especially since in the real world, it is rare = to have bare SMTP addresses in that header field.

= --Kurt


On Tue, Jun 2, 2020 at 3:01 PM Dave Crocker <= dcrocker@gmail.com> wrote:
=
=20 =20 =20
Wow. I'll ask folk to reread my text, here, carefully, since it specified something quite narrow and concrete, but is somehow being taken to have meant something broad and general:
On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <dcrocker@gmail.com&= gt; wrote:
However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.

And again, there are all sorts of threats and all sorts of bad behaviors, but the question is whether a particular kind of bad actor behavior affects recipient end-user behavior.=C2=A0=C2=A0

--0000000000005ef1ab05a7216728-- From nobody Tue Jun 2 15:28:56 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD23A10A0 for ; Tue, 2 Jun 2020 15:28:54 -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, FREEMAIL_FROM=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=gmail.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 hKn4QMdhjw3I for ; Tue, 2 Jun 2020 15:28:53 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 60DB13A109D for ; Tue, 2 Jun 2020 15:28:53 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id 69so280522otv.2 for ; Tue, 02 Jun 2020 15:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mENNev/EbjQbB8n5TdtxtWBZfS1uIwznP2KJDMdR1rw=; b=Jy6aO2zrCYqu1xORMidXhyzM0+9Gvlhtc7CLVPEWFEDYh9RL3fY8gXDtObIsa6N6VV GcGvHIWmtFJ9YyQnsDOnY8d5gWg0QHh1O4ZlcsraKvyAv5SAgimlAukc3YnNUJZexEQb F+Ko7ZSBWFCyfGr4fAtpEPswpN0tFl5mC3seOobs5NqZMPUdcXHNnNAlcDcrNfH2OML+ Z7bxWVwsuf/U4U24cENsYeMSBvRzwzErQ4648c4Vjz7OtGqAhiAbf+8Za8yr7HEgg7Wl ZxkY6vyv23gkkABXMMuNPfeCmrLvgYHiBcwizk2CAWJtU8SKQPINc5AL+ZciVHWqkpzk n9XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mENNev/EbjQbB8n5TdtxtWBZfS1uIwznP2KJDMdR1rw=; b=j6ytpBVHU896mNn8rJQbY6wiE5BtgHTrmPKL5hlJS2xWIXFSxcnqyYodaa4ITVU0C/ C1hW7WxA2hyyx1N49SK+cnMV5qqiB2dItXfOSnp4vdkyNBDHCniCTHGzlJ8OK19bzrUS H65o+Rv+opC9AEAAUxXO6B59xkLQUbDZhNJzwm0qVVv8eaHskHJ1boV9iliNZlxbbMNY 6dWgzGVhGlJa90AsjsW1WElDbhzRqPcmN23iG+PObG3T/dB8v3zX+tl7y0L5a1mjBMKy +HjdWhSRKfI7Y26h7OHvxZbUCjH2lQOvk9YKuLqt/efenq2mEd7oPYZpuesfnY12EFiQ 1nBg== X-Gm-Message-State: AOAM531baAZAE82ri6Bnr8QgeUyiD470dqMiVdIM+v76W9ro3TDO4+um H5DaDczeqxvi6Sjfy8FINlKRXw1+ X-Google-Smtp-Source: ABdhPJxlh5c12KHrNH5+qQUl5h5hzZuvdDgi7UF0AZCdr3MzjMywLUISxFMu8I4alJkohIbhsgGOTg== X-Received: by 2002:a9d:3423:: with SMTP id v32mr1064539otb.178.1591136932549; Tue, 02 Jun 2020 15:28:52 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id a8sm50908otp.65.2020.06.02.15.28.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 15:28:52 -0700 (PDT) To: Seth Blank , "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> From: Dave Crocker Message-ID: <62befcd6-c209-8f43-f713-f31fb4d16ba6@gmail.com> Date: Tue, 2 Jun 2020 15:28:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 22:28:55 -0000 On 6/2/2020 2:42 PM, Seth Blank wrote: > Also, from literally today: > https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more Oh my. Is it really that difficult to understand the difference between choosing to take an action, versus being affected by your taking that action. Let's keep this simple: 1. Most users do not see the domain name in the From: field.  So how could using a cousin domain or any other misbehavior with the domain name, cause the recipient to be tricked? 2. Nothing in that article demonstrates that a recipient was tricked into misbehavior by the presence of a problematic From: field domain name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 15:42:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5643A10C0 for ; Tue, 2 Jun 2020 15:42:32 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 5Ii_N_YUrU4Q for ; Tue, 2 Jun 2020 15:42:30 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 94DAF3A10BD for ; Tue, 2 Jun 2020 15:42:30 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id r9so31752wmh.2 for ; Tue, 02 Jun 2020 15:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YrK7MaIzYMZMhHGX9142NEiUZEuQNm4xKqvn5c1CuLE=; b=fMAQCDZoyWveTJvqEkxBymzaGr3/WG+/LeZqBKgtfD8aVKbcod7yazBqGfNvoiCUWx PAgwYGv2Y75vunocQ+cFueX262iXYVzLU21KoUf1cn5Hb7sgUCoYBHCmdQ/LdLhYzZJl ZmWeoQCef8iHBDZ6bFa8DYHq6lxljyBuNl7r8/Y+hYHj4nWSAYsB3Y4uZo1qstXx8BIK vl+Lz9ntwWCwIEk90hNJDyfmclnvcdMLUuBKPf4ohgr9CJlFUgjjLuOYUOrAyKjD4Hb8 O0QqwkZWOk81/p5sWMeT9IrG7VTfqM/cThkT/5X8VIrQ09GV6Th4rL6dQTaZ++gac8fL l7ow== 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=YrK7MaIzYMZMhHGX9142NEiUZEuQNm4xKqvn5c1CuLE=; b=otk2p474pdKdohZOkutgXCGimr8gDymeSoBrPyG3s9upZWGEllYZrgpg8ZXNyNryQq KQ9fr8rQxtGv/0WX70glT0u1tyCwUXOOEVLit222a8muMBfeiNi/JYiGY63Pjsvi9MQg f5rPd/7BwkDq+ZYyQphaA3M0EaW8RDPwxSBHqcqo0nds6BRRf0idMq/syIX/5Cpwhlw+ PGVwM6v6qxrVHEN2ZnwLNzEv/uFkqdbGqy1FzTNhXMYLUDkLrScQlWFr3OfcqYogsXqY 8MguZARfrQ9ukTiFP9nDsaso2B6b+w68ov4t/N0pAgLK0Jzn5d/UDO3Al8oV2eA43ToH hW6A== X-Gm-Message-State: AOAM531N5QKAsqfyjwj0PRrumxNTgTwPjv7qguV47X7dLElbXqrbp9Kk qakhWmzHVK5b48q3KpwUHeRHA+HFXx6FlFLi5yI= X-Google-Smtp-Source: ABdhPJwXRURRSy2Ivcer3UXQbvm5EJ+KsWgCFL6ismnyu5O6kNASB4ZYCThj4suolhKHoLjKxTJzLY/k/16TG/FKI3I= X-Received: by 2002:a1c:46c3:: with SMTP id t186mr5691549wma.36.1591137727568; Tue, 02 Jun 2020 15:42:07 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> In-Reply-To: From: Dotzero Date: Tue, 2 Jun 2020 18:41:55 -0400 Message-ID: To: Seth Blank Cc: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000a63ad05a7219ff9" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 22:42:33 -0000 --0000000000000a63ad05a7219ff9 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 5:31 PM Seth Blank wrote: > As an individual: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > >> However there appears to be no actual evidence that lying in the From >> field affects end user behaviors, and certainly none that lying in the From >> field about the domain name does. >> > > There are decades of data that prove just this. On the abuse side, > Microsoft, Google, Proofpoint, Mimecast, and others (including Valimail) > have all published reams of research reports over the years. On the > marketing side, there's another decade or two of data about how properly > crafting the From materially impacts open rates on messages, which means > user behavior is certainly impacted by what's in the From and display name. > > There's more data here than can be meaningfully summarized. So to pick one > at random about usage of these methods in abuse, read page 11 of this > report: > https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf > > And on the marketing side, after a 2 second google search, here's some A/B > testing: > https://blog.influenceandco..com/how-to-optimize-your-email-open-rate-with-friendly-froms > > > I suppose it's possible that operators came up with this problem and >> decided it needs solving, with no user complaints like "I was fooled by >> this fake From, can't you do something about that?" on which to base that. >> >> Exactly. >> > > The history of DMARC is the exact opposite. There was a mountain of phish > impersonating well known companies that was defrauding consumers to the > tune of hundreds of millions of dollars, and the companies involved got > together and asked the major mailbox providers to work with them to > determine the appropriate signals needed to prevent the phishing using > their domains. DMARC is the result of a multi-year comprehensive data > investigation here. > > Actually Seth, you are flat out wrong. I was there and part of it. It was not about signaling. It was implemented at the MTA level and was about preventing the "badness" from reaching the end user rather than signaling to the end user. Google experimented with displaying "keys" and Microsoft experimented with displaying "shields". Neither of those efforts were integral to the DMARC effort. My own experience is that a significant percentage of end users will click on just about anything. This was validated in the 2007 timeframe during some phishing runs where the bad guys actually left some tracking code on a fake WWW landing page the email links led to. It was also validated during the Storm Worm when the links used IP Addresses. This issue has been validated at other points and times. Individual sending organizations and receiving domains have been generally reluctant to release data because it might expose company confidential information. Aggregated isn't so useful because there are significant variations in company efforts - not just with DMARC - that impact outcomes. So far, signaling to the end user doesn't have a particularly good track record. DMARC started as a private effort among a handful of private parties. when it was successful in stopping direct domain abuse for a handful of sending domains at a handful of receivers we started discussing whether the approach could be codified as a standard to enable others to benefit from the approach. The origins and history are important in understanding why DMARC is what it is. Michael Hammer > --0000000000000a63ad05a7219ff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 2, 2020 at 5:31 PM Seth B= lank <seth=3D40valimail.com@dmarc.ietf.org> wrote:
As an individual:

On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <dcrocker@gmail.com>= wrote:
=20 =20 =20
However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does.

There are decades of data that prove just this. On the abuse side, Microso= ft, Google, Proofpoint, Mimecast, and others (including Valimail) have all = published reams of research reports over the years. On the marketing side, = there's another decade or two of data about how properly crafting the F= rom materially impacts open rates on messages, which means user behavior is= certainly impacted by what's in the From and display name.
<= br>
There's more data here than can be meaningfully summarize= d. So to pick one at random about usage of these methods in abuse, read pag= e 11 of this report:=C2=A0https://www.p= roofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf

And on the marketing side, after a 2 second google se= arch, here's some A/B testing:=C2=A0https://blog.influenceandco..com/how-to-optimize-your-email-open-r= ate-with-friendly-froms

<= div>I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't= you do something about that?" on which to base that.

Exactly.


The history of DM= ARC is the exact opposite. There was a mountain of phish impersonating well= known companies that was defrauding consumers to the tune of hundreds of m= illions of dollars, and the companies involved got together and asked the m= ajor mailbox providers to work with them to determine the appropriate signa= ls needed to prevent the phishing using their domains. DMARC is the result = of a multi-year comprehensive data investigation here.
=C2=A0

Actually Seth, you are flat = out wrong. I was there and part of it. It was not about signaling. It was i= mplemented at the MTA=C2=A0 level and was about preventing the "badnes= s" from reaching the end user rather than signaling to the end user. G= oogle experimented with displaying "keys" and Microsoft experimen= ted with displaying "shields". Neither of those efforts were inte= gral to the DMARC effort. My own experience is that a significant percentag= e of end users will click on just about anything. This was validated in the= 2007 timeframe during some phishing runs where the bad guys actually left = some tracking code on a fake WWW landing page the email links led to. It wa= s also validated during the Storm Worm when the links used IP Addresses. Th= is issue has been validated at other points and times. Individual sending o= rganizations and receiving domains have been generally reluctant to release= data because it might expose company confidential information. Aggregated = isn't so useful because there are significant variations in company eff= orts - not just with DMARC - that impact outcomes. So far, signaling to the= end user doesn't have a particularly good track record.

=
DMARC started as a private effort among a handful of private par= ties. when it was successful in stopping direct domain abuse for a handful = of sending domains at a handful of receivers we started discussing whether = the approach could be codified as a standard to enable others to benefit fr= om the approach. The origins and history are important in understanding why= DMARC is what it is.

Michael Hammer
--0000000000000a63ad05a7219ff9-- From nobody Tue Jun 2 15:53:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7474F3A10CF for ; Tue, 2 Jun 2020 15:53:29 -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=valimail.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 A4rmPg1yVHE3 for ; Tue, 2 Jun 2020 15:53:27 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 327C03A10CE for ; Tue, 2 Jun 2020 15:53:27 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id r15so42144wmh.5 for ; Tue, 02 Jun 2020 15:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LY5Q8TheCUnH+yVaL4kRbnj31diX0up/nfp2NjN72iY=; b=EgzIAbhP8sgyVcGGyfZNT0MoVL/A6aJL4HDB59y0/dEUiTA8RgUxdzTL7MDiaaFT9Y D1bx5arxDqyFWdz3Y63o8CYoXOrql5cie8xCSmKbZHW724MkEnn8Ks+P6zdKJ+zdqivu uPVjnw3XRYB8x84eKfbN0KU4raPagGIP7hLY8aCO1idNdvBusY/wSVu7pLDaUoqmhFe9 oqsFvHudlT9NkBqhL+ub1SQ/7vhMhl6pkppem/FgSTJXcqTR6Xsz1evMiJufl2hCjZW+ qX7jarqD21Lcz7LWPKlgrTzZ3I5/hfuHkiks2r1WzVfE8AHJePPHbHQn42DSdwsMxQ/G oOsA== 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=LY5Q8TheCUnH+yVaL4kRbnj31diX0up/nfp2NjN72iY=; b=DGmAt1mtBzQ67tKTubR9w/+U+kSs3qGJks6iUM0dqWQwISW+ji3RQrJluyCA+mNfEW WbKzRHUYGAxJ3g4ZEENgVbQhb3LbjB6KwuLx2VAbPo51/l/jAO4XjlVRM+mc8hMFcgVQ XMUkB/OOK7ku6UTvIN5ELhWyANWW4kUAuxfiNUVO9n7HP/fRZMsB812cVXG7Vr5McGzK kVPDpHEfZwsf182dOzbT4GV6UEDW9mEOiJuuO5YdPbJXQlCPoLPTeKtTPg/1RW83pCuL PjQFR/v7at878Ei9FXNGGJQpeMQ8j2VHOwrOIsN5mNU3+C5NXta59gRAZFqYSgDmuj7s lroQ== X-Gm-Message-State: AOAM531C1SqLpcMM08MIGjCNR/Xs7G7WmhjRet9liKehKbjCjj+Bb0XP SiKNBbsb6ktg8DC08rWWpvltYaXKPQP7sqpq7ZLK7w== X-Google-Smtp-Source: ABdhPJxqudT29WrGOrxkxt//fqkRu1H3YiDavBUgalrUOWv2P4CXlyzNCNLiWyr+75bNMAZG+6bZL71MbIMWnHmZ1tI= X-Received: by 2002:a7b:c8d6:: with SMTP id f22mr6019707wml.188.1591138405459; Tue, 02 Jun 2020 15:53:25 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> In-Reply-To: From: Seth Blank Date: Tue, 2 Jun 2020 15:53:14 -0700 Message-ID: To: Dotzero Cc: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000072432905a721c71b" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 22:53:29 -0000 --00000000000072432905a721c71b Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 3:42 PM Dotzero wrote: > Actually Seth, you are flat out wrong. I was there and part of it. It was > not about signaling. It was implemented at the MTA level and was about > preventing the "badness" from reaching the end user rather than signaling > to the end user. > Michael, there's a crossed wire here-- I didn't mean to communicate that DMARC is in any way about signaling. I'm in complete agreement here. The point I was trying to make is that consumers are susceptible to fraud, and the system needs to stop these messages before they ever get in front of a user. The signal I was talking about is from the data: when something tries to authenticate to an MTA but then tell the user it's someone else. That's what alignment fixes and what's so powerful about DMARC. > Google experimented with displaying "keys" and Microsoft experimented with > displaying "shields". Neither of those efforts were integral to the DMARC > effort. My own experience is that a significant percentage of end users > will click on just about anything. This was validated in the 2007 timeframe > during some phishing runs where the bad guys actually left some tracking > code on a fake WWW landing page the email links led to. It was also > validated during the Storm Worm when the links used IP Addresses. This > issue has been validated at other points and times. Individual sending > organizations and receiving domains have been generally reluctant to > release data because it might expose company confidential information. > Aggregated isn't so useful because there are significant variations in > company efforts - not just with DMARC - that impact outcomes. So far, > signaling to the end user doesn't have a particularly good track record. > > DMARC started as a private effort among a handful of private parties. when > it was successful in stopping direct domain abuse for a handful of sending > domains at a handful of receivers we started discussing whether the > approach could be codified as a standard to enable others to benefit from > the approach. The origins and history are important in understanding why > DMARC is what it is. > I'm in complete agreement with this, and didn't mean to convey otherwise. > > Michael Hammer > >> --00000000000072432905a721c71b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 2, 2020 at 3:42 PM Dotzero <dotzero@gmail.com> wrot= e:
Actually Seth, you are flat= out wrong. I was there and part of it. It was not about signaling. It was = implemented at the MTA=C2=A0 level and was about preventing the "badne= ss" from reaching the end user rather than signaling to the end user.<= /div>

Michael, there's a crossed = wire here-- I didn't mean to communicate that DMARC is in any way about= signaling. I'm in complete agreement here. The point I was trying to m= ake is that consumers are susceptible=C2=A0to fraud, and the system needs t= o stop these messages before they ever get in front of a user. The signal I= was talking about is from the data: when something tries to authenticate t= o an MTA but then tell the user it's someone else. That's what alig= nment fixes and what's so powerful about DMARC.
=C2=A0
Google experimented with displaying "keys" and Micro= soft experimented with displaying "shields". Neither of those eff= orts were integral to the DMARC effort. My own experience is that a signifi= cant percentage of end users will click on just about anything. This was va= lidated in the 2007 timeframe during some phishing runs where the bad guys = actually left some tracking code on a fake WWW landing page the email links= led to. It was also validated during the Storm Worm when the links used IP= Addresses. This issue has been validated at other points and times. Indivi= dual sending organizations and receiving domains have been generally reluct= ant to release data because it might expose company confidential informatio= n. Aggregated isn't so useful because there are significant variations = in company efforts - not just with DMARC - that impact outcomes. So far, si= gnaling to the end user doesn't have a particularly good track record.<= br>

DMARC started as a = private effort among a handful of private parties. when it was successful i= n stopping direct domain abuse for a handful of sending domains at a handfu= l of receivers we started discussing whether the approach could be codified= as a standard to enable others to benefit from the approach. The origins a= nd history are important in understanding why DMARC is what it is.

I'm in complete agreement wit= h this, and didn't mean to convey otherwise.
=C2=A0

Michael Hammer

--00000000000072432905a721c71b-- From nobody Tue Jun 2 16:02:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96A93A10EE for ; Tue, 2 Jun 2020 16:02:14 -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, FREEMAIL_FROM=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=gmail.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 URppgNW0gnXd for ; Tue, 2 Jun 2020 16:02:13 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 9FDA83A1129 for ; Tue, 2 Jun 2020 16:02:11 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id u23so305889otq.10 for ; Tue, 02 Jun 2020 16:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4udBsD/DOWQbUXf9NT7JRMWAlDaLHhs4xQ1q+1KNeF0=; b=jwT0S7RazL8HcvEmj9+bQYT4VK4f+dz5js6l3xtbxXekAms06ysNWCuAO5BH2DTp8n /Jr5dZiZojDbyNEh+joujPF8P22xa1B0z+8icp3dkvNBgb9Vn1Sjx75LXiNtYzFQUuWi jOju9j84J3voL+LrksqeWmv+OAOsI1VgfkFUdlLLWXSuFhLQD4L7UCmKSGjqHFMtN/7a hA2tscfYqImRrtH5XXpxygqa0b4rBHPbZWvKtfY1NEXJfK2sPdzlJd911+uQIKPvx/ZO Gm6OnAPd6u0r/6fs51Y3tOIisMdE0XT8j340jE4rTqwFSkTm2pKqJfpOQgoqzmj9ePvO HSrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4udBsD/DOWQbUXf9NT7JRMWAlDaLHhs4xQ1q+1KNeF0=; b=MzfBVX7PwCEk4Vz0duyEaimdAhde6MfAUS938o7fJadBKy1l+ncd0QYwZbQbSyPo4A So+3D2/fSHg7ZpmijYIp4XP2szd6jenWY8/0DwYLL/INr2oG0aOIxGxBsJp/+3B+Fgan EFXffJACxizToZ1QR6I/ApjdBBAk8Fn0t+lKR5XmJ3iZznjcGewzf2wkTN5iM6CSdB4+ V1GYLpw5dvobnEmBu3QZEFxbKgSdRBatOzeGpy4+oqt7GHq4INYAAhWQMhY4bX1R0egD yy4Dmp1BhtvkZ+TT3QUSlEYB0kOerc18kZtRpaY2dJLSi85oDGHwz0terYTr82lMBvtw guOQ== X-Gm-Message-State: AOAM532rPLemecFS4rjPVz284Xht0teqSGFpCtCF6JuZMKlVa0AfRHjP UCwsNNu0k2qUC55rGZHv6p86rwEX X-Google-Smtp-Source: ABdhPJxns7suq5tRUAoojVK9cp2103hhj0BJ6fvluvTbv6nceBWFxieadaHx8FEc0I9tAf0Ang9zyw== X-Received: by 2002:a9d:4703:: with SMTP id a3mr1075982otf.219.1591138930766; Tue, 02 Jun 2020 16:02:10 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id d66sm128475oia.47.2020.06.02.16.02.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 16:02:10 -0700 (PDT) To: Seth Blank , Dotzero Cc: "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> From: Dave Crocker Message-ID: <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> Date: Tue, 2 Jun 2020 16:02:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 23:02:21 -0000 On 6/2/2020 3:53 PM, Seth Blank wrote: > The point I was trying to make is that consumers are susceptible to > fraud, Of course they are.  Unfortunately, that point is irrelevant, because it isn't the question at hand. > and the system needs to stop these messages before they ever get in > front of a user. Exactly.  And that's why claiming that making the From: field domain name better (or worse) in changing recipient user behavior is wrong. > The signal I was talking about is from the data: when something tries > to authenticate to an MTA but then tell the user it's someone else. > That's what alignment fixes and what's so powerful about DMARC. Seth, your statement is so confused, I'm not sure I can fix it up. "Authenticate to the MTA?"  DKIM and DMARC don't do that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 2 17:13:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5333A1147 for ; Tue, 2 Jun 2020 17:13:34 -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=valimail.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 B-ooeAcU1MXc for ; Tue, 2 Jun 2020 17:13:32 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 55A2D3A111B for ; Tue, 2 Jun 2020 17:13:32 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id x6so399094wrm.13 for ; Tue, 02 Jun 2020 17:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1hCDuhl2K5rTbm/xiu1Ooort4uqtob80E6Lu6z1t2Tk=; b=YJg4j9yFRwZ0CokFzxWCO6wfZo0w8h9aAWtmjagS0vLx0KeK5XO+pKD1ANNHe/t65q KkBzpR0eUGiqJUJDLniOSMln+1pyuXx/421MSC1YwlF58myxfWCG9aEXqP3MHjTvA5p0 LbfQs7NKpADkKACe7hrC+oXJUaurIyxkW9cuQqL4f8+E4EDgYqNfTDgNB83qUj7cexKO LslOFzHpp/B/lCahVJOA2GAjSALZlC0Sx3Uz9Ltp6lDr7Ev4sc6k20rRgQT0r7eECUxw DnSpSDSfDl9v9K6/tGTVF8Ku+J22ZEuZFGSueEfHz5McO/eiWj/ob+5YSiaX+jbtwaEr TgHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1hCDuhl2K5rTbm/xiu1Ooort4uqtob80E6Lu6z1t2Tk=; b=Eiy+yhx5iSNPESVWZxdCzzqkEKXx/PUVf1ZJp/Gax3ngHRLZiZrrvBX6TuuuAdHy2F 2Uafc6P9eizI+dFakhOPpcabz/b1XmXztO39HMPssEfEwSiJzLEl+8PxBNOI0UVXfHnj OOqFaAOBkJ1HKyzoOplD2Z2rC5PZC2W8TyvT2OonREv4ctwOz9U6B+sVAFBi9q/Lm7Uq DcguTCMoPDtTReW0TdR8U9EpTDZ5AjULdQqUehpmI/hv8FJH1B39KvaHn5Bc/jKtwGT5 V3s/qt+Kq7cVlTByZi2A1XD7hk6l08fHba8g6Vh28JdLuPA9OJ9vy1wTPNoYC6OlAmHC J1pA== X-Gm-Message-State: AOAM531c4ifvTC2nT0Yw9p061UXtja4Piq//lJrKUNTravz6GPoG4Ujm SnwhnCGbnH9YaefoOEsO5Z5sSGTK4/B/aAPAor1uLCts X-Google-Smtp-Source: ABdhPJzNanDYxBGSwAJu9vVoiTuvXQowAtyf9GTaL+ZN7eBtoXPcw7AOIv42wMz2MGk94V+TqjlgwtvEzD/ELBUg8V8= X-Received: by 2002:adf:f507:: with SMTP id q7mr27782885wro.353.1591143210469; Tue, 02 Jun 2020 17:13:30 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> In-Reply-To: <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> From: Seth Blank Date: Tue, 2 Jun 2020 17:13:19 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d8de8205a722e572" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:13:34 -0000 --000000000000d8de8205a722e572 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker wrote: > On 6/2/2020 3:53 PM, Seth Blank wrote: > > The point I was trying to make is that consumers are susceptible to > > fraud, > > Of course they are. Unfortunately, that point is irrelevant, because it > isn't the question at hand. > Dave, this is exactly the point where I think we're on different pages. The From: domain matters because its contents affect user behavior. Unless I'm deeply misunderstanding your earlier posts (and I'm glad to be wrong here), you don't appear to believe this to be true. Alignment matters, because it ensures that the domain which is authenticated matches what the user sees in the inbox (because, rightly or wrongly, inboxes show the contents of the From: header field). When this match fails, a message can be rejected before it's ever in front of a user and capable of causing confusion or fraud. The point is NOT to change user behavior due to what is presented in the From:, it is to prevent manipulation of user behavior by only allowing From: domains to be displayed if they have been authenticated. Your argument seems to be that you don't believe that spoofing the From: domain leads to user impact, or am I completely misunderstanding you? Seth --000000000000d8de8205a722e572 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 2, 2020 at 4:02 PM Dave Crock= er <dcrocker@gma= il.com> wrote:
On 6/2/2020 3:53 PM, Seth Blank wrote:
> The point I was trying to make is that consumers are susceptible=C2=A0= to
> fraud,

Of course they are.=C2=A0 Unfortunately, that point is irrelevant, because = it
isn't the question at hand.

Dave, t= his is exactly the point where I think we're on different pages. The Fr= om: domain matters because its contents affect user behavior. Unless I'= m deeply=C2=A0misunderstanding your earlier posts (and I'm glad to be w= rong here), you don't appear to believe this to be true.

=
Alignment matters, because it ensures that the domain which is a= uthenticated matches what the user sees in the inbox (because, rightly or w= rongly, inboxes show the contents of the From: header field). When this mat= ch fails, a message can be rejected before it's ever in front of a user= and capable of causing confusion or fraud.

The po= int is NOT to change user behavior due to what is presented in the From:, i= t is to prevent manipulation of user behavior by only allowing From: domain= s to be displayed if they have been authenticated.

Your argument seems to be that you don't believe that spoofing the Fro= m: domain leads to user impact, or am I completely misunderstanding you?

Seth
--000000000000d8de8205a722e572-- From nobody Tue Jun 2 17:26:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF743A1153 for ; Tue, 2 Jun 2020 17:26:16 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 Dlqc7paVgsCg for ; Tue, 2 Jun 2020 17:26:14 -0700 (PDT) Received: from mail-oo1-xc41.google.com (mail-oo1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B623A1158 for ; Tue, 2 Jun 2020 17:26:14 -0700 (PDT) Received: by mail-oo1-xc41.google.com with SMTP id q188so159924ooq.4 for ; Tue, 02 Jun 2020 17:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lSDKBTXlh8PxtDawBUFH7S9eh0pYVb23d7kwhahfhtI=; b=WUiZUGE0SpPx5Tf6d+oC8+u1O7W2uz8KGAIPgzkosj8W6xNBbEMXEw04gtF5dXwrab 3b/FoibKsrzN6i4pWdux+oWD8CeDcrKcqHs8STU8ScnrERdeRKnEgv5uBuKJ4dHmwQus /809uWmIgQ/Yn2qF+G1/mFx0IeXwdcc5y4T2g5+/joBU0OfWT4vlLdGBICLkBhzxYCGC Kn4F/zogg0UsqzPFn5+Mndx1cyHrxlG5FEmoSfGxNuAzxONi3/7Em7W3hTMNlOKAf+EN nMHyZTjJLbH4as3GNmRhLeLu1AvEQOXRhX6ScXyNQqmy17GIxbZfKOQ1USri0vIAqFdr 2UZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lSDKBTXlh8PxtDawBUFH7S9eh0pYVb23d7kwhahfhtI=; b=S+FcQkOUri2SvBc52PoUSiPkkU741n8W2QdhFVvKPJ1vTMrxA/gAGsl4SJlABteEyU CbMXuqyvjZ7LUzKvjTDOhMcc3cp1ZdNnT2aM881In+ipvxFfZ3tQKP5/m8AokrP6a6YL wkxNJjie5uRMkxjxD2DkpHXMSe5DTPxjQTPkeWgsjhRHnXAk3fwxSl+CIVn3OmJx/64N dmGky9/+5zevEaPy8/gT07dLCNAbnA6XID7P0WW0Hw0D6CL0t833O9ROWATb8oLGGvwh mEbFdmc6ZFIPhwUFIZnZCAQP2Pb7Z7qqMkbkcGQBmUdczSupyMSPlDi5bo5R+ple8hnf gylw== X-Gm-Message-State: AOAM531ImeO6tu6ADaG5W0vm0z4OiGwFsXJrZE673LFDHPPcckz8gCam W5u80UiI7Sp1ApCwmIINStKgzzup X-Google-Smtp-Source: ABdhPJyYys2368x8IvihMCGvDBI0NLD08TGBSC7Vhf55qLIeUukFBWxSN01N2tfsqECsxEXVrLuWHw== X-Received: by 2002:a4a:a20b:: with SMTP id m11mr5143088ool.20.1591143973579; Tue, 02 Jun 2020 17:26:13 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id v79sm187380oia.29.2020.06.02.17.26.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 17:26:13 -0700 (PDT) To: Seth Blank , "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> From: Dave Crocker Message-ID: Date: Tue, 2 Jun 2020 17:26:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AEFAF190710CF62CA2D9B892" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:26:17 -0000 This is a multi-part message in MIME format. --------------AEFAF190710CF62CA2D9B892 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/2/2020 5:13 PM, Seth Blank wrote: > On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker > wrote: > > On 6/2/2020 3:53 PM, Seth Blank wrote: > > The point I was trying to make is that consumers are susceptible to > > fraud, > > Of course they are.  Unfortunately, that point is irrelevant, > because it > isn't the question at hand. > > > Dave, this is exactly the point where I think we're on different > pages. The From: domain matters because its contents affect user > behavior. Apparently I wasn't simple enough, so let's reduce this to the absurd reality that typically applies:      If a user doesn't see it, how can it affect their behavior? > Alignment matters, because it ensures that the domain which is > authenticated matches what the user sees in the inbox (because, > rightly or wrongly, inboxes show the contents of the From: header field). Except that most users don't see the From: domain name. > When this match fails, a message can be rejected before it's ever in > front of a user and capable of causing confusion or fraud. Exactly.  What matters is that unalignment is presumed to demonstrate bad faith by the originator.  THAT is what significant.  And it's significant to the filtering engine, not the recipient user. > > The point is NOT to change user behavior due to what is presented in > the From:, it is to prevent manipulation of user behavior by only > allowing From: domains to be displayed if they have been authenticated. Yeah, but that's quite different from saying that a user who sees a bad from: field is manipulated. > > Your argument seems to be that you don't believe that spoofing the > From: domain leads to user impact, or am I completely misunderstanding > you? Where is the clear and credible research data that says that a bad From: field domain name specifically tricks end users? d/ > -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------AEFAF190710CF62CA2D9B892 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/2/2020 5:13 PM, Seth Blank wrote:
On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 6/2/2020 3:53 PM, Seth Blank wrote:
> The point I was trying to make is that consumers are susceptible to
> fraud,

Of course they are.  Unfortunately, that point is irrelevant, because it
isn't the question at hand.

Dave, this is exactly the point where I think we're on different pages. The From: domain matters because its contents affect user behavior.

Apparently I wasn't simple enough, so let's reduce this to the absurd reality that typically applies:

     If a user doesn't see it, how can it affect their behavior?


Alignment matters, because it ensures that the domain which is authenticated matches what the user sees in the inbox (because, rightly or wrongly, inboxes show the contents of the From: header field).

Except that most users don't see the From: domain name.


When this match fails, a message can be rejected before it's ever in front of a user and capable of causing confusion or fraud.

Exactly.  What matters is that unalignment is presumed to demonstrate bad faith by the originator.  THAT is what significant.  And it's significant to the filtering engine, not the recipient user.



The point is NOT to change user behavior due to what is presented in the From:, it is to prevent manipulation of user behavior by only allowing From: domains to be displayed if they have been authenticated.

Yeah, but that's quite different from saying that a user who sees a bad from: field is manipulated.



Your argument seems to be that you don't believe that spoofing the From: domain leads to user impact, or am I completely misunderstanding you?

Where is the clear and credible research data that says that a bad From: field domain name specifically tricks end users?

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------AEFAF190710CF62CA2D9B892-- From nobody Tue Jun 2 17:46:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797273A135D for ; Tue, 2 Jun 2020 17:46:32 -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=valimail.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 VTre1TpNhhMr for ; Tue, 2 Jun 2020 17:46:30 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 B24C83A1227 for ; Tue, 2 Jun 2020 17:46:04 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id q11so495480wrp.3 for ; Tue, 02 Jun 2020 17:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g77mE1x0WAdHVrrzRndzhko3s9cTvrmURJ10QTSOmJM=; b=Ee0nXnv3gZKvrMT4PVVR1oaHW1eOwa538iY8fgjLdwpIqnzTIZFx54f4bfvkI+Okgb wci3fkGfHAoYs3D50vij1R1P57DJ3DDHfME+3tFiQ+rtbTJNva1GxOGIxcQP/JT3ziMy bUI8koXSuW3+nDrYfbBzcaPjhKxnIGIqzJzUxnfcJd9QIGg6mDHjLbgd3HXHLORZNc3p 8oa4cK+SPistqLObaUXQoUcxGzO6EoTOv0M3n1BazngWrDcDD9l+8zFEBJ/5CUs6zhKi qoK78i/+umurNT+GgkEKSzyuTcOcvmRCaeVRK6jRAD7O1HQXP1qpYjmToYpqmWbhcWUS 6E2Q== 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=g77mE1x0WAdHVrrzRndzhko3s9cTvrmURJ10QTSOmJM=; b=hlx4vNo7mGLfJl4CcmLCMiwvOgVX3BQ2zGeBwU07STRY2K+nZA8Y9/vNtKaZLRSZfn JcPmODkp8lFsw6SPmtQyYxPwG6nCE1kljptQbIqb1PPu5Xkl77DLeC1qgHjKAe3mNdc9 nBIEWDic+I0+Umfb/h3hCbuSrb1bgREVX954e5U0xAaWiIJ6P4tl3maw7JLTnM4apPTH B/Evmy3lHj8gvi8yz9+aQfc0DuwZ8HnxV9gaF5jqjW/wfzLEQTVPllawl80qXZ49mXyV R3lZwVNZ80K+ezija6RkxBdiDQLhMvm5EOgKlN00X5+t5DEb2yeUPnVdPrQQ5BBQGscd xI3g== X-Gm-Message-State: AOAM532KbxV7HGmZbZklwx7l5Dn8rfXb27oJebwPMKrUfrTufJDAWFKq 3IUQ66YKzd9fWv5KhgwYn4hHJF7TC8zTrhaVwq4oGA== X-Google-Smtp-Source: ABdhPJzPc6Qq9KjlWyGCl6AzbS2Y+xsjsjdGx9tth7h+fG9QplXC9G43ZYkSItvtJkzuJaOD8NkDC5PW+nUSSjrtjes= X-Received: by 2002:a05:6000:7:: with SMTP id h7mr30791181wrx.55.1591145158036; Tue, 02 Jun 2020 17:45:58 -0700 (PDT) MIME-Version: 1.0 References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> In-Reply-To: From: Seth Blank Date: Tue, 2 Jun 2020 17:45:47 -0700 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ee6b2505a7235955" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:46:33 -0000 --000000000000ee6b2505a7235955 Content-Type: text/plain; charset="UTF-8" Thanks for bearing with me, Dave. On Tue, Jun 2, 2020 at 5:26 PM Dave Crocker wrote: > When this match fails, a message can be rejected before it's ever in front > of a user and capable of causing confusion or fraud. > > Exactly. What matters is that unalignment is presumed to demonstrate bad > faith by the originator. THAT is what significant. And it's significant > to the filtering engine, not the recipient user. > Yes, we're agreed 100% here. > Your argument seems to be that you don't believe that spoofing the From: > domain leads to user impact, or am I completely misunderstanding you? > > Where is the clear and credible research data that says that a bad From: > field domain name specifically tricks end users? > There's a lot of clear and generally consistent data that shows From: header field spoofing leads to outsized impact on end users. However, if by "credible" you mean peer reviewed and not presented by someone with something to sell in preventing the problem, that may be missing (although, it only tends to be systems with a part to play in preventing abuse that are even capable of seeing and distinguishing the issues) and could be an interesting independent study to run. Seth --000000000000ee6b2505a7235955 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for bearing with me, Dave.

On Tue, Jun 2, 2020 at 5:26 PM Dave Crocker &= lt;dcrocker@gmail.com> wrote:<= br>
=20 =20 =20
<= div>When this match fails, a message can be rejected before it's ever in front of a user and capable of causing confusion or fraud.

Exactly.=C2=A0 What matters is that unalignment is presumed to demonstrate bad faith by the originator.=C2=A0 THAT is what significant.=C2=A0 And it's significant to the filtering engine, = not the recipient user.


Yes, we= 're agreed 100% here.
=C2=A0
Your argument seems to be that you don't believe that spoofing the From: domain leads to user impact, or am I completely misunderstanding you?

Where is the clear and credible research data that says that a bad From: field domain name specifically tricks end users?

<= /blockquote>

There's a lot of clear and genera= lly consistent data that shows From: header field spoofing leads to outsize= d impact on end users. However, if by "credible" you mean peer re= viewed and not presented by someone with something to sell in preventing th= e problem, that may be missing (although, it only tends to be systems with = a part to play in preventing abuse that are even capable of seeing and dist= inguishing the issues) and could be an interesting independent study to run= .

Seth

--000000000000ee6b2505a7235955-- From btv1==423bcad6c17==fosterd@bayviewphysicians.com Tue Jun 2 17:46:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F03A127E for ; Tue, 2 Jun 2020 17:46:30 -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 (1024-bit key) header.d=bayviewphysicians.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 3UlWe3MJP27W for ; Tue, 2 Jun 2020 17:46:28 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4BD3A12CE for ; Tue, 2 Jun 2020 17:46:03 -0700 (PDT) X-ASG-Debug-ID: 1591145161-11fa313a10327e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id lD8tLMRDX85U33aa (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 02 Jun 2020 20:46:01 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=agzmaKpSJJjb+tU7SdFTn87b8LLHYtuEDilYItaxSTg=; b=eXT9XbZXjE9ctVo9WpGSmcBYfdS/emF7lTQbozYY8n0lLz2/yLISlM3Z5R+/2phlj 1x9/B2K/h+sspo6sTdrUZbn0482JbVMN4ndf4zCs3z+ZAGT97U+c0bv3PE3JKR6jc rEy5tn4/x6E0OqF5SoOWBho+71BHoWo1A4retY9zs= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Wed, 03 Jun 2020 00:45:54 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D Reply-To: fosterd@bayviewphysicians.com Message-ID: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=4353dc829513428eae66903a0d7a8403 X-Exim-Id: 215ef4b3387e4cf79d4512dcb60c83f4 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1591145161 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 7246 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82285 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:50:03 -0000 This is a multipart message in MIME format. --4353dc829513428eae66903a0d7a8403 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don't understand why this topic is debatable. We are faced with a constant stream of mail which we do not want. We need t= o block the nuisance stuff as well as the dangerous stuff, so that the impo= rtant stuff gets processed in a timely manner, and so that our labor effort= s can be spent on things more productive than reading nuisance emails. Ergo= , if a message contains a lie, I want to block it. If the identifier is a l= ie, the content will not be any better. IETF settled on standards for filte= ring identifiers because it is simply more feasible than filtering free-for= m text. As to consequences: Was no one present during the 2016 election cycle, when= a phony GMAIL password reset compromised a U.S. Presidential campaign? I'l= l admit that I have not seen that specific message's From header, but suppo= sedly it convinced John Podesta and his I.T. person, so I am pretty confide= nt the From domain was "@gmail.com", not SstealYourData@BadGuys.R.US" Someone said that the Sender Address is all we can trust. Nonsense. The onl= y thing that is "true" in an email header is the IP Address, and that is tr= ue only if the recipient assumes that no nation state has a NAT-translating= device in front of their internet connection. Everything else can and will= be fraudulent at times. As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my= understanding, to represent the login account used to create the message, = while the RFC 5322 From Header represents the "speaker", the person whose i= deas are being represented by the content. It matters if someone puts words= in someone else's mouth, and From fraud is exactly that type of fraud. It is reasonable to require senders to demonstrate authority to speak on be= half of someone else. DMARC provides two ways to demonstrate that authority= : if there is domain alignment, the implication is that the security enviro= nment of the sender domain has chosen to allow one sender to act as agent f= or another, because it would be in their power to prevent him from doing so= . Therefore intra-domain agency is not a significant concern to the recipie= nt. However, when the sender address (login account) represents a different= security domain than the sender address, the recipient has no reason to ig= nore the discrepancy. The DKIM signature is the alternative credential whic= h demonstrates authority to send on behalf of the From address entity.. I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibi= ts authorship, or creates any other attribution problem. This assertion was= simply not explained. Feel free to do this test to see if From address matters: Start sending inf= lammatory stuff with a From address @WHITEHOUSE.GOV to major news organizat= ions or foreign governments around the world. See how long it takes the Sec= ret Service to pay you a visit. As to visibility: The business world still runs on Microsoft Outlook, and O= utlook presents the From Address when a message is read. So it is odd to as= sert that no one ever sees that data. The real scandal is that the Sender A= ddress is never displayed. It would be very interesting if MUAs would say From: Marketing@BigRetailer.Com by: BigRetailer@MassMailer.com Whose ideas was it to keep the sender secret? If the integrity of identifiers does not matter, why are we here? Doug Foster --4353dc829513428eae66903a0d7a8403 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I don't understand= why this topic is debatable.

We are faced with a = constant stream of mail which we do not want. We need to block the nuisance= stuff as well as the dangerous stuff, so that the important stuff gets pro= cessed in a timely manner, and so that our labor efforts can be spent on th= ings more productive than reading nuisance emails. Ergo, if a message conta= ins a lie, I want to block it. If the identifier is a lie, the content will= not be any better. IETF settled on standards for filtering identifiers bec= ause it is simply more feasible than filtering free-form text.
As to consequences: Was no one present during the 2016 electio= n cycle, when a phony GMAIL password reset compromised a U.S. Presidential = campaign? I'll admit that I have not seen that specific message's From head= er, but supposedly it convinced John Podesta and his I.T. person, so I am p= retty confident the From domain was "@gmail.com", not SstealYourData@BadGuy= s.R.US"

Someone said that the Sender Address is al= l we can trust. Nonsense. The only thing that is "true" in an email header = is the IP Address, and that is true only if the recipient assumes that no n= ation state has a NAT-translating device in front of their internet connect= ion. Everything else can and will be fraudulent at times.

As to identifiers: The RFC 5321 MAILFROM sender is intended, at lea= st in my understanding, to represent the login account used to create the m= essage, while the RFC 5322 From Header represents the "speaker", the person= whose ideas are being represented by the content. It matters if someone pu= ts words in someone else's mouth, and From fraud is exactly that type of fr= aud.

It is reasonable to require senders to demons= trate authority to speak on behalf of someone else. DMARC provides two ways= to demonstrate that authority: if there is domain alignment, the implicati= on is that the security environment of the sender domain has chosen to allo= w one sender to act as agent for another, because it would be in their powe= r to prevent him from doing so. Therefore intra-domain agency is not a sign= ificant concern to the recipient. However, when the sender address (login a= ccount) represents a different security domain than the sender address, the= recipient has no reason to ignore the discrepancy. The DKIM signature is t= he alternative credential which demonstrates authority to send on behalf of= the From address entity..

I simply cannot grasp h= ow DMARC conflicts with RFC 5321 or RFC 5322, inhibits authorship, or creat= es any other attribution problem. This assertion was simply not explained.<= /div>

Feel free to do this test to see if From address m= atters: Start sending inflammatory stuff with a From address @WHITEHOUSE.GO= V to major news organizations or foreign governments around the world. See = how long it takes the Secret Service to pay you a visit.

As to visibility: The business world still runs on Microsoft Outlook= , and Outlook presents the From Address when a message is read. So it is od= d to assert that no one ever sees that data. The real scandal is that the S= ender Address is never displayed. It would be very interesting if MUAs woul= d say
Whose ideas was it to keep the s= ender secret?

If the integrity of identifiers does= not matter, why are we here?

Doug Foster


--4353dc829513428eae66903a0d7a8403-- From nobody Tue Jun 2 17:57:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372923A1185 for ; Tue, 2 Jun 2020 17:57:32 -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, FREEMAIL_FROM=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=gmail.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 QNg4R-_YdlSd for ; Tue, 2 Jun 2020 17:57:31 -0700 (PDT) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 EE79D3A1095 for ; Tue, 2 Jun 2020 17:57:30 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id x202so236965oix.11 for ; Tue, 02 Jun 2020 17:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=p3nAPt6hQW+HZEmt5XfdbP6tDU2CA0O+QmaBO++gbZk=; b=q5ptlF73uGK5/li+FKcclB6TU3+o/LBGtTqZSr+xlULpKWsiCL3vHGKgzg8GqD4d44 Ve74raNRMsJ6HB95m9uZOen83/PLF2B7adNiQoIZJyXvFzPhgb4mFpAIUPFRnzSLwTnF 3bPsYcwKtFoHJGwjDnuw97GUoFG5T+WkWn+Vn6Ov5IMSWtabALcy+PSK6dn4qgDxtkIF 6RGts+ofZQCoSiQU/qMxAbtNykHeh2APBW7WDPEmp2W1WJvtOCvi48RRCqU+HfaFnPfD eN7Wn2B8Z6Zu6jmkXAErQx0XZiqnpn2uysynWhTmYqkov7xlLTxamSZTIq0OEdvcxm7s l46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=p3nAPt6hQW+HZEmt5XfdbP6tDU2CA0O+QmaBO++gbZk=; b=e+GMnIvcF1MIlfro+h35PFEmoIGfB3cBm/B8mPXbZoPgDxjs4cU2TScEKZbjdkxrmj 3FOx/BURxM0YxF/YdEYjkIsW1C0wI0GmtvZn9/DGsco55Z65FmBcErUiSM4lmdSyKAit ak2idNk7lrN9IT1QhyDbVfGmxHHEG3iSXFCr71nrxDATb1IQrMsh/6RjVxF9MwWKu9wp EVRUtZHj0UhLlvzVTabwHO5K+1RRXnKaC4fperUB8Pge+feL2XCANIzWn+BHbwTTmyN6 6NamKNqecQEKlzUUqljmZOpmRZTYza1VLDLJnJTI4ZLHpx/Ivs6b+pCfJ6gq5JLxIX/3 2qLA== X-Gm-Message-State: AOAM5306oqPtdk8lYy+2Zp1Z7ephFG47wKsdJ207j0SAnuV7boJFfieH vgpVDKNvIJTMdnnKOWvZcomlXfit X-Google-Smtp-Source: ABdhPJzlcBiVwzF4+ljptLpOkD5Q60GteCcjkG7/K8Dw3evT41rQLoFsPoGLvI2kdu5iF4D2lXK/tA== X-Received: by 2002:aca:b842:: with SMTP id i63mr4454290oif.169.1591145848752; Tue, 02 Jun 2020 17:57:28 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77? ([2600:1700:a3a0:4c80:74d5:2e17:a5f6:1e77]) by smtp.gmail.com with ESMTPSA id m26sm143172otl.30.2020.06.02.17.57.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 17:57:28 -0700 (PDT) To: Seth Blank Cc: "dmarc@ietf.org" References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <1093905c-7556-ab65-ae9f-6c97d1707878@gmail.com> <150bd1d9-dc9c-8183-308f-5e251caeac74@gmail.com> From: Dave Crocker Message-ID: <25f91ea0-cb97-97bb-b1b3-d34c54b887f4@gmail.com> Date: Tue, 2 Jun 2020 17:57:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:57:32 -0000 On 6/2/2020 5:45 PM, Seth Blank wrote: > There's a lot of clear and generally consistent data that shows From: > header field spoofing leads to outsized impact on end users. Odd that I've never seen it.  Odd that it didn't surface during the literature search that was done when BIMI was started. Again:  Please point to work that is specific to this issue and, just in case it is part of a larger tome, please point to the specific place in the document that is relevant to this issue. > However, if by "credible" you mean peer reviewed and not presented by > someone with something to sell in preventing the problem, that may be > missing (although, it only tends to be systems with a part to play in > preventing abuse that are even capable of seeing and distinguishing > the issues) and could be an interesting independent study to run. People with something to sell often do serious research.  And they often document it.  But this is quite different from marketing literature or hallway discussion.  I'm asking to see the research writeups.  (I made that plural since you are so firm in saying there is lots of supporting research.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 3 09:38:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6F3A0906 for ; Wed, 3 Jun 2020 09:38:05 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 l6Zt7S1hEAt6 for ; Wed, 3 Jun 2020 09:38:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 59D003A08FB for ; Wed, 3 Jun 2020 09:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591202281; bh=YdGYFIoyRRHl4T1R60wyW8zCpDBYXpeCUNkBCh57CZE=; l=1871; h=To:References:From:Date:In-Reply-To; b=BTPcrlqinTS5dlPBnI5DwpAsMvmxD5UZKbofePwmoN6vRlkLv13vmwEq3FJiI03Sj oFjF9NVGKS7pttwBWNTGSvwPN5hPtq/CZTNgTUimz0HYKg0xUGdBqQaico8q4huefG vn4iE9Gp+FbHwpmKH/Lqs/Iy3irt+Lnn+P8wHyRyXf31jQOy0PlAdQ7HU43Hq Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005ED7D1E9.00001582; Wed, 03 Jun 2020 18:38:01 +0200 To: dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> From: Alessandro Vesely Message-ID: Date: Wed, 3 Jun 2020 18:38:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:38:06 -0000 On Tue 02/Jun/2020 19:00:55 +0200 Dave Crocker wrote: > On 6/2/2020 9:44 AM, Jesse Thompson wrote: >> I'm relaying these DMARC questions/concerns on behalf of an email admin at >> another university.  [...] >> >> " >> I don't see on the list of issues the most fundamental problem of DMARC, >> namely that it conflicts with RFC 5322 on the use of the From and Sender >> header fields [1] and possibly with RFC 6326 as to the significance of DKIM >> fail [2].  The former is the more serious problem. Making DMARC alignment >> part of a standard for Internet messages requires a revision of RFC 5322. I'd >> love to see this resolved. > > [...] > > DMARC enforcement requires that the DKIM/SPF domain be the same as the author > From:.  That is, the folk doing email operations have to be able to sign the > DMARC aligned domain. > > Hence the From: field is now really the Sender: field.  The From: field fixup > hacks that are needed by intermediaries, to avoid DMARC-based rejections, makes > this fact painfully clear, even as they serve to undermine recipient use of the > From field for author-related message management. > > [...] > > The only suggestion I've been able to formulate is:  create a new field, such > as Author:. +1, that's the proper way to fix the issue Jesse relayed. Re-senders who rewrite From: should copy its value to Author: unless such field is already present. MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. > (Give it a simple, clean, appropriate name, rather than something like > Original-From.) Yes, and let's note that the issue is so fundamental that solving it also solves the long-standing problem of how to standardiz mailing lists behavior with DMARC. Best Ale -- From nobody Wed Jun 3 09:43:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7623A0AD9 for ; Wed, 3 Jun 2020 09:43:23 -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, FREEMAIL_FROM=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=gmail.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 7-6Cp6aZdhcb for ; Wed, 3 Jun 2020 09:43:22 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 A079D3A0AD7 for ; Wed, 3 Jun 2020 09:43:22 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id 25so1464395oiy.13 for ; Wed, 03 Jun 2020 09:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GquJGkTd9YnjcNxsP84rrZNJtn13ItBTuZnqmxtgEGM=; b=PM9WH2SPinSW7KU4SqBkcGezWgKctAiRYZqFC7MCsx0wPuiabbDcw8yu2Oo5/HcBbx HXZqphzYYZzbJdSFy9e7hDpUWzaZUoFGavyk8AjGXoSTyulP6WP4l2s60iN38c1TZeDr gwM61r51ZhKvOnBEA7nRsTBRgtDGnhNoSheuReYiWPapJ2svGKlx9A9Bxtmctmd7j631 /QqFIyC314ilQDjgXVc5chS4dSGePzP5xh1C1rcIAxFfKoq2r6g4c6DkCmQzofPYjs/M OyZCrqu39lklOXNKjBrYK0Ls/YQUe8ol8PHw5fWj+6uR5OhDK/yGdpmwV/M9liv/bVE1 vC+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GquJGkTd9YnjcNxsP84rrZNJtn13ItBTuZnqmxtgEGM=; b=Y30nZx4tRu2qDtJEypPDohdmOo77cD/ZXAkDdAHgrJQDEglUmV9JO6XZTtk7wkpSIq PitFa3RaG5fy5rLZ1TADTwd+JBpwxY2whOGN5SVpFLlgZ/0UzjhlELsttVyKS3HxNr+p kDRj0gxfdxK/mT4Tf/ZoYoRn/ptXc4GEvYtS4hJHa7ibzf59A6G6tnxZk20C3j3mOpsu DtdVNGtJ13fkYeB48IBlYpF8J+RgkWJX11vDZnPfpeZQ5vA6h88Mn0p+p2frhj4Zm4Z3 vdgt8i4UDJM+cd1GF+ISfCQpvFVwnbiA54zeU1bNIJQudTB/bgR5ELiP58WS5ocy8pRm YKZw== X-Gm-Message-State: AOAM531v41oHTBj8vdd3eNEFBH302imcfNuefiQmpumKpK8kDNAO06yN YCMe9yC84QU55ppAk5pEFLXSiRMe X-Google-Smtp-Source: ABdhPJzO6qBRKSvqsHIkWhLKI1wqa+B79OAf0ygiZ4A+T+0Fe5jQeQvamLblXrP4fEwPnJnS/iLXpQ== X-Received: by 2002:aca:2108:: with SMTP id 8mr461169oiz.10.1591202600217; Wed, 03 Jun 2020 09:43:20 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:a98b:b45f:bb45:5051? ([2600:1700:a3a0:4c80:a98b:b45f:bb45:5051]) by smtp.gmail.com with ESMTPSA id g10sm597487otn.34.2020.06.03.09.43.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 09:43:19 -0700 (PDT) To: Alessandro Vesely References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> Cc: dmarc@ietf.org From: Dave Crocker Message-ID: <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> Date: Wed, 3 Jun 2020 09:43:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:43:24 -0000 On 6/3/2020 9:38 AM, Alessandro Vesely wrote: > MUAs should be discouraged from displaying or using Author:, unless > (verifiably) signed by a trusted domain or otherwise configured by the user. Why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 3 10:20:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B73A0CF4 for ; Wed, 3 Jun 2020 10:20:42 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 tyRFh8hRA-5F for ; Wed, 3 Jun 2020 10:20:41 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 EB42A3A0CB8 for ; Wed, 3 Jun 2020 10:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591204837; bh=ABYSET0h5YWtPfbzGVPggyuPO3Q8eaZfJR2ioHV0IK0=; l=719; h=To:Cc:References:From:Date:In-Reply-To; b=BTsaGrAPtW+tf5MAc2yd/0rOfG5IZjYNcMTEPDH7EN+okn+7M5Eb2EC9CwYfbYJyK uyWu6o6TmRjuotTt8LiFljxTyMxPccedDvz9VMfy7YJy2zKWbXz2RUZd/EHrL5jj9j L6S3ippKkjDslKTLKi1yERbsqgqL6pnfUpk2/fipFecmPLDN92FBepVFVu5BP Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005ED7DBE4.00001A8E; Wed, 03 Jun 2020 19:20:36 +0200 To: Dave Crocker Cc: dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> From: Alessandro Vesely Message-ID: <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> Date: Wed, 3 Jun 2020 19:20:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 17:20:50 -0000 On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: > On 6/3/2020 9:38 AM, Alessandro Vesely wrote: >> MUAs should be discouraged from displaying or using Author:, unless >> (verifiably) signed by a trusted domain or otherwise configured by the user. > > Why? That avoids the dreaded back-to-square-one path that Brandon conjectured. It prevents attacks based on this field, while maintaining the DMARC paradigm. I, for example, would configure to display Author: in the listing of [dmarc-ietf] and similar folders. Reply-to-Author would also be a useful button, if not abused. It's fine to fulfill advanced users' wishes as long as average user behavior is not forced to change. Best Ale -- From nobody Wed Jun 3 10:28:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF423A0C3B for ; Wed, 3 Jun 2020 10:27:59 -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, FREEMAIL_FROM=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=gmail.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 AL8qqAG61n3m for ; Wed, 3 Jun 2020 10:27:58 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 987513A0C38 for ; Wed, 3 Jun 2020 10:27:58 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id a21so2506837oic.8 for ; Wed, 03 Jun 2020 10:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cHEKaIGPEN07jkWUxFblBRe0Q/Tc1qa9I5XmsMKNPfY=; b=IirX3kkvtFKhLZxZdgX3Y/fgXSpJ2V5h4TSvRrGDwygaMn2tbSZ/3Wd7rD54/RadS3 ZOyOam6nWp7RgQ2HuYMawBhRxn9ZJ9Cmd6Mp1+tvWdPvsS20alet/DaGareTspbcNxfn wSdTJZTTpPdRNx4zA/nTq/RIwQTo5KTS1XQt10axN8hhdvAd59aaAC//D0xDnGdScuKk ncqi+PgqtwkAuV6cdwxQoAfg+7RLgFUt67hBpqSBERDzv+1VaC1oWwsM6hxvC5WUa8es Vf2e324AGe8x/CgcWu1fMc22jBoV+md5gArnyAaBxnQzbAInj01mbm0re1o8DP6Hw8oy uEyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cHEKaIGPEN07jkWUxFblBRe0Q/Tc1qa9I5XmsMKNPfY=; b=l7khiuKihpmmqhJgy0gfy+gYekTTvW6sp71tmR649SaW1o9m4UqEibpl0XJbUrVy3O XkRToqn4cN6cla5MI6GbHjLMhxaAvBS5PmPQXAp5gnN4sikzEq11va9Ef8+UHBUViprQ 1ibhQxIXgCB9qjHQ47laMV7TubJDmVaQHeibqPasz5Nr+KZb0nFgDzEwnaT288CwzACf mOuA7mAAMGCEf2DsWzUvfvt3c/9L5UZrwo3MBC3ynepWu63R3BJzh5sqokhmtmz/XyXe 419Qir8lcqCkTJK8TQKydhcdQxSfTvplqdeJdY5+TxV+RzRzTj2wifyUsVSIKKfiqf2N HX9Q== X-Gm-Message-State: AOAM53050IiQ/2BuyFSV5VEdibcKJOnn6aWTonyS/a8fPUvBp3i1FiFH lwef4qMXBlxC6j1oT151N38J90H6 X-Google-Smtp-Source: ABdhPJyMnjKdjR6ssw/yQ6/8ZB/ZZ+6iFsGQhxKh9gV9NDKm5g9rGR0cp0tQIFexw2J5eFoJwgO09w== X-Received: by 2002:aca:cf4c:: with SMTP id f73mr509261oig.165.1591205276643; Wed, 03 Jun 2020 10:27:56 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:a98b:b45f:bb45:5051? ([2600:1700:a3a0:4c80:a98b:b45f:bb45:5051]) by smtp.gmail.com with ESMTPSA id a17sm622656otj.46.2020.06.03.10.27.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 10:27:56 -0700 (PDT) To: Alessandro Vesely Cc: dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> From: Dave Crocker Message-ID: <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> Date: Wed, 3 Jun 2020 10:27:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 17:28:00 -0000 On 6/3/2020 10:20 AM, Alessandro Vesely wrote: > On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: >> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: >>> MUAs should be discouraged from displaying or using Author:, unless >>> (verifiably) signed by a trusted domain or otherwise configured by the user. >> Why? > That avoids the dreaded back-to-square-one path that Brandon conjectured. It > prevents attacks based on this field, while maintaining the DMARC paradigm. The barrier you specified sounds reasonable.  But it isn't. Any signature put in place when the Author: field is created is likely broken by the time it gets to the recipient.  That's the entire problem that necessitates rewriting the From: field. We do not require 'signatures' on Subject: or the Body or Date:. This is just one more field. The concern about square one is misguided, apparently mostly because it continues the erroneous belief that the validation work is done for the end user, rather than the filtering engine. Besides that, it ignores the fact that authentication mechanisms are presumably still in place. Users are tricked by the content of the message, not by the From: (or Author:) field. On the other hand, a clean From: (or Author:) field enables consistent MUA organizing of messages.  Messing with the From: (or Author:) field by intermediaries defeats that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 3 11:31:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27F73A110B for ; Wed, 3 Jun 2020 11:31:16 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 kkbMvH_PUwuE for ; Wed, 3 Jun 2020 11:31:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E746B3A0EEF for ; Wed, 3 Jun 2020 11:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591209038; bh=/ViVwrxnWcyKi/7JNUUNjq4pyJsdl7dJ2v8HvsFq+LY=; l=3174; h=To:Cc:References:From:Date:In-Reply-To; b=A2xxdEJamA5Jc1A8JUy1Sx0xYFyOvWKzr8LCfCSpRcJWe47FUSSupleF7pELh9c8H QPgDNl02FYiLsEE9xC83jP2jlLagCzMghbV+UssICjaOgZiN2G8knaDhWmtq+SkRUV JtE5NSZCvNMRCGElrR6/ixpWwj1k1ZUMqdbIQgs7vmV43x8jS6PLFjrLMdmDu Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005ED7EC4E.0000215D; Wed, 03 Jun 2020 20:30:38 +0200 To: Dave Crocker Cc: dmarc@ietf.org References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> From: Alessandro Vesely Message-ID: Date: Wed, 3 Jun 2020 20:30:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 18:31:23 -0000 On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: >>>> MUAs should be discouraged from displaying or using Author:, unless >>>> (verifiably) signed by a trusted domain or otherwise configured by the user. >>> Why? >> That avoids the dreaded back-to-square-one path that Brandon conjectured.  It >> prevents attacks based on this field, while maintaining the DMARC paradigm. > > The barrier you specified sounds reasonable.  But it isn't. > > Any signature put in place when the Author: field is created is likely broken > by the time it gets to the recipient.  That's the entire problem that > necessitates rewriting the From: field. That depends on who creates the Author: field. I'd imagine it can be created on rewriting From:. If it exists already at that time, one can still check (by ARC?) if it was signed, and, in case, sign it in turn. > We do not require 'signatures' on Subject: or the Body or Date:. This is just > one more field. Right. To sign Author: wouldn't be a DKIM or DMARC rule. It's just a hint for MUAs. Rather than thoughtless treating Author: as From: by default, do some serious checking and/or trust user settings. > The concern about square one is misguided, apparently mostly because it > continues the erroneous belief that the validation work is done for the end > user, rather than the filtering engine. Besides that, it ignores the fact that > authentication mechanisms are presumably still in place. Some authentication results are displayed to the end user. They are important in edge cases. > Users are tricked by the content of the message, not by the From: (or Author:) > field. The content is only seen if the message is opened. In the message listing I only see the display name. So, it is important that the display name comes from a trusted field. That is to say, from From:, at least in the default configuration. When the message is open, on edge cases the user should first look at the authentication results, which shows the domain name on a decent MUA. > On the other hand, a clean From: (or Author:) field enables consistent MUA > organizing of messages.  Messing with the From: (or Author:) field by > intermediaries defeats that. Intermediaries already mess up when they rewrite the From:. Adding an Author: allows that mess to be partially undone. Experience seems to indicate that mailing list software reacts more quickly than MUAs. MUAs will not add an Author: field any time soon, especially if it has to be a copy of From:, with zero added information. And then an Author: field is only needed by mailing lists and similar minorities, when the From: is rewritten. Recall DMARC was adopted because the amount of such traffic is negligible. In addition, I'd dare hypothesize that users who subscribe to mailing lists are more skilled than average (?) They should be able to configure a MUA to deviate from the "safe" behavior in certain cases. Best Ale -- From nobody Wed Jun 3 20:04:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639413A0E39 for ; Wed, 3 Jun 2020 20:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Z6KnkGIs; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=poSN/Kfo 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 GMeQS2b6QvGD for ; Wed, 3 Jun 2020 20:04:24 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) (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 2B10F3A0E36 for ; Wed, 3 Jun 2020 20:04:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=451; t=1591239857; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=oP/W8HoUHECwJ8bC/jLxH3PUAgI=; b=Z6KnkGIsDahLBhTmHkSJ7Me7SjTuMi2Z/HXJQJKrru6l2+MtxudYMGBHwOw/tt ourS1ivLbb4M29ABXXadUe9CpyWdJ7KIh5+aJcM3kkg6YB6ZjFmjTYFi1SQRfVzw +D/x7rfx9zHmXnYsmuWFrTsRx+s1G6jPceEdAwDRPaqOc= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 03 Jun 2020 23:04:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1967171325.13385.1940; Wed, 03 Jun 2020 23:04:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=451; t=1591239830; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vCATinw L2dHpUSRpaY92AhkdEoJDP01f2nTwFI2zVuY=; b=poSN/KfoX4i4aXgECx4sc2M bu6Py+aFx9IUJyUAAwECiUJZFnGWx+uxzgki0h4l7k8sZDehmHjLq9RGWAUelHlV 82ioHyjMtK6ev5K8ke0SG1/WebwRnA8+FOvrMsrbOR8mLahT/69aOEUeCtUTDSNY MJ45soqluRS6UBB8wLzQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 03 Jun 2020 23:03:50 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2973525546.383.28264; Wed, 03 Jun 2020 23:03:49 -0400 Message-ID: <5ED864AC.5080902@isdg.net> Date: Wed, 03 Jun 2020 23:04:12 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Requirements for a DKIM Signing Practices Protocol X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 03:04:26 -0000 I have to ask these engineering questions because we spent a lot of time developing this functional specifications. How much does DMARC follow the DKIM Signing Policy functional specs? Requirements for a DKIM Signing Practices Protocol https://tools.ietf.org/html/rfc5016 In addition, is DMARC consistent with the DKIM Service Overview? DomainKeys Identified Mail (DKIM) Service Overview https://tools.ietf.org/html/rfc5585 -- HLS From nobody Wed Jun 3 20:28:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9143A0EA9 for ; Wed, 3 Jun 2020 20:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jWt2yI80; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=FCOU7xE1 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 tX_MUhcMmRBO for ; Wed, 3 Jun 2020 20:28:14 -0700 (PDT) Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (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 2A6803A0E81 for ; Wed, 3 Jun 2020 20:28:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1856; t=1591241292; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=rzTYjF9YGO+hV/CGKHrypuAhPPE=; b=jWt2yI80j29Mb+Gy2MO/xBmNowWMMq/WYFYdEJJsQUOsMVeDyzD4nlJkkNMvNA PKbT3SiJn1/X5mT5WXuCbWWoa+qS+4ODY4p1OfWNzwgk4u+LYqTA9YkmVM1q6st2 7L5PGEFGDSLZ45DLmV4zmK0GOD5/Pt77v1Y9a7Xhzbzhk= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 03 Jun 2020 23:28:12 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1968606394.13385.3212; Wed, 03 Jun 2020 23:28:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1856; t=1591241266; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WGPU3cg bxdXv12Lb/IKEumC9JPh9gzr6zcxOk1cNKKU=; b=FCOU7xE1prnGrXi2XLv09+V D2OwBa18K6DW9GXnCnd9P1KbGHX1tUYWC8UU9bxPnLfPRZtfaxbpIQVQ8Q4La7Ne JzRSGBvZcQ5ZFtP+8r0hXMAUMUsXZ+3QQbsorHsBvvCRv6aEgvEt0ov0IaTSEvPr WjFUTrodh0ZYqSfyylxA= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 03 Jun 2020 23:27:45 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2974961203.383.28600; Wed, 03 Jun 2020 23:27:45 -0400 Message-ID: <5ED86A48.5090801@isdg.net> Date: Wed, 03 Jun 2020 23:28:08 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> In-Reply-To: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 03:28:23 -0000 On 6/2/2020 8:45 PM, Douglas E. Foster wrote: > Someone said that the Sender Address is all we can trust. Nonsense. +1 > > As to identifiers: The RFC 5321 MAILFROM sender is intended, at least > in my understanding, to represent the login account used to create the > message, while the RFC 5322 From Header represents the "speaker", the > person whose ideas are being represented by the content. It matters if > someone puts words in someone else's mouth, and From fraud is exactly > that type of fraud. You bring up a basic fundamental reason what the 5322.From field is the only signature binding requirement for DKIM. When it comes to exclusive mail, it is the anchor that is associated with: - Login Account - The Alias or Display Name, - The Default From name for local messages and if the message is exported for a network mail system then we have the additional related identities: - 5322.From - 5321.Mail From In the restrictive DKIM Policy Model, all these identities are closely tied together. They are usually represented and traceable to one person and thus illustrating the long time "Proof Of Concept" that a restrictive DKIM Policy is so powerful, "It's Scary!" A break or deviation from this expectation is a strong candidate for rejection. > I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, > inhibits authorship, or creates any other attribution problem. This > assertion was simply not explained. I believe they are simply catching up with the list problem. Thats all. The problem was recognized long ago with SSP, ADSP. But when ADSP was abandoned for these lists problem and replaced with DMARC, the list problem was no longer a concern but DMARC did not resolve the list problem and it appears DMARC "Proposed Standard" will not try to address it. -- HLS From btv1==424c906265b==fosterd@bayviewphysicians.com Thu Jun 4 03:32:04 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74FD3A0AB8 for ; Thu, 4 Jun 2020 03:32:04 -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 (1024-bit key) header.d=bayviewphysicians.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 meHxdI1_jG-f for ; Thu, 4 Jun 2020 03:32:02 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FCD3A08D9 for ; Thu, 4 Jun 2020 03:32:02 -0700 (PDT) X-ASG-Debug-ID: 1591266720-11fa313a104ed70001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id gEbqlRkwvxqCKO3N (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 04 Jun 2020 06:32:00 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=TmllTtQPqpEZOIlRp0PH/oXOA+cBlvjd6bC5UjGD5uE=; b=HhtRrJRnvPHNs6xI+1ujOTGNZpVN02aZpi0oWqdLWlXw0GUiOc85CDq29E5/eudDB 6Ong4m8LB+oRjZk70C9GK0JxJEwgrLBUMUtypBiq2tHLTKJmFmUwm6nuj0zZI5t2L gYgjp8FEzvt8vO0BdRkbbp2RrSg+y4J8zXjCawLh8= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Thu, 04 Jun 2020 10:31:51 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e0f4e08c65cc4a3abe4b883a1f7b94c5 In-Reply-To: <5ED86A48.5090801@isdg.net> References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <5ED86A48.5090801@isdg.net> X-Exim-Id: e5d30beca6bb43d68529db2498781191 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1591266720 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 6713 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82318 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 11:05:03 -0000 This is a multipart message in MIME format. --e0f4e08c65cc4a3abe4b883a1f7b94c5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MAILING LISTS. The mailing list problem can be stated as follows: Domain B wants to operate a mailing list.The list owner will accept message= s from domain A, alter them, then re-transmit the altered message to member= C.List owner B wants the mail filter for member C to guarantee that his li= st messages are granted the same trust level as a message sent directly fro= m A to C without alteration. This problem is unsolvable because it is unreasonable. The options for cr= eating trust in indirect mail have been discussed in another RFC. Applied= to this issue, the options are: 1) Make List B the originator by changing the RFC 5321 sender address as we= ll as the RFC 5322 Message From. Ideally add a DKIM signature for B, in c= ase the message is forwarded downstream. This is the IETF list behavior a= nd the only one that is feasible in practice. . 2) Require all submitting domains to make List B a trusted sender for their= domain by including B in their SPF record 3) Configure the list to make no changes, then require all senders to inclu= de DKIM signatures for their own domain. 4) Require all recipient systems to make special policy accommodations to g= rant trust to messages from List B, simply because it comes from List B. = This is feasible, but specific to each participants incoming email filter. DKIM and IDENTIFIERS A large portion of legitimate mail is generated by third parties acting as = agents. The problem being addressed by SPF / DKIM / DMARC is: "How can a sender provide information so that a recipient can distinguish b= etween an authorized agent and an unauthorized identity thief?" A subset of this issue is "How do we expect recipient systems to behave?" = This is a rather important detail which this group has explicitly chosen = to not pursue. But I can provide these observations based on experience w= ith mail filtering: To avoid false positives on desired messages, messages from some senders mu= st be given some filtering exceptions. For those exceptions to be applied= safely, the sender must be verified to a degree acceptable to the recipien= t. Depending on the situation, there are multiple ways that a sender can b= e identified. These include, but are not limited to, SPF, DKIM, and DMARC= . In the general case, SPF, DKIM, and DMARC simplify this problem for the = recipient. Although SPF, DKIM, and DMARC are often assumed to be tools for discarding = fraudulent messages, this is extraordinarily difficult to implement in prac= tice. Too many senders have errors in their SPF / DKIM / DMARC configurat= ions, and too many legitimate senders do things that violate a domain owner= 's SPF / DKIM / DMARC policies. Policy failure has not proven to be a rel= iable indicator of unwanted content. Without DMARC, SPF and DKIM configuration errors persist because the sender= obtains no feedback about those errors. DMARC fixes the feedback problem.= I still do not understand how DMARC does anything other than enhance prior = work on SPF and DKIM, or how there is any conflict with prior standards. Doug Foster --e0f4e08c65cc4a3abe4b883a1f7b94c5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
MAILING LISTS.

The mailing list problem can be stated as follows:
  • Domain B wants to operate a mailing list.
  • The list owner= will accept messages from domain A, alter them, then re-transmit the alter= ed message to member C.
  • List owner B wants the mail filter for memb= er C to guarantee that his list messages are granted the same trust level a= s a message sent directly from A to C without alteration.
Thi= s problem is unsolvable because it is unreasonable.   The options for = creating trust in indirect mail have been discussed in another RFC.   = Applied to this issue, the options are:

1) Make Li= st B the originator by changing the RFC 5321 sender address as well as the = RFC 5322 Message From.   Ideally add a DKIM signature for B, in case t= he message is forwarded downstream.   This is the IETF list behavior a= nd the only one that is feasible in practice.
.
2) Requ= ire all submitting domains to make List B a trusted sender for their domain= by including B in their SPF record

3) Configure t= he list to make no changes, then require all senders to include DKIM signat= ures for their own domain.

4) Require all recipien= t systems to make special policy accommodations to grant trust to messages = from List B, simply because it comes from List B.   This is feasible, = but specific to each participants incoming email filter.


DKIM and IDENTIFIERS

A large= portion of legitimate mail is generated by third parties acting as agents.=   The problem being addressed by SPF / DKIM / DMARC is:  
<= div>"How can a sender provide information so that a recipient can distingui= sh between an authorized agent and an unauthorized identity thief?"

A subset of this issue is "How do we expect recipient sys= tems to behave?"    This is a rather important detail which this = group has explicitly chosen to not pursue.   But I can provide these o= bservations based on experience with mail filtering:
  • To avoid = false positives on desired messages, messages from some senders must be giv= en some filtering exceptions.   For those exceptions to be applied saf= ely, the sender must be verified to a degree acceptable to the recipient. &= nbsp;Depending on the situation, there are multiple ways that a sender can = be identified.   These include, but are not limited to, SPF, DKIM, and= DMARC.  In the general case, SPF, DKIM, and DMARC simplify this probl= em for the recipient.

  • Although SPF, DKIM, and DMARC are oft= en assumed to be tools for discarding fraudulent messages, this is extraord= inarily difficult to implement in practice.   Too many senders have er= rors in their SPF / DKIM / DMARC configurations, and too many legitimate se= nders do things that violate a domain owner's SPF / DKIM / DMARC policies. =   Policy failure has not proven to be a reliable indicator of unwanted= content.

  • Without DMARC, SPF and DKIM configuration errors = persist because the sender obtains no feedback about those errors.  DM= ARC fixes the feedback problem. 
I still do not understa= nd how DMARC does anything other than enhance prior work on SPF and DKIM, o= r how there is any conflict with prior standards.   
Doug Foster

--e0f4e08c65cc4a3abe4b883a1f7b94c5-- From nobody Thu Jun 4 07:57:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DBE3A0833 for ; Thu, 4 Jun 2020 07:57:14 -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_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=wdCkAM0O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1OINStxM 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 sb0C_rsLRQ_t for ; Thu, 4 Jun 2020 07:57:13 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102933A081F for ; Thu, 4 Jun 2020 07:57:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2F519964; Thu, 4 Jun 2020 10:57:12 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Thu, 04 Jun 2020 10:57:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=6a ZCEXe523a2nkzFXNnJ4a83rYUYfyURRno9x9sm1Rk=; b=wdCkAM0ONFA5seq/hB G7POeRWcSRd5n+K7SoMBS93+b13mCJ/L9+e3gCPeYXZE6t7hmuI2doAPlUqwfRu8 7HCh5Zfxf14Cw4zQkPCJVjTRPpjGZmGtMSDymi7vQiZgIPcrxzJXbuCCZeqd5swz ZGrfhpX70H7Bj0u/LyFpJSIUHG2viaU0JgSXUcydP8mSUt/VfPfJVJp7fYMnBbY6 MYLQDFB7qvBgTmQk+Ao8C2WQt/vyixPS/WvycocRIEvxD15SmKpeP3VQ8Y1ckPZr vYQ6FAJ0uhgHpQibXiBnM2LARxfmyre+6WLK0lUduufN0u5W1KA6CR5lcLMUK6he ryXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=6aZCEXe523a2nkzFXNnJ4a83rYUYfyURRno9x9sm1 Rk=; b=1OINStxMvNV/pD9l9YNd4/c7pkx/B4fEc0eAqOa5EAaFnGFqAlz9G1y8k Muf0Esn+5+OQ+tfnklofjpoV/dDb/LlSydTHZw+fr2dndD/RltK2dcjL7C6hWERK BrU0FpTw5iK+d1GmyuTlYs7v0QXCapJ2K0X0iTTmx7pWfldS33wuSH4WYCaoKhh6 NxqJom6erxZ4hcHtVLOMPKPizXDMAE6WvaWoEt5RFCzCV/dqT9dgCP1jncQVz4EH Nbd16mmSdtJ6yp8+/0sBVZtVDYTDqkX3UnTL+2lB0x2SHDsOOTlguWwDwFWT20+V 0+oJT46WychK6HtXe32eMyuNx2PsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufht rghnucfmrghlihhstghhfdcuoehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtg gvrdhnvghtqeenucggtffrrghtthgvrhhnpedvjeehjedvvedtffeugfetieevvdfhgffg leffheetteekvdelueegieffuddtueenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtggv rdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 260C71400A1; Thu, 4 Jun 2020 10:57:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <652580c1-5f8b-4d11-af25-d968b277c2b5@www.fastmail.com> In-Reply-To: References: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> Date: Thu, 04 Jun 2020 10:56:18 -0400 From: "Stan Kalisch" To: "Alessandro Vesely" , "Dave Crocker" Cc: dmarc@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 14:57:15 -0000 On Wed, Jun 3, 2020, at 2:30 PM, Alessandro Vesely wrote: > On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: > >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: > >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: > >>>> MUAs should be discouraged from displaying or using Author:, unle= ss > >>>> (verifiably) signed by a trusted domain or otherwise configured b= y the user. > >>> Why? > >> That avoids the dreaded back-to-square-one path that Brandon conjec= tured.=C2=A0 It > >> prevents attacks based on this field, while maintaining the DMARC p= aradigm. > >=20 > > The barrier you specified sounds reasonable.=C2=A0 But it isn't. > >=20 > > Any signature put in place when the Author: field is created is like= ly broken > > by the time it gets to the recipient.=C2=A0 That's the entire proble= m that > > necessitates rewriting the From: field. >=20 >=20 > That depends on who creates the Author: field. I'd imagine it can be = created > on rewriting From:. If it exists already at that time, one can still = check (by > ARC?) if it was signed, and, in case, sign it in turn. I, too, was wondering whether ARC was really the only practical way to a= ttempt this, assuming you don't think it deviates enough from ARC's purp= ose. Thanks, Stan From nobody Thu Jun 4 09:32:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53993A0B20 for ; Thu, 4 Jun 2020 09:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=C9aEAB21; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=TvyNaizF 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 MUQskR_awboq for ; Thu, 4 Jun 2020 09:32:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2A3B33A0B23 for ; Thu, 4 Jun 2020 09:32:30 -0700 (PDT) Received: (qmail 49377 invoked by uid 100); 4 Jun 2020 16:32:27 -0000 Date: 4 Jun 2020 16:32:26 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=c0d6.5ed9221b.k2006; i=news@user.iecc.com; bh=fgjaAgJbGmvvHpp0rCS7U5rqKkhDw4FX6ppQW1NEPvY=; b=C9aEAB21IHXj74z8ss59ZGROj9jtuwxbs5eA+/FVb5EZhtuuuz34VeAbwZp71PQMOf6Lz72bYjly6lvO8u7+yRxdEzyiHemXnV2YtBvuluU/1+30wMzpQqB/TZC7wES9ocYtAWMzormgIlc3dCjBKweFyJzflTPMiarGoYRU4S9KDxTtJCMS1vyWTtisFRLZIyJXp6V3+QiUQHho5Qv1F9WoIxblgv/6Y4ZoApJaBG/sbYRyDHpXNC2HxKbjtC24 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=c0d6.5ed9221b.k2006; olt=news@user.iecc.com; bh=fgjaAgJbGmvvHpp0rCS7U5rqKkhDw4FX6ppQW1NEPvY=; b=TvyNaizFv02IFBwAnO6JUDr+VfDM19UCdmd/MRBar0E6sZ0JhdPptN0lcaNLohcrDCkw4gVHOw01zpttceAXpr8rIoVfRQmwgS2UWjN47bxElqdXFBGhWJCE+mQ8HBM2WKQzPDxBeSMGOQsNrYppAFXBtIYGebGFZSoTZ3PWC0meXTFn2psch3FRtDFNPp1yHxubokElj42LYLjf+19aRoLCFv0OfN3rsxqK2UTFqKLB0kXpa5TcqqJHUR7E5P/3 Organization: Taughannock Networks References: <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> <652580c1-5f8b-4d11-af25-d968b277c2b5@www.fastmail.com> In-Reply-To: <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> <652580c1-5f8b-4d11-af25-d968b277c2b5@www.fastmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 16:32:33 -0000 In article <652580c1-5f8b-4d11-af25-d968b277c2b5@www.fastmail.com>, Stan Kalisch wrote: >> That depends on who creates the Author: field. I'd imagine it can be created >> on rewriting From:. If it exists already at that time, one can still check (by >> ARC?) if it was signed, and, in case, sign it in turn. > >I, too, was wondering whether ARC was really the only practical way to attempt this, assuming you >don't think it deviates enough from ARC's purpose. It took me a while to understand why ARC works the way it does but now that I do, I don't think anything simpler would do. In particular, anything that lets you say "I'm a mailing list" is out since spammers can do that too. Also, real mailing lists tend to have lousy spam filtering and leak a lot of spam, so you can't just whitelist everything from even real lists. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jun 4 17:32:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D93A10EB for ; Thu, 4 Jun 2020 17:32:21 -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, FREEMAIL_FROM=0.001, 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=gmail.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 ArUuEsBcWvIP for ; Thu, 4 Jun 2020 17:32:19 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 AB3073A10F2 for ; Thu, 4 Jun 2020 17:32:19 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id b8so6800839oic.1 for ; Thu, 04 Jun 2020 17:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=w7HDDlxTHGotU7TkIS5icAuVgnaR+L+hcKAB4vNAG5U=; b=tQdWVgKOezFLGgty/SvilhMdDotbUG+fogvxvdeOMbdArX4oSSAyoEmbbLqgt64kHX Ch4IKqv+vXmO2NyKBs1wUws3oQYiPPUygBYRSVqw3B8qBf+A9+PPYE2O+xYz37ZccLm+ gPl19OToCgWNVzBihhFviKMi+EymhkDaJftjVhyhokFkBvfJyMZQVylOIPrlERJ+BW+9 2sdEjJpo44H42jh/fB72DUPOEWrwdfE1L+10EOt4mdPJIz4s3w0+wOJI3bu506z4UWrc AKPMZAgslFwFQw7DeHdhXdkpsmkKb3C5ExvRQrDR/qMIN5aWB34ByFGLcanm+fPM7Y1U moMw== 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=w7HDDlxTHGotU7TkIS5icAuVgnaR+L+hcKAB4vNAG5U=; b=NRui0L1d8O9gBfKhpkCbKKbN2XP39IcTFQSIQpkY5isBqQmD31cDDxJhwWdmL8n/x3 OSYeNKM4dWzNJzjoJcfC+OBqv9DTUhU8Os4cFTaxmoHba3Iyx0Vp/hFor/HC82KrRApH arI4DS1LHMaXwob6VzK+qBPfOYt2hzfgCI2VckuyWEN9cs8v51hp7BPjSECoA9Gmbcru 3+OWmMCwd6dQP0eK+mUGIvta1ZiSdkwvxqbcocWiUqTl6KeIIWkoPU7xMGkY7zRpXpF0 sM7YznQi0zANyDHoeiwRPSon7KPPpvV+drivlPuDQd8W2zPznPPbOXRYk8yNJrPkVln2 MslQ== X-Gm-Message-State: AOAM533P6W6xKAXW7C5lDgKwURnHEbn7/iGF/w2bkJcGeKGHiZ9WnWoX aF1+kt8/1ePfIY5rmMQGsAT1OtHdtGwOr6z4N4LXxk/G X-Google-Smtp-Source: ABdhPJw680k6oExq3SKFGQAbNcHesPjTT9Wr5G3TUxvtIhrC0UrV01m32S0jO7z0zViXbsJeJcJNTj8lodqG9//DEaU= X-Received: by 2002:aca:ac42:: with SMTP id v63mr369228oie.6.1591317137159; Thu, 04 Jun 2020 17:32:17 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Thu, 4 Jun 2020 20:32:05 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/mixed; boundary="000000000000afa7c205a74b64a1" Archived-At: Subject: [dmarc-ietf] Reminder - DMARC Interim 11 June 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 00:32:25 -0000 --000000000000afa7c205a74b64a1 Content-Type: multipart/alternative; boundary="000000000000afa7c005a74b649f" --000000000000afa7c005a74b649f Content-Type: text/plain; charset="UTF-8" All Reminder that the DMARC Interim will happen next Thursday 11 June 2020. This will be after a M3AAWG session on DMARC 2.0. The main agenda will be bringing forward discussion items from the M3AAWG session. The IETF portion will be under IETF rules, with the appropriate IETF Note Well (https://ietf.org/about/note-well/) Date: 14 April 2020 Time: 1400-1600 UTC Webex: https://ietf.webex.com/ietf/j.php?MTID=m706bba8b48e3db3db02d72f0941b2630 Alexey/Seth/Tim --000000000000afa7c005a74b649f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= ll

Reminder t= hat the DMARC Interim will happen next Thursday 11 June 2020.=C2=A0 This wi= ll be after a M3AAWG session on DMARC 2.0.=C2=A0 The main agenda will be br= inging forward discussion items from the M3AAWG session.=C2=A0 =C2=A0
=

The IETF portion will be under IETF rules, with the appropriate=C2= =A0IETF Note Well (https://ietf.org/about/note-well/)
<= br>
Date: 14 April 2020
Time: 1400-1600 UTC
Webex: http= s://ietf.webex.com/ietf/j.php?MTID=3Dm706bba8b48e3db3db02d72f0941b2630<= br>

Alexey/Seth/Tim
--000000000000afa7c005a74b649f Content-Type: text/calendar; charset="UTF-8"; method=PUBLISH Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VEVENT UID:ietf-interim-2020-dmarc-01-12834-dmarc SUMMARY:dmarc - Domain-based Message Authentication, Reporting & Conformance LOCATION:None STATUS:CONFIRMED CLASS:PUBLIC DTSTART;TZID="UTC":20200611T160000 DTEND;TZID="UTC":20200611T170000 DTSTAMP:20200510T124745Z URL:https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01 DESCRIPTION:\n \nAgenda: https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01\n END:VEVENT END:VCALENDAR --000000000000afa7c005a74b649f-- --000000000000afa7c205a74b64a1 Content-Type: text/calendar; charset="US-ASCII"; name="dmarc.ics" Content-Disposition: attachment; filename="dmarc.ics" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kb1gsr390 QkVHSU46VkNBTEVOREFSClZFUlNJT046Mi4wCk1FVEhPRDpQVUJMSVNIClBST0RJRDotLy9JRVRG Ly9kYXRhdHJhY2tlci5pZXRmLm9yZyBpY2FsIGFnZW5kYS8vRU4KQkVHSU46VkVWRU5UClVJRDpp ZXRmLWludGVyaW0tMjAyMC1kbWFyYy0wMS0xMjgzNC1kbWFyYwpTVU1NQVJZOmRtYXJjIC0gRG9t YWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZyAmIENvbmZvcm1hbmNl CkxPQ0FUSU9OOk5vbmUKU1RBVFVTOkNPTkZJUk1FRApDTEFTUzpQVUJMSUMKRFRTVEFSVDtUWklE PSJVVEMiOjIwMjAwNjExVDE2MDAwMApEVEVORDtUWklEPSJVVEMiOjIwMjAwNjExVDE3MDAwMApE VFNUQU1QOjIwMjAwNTEwVDEyNDc0NVoKVVJMOmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy9pbnRlcmltLTIwMjAtZG1hcmMtMDEvbWF0ZXJpYWxzL2FnZW5kYS1pbnRlcmltLTIw MjAtZG1hcmMtMDEtZG1hcmMtMDEKREVTQ1JJUFRJT046XG4KIFxuQWdlbmRhOgogIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtZG1hcmMtMDEvbWF0ZXJp YWxzL2FnZW5kYS1pbnRlcmltLTIwMjAtZG1hcmMtMDEtZG1hcmMtMDFcbgpFTkQ6VkVWRU5UCkVO RDpWQ0FMRU5EQVIK --000000000000afa7c205a74b64a1-- From nobody Thu Jun 4 17:56:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3C3A0B50; Thu, 4 Jun 2020 17:56:38 -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, FREEMAIL_FROM=0.001, 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=gmail.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 FNKlyUG5En0A; Thu, 4 Jun 2020 17:56:37 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 3E76A3A0B42; Thu, 4 Jun 2020 17:56:37 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id b8so6841035oic.1; Thu, 04 Jun 2020 17:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3VgtRVNDfMp6BVuFbGPnyvQN7SVyte9ywyFuFkOaIdQ=; b=NrrOF2WoEqjME9ct+typsDDEQHAPwViwNkeTq/sbNfHJanamoJlHjwkYh8ge7GIrw9 hT8oVDL75c4ZLsuHD1tJaC5us/3EzSIdK1W7+JrCCIju6q1CSlFna9myp2t8pnsE1+9Q pX3KNZENEd9ffo8pLGresfB12qrDrx0nrbBYISVHR+Mabio0b25rV5WUOBSCvHfbTJ3R 5WW9Zvsj+Djb6UvMe03iuS2niIC/sYU7JUEpuhAgtqYhyxfMqGPunGESvIhVyBaPqrlY 6wm9ob+hoamRxr81t4rejCaoSdvLoheNQxWNbGxvK5mFTpcLCwaGxhAbuMcQvow3o26x XfAw== 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=3VgtRVNDfMp6BVuFbGPnyvQN7SVyte9ywyFuFkOaIdQ=; b=XKo2OCjqIpvB6isdSVzZJxHoRnBDcZ7m5n7speFy26mxbOV3mDlACih14Cju3eZYNR eWTV6HwwzA3M0aqd5it/GDfx/pObwu9iQjuL3QznZd9H1NEqe4ToDQu5VrGU3PDIAWpv geEijSft6bDgcjIKrzTIlyhdjyubwsWfDk4PzGTnoqmeWYaq6VqQ/OL+XS3ayGPjv72o xhHgyupOg5wtymMpNPkGvnTs/oUfcjlzSWgmvhO54UX8FHYagEqtX/5SP57enGxWyFF9 hoiLpexgTthvR5ZN4eMEklyPcDmhZ/Fybbe4MaTmKjCjNkzzVNE7dPhRm5JOzmwAtX6n AcwA== X-Gm-Message-State: AOAM5339tpLKA+IzOOt/c6USmoXg6eRAWzz3ESGR4YhIjTFZrx7EscPv 5EOlI1RIWNoTrwN2Uu2RWRy60XhLaE8HEimeUeA4Jg== X-Google-Smtp-Source: ABdhPJwTzAHNvaSUhTOZrpGTWrrkeQNY+BIYy5NdY8Oo6kMSgYDchdBVGDdfg9hZou+9OJAE/8VVaqcCX6WbbQrZU0Q= X-Received: by 2002:aca:bd08:: with SMTP id n8mr342977oif.173.1591318594940; Thu, 04 Jun 2020 17:56:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 4 Jun 2020 20:56:23 -0400 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000093714205a74bbb4a" Archived-At: Subject: Re: [dmarc-ietf] Reminder - DMARC Interim 11 June 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 00:56:39 -0000 --00000000000093714205a74bbb4a Content-Type: text/plain; charset="UTF-8" We are also looking for someone to take minutes and someone to assist monitoring the Jabber room For minutes, we'll try to use the Etherpad (link in the Agenda) but minute taker is not bound by that. Thanks tim On Thu, Jun 4, 2020 at 8:32 PM Tim Wicinski wrote: > > All > > Reminder that the DMARC Interim will happen next Thursday 11 June 2020. > This will be after a M3AAWG session on DMARC 2.0. The main agenda will be > bringing forward discussion items from the M3AAWG session. > > The IETF portion will be under IETF rules, with the appropriate IETF Note > Well (https://ietf.org/about/note-well/) > > Date: 14 April 2020 > Time: 1400-1600 UTC > Webex: > https://ietf.webex.com/ietf/j.php?MTID=m706bba8b48e3db3db02d72f0941b2630 > > Alexey/Seth/Tim > --00000000000093714205a74bbb4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

W= e are also looking=C2=A0for someone to take minutes and someone to assist m= onitoring the Jabber room

For minutes, we'll try to use the Etherpad (link in the Ag= enda) but minute taker is not bound by that.

Thanks
tim

On Thu, Jun 4, 2020 at 8:32 = PM Tim Wicinski <tjw.ietf@gmail.co= m> wrote:

= All

<= /div>
Reminder = that the DMARC Interim will happen next Thursday 11 June 2020.=C2=A0 This w= ill be after a M3AAWG session on DMARC 2.0.=C2=A0 The main agenda will be b= ringing forward discussion items from the M3AAWG session.=C2=A0 =C2=A0

The= IETF portion will be under IETF rules, with the appropriate=C2=A0IETF Note= Well (https://ietf.org/about/note-well/)

=
Date: 14 April 2020Time: 1400-1600 UTC
Webex: https://ietf.= webex.com/ietf/j.php?MTID=3Dm706bba8b48e3db3db02d72f0941b2630

Alexey/Seth/Tim
--00000000000093714205a74bbb4a-- From nobody Thu Jun 4 21:40:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3434E3A124C for ; Thu, 4 Jun 2020 21:40:20 -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 (1024-bit key) header.d=bluepopcorn.net 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 ZI4kyZwnZ7kd for ; Thu, 4 Jun 2020 21:40:18 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 639C83A11F7 for ; Thu, 4 Jun 2020 21:40:18 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:1835:3dc7:38c:bef7]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 0554e811002752 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 4 Jun 2020 21:40:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591332013; bh=iYK24NEJ+tKWajpjfJMXNQStKX8H5IOfiSqExrYuAT4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oG9NU38Y/up87UgF6I0arBXOSaya7RM+Alx+fSy+/2GflTaOuay7CvdWoCz5eJOsT t+sOv/jT7cH0fyxTS/jMATMxc9BKW+cwe+Sk+DObxiGbahi7zDTwZxB0QxB2Cp+Cgi 1TPyj6UWGWCTIb+5moGVrfXn5CCBxfRERmR5ywXs= To: Dotzero Cc: "dmarc@ietf.org" References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> Date: Thu, 4 Jun 2020 21:40:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------056FA66113D486B82BA1CA3B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 04:40:20 -0000 This is a multi-part message in MIME format. --------------056FA66113D486B82BA1CA3B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/2/20 10:35 AM, Dotzero wrote: > > As part of the original DMARC team, the goal was to make clear whether > the email was authorized by the domain being used, hence the reliance > on SPF and DKIM. These are clearly under the domain > owner/administrator's control to the extent they choose to exercise > that control. There was much discussion in the community at the time > to use thei=3D field to enable more granular signing. it never gained > traction. Because the intent was to protect end users from fake emails > purporting to be from (primarily) commercial domains such as financial > institutions, greeting card companies, etc., the Sender field was not > a significant issue. Also, when the Sender is in the same domain as > the From, there is no DMARC issue. I'm all confused about why alignment matters. Back around the time DKIM was standardized, we were concerned about phishing attacks from look-alike domains, i.e., substitutions of 1 for l, that might be registered by attackers and sign their messages with valid DKIM signature= s. But now a lot of people don't see anything but the Friendly Name; the email address isn't displayed at all. For that (apparently increasing) proportion of users, the From or Sender addresses aren't visible; the attacker might as well use any Friendly Name of their choosing with any domain they can sign for there. So they get DMARC alignment, but what has it accomplished? -Jim --------------056FA66113D486B82BA1CA3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/2/20 10:35 AM, Dotzero wrote:

As part of the original DMARC team, the goal was to make clear whether the email was authorized by the domain being used, hence the reliance on SPF and DKIM. These are clearly under the domain owner/administrator's control to the extent they choose to exercise that control. There was much discussion in the community at the time to use thei= field to enable more granular signing. it never gained traction. Because the intent was to protect end users from fake emails purporting to be from (primarily) commercial domains such as financial institutions, greeting card companies, etc., the Sender field was not a significant issue. Also, when the Sender is in the same domain as the From, there is no DMARC issue.


I'm all confused about why alignment matters. Back around the time DKIM was standardized, we were concerned about phishing attacks from look-alike domains, i.e., substitutions of 1 for l, that might be registered by attackers and sign their messages with valid DKIM signatures.

But now a lot of people don't see anything but the Friendly Name; the email address isn't displayed at all. For that (apparently increasing) proportion of users, the From or Sender addresses aren't visible; the attacker might as well use any Friendly Name of their choosing with any domain they can sign for there. So they get DMARC alignment, but what has it accomplished?

-Jim


--------------056FA66113D486B82BA1CA3B-- From nobody Thu Jun 4 22:40:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6453A12B5 for ; Thu, 4 Jun 2020 22:40:10 -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, FREEMAIL_FROM=0.001, 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=gmail.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 ZPSotTKvBC35 for ; Thu, 4 Jun 2020 22:40:09 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 116943A12AE for ; Thu, 4 Jun 2020 22:39:51 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id l11so8415937wru.0 for ; Thu, 04 Jun 2020 22:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6KTrEChaWh87Fzy47F+iwxdxbpJB1OznV1wzgYzMf6w=; b=gF1X8XFxpu0MYXIdMq+yGbKsnTh25vqvNm8BV95QsyDXJsB2Kfz8h/KtJNJfBczviZ F6g51TE+2d/tqhL8OUzZfQWB9iUTbRvPT10grY9TpKFz7N/ZNhq642925eomLibX9y2c MkprS5+6aNRepQ9Ys3h26BpPxj146MWHoHfa/wnlI37gCNxA4gjGdlP2/vz3kdyYRk7D x87mtOOb873XQQ+uDQ2jfJLDhXsqqA4JCg+ztL5pitE1KwtcuQZgZqE3DijwMfvzPZTJ BhD3SgADKP7ocf0LHfWD1U90Z7F+m8KhUf7Nnfdb7rtg/ub4x3FSVpkNV3Mx5csp7y5j RXpw== 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=6KTrEChaWh87Fzy47F+iwxdxbpJB1OznV1wzgYzMf6w=; b=g3FkiqC38VMMwK6sIZhcmeH0eIBTxgKDrsNEctl1dgBXw9PtXlioK0PcgiHx8swqDp AqqAf+0JFYvu0R69QyVFGWN9HHWxcbHBDrvL3KIpgKIhqfQXecE3yJSkywm79i/eguc6 0jY4qkmMWnbHJPPtCz5GbtWf6cFPm0Dehv22GmChKu7+Fi5tIM/XlGjffJdGDOlMC/0Q TPjzkBaH0fXwzxsyvyi21h8CJvmf+8SXDNtE6gxn3t6XF3AShi5F5QWG2ysMSc865Gqp dC9/EJyUUPKotcDn6Hylc//sYf5HPadZuCv09hLUHIxOTqY6TY9c6NjN86Eh0JuYiA+c NbMQ== X-Gm-Message-State: AOAM531A5uOy3A/jExJsWjZ+ZE0UqMq/ot3OoN6N5yhjBVYhq8txA2xU vCqyNsVncLMVwGyH0Se+uyuq/I0y7G636rAGyuXmhGmZ3l8= X-Google-Smtp-Source: ABdhPJxEWxPVsGZZ2E+EMY6ltdNFt8P2Ctx6C3oAUVI0gMwy94l1pXdO2YhtP+6IP1VHeKir4SBhUp4tGMG9Wf4plZs= X-Received: by 2002:a5d:604b:: with SMTP id j11mr7730785wrt.193.1591335589422; Thu, 04 Jun 2020 22:39:49 -0700 (PDT) MIME-Version: 1.0 References: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> In-Reply-To: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> From: Dotzero Date: Fri, 5 Jun 2020 01:39:37 -0400 Message-ID: To: Jim Fenton Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086abba05a74fb0de" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 05:40:12 -0000 --00000000000086abba05a74fb0de Content-Type: text/plain; charset="UTF-8" On Fri, Jun 5, 2020 at 12:40 AM Jim Fenton wrote: > On 6/2/20 10:35 AM, Dotzero wrote: > > > As part of the original DMARC team, the goal was to make clear whether the > email was authorized by the domain being used, hence the reliance on SPF > and DKIM. These are clearly under the domain owner/administrator's control > to the extent they choose to exercise that control. There was much > discussion in the community at the time to use thei= field to enable more > granular signing. it never gained traction. Because the intent was to > protect end users from fake emails purporting to be from (primarily) > commercial domains such as financial institutions, greeting card companies, > etc., the Sender field was not a significant issue. Also, when the Sender > is in the same domain as the From, there is no DMARC issue. > > > I'm all confused about why alignment matters. Back around the time DKIM > was standardized, we were concerned about phishing attacks from look-alike > domains, i.e., substitutions of 1 for l, that might be registered by > attackers and sign their messages with valid DKIM signatures. > > But now a lot of people don't see anything but the Friendly Name; the > email address isn't displayed at all. For that (apparently increasing) > proportion of users, the From or Sender addresses aren't visible; the > attacker might as well use any Friendly Name of their choosing with any > domain they can sign for there. So they get DMARC alignment, but what has > it accomplished? > > -Jim > The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing more and nothing less. It helps receiving systems identify a (correctly) participating domain's mail. That is why a DMARC policy is often described as a sending domain's request and local policy is so important (and can override that request). For attackers that deploy DMARC it simply means that they are self identifying their malicious messages as theirs. Much has incorrectly been attributed to SPF/DKIM/DMARC. For example: "It stops spam" - It does not. "It stops phishing" - It does not. The modest goal is to stop direct domain abuse. It can do this remarkably well. On the other hand it creates an incentive for attackers to compromise participating domains. This has led to the long standing discussion (more lately lapsed) between Dave Crocker and my self about reputation. My position is that long term, reputation systems are of limited value because of domain compromise or even sending policy change. To put it another way, "What have you done to me today?". Dave has in the past had greater faith in reputation. For Sending domains, SPF/DKIM/DMARC is only one set of tools in protecting their brand from abuse. It protects end users from abuse. In fact, in many cases the individuals most susceptible to falling prey to such abuse may not even be customers of that sending domain. No, that greeting card you received isn't legit (Nobody loves you). No, that retailer isn't giving you a $200 gift card. This is why other tools like takedowns are so important and why the removal of registrant information from domain registrations has enabled abusers. Just a few thoughts. Michael Hammeer --00000000000086abba05a74fb0de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Fri, Jun 5, 2020 at 12:40 AM Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
On 6/2/20 10:35 AM, Dotzero wrote:
=20

As part of the original DMARC team, the goal was to make clear whether the email was authorized by the domain being used, hence the reliance on SPF and DKIM. These are clearly under the domain owner/administrator's control to the exten= t they choose to exercise that control. There was much discussion in the community at the time to use thei=3D field to enable more granular signing. it never gained traction. Because the intent was to protect end users from fake emails purporting to be from (primarily) commercial domains such as financial institutions, greeting card companies, etc., the Sender field was not a significant issue. Also, when the Sender is in the same domain as the From, there is no DMARC issue.


I'm all confused about why alignment matters. Back around the time DKIM was standardized, we were concerned about phishing attacks from look-alike domains, i.e., substitutions of 1 for l, that might be registered by attackers and sign their messages with valid DKIM signatures.

But now a lot of people don't see anything but the Friendly Name= ; the email address isn't displayed at all. For that (apparently increasing) proportion of users, the From or Sender addresses aren't visible; the attacker might as well use any Friendly Name of their choosing with any domain they can sign for there. So they get DMARC alignment, but what has it accomplished?

-Jim


The goal of DMARC= was (and is) to mitigate direct domain abuse. Nothing more and nothing les= s. It helps receiving systems identify a (correctly) participating domain&#= 39;s mail. That is why a DMARC policy is often described as a sending domai= n's request and local policy is so important (and can override that req= uest).

For attackers that deploy DMARC it simply m= eans that they are self identifying their malicious messages as theirs.
=
Much has incorrectly been attributed to SPF/DKIM/DMARC. For example: &q= uot;It stops spam" - It does not. "It stops phishing" - It d= oes not. The modest goal is to stop direct domain abuse. It can do this rem= arkably well. On the other hand it creates an incentive for attackers to co= mpromise participating domains. This has led to the long standing discussio= n (more lately lapsed) between Dave Crocker and my self about reputation. M= y position is that long term, reputation systems are of limited value becau= se of domain compromise or even sending policy change. To put it another wa= y, "What have you done to me today?". Dave has in the past had gr= eater faith in reputation.
<= /sup>
For Sending domains,=C2=A0SPF/DKIM/DMA= RC is only one set of tools in protecting their brand from abuse. It protec= ts end users from abuse. In fact, in many cases the individuals most suscep= tible to falling prey to such abuse may not even be customers of that sendi= ng domain. No, that greeting card you received isn't legit (Nobody love= s you). No, that retailer isn't giving you a $200 gift card. This is wh= y other tools like takedowns are so important and why the removal of regist= rant information from domain registrations has enabled abusers.
<= br>
Just a few thoughts.

Michael Hammeer=
--00000000000086abba05a74fb0de-- From nobody Fri Jun 5 03:34:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9753A0CB0 for ; Fri, 5 Jun 2020 03:34:30 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 8A2_DCmV833S for ; Fri, 5 Jun 2020 03:34:28 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 AA5E73A144F for ; Fri, 5 Jun 2020 03:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591353264; bh=cdkMbkMEm6hdessEycZHZihKA73UFJjfqeDSuVD9vD0=; l=3072; h=To:References:From:Date:In-Reply-To; b=DN3St98k6ZmtzfzW5pIsbAOEPi7Ju8MBR+1XpkJBDR8O4a5VcinabGj6Pp1p2nUMR 70L8qfIa6vFyE7af3qIQYVAqeQEIcdFTE7eLMVCu7Rjp5yOFUpzsv23mKO8Gx+OtqP PWeez07kK48p5JlmMfETcanI0IyA8mL8l0pdVPY2mg8m5nIa/m+AjcMzipfYi Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07E.000000005EDA1FB0.00006A8B; Fri, 05 Jun 2020 12:34:23 +0200 To: dmarc@ietf.org References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <5ED86A48.5090801@isdg.net> From: Alessandro Vesely Message-ID: Date: Fri, 5 Jun 2020 12:34:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 10:34:31 -0000 On Thu 04/Jun/2020 12:31:51 +0200 Douglas E. Foster wrote: > MAILING LISTS. > > The mailing list problem can be stated as follows: > > * Domain B wants to operate a mailing list. > * The list owner will accept messages from domain A, alter them, then > re-transmit the altered message to member C. > * List owner B wants the mail filter for member C to guarantee that his list > messages are granted the same trust level as a message sent directly from A > to C without alteration. > > This problem is unsolvable because it is unreasonable. Starting a message by posing an ill-defined problem does not help clarity. > The options for creating trust in indirect mail have been discussed in > another RFC. Applied to this issue, the options are: > > 1) Make List B the originator by changing the RFC 5321 sender address as well > as the RFC 5322 Message From.   Ideally add a DKIM signature for B, in case the > message is forwarded downstream.   This is the IETF list behavior and the only > one that is feasible in practice. This is the *de-facto* standard. As the OP noted, the agent responsible for the transmission should be set in the Sender: field. Instead, mailing lists are forced to rewrite the From: field because of DMARC. IOW, DMARC hijacked From: thereby violating RFC 5322. I agree this point should be fixed, making a real standard of it. I think that would take more than one RFC. > 2) Require all submitting domains to make List B a trusted sender for their > domain by including B in their SPF record This never was an option. Mailing lists used to practice some form of VERP long before SPF. > 3) Configure the list to make no changes, then require all senders to include > DKIM signatures for their own domain. Many lists do so, for example opendkim-users, that some of us are subscribed to. Note that this set-up does not prevent posters from writing "[opendkim-users]" in the Subject: of new messages. Nobody does so, since posts are accepted even without a subject tag, yet it could be easily enforced. > 4) Require all recipient systems to make special policy accommodations to grant > trust to messages from List B, simply because it comes from List B.   This is > feasible, but specific to each participants incoming email filter. This is a hindrance to DMARC adoption. The need to catch and mark all the mailing list domains that don't rewrite From: can prevent an MTA from blindly conforming to all DMARC policies. Alternatively, an MTA can mark highly abused domains and conform to DMARC policies in those cases only. For completeness, I'd also mention conditional signatures, as a fifth point. They were specified, implemented and then abandoned in lieu of ARC. > [...] > > I still do not understand how DMARC does anything other than enhance prior work > on SPF and DKIM, or how there is any conflict with prior standards.    The OP quoted the passage of RFC 5322 where the roles of From: and Sender: are specified. Best Ale -- From nobody Fri Jun 5 04:33:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780DE3A14B8 for ; Fri, 5 Jun 2020 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=agsiV/Xv; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=NYzTrtNX 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 jYHZdug8wmEo for ; Fri, 5 Jun 2020 04:32:56 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (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 4C87B3A1492 for ; Fri, 5 Jun 2020 04:32:55 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4456; t=1591356765; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=HH9zWT2aqDjB9ja4cI7TptILnZo=; b=agsiV/XvRkzgreIQWdvxVbsBKNyqZAaPa5lLAOeYZTZkMYkRcMzMZ60sO2WW2B h023ZRFGadXkEbp8EcoWoLdEM9ZmfMxpCm3LxCeR6isiUrNzHQTs3eaO+mZ2rOpy L6roSmFMSR3vhvTebWfwouQA30WuxAyUekDvUbPg/AMes= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 07:32:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2084077491.13385.8020; Fri, 05 Jun 2020 07:32:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4456; t=1591356736; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yK5enOO svfw4fBPgumcx/NAiM4nrY/qGif/rFJ946QE=; b=NYzTrtNXtKcf0UlJVPUNIjP wsWtTeV7zXWPr+2NZIU3QEyLqez/JwXspWHJsczR7bt7tij8Ew8CPQeR1gOmW9xr 3lfSNXi7dDDtOhDRBPeVDeF0MvlVYPk3xhMUagnn2NwznS+UI2bFTCZAl2MZ5D8x oEQ58QgG0JQfSTz2awic= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 07:32:16 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3090431359.383.30296; Fri, 05 Jun 2020 07:32:15 -0400 Message-ID: <5EDA2D5A.3070102@isdg.net> Date: Fri, 05 Jun 2020 07:32:42 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <5ED86A48.5090801@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 11:33:07 -0000 On 6/4/2020 6:31 AM, Douglas E. Foster wrote: > MAILING LISTS. > > The mailing list problem can be stated as follows: > > * Domain B wants to operate a mailing list. > * The list owner will accept messages from domain A, alter them, > then re-transmit the altered message to member C. > * List owner B wants the mail filter for member C to guarantee that > his list messages are granted the same trust level as a message > sent directly from A to C without alteration. > > This problem is unsolvable because it is unreasonable. Hi Douglas -1. I have to respectfully disagree with this. Using the proper protocol, Domain A can reasonably declare, with certainty, to explicitly and deterministically authorize the Domain B resigner where the Domain C receiver can verify whether Author Domain A 3rd party policy allows Domain B to resign. It is done with DMARC with the add-on ATPS by adding an extended tag "atps=y" to your DMARC record. My DMARC record for my domain isdg.net is: v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net;" The isdg.net domain zone has authorized the following domains with the ATPS records: e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) lykm653kj7yxeia665va7lszzthcx7jj._atps TXT ( "v=atps01; d=beta.winserver.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) It works very well. If you wish to explore this, this wizard is available: https://secure.winserver.com/public/wcDmarc Use the simulator in the wizard to show proof of concept. > The options for creating trust in indirect mail have been discussed in another > RFC. Which one? With the exception of VBR, I am not aware of any IETF-based Signer Domain DKIM Trust/Vouching Protocol. Until we have a 3rd party authorization system in play, the Signer Trust can not be established. It would be unreasonable for Domain C to blindly use some unknown Trust Authority to all incoming domain As coming from Domain Bs. On the other hand, if the Domain A, explicitly said something in the DMARC record such as: v=DMARC1; p=reject; trust=trust1.example,trust2.example; ..... Then Domain C can check for some "trust" protocol where it will look up poll a trust service, trust1.example or trust2.example. Maybe the trust service will give DOMAIN A some zone records specific to the trusted resigners. Either way, the process model would be: trust.result = DKIM_TRUST(Author.Domain, Sender.Domain[, User.Agent.Identity]) Is this unreasonable? I don't think so, but we don't have it. Again, VBR is similar to this. It has a lookup method where you combine the author domain with the signer domain plus other spam-based tags specific to the type of mail, or something like that. Note, it was always my technical opinion, DKIM std incorrectly attempted to remove the Author Domain Identity from the DKIM base protocol, but instead it attempted to replace the DKIM Policy model was a DKIM Trust model, so the process prototype would be: trust.result = DKIM_TRUST(Sender.Domain[, User.Agent.Identity]) But as expected, this trust model never materialize but instead the self-signing DKIM Policy model was too strong to eliminate from the DKIM picture. Add ATPS or a similar 3rd party authorization protocol, and we will get a lot further than we have been since DMARC replaced ADSP without addressing and resolving the 3rd party resigner issue. Finally, my DKIM modeling contention has always been, DKIM is a two pass layer model: - Pass 1, DKIM Policy check using the Author Domain - Pass 2, iff pass 1 is successful, check the signer domain trust. I believe that is what the DKIM Service Overview attempt to depict, by combining two assessment inputs - signing practice/policy and trust info. DomainKeys Identified Mail (DKIM) Service Overview https://tools.ietf.org/html/rfc5585#page-14 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jun 5 04:45:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADDC3A1099 for ; Fri, 5 Jun 2020 04:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=ZJ6eQ0Dk; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=wNpYXW+O 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 G6yWo9qlMusK for ; Fri, 5 Jun 2020 04:45:25 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (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 55D903A0F59 for ; Fri, 5 Jun 2020 04:45:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1355; t=1591357520; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=JHlxcWV4un0Yu+NJ340CxoZb0UY=; b=ZJ6eQ0DkNVvgLjdvrMWLHwZEsLxB1jqzDZC0x7dDl3NjJRMoBQyvntEB40mowC rcuJTCsmG6LPMlwJMLsnQI71OiJEdqIXGlF/DwHraBzgnYWgbI1PqMOfhs5/C50W CZJGoIc3lrvYZ4dYsBlfuonD3IIN665udQOr2aR/KROs4= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 07:45:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2084832599.13385.3340; Fri, 05 Jun 2020 07:45:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1355; t=1591357491; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jrfVuNp u6HhivDd5Fio6rO8DBGNsrMtoDgw4iMKspKY=; b=wNpYXW+OcH4+ESAnEruVbAW NmsrlhTBn+ZoLHDwMDMynxYpIo6rxXfDl5imSlIjIXE+A2LzoY6EhfSDNo8z9S/O MkeuLJza+NgLFZOAys1QPfHj3jZ7pwKvvLDP/1Kl4HopfpUgcsyfdegVWbCJgyUb V53VQVidsfwFCecmEwjQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 07:44:51 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3091187078.383.30204; Fri, 05 Jun 2020 07:44:51 -0400 Message-ID: <5EDA304E.40601@isdg.net> Date: Fri, 05 Jun 2020 07:45:18 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Alessandro Vesely , dmarc@ietf.org References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <5ED86A48.5090801@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 11:45:27 -0000 On 6/5/2020 6:34 AM, Alessandro Vesely wrote: > >> 4) Require all recipient systems to make special policy accommodations to grant >> trust to messages from List B, simply because it comes from List B. This is >> feasible, but specific to each participants incoming email filter. > > > This is a hindrance to DMARC adoption. The need to catch and mark all the > mailing list domains that don't rewrite From: can prevent an MTA from blindly > conforming to all DMARC policies. Alternatively, an MTA can mark highly abused > domains and conform to DMARC policies in those cases only. It doesn't have to be all mailing list, just the ones authorized to resign on your behalf. Of course, there are scalability issue with the "bigger guy" but that should not preclude the "smaller guy" from leveraging this method. > For completeness, I'd also mention conditional signatures, as a fifth point. > They were specified, implemented and then abandoned in lieu of ARC. hmmmm, interesting. Where was the "Conditional Signature" proposal implemented? I have never come across a conditional signature header. I was not aware ARC was a "conditional signature" or "3rd Party Authorization" protocol. IMO, ARC has a high barrier of entry with an awful amount of complexity to implement in order to authorize a 3rd party domain. -- HLS From nobody Fri Jun 5 06:32:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581A13A082D for ; Fri, 5 Jun 2020 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=UnNawpPk; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=JLCtTmWH 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 1JU735yvocrE for ; Fri, 5 Jun 2020 06:31:57 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (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 339353A082B for ; Fri, 5 Jun 2020 06:31:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1759; t=1591363910; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=BZsHyQwoQxXOPJRiZmERjTFYtJY=; b=UnNawpPkaTM0imznbVMG9zHn9atQjKxeE48MWVqEhCA9LB5grUfi0NzAyWfqlf zS1NU6XxVhMeC03ri8o2plksdMNoMbljZ0PgAt6eiVXXuON7PqQ9rHdN1aMRQl+Q YJZkvNReq8oGFAYBuPHmTLpFIoNJqk7a3hmHDi/CK/DP8= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 09:31:50 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2091222665.13385.2712; Fri, 05 Jun 2020 09:31:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1759; t=1591363884; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GZnfqic 23vp9nTNzPEcxB8j593M1DLpi0E1757mmmog=; b=JLCtTmWH50DIYIpyAUdkFcz xDnUSa8pcjaVVN9hWnoeqkHbStkttTDfQUUQtwKT0sCcXiiX5p9YwIGkfAkQGYoY D0aueetiF3aL8Hgocjip65YsRrAWjeviLCijlBCxfABfI7DO98FVminLyOvKVJM3 RJmvRAGKDRMaKAIiWU8s= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 05 Jun 2020 09:31:24 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3097578890.383.29808; Fri, 05 Jun 2020 09:31:22 -0400 Message-ID: <5EDA4946.4080406@isdg.net> Date: Fri, 05 Jun 2020 09:31:50 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 13:31:59 -0000 On 6/5/2020 1:39 AM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. +1, it was the goal of: [1] The original proof of concept with DomainKeys' built-in o= policy tag for 1st party support, and [2] The original DKIM draft augmented with the original SSP draft with extended o= tags that included 3rd party signer considerations, and [3] My own DSAP with its full coverage of 1st party and 3rd party signer policies, and [4] SSP/ASP when policy was separated from DKIM to create DKIM-BASE. SSP/ASP was replaced with, [5] ADSP which was limited to 1st party and ambiguous 3rd party signer support which was replaced with, [6] DMARC with its limited 1st party only support, punting on addressing the 3rd party signer issue. Short of reporting and SPF integration, DMARC did not bring any more to the DKIM Policy design picture. All of the DKIM Policy proposals offered the same power for highly detectable, enforcible direct mail, exclusive and restrictive 1st policies. From day one, a few of the key cogs here stated for the most part, "No will ever use an exclusive DKIM policy, and if so, it will be an extremely narrow case with small guys, and we don't about them" was the prevailing attitude about DKIM Policy protocols. Thanks to a non-IETF Trade Group who filled in the abandoned IETF DKIM Policy ADSP model with "Super ADSP" aka DMARC, that all changed with domains, of all sizes, switching to restrictive, rejectable DMARC policy and the verifiers where beginning to honor it. It brought the DKIM Policy theory into practice along with the unhandled indirect 3rd party resigner list problem. > Nothing more and nothing less. +1 for the most part. -- HLS From nobody Fri Jun 5 08:35:42 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B53A07C3 for ; Fri, 5 Jun 2020 08:35: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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 uSQc5e1-t-Me for ; Fri, 5 Jun 2020 08:35:37 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 89D893A07BC for ; Fri, 5 Jun 2020 08:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591371334; bh=mzbvEcERG90EzLtz/Bb+ZEUsjF44j6i7ZIT0tcga0pg=; l=1452; h=To:References:From:Date:In-Reply-To; b=B3AOcoGVpTv8YbRj3j37UPDvRcGsT9x57MD4rSJ6qiWG/WYtrs0rNVAYZ/lstwzQb A7qWKI6XY+NQE/tysb/6fJm+nLjuYqMnKHqmAVDCVd2qdzFEVlz/7tIjbq3xWLHGxM nMg3kz03tsPpguonmCsY/cwcMwoOlONsVcAP6XjhoDap7cwjjT7qpoI1v5gKF Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B7.000000005EDA6646.00000E4F; Fri, 05 Jun 2020 17:35:34 +0200 To: dmarc@ietf.org References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <5ED86A48.5090801@isdg.net> <5EDA304E.40601@isdg.net> From: Alessandro Vesely Message-ID: <5725645a-55cb-95ef-1796-0822501007f3@tana.it> Date: Fri, 5 Jun 2020 17:35:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EDA304E.40601@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 15:35:39 -0000 On Fri 05/Jun/2020 13:45:18 +0200 Hector Santos wrote: > On 6/5/2020 6:34 AM, Alessandro Vesely wrote: >> > >> For completeness, I'd also mention conditional signatures, as a fifth point. >> They were specified, implemented and then abandoned in lieu of ARC. > > hmmmm, interesting. Where was the "Conditional Signature" proposal implemented? OpenDKIM implemented it "conditionally", that is configure --enable-conditional > I have never come across a conditional signature header.  I was not aware ARC > was a "conditional signature" or "3rd Party Authorization" protocol. IMO, ARC > has a high barrier of entry with an awful amount of complexity to implement in > order to authorize a 3rd party domain. ARC has nothing to do with conditional signatures, except for the fact that it seemed to contend by which end, sending or receiving, should the mailing list problem be tackled. In May 2016 John wrote: One approach to what we can oversimplify as the mailing list problem is to do it from the sending end, with the sender using something like conditional double signatures to say mutated messages are OK. The other is to provide data that the recipient can use to decide these mutations are OK. ARC is definitely in the latter camp, and it would be painful to have both ends arguing about how OK stuff is. [https://mailarchive.ietf.org/arch/msg/dmarc/BUmNmm9aODMhY_6jdM7Y52S-o7E/] Best Ale -- From nobody Fri Jun 5 14:26:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2992F3A0DF7 for ; Fri, 5 Jun 2020 14:26:32 -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 (1024-bit key) header.d=bluepopcorn.net 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 z-snQz_OpYhg for ; Fri, 5 Jun 2020 14:26:30 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 721AC3A0DF2 for ; Fri, 5 Jun 2020 14:26:30 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:ed37:e39e:255f:f19e]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 055LQPmE018342 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 5 Jun 2020 14:26:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591392387; bh=WvZdWrn2+XmlJztYFb6RKxhopBpCVcH1EckPKHpcEtc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S9QngBcAcqXmknDGeGDqXMWs2kRBXwNG48uz/U87AGu4xfShGX4Ufilp1LmvrxnF2 vaB34LoS2rKWPSYya4jg56kWKgFxJktnDzjecZzZ8Pdy5DOWqKoFYeomuMS3rBe+4C zmauwKgMszenumCQn6mT46RaRWr0nQvd7hT0TkVE= To: Dotzero Cc: "dmarc@ietf.org" References: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Fri, 5 Jun 2020 14:26:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0E9A92FCAD15B2E5876B2FBA" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 21:26:32 -0000 This is a multi-part message in MIME format. --------------0E9A92FCAD15B2E5876B2FBA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/4/20 10:39 PM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. > Nothing more and nothing less. It helps receiving systems identify a > (correctly) participating domain's mail. That is why a DMARC policy is > often described as a sending domain's request and local policy is so > important (and can override that request). I'm not clear on what kind of direct domain abuse you're referring to. If we accept that domain names are either not visible or are ignored by the recipient, the domain name doesn't matter much as long as the attacker can get their message delivered, and DMARC doesn't apply because they're using their domain. > > For attackers that deploy DMARC it simply means that they are self > identifying their malicious messages as theirs. No, DKIM and SPF do that. DMARC doesn't have anything to do with identifying messages. > > For Sending domains,=C2=A0SPF/DKIM/DMARC is only one set of tools in > protecting their brand from abuse. It protects end users from abuse. > In fact, in many cases the individuals most susceptible to falling > prey to such abuse may not even be customers of that sending domain. > No, that greeting card you received isn't legit (Nobody loves you). > No, that retailer isn't giving you a $200 gift card. This is why other > tools like takedowns are so important and why the removal of > registrant information from domain registrations has enabled abusers. So maybe the core question here is, does the identity in the domain name matter or not? It does to me personally because I look at it (whenever I can -- my iPhone doesn't make it easy to display) and I pay attention to it. But I know I'm not a typical user, and I also see increasing evidence of mail client software that doesn't show anything but the Friendly Name. So is there a "brand" associated with the email domain name any more? If the domain name doesn't matter, the binding to the From/Signer address doesn't either. -Jim --------------0E9A92FCAD15B2E5876B2FBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/4/20 10:39 PM, Dotzero wrote:

The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing more and nothing less. It helps receiving systems identify a (correctly) participating domain's mail. That is why a DMARC policy is often described as a sending domain's request and local policy is so important (and can override that request).
I'm not clear on what kind of direct domain abuse you're referring to. If we accept that domain names are either not visible or are ignored by the recipient, the domain name doesn't matter much as long as the attacker can get their message delivered, and DMARC doesn't apply because they're using their domain.

For attackers that deploy DMARC it simply means that they are self identifying their malicious messages as theirs.
No, DKIM and SPF do that. DMARC doesn't have anything to do with identifying messages.

For Sending domains, SPF/DKIM/DMARC is only one set of tools in protecting their brand from abuse. It protects end users from abuse. In fact, in many cases the individuals most susceptible to falling prey to such abuse may not even be customers of that sending domain. No, that greeting card you received isn't legit (Nobody loves you). No, that retailer isn't giving you a $200 gift card. This is why other tools like takedowns are so important and why the removal of registrant information from domain registrations has enabled abusers.

So maybe the core question here is, does the identity in the domain name matter or not? It does to me personally because I look at it (whenever I can -- my iPhone doesn't make it easy to display) and I pay attention to it. But I know I'm not a typical user, and I also see increasing evidence of mail client software that doesn't show anything but the Friendly Name. So is there a "brand" associated with the email domain name any more?

If the domain name doesn't matter, the binding to the From/Signer address doesn't either.

-Jim


--------------0E9A92FCAD15B2E5876B2FBA-- From nobody Fri Jun 5 15:37:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3519B3A0ED1 for ; Fri, 5 Jun 2020 15:37:57 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=gtm1wvXh; dkim=pass (2048-bit key) header.d=kitterman.com header.b=PCfIzQNd 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 zQfqxC3Yj1az for ; Fri, 5 Jun 2020 15:37:55 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BBF3A0ECD for ; Fri, 5 Jun 2020 15:37:55 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 12878F80295 for ; Fri, 5 Jun 2020 18:37:53 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591396672; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=OmHXP6vXazPoaHSP+XqS2Q1F5WNYiBVf5KhixzjDCTE=; b=gtm1wvXhQvOpUbHQgT36hoeQWhcOhg65xgSFRMaAYo2dtqr4yTDVHVOa6mgAo/5RvU+mA OkmvigvmzBIuuYdAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591396672; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=OmHXP6vXazPoaHSP+XqS2Q1F5WNYiBVf5KhixzjDCTE=; b=PCfIzQNdVHhjwFiCENpmZ4eEF6ldgPEJWhEt2qQsXECEbX+MydE44qXkcfhxy7FUMDtUG a5lwIp7W2x1UtgzQrsYxig/zjwete2pIV+HkIq13ymUenXdcwHp/qE8lprWe0HWogPyFPC5 G/FUEoK4IlOh8+Aj4D56wnm3HVpvCpV4E4wDemEaRELgKvoDDyNxQm6YgQxGj3B80mxYv0J oD3CiR6nTiIfrtiPqJ/qg7ZwogToTT4JC4etif0Z5DsTJmHGp18DhmqJs2/odpifjpnQpt6 fVoWCPxcpw5//qmux/HAh9lwHL3KcfF6K3XVDtJ5PeMhbo/2xTvi4dreU8Dw== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id D55A1F801AC for ; Fri, 5 Jun 2020 18:37:52 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 05 Jun 2020 18:37:52 -0400 Message-ID: <83781802.4yxyyzPtoS@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 22:37:57 -0000 On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: > On 6/4/20 10:39 PM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. > > Nothing more and nothing less. It helps receiving systems identify a > > (correctly) participating domain's mail. That is why a DMARC policy is > > often described as a sending domain's request and local policy is so > > important (and can override that request). > > I'm not clear on what kind of direct domain abuse you're referring to. > If we accept that domain names are either not visible or are ignored by > the recipient, the domain name doesn't matter much as long as the > attacker can get their message delivered, and DMARC doesn't apply > because they're using their domain. > > > For attackers that deploy DMARC it simply means that they are self > > identifying their malicious messages as theirs. > > No, DKIM and SPF do that. DMARC doesn't have anything to do with > identifying messages. > > > For Sending domains, SPF/DKIM/DMARC is only one set of tools in > > protecting their brand from abuse. It protects end users from abuse. > > In fact, in many cases the individuals most susceptible to falling > > prey to such abuse may not even be customers of that sending domain. > > No, that greeting card you received isn't legit (Nobody loves you). > > No, that retailer isn't giving you a $200 gift card. This is why other > > tools like takedowns are so important and why the removal of > > registrant information from domain registrations has enabled abusers. > > So maybe the core question here is, does the identity in the domain name > matter or not? It does to me personally because I look at it (whenever I > can -- my iPhone doesn't make it easy to display) and I pay attention to > it. But I know I'm not a typical user, and I also see increasing > evidence of mail client software that doesn't show anything but the > Friendly Name. So is there a "brand" associated with the email domain > name any more? > > If the domain name doesn't matter, the binding to the From/Signer > address doesn't either. If the domain name didn't matter, no one would bother to use 'real' domains in abusive mail. They demonstrably do, so while one might have differences of opinion about how important they are (every MUA I use displays them, so let's also not draw too hasty conclusions about them not being displayed) I don't think it's a supportable that they don't matter. Scott K From nobody Sat Jun 6 12:26:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C9A3A0AC4 for ; Sat, 6 Jun 2020 12:26:06 -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, 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 (1024-bit key) header.d=bluepopcorn.net 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 09WcGJZdkbtS for ; Sat, 6 Jun 2020 12:26:05 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 B01903A0AC2 for ; Sat, 6 Jun 2020 12:26:05 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:ed37:e39e:255f:f19e]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 056JQ22Z006237 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 6 Jun 2020 12:26:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591471563; bh=CLEYaoQ+urwpoN6MfG5jolOmoRZJ9T4wZIzHtBc5bso=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gFcg0WSo4B+jl7vHT0ZpBQgPoS1pB+6W6Hi5XFii9N2+iED+ZqBQ0gnbD34fA+hX1 uRRGesigMpORgoHFEWjaVvj9ENOW8ZwDrmsyYh1GECHCgb0RYZAm3ZrSoi20yNA1jH khDYkjnIgKsy2qlg/ButCS8NfKd+qJe6qJOGiIBY= To: dmarc@ietf.org References: <83781802.4yxyyzPtoS@sk-desktop> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <049dac36-6be6-aa99-ccf7-e68da4a240f9@bluepopcorn.net> Date: Sat, 6 Jun 2020 12:25:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <83781802.4yxyyzPtoS@sk-desktop> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 19:26:07 -0000 On 6/5/20 3:37 PM, Scott Kitterman wrote: > On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: >> >> So maybe the core question here is, does the identity in the domain na= me >> matter or not? It does to me personally because I look at it (whenever= I >> can -- my iPhone doesn't make it easy to display) and I pay attention = to >> it. But I know I'm not a typical user, and I also see increasing >> evidence of mail client software that doesn't show anything but the >> Friendly Name. So is there a "brand" associated with the email domain >> name any more? >> >> If the domain name doesn't matter, the binding to the From/Signer >> address doesn't either. > If the domain name didn't matter, no one would bother to use 'real' dom= ains in=20 > abusive mail. They demonstrably do, so while one might have difference= s of=20 > opinion about how important they are (every MUA I use displays them, so= let's=20 > also not draw too hasty conclusions about them not being displayed) I d= on't=20 > think it's a supportable that they don't matter. And I receive a good deal of email with friendly names like "DHL Express" or the names of friends (who apparently have suffered address book compromise) but completely unrelated domain names. I phrased my comment as a question because I really don't know the answer to this, and have been reading comments from people asserting opinions on both sides. It would simplify the discussion if the WG could reach rough consensus on this. And if the domain name doesn't matter, the WG really needs to rethink the utility of DMARC. -Jim From nobody Sat Jun 6 13:33:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671113A0C26 for ; Sat, 6 Jun 2020 13:33:04 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=EVtKolQp; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Um5JXKkj 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 sGwQP58I1Z_e for ; Sat, 6 Jun 2020 13:33:03 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1248C3A0C21 for ; Sat, 6 Jun 2020 13:33:02 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 20EF0F80230; Sat, 6 Jun 2020 16:33:00 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591475579; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=DKLU1LSP94pHCAQ6IXMRjN0H9jB7RzRopb5vMV8A3MU=; b=EVtKolQpl8MIKBom++wv6TFKyowcCaE0/POl1TjebYM98xMe8wKFfb2bZQ0sJzCsvejJ3 3fl/vKU23XAQnrzDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591475579; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=DKLU1LSP94pHCAQ6IXMRjN0H9jB7RzRopb5vMV8A3MU=; b=Um5JXKkjLfmxLKYnO1lSQF+3bmwoxz+oJ5CDNENZMPbBGi1UY0tA6s6I15RHLH/iN70Qd +QTbitydxYAgwVFgoTNynhbZ8CWnSqXxQRjh1UHu2kVWJYrbGFNZas8tICevRkWvx7/P/nQ zvJp1p806PJKmYaLkM2T8pJom0/hc9mPvJEOaKy7/4hKus/c66WKKSkDYGAkkHpzAnNeNPb TBVAnc5J6a9Yn3E2fIviCmeHj3TZNFkW3+f6s7ncgkLv2/36r9p0txzr1YbjnhQU1JuAcOB See60O5MZHwrZQIoeEP/yWLPFf7NcMKAvUKShCZyLH0QiEcA28LnpSy+6IeA== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id D040DF801DD; Sat, 6 Jun 2020 16:32:59 -0400 (EDT) Date: Sat, 06 Jun 2020 20:32:57 +0000 In-Reply-To: <049dac36-6be6-aa99-ccf7-e68da4a240f9@bluepopcorn.net> References: <83781802.4yxyyzPtoS@sk-desktop> <049dac36-6be6-aa99-ccf7-e68da4a240f9@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 20:33:04 -0000 On June 6, 2020 7:25:56 PM UTC, Jim Fenton wrot= e: >On 6/5/20 3:37 PM, Scott Kitterman wrote: >> On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: >>> >>> So maybe the core question here is, does the identity in the domain >name >>> matter or not? It does to me personally because I look at it >(whenever I >>> can -- my iPhone doesn't make it easy to display) and I pay >attention to >>> it=2E But I know I'm not a typical user, and I also see increasing >>> evidence of mail client software that doesn't show anything but the >>> Friendly Name=2E So is there a "brand" associated with the email >domain >>> name any more? >>> >>> If the domain name doesn't matter, the binding to the From/Signer >>> address doesn't either=2E >> If the domain name didn't matter, no one would bother to use 'real' >domains in=20 >> abusive mail=2E They demonstrably do, so while one might have >differences of=20 >> opinion about how important they are (every MUA I use displays them, >so let's=20 >> also not draw too hasty conclusions about them not being displayed) I >don't=20 >> think it's a supportable that they don't matter=2E > >And I receive a good deal of email with friendly names like "DHL >Express" or the names of friends (who apparently have suffered address >book compromise) but completely unrelated domain names=2E > >I phrased my comment as a question because I really don't know the >answer to this, and have been reading comments from people asserting >opinions on both sides=2E It would simplify the discussion if the WG >could >reach rough consensus on this=2E And if the domain name doesn't matter, >the WG really needs to rethink the utility of DMARC=2E I think the market has spoken on the utility of DMARC=2E Scott K From nobody Sat Jun 6 13:45:17 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0033A0C3F for ; Sat, 6 Jun 2020 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=YGngKzlP; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=X8DCxib6 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 vZbe_xBpYIam for ; Sat, 6 Jun 2020 13:45:14 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7821A3A0C3E for ; Sat, 6 Jun 2020 13:45:13 -0700 (PDT) Received: (qmail 79165 invoked by uid 100); 6 Jun 2020 20:45:12 -0000 Date: 6 Jun 2020 20:45:11 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=13536.5edc0058.k2006; i=news@user.iecc.com; bh=3k5nZupfaWc0XBZw1agErzlKU2Urkq9JXsM/XKDzNlE=; b=YGngKzlPraHJUB4PcgBYd/bUCf3If8jZT/2L2rhLfL22qxQGbw1LIdOEViAz7ER0LW+rm+cATltCCK8mLaex+v1u77AUv0+baNCfU3pFEJqW5uqQ8lLnEadLoZJoG7u2Mt3hspd3EgWfAP5zYgRquLBEmUYoLjrC/peES95751LAckw+erY7mIWVJMlT6yE1a+I+SwkwbnO+cw8bxj6Fca59uExbNwUeqYy2ZX7+Tnwh/Q78uIWUgjMmrq7hM8xk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=13536.5edc0058.k2006; olt=news@user.iecc.com; bh=3k5nZupfaWc0XBZw1agErzlKU2Urkq9JXsM/XKDzNlE=; b=X8DCxib6dEETGBYszHsWOUGztDvKm02FlH6KkkPiRx1sRXSRFiq0qemWBQ3pdxp3jI5JQEL7+yT03/My3La3K1U2tbZGLJjYKW+NompQxz0mgmy/VtDDwKLwNkfutEaYs7tiuhonU91Q1pubAUKpDzsorh4TA1kSx5SnH9wTPF8YaWB8NEL7rHFYdb4kvx6lC8GTl2hFgWabjpoBlLJiAMFSGJT2pC+ris6vP7xo6KagwmKTykgmY6g+rff4/imV Organization: Taughannock Networks References: <83781802.4yxyyzPtoS@sk-desktop> <049dac36-6be6-aa99-ccf7-e68da4a240f9@bluepopcorn.net> In-Reply-To: <83781802.4yxyyzPtoS@sk-desktop> <049dac36-6be6-aa99-ccf7-e68da4a240f9@bluepopcorn.net> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 20:45:16 -0000 In article , Scott Kitterman wrote: >I think the market has spoken on the utility of DMARC. There's no question that it was highly successful at Yahoo and AOL after they let crooks steal their address books at reducing the amount of spam their users received that forged addresses in those stolen address books. Of course, if you are not Verizon Media, who cares? I gather it is also quite effective against phishes that for some reason put the actual target's domain in the From: address, but at this point I don't know how common that is relative to phishes that put it in the From: comment, viz. Jim's question. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 6 14:23:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCEA3A0CDD for ; Sat, 6 Jun 2020 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=OQ7blfd5; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Hb3o8X0B 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 R9qxwQ-Js9pv for ; Sat, 6 Jun 2020 14:23:21 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99EA3A0CF2 for ; Sat, 6 Jun 2020 14:23:21 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id D3CCBF80230 for ; Sat, 6 Jun 2020 17:23:20 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591478600; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=2WMhtvSxUVXUBJyZxYDj6iE4Kw04MAZN8AMHVK1NKLE=; b=OQ7blfd5DyBGpxmTFCkt4TLV0AxXUDuhlsU51fdFf+IPPt1Onb6ALjXTVng1nQHTlyfZ3 yFBH5FB9gjL1ycgDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591478600; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=2WMhtvSxUVXUBJyZxYDj6iE4Kw04MAZN8AMHVK1NKLE=; b=Hb3o8X0BFvhEjywKcwSytB+PateDc3pucBLS+JIwaXonflmVg8TCElfhqvpMheo3lA1xd /Ak40XnojM0DcsAazkSqI6jY0BWvVe6LenhIZaQphA0s5c54y/z8ylcPHHy1MFZO6yyZYHu 0XCYbfbHxx0wTM+0zrbLMwzW6e7Le3naXuCgkTC4Ooo4zJ3vM3B7soaVVjkdDC6WqBQIbVp Te8vWiKbwum8KI83EdI2TAETPKE6RhzTXNN4KTE9/B2wABiB7PQgpKVxc5qtnHKJEfdcMg9 i6VLiANvtRJfeu2R+QOmbzs/JWiLKa3VTuNXxNGJyWzxTt28Kk1H7dLiWcMA== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id A7E25F801DD for ; Sat, 6 Jun 2020 17:23:20 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 06 Jun 2020 17:23:20 -0400 Message-ID: <11640715.3lbasgNmsr@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 21:23:23 -0000 On Saturday, June 6, 2020 4:45:11 PM EDT John Levine wrote: > In article , > > Scott Kitterman wrote: > >I think the market has spoken on the utility of DMARC. > > There's no question that it was highly successful at Yahoo and AOL > after they let crooks steal their address books at reducing the amount > of spam their users received that forged addresses in those stolen > address books. Of course, if you are not Verizon Media, who cares? > > I gather it is also quite effective against phishes that for some > reason put the actual target's domain in the From: address, but > at this point I don't know how common that is relative to phishes > that put it in the From: comment, viz. Jim's question. I'm not sure how important a question it is. It used to be quite common. If it's not anymore (I don't have access to a current data set big enough to really have an opinion), then I'd suggest that it's because abusers are, at least to some degree, deterred from doing so. If things like DMARC, SPF, and DKIM do nothing more than get abusers to use different domains than they would otherwise, I think that's a win. Unfortunately it's quite difficult to measure the deterrent effect associated with these mechanisms. I would expect that using different domains would make the filtering problem easier to solve, so even if the domain presented to end user doesn't matter (I think it does, but meh), pushing abusive mail to use other domains helps solve the filtering problem. Scott K From nobody Sat Jun 6 14:26:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22CC3A0D13 for ; Sat, 6 Jun 2020 14:26:14 -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, FREEMAIL_FROM=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=gmail.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 s4VVpf6-bAYL for ; Sat, 6 Jun 2020 14:26:13 -0700 (PDT) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 D43E03A0D23 for ; Sat, 6 Jun 2020 14:26:12 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id v79so13513968qkb.10 for ; Sat, 06 Jun 2020 14:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YrjdnqQhjwUQo9aVeziV/Kf2TN1n1jTJG3n//tCMqSU=; b=l6azAwPZpTkg1DyvV711PRpQrX9iId9QX8oynjpqa2N4F8tHIu2d4XGplTeOXFro4J hENDXOJLmRzZLCscPLw9dTrXM0GwYf9C2tdAAXtDOH7Sq3CBrI4+WAuh+gjmY6SU+v7q q47xn0izb65A1Pd4887PQr9Apgq29Ag8nElXqyb7zzI5dWPXlEJV+iBDMC56b5Ir5y1B EwJ4nHHCpQF23YjHWPBzyGq/KG468WBbz960xVV7/Zv8cV29r25g8HIYYLXwFg6ejc/C 60h3Nxpu/L9VG43INmcdzFWKtSNhDz2GLjRIA16kSFe18Rcm7e1FMp+CsIQOZfQaysst mMnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YrjdnqQhjwUQo9aVeziV/Kf2TN1n1jTJG3n//tCMqSU=; b=qxyLjLLxBiCqloKsdRw/zW426CVswAz+gjv0QfTJ7hrzAeqxeYy5VVZFWaA3i2JZ7U jYt6xeaun3Yr7Rs/Xo+6djcLEIKKw2knV+2G8SiaPo89R7FsiZaNtGAxvwjQnL1wBQOA qmFstuJ1GvIywYA9tGYi04pIcI0MGLchKGCrT5IcOpfs4UU4ss6Jklv+XnlkN6Rznh3i BJS6/90e5ZWKrHdX5v4AzB7DenJ6zGKZYAdOfCyfLc+8Dp5AZfw2uI3aYqDCybSWdEPG v7l3jZCQlY+8Aap+kpx867ntB991RHF/OxrS0uNHwC1gKaYAz5JCAReUchir4LXIDAku T/Fg== X-Gm-Message-State: AOAM530sS4PnkDqo09TQQMNuQsnbDWlOi+bzyVcK6SJnhxmMT4Y4N4fp oxIKkTJ+PVG9w6Bpmc+4kBKPkBPI X-Google-Smtp-Source: ABdhPJxI9nn4yHSlOeldNphGv3KqdHKCpn5jid8AwUDzKeJcnYki+hQ2r9d+T5eR37ILn3GyllAIhg== X-Received: by 2002:a05:620a:4fa:: with SMTP id b26mr16187564qkh.63.1591478771624; Sat, 06 Jun 2020 14:26:11 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:348c:a0a2:a094:ddee? ([2600:1700:a3a0:4c80:348c:a0a2:a094:ddee]) by smtp.gmail.com with ESMTPSA id y185sm3188308qkd.83.2020.06.06.14.26.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 14:26:11 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> From: Dave Crocker Message-ID: <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> Date: Sat, 6 Jun 2020 14:26:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <11640715.3lbasgNmsr@sk-desktop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 21:26:18 -0000 On 6/6/2020 2:23 PM, Scott Kitterman wrote: > If things like DMARC, SPF, and DKIM do nothing more than get abusers to use > different domains than they would otherwise, I think that's a win. The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of the 3 that restricts the choice of domain name. With that in mind, I'll ask you why you think the kind of change you cite is a win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 6 14:28:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38793A0D0B for ; Sat, 6 Jun 2020 14:28:45 -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, FREEMAIL_FROM=0.001, 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=gmail.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 UWVmMfiYD69N for ; Sat, 6 Jun 2020 14:28:44 -0700 (PDT) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 1EB623A0D0A for ; Sat, 6 Jun 2020 14:28:44 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id t18so13406616wru.6 for ; Sat, 06 Jun 2020 14:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+w2aAAcm5qNHCbxFNchLPbhJq+BPXw0X9siOxUQtasc=; b=STCFqP3mSHB0ZfURwc094p5A/TXEpzS1Zg0sVuQTE4cuX7our5TXF0prwzSzNwAO2u ajrZzp3oYrdHsoWnqnXMed4km0egfBDIg1LruhKFzHYeZhRiZiGjqu/APcemxy0WA8Va Qfrg3oZZZKJwxCRf8/cGjRc7387G+BIG+/y2cXZeRrdOOzzW18Rg+xgwRPipNHWuzPuu 3bh06PcQm4bUH9yOeneiojg/ambuu4ddSi+rhQ4Ass62O9e9WyAymqPJiv6Yd3rM2lE+ u5Tt9+5ml2bY8RjNIBEi1HFh7XIQabMh3YhrK+1SxtSol7AEPBNT0tUJWK3zSn46Ft6I 77xQ== 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=+w2aAAcm5qNHCbxFNchLPbhJq+BPXw0X9siOxUQtasc=; b=Jmjq6adc2tsblkgpLdi7nRyuQBKkj9TJZBWF7kogyx9U9Ra33qkIaeX9EUo2A/VP9G /aYF36p0eJAFbLguIjVLjJMXYqUHUr7KafGwrLJZtznPP6KXpVArNcM5odhHr2KS2Uy7 JPE5H1xwYNn7DTh97uFWbqx94ZsksBrEF3oD2riAYogYmi0WYS5dUOr6FFfz2J6xBMLg jHIEJbqTyD9d67Iy8R7ws4UeR1f47CCj0QFEqrYqs9HpTW2w13tzipO3DGoIMtOB93zJ IY45ca7eYvYGk320eprtobokFpOXMVfFLr+uIpcV7AgxsP74c8GuMzgrDxcxroBkHxAd fahg== X-Gm-Message-State: AOAM5336mANf3ya+2pMGHIxz/cF/SlMCvrtahriSlVYY70p+4jGKvYBi v+4s/awEDvHHXS+ebshKBbq4ytz91axUQBNtkw1H5zyskdQ= X-Google-Smtp-Source: ABdhPJxjbU8Ygx5XJLKCX0GkOogJ1mNX5dsbksl7Zz3Tu8egXyFWjRDX8Lm7qH2MUKVnFZSThTmzArOkrHAB2yn6CSI= X-Received: by 2002:adf:dccc:: with SMTP id x12mr15535396wrm.72.1591478921298; Sat, 06 Jun 2020 14:28:41 -0700 (PDT) MIME-Version: 1.0 References: <114ec030-dbc9-bf7d-a453-e5cf3dd3f642@bluepopcorn.net> In-Reply-To: From: Dotzero Date: Sat, 6 Jun 2020 17:28:21 -0400 Message-ID: To: Jim Fenton Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c584e205a7710f8f" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 21:28:46 -0000 --000000000000c584e205a7710f8f Content-Type: text/plain; charset="UTF-8" On Fri, Jun 5, 2020 at 5:26 PM Jim Fenton wrote: > On 6/4/20 10:39 PM, Dotzero wrote: > > > The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing > more and nothing less. It helps receiving systems identify a (correctly) > participating domain's mail. That is why a DMARC policy is often described > as a sending domain's request and local policy is so important (and can > override that request). > > I'm not clear on what kind of direct domain abuse you're referring to. If > we accept that domain names are either not visible or are ignored by the > recipient, the domain name doesn't matter much as long as the attacker can > get their message delivered, and DMARC doesn't apply because they're using > their domain. > > > The type of direct domain abuse where someone attempts to send a message using in the From email address field. As I wrote earlier, the combination of SPF/DKIM/DMARC is a tool that accomplishes a narrow goal. It is not a silver bullet that solves all forms of abuse. It can be used to mitigate a specific type of abuse. > For attackers that deploy DMARC it simply means that they are self > identifying their malicious messages as theirs. > > No, DKIM and SPF do that. DMARC doesn't have anything to do with > identifying messages. > > > As with SPF and DKIM, some abusers were quick to implement DMARC in addition to SPF and/or DKIM on the theory that it makes their email appear more legitimate to receivers. Just one more nail in the coffin. > For Sending domains, SPF/DKIM/DMARC is only one set of tools in protecting > their brand from abuse. It protects end users from abuse. In fact, in many > cases the individuals most susceptible to falling prey to such abuse may > not even be customers of that sending domain. No, that greeting card you > received isn't legit (Nobody loves you). No, that retailer isn't giving you > a $200 gift card. This is why other tools like takedowns are so important > and why the removal of registrant information from domain registrations has > enabled abusers. > > So maybe the core question here is, does the identity in the domain name > matter or not? It does to me personally because I look at it (whenever I > can -- my iPhone doesn't make it easy to display) and I pay attention to > it. But I know I'm not a typical user, and I also see increasing evidence > of mail client software that doesn't show anything but the Friendly Name. > So is there a "brand" associated with the email domain name any more? > There is. Don't get hun up on what is displayed to the end user. Think about the reporting aspect. In my previous incarnation we were able to initiate takedowns and/or blocking by 3rd parties much more quickly based on DMARC reports than simply waiting for end user complaints to customer service or abuse@. > If the domain name doesn't matter, the binding to the From/Signer address > doesn't either. > > -Jim > It does matter for the specific abuse scenario. Those particular abusive mail streams never get to the end user recipient. I'm basing this on my experience on a corpus of billions of emails sent for what had been previously highly abused domains/brands. For other types of abuse we implemented other types of mitigation approaches. Collectively those approaches reduced abuse by over 95%. The goal was to reduce ROI for the bad guys to the point that they would look for greener pastures. You are implying/assuming that DMARC solves the problem of a wider scope of abusive email types than it does. The Display Name (Mail From) is a particularly thorny problem to solve in that it is not tied to anything in that it is a free form field into which anything can be entered. Michael Hammer --000000000000c584e205a7710f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 5, 2020 = at 5:26 PM Jim Fenton <fenton@= bluepopcorn.net> wrote:
=20 =20 =20
On 6/4/20 10:39 PM, Dotzero wrote:
=20

The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing more and nothing less. It helps receiving systems identify a (correctly) participating domain's mail. That is why a DMARC policy is often described as a sending domain's request and local polic= y is so important (and can override that request).
I'm not clear on what kind of direct domain abuse you're referr= ing to. If we accept that domain names are either not visible or are ignored by the recipient, the domain name doesn't matter much as long as the attacker can get their message delivered, and DMARC doesn't apply because they're using their domain.

The type of direct domain abuse where someone attempts to se= nd a message using=C2=A0<fento= n@bluepopcorn.net> in the From email address field. As I wrote earli= er, the combination of SPF/DKIM/DMARC is a tool that accomplishes a narrow = goal. It is not a silver bullet that solves all forms of abuse. It can be u= sed to mitigate a specific type of abuse.
=C2=A0
For attackers that deploy DMARC it simply means that they are self identifying their malicious messages as theirs.
No, DKIM and SPF do that. DMARC doesn't have anything to do with identifying messages.

As with SPF and DKIM, some abusers were quick = to implement DMARC in addition to SPF and/or DKIM on the theory that it mak= es their email appear more legitimate to receivers. Just one more nail in t= he coffin.
=C2=A0
For Sending domains,=C2=A0SPF/DKIM/DMARC is only one set of tools in protecting their brand from abuse. It protects end users from abuse. In fact, in many cases the individuals most susceptible to falling prey to such abuse may not even be customers of that sending domain. No, that greeting card you received isn't legit (Nobody loves you). No, that retailer isn't giving you a $200 gift card. This is why other tools like takedowns are so important and why the removal of registrant information from domain registrations has enabled abusers.

So maybe the core question here is, does the identity in the domain name matter or not? It does to me personally because I look at it (whenever I can -- my iPhone doesn't make it easy to display) and I pay attention to it. But I know I'm not a typical user, and I also see increasing evidence of mail client software that doesn't show anything but the Friendly Name. So is there a "brand" associated with the email domain name any more?

=
There is. Don't get hun up on what is displayed= to the end user. Think about the reporting aspect. In my previous incarnat= ion we were able to initiate takedowns and/or blocking by 3rd parties much = more quickly based on DMARC reports than simply waiting for end user compla= ints to customer service or abuse@.

If the domain name doesn't matter, the binding to the From/Signe= r address doesn't either.

-Jim

It does matter for the specific = abuse scenario. Those particular abusive mail streams never get to the end = user recipient. I'm basing this on my experience on a corpus of billion= s of emails sent for what had been previously highly abused domains/brands.= For other types of abuse we implemented other types of mitigation approach= es. Collectively those approaches reduced abuse by over 95%. The goal was t= o reduce ROI for the bad guys to the point that they would look for greener= pastures. You are implying/assuming that DMARC solves the problem of a wid= er scope of abusive email types than it does. The Display Name (Mail From) = is a particularly thorny problem to solve in that it is not tied to anythin= g in that it is a free form field into which anything can be entered.
=

Michael Hammer
--000000000000c584e205a7710f8f-- From nobody Sat Jun 6 14:42:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18C93A0D62 for ; Sat, 6 Jun 2020 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Pazygqih; dkim=pass (2048-bit key) header.d=kitterman.com header.b=klKOHQNK 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 ASIEL8KZLEZp for ; Sat, 6 Jun 2020 14:42:38 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FFB3A0D61 for ; Sat, 6 Jun 2020 14:42:38 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 2523EF80230 for ; Sat, 6 Jun 2020 17:42:38 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591479758; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=8xm7dhwsp58+Z8d3o9FxJ7R7cdXWYNEsg3Ho+2v15/M=; b=Pazygqih+O0sCHkMIqYTsjAaac6cdAGPp6FPELTwv/fzgCubGP/FEeGwevACb/oiUwCw5 tg+taIILAxEeR4DDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591479757; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=8xm7dhwsp58+Z8d3o9FxJ7R7cdXWYNEsg3Ho+2v15/M=; b=klKOHQNKDhY78u1RPT+WRyDWQe330YWHDS0cTYfIKpeNJSkTkXlc/QXo1VrwaW5Al4ZkT Mj+z3LELXxJQf0OILpeB9VnCa56YjvDNzdyCgXucSvfGuz5FSS941pkkff6rXBGrVVUrekc e2HTm5gPXOtK067jNq9KCnBWkDEhkiWq7NU3kEBFn7nvf8wXPrIldZyjuB0wJHJPbukKbVn jM0YFSKkwMIvXL307HDOYlONHzFg8FFF8PJpj4o5+IjbtdL666Y+W9iRyYC16jdEIN14zLl RtAL183G+By3TihOwYfi3TmeLdXTk1S/g+glPUkmo2JLbzTWp032DpssapLg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E18CCF801DD for ; Sat, 6 Jun 2020 17:42:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 06 Jun 2020 17:42:37 -0400 Message-ID: <3138524.EPDo7oxCqE@sk-desktop> In-Reply-To: <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 21:42:40 -0000 On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: > On 6/6/2020 2:23 PM, Scott Kitterman wrote: > > If things like DMARC, SPF, and DKIM do nothing more than get abusers to > > use > > different domains than they would otherwise, I think that's a win. > > The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of > the 3 that restricts the choice of domain name. > > With that in mind, I'll ask you why you think the kind of change you > cite is a win. 1. I think the domain displayed to the end user matters. In my sample size of 1, it matters to me. I know I'm not the average user, but independent of the question of how many users it matters to, there are some. 2. When abusers use different domains to send mail, it adds more information for filters to work on, so even if this is all about filtering, that works better too. Scott K From nobody Sat Jun 6 15:03:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DBE3A0E06 for ; Sat, 6 Jun 2020 15:03:37 -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, 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 (1024-bit key) header.d=bluepopcorn.net 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 QU-5B_rM53MG for ; Sat, 6 Jun 2020 15:03:35 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 8831F3A0E05 for ; Sat, 6 Jun 2020 15:03:35 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:3509:e130:7dd6:7dc5]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 056M3XTl008349 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 6 Jun 2020 15:03:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591481015; bh=UVLcSRPXGo6toGTK8JIj4zidoylFaObhi5KQFfkCJaM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QD9y3IA/quCrHYD4OrSIHEh+BcrenQ65Dhgs/U1mgc2kfLwfzisNTnFrMcSxwE7oh dZuCLSGq647dw/3Nq/CG3q48ZjFSR4S2Gmf0N4brv7k43DRiWzFjNe7fs5liUuvuUe w+N9onzhy83bOEIVdauChzxGThhlfwUgrzAc5YS4= To: dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> Date: Sat, 6 Jun 2020 15:03:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3138524.EPDo7oxCqE@sk-desktop> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 22:03:37 -0000 On 6/6/20 2:42 PM, Scott Kitterman wrote: > On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>> If things like DMARC, SPF, and DKIM do nothing more than get abusers = to >>> use >>> different domains than they would otherwise, I think that's a win. >> The issue here is DMARC, not SPF or DKIM, since DMARC is the only one = of >> the 3 that restricts the choice of domain name. >> >> With that in mind, I'll ask you why you think the kind of change you >> cite is a win. > 1. I think the domain displayed to the end user matters. In my sample= size=20 > of 1, it matters to me. I know I'm not the average user, but independe= nt of=20 > the question of how many users it matters to, there are some. Same with me, but again I'm not the average user. > > 2. When abusers use different domains to send mail, it adds more infor= mation=20 > for filters to work on, so even if this is all about filtering, that wo= rks=20 > better too. But when abusers use different domains, the DMARC policy that applies is controlled by them and is therefore meaningless. And the reports, if any (probably none), are sent back to the attacker or their designate. Filtering might be done based on the DKIM signing domain or the envelope-from domain if SPF is used, but neither of those require DMARC. -Jim From nobody Sun Jun 7 03:18:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570CE3A0CE4 for ; Sun, 7 Jun 2020 03:18:53 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 6_feQyP6MRDO for ; Sun, 7 Jun 2020 03:18:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 751443A0CE1 for ; Sun, 7 Jun 2020 03:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591525125; bh=rYHQ+G/pPUCHV/jh4OsxILGzkxmR0TFHdEdpAG/l7l8=; l=2561; h=To:References:From:Date:In-Reply-To; b=Bit+G+F3lWZqdSfQ2hDY+hDpn4BDYOtCOvEUfeX3pBNEY/8qx0xjGv+PGA3bH1TTM 9RW5bkudozqWpla8wO3Cts+TZavIYddlIV+9V3qnRhXRuWvJOZv+DVzmj69m5b51kk 8++M3rhgM20pw9BVzumFrAfB465q0aq4b0FMYUJkISxLZVFR+HCrS3NdrmmLz Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005EDCBF05.00004E74; Sun, 07 Jun 2020 12:18:45 +0200 To: dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> From: Alessandro Vesely Message-ID: Date: Sun, 7 Jun 2020 12:18:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 10:18:53 -0000 On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>>> If things like DMARC, SPF, and DKIM do nothing more than get abusers >>>> to use different domains than they would otherwise, I think that's a >>>> win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of >>> the 3 that restricts the choice of domain name. >>> >>> With that in mind, I'll ask you why you think the kind of change you >>> cite is a win. >> 1. I think the domain displayed to the end user matters. In my sample size >> of 1, it matters to me. I know I'm not the average user, but independent of >> the question of how many users it matters to, there are some. > Same with me, but again I'm not the average user. +1, but then we're mailing list subscribers (leaving aside this list's topic.) >> >> 2. When abusers use different domains to send mail, it adds more information >> for filters to work on, so even if this is all about filtering, that works >> better too. > > But when abusers use different domains, the DMARC policy that applies is > controlled by them and is therefore meaningless. And the reports, if any > (probably none), are sent back to the attacker or their designate. > > Filtering might be done based on the DKIM signing domain or thesimilar > envelope-from domain if SPF is used, but neither of those require DMARC. The From: domain was chosen because that's the field that users can see. Now we conjecture that users don't actually see it. Oh boy. Certainly, if the From: domain is not visible we could filter on X-Filter-On-Me: and gracefully avoid the mailing list problem. On closer view, we seem to be discovering that the From: domain is obscured by the display name. We always neglected the display name. Furthermore, by letting the mailing list problem be dodged by creative From: rewriting, such as From: User@Example.com we are granting full citizenship to devious display names. Some clients (e.g. Thunderbird) can show only display name for people in the address book.[*] A close, perhaps formally easier, subject is the IDN homograph attack.[†] Would it make sense to ban, say, the use of the at sign (@) in display names? Best Ale -- [*] https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displayed [†] https://en.wikipedia.org/wiki/IDN_homograph_attack From btv1==427d487c9ec==fosterd@bayviewphysicians.com Sun Jun 7 06:16:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29843A0818 for ; Sun, 7 Jun 2020 06:16:36 -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 (1024-bit key) header.d=bayviewphysicians.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 7ZesxGDtDsJh for ; Sun, 7 Jun 2020 06:16:34 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACCE3A0816 for ; Sun, 7 Jun 2020 06:16:33 -0700 (PDT) X-ASG-Debug-ID: 1591535788-11fa313a1090f50001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id q8q4deJWEzIuZ0vF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 07 Jun 2020 09:16:29 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=jDMGwo7YthI8ZH2eDhY4SacUMRlCXMIQEdDz1Eo7sHw=; b=oltKhxuQNZZVv/IOdUXdBOBdaSrpykhgV6plOaYpGuiVIhHA1E8HEuMea1dXoWGJ9 YI5wFT19o6e6r/P9ifVOruqgX91zp1vN+CtG8a88uEPbFWe3f5NjGMsCb5M/CF5mP 9jxHXzTltZru0J3tNr9oGg3+3XqQjKnvCx30fi+IM= From: "Douglas E. Foster" To: Date: Sun, 07 Jun 2020 13:16:21 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields Reply-To: fosterd@bayviewphysicians.com Message-ID: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=32de30de0f944a3a9768dea585aa106d In-Reply-To: References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> X-Exim-Id: 14fe18acad53467a8027e680dfc1067e X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1591535789 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10762 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82388 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 13:58:35 -0000 This is a multipart message in MIME format. --32de30de0f944a3a9768dea585aa106d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1) The original assertion, that DMARC creates a conflict with prior specifi= cations, appears to be undefended and incorrect. For From Addressing, It = merely establishes some boundaries that the sender and the recipient choose= to consider appropriate. For DKIM, it creates a use-case for a technolo= gy that was initially defined without any use cases. Consequently, I thi= nk this topic is ready for closure. 2) Some of the discussion appeared to resolve around the assertion that DMA= RC can have no value. Since that view is not universal, I think the proje= ct can continue with those who do believe that it adds value. 3) Some of the discussion has been about how to prevent soclal engineering = of the recipient user. This is an important topic, but not directly relate= d to the project. IETF would do well to establish some recommendations abo= ut how MUAs should behave, so that trust data can be displayed to the user.= A typical user will have access to at least three different email client= s: one on his cell phone, a product-specific web page, and a desktop produc= t like Outlook or Thunderbird. If I wanted an organization policy that c= ontrolled when Friendly Name was displayed or DMARC status was displayed, I= would have to find and distribute plug-ins to all of these products. As = best as I have been able to tell, no such plug-ins even exist for Outlook a= nd the other products do not accept extensions. There is an opportunity h= ere for valuable standardization. ---------------------------------------- From: Alessandro Vesely Sent: 6/7/20 6:19 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the us= e of the From and Sender header fields On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>>> If things like DMARC, SPF, and DKIM do nothing more than get abusers >>>> to use different domains than they would otherwise, I think that's a >>>> win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the o= nly one of >>> the 3 that restricts the choice of domain name. >>> >>> With that in mind, I'll ask you why you think the kind of change you >>> cite is a win. >> 1. I think the domain displayed to the end user matters. In my sample si= ze >> of 1, it matters to me. I know I'm not the average user, but independent= of >> the question of how many users it matters to, there are some. > Same with me, but again I'm not the average user. +1, but then we're mailing list subscribers (leaving aside this list's topi= c.) >> >> 2. When abusers use different domains to send mail, it adds more informa= tion >> for filters to work on, so even if this is all about filtering, that wor= ks >> better too. > > But when abusers use different domains, the DMARC policy that applies is > controlled by them and is therefore meaningless. And the reports, if any > (probably none), are sent back to the attacker or their designate. > > Filtering might be done based on the DKIM signing domain or thesimilar > envelope-from domain if SPF is used, but neither of those require DMARC. The From: domain was chosen because that's the field that users can see. No= w we conjecture that users don't actually see it. Oh boy. Certainly, if the From: domain is not visible we could filter on X-Filter-On-Me: and graceful= ly avoid the mailing list problem. On closer view, we seem to be discovering that the From: domain is obscured= by the display name. We always neglected the display name. Furthermore, by letting the mailing list problem be dodged by creative From: rewriting, suc= h as From: User@Example.com we are granting full citizenship to devious display names. Some clients (e.= g. Thunderbird) can show only display name for people in the address book.[*] = A close, perhaps formally easier, subject is the IDN homograph attack.[= =E2=80=A0] Would it make sense to ban, say, the use of the at sign (@) in display name= s? Best Ale -- [*] https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displ= ayed [=E2=80=A0] https://en.wikipedia.org/wiki/IDN_homograph_attack _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --32de30de0f944a3a9768dea585aa106d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
1) The original as= sertion, that DMARC creates a conflict with prior specifications, appears t= o be undefended and incorrect.   For From Addressing, It merely establ= ishes some boundaries that the sender and the recipient choose to consider = appropriate.    For DKIM, it creates a use-case for a technology = that was initially defined without any use cases.    Consequently= , I think this topic is ready for closure.

2) Some= of the discussion appeared to resolve around the assertion that DMARC can = have no value.   Since that view is not universal, I think the project= can continue with those who do believe that it adds value.

<= /div>
3) Some of the discussion has been about how to prevent soclal en= gineering of the recipient user.  This is an important topic, but not = directly related to the project.  IETF would do well to establish some= recommendations about how MUAs should behave, so that trust data can be di= splayed to the user.   A typical user will have access to at least thr= ee different email clients: one on his cell phone, a product-specific web p= age, and a desktop product like Outlook or Thunderbird.    If I w= anted an organization policy that controlled when Friendly Name was display= ed or DMARC status was displayed, I would have to find and distribute plug-= ins to all of these products.   As best as I have been able to tell, n= o such plug-ins even exist for Outlook and the other products do not accept= extensions.   There is an opportunity here for valuable standardizati= on.



From: Alessandro Vesely <vesely@tana.it>
Sent: 6/7/= 20 6:19 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of = the From and Sender header fields
On Sun 07/Jun/2020 00:03= :28 +0200 Jim Fenton wrote:
> On 6/6/20 2:42 PM, Scott Kitterm= an wrote:
>> On Saturday, June 6, 2020 5:26:08 PM EDT Dave = Crocker wrote:
>>> On 6/6/2020 2:23 PM, Scott Kitterman = wrote:
>>>> If things like DMARC, SPF, and DKIM do no= thing more than get abusers
>>>> to use different dom= ains than they would otherwise, I think that's a
>>>>= win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is = the only one of
>>> the 3 that restricts the choice of d= omain name.
>>>
>>> With that in mind= , I'll ask you why you think the kind of change you
>>> = cite is a win.
>> 1. I think the domain displayed to the en= d user matters. In my sample size
>> of 1, it matters to me= . I know I'm not the average user, but independent of
>> th= e question of how many users it matters to, there are some.
> = Same with me, but again I'm not the average user.

=
+1, but then we're mailing list subscribers (leaving aside t= his list's topic.)

>>
>> 2. = When abusers use different domains to send mail, it adds more information
>> for filters to work on, so even if this is all about filt= ering, that works
>> better too.
>
&= gt; But when abusers use different domains, the DMARC policy that applies i= s
> controlled by them and is therefore meaningless. And the r= eports, if any
> (probably none), are sent back to the attacke= r or their designate.
>
> Filtering might be done= based on the DKIM signing domain or thesimilar
> envelope-fro= m domain if SPF is used, but neither of those require DMARC.

=

The From: domain was chosen because that's the fi= eld that users can see. Now
we conjecture that users don't actual= ly see it. Oh boy. Certainly, if the
From: domain is not visible = we could filter on X-Filter-On-Me: and gracefully
avoid the maili= ng list problem.

On closer view, we seem to be dis= covering that the From: domain is obscured by
the display name. W= e always neglected the display name. Furthermore, by
letting the = mailing list problem be dodged by creative From: rewriting, such as

From: User@Example.com <actually@someone.else>

we are granting full citizenship to devious display na= mes. Some clients (e.g.
Thunderbird) can show only display name f= or people in the address book.[*] A
close, perhaps formally easie= r, subject is the IDN homograph attack.[=E2=80=A0]

Would it make sense to ban, say, the use of the at sign (@) in display nam= es?


Best
Ale
--=

[*]



























___= ____________________________________________
dmarc mailing list
dmarc@ietf.org
--32de30de0f944a3a9768dea585aa106d-- From nobody Sun Jun 7 10:03:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75F3A0A00 for ; Sun, 7 Jun 2020 10:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ZCegZv6/; dkim=pass (1536-bit key) header.d=taugh.com header.b=TgTH/4pc 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 qS-4CONHrOul for ; Sun, 7 Jun 2020 10:03:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 055F53A09FF for ; Sun, 7 Jun 2020 10:03:42 -0700 (PDT) Received: (qmail 44688 invoked from network); 7 Jun 2020 17:03:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ae8d.5edd1ded.k2006; bh=PTBouOxveypYioOE3HP3fkBKQS7s18dyQsy2JjOT4qg=; b=ZCegZv6/J2mcbPfWzB8Tb50Iw7IrMZaFV6uLxcb1TI2Dzg00hkCZ6PnMXlWDAVwOmf6XuDxvyMOU0vgAioAdOW0M+b9SR27+N2+eHkdDC2NM3x8dpbMQkfGohjXvpKqvlF8d3tf/RjF+jEN+FzKAsGDl+1aZLd0f7bfoQ1gH65oagWROO9Bag8Fn/qVTZrE/MUkZAVdqk8pv4Li2W0ilwDZhbt8BuTWT0xzG1lgImRqc18AwIPu1H2NySTnvmeLC DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ae8d.5edd1ded.k2006; bh=PTBouOxveypYioOE3HP3fkBKQS7s18dyQsy2JjOT4qg=; b=TgTH/4pcvVaX41c0k67755J2B9DI3ha+KMnIuxZO3k+HzYm5cpmrurjUJL8qKfa+zHIFrp4Ytd7OM880mFd8V0i35geWNXec9r/d1Yx2H14z/3qJK30hM+DZpyovZGd01x17uv+pYRP3zfKzy43Mhpuq1jf6apLi84/NkhArUmHWDEydNZffMV3RnGLEmkjCNKqdrqRWzVRQoHfBtw3oeBNQnYmE6qxbBVSO39vP8ZTx+mHagngmkgZ9+1CeCV8p Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 Jun 2020 17:03:41 -0000 Received: by ary.qy (Postfix, from userid 501) id 4202D1A437D4; Sun, 7 Jun 2020 13:03:41 -0400 (EDT) Date: 7 Jun 2020 13:03:41 -0400 Message-Id: <20200607170341.4202D1A437D4@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 17:03:45 -0000 In article <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> you write: >-=-=-=-=-=- >1) The original assertion, that DMARC creates a conflict with prior specifications, appears to be undefended and incorrect. It should not be controversial that DMARC can only describe a subset of valid Internet mail. The problem arises when people then assert that somehow it is our fault that we are sending mail that DMARC can't describe, typically in ways we've been using for decades, long before anyone thought of DMARC. >2) Some of the discussion appeared to resolve around the assertion that DMARC can have no value. It clearly has value to Verizon, and it apparently has value to banks and Paypal. I can't see that it has much value for me or my users, since it has screwed up all the mailing lists we use, and for whatever reason we're not big phish targets. R's, John PS: My bank chronically sends out real mail that looks like a total phish, e.g., it says there's a dubious charge on your card, click this button if it's real or that button if it's not, with the URL for neither button having any connection to any domain the bank owns. I know it's real because I know enough about the bank business to recognize the subcontractor they use, but jeez. From nobody Sun Jun 7 10:54:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E93A040F for ; Sun, 7 Jun 2020 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=y5OgwLEv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J0AEWzsf 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 7FpcxG3ThklX for ; Sun, 7 Jun 2020 10:54:26 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357953A0400 for ; Sun, 7 Jun 2020 10:54:26 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 61EAD458 for ; Sun, 7 Jun 2020 13:54:25 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 13:54:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=tunoTnYrlMfmxyuqhEQ5a2Znk/6q9zW Q7ct7zGHxvB8=; b=y5OgwLEvUfNgLlHsb440hBmWsGV2LJe5TQBG2ZuUijyrE6X U1mK/c8HW6JZD3xhToPfh8D4CcmgIs4CNa/APuEz+P30+gZmISymXg6MoUckgnuI F6YWDpawQ5XXcdIaWPXXugAL3Kl5uF2zJmOwVRBdnjs9Ij/0BUhlZfPNks/W/jV/ TTwdU40ukEQbDtLLyouUtZ9PxTgkdFJYU3MXZCdb47lvLcOgp2UxPnFgpFLtYkid tTGIXeSjM7Pr3OyKO4q7Qv74gQS+JFCASNMvGMZHjMFQ4uRPLfL5CoM59uo46gyw gvsu/77ssJ4o96+33F2l8AILk3hQUvfFZ0CRVSQ== 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=fm3; bh=tunoTn YrlMfmxyuqhEQ5a2Znk/6q9zWQ7ct7zGHxvB8=; b=J0AEWzsfbEA3gIikFVlhhl Bwn+ZoB+cK8IZxaryKJO/PL7CWDTFwm6pK6s+XrJdtKVgi1lnd8Ts/6Dx2WNwEoA U3IhHsyiNWzwgCqsvbsnEBs3gO21b1hUYnoaTEviDDqbXo/v3XeJXfL2w4hvka3I XR6aE/BGRfyu3HoQCGRB2y3cXs0PE2IZdz2ziHDR5EKja03+fF/lHw7WbyXQs/90 9iXRKQsMw9LaLXxsh2jmv/be5zD890nzb+AhUCr6VmVVjDo4WGUPT+Kk0hsbmFE/ 11rfrlDzYdWcr6LQ4xKPmfEG/62REirUxps1H92+vBrnfH+0qS45o7kFs/iLIhOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegledguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehg lhihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecuggftrfgrthhtvghrnhepie fgvddvffeikeeukeekueeiuedukeeltefhffffffduueeftdejkefggfduheegnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglh ihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C8191400A1; Sun, 7 Jun 2020 13:54:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> Date: Sun, 07 Jun 2020 13:53:54 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=01c3bfda549e4be5a576178d67b84bc2 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 17:54:28 -0000 --01c3bfda549e4be5a576178d67b84bc2 Content-Type: text/plain On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > 3) Some of the discussion has been about how to prevent soclal engineering of the recipient user. This is an important topic, but not directly related to the project. IETF would do well to establish some recommendations about how MUAs should behave, so that trust data can be displayed to the user. Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." Which is a question many have struggled to answer, given the history of users understandably wanting to pull their hair out over trust data and warnings. Stan --01c3bfda549e4be5a576178d67b84bc2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wr= ote:
3) Some of the discussion has b= een about how to prevent soclal engineering of the recipient user.  = ;This is an important topic, but not directly related to the project.&nb= sp; IETF would do well to establish some recommendations about how MUAs = should behave, so that trust data can be displayed to the user.

Assuming this can be practically done, I would= rephrase this, "...[E]stablish how MUAs should display trust data to us= ers."

Which is a question many have struggled to answer, = given the history of users understandably wanting to pull their hair out= over trust data and warnings.


Stan

--01c3bfda549e4be5a576178d67b84bc2-- From nobody Sun Jun 7 12:52:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057B3A08AF for ; Sun, 7 Jun 2020 12:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=RVEEztAV; dkim=pass (1536-bit key) header.d=taugh.com header.b=IotS0lu6 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 6lp7qNAtmJiT for ; Sun, 7 Jun 2020 12:52:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 DE39E3A08B0 for ; Sun, 7 Jun 2020 12:52:30 -0700 (PDT) Received: (qmail 65936 invoked from network); 7 Jun 2020 19:52:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1018e.5edd457c.k2006; bh=CSjLjgLzDzTcF+M2CNYc8ROktmIEdgyro0ONBI3vPlI=; b=RVEEztAV9bsUntmUqdovuH/JuVN4pmRO9UIv4Y+YoG+6Picw5lqmywzNKPDllMqXfOXIamzzLMoeo2q19F0s1kTyaOLAXtnncJbKkz7JwoChkK3bxZOrdOZBcBA4TFhbVNWgZfb10fvaZjJirMxaU035N6CP1i8NJNEJjiuPsWKVRr9+NZqSFLrnqvdpHz6yYZ4z3ISzqlYrWnexWU/BCopj64HJLbbCuqEKP12mfkFwrxgYEy9KV2PCJTQR8kQ/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1018e.5edd457c.k2006; bh=CSjLjgLzDzTcF+M2CNYc8ROktmIEdgyro0ONBI3vPlI=; b=IotS0lu67817fCdFjYvFOZAVW1hdDMT+g833KeEw642odQZ4b/Q9T8rNn3ZUsHpQCbGAD9vaEHch7++NIsDBEXOltDWuKam1dSsC4xvAkT0NCwaMVqpMn47UChnKNsXGFXlRIG9zeS1FfaleyK5Tqp2JF4+W5a1mNgH0Two4rpmrOGT62P9pZSpbni1bDK3xpg6tQ4iIfA96V1MtYqCfh69iX7w3lnFL/PCjCO9kASEPluJjtnhZD7SFT+mI2DfH Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 Jun 2020 19:52:28 -0000 Received: by ary.qy (Postfix, from userid 501) id 70FC51A44FEC; Sun, 7 Jun 2020 15:52:28 -0400 (EDT) Date: 7 Jun 2020 15:52:28 -0400 Message-Id: <20200607195228.70FC51A44FEC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: stan@glyphein.mailforce.net In-Reply-To: <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 19:52:33 -0000 In article <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> you write: >-=-=-=-=-=- > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: >> 3) Some of the discussion has been about how to prevent soclal engineering of the recipient user. This is an important >topic, but not directly related to the project. IETF would do well to establish some recommendations about how MUAs should >behave, so that trust data can be displayed to the user. > >Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." We have decades of experience that tells us that the IETF is hopeless at UI design, and our intuition is usually wrong. In particular, displaying warnings that "this may be bad" or even "this is extremely bad" is known not to work. No matter what you say, people will click through any warning to get to their kitten GIFs or porn or whatever. From nobody Sun Jun 7 13:23:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85A3A0907 for ; Sun, 7 Jun 2020 13:23:48 -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_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=sc1o3157; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HM9AAwUI 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 oT6EJQgt5oaT for ; Sun, 7 Jun 2020 13:23:47 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679073A0902 for ; Sun, 7 Jun 2020 13:23:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id BA228404 for ; Sun, 7 Jun 2020 16:23:46 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 16:23:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=ZKalgwBjrgOp3j3ksDU0DxW1BGfoNHF PP+AP7qZIe+k=; b=sc1o31570AE6vb0H/46JwTGrAumOr5lmhkjKB5Z9/8sugQt Ig1LN8PTKdefwfv2/gg5RdEbLZ4JxBK7vVmScyQ798HbLEO80XSUN0xJt6bVlQgX X8lDSqJeSfJseRDdaRYW+OGsbgtxgjgIst1S4x4y+PnKPvC/RUr2KipQBQT9IGUa MMmFFM/tTMgObVmpcMf7+BbMGEKVb5/ugjYPYHzU5R7Qm3c0sqejGTrJuEDkYqB9 EcduOsG/kvWG2pbAiJOXDI+69SUKy1exeNNyOp1RB3/w/2i4C7sA/2MWk2Z7IZoi bjxSHx4xMpH5CuTimv4WJAGO3lhMMlHX4s10FkQ== 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=fm3; bh=ZKalgw BjrgOp3j3ksDU0DxW1BGfoNHFPP+AP7qZIe+k=; b=HM9AAwUIXisEREIxOWhROM lnHteq6feU4h/0FvDB42VtjuCT1Yzk4ZGsT82C1sVdV2u7r4PTi5moirhhCxKtZI lFvtl5RCNZyVnRz1AwFctfoR1hh7HGp65Z5b3QVujSo7lfu6X0Ft9NjUGQFz7Fom xjEEakycPyB8p/8Rb6fvdatI6EunasBe031FIcVEKXkwyE41DISaUvDSXxj+/AqE WzafFQPSmL2ajsFYamTe/h2W2D7Map1Od8Zc1kms+NVnS9zc5m9Yv77xoKgujKCA DBH4Sg+xv60MBZldJn0nCV1n/NcromDEzuSO5GScaPbUOYDQJW+CNg9C2O4yDpEQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegledgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehg lhihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecuggftrfgrthhtvghrnhepff dufedutdegvdefvdeihfeiueffgeekkeeftefghfelheevhfefleeileehfeeknecuffho mhgrihhnpehfrghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhr tggvrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17C261400A1; Sun, 7 Jun 2020 16:23:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <71cddc80-008c-4f33-bdac-71ebc029bb3c@www.fastmail.com> In-Reply-To: <20200607195228.70FC51A44FEC@ary.qy> References: <20200607195228.70FC51A44FEC@ary.qy> Date: Sun, 07 Jun 2020 16:23:24 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 20:23:49 -0000 On Sun, Jun 7, 2020, at 3:52 PM, John Levine wrote: > In article <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> you write: > >-=-=-=-=-=- > > > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > >> 3) Some of the discussion has been about how to prevent soclal engineering of the recipient user. This is an important > >topic, but not directly related to the project. IETF would do well to establish some recommendations about how MUAs should > >behave, so that trust data can be displayed to the user. > > > >Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." > > We have decades of experience that tells us that the IETF is hopeless > at UI design, and our intuition is usually wrong. > > In particular, displaying warnings that "this may be bad" or even > "this is extremely bad" is known not to work. No matter what you say, > people will click through any warning to get to their kitten GIFs or > porn or whatever. I didn't know the history of the IETF's approach to UI, in particular, but I'm aware of the research on the nastiness of solving the UI problem. I mostly wanted to clarify that the problem is, indeed, *how* to show that data to users, and that no one has actually ever been able to solve that problem. Thanks, Stan From nobody Sun Jun 7 13:38:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4323A0927 for ; Sun, 7 Jun 2020 13:37:58 -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=[AC_BR_BONANZA=0.001, 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=valimail.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 u46LcLHxM49t for ; Sun, 7 Jun 2020 13:37:56 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 B7F7F3A0926 for ; Sun, 7 Jun 2020 13:37:55 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id r7so15267091wro.1 for ; Sun, 07 Jun 2020 13:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=j5nFoObm12zUu5Wt1scAipQgsmwwJ1G59ePgfUd1SZs=; b=bPgvDvYcwK70mXLHCZOi7BBRE3t0k98rUiLHcJ0qDfKJdVezl8mX44EXPjax+DsiEY aj5DTXZh6WFVpvQeTXjIUafxro8Ve7avmQKJ+4RYBSsyrvGUiyFpmwQN2PhG8fBi4KmL GRnY7WlBDKrfNq4ebUgCMp0pK+I9jbU8sib73zNNYtekeYLqn55vN/5MqlyQmvPNrHUv hXoLyOvkzn65rJAaigXRZWuG71F4V4jCe4x3m7fpTxN0Q4aIrYuJhNL/ofQlhBNDho7I KuRt7DhGRvtacLK0VuZC6eL+bzCH0NKevPVqNyV4xI9sd+pR7z2ZnNUWIprBhaSgc+Po AUmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=j5nFoObm12zUu5Wt1scAipQgsmwwJ1G59ePgfUd1SZs=; b=Ih/fnUUaEvzN4vOLy8ptUG6nx51iXHlXj3pE3GnLU84yP1giP16eoaVw2J5SjVzqja 6fiX4UjiqdkDU0rQqhXVoiguc5PSwyJh0LltOYEtZZgc23s5g0x+LMqlJVYwUjK00/UG tcLLHcfvY03txnrCLNJIUNNdxVoApSio5zkmSQr1x170XJKFhwRAn6C+kVQ5E3SbJJT4 zBO1okhMLPCUbjt+NCzpFIa7GlxED/jmip37EW/aPWyWZauy5h4rIsnHDFgKZte1/5h6 oVUy/UDk7VHtTDWchfPidWadi29M9XHlk9oCzyEgNmNcDkciny1T15adX0S6Cliz1OpI GTug== X-Gm-Message-State: AOAM531KffxCAuf6cfrDx0s8YsKXQ7DH3sB61zPDUJfDkhk1lDNJ0sdh xHCFIj7sn/fThkRBSaHsbnofrb4x97zJCPO7yYgkv2Gi X-Google-Smtp-Source: ABdhPJxjCBdytDj8RbsjHVvYzyAfCrqalV1rp6b0PtQoB/eU5clEp+syWWU3BVkIlburNSSsacchr091alJJejaj0V8= X-Received: by 2002:adf:f507:: with SMTP id q7mr19791382wro.353.1591562273829; Sun, 07 Jun 2020 13:37:53 -0700 (PDT) MIME-Version: 1.0 References: <1784228.uJLO1Brz0r@localhost> <7c29c378-56cf-d601-6a18-215fe2b502d2@tana.it> In-Reply-To: <7c29c378-56cf-d601-6a18-215fe2b502d2@tana.it> From: Seth Blank Date: Sun, 7 Jun 2020 13:37:42 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f8490405a7847792" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 20:37:58 -0000 --000000000000f8490405a7847792 Content-Type: text/plain; charset="UTF-8" As Chair, I'm closing ticket #49 and recording the consensus of the group as in favor of removing the constraint. On Fri, May 22, 2020 at 1:03 AM Alessandro Vesely wrote: > On Thu 21/May/2020 23:11:54 +0200 Scott Kitterman wrote: > > Agreed. I don't think this is controversial. > > > > Also, I don't see a problem with making the p= tag optional (with an > inferred > > value of None if not present). This is consistent with an existing > SHOULD in > > RFC 7489 and appears to be broadly supported in existing implementations. > > > > I'd propose we close this ticket with the following resolution: > > > > The requirement that the v=DMARC1 tag be first will be retained. > > > > The requirement that the p= tag be second and the requirement that the > p= tag > > is mandatory will be dropped. If the p= tag is not present, the implied > > policy value is None. > > > Please, let's not forget to update the grammar, e.g. as proposed in > https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8 > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f8490405a7847792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Chair, I'm closing ticket #49 and recording the con= sensus of the group as in favor of removing the constraint.

On Fri, May 22, = 2020 at 1:03 AM Alessandro Vesely <ves= ely@tana.it> wrote:
On Thu 21/May/2020 23:11:54 +0200 Scott Kitterman wrote:
> Agreed.=C2=A0 I don't think this is controversial.
>
> Also, I don't see a problem with making the p=3D tag optional (wit= h an inferred
> value of None if not present).=C2=A0 This is consistent with an existi= ng SHOULD in
> RFC 7489 and appears to be broadly supported in existing implementatio= ns.
>
> I'd propose we close this ticket with the following resolution: >
> The requirement that the v=3DDMARC1 tag be first will be retained.
>
> The requirement that the p=3D tag be second and the requirement that t= he p=3D tag
> is mandatory will be dropped.=C2=A0 If the p=3D tag is not present, th= e implied
> policy value is None.


Please, let's not forget to update the grammar, e.g. as proposed in
https://mailarchive.ietf.org/= arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8

Best
Ale
--
































_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818



This em= ail and all data transmitted with it contains confidential and/or proprieta= ry information intended solely for the use of individual(s) authorized to r= eceive it. If you are not an intended and authorized recipient you are here= by notified of any use, disclosure, copying or distribution of the informat= ion included in this transmission is prohibited and may be unlawful. Please= immediately notify the sender by replying to this email and then delete it= from your system.

--000000000000f8490405a7847792-- From nobody Sun Jun 7 13:42:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477EE3A0938 for ; Sun, 7 Jun 2020 13:42:07 -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=valimail.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 G2POJynF3xEh for ; Sun, 7 Jun 2020 13:42:05 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 5864D3A0935 for ; Sun, 7 Jun 2020 13:42:05 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id x6so15194867wrm.13 for ; Sun, 07 Jun 2020 13:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XIYyAB6LwG/z4nBMZ+YcMm5IRqT+XYxCCF+uqK74JJw=; b=K+LXdrIw3w+TBpdeb7dGHfb8e4ssX1Ml0sNZOe2tsZYTzZxnKhxdLPEzeqvEaky2Hn Q7Tw8T8/S1e7yUZRflcTDvwp8V4TVDDSdyohgTkgQYUFv0pH3HCL1YD1LveL9at7Wlh5 OW3psXBK3QzmnK7Z+S0MolvoutH/OojZJG/Zfzfxow+8HtJl5nz3cV0B+YwV+kTJU/Cd p2gaWYEh/S9VXCVEBSJznG+bwnWZJl5QRJifMVK0Kev23PzDj/dkqLZ6I9MbfUWUWlGd /ntBewfBQ7nf5hBxcQB3LftvQwV5Em6AXkstSSA6jmtoyWEbLfPOXx6NViASnGks4Lx0 ijZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XIYyAB6LwG/z4nBMZ+YcMm5IRqT+XYxCCF+uqK74JJw=; b=nwqYDIqEVTu1yhzac1yQYC88GnMIIOf/a0YfJaocpYAkKJSesrA8jeJFM3qKGldO38 3QJM8cyMutQwXldFrqOW1R6cSdDhGEV2ZPyIoUqQgJ5CFq5YZdkK30Kg00Ry2R5muRj4 ZSV0I3Pb1+jaZ/p8PoqUgveoAr1ZRUnE1DUyFT/5e739GqW7sI4ON56LOByyYXL89yI0 4Og9d6uxyMnya/gP5FDJtZ9fSXLSkwnmVZwRLvtiqiNHmv1lC8nHPF/e0Qp41KlcEpDU 4U2ZZ1kYnoa5UJcYpAny4PlS5e0wFs/KxzRBX6MhyKHSm6TVjxmqbJrghNeW5WAujw4v HRHg== X-Gm-Message-State: AOAM532ySI3tJgNnlZSaJjqU8CwQixzMVag7f+eHBWulyNMzBnDlhTpc klPtZ1X/YwHlI84EG5hUQyiPQ8TyPEeV69L+4izxU3bO X-Google-Smtp-Source: ABdhPJyd86/63kgLuGnyECkJtS41R2xt4HkSLVRzhXKnEWrxte2+mQVLD1rgsmf6eyWNbEPHYeIXm8WekiJJpbpO8/s= X-Received: by 2002:adf:f507:: with SMTP id q7mr19800110wro.353.1591562520011; Sun, 07 Jun 2020 13:42:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Sun, 7 Jun 2020 13:41:49 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a4abfb05a7848635" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 20:42:07 -0000 --000000000000a4abfb05a7848635 Content-Type: text/plain; charset="UTF-8" As Chair, I'm closing ticket #63 and recording consensus of the group as leaving this as-is, any guidance around this matter should be left to a BCP or guidance document. On Thu, May 21, 2020 at 6:10 PM Dotzero wrote: > > > On Thu, May 21, 2020 at 5:57 PM Tim Wicinski wrote: > >> (with no hats) >> >> p=none with no reporting is fine, and we should keep it. >> >> One thing the WG could do is a BCP document on operational recommendations >> where there are certain suggestions like this. >> >> tim >> >> +1 >> > > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a4abfb05a7848635 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Chair, I'm closing ticket #63 and recording consens= us of the group as leaving this as-is, any guidance around this matter shou= ld be left to a BCP or guidance document.

On Thu, May 21, 2020 at 6:10 PM Do= tzero <dotzero@gmail.com> wr= ote:


On Thu, May 21, 2020 at 5:57 PM Tim Wicinski <= ;tjw.ietf@gmail.com= > wrote:
=
(with no hats)
<= div style=3D"font-family:monospace">
p=3Dnone with no reporting is fine, and we should keep it.=C2=A0

One thing the WG could do is a BCP document on operational reco= mmendations
where there are certa= in suggestions like this.=C2=A0=C2=A0

tim

+1

Michael Hammer
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818



This em= ail and all data transmitted with it contains confidential and/or proprieta= ry information intended solely for the use of individual(s) authorized to r= eceive it. If you are not an intended and authorized recipient you are here= by notified of any use, disclosure, copying or distribution of the informat= ion included in this transmission is prohibited and may be unlawful. Please= immediately notify the sender by replying to this email and then delete it= from your system.

--000000000000a4abfb05a7848635-- From nobody Sun Jun 7 13:48:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3759F3A094D for ; Sun, 7 Jun 2020 13:48:30 -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=[AC_BR_BONANZA=0.001, 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=valimail.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 r6LJpVoc1SsM for ; Sun, 7 Jun 2020 13:48:28 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A6DFB3A094C for ; Sun, 7 Jun 2020 13:48:27 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id x6so15208747wrm.13 for ; Sun, 07 Jun 2020 13:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FrJcufsSpWsRJ1hyBkV2evX8/S3DXY7GFCiTp9nZrLY=; b=PW3JEH8TwL1OERnXeT6H/I8bG4JHo2jUDslijjVSUfSMdFYHuk69VyO7UEeo7WqIs+ o2vjpJ25Wts7JO6Vw8OppKqXV1qnAfVAUERPJsw1wX+ypHWKCxmQNJgqoNu8Zg1O70Ca JV/tQaEZb9qsC+UI5pj4oWFhAuVmC0+LR13C9tA+iJrp12iTHwYqogF1orw90l8QrPQS 68YkU42XOZytAI3WZt0swf3IQl4vxL4+qMEq7u6RKuAGpX+JCTPhijFzwWfVXaSvNrrN ws8hnMJ8IxfmgSS6qBtlsaYypumUQ9eFI7n3+J1qXMzI3a+r27fvRGynn7HcU9v0xU9v 3YYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FrJcufsSpWsRJ1hyBkV2evX8/S3DXY7GFCiTp9nZrLY=; b=DxUzDpDVjuvqiVLCMRVoDRN016/+Hr/5AD4w1le76E6T0l/gQBzIMPdCjrhGLNPTxw 6eJ59n8jqYgINa29rEv/EADYOpASUOhBa7ZcwIENuALvQkVfHmuBQjSQUBZCYdKOS7rM xIiw9oMElWHTGLnc1oD2zCxDo7ZUlCMQNRERgmv0f4B4x3PMOJHD8D5o1vVto7yonOzx aNt9ulpRtlNZnh34VY4HwcEXCG40xAR9orrdiNnc9ZXcY8AsY/4B0kqrRNTcdxF8ZWHw y9HQDOcoamGeIOM+m0Cpv0PKIvD3njdzDkBeg2M67uRcYuvOPgMqS1vDbfSrVy74HvKh 04kA== X-Gm-Message-State: AOAM532UTf0Q8/2OdQnbogEttpa2vNbOicPx5FLt8s8Uz0+iW/rnzkxd Ub+Vz9lr7wJqUx5w3ItxowE85b7UxUrySo5U+7C6lQEo+QU= X-Google-Smtp-Source: ABdhPJwyiZL7sijBXJegxOKWnjy6tZV68ZehsLMmDEIAnsF9NbXB5fCcXxC+4AS4lFexlzxs/3h80vs4znPE514Eeoo= X-Received: by 2002:a5d:4490:: with SMTP id j16mr21882733wrq.276.1591562905727; Sun, 07 Jun 2020 13:48:25 -0700 (PDT) MIME-Version: 1.0 References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> <5EC58C62.8090703@isdg.net> In-Reply-To: From: Seth Blank Date: Sun, 7 Jun 2020 13:48:14 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a24f1305a7849dac" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 20:48:30 -0000 --000000000000a24f1305a7849dac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Chair, I'm closing ticket #69 and recording consensus as remaining with XML for report formatting. This consensus may be revisited if https://trac.ietf.org/trac/dmarc/ticket/42 opens a new reporting mechanism for which JSON is optimal, but the group's current consensus is that even in that case, XML will be sufficient. On Thu, May 21, 2020 at 3:38 AM Alessandro Vesely wrote: > On Wed 20/May/2020 22:00:34 +0200 Hector Santos wrote: > > On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > > > >> I mean, what is the CSV format of the following report, that I sent > yesterday > >> for this list: > > > > Sorry, if I ignored it. > > > > Forgetting fact that you can your report easier to read for consumers, > these > > would be an example of the CSV field headers. > > > > CSV headers: > > > > report_metadata.org_name, report_metadata.email, > report_metadata.report_id, > > report_metadata.date_range.begin, report_metadata.date_range.end > > > > Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, > > Policy_Published.p > > > > record.row, record.row.source_ip.record.count. > record.row.policy_evaluated, > > record.row.policy_evaluated.disposition, > > record.row,policy_evaluated.disposition, > record.row.policy_evaluated.dkim, > > record.row.policy_evaluated.spf > > > > Note: You don't have to stick to redundant "name space" field names. > > > You didn't include auth_results. That's tricky because you can have zero > or > more dkim and spf results. That would bring on a variable number of > columns, > with no hint about which is which. > > As Freddie noted, repeating the headers for every record may sound a > little bit > wasteful, but gzip may come to rescue here too. > > As for readability, aggregate reports are designed to be machine-readable > to > the extreme detriment of any kind of human readability. The best samples > of > such attitude are the date_range elements. HTML provides for a much bett= er > human readability. (Indeed, it is one of the formats you mentioned, as i= t > is > supported by Google Docs). I attach the HTML equivalent of the data I se= nt > yesterday. Posters whose From: was rewritten can easily spot their row > =E2=80=94readability meaning exactly that. > > Let me note that such htmlization is the result of a DMARC XSLT applied b= y > a > mail filter after rua messages authentication but before delivery. That > way, a > readable format of the reports is ready in the mail folder whenever I'd > care to > look at it, *as if it had been written in HTML in the first place*. By > similar > techniques one can obtain JSON, SQL, TXT, =E2=80=A6. In the face of such > flexibility, > I'm puzzled by your asking for more. > > > >>>> ... Can we get back to work, please? > >>> > >>> Sorry, but I consider a rude, disrespectful and ignorant statement, t= o > be > >>> saying that. > >> > >> > >> No personal attack intended. I'm being rude because I have the > impression that > >> you are not defending a concrete, well defined need, but instead find > new > >> arguments opportunistically to pursue a vague sense of format fashion. > > > > That's a personal attack. If you don't understand the proposal, you > should back > > off or ask for clarification. > > > I /am/ asking for clarifications. Please excuse my tone if it hurts you. > I'll > try and keep calm, but please restrain from technically flaky arguments > such as > CSV. I think you're perfectly aware of the capabilities I'm exemplifying > here. > They rest on the fact that a report consumer knows in advance the format > of > the data inside the received gzip. Hence, that flexibility would be > destroyed > by the introduction of multiple formats, as they would come randomly at t= he > mercy of the report generators, any prf=3D notwithstanding. Not a great > loss, > given your feeling about reporting? > > > >> You shifted from an asserted necessity of producers to a possible desi= re > >> of consumers.> > > I did no such thing. I won't repeat it, but it appears you didn't > understand > > the proposal. > > > For sure, I don't understand the proposal. Let's start over: > > On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote: > > Just consider, when the spec has XML-only, then for those who use a sol= id > > JSON I/O system, they are now going to be required to add XML. So for > them, > > its additional development complexity. Everything they probably do JSO= N > > related. The exception would be DMARC using XML. This alone can delay o= r > > push aside DMARC Reporting implementation. > > > Does DMARC Reporting implementation mean generation or consumption? > > > On Wed 20/May/2020 02:23:37 +0200 Hector Santos wrote: > > I suggest that there is a new tag that provides a "Preferred Report > Format" > > or "prf=3D" tag using registered acronymns for long time "standard" > formats. > > For example:> > > prf=3Dcvs,json,xml,afrf,iodef > > > > [...] > > > > The verifier will do what can it offer. The publisher is providing a > > preference, that it may not get. > > > That's 100% uncertainty of the result, isn't it? How is flexibility > improved? > I cannot store a received report as-is in Google Docs anyway, can I? > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a24f1305a7849dac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Chair, I'm closing ticket #69 and recording consens= us as remaining with XML for report formatting.

This con= sensus may be revisited if=C2=A0https://trac.ietf.org/trac/dmarc/ticket/42 opens a new repo= rting mechanism for which JSON is optimal, but the group's current cons= ensus is that even in that case, XML will be sufficient.

On Thu, May 2= 1, 2020 at 3:38 AM Alessandro Vesely <= vesely@tana.it> wrote:
On Wed 20/May/2020 22:00:34 +0200 Hector Santos wrote:
> On 5/20/2020 2:43 PM, Alessandro Vesely wrote:
>
>> I mean, what is the CSV format of the following report, that I sen= t yesterday
>> for this list:
>
> Sorry, if I ignored it.
>
> Forgetting fact that you can your report easier to read for consumers,= these
> would be an example of the CSV field headers.
>
> CSV headers:
>
> report_metadata.org_name, report_metadata.email, report_metadata.repor= t_id,
> report_metadata.date_range.begin, report_metadata.date_range.end
>
> Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf= ,
> Policy_Published.p
>
> record.row, record.row.source_ip.record.count. record.row.policy_evalu= ated,
> record.row.policy_evaluated.disposition,
> record.row,policy_evaluated.disposition, record.row.policy_evaluated.d= kim,
> record.row.policy_evaluated.spf
>
> Note: You don't have to stick to redundant "name space" = field names.


You didn't include auth_results.=C2=A0 That's tricky because you ca= n have zero or
more dkim and spf results.=C2=A0 That would bring on a variable number of c= olumns,
with no hint about which is which.

As Freddie noted, repeating the headers for every record may sound a little= bit
wasteful, but gzip may come to rescue here too.

As for readability, aggregate reports are designed to be machine-readable t= o
the extreme detriment of any kind of human readability.=C2=A0 The best samp= les of
such attitude are the date_range elements.=C2=A0 HTML provides for a much b= etter
human readability.=C2=A0 (Indeed, it is one of the formats you mentioned, a= s it is
supported by Google Docs).=C2=A0 I attach the HTML equivalent of the data I= sent
yesterday.=C2=A0 Posters whose From: was rewritten can easily spot their ro= w
=E2=80=94readability meaning exactly that.

Let me note that such htmlization is the result of a DMARC XSLT applied by = a
mail filter after rua messages authentication but before delivery.=C2=A0 Th= at way, a
readable format of the reports is ready in the mail folder whenever I'd= care to
look at it, *as if it had been written in HTML in the first place*.=C2=A0 B= y similar
techniques one can obtain JSON, SQL, TXT, =E2=80=A6.=C2=A0 In the face of s= uch flexibility,
I'm puzzled by your asking for more.


>>>> ...=C2=A0 Can we get back to work, please?
>>>
>>> Sorry, but I consider a rude, disrespectful and ignorant state= ment, to be
>>> saying that.
>>
>>
>> No personal attack intended.=C2=A0 I'm being rude because I ha= ve the impression that
>> you are not defending a concrete, well defined need, but instead f= ind new
>> arguments opportunistically to pursue a vague sense of format fash= ion.
>
> That's a personal attack. If you don't understand the proposal= , you should back
> off or ask for clarification.


I /am/ asking for clarifications.=C2=A0 Please excuse my tone if it hurts y= ou.=C2=A0 I'll
try and keep calm, but please restrain from technically flaky arguments suc= h as
CSV.=C2=A0 I think you're perfectly aware of the capabilities I'm e= xemplifying here.
=C2=A0They rest on the fact that a report consumer knows in advance the for= mat of
the data inside the received gzip.=C2=A0 Hence, that flexibility would be d= estroyed
by the introduction of multiple formats, as they would come randomly at the=
mercy of the report generators, any prf=3D notwithstanding.=C2=A0 Not a gre= at loss,
given your feeling about reporting?


>> You shifted from an asserted necessity of producers to a possible = desire
>> of consumers.>
> I did no such thing. I won't repeat it, but it appears you didn= 9;t understand
> the proposal.


For sure, I don't understand the proposal.=C2=A0 Let's start over:<= br>
On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote:
> Just consider, when the spec has XML-only, then for those who use a so= lid
> JSON I/O system, they are now going to be required to add XML. So for = them,
> its additional development complexity.=C2=A0 Everything they probably = do JSON
> related. The exception would be DMARC using XML. This alone can delay = or
> push aside DMARC Reporting implementation.


Does DMARC Reporting implementation mean generation or consumption?


On Wed 20/May/2020 02:23:37 +0200 Hector Santos wrote:
> I suggest that there is a new tag that provides a "Preferred Repo= rt Format"
> or "prf=3D" tag using registered acronymns for long time &qu= ot;standard" formats.
> For example:>
> prf=3Dcvs,json,xml,afrf,iodef
>
> [...]
>
> The verifier will do what can it offer. The publisher is providing a > preference, that it may not get.


That's 100% uncertainty of the result, isn't it?=C2=A0 How is flexi= bility improved?
=C2=A0I cannot store a received report as-is in Google Docs anyway, can I?<= br>

Best
Ale
--



































_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818



This em= ail and all data transmitted with it contains confidential and/or proprieta= ry information intended solely for the use of individual(s) authorized to r= eceive it. If you are not an intended and authorized recipient you are here= by notified of any use, disclosure, copying or distribution of the informat= ion included in this transmission is prohibited and may be unlawful. Please= immediately notify the sender by replying to this email and then delete it= from your system.

--000000000000a24f1305a7849dac-- From nobody Sun Jun 7 14:20:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F673A097E for ; Sun, 7 Jun 2020 14:20:29 -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, 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 (1024-bit key) header.d=bluepopcorn.net 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 tWvCjW6vteI8 for ; Sun, 7 Jun 2020 14:20:27 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 A934D3A0979 for ; Sun, 7 Jun 2020 14:20:27 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:90:85c0:1871:c24f]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 057LKPar028751 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 7 Jun 2020 14:20:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591564827; bh=5Kj5TTX87C7hxqZZqX4Cmm914rtVBaXscfBNVXlegF8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=scgs6OydQBPlrC5zjGEyPBH2IfPAo874x8BXXJrn/Q5buueeriKDBqtCKY1BBFbQ6 zW5R3s+O+7fSIPJgZebjp+ZyBnDVxOw/UkKxjpYZ2PMljfkePxiCjnMazxOIRu0wl/ Xxp9RoDr8ydDqnCbtLP0Y+TVQBoXPZTxu7JrwQcU= To: dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <11b7a02a-88e3-311f-61f6-c20ffeb95bfc@bluepopcorn.net> Date: Sun, 7 Jun 2020 14:20:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:20:29 -0000 On 6/7/20 6:16 AM, Douglas E. Foster wrote: > 2) Some of the discussion appeared to resolve around the assertion > that DMARC can have no value. =C2=A0 Since that view is not universal, = I > think the project can continue with those who do believe that it adds > value. > That's not how it works; this working group is discussing an IETF standards-track specification. This is based on the rough consensus of the entire working group; you can't just go forward with a subset of people who agree. -Jim (with apologies to the WG chairs if I'm venturing into their territo= ry) From nobody Sun Jun 7 14:23:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090293A0984 for ; Sun, 7 Jun 2020 14:23: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_IMAGE_ONLY_32=0.001, 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=valimail.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 fjr84zrASjVJ for ; Sun, 7 Jun 2020 14:23:29 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 C87423A0982 for ; Sun, 7 Jun 2020 14:23:28 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id r7so15339562wro.1 for ; Sun, 07 Jun 2020 14:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=xRdPakVZIPEYyeDqb+GPLBHTtNMZ4OMWA1rWGibESrI=; b=Sc4DjPQ/KGe33tgRYjL/QRJoJtpE14PHCExXk+7pvyLyPp/mXLd0YvRcAiuP+dlk5b AgOBlNazXlv2oPYpeOzKghSDEYaNZZxuKNMd9Dw00U1l7XcATBDstZo+eMlMFALt9zlI c89+7CHf5fNXnr4XVrNljZzRRaPbKJzvyKygpR0wWDGmfMlyO/hd+U+gQ0hHixzHg2If lQh9aD/gm2p/i9XfAvgayrKSJ3jYYDhx/yjAkX2/P0SHVaSWeTV+smmewAVCsmLXp6Kt pQUB64ghkraXf7C5SmTiFV3j+48w/yKUKwjXV/Z5HsaO0CySBLMw/QN2OvZzBS5P/rCe bU7w== 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=xRdPakVZIPEYyeDqb+GPLBHTtNMZ4OMWA1rWGibESrI=; b=JfOqeHugiqys2E8WTet4mfHYMNkw5r0KMwOZugF0LehVI+X9si4t3MvDexsuZJOn9n nuNrzBCL3H5sgFvoti20WwhJ5R6YKHW2w+xQt4MuJXKLkq/EzEXmu1bWOjMe2ahT9uxA izbhdi/n0uZFkuGMJaB9AeQ5raNxciRiWahrLKxCCXYAgOemYAKhJsFxfVc1MUBhcw0y oxlsSgHV+xdkhA28SrSkj06FtZnzDacy/KJL5gKvAwl1NlHxur5lUq/yKL+/KT6r3keQ /5h8ALt2ATqPPCz844Gh3nxK1MDiYW1fFnAy3CbPSVl76sqpeMTivbggad9GyER7/oVz +jaw== X-Gm-Message-State: AOAM533saUOB0oBmbKuRy854pr/iribX8SZBBl4nkpK6gaoJbjrsmgCE /TdSDyHEUKalw3fdFRf7ffSDlKGzecLJi+mS1YgTs+A4/pw= X-Google-Smtp-Source: ABdhPJy+sCFy6DCZMqLqDdWohoETytOa3YXCzNyxmFfu1hSJFEXsuP0mcRWIvcYbf3SsTnZsIdWE5xiS7+Tsh/iW9ZI= X-Received: by 2002:a5d:40d0:: with SMTP id b16mr20049910wrq.218.1591565007001; Sun, 07 Jun 2020 14:23:27 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Sun, 7 Jun 2020 14:23:16 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e12d9605a7851a13" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:23:31 -0000 --000000000000e12d9605a7851a13 Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/51 In a DMARC aggregate report, a record with a disposition of "none" is ambiguous, as a disposition of "none" at p=none means a different thing (that no action was taken on the message) than a disposition of "none" if the DMARC policy is reject or quarantine (the message passed an aligned authentication check of either SPF or DKIM, and was therefore not subject to policy). It is desirable to have logically distinct disposition responses, and if so, what should be reported in the latter case? As a straw man, "pass" instead of "none"? -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000e12d9605a7851a13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://trac.ietf.org/trac/dmarc/ticket/51

In a DMARC a= ggregate report, a record with a disposition of "none" is ambiguo= us, as a disposition of "none" at p=3Dnone means a different thin= g (that no action was taken on the message) than a disposition of "non= e" if the DMARC policy is reject or quarantine (the message passed an = aligned authentication check of either SPF or DKIM, and was therefore not s= ubject to policy).

It is desirable to have logical= ly distinct disposition responses, and if so, what should be reported in th= e latter case? As a straw man, "pass" instead of "none"= ?

--

Seth Blank | VP, = Standards and New Technologies
= p: 415.273.8818
=



T= his email and all data transmitted with it contains confidential and/or pro= prietary information intended solely for the use of individual(s) authorize= d to receive it. If you are not an intended and authorized recipient you ar= e hereby notified of any use, disclosure, copying or distribution of the in= formation included in this transmission is prohibited and may be unlawful. = Please immediately notify the sender by replying to this email and then del= ete it from your system.

--000000000000e12d9605a7851a13-- From nobody Sun Jun 7 14:23:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5143A0982 for ; Sun, 7 Jun 2020 14:23:31 -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=valimail.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 4VvQRjMvoe9c for ; Sun, 7 Jun 2020 14:23:29 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 C8F3D3A0983 for ; Sun, 7 Jun 2020 14:23:28 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id l10so15301896wrr.10 for ; Sun, 07 Jun 2020 14:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=Z2yvc2hLDlfWKZmGws52O2DOgI9yPk1coC03GFIdgwQ=; b=K0eSem9GkZDNx1RE4Vy+oeknPr28WIRMAGJ/ipyAxxoXWYkHjzZyr9O8e0hS1CpN5K ZBUlPnAc6KfxUUYd+7QHYehCP3uRA/zq1gILRrlpwy3sR9vjI2PsFUwS9iriKNTHAndo 6A0+6Gj3Ozy3yIjJTV8Zqoartgj+GuGE6qwWJuMLc0zgufQe5ekl9r6d4RZAgSnrLuc0 5qNSZTliNZCpV44XSCmchVq9/mzFvv22D4JTp+zXFSrwW7EkYIurXoJwXt5nDstgrfSB LzN21etW4N+vmNsNq0QZHeFXFNz7Wx1zOjzngQ2y0nzfHNOEOdiN8eakn2b3ddcDbEBc GVTg== 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=Z2yvc2hLDlfWKZmGws52O2DOgI9yPk1coC03GFIdgwQ=; b=PuS/YbCZYi4TiobItV4Gjr7Zx8jwyUZwUpe9VNoHRuMR5HQ4ZrM8H4uc8xXk2KdQmx Pbm6uLWh924ZT2+biMOv71HP+tjGqtIXogFxNGbKqsBo763EttHM/DhlNzkFaufZ5NLT i7GTRgO7MCJcq9/n5Kzo1v1MniOFTCpJLrA71BndrgV5MlNgGB3K8JUaTYaku5cxJHdF /vQv7s/YT1v7zBhwt/jIhYq9jBf+Fk4BrGd4ko/j9sG3NcYbNU9W7nNsavWOpKLSwqxU M5LyUcrgJZjMwIXsvmhv2K2K2Qyq0dmXHHVWLVk7Dbj+F1mdpq7IVRPufAZzfZMzwm/U CrAQ== X-Gm-Message-State: AOAM532sWEMlR0AXG+v79mm0YMKxxxEXJ/lHzCNpbfU5JxHtLEiLGKOi o0kuHQ2LNdgW1ZoNyRWx6reqVd0M0nRmgFqS6XN3CM7fBbc= X-Google-Smtp-Source: ABdhPJz1zugkUhwd9P//XbpxXoGcFWHwe8jd4a6tbNR2/CqpS5AmOT+Uov/UxcdVxjP52mz4hw4kIcBvdzEnj7BZ95k= X-Received: by 2002:a5d:6444:: with SMTP id d4mr20957037wrw.239.1591565003479; Sun, 07 Jun 2020 14:23:23 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Sun, 7 Jun 2020 14:23:12 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ab6bdc05a7851a69" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:23:32 -0000 --000000000000ab6bdc05a7851a69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://trac.ietf.org/trac/dmarc/ticket/38 The spec is ambiguous about which DKIM key needs to be reported. The real world problem here is that sometimes the DKIM key(s) which are reported in a row of an aggregate report have nothing to do with the DKIM key used to evaluate the DMARC status within the same row. In https://tools.ietf.org/html/rfc7489#section-7.2, it says: The report SHOULD include the following data: o The identifier evaluated by DKIM and the DKIM result, Elizabeth Zwicky previously wrote: https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ "is genuinely unclear. Often there are multiple identifiers. Does this mean I can pick any one of them? (That does not actually provide sufficient interoperability.) If there=E2=80=99s a specific one I should pick, which i= s it?" https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ "I believe they MUST contain any aligned DKIM signature regardless of validity and SHOULD contain an entry for each domain, selector, result triple." Is it desirable to clarify this language, such that it is clear which DKIM keys are required to include in a report, and if so, how should the appropriate keys be determined? --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ab6bdc05a7851a69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://trac.ietf.org/trac/dmarc/ticket/38

The spec is = ambiguous about which DKIM key needs to be reported.

The real world problem here is that sometimes the DKIM key(s) which= are reported in a row of an aggregate report have nothing to do with the D= KIM key used to evaluate the DMARC status within the same row.
<= div>
In=C2=A0https://tools.ietf.org/html/rfc7489#section-7.2, it says:

=C2=A0 =C2=A0 The report SHOULD include the followi= ng data:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0T= he identifier evaluated by DKIM and the DKIM result,

Elizabeth Zwicky previously wrote:

"is genuinely unclear. Often there are multiple identif= iers. Does this mean I can pick any one of them? (That does not actually pr= ovide sufficient interoperability.) If there=E2=80=99s a specific one I sho= uld pick, which is it?"

=
"I believe they MUST contain any aligned DKIM signature regardles= s of validity and SHOULD =C2=A0contain an entry for each domain, selector, = result triple."

Is it desirable to clarify this lan= guage, such that it is clear which DKIM keys are required to include in a r= eport, and if so, how should the appropriate keys=C2=A0be determined?
=

--

Seth Blank | VP, Standards an= d New Technologies
p:= 415.273.8818


<= br>

This email an= d all data transmitted with it contains confidential and/or proprietary inf= ormation intended solely for the use of individual(s) authorized to receive= it. If you are not an intended and authorized recipient you are hereby not= ified of any use, disclosure, copying or distribution of the information in= cluded in this transmission is prohibited and may be unlawful. Please immed= iately notify the sender by replying to this email and then delete it from = your system.

--000000000000ab6bdc05a7851a69-- From nobody Sun Jun 7 14:23:42 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD44C3A09E7 for ; Sun, 7 Jun 2020 14:23:35 -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=valimail.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 dO_7JuyiIaqE for ; Sun, 7 Jun 2020 14:23:34 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 C99433A0993 for ; Sun, 7 Jun 2020 14:23:33 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id j10so15318481wrw.8 for ; Sun, 07 Jun 2020 14:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=g9L8uvliAH7PvyWQVCM7xMuFVWMhCbkYl0qQwLaHiOg=; b=Hzg8uRmmkpdPmxIX2XMtaycVoz2e05dLJM36NKEIRlc/eufmJqMCtRw/ZzQNaSOAOK 4rYf3Uxt8MHnQxPgal0ay1aIuv17Zd9FqtfRmsS0wFfphIGkCorgwpYVbnVSl9/s/VU3 /9IapLcwEFUFza3D0Vner22bfpvZK1yBbBC//dvYAA/EszvkzjSdF3vi0wT+az8nS/q8 zWIlY5EE+OSQvmwUPiNsG39HI+QmSRrUOOH0MtUoqYKIoz3yX2Kv8KwDb4rzBXjgRWX5 FGn175qUNnCVOrCGW4poTpCjura44sJQgWm206EznLKKlyhXmaXEgYCMgi39qo1bfMYS 6P0w== 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=g9L8uvliAH7PvyWQVCM7xMuFVWMhCbkYl0qQwLaHiOg=; b=iiWLznHhs0UYIqkjf6sxFF5pn1aYAx6EbiEq55CD84DXOOGunaMirH0hEY8jK0p4k9 SQZKgMKhOWfPkVUX5sOWYpegTl7mSGlfhkKQuT9uzb58xKIc8G2DWOxQoFEPIK/q+lpn TCUZ2ei2o/etQyAa5orlvnXUimWWDV5ujMVgChx7U2vA1Hat4s9KWccM4mhegjhEamgI KRPsyl4ohn6laIsv6PmgDnEOm5LcLSY18iHoxbrfmmL2pjx2SBO3lNK/kQDdgXqIZdgd dt6RAmAjTN67/wP76rIymJryu71IT5D+WnsShS9Z22P5w9JDd9w335DCqXiCB8OoDVB8 UbDg== X-Gm-Message-State: AOAM533z5IwdcWc1PVSwrJXv8eGyC1Y5Laqe6XUbfxqpf/Rdl2wZkAzP jCujxEFZirf/izTqamWDgve4Gjsq5mB39BIZTneTdt/yj5U= X-Google-Smtp-Source: ABdhPJwJjgBtoguCnzfhdWB3Pm4sjsXn8/OYSIGo8D7JRqrnHoq5WDfnLSM92FfrQszPwT42DwAMSkJW0uV56rzvKds= X-Received: by 2002:a5d:4490:: with SMTP id j16mr21980126wrq.276.1591565008361; Sun, 07 Jun 2020 14:23:28 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Sun, 7 Jun 2020 14:23:17 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f5e88305a7851a1c" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:23:42 -0000 --000000000000f5e88305a7851a1c Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/66 Many different entities participate in DMARC, and to each, there is a different definition of what is needed to "implement" or participate in DMARC. Should the spec be clear about the different participants, and what it means for each to participate partially and completely? As a straw man to start conversation (assume this is all wrong): The domain owner: - partially participating: valid record? - complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender? The receiver/MTA: - partially participating: validates DMARC? - complete participation: validates DMARC and ARC, and sends aggregate reports? The intermediary (is this different than a receiver?): - partially: validates DMARC? - complete participation: validates DMARC and validates and seals ARC? -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f5e88305a7851a1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://trac.ietf.org/trac/dmarc/ticket/66

Many differe= nt entities participate in DMARC, and to each, there is a different definit= ion of what is needed to "implement" or participate in DMARC.

Should the spec be clear about the different particip= ants, and what it means for each to participate partially and completely?

As a straw man to start conversation (a= ssume this is all wrong):

The domain owner:
<= div>=C2=A0 =C2=A0 - partially participating: valid record?
=C2=A0= =C2=A0 - complete=C2=A0participation: no part of the domain hierarchy can = be spoofed by an unauthenticated sender?

The recei= ver/MTA:
=C2=A0 =C2=A0 - partially participating: validates DMARC= ?
=C2=A0 =C2=A0 - complete participation: validates DMARC and ARC= , and sends aggregate reports?

The intermediary (is this = different than a receiver?):
=C2=A0 =C2=A0 - partially: validates= DMARC?
=C2=A0 =C2=A0 - complete participation: validates DMARC a= nd validates and seals ARC?


--
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">

Seth Bla= nk | VP, Standards and New Technologies
p: 415.273.= 8818



This email and all data transmitted wit= h it contains confidential and/or proprietary information intended solely f= or the use of individual(s) authorized to receive it. If you are not an int= ended and authorized recipient you are hereby notified of any use, disclosu= re, copying or distribution of the information included in this transmissio= n is prohibited and may be unlawful. Please immediately notify the sender b= y replying to this email and then delete it from your system.=

--000000000000f5e88305a7851a1c-- From nobody Sun Jun 7 14:40:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F03A09C3 for ; Sun, 7 Jun 2020 14:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=guEl/WRg; dkim=pass (1536-bit key) header.d=taugh.com header.b=KZmFiLv1 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 UMmPdTNCr6UW for ; Sun, 7 Jun 2020 14:40:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 373DE3A09C1 for ; Sun, 7 Jun 2020 14:40:48 -0700 (PDT) Received: (qmail 85054 invoked from network); 7 Jun 2020 21:40:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14c3a.5edd5ede.k2006; bh=Dai7vKCR06Y87qrxk3lprmw6vZ3YH6v6IGBtojLQy5o=; b=guEl/WRgtYBvZa2i930+km1/wnwk5Ow1hiZMb9OaOgV3dkxqKWojZBQyzSwBwj6aPaiL0yoZcrM7VA9aLCZfOt2xaiVwOPhg6z5VQhPBnLBeC2K+IkMbcz8ZaQFXxgboG2wh9iZYYEAkajKHCirJCBbHdFKilsraVvUfG9r+GG8UbY4urLfYo1tQNPBZacK1EA8bKASrJgPURSoBGj3IfHSHpeWJVKGSCfZGlx7yJBDWGBnv3pS8Wiiax0rwGDEr DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14c3a.5edd5ede.k2006; bh=Dai7vKCR06Y87qrxk3lprmw6vZ3YH6v6IGBtojLQy5o=; b=KZmFiLv1Q+WGfgZ31yQsZ1j9xNdhQdsGe5hzWGdkq4/7V8WiltAYZBkIhIE1/qjZFKuB52KTN0/XJDW7V7IDAmR3TrlnAIh94Z/7C9mEzv1O3EHW3VmE8vjJFz8c8hVQHtq0mck+EkyhC8xNB2k5eE+jk1i+G2SxO4vv7KerhNPH/xKvqu0w2lXx5Xu1j3/Ww2Bfm6I+L/Wb+ttLhoghGv/HRDDi0vM7xZvOKU0uzdOrejJ7MTOq/oWVHpiDoxyU Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 Jun 2020 21:40:45 -0000 Received: by ary.qy (Postfix, from userid 501) id E1CDB1A4634B; Sun, 7 Jun 2020 17:40:45 -0400 (EDT) Date: 7 Jun 2020 17:40:45 -0400 Message-Id: <20200607214045.E1CDB1A4634B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: stan@glyphein.mailforce.net In-Reply-To: <71cddc80-008c-4f33-bdac-71ebc029bb3c@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:40:51 -0000 In article <71cddc80-008c-4f33-bdac-71ebc029bb3c@www.fastmail.com> you write: >I didn't know the history of the IETF's approach to UI, in particular, but I'm aware of the research on the nastiness of >solving the UI problem. I mostly wanted to clarify that the problem is, indeed, *how* to show that data to users, and that no >one has actually ever been able to solve that problem. I believe the real question is *whether* to show trust data to users and the consensus seems to be don't bother, it only confuses them. R's, John From nobody Sun Jun 7 14:53:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7AE3A0A96 for ; Sun, 7 Jun 2020 14:53:16 -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, FREEMAIL_FROM=0.001, 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=gmail.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 yai7EgoonTOH for ; Sun, 7 Jun 2020 14:53:14 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 04AF93A0A80 for ; Sun, 7 Jun 2020 14:53:14 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id w3so15496638qkb.6 for ; Sun, 07 Jun 2020 14:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2Y8Eeff7mcFeVcfhOKybwMc4Ff0VTcB6+UAU5SnQw9w=; b=BjUsfC1D/Aurz/B+Z8ulyU/JA3bxxh/H8/TwXVXHENqO/3pCqL5MDOx5icS/IinPTf isDWUp0nEx7yOTBxuxT0B7s1BqB0TLwuMHNwFC3LS0qg1pTQf4oA7tbrNnTs/ftYmRts MvKz5RljFifzc/uqErv7993/c7pacE54kxS1/SzXcUsAEU2ot0asscITl071TZlrEsHx dLjRANe2FTCV7U4qAZzZkkzL8HGO6puMa6IWUFCxmXtACkqBWI81gsYSJhmLn5qHtzgU iUjOB1HzQvwKBrSFF1fQT2jQr6Tx5IfzH/3Sf6AYEXRI6ZSk+L79jQL09H9mmj09n351 H2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2Y8Eeff7mcFeVcfhOKybwMc4Ff0VTcB6+UAU5SnQw9w=; b=oVqA75Io2FhX3rlJAuITI/g1wndW9zAhA/HSgDbggjLoZfTqD+x+0QuCSkf5p49V1J mNHr0crnY4yYoADjL++dV8p/PMfYAsQ4W6+74trUGt9m6sa9nRswi2fByyVn2GrjeYZ2 j2R11TJGMCk+rIzggS3L8dLZMXnge0fz2FETzUIRIqkOnWINobEmiipqbxLCaNCNd6EV oYJ/dWTjd/pimGWJTmn7LRIU07GJpqG1NphFW4YhBcYhZp5vwdRRsgWUo3ETda32gWfS 2UxWDeyF+Wy0hGYIfhviLTEz62SISbOILadEK1GO5pK0wdPa6p49ZNQmVexzFFLWyelV v7UQ== X-Gm-Message-State: AOAM5317E61k4DkTSAeBVgkcnAhEItdDSGbitSV3d4Ckp5MFPvq4TKzH ivTSpaalOLEqz0tZzS4c9WcXqQXb X-Google-Smtp-Source: ABdhPJzw911q7AIffvJm0zRQSSKjydx/eEnv/QuPNMbroLDnV8Z3ddd75wtS4alLF0W5GezJS3xDHA== X-Received: by 2002:a37:a147:: with SMTP id k68mr19591985qke.62.1591566791252; Sun, 07 Jun 2020 14:53:11 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:5443:4b56:d117:6ef3? ([2600:1700:a3a0:4c80:5443:4b56:d117:6ef3]) by smtp.gmail.com with ESMTPSA id i94sm6116410qtd.2.2020.06.07.14.53.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 14:53:10 -0700 (PDT) To: dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> From: Dave Crocker Message-ID: Date: Sun, 7 Jun 2020 14:53:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------7C14176FE9E9294D85C9859A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 21:53:22 -0000 This is a multi-part message in MIME format. --------------7C14176FE9E9294D85C9859A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/7/2020 10:53 AM, Stan Kalisch wrote: > Assuming this can be practically done, I would rephrase this, > "...[E]stablish how MUAs should display trust data to users." > Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful.  Good luck with that. On 6/6/2020 2:42 PM, Scott Kitterman wrote: > 1. I think the domain displayed to the end user matters. In my sample size > of 1, it matters to me. I know I'm not the average user, but independent of > t I might be wrong, but I believe the IETF does not intend to make global standards on the basis of possible utility for only one engineer working on the specification.  Or two.  Or three. cf, above. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------7C14176FE9E9294D85C9859A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/7/2020 10:53 AM, Stan Kalisch wrote:
Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users."

Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful.  Good luck with that.


On 6/6/2020 2:42 PM, Scott Kitterman wrote:
1.  I think the domain displayed to the end user matters.  In my sample size 
of 1, it matters to me.  I know I'm not the average user, but independent of 
t

I might be wrong, but I believe the IETF does not intend to make global standards on the basis of possible utility for only one engineer working on the specification.  Or two.  Or three.

cf, above.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------7C14176FE9E9294D85C9859A-- From nobody Sun Jun 7 15:07:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29703A0A3A for ; Sun, 7 Jun 2020 15:07:44 -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_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=Kv8BYQ7s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o/AvLHzJ 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 vTsZ1N-4VLsC for ; Sun, 7 Jun 2020 15:07:43 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E70D3A0A39 for ; Sun, 7 Jun 2020 15:07:43 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B1087487; Sun, 7 Jun 2020 18:07:42 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 18:07:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=F/97o7PQG6arSe1o+qQoUw2fukk8JrC 2N7MOqpxquH0=; b=Kv8BYQ7sNTQuyYP0NPlnLvS4jAIoQSC1rqG1xO6mQ0dwxPS p0q5DZX1CNO+cH9bH3depdGL086+nS8Wh0CEurB722CU8K1DalaZ+21aiDH1nyZi B+zJ2yEPHHF8dF0eededsInsUzF7AyMQUlhRHVWo2gZt2h9kOcAmMusPWsuJdPpU NxPDqEht5Seq+p4Hz8Fj0lyn1ynYpHsv4SWWUQ78u/6E2zNiTpBh3C/F+ox/ANt4 c99E9d6p67neuYuWQ5PqQFbENWB/IMWpikSxQKx/z6RV/SP3JZXv5ppwQVkNB/VH k7TPD2e3gwA7ajnOs/7oeTD/5qZ5wIuUEZv6EIQ== 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=fm3; bh=F/97o7 PQG6arSe1o+qQoUw2fukk8JrC2N7MOqpxquH0=; b=o/AvLHzJ+/PCy/qEJJFwAF clOdOKlWQXEynLJ/jteiwT5q8lklGZZKbsOUCpH+lOe5G1+vtlDXBgn4rJA/PH8C cu7C12iCSXKtnHti6G3hFqTrpSyyZ77t5//yCSbhl9pm/QUbdm9czBsBNmEjoKbm 2L5nUMxOapTxykTDO3IB7XyBabDXqubmnSCWPPLOUfIv4u4BZEUHiQ76n4zGRM5m Zukd0Wn8xbfnDup06yLiQg98hewDsjABzKmyQBv5sWaNwqN4LVovJjrVhLxpYea9 xJ2bVsJkCDQqyQQnEn+4RSueG52f7VlOEZ4DlASg29NDoEv2apjwz8Q440j+ak2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehtddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdfuthgr nhcumfgrlhhishgthhdfuceoshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorhgtvg drnhgvtheqnecuggftrfgrthhtvghrnhepvdegtdeffeejgffhueetieeuuddugeetgefh tdffteeulefgveffteelheejffffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorhgtvgdr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EB9371400A1; Sun, 7 Jun 2020 18:07:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <4fe54a6c-6176-4f0a-bd34-a353c074c303@www.fastmail.com> In-Reply-To: <20200607214045.E1CDB1A4634B@ary.qy> References: <20200607214045.E1CDB1A4634B@ary.qy> Date: Sun, 07 Jun 2020 18:07:20 -0400 From: "Stan Kalisch" To: "John Levine" , dmarc@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?DMARC_alignment_conflicts_with_RFC_5322_o?= =?utf-8?q?n_the_use_of_the_From_and_Sender_header_fields?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 22:07:45 -0000 On Sun, Jun 7, 2020, at 5:40 PM, John Levine wrote: > I believe the real question is *whether* to show trust data to users > and the consensus seems to be don't bother, it only confuses them. I mean, I can't dispute that that's a fair question. Confusion obviously works against the goals behind showing the user the data in the first place. Stan From nobody Sun Jun 7 16:04:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF083A0437 for ; Sun, 7 Jun 2020 16:04:37 -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 (1024-bit key) header.d=bayviewphysicians.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 7OrlFeAV8WaS for ; Sun, 7 Jun 2020 16:04:35 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB493A0433 for ; Sun, 7 Jun 2020 16:04:35 -0700 (PDT) X-ASG-Debug-ID: 1591571074-11fa313a1092990001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id yEBCqEwHUkG4Oci8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 07 Jun 2020 19:04:34 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=HIhxyOtKpJamZIbQMC7RoJlfMvFYcRuZHmzhYzgwSRY=; b=ahanevxa1ZS27/h96fFXDIocD5rEjIL4Diw64o05Uu50V4pTW8c6gWgYiQyplDI7m oixi/kllzpRsXU1qhtd8VmDyiOk4/APhLv8MjIRp9pjVpXTuK5EIi9jICNq6HOAEX dY3CZpfloXpUfgdsEZAF7j3Dv2PXnFGQA/DdOiP8o= From: "Douglas E. Foster" To: Date: Sun, 07 Jun 2020 23:04:24 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] About user notification in the MUA Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ff3927184ede40d09c8f36c0b003b1c8 In-Reply-To: References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> X-Exim-Id: dbcc34fb870e45b2b1cd3903b90b8a87 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1591571074 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5290 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82398 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:04:37 -0000 This is a multipart message in MIME format. --ff3927184ede40d09c8f36c0b003b1c8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am trying to play by the rules and not chase topics outside the one assig= ned, but since several have jumped on my comment, I will follow up briefly. Dave Crocker wrote Since there has been a demonstrated lack of efficacy in this sort of displa= y, there needs to be an objective basis for knowing that any new such requi= rement will be useful. Every email filtering product that I have examined has provided a user-sign= aling system, using one or more of the following: tagging the subject, adding text as a body header or body footerconverting = the suspect message into an attachment of a replacement message,soft-quara= ntining, where the user has unrestricted control to release the message fro= m quarantine. Given that market reality, I conclude that most vendors and their customers= believe that user-signalling is useful. The signalling system does not h= ave to prevent every mistake for the signal to be useful. The problem with all current notification methods is that they are relative= ly primitive, often communicating nothing substantive about the suspicious = message characteristics. They also work against other security mechanisms.= Any form of tagging breaks DKIM signatures, reducing the credibility of the= message if it is auto-forwarded for any reason. The tagging also becomes tattooed to the message and its replies, rather th= an being restricted to the trust domain that assigned the tag. One exampl= e should suffice: a message was tagged with [SPAM?] because the sender had= an error in his SPF record and I was trying to enforce SPF. Then when my= staff replied, the originator treated the reply as spam because the word S= PAM was still in the subject line when he received it! We need a user notification mechanism that is local to the trust domain and= does not break DKIM signatures. You have already done the heavy lifting f= or this interoperability problem with Authentication-Results and ARC I am= not expecting a "Standard" that requires every implementation to notify ev= ery user in the same way. I am looking for a guidance document that helps= vendors to deliver products which permit an organization to implement a no= tification policy which they find to be effective and appropriate. IETF i= s the right organization to take this on because the email filter, the mail= system, and the multiple MUAs are almost always a multi-vendor configurati= on. df --ff3927184ede40d09c8f36c0b003b1c8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I am trying to pla= y by the rules and not chase topics outside the one assigned, but since sev= eral have jumped on my comment, I will follow up briefly.

Dave Crocker wrote
Since the= re has been a demonstrated lack of efficacy in this sort of display, there = needs to be an objective basis for knowing that any new such requirement wi= ll be useful.

Every email filtering product that I= have examined has provided a user-signaling system, using one or more of t= he following:
  • tagging the subject, 
  • adding text a= s a body header or body footer
  • converting the suspect message into = an attachment of  a replacement message,
  • soft-quarantining, wh= ere the user has unrestricted control to release the message from quarantin= e.
Given that market reality, I conclude that most vendors an= d their customers believe that user-signalling is useful.   The signal= ling system does not have to prevent every mistake for the signal to be use= ful.

The problem with all current notification met= hods is that they are relatively primitive, often communicating nothing sub= stantive about the suspicious message characteristics.  They also work= against other security mechanisms.   
  • Any form of t= agging breaks DKIM signatures, reducing the credibility of the message if i= t is auto-forwarded for any reason.  

  • The tagging als= o becomes tattooed to the message and its replies, rather than being restri= cted to the trust domain that assigned the tag.   One example should s= uffice:  a message was tagged with [SPAM?] because the sender had an e= rror in his SPF record and I was trying to enforce SPF.   Then when my= staff replied, the originator treated the reply as spam because the word S= PAM was still in the subject line when he received it!   
    • We need a user notification mechanism that is local to the trust dom= ain and does not break DKIM signatures.  You have already done the hea= vy lifting for this interoperability problem with Authentication-Results an= d ARC   I am not expecting a "Standard" that requires every implementa= tion to notify every user in the same way.   I am looking for a guidan= ce document that helps vendors to deliver products which permit an organiza= tion to implement a notification policy which they find to be effective and= appropriate.   IETF is the right organization to take this on because= the email filter, the mail system, and the multiple MUAs are almost always= a multi-vendor configuration.

    df




    --ff3927184ede40d09c8f36c0b003b1c8-- From nobody Sun Jun 7 16:06:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AB3A0477 for ; Sun, 7 Jun 2020 16:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Vic9CS12; dkim=pass (2048-bit key) header.d=kitterman.com header.b=sKMvaFiw 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 ehRh0pjjFsBi for ; Sun, 7 Jun 2020 16:06:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A9A3A0437 for ; Sun, 7 Jun 2020 16:06:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 38AE0F801EA for ; Sun, 7 Jun 2020 19:06:28 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591571188; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=PPpIEooM1YDk6UQ4SkFvJUGVuGfG3uPEIBGvaoL8NYQ=; b=Vic9CS12FC25Xy/3tA5EHakzZZV7kmC6FxATp3iQ+kdeGL3x6P88zNw+8xalKGqKe+m0l 22G4YR+vcTXvbzvAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591571188; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=PPpIEooM1YDk6UQ4SkFvJUGVuGfG3uPEIBGvaoL8NYQ=; b=sKMvaFiwyPydgi05wqlzXqYqd8kInMUTa2YO7Sl2PmFMhOI7bgQfNvVSzde8/7GTCTZ2L Abq8n8H0Yzy+986iXPhXKadJ49Hxi8GJZeV1cWrLD2b31Ajfwz5lkBET1D8qDFwaDr51G7q tNT7uEZnuS87JjshwbrFBAw6XmUBirUo2fnjTYAKi9TPVgoiiGMFqPxmKIYKY3ESsWklvAK Nfh5bClO10zvaom3MkJfowg/kYKtRlPnQx04qA0KGurc5IH7cdv1wdba2xvzg119ChF2EkW 2nPq5r1JD2UV/dTDLoIhEVF/KGLCw5SHxOsuo0gGd0EZ5Vk4TjLDigYanBMg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id EEFABF801AA for ; Sun, 7 Jun 2020 19:06:27 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 07 Jun 2020 19:06:27 -0400 Message-ID: <4766648.lM4k2y0xV2@sk-desktop> In-Reply-To: References: <7c29c378-56cf-d601-6a18-215fe2b502d2@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:06:31 -0000 On Sunday, June 7, 2020 4:37:42 PM EDT Seth Blank wrote: > As Chair, I'm closing ticket #49 and recording the consensus of the group > as in favor of removing the constraint. Thanks. In the discussion about that ticket there was an additional suggestion about making p= optional which was outside the scope of that ticket. I've filed: https://trac.ietf.org/trac/dmarc/ticket/72 to capture that. Scott K From nobody Sun Jun 7 16:08:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21A63A0486 for ; Sun, 7 Jun 2020 16:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=MxJ7HLNn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=BNzLG00x 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 sl-yX5qmYVUO for ; Sun, 7 Jun 2020 16:08:31 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B513A0477 for ; Sun, 7 Jun 2020 16:08:31 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B1965F801EA for ; Sun, 7 Jun 2020 19:08:30 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591571310; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LW+yM4OwDjbd6Gttv2UGTrqdT077XYHjIr8770jkAcw=; b=MxJ7HLNnuJHp3Rrl3gJBVcwrHsfwY61A2E0kF2pe59huHTXELZavGc3GWek/eAoU5eG34 FGRwV47lEuiLO0sBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591571310; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LW+yM4OwDjbd6Gttv2UGTrqdT077XYHjIr8770jkAcw=; b=BNzLG00xNSFQ0drzdSuK4OT70V4GvYDfWHLIjEPlSia4mRAStkLKk/cPkP2Jyv5UHuWos BFWJqq4uc7CBMAKHDeMBlTtwc958gMPQaRQuXpqigA9VbHnpdJ8vcjLr2UmOiT4nvvOxfpX dpIB0a+PRBUEQCkb35z62sYL64lAFcoUUyahvZ8jzV6aB94uy8WmX/40g43h3ehBJFe/9GI Je1wUN92mUWTTQT6TFsSpvHFubFp/ACQs6N7vddn0du12S9J2Uo0IKiTpzKqKhtym2gm1zu +yazPNtE5pYFOiiR6fIad0YI3o8O+Vy8okbo5We3VTxQ3Eui1kvDAY8gDx6A== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 75D0DF801AA for ; Sun, 7 Jun 2020 19:08:30 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 07 Jun 2020 19:08:30 -0400 Message-ID: <5470782.pd3ty62yEX@sk-desktop> In-Reply-To: References: <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:08:33 -0000 On Sunday, June 7, 2020 5:53:08 PM EDT Dave Crocker wrote: > On 6/7/2020 10:53 AM, Stan Kalisch wrote: > > Assuming this can be practically done, I would rephrase this, > > "...[E]stablish how MUAs should display trust data to users." > > Since there has been a demonstrated lack of efficacy in this sort of > display, there needs to be an objective basis for knowing that any new > such requirement will be useful. Good luck with that. > > On 6/6/2020 2:42 PM, Scott Kitterman wrote: > > 1. I think the domain displayed to the end user matters. In my sample > > size of 1, it matters to me. I know I'm not the average user, but > > independent of t > > I might be wrong, but I believe the IETF does not intend to make global > standards on the basis of possible utility for only one engineer working > on the specification. Or two. Or three. > > cf, above. Conveniently, I'm not proposing any new requirements. Scott K From nobody Sun Jun 7 16:14:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E413A0538 for ; Sun, 7 Jun 2020 16:14:30 -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, FREEMAIL_FROM=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=gmail.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 AuqJOQ-86sw6 for ; Sun, 7 Jun 2020 16:14:29 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 D73973A0528 for ; Sun, 7 Jun 2020 16:14:29 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id e5so12161902ote.11 for ; Sun, 07 Jun 2020 16:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Nc3Wv65LYyfDQCi92G7rB94ACzWsf/73y/D5AdzgbE8=; b=fr/WTMg7Ivrs6NbI9sVOF758yHZ6VSkARqWNrxOkv6fbDkupP5AbNbblkc64/bVhvI sscUVjR91VuyB18EPzEX4mw1jHyhu21a99LaBoCY8T/sarzDKAXbzSE+7cDDNJ8MMfR3 vXizitQwpKiHn0VAlbDiU8lqs9f6z4Dp2+XQy+akKZ3uVPMzvnW189nhI4+536hggZbb gsDSRZKCl1Oaa6r566a+Zu5o2/eG1xkEkpDGQJqcIveJX+ZOcFtUlhpFI7nHicr1PFFz iMc+G09ip4z1WdwCj79El8m/K7ok7S25QyjTPD57VOniF2RUEQkYIxtw69XPHq4N4XYL iX0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Nc3Wv65LYyfDQCi92G7rB94ACzWsf/73y/D5AdzgbE8=; b=V1o0WoThsotRblFd0ixoFj7YQpKFoocLfn/naAO+wUKby3bjhTpnYdGgcNHdlgsJ7k Q6XA2gOe5dA2le0+rk1GprM3Geq7b656OD+VvkoyRMgXqNeMtqsqIruT7Rh3MNSeRM5B vKcc07ZUxfmeRTgufvze/tU4wDAQ1kcGjvoyo3SNvhwwHGXt/c4Ttc4vnI5LTwAR0j7u bD/beQ33XH8HhXOM2pnU2MCWoa5mGru9+pqMtN3erYEulYoOr2ulAx+MreoXncEumphm yqUPUnjQO3xdBV1WyMyxeLKCpzN/4An8bsg9/RPKgubXV6KpNn4JDVAh6NsV6gIhfXtK FGpw== X-Gm-Message-State: AOAM532VcvSyUgCzIS6+b93kVX846ybUGDTbwhjVh6d0jaqlgqYJesHf +fPBuS0UbaC/IF9XI3dp32+CqvdY X-Google-Smtp-Source: ABdhPJx3sW22wIXQaygBSNtIlRiSRGtbWeme7Hbv89Zp7YJyG+upkdxPnEcg6dspij7aCOUUTde7uA== X-Received: by 2002:a9d:dc6:: with SMTP id 64mr9993875ots.247.1591571667645; Sun, 07 Jun 2020 16:14:27 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:5443:4b56:d117:6ef3? ([2600:1700:a3a0:4c80:5443:4b56:d117:6ef3]) by smtp.gmail.com with ESMTPSA id f109sm1162170otf.39.2020.06.07.16.14.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 16:14:27 -0700 (PDT) To: fosterd@bayviewphysicians.com, dmarc@ietf.org References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> From: Dave Crocker Message-ID: Date: Sun, 7 Jun 2020 16:14:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:14:31 -0000 On 6/7/2020 4:04 PM, Douglas E. Foster wrote: > Given that market reality, I conclude that most vendors and their > customers believe that user-signalling is useful.   The signalling > system does not have to prevent every mistake for the signal to be useful. What you are describing has nothing at all to do with system-provided trust assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 7 16:17:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C278A3A079D for ; Sun, 7 Jun 2020 16:17:19 -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, FREEMAIL_FROM=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=gmail.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 QzU8p36nmh0Q for ; Sun, 7 Jun 2020 16:17:18 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 073403A07C5 for ; Sun, 7 Jun 2020 16:17:17 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id 97so810758otg.3 for ; Sun, 07 Jun 2020 16:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=2d57HJzbniH4V6FA9e1bUiv3hgdo8ps+DtXcs6VjngU=; b=RkMSjGMIezyaaUbe6ZlfnFzzqE6tngR0dQOheX5X5VkhQUVOurmrGaRoDmUPNoJpa2 hlPaLel1gTY4bdIcuHbSOETGyrK0g9tXnsIrCzHoKS/B/9n3QqNFme1LY/Cwuo2Z4PLJ PKEofBGzAvueMsXuqNa2XtvMFxNXUiKR2CZHxAsbs42utQ8P02iDRo/xuu7EtqRRyB2L ftSwCajpm+uZm2yBNoZsVKepkVBenipiiu4IEr8ktFzHdpRxjHbXacec4CAKOnBDRRbi 5Q7q4v6FikdJ21VSQdHlvxMhulQ7+RZ4QrsL8hecaGeMAnakZ/YDGVe7e9P9FlCrx8eD uMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2d57HJzbniH4V6FA9e1bUiv3hgdo8ps+DtXcs6VjngU=; b=gLeGC0d7qCQySLAPCcW//Kq85BRjoPIebVaAkx1DzSgvnJEfZV48L+LNXRtoLbWDWQ 0XqZ8wp8LHJ1lpSufWTcPBIt4Obz9jAazCIwW4npSGuDvZq47e6tkDCXtgu9ZWRKbhwd MkVOE5DqWpVLPxh4woDpEK+jcsTJNs5EtSGcm8ux7OieDei7oGD7nGD8U+eG9cgi4Mzu Hx05UG1rbULm5HkTmFxEbNXWX1kgC0gvVkyU0c/I/I0zHXPmQuwgyZY0XC8pqe33EVvd SqMoRcDvLp+xyg46nNaAlVZxEC3jsqjAAP7xX+fOLEdmybwDhaSu4NbTKVgDSYLZ92Rv 5DOA== X-Gm-Message-State: AOAM531mRkmRPIjCd260w8/lwDrNSdkek5yQsspm42OgLoGoQdKrdmzM uucrnqrC+8yC/8WS03PCqEZ5jXnq X-Google-Smtp-Source: ABdhPJyeLNuQZJd4zajQLJx2KJoZ0AUhC4xG8ff52OUO34zsz2jK/zBitsrH1K3ftmvJ0KCmRYJPjA== X-Received: by 2002:a9d:7083:: with SMTP id l3mr10300436otj.232.1591571837387; Sun, 07 Jun 2020 16:17:17 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:5443:4b56:d117:6ef3? ([2600:1700:a3a0:4c80:5443:4b56:d117:6ef3]) by smtp.gmail.com with ESMTPSA id w132sm2054563oib.30.2020.06.07.16.17.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 16:17:16 -0700 (PDT) To: John Levine , dmarc@ietf.org Cc: stan@glyphein.mailforce.net References: <20200607214045.E1CDB1A4634B@ary.qy> From: Dave Crocker Message-ID: <06db657a-2b87-2bb0-6e80-f58de8fc9930@gmail.com> Date: Sun, 7 Jun 2020 16:17:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200607214045.E1CDB1A4634B@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:17:26 -0000 On 6/7/2020 2:40 PM, John Levine wrote: > I believe the real question is*whether* to show trust data to users > and the consensus seems to be don't bother, it only confuses them. It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years and none has demonstrated efficacy. Anyone claiming the contrary needs to provide objective data to substantiate a claim of efficacy. Adding a capability or relying one carries an affirmative obligation to provide a basis for knowing that the cost is justified. So far, there isn't one, for end-user trust notifications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 7 16:21:42 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30CB3A0602 for ; Sun, 7 Jun 2020 16:21:40 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=/qFPtTHn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qqcS7yhW 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 739Ey_OqWKKf for ; Sun, 7 Jun 2020 16:21:39 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FC43A05A0 for ; Sun, 7 Jun 2020 16:21:39 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 29DF5F801EA for ; Sun, 7 Jun 2020 19:21:37 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591572097; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hlARtd7t51W4es61Q0liq6wZ7Ajb31wf4SdLrmxLEVk=; b=/qFPtTHn3TF27Is1hV7JjX6hi9n/xFZpzWwV5ZqiaJ+gB3C+wYzNfBP+VAXsJi81aFnlv rj5Ey5HV2x1cizXCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591572097; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hlARtd7t51W4es61Q0liq6wZ7Ajb31wf4SdLrmxLEVk=; b=qqcS7yhWMH5JL3+lDQMzqvYLOQYtHLMglpIfx1XJDJUrvvNH+fkhH0GNQKKzmDgIAyZsT IRkbujJp+Qm1MOxruu7/3/740cj0lAgBy2uHvoFioTeigWsKufhi/zzDdiF8yhvLmuRmnzH 09ourAdAcckEDNJno765KzwLYGQ6xEYqdpZck2XAKiMSEBcGsj/QYh6Qpf1NHMIEOsrD/Ri U97nrPWM+0lVQFOXJoJZCbKSpUkWUp9DFRMyHPTnjkd7lCYUY/Ooxm4sn6v9PeSyhOmX2wB Mv88f9aC25PJGCS79q9T2ZZO3EtIuhejqbgNb6Pzb4vrTQ5QcfWfanGirNEg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id F1F8FF801AA for ; Sun, 7 Jun 2020 19:21:36 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 07 Jun 2020 19:21:36 -0400 Message-ID: <6497677.MpAdVSVx3U@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:21:41 -0000 On Sunday, June 7, 2020 5:23:12 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/38 >=20 > The spec is ambiguous about which DKIM key needs to be reported. >=20 > The real world problem here is that sometimes the DKIM key(s) which are > reported in a row of an aggregate report have nothing to do with the DKIM > key used to evaluate the DMARC status within the same row. >=20 > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: >=20 > The report SHOULD include the following data: >=20 > o The identifier evaluated by DKIM and the DKIM result, >=20 > Elizabeth Zwicky previously wrote: >=20 > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ > "is genuinely unclear. Often there are multiple identifiers. Does this me= an > I can pick any one of them? (That does not actually provide sufficient > interoperability.) If there=E2=80=99s a specific one I should pick, which= is it?" >=20 > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ > "I believe they MUST contain any aligned DKIM signature regardless of > validity and SHOULD contain an entry for each domain, selector, result > triple." >=20 > Is it desirable to clarify this language, such that it is clear which DKIM > keys are required to include in a report, and if so, how should the > appropriate keys be determined? In DKIM, I would have thought that the 'identifier' is the d=3D domain. Ju= st=20 based on that text, there's no need to provide the selector. Looking throu= gh=20 the rest of the list, I don't see anything that indicates the DKIM selector= =20 should be included in an aggregate report. That said, the selector is pretty useful. I'd suggest it's essential for=20 troubleshooting failures. Maybe there's two things here: 1. identifier needs a better definition. 2. Is there a backward compatible way to specify inclusion of the selector. Scott K From nobody Sun Jun 7 16:42:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B1B3A07AE for ; Sun, 7 Jun 2020 16:42:14 -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=valimail.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 3qwEj_QV2QEE for ; Sun, 7 Jun 2020 16:42:12 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 8B4333A07AA for ; Sun, 7 Jun 2020 16:42:12 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id k26so14739271wmi.4 for ; Sun, 07 Jun 2020 16:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4+9jVTm8iVNE9lLtMLT60gJyFJnFOS3stJIPp1ZSxA=; b=T+kfjHlz+tOz/dj97TX8UvLqBvtwZNkKLZR/kSBVck1C/lL2VXiyiJxstJ6SpGRWp2 +PSbcYWESyQR5OOHZyDGkgoPZLW/aC2Ck+0mmBGHSr5POq+J/832kedl/U6EfFGcFf8M z4YccRItlpBA68D5KsBWT5j0YUTeA8QRLkY1fAbK2Rlz2bv13iZMPjArjKJiqInXCw1p snakD7LHC5+YA6Of52Acz4HO5CPbtz/4ElK/93hA1ehSiZMrbJPttjenCtntkKSKH9Tc 5aSxPfJIQR2U9l0fMSYMork28xIb398u7xWOXRcXWzwH2fk+veyzR8s0NmrGu1sLmGpR wYQg== 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=W4+9jVTm8iVNE9lLtMLT60gJyFJnFOS3stJIPp1ZSxA=; b=VJCs2cF4/OdfHkGYf6jHXsNHb54U5yfhiY/ztJQFNM7XhXxPSY/2YkItgrkNzcynOd QMe/iWfujsIUVEFid2F6BVNVQILoDBOzMSLS4cl4yVp82dfMevmjBgNe9MLV7galxVbW OGIb5dR7w512gh9TMjsY2yILj3LjnFPelKg/TuFyjPId1mcuDirEGOTYf8QKp2uGqQtH huVCYkovrxncy5STOED1eABbwK/LCtMjHxZ0tsw7O4zwCGEeh+QdPBQXi7xGE6tIyTLC NH62634pK6zyrH10BiuVz0w8k0f9f/WHkvHtcacXNlrKp3f3TpY8fmI10F2/jca2EPYX RKtg== X-Gm-Message-State: AOAM532m2+xGUxovsN36h3rF+TgowVXkOeVSylzSmW9qMxEd9Prf6+1c aD61UjUuzblvtYb+CthqKMK69lB4x3VEpV4EqIRWljvc X-Google-Smtp-Source: ABdhPJy0GIqgvPv1RbLQv1HU0uegi2nN7Uz8eElnEhy4DsEKif2AHqCF9u55UvBMRTELqT0l25hMNt0CqBaX6apnwDg= X-Received: by 2002:a1c:4302:: with SMTP id q2mr13696317wma.54.1591573330702; Sun, 07 Jun 2020 16:42:10 -0700 (PDT) MIME-Version: 1.0 References: <6497677.MpAdVSVx3U@sk-desktop> In-Reply-To: <6497677.MpAdVSVx3U@sk-desktop> From: Seth Blank Date: Sun, 7 Jun 2020 16:42:00 -0700 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000002c26805a7870bec" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:42:15 -0000 --00000000000002c26805a7870bec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 7, 2020 at 16:21 Scott Kitterman wrote: > On Sunday, June 7, 2020 5:23:12 PM EDT Seth Blank wrote: > > https://trac.ietf.org/trac/dmarc/ticket/38 > > > > The spec is ambiguous about which DKIM key needs to be reported. > > > > The real world problem here is that sometimes the DKIM key(s) which are > > reported in a row of an aggregate report have nothing to do with the DK= IM > > key used to evaluate the DMARC status within the same row. > > > > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: > > > > The report SHOULD include the following data: > > > > o The identifier evaluated by DKIM and the DKIM result, > > > > Elizabeth Zwicky previously wrote: > > > > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M= / > > "is genuinely unclear. Often there are multiple identifiers. Does this > mean > > I can pick any one of them? (That does not actually provide sufficient > > interoperability.) If there=E2=80=99s a specific one I should pick, whi= ch is it?" > > > > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084= / > > "I believe they MUST contain any aligned DKIM signature regardless of > > validity and SHOULD contain an entry for each domain, selector, result > > triple." > > > > Is it desirable to clarify this language, such that it is clear which > DKIM > > keys are required to include in a report, and if so, how should the > > appropriate keys be determined? > > In DKIM, I would have thought that the 'identifier' is the d=3D domain. > Just > based on that text, there's no need to provide the selector. Looking > through > the rest of the list, I don't see anything that indicates the DKIM > selector > should be included in an aggregate report. > > That said, the selector is pretty useful. I'd suggest it's essential for > troubleshooting failures. > > Maybe there's two things here: > > 1. identifier needs a better definition. > > 2. Is there a backward compatible way to specify inclusion of the > selector. Selector is already there, it=E2=80=99s just OPTIONAL. There=E2=80=99s anot= her ticket about making it required. > > Scott K > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000002c26805a7870bec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Jun 7, 2020 at 16:21 Scott Kitterman <sklist@kitterman.com> wrote:
    =
    On Sunday, June 7, 2020 5:23:12 PM EDT Seth = Blank wrote:
    > https://trac.ietf.org/trac/dmarc/ticket/38
    >
    > The spec is ambiguous about which DKIM key needs to be reported.
    >
    > The real world problem here is that sometimes the DKIM key(s) which ar= e
    > reported in a row of an aggregate report have nothing to do with the D= KIM
    > key used to evaluate the DMARC status within the same row.
    >
    > In https://tools.ietf.org/html/rfc7489#section-7= .2, it says:
    >
    >=C2=A0 =C2=A0 =C2=A0The report SHOULD include the following data:
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The identifier evaluated by D= KIM and the DKIM result,
    >
    > Elizabeth Zwicky previously wrote:
    >
    > https://mailarchive.iet= f.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/
    > "is genuinely unclear. Often there are multiple identifiers. Does= this mean
    > I can pick any one of them? (That does not actually provide sufficient=
    > interoperability.) If there=E2=80=99s a specific one I should pick, wh= ich is it?"
    >
    > https://mailarchive.iet= f.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/
    > "I believe they MUST contain any aligned DKIM signature regardles= s of
    > validity and SHOULD=C2=A0 contain an entry for each domain, selector, = result
    > triple."
    >
    > Is it desirable to clarify this language, such that it is clear which = DKIM
    > keys are required to include in a report, and if so, how should the > appropriate keys be determined?

    In DKIM, I would have thought that the 'identifier' is the d=3D dom= ain.=C2=A0 Just
    based on that text, there's no need to provide the selector.=C2=A0 Look= ing through
    the rest of the list, I don't see anything that indicates the DKIM sele= ctor
    should be included in an aggregate report.

    That said, the selector is pretty useful.=C2=A0 I'd suggest it's es= sential for
    troubleshooting failures.

    Maybe there's two things here:

    1.=C2=A0 identifier needs a better definition.

    2.=C2=A0 Is there a backward compatible way to specify inclusion of the sel= ector.

    Selector i= s already there, it=E2=80=99s just OPTIONAL. There=E2=80=99s another ticket= about making it required.



    Scott K



    _______________________________________________
    dmarc mailing list
    dmarc@ietf.org
    https://www.ietf.org/mailman/listinfo/dmarc
    --

    Seth Blank | VP, St= andards and New Technologies
    p: 415.273.8818

    <= /p>



    This e= mail and all data transmitted with it contains confidential and/or propriet= ary information intended solely for the use of individual(s) authorized to = receive it. If you are not an intended and authorized recipient you are her= eby notified of any use, disclosure, copying or distribution of the informa= tion included in this transmission is prohibited and may be unlawful. Pleas= e immediately notify the sender by replying to this email and then delete i= t from your system.

    --00000000000002c26805a7870bec-- From nobody Sun Jun 7 16:45:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48743A07BE for ; Sun, 7 Jun 2020 16:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=nOf5yznX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AkQRv1SF 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 nYxX5P97Pauc for ; Sun, 7 Jun 2020 16:45:52 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8060B3A07BD for ; Sun, 7 Jun 2020 16:45:52 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 8DAA33ED for ; Sun, 7 Jun 2020 19:45:51 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 19:45:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=qz5uNf9O0rbsJz4S6hdZHRxjwzcJ2PL AzWnecQTAOxA=; b=nOf5yznX7usB/Kk9Nw//J+Dvep5Dpsz/cCKaqqXppwo0t+s Sf4kwkAQJTqKkuQdgDrXh71mRwSPSQhmPTF7dYHxiCA2Ge83Mo4twM/FA7sud7Y7 FWWUTA0G56heuTiRkIg9mbOjLIyDAzA7/W6A1Dx++uDms9YOz130nZVoTuT3NXjN FDEmXmpd9oUDb3NYaoRsos6AI7HSxXLn1VKlLdrKn5vUOfChfQwjaU78xY/NPbLI sMq+zCR+vVcXEnw29t7qhuD97ivhxJ8BZArXbjHl8///kyMGP3RyPOqBBts2Ky29 KoIUITjr2lqxMmSV5qrNBQ0ACcWq8OvsqLLljtw== 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=fm3; bh=qz5uNf 9O0rbsJz4S6hdZHRxjwzcJ2PLAzWnecQTAOxA=; b=AkQRv1SFaXf4YSuZO9RXBx E7UJ4HUxoIojJdl8W+HYpQMf1MHdts3rhSIxb+jLjQ43XoolUi0ufrkRvauwkxL4 VaTrhSRIR1cuaFAf7IIz/sp5FDzujrvCgvkYcA5RdOkijQGapCZVM6aCsqQQuibm M2L/t7IX8NUr2aEWuMStJU2UgD9RbLLbIWBOoNq1Vq9D8839iP4kGnIy2fZov8fq Sthr7NW0HOuGqFNBtXiiJT2/SGQPjnTu1Figl5jZZ4M5y9tl/8uon6UFVQcMfKzW GLBcgg/2OyVO9yD8v94LehMoT/MofaLpfbRsLKCVjbhNyRyWmuJ7z8/0B7mBYaoQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehtddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucggtffrrghtthgvrhhnpefgie ejteehfeeguefgfeefvedtvdegudekvdeukeejveejffeiiefhieejudelieenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhi hphhgvihhnrdhmrghilhhfohhrtggvrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE0E11400A1; Sun, 7 Jun 2020 19:45:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <33b12416-cd41-4826-9950-3afc9fdb83bf@www.fastmail.com> In-Reply-To: References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> Date: Sun, 07 Jun 2020 19:45:06 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=76c48f6cba4b48f6b7b13e2402de1ffb Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 23:45:54 -0000 --76c48f6cba4b48f6b7b13e2402de1ffb Content-Type: text/plain On Sun, Jun 7, 2020, at 7:04 PM, Douglas E. Foster wrote: > The problem with all current notification methods is that they are relatively primitive, often communicating nothing substantive about the suspicious message characteristics. And you propose the average user can understand, much less take the time to understand, the substance? Stan --76c48f6cba4b48f6b7b13e2402de1ffb Content-Type: text/html
    On Sun, Jun 7, 2020, at 7:04 PM, Douglas E. Foster wrote:
    The problem with all current notification methods is that they are relatively primitive, often communicating nothing substantive about the suspicious message characteristics.

    And you propose the average user can understand, much less take the time to understand, the substance?


    Stan
    --76c48f6cba4b48f6b7b13e2402de1ffb-- From nobody Sun Jun 7 17:02:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CBC3A07D6 for ; Sun, 7 Jun 2020 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=B68PRNeZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=Yxw2zVew 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 swOPy0hoo8bW for ; Sun, 7 Jun 2020 17:02:16 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A5B743A07D5 for ; Sun, 7 Jun 2020 17:02:16 -0700 (PDT) Received: (qmail 11937 invoked from network); 8 Jun 2020 00:02:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2e9d.5edd8006.k2006; bh=dUnoTdpZWIhDocHbLmq4YU4gCD491+TLK5ABjkMPSFs=; b=B68PRNeZ0kJuqAU5vtWrluxNrJ/DPVfAbRLo+tfe7SNpKJa4FO184RF8ifVVq5ee6AgGOEDYe1XWI/28bJPepEEVRaJH6PaZyCgO4sTn7ZL0iipmXZXkUaDX1kSg6uqQWktBqJNmGGItLd8rbi6Al7JjWBo7UNDTL9RoAD2jdJqc5nuW85Nvx3B8trujJoeKJKe0Wwps1K6nAQ/r4Jg8Xiy6aQI/k/hpDG0oCedlgfyyBmKHuoCDVYHOyThktFIz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2e9d.5edd8006.k2006; bh=dUnoTdpZWIhDocHbLmq4YU4gCD491+TLK5ABjkMPSFs=; b=Yxw2zVewYBZal8owAXV3b6scCKslSTLCIPvghP9wSIbRaSXGcfyyb28M+6QZ1JhBopRYPXgVGqbos7Eu8ah/QGmFCjLtAfT/K5Fsjdf22ILTfy2KF0T+FLe8PHfdCmDav7GEsvovdoICgxMY9Wk5/2adWaMXMIHiU+7K9l7fMuxpyD5hVvGaLQu2+kkD5wtw75SUPy51eE2JSyutdQ28y3NpSZpoInwm7Gnl7SIuHj3DspNaf80yDZIZuzDkMTNy Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Jun 2020 00:02:13 -0000 Received: by ary.qy (Postfix, from userid 501) id A1FD71A46C3E; Sun, 7 Jun 2020 20:02:13 -0400 (EDT) Date: 7 Jun 2020 20:02:13 -0400 Message-Id: <20200608000213.A1FD71A46C3E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 00:02:19 -0000 In article you write: >-=-=-=-=-=- > >https://trac.ietf.org/trac/dmarc/ticket/38 > >The spec is ambiguous about which DKIM key needs to be reported. > >The real world problem here is that sometimes the DKIM key(s) which are >reported in a row of an aggregate report have nothing to do with the DKIM >key used to evaluate the DMARC status within the same row. How about saying that reports MUST include the key used to evaluate the DMARC status, if there was one, and SHOULD include all DKIM keys evaluated. The other ones can be useful, e.g., mailing lists usually resign their outgoing mail so if you have an idea what what lists are sending you mail, that gives you a strong hint that a DMARC failure is due to mail from a list. From nobody Sun Jun 7 17:06:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE43A07FC for ; Sun, 7 Jun 2020 17:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qVA6cVln; dkim=pass (1536-bit key) header.d=taugh.com header.b=LdKgDlMT 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 J6AtuLm5eEDv for ; Sun, 7 Jun 2020 17:06:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 01EB33A07FB for ; Sun, 7 Jun 2020 17:06:19 -0700 (PDT) Received: (qmail 12458 invoked from network); 8 Jun 2020 00:06:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30a8.5edd80fa.k2006; bh=5E+OiTd4emkrJSXyxSP9l7g/VgEK1YX7Aqp4sbEg6Cw=; b=qVA6cVlnU1HwgopOomdYT1miA8C9+quTOdULd5KD9LOL1p6Bgy706qPSW2u3UztBIw+SQGTrhfoQ9lerEATKrkA+o06JCvYQJUoYhbFQAA6N4F2Z4rgkFL8PtD05zX1vK1CUjLKGM6+SRrIGPkFdzSdF3vgH041emSuMJF1yJu1xHCN3Gwgcq8lmMU5FQ6KCnR2RdJKjZcqSoIxXUEGv5bzBCE9nK8zWbOkZmVrjVlKsUrVxtj6EolqG1aD3AlUQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30a8.5edd80fa.k2006; bh=5E+OiTd4emkrJSXyxSP9l7g/VgEK1YX7Aqp4sbEg6Cw=; b=LdKgDlMTmA2flv3NuWZgDZRxBU7cyvj1ApcPVPXrhLrkXk1NoYaRwoznFEeJIQNV2GUgVragz0HkAEFjgCzc0NXF6tq68e0rcFWfi42CzgrhnWhHN6Q4Bq/knX64hlNAPTkAIpK5SBHZA3PU7LEc2BSm+5qLEWzTppMobNfzf8CysrigGXc5ZED8mZKM4LomjKpJ/YlLYT3KKu6CDJSyW4X9xI+o+SIY6FZ2dCQCnMmUpZobaK88Qe4T0Gdz3tKD Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Jun 2020 00:06:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 58E5D1A46D5B; Sun, 7 Jun 2020 20:06:18 -0400 (EDT) Date: 7 Jun 2020 20:06:18 -0400 Message-Id: <20200608000618.58E5D1A46D5B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 00:06:22 -0000 In article you write: >-=-=-=-=-=- > >https://trac.ietf.org/trac/dmarc/ticket/66 > >Many different entities participate in DMARC, and to each, there is a >different definition of what is needed to "implement" or participate in >DMARC. I would rather put this in a separate non-normative BCP. >The receiver/MTA: > - partially participating: validates DMARC? My MTA validates DMARC and then does nothing with it other than put the result in an A-R header. It currently only validates ARC on mail that will be run through a mailing list. This can be a rather deep rabbit hole. R's, John From nobody Sun Jun 7 19:14:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B483A093C for ; Sun, 7 Jun 2020 19:13:58 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Wo4A+7ru; dkim=pass (2048-bit key) header.d=kitterman.com header.b=WpIVq6j5 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 b9_nbwhPb-Bk for ; Sun, 7 Jun 2020 19:13:57 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF69B3A093A for ; Sun, 7 Jun 2020 19:13:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id DBF06F801EA; Sun, 7 Jun 2020 22:13:55 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591582435; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=EBdM/dn4wZ8n5ISPuxhsJs9p+LGRJFpMYmHV9F/1M3E=; b=Wo4A+7ruRVajC/5W1MyEqfZoyVg576qy86uHA7WtphUQyPojDalzKBtdiS6Io60ClO4Ik dXKeJUgkOcuu0X0Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591582435; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=EBdM/dn4wZ8n5ISPuxhsJs9p+LGRJFpMYmHV9F/1M3E=; b=WpIVq6j5vgkEjTllpwgqYfv8ES5WIdUF4Ngv2rKXvb7LperXO0nc7En40t+ui+QJWh1ls LiqlQ1eFZ+JTSY4KiLYJlPgEDK0Kx4aiTIMTHThb5BD8WFh7fZOgRLOd+9Rsin+Clej1Bq8 fNPPTpttbGT/yVIPaGHAZXSU2nlsCG80JknnFdO0UzZkBAPMl5L3cFUX7t+cihXFhdUY6CJ GcpznwWXs7K/StMCKqsk+NyLYhMy6PkNHvFEHeYXKPYVl0FwDla/yQHsfxZSG9s4zvfdWKc mQx5E/YUyTcv4GJDsPwfcbwKIGnftHaomZAw52+VTUO+73BoaBgHlYbei58A== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 68FD2F801AA; Sun, 7 Jun 2020 22:13:55 -0400 (EDT) Date: Mon, 08 Jun 2020 02:13:54 +0000 In-Reply-To: <20200608000213.A1FD71A46C3E@ary.qy> References: <20200608000213.A1FD71A46C3E@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 02:13:59 -0000 On June 8, 2020 12:02:13 AM UTC, John Levine wrote: >In article > >you write: >>-=3D-=3D-=3D-=3D-=3D- >> >>https://trac=2Eietf=2Eorg/trac/dmarc/ticket/38 >> >>The spec is ambiguous about which DKIM key needs to be reported=2E >> >>The real world problem here is that sometimes the DKIM key(s) which >are >>reported in a row of an aggregate report have nothing to do with the >DKIM >>key used to evaluate the DMARC status within the same row=2E > >How about saying that reports MUST include the key used to evaluate >the DMARC status, if there was one, and SHOULD include all DKIM keys >evaluated=2E > >The other ones can be useful, e=2Eg=2E, mailing lists usually resign thei= r >outgoing mail so if you have an idea what what lists are sending you >mail, that gives you a strong hint that a DMARC failure is due to mail >from a list=2E When you say 'include the key', do you mean put the literal public key in = the report or the selector which, in combination with the signing domain, t= ells one where to find the record in DNS? Scott K From nobody Sun Jun 7 19:35:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555283A094B for ; Sun, 7 Jun 2020 19:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=U5bEfZtw; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=nvLCkbOs 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 Px-jGLg5gCDC for ; Sun, 7 Jun 2020 19:35:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6D7653A094C for ; Sun, 7 Jun 2020 19:35:30 -0700 (PDT) Received: (qmail 37076 invoked by uid 100); 8 Jun 2020 02:35:28 -0000 Date: 8 Jun 2020 02:35:28 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=90cd.5edda3f0.k2006; i=news@user.iecc.com; bh=U8LHBryZa1s4Ou8Wjtuz43rAJJqAn5HEQnh7GZt6Le4=; b=U5bEfZtwazC0h6USL917ZHxwRtTP+X7+Jg9wIiG5GghqTkMJ5JOozvFHUWUYcig1B8OFJS0r61AM3RQlEAt1Ery2g9zXi0PLyATkSZPHK7EiSEuihJT6zx2Ks1y1jlmAvvFfKYqRJWa/dq2lRrc/E+Z+RYaJ6MToyvoSE/JqVnU8FZaI6FUEY++tCz0rssevY8Y3T0IprxykfLXX6pBRoBJ84TiFFh8SioPzMMTC4p/l2DnG+nxih5j5Ppr3ogrY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=90cd.5edda3f0.k2006; olt=news@user.iecc.com; bh=U8LHBryZa1s4Ou8Wjtuz43rAJJqAn5HEQnh7GZt6Le4=; b=nvLCkbOswwHsAr08kKVfWSyjY0WBTMylTW8hg/TbuoIzL0aCeXy5UJUsuZXot9rdsPFM1FcLmLIK+kEMWpmNV93AtcY84bXicpCOjzSqL+tfFpLo4ucTrqBL6IB1y/zqpXcCDOZCHfaD1yY6DJAkbVsVi8hpbbAgzORBCmdzhGWosuxGI/XqeNlreqinXTN56tRUoPna+e2cyYB5PhcdykU7c4fCmjI+IrTi/zVqbGpZ03CP2vq/+UQHwL08z7MX Organization: Taughannock Networks References: <20200608000213.A1FD71A46C3E@ary.qy> In-Reply-To: <20200608000213.A1FD71A46C3E@ary.qy> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 02:35:32 -0000 In article , Scott Kitterman wrote: >>How about saying that reports MUST include the key used to evaluate >>the DMARC status, if there was one, and SHOULD include all DKIM keys >>evaluated. >> >>The other ones can be useful, e.g., mailing lists usually resign their >>outgoing mail so if you have an idea what what lists are sending you >>mail, that gives you a strong hint that a DMARC failure is due to mail >>from a list. > >When you say 'include the key', do you mean put the literal public key in the report or the selector >which, in combination with the signing domain, tells one where to find the record in DNS? Sorry, domain and selector. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jun 7 19:58:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446093A0970 for ; Sun, 7 Jun 2020 19:58:05 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=5DFHTCmt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Zqxfx/Vu 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 QvKb9iTZ1Ha1 for ; Sun, 7 Jun 2020 19:58:04 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368053A096E for ; Sun, 7 Jun 2020 19:58:04 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 72ADFF801EA; Sun, 7 Jun 2020 22:58:02 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591585082; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=pltkkyWdHCfrg/N47bQN03S/eqXP+lt6AK4Fd9gmP/0=; b=5DFHTCmtePJL7rKG5SNyYh+Tx9BwyXW5Zwjz6drkHXHbhzr6HKGC4ux33rqPKcC67wGvQ W/fOVFv+PWTuX04CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591585082; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=pltkkyWdHCfrg/N47bQN03S/eqXP+lt6AK4Fd9gmP/0=; b=Zqxfx/VuCDTLeOr0jo1UzmYuDvtbIF/lbEDFStV0TLpBqubVo7R+RegKk5F8LopHWaIJW NMmp8TyyXX5QPkfu8flJLguH3Qwf1FgZZqXt3UL6HDPrViwKOMZGFLCe5LTK/vuyaUMWMQ1 1ucaPKmretP54bs2zVzXf2gL8dLoBb8mIUPI1LKb1BJ/NsdG4eRZcTCSzPeG3oxrb9zEkcu qxLT4eJn8/+GxkqD8jgH7dOm8SbDgrUTFRtwVrsIEKm+iB9vkBzNSE3ko6U+F0CVKRgL/AA EltRwhRfPfbKlEf32asXA0Fvgp5/FBqvOOfbRIR2VEUPyOhYxrrZ1tBkojmg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 02B65F801AA; Sun, 7 Jun 2020 22:58:01 -0400 (EDT) Date: Mon, 08 Jun 2020 02:58:00 +0000 In-Reply-To: References: <20200608000213.A1FD71A46C3E@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 02:58:05 -0000 On June 8, 2020 2:35:28 AM UTC, John Levine wrote: >In article , >Scott Kitterman wrote: >>>How about saying that reports MUST include the key used to evaluate >>>the DMARC status, if there was one, and SHOULD include all DKIM keys >>>evaluated=2E >>> >>>The other ones can be useful, e=2Eg=2E, mailing lists usually resign >their >>>outgoing mail so if you have an idea what what lists are sending you >>>mail, that gives you a strong hint that a DMARC failure is due to >mail >>>from a list=2E >> >>When you say 'include the key', do you mean put the literal public key >in the report or the selector >>which, in combination with the signing domain, tells one where to find >the record in DNS? > >Sorry, domain and selector=2E Thanks for clarifying=2E I think that makes sense=2E Scott K From nobody Sun Jun 7 20:04:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CB03A097A for ; Sun, 7 Jun 2020 20:04: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, FREEMAIL_FROM=0.001, 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=gmail.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 TYMQ8QtJUCDg for ; Sun, 7 Jun 2020 20:04:29 -0700 (PDT) Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (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 706E83A0977 for ; Sun, 7 Jun 2020 20:04:29 -0700 (PDT) Received: by mail-vk1-xa43.google.com with SMTP id t23so3608246vkt.5 for ; Sun, 07 Jun 2020 20:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DkxNWiVPG22Q9qcSU57Su8ggoXOiTHHcLmk2szUUsaQ=; b=sV8laat+2a2gByOby7gbcYIYoi/6aZrUXsGUrk2kDRS2Tlp2BgFYPawHGYoFGN5cVK romFrV49oP+158K8jZqIiH3u0lz1SDUWq9UO+Nvw6+AIHiTJwMKEjxMZWPZTOZmdEZZu HWcL056wA+IBPtWCg157CRuqNzexmlBzIIxYWtFzPVH7743L3jrBHh9zMIBCTlS4kXTy YBe+yjicV76UW1MuMX3wB/5JQlbVSZNCuVBu8dO9Cl2vP38FgmV+WqAJB/Lb3Vj0LGI6 Kpj0evcuosrWInoCJAlM9nzE4SKnM7xlenr+CtxS3B5n/BZKwGUnKyi9/otqGOQ/lM55 wunA== 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=DkxNWiVPG22Q9qcSU57Su8ggoXOiTHHcLmk2szUUsaQ=; b=lf4rj5movCh6t0y03OKeFRAvnZpcr9929FLOBqtPbLJVmn+Gw9QdWHru06ypqCPlQs kOFIHchfQQq+YAwgt1vw/FdD/pZdlKkexMtFeR0/oYXAA1Kr6gZG4/02iJH3+1orDtYR KUnZ2HVO54xlmW3GkvyagrTqPc573Nn+JN6VuWbxmkV43EXuXwxThGvZaY5suIENDTKt KJpR1FXSdnYF0O6KTNX6YoLar3OnY5UzTQxx1r7gWpJ33PJSnX87JT/p0Lmp4aACvH71 xmPDxUGjU56OxE3FsnixL8fjHkUKSBhlYsD+J1aIqSDWQMlU/KIok3uXOWicPGY+4lre YbpQ== X-Gm-Message-State: AOAM530S+YUw/dJlCdqLf9cOqiqnhq/9TbEQ3/xWkc8vqLUMQCMT2t5k dLPyZzXwlknQfVYYWrwFMsLwBhPVI5Ab0+uCpIAYTw== X-Google-Smtp-Source: ABdhPJwnBuRBWGZ2ZOO/Qs69DhxkMMfQil+ISVw2MM3kkLwPkgPhnO+L73nvLn2H4uPjyl2/E00VekBo5AdLNckOwGQ= X-Received: by 2002:ac5:ccf0:: with SMTP id k16mr13891791vkn.95.1591585467078; Sun, 07 Jun 2020 20:04:27 -0700 (PDT) MIME-Version: 1.0 References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Sun, 7 Jun 2020 20:04:14 -0700 Message-ID: To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000651a9405a789def2" Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 03:04:32 -0000 --000000000000651a9405a789def2 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > 1) The original assertion, that DMARC creates a conflict with prior > specifications, appears to be undefended and incorrect. For From > Addressing, It merely establishes some boundaries that the sender and the > recipient choose to consider appropriate. For DKIM, it creates a > use-case for a technology that was initially defined without any use cases. > Consequently, I think this topic is ready for closure. > I claim your assertions here are contradictory. Specifically, by establishing "some boundaries", it is creating a conflict with prior specifications which established none, possibly intentionally. 3) Some of the discussion has been about how to prevent soclal engineering > of the recipient user. This is an important topic, but not directly > related to the project. IETF would do well to establish some > recommendations about how MUAs should behave, so that trust data can be > displayed to the user. A typical user will have access to at least three > different email clients: one on his cell phone, a product-specific web > page, and a desktop product like Outlook or Thunderbird. If I wanted an > organization policy that controlled when Friendly Name was displayed or > DMARC status was displayed, I would have to find and distribute plug-ins to > all of these products. As best as I have been able to tell, no such > plug-ins even exist for Outlook and the other products do not accept > extensions. There is an opportunity here for valuable standardization. > The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts. Are you claiming that's changed? -MSK --000000000000651a9405a789def2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Sun, Jun 7, 2020 at 6:58 AM Douglas E.= Foster <fosterd@bayvie= wphysicians.com> wrote:
    1) The original assertion, that DMARC creates a conflic= t with prior specifications, appears to be undefended and incorrect. =C2=A0= For From Addressing, It merely establishes some boundaries that the sender= and the recipient choose to consider appropriate. =C2=A0 =C2=A0For DKIM, i= t creates a use-case for a technology that was initially defined without an= y use cases. =C2=A0 =C2=A0Consequently, I think this topic is ready for clo= sure.

    =C2=A0I claim your assert= ions here are contradictory.=C2=A0 Specifically, by establishing "some= boundaries", it is creating a conflict with prior specifications whic= h established none, possibly intentionally.

    3) Some of the discussion has been about how to prevent soclal = engineering of the recipient user.=C2=A0 This is an important topic, but no= t directly related to the project.=C2=A0 IETF would do well to establish so= me recommendations about how MUAs should behave, so that trust data can be = displayed to the user. =C2=A0 A typical user will have access to at least t= hree different email clients: one on his cell phone, a product-specific web= page, and a desktop product like Outlook or Thunderbird. =C2=A0 =C2=A0If I= wanted an organization policy that controlled when Friendly Name was displ= ayed or DMARC status was displayed, I would have to find and distribute plu= g-ins to all of these products. =C2=A0 As best as I have been able to tell,= no such plug-ins even exist for Outlook and the other products do not acce= pt extensions. =C2=A0 There is an opportunity here for valuable standardiza= tion.

    The IETF has routinely punted, = at least in the email space, on the idea of prescribing or proscribing user= interface behaviors because we are protocol engineers, not human factors e= xperts.=C2=A0 Are you claiming that's changed?

    -MSK
--000000000000651a9405a789def2-- From nobody Sun Jun 7 20:13:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617733A0991 for ; Sun, 7 Jun 2020 20:13:05 -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, FREEMAIL_FROM=0.001, 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=gmail.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 u4s2Um4slvCK for ; Sun, 7 Jun 2020 20:13:04 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 3B3033A0990 for ; Sun, 7 Jun 2020 20:13:04 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id g5so12475669otg.6 for ; Sun, 07 Jun 2020 20:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=kYFrejVir68jI3lfN5Y1q6ajttbQigvxCY6AetGznBs=; b=CZDnxcavllewPntzU12Om2rK23KSq22+GCP/wglKCSonmLR4bEJPxHk5jI+sia+v6F g5P8GUtAfBFJz7ypO1PeTnXksgXWkZmbwV3QetK2v6RAfZAczMUzvlIErtv0MzMiikFu 82VbcI2EWnaSdf8KhIJallYmTrcLL/d/YA9jTDcwP9P7/MwWjPllre9DUWv7ZRO6QPer ZmGI27tbTlQlCCWxBzNgF7tj9SplpC1Zodt15K6J28v+r3SjdgWANL3eTmt/vN/FrUwx XoKajLjge6dzJs77RvvZrWTlGyf1B2U4kbbNfQqQwM61QBUG112BnWTAg31l8RoyOWAU Z7ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=kYFrejVir68jI3lfN5Y1q6ajttbQigvxCY6AetGznBs=; b=WF3jUP735pQJDkMyIPy7O7kUUZ3tMtkrfaywtjAZaD3BWl0fHmylTXgET3Dp3r1iof SjZonBAg0VWE2D+Qk/zuP1v3MTzz+eRES8Jz8PMVaLYTUYUMGHbBh334XjwsSp5S89SM 9bg97Z+BdkhR+0j+bemzYLQXdxvuoUypiDTHWqfZ7fsuQaXhxX02lI1MpNzf33cJay+z 9XH/8EOaygNQPprCYBYgj2Lgpt1D642g72C6mFQUGS81jyBoftE0FmSP63VDhoPeZrzh 8wMJw1qYSTiFYNYm2nk24gAbAtSemf5uQxseMh7Y7IozwG99JCo1yQ5HiCaijab4L6zC zRNw== X-Gm-Message-State: AOAM530gUAs6IduSJ8yW/kACZOO2Bdf+eoA1gM8tHKJAomlFbaZpmRzj kyIrsQg2xHnRf4Vcs82dXiqWZCJO X-Google-Smtp-Source: ABdhPJxTvNAanJ0QC15nDzvJMP/tS5MdvhFKewAhTDVZejqKPVVejnD2MV7IdUcqusSQkKaG5RxW6A== X-Received: by 2002:a9d:d0e:: with SMTP id 14mr15150340oti.42.1591585983294; Sun, 07 Jun 2020 20:13:03 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:5443:4b56:d117:6ef3? ([2600:1700:a3a0:4c80:5443:4b56:d117:6ef3]) by smtp.gmail.com with ESMTPSA id n60sm1253782otn.75.2020.06.07.20.13.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 20:13:02 -0700 (PDT) To: "Murray S. Kucherawy" , fosterd@bayviewphysicians.com Cc: IETF DMARC WG References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> From: Dave Crocker Message-ID: <7ca6638f-7c98-3041-c24b-89a6d1d74681@gmail.com> Date: Sun, 7 Jun 2020 20:13:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AA4AB65006241970F3FA8AD7" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 03:13:05 -0000 This is a multi-part message in MIME format. --------------AA4AB65006241970F3FA8AD7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/7/2020 8:04 PM, Murray S. Kucherawy wrote: > >  If I wanted an organization policy that controlled when Friendly > Name was displayed or DMARC status was displayed, I would have to > find and distribute plug-ins to all of these products.   As best > as I have been able to tell, no such plug-ins even exist for > Outlook and the other products do not accept extensions. There is > an opportunity here for valuable standardization. > > > The IETF has routinely punted, at least in the email space, on the > idea of prescribing or proscribing user interface behaviors because we > are protocol engineers, not human factors experts.  Are you claiming > that's changed? A 'friendly' amendment, or rather addition:      The origination side of an email exchange has no authority over the reception side.  Different administrative authorities. Compliance with DMARC is voluntary -- and receiving administrations often implement behaviors that differ from what is requested via DMARC.      There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------AA4AB65006241970F3FA8AD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/7/2020 8:04 PM, Murray S. Kucherawy wrote:
 If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products.   As best as I have been able to tell, no such plug-ins even exist for Outlook and the other products do not accept extensions.   There is an opportunity here for valuable standardization.

The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts.  Are you claiming that's changed?

A 'friendly' amendment, or rather addition: 

     The origination side of an email exchange has no authority over the reception side.  Different administrative authorities.  Compliance with DMARC is voluntary -- and receiving administrations often implement behaviors that differ from what is requested via DMARC. 

     There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------AA4AB65006241970F3FA8AD7-- From btv1==428e278cf9e==fosterd@bayviewphysicians.com Sun Jun 7 23:03:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75A83A03F2 for ; Sun, 7 Jun 2020 23:03:33 -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 (1024-bit key) header.d=bayviewphysicians.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 8-agY-2hyTBg for ; Sun, 7 Jun 2020 23:03:32 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495683A03EA for ; Sun, 7 Jun 2020 23:03:32 -0700 (PDT) X-ASG-Debug-ID: 1591596209-11fa313a1093910001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id CkKhoZFDGc9BoqAb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 08 Jun 2020 02:03:29 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=OpGS5zfx1nsZg8CPiKZQb1OGJCd0gtBjyowOOY4PS/E=; b=KPbIM7MC8r9Oyzbl+UmuTyCbm/5m2EwvXFmnZEZqKuF4h17kZkTnsz7q9ES9lt3QF Knu5Aq/LnLFD/YsWFeNdURDWHzR2tnYaBHebSu7fpxH3xymy3w6taJJvQ6A2G5mno xF/Mo9Akq4jvpC7NXE+rBrEHahuz8Mde5b6lqOBsI= From: "Douglas E. Foster" To: Date: Mon, 08 Jun 2020 06:03:21 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] About user notification in the MUA Reply-To: fosterd@bayviewphysicians.com Message-ID: <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=df7b6df385ad4544b558048ebbebf1ea In-Reply-To: <33b12416-cd41-4826-9950-3afc9fdb83bf@www.fastmail.com> References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> <33b12416-cd41-4826-9950-3afc9fdb83bf@www.fastmail.com> X-Exim-Id: 3eb519fc08214b4bb23ed00737cdc0db X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1591596209 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 3390 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 06:04:39 -0000 This is a multipart message in MIME format. --df7b6df385ad4544b558048ebbebf1ea Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stan Kalisch asks: And you propose the average user can understand, much l= ess take the time to understand, the substance? Yes. I believe users are worried about spam, and want to make intelligent= decisions about whether or not email can be trusted. Unfortunately, our p= resent software denies them access to the available information needed to m= ake intelligent decisions. Dave Crocker observes: There is no basis for believing that requests = about MUA display will achieve meaningful support on the receive side, neve= rmind whether they would be at all useful. I was not talking about the sender. I was talking entirely about the rece= iving organization: its spam filter communicating to its MUA to communic= ate information to the end user based on its local policy. Dave Crocker also observes about end-user signaling failures: It's no= t that it 'seems to be'. It isn't nearly that soft. It is that there have = been multiple efforts over the years and none has demonstrated efficacy. Then lets restate that assertion in all its ugly elitism, and put it in= to an RFC: Incontrovertible research shows that humans will always act on malicious em= ail, and cannot be taught to do otherwise. Organizations should deploy em= ail if and only if they have automated tools which provide perfect protecti= on from unwanted email. End user training is useless. I have a higher opinion about my users than that. --df7b6df385ad4544b558048ebbebf1ea Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Stan Kalisch asks:=  And you propose the average user can understand, much less take the = time to understand, the substance?

Yes.   I believe users are worried about spam, and want = to make intelligent decisions about whether or not email can be trusted. &n= bsp;Unfortunately, our present software denies them access to the available= information needed to make intelligent decisions.

Dave Crocker observes:       There is no basis for believin= g that requests about MUA display will achieve meaningful support on the re= ceive side, nevermind whether they would be at all useful. 
=
I was not talking about the sen= der.   I was talking entirely about the receiving organization:  =  its spam filter communicating to its MUA to communicate information = to the end user based on its local policy.

Dave Cr= ocker also observes about end-user signaling failures:      = It's not that it 'seems to be'. It isn't nearly that soft.  It is tha= t there have been multiple efforts over the years and none has demonstrated= efficacy.

    Then lets restate that as= sertion in all its ugly elitism, and put it into an RFC:
  &= nbsp;
Incontrovertible research show= s that humans will always act on malicious email, and cannot be taught to d= o otherwise.   Organizations should deploy email if and only if they h= ave automated tools which provide perfect protection from unwanted email. &= nbsp;   End user training is useless.

I have a higher opinion about my users than that.

--df7b6df385ad4544b558048ebbebf1ea-- From nobody Mon Jun 8 01:11:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2498B3A097E for ; Mon, 8 Jun 2020 01:11:22 -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, FREEMAIL_FROM=0.001, 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=gmail.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 Wm7jFcSkek4I for ; Mon, 8 Jun 2020 01:11:19 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 1D17C3A097C for ; Mon, 8 Jun 2020 01:11:13 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id d21so8885617vsh.12 for ; Mon, 08 Jun 2020 01:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nRfrockg00Z5kcF9KGippaR5+U781MPs2YwVpVdBa8E=; b=vHe6Uc6POb67J1V53x8ZEtcl3VFz8ODR/dPNT1BzIKop+7cAIXQpt3KhoyG8OXI3Ed jMyywno+vd5YhKy19sTMArqjyxNSnsncJaDwz1l123XxlLnq9iDxB8DrivXXCVjCjD3h JMDTIvBkxvE0YjqEJfRWnw+Ti4IteRlbvWWQ0e6kl2GiYjRNtcIj3fyOJWHLjGJzuhTh 8r/SlrgAXL/fQkzr16M62GmNYt71H0dymFbO4WdEGB6I37STVEa81weyQzPTc2v3rHx+ NRQy2C9GebZskCwNZzC8vfvJEzkmYrOU8w7STIOiIb2ZDqoF0Zo50/mmbu6BBfKkoz0W yLpg== 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=nRfrockg00Z5kcF9KGippaR5+U781MPs2YwVpVdBa8E=; b=sdfpbuK8pnTW4QA09oOmnxAdiE68gcm/5TUG009itSriskmt6NYIZurzsbG2hf/pmU t6TV+42AhdysAPt9IwFLTXBFVybJA7ejO79mO8VImguepjHVCNWkV1y7L3srVvS0pJvp POOYoQ2KU6nuqyZkm3xfwEtab5GT32L3KRX3fv/GsmvNwxIH/WD9LhC2w54wr8sZki/+ mVdRPmimu44cfKaJYz93wAdNpndmwpoXkS2nnwKLtGkiCqkpCom8YbFcJQpF125MRE7K 4olUsLD3z8fRX4DRG6rX0/ANOo+JE97VUedxHFDcIFljzgbfAQxXAk7KKQVq8QI2o4Yq zssg== X-Gm-Message-State: AOAM530i0n5C5+a3sgLpfe561Jm2+fhRRhZzFTNgL1ojlPuuCSlyly5m x/YVr7x+rwSk4FDIklVqQVkLGVEjpTIMRooAfDsrN4fp X-Google-Smtp-Source: ABdhPJxWjPxJED/T1gWISxJBb1ele0fCnGR6ZyXmVQeJHYRropyyg6Idz4s/gSINpehFTgR6DAn2zO3rAZL3m5QzMmk= X-Received: by 2002:a67:7dcd:: with SMTP id y196mr13954127vsc.13.1591603871949; Mon, 08 Jun 2020 01:11:11 -0700 (PDT) MIME-Version: 1.0 References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> <33b12416-cd41-4826-9950-3afc9fdb83bf@www.fastmail.com> <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> In-Reply-To: <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Mon, 8 Jun 2020 01:11:00 -0700 Message-ID: To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000069265005a78e2748" Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 08:11:22 -0000 --00000000000069265005a78e2748 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 7, 2020 at 11:04 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > Stan Kalisch asks: And you propose the average user can understand, much > less take the time to understand, the substance? > > Yes. I believe users are worried about spam, and want to make > intelligent decisions about whether or not email can be trusted. > Unfortunately, our present software denies them access to the available > information needed to make intelligent decisions. > A study presented some years ago now, I think back when DKIM was young, (if I can find a citation, I will send it along) found that a statistically significant -- it was more like 18% -- portion of their test subjects would willingly click on links found in their spam folders if the email found there looked legitimate. That's right, they weren't just clicking links in their inboxes, they were clicking links in a partition of their inbox expressly created, and named, to store stuff the receiving system thought was probably dangerous. The theory, as I recall, was that they were worried they were missing something important. Who were these users? As I recall, the study was run by a collaboration of banks attempting to ascertain the gullibility of their typical customers. That seems to be data antithetical to the notion that users are universally worried about spam and want to make intelligent decisions. Moreover, these particular users were presented with information clearly marking these messages as possibly dangerous, insofar as they had to click through to their spam folders first. They did it anyway. Dave Crocker also observes about end-user signaling failures: It's > not that it 'seems to be'. It isn't nearly that soft. It is that there > have been multiple efforts over the years and none has demonstrated > efficacy. > > Then lets restate that assertion in all its ugly elitism, and put it > into an RFC: > > Incontrovertible research shows that humans will always act on malicious > email, and cannot be taught to do otherwise. Organizations should deploy > email if and only if they have automated tools which provide perfect > protection from unwanted email. End user training is useless. > > I have a higher opinion about my users than that. > I wonder on what basis. Given the contortions through which we went to produce even the vague text in Appendix D of RFC 6376, we didn't know then what would work. I don't think today is any different, or we'd be doing it already. -MSK --00000000000069265005a78e2748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 7, 2020 at 11:04 PM Douglas E= . Foster <fosterd@bayvi= ewphysicians.com> wrote:
Stan Kalisch asks: =C2=A0And you propose the average u= ser can understand, much less take the time to understand, the substance?

Yes. =C2=A0 I believe us= ers are worried about spam, and want to make intelligent decisions about wh= ether or not email can be trusted.=C2=A0 Unfortunately, our present softwar= e denies them access to the available information needed to make intelligen= t decisions.

A study presented = some years ago now, I think back when DKIM was young, (if I can find a cita= tion, I will send it along) found that a statistically significant -- it wa= s more like 18% -- portion of their test subjects would willingly click on = links found in their spam folders if the email found there looked legitimat= e.

That's right, they weren't just clickin= g links in their inboxes, they were clicking links in a partition of their = inbox expressly created, and named, to store stuff the receiving system tho= ught was probably dangerous.=C2=A0 The theory, as I recall, was that they w= ere worried they were missing something important.

W= ho were these users?=C2=A0 As I recall, the study was run by a collaboratio= n of banks attempting to ascertain the gullibility of their typical custome= rs.

That seems to be data antithetical to the notion that users are = universally worried about spam and want to make intelligent decisions.=C2= =A0 Moreover, these particular users were presented with information clearl= y marking these messages as possibly dangerous, insofar as they had to clic= k through to their spam folders first.

They did it= anyway.

Dave Crocker also obser= ves about end-user signaling failures: =C2=A0 =C2=A0 =C2=A0 It's not th= at it 'seems to be'. It isn't nearly that soft.=C2=A0 It is tha= t there have been multiple efforts over the years and none has demonstrated= efficacy.

=C2=A0 =C2=A0 Then lets restate that assertio= n in all its ugly elitism, and put it into an RFC:
=C2=A0 =C2=A0<= /div>
Incontrovertible research shows that h= umans will always act on malicious email, and cannot be taught to do otherw= ise. =C2=A0 Organizations should deploy email if and only if they have auto= mated tools which provide perfect protection from unwanted email. =C2=A0 = =C2=A0 End user training is useless.
<= br>
I have a higher opinion about my users than that.
=

I wonder on what basis.=C2=A0 Given the contort= ions through which we went to produce even the vague text in Appendix D of = RFC 6376, we didn't know then what would work.=C2=A0 I don't think = today is any different, or we'd be doing it already.

-MSK
--00000000000069265005a78e2748-- From nobody Mon Jun 8 01:24:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7893A09C9 for ; Mon, 8 Jun 2020 01:24:14 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 9rS1H0lt04Oy for ; Mon, 8 Jun 2020 01:24:12 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 332C73A09C3 for ; Mon, 8 Jun 2020 01:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591604648; bh=e/8Zo3Vpu9P0Lo4PU5xxMOLfBDLKR2yUQjrcNJQkOpE=; l=2074; h=To:References:From:Date:In-Reply-To; b=DcCVj1qduanEn6T1v/NN/42oUpQ1gkL0kxV/tQvHCxyFEaDl8qbnE/DZ2a6xLWPaw jqr/h8Fu/YE/07OJUzLL2Oq+3HZuAsByEBnrvwzAzgkVdAOYYQBplsQ5FuyY6wk6F0 Z+PIeBCO6uX3Una5ZsowXXnCxKo805JSfPYSqDxFKzz58mDIKHd/LVvpPzvja Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EDDF5A8.0000778B; Mon, 08 Jun 2020 10:24:08 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <27affddf-4f13-ff6a-17b5-746c6bd57d79@tana.it> Date: Mon, 8 Jun 2020 10:24:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 08:24:14 -0000 On Sun 07/Jun/2020 23:23:16 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/51 > > In a DMARC aggregate report, a record with a disposition of "none" is > ambiguous, as a disposition of "none" at p=none means a different thing (that > no action was taken on the message) than a disposition of "none" if the DMARC > policy is reject or quarantine (the message passed an aligned authentication > check of either SPF or DKIM, and was therefore not subject to policy). > > It is desirable to have logically distinct disposition responses, and if so, > what should be reported in the latter case? As a straw man, "pass" instead of > "none"? The current spec, RFC 7489, does not dwell too much upon message disposition, but it is clear enough. IIRC, some ambiguity was intentional, letting "none" mean that delivery was not altered, which is not the same as telling the sender whether the corresponding messages did it to respective mailboxes or not. The report producer may be reluctant to disclose that detail, and/or further filtering decisions can be made downstream —even by the MUA— without informing DMARC agents. All in all, the current enumeration DispositionType looks fine to me, although the comment in Appendix C should clarify that it is used both for published and for evaluated policies. Personally, I do write dmarc=pass in the Authentication-Results header fields only when the "pass" comes after a strict policy. This is a per-message datum which may be worth highlighting in the UI. However, I don't think aggregate reports would be clearer by distinguishing such cases. They are not usually read by human eyes, and software can easily deduce that value by comparing with policy_published. The margin of error is limited to the case of single reports generated for periods during which the published DMARC policy changed. Yet, such events seem to be less likely than the possibility of reports erroneously reporting "pass" even when the policy published was steadily "none". Best Ale -- From nobody Mon Jun 8 02:19:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6E33A07A6 for ; Mon, 8 Jun 2020 02:19:34 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 v18Xq3hbADgH for ; Mon, 8 Jun 2020 02:19:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E6DBD3A079D for ; Mon, 8 Jun 2020 02:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591607970; bh=/u1q4YVZFi1aifdYIyeXHReMb0e7rrE3CNvjTeO51yo=; l=2078; h=To:References:From:Date:In-Reply-To; b=CK7DLSNkafhvittY7rxptzelw54Gx6LKfSIUNTrEdVkm541eStyIZ7dyegL3X8Akw PGHelR0w1Q9hcr9ck9ok8yAwcDPUfPJEdwHC+OqYOXG/nXTP8ufHvlPv1i81yrGAqb b90NMzXfzf8XNJccZqVEU3GJXRYAITD3yucRZD3BNZCUKxOkQjAOgRKaEN+Sn Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EDE02A2.00000178; Mon, 08 Jun 2020 11:19:30 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <49ee1afc-5127-75e6-1ab6-c2a9d51a11a7@tana.it> Date: Mon, 8 Jun 2020 11:19:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 09:19:35 -0000 On Sun 07/Jun/2020 23:23:17 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/66 > > Many different entities participate in DMARC, and to each, there is a different > definition of what is needed to "implement" or participate in DMARC. > > Should the spec be clear about the different participants, and what it means > for each to participate partially and completely? The spec should encourage participation, but there is no badge to be won. > As a straw man to start conversation (assume this is all wrong): > > The domain owner: >     - partially participating: valid record? >     - complete participation: no part of the domain hierarchy can be spoofed by > an unauthenticated sender? That's what many MTA-check tools improperly hint at. It is wrong. We cannot /recommend/ strict policies, at least until the mailing list problem persists. > The receiver/MTA: >     - partially participating: validates DMARC? >     - complete participation: validates DMARC and ARC, and sends aggregate reports? ARC is not a subset of DMARC, as the substring occurrence could mistakenly suggest. It should not even be mentioned in a DMARC spec. To validate DMARC is an obvious requisite to participation. It doesn't mean that the suggested disposition should be (blindly) honored. To generate aggregate reports in order to inform the sender /as well as the receiver/ on how DMARC works is a useful, recommended exercise. > The intermediary (is this different than a receiver?): >     - partially: validates DMARC? >     - complete participation: validates DMARC and validates and seals ARC? I tend to identify intermediaries with mailing list operators. It is time to say something about From: rewriting, otherwise DMARC remains a wannabe. ARC is not going to solve the mailing list problem any time soon. Since From: rewriting is the de-facto standard, we should at least report our experience with it. It may be an integral part of the DMARC spec or a separate document. Best Ale -- From nobody Mon Jun 8 02:46:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8A3A0811 for ; Mon, 8 Jun 2020 02:46:57 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 tsvBMehtv5iQ for ; Mon, 8 Jun 2020 02:46:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 B50F03A080E for ; Mon, 8 Jun 2020 02:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591609610; bh=vuqse2PYfenn6uEwiWI//zV6AfTOxrfM/1zCTOgs6KY=; l=2083; h=To:References:From:Date:In-Reply-To; b=DefV+DGcIK+r1DtB7zbBTRqR9mdUKfwtKo7fhOHbr1uFRrolw+mABBreDX7jvV8WC JwmW35WcuGghcHouQ/TSdV9c2oL2HaObtzjW1xdbWOFOxr7fcGILy0TTdBamROOIh/ xddpVUlJntMzRvZGgYmz7vrfNAQxUHKWJv3e0d3KnCg9u9YN9gDlsBTvWa0+P Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EDE090A.0000053D; Mon, 08 Jun 2020 11:46:50 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Mon, 8 Jun 2020 11:46:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 09:46:57 -0000 On Sun 07/Jun/2020 23:23:12 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/38 > > The spec is ambiguous about which DKIM key needs to be reported. > > The real world problem here is that sometimes the DKIM key(s) which are > reported in a row of an aggregate report have nothing to do with the DKIM key > used to evaluate the DMARC status within the same row. > > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: > >     The report SHOULD include the following data: > >         o  The identifier evaluated by DKIM and the DKIM result, > > Elizabeth Zwicky previously wrote: > > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ > "is genuinely unclear. Often there are multiple identifiers. Does this mean I > can pick any one of them? (That does not actually provide sufficient > interoperability.) If there’s a specific one I should pick, which is it?" > > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ > "I believe they MUST contain any aligned DKIM signature regardless of validity > and SHOULD  contain an entry for each domain, selector, result triple." I think every MTA can have its own criteria about how to order DKIM signatures in each message. For DMARC validation, aligned signatures are important. Valid signatures are more important than invalid or non-verifiable ones, although reporting unverifiability is important. Signature by trusted domains are more important than those by unknown ones. Key size also matters. These are all subjective criteria. > Is it desirable to clarify this language, such that it is clear which DKIM keys > are required to include in a report, and if so, how should the appropriate > keys be determined? Signatures should be reported in order of decreasing importance. The more signatures are reported, the better. The subjective order in which they appear is part of the informative content of the report. Software should allow to configure ordering criteria when possible. Best Ale -- From nobody Mon Jun 8 04:11:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F133A0913 for ; Mon, 8 Jun 2020 04:11:56 -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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 SATSm9Rod9ib for ; Mon, 8 Jun 2020 04:11:54 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 11AE03A0874 for ; Mon, 8 Jun 2020 04:11:52 -0700 (PDT) Authentication-Results: mail.aegee.org/058BBkqA3711312; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1591614708; i=dkim+MSA-tls@aegee.org; bh=AaEjD2FXa9xOsznkFrTEBjgnVQeHjOu2Dn5R4HRX8Bk=; h=Subject:From:To:Date:In-Reply-To:References; b=RUAHaMpBFlFbPT7NigxtuiPya06VN67GNvufNuxyhyEidhhbWRUmVwEAOcY1ZQnlR KglZP2TakieXPb7fzoRwrkYNalIZQab0KBHS4aC/BhdEj5bWHWcSRB3urtVqEuC4s9 MKvOAfnA8dlwp6wt8a+63OJaGjDio+o83q7dunjkLMYMiA54N8AeASqjD1Bco2+mH3 j6NbqHpZYcHgeni7lSmGvDHYKPu2IpBdO1ttYyP2MvcinbhSFQ4T09vMgSNQ9lGryK JGWU8kAFMgcAw8v56VGLFdZzrKd45djDi5UHJRzbIbQ4MGvWmrFkLQTdmEJRW+xLKL r0fGmv/omLBx8MKtC7FynuFBT4tW2DjYre7XTgGy98XwQmRR6akyYyt9ubKquWaIuX WvUlsIYp8eS20khYyXlNGhhtlXSj4nEt5UDx1n82+mYZrJYlwQKH5wfMNTr8Y12r00 0jzlQd/IjXRe0SmJiDLftCP+nSHHHB3Qzd5iF77ht9z+ImS/emtrN3ZHn+Fs7Lg3FR ojJrhbcLp3UJin6awU5ZVI1IMa/WmcgIbHsI9IsuB0xSZ8wj11djPDBe+Y5dQvqysi 8+1c27ZF6u1rp3unVSn2wUo4z20TvLIQQVxiZzs+d3c629PjaXmDcBXeHZ3mIwELcS y6BC/kBb6MWBYPJhEJ/dATdA= Authentication-Results: mail.aegee.org/058BBkqA3711312; dkim=none Received: from Tylan (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 058BBkqA3711312 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Jun 2020 11:11:47 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: fosterd@bayviewphysicians.com, dmarc@ietf.org Date: Mon, 08 Jun 2020 11:11:46 +0000 In-Reply-To: References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.37.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.3 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 11:11:56 -0000 Hello, when a message is wrongly evalutated as spam, and is left therefore unnoticed, it is nobody’s fault. You can signal the users as you want, including the users, which just redirect mails on your host, and do not utilize the “Spam” store there. A message is either likely spam (subject to signaling), or it is not likely spam. When the message is likely spam, you can signal the sender by sending a non delivery report. That report can contain information, entered by the intended recipient, like snail mail address or phone number.  If you signal the sender (by rejecting at SMTP level) you do not need a signaling method on the recipients’ side, that works across all MUAs. Besides, there is no “nobody is fault for the overseen signaled message”. If you run a server with 10 local users and 10 000 redirecting addresses (aliases), you have to use a signaling method, that does not break the DKIM-signature, and works for redirected emails. For users that utilize just redirecting there is no “neither likely spam, nor unlikely spam” category. And the other users also do not need such category. Greetings Дилян On Sun, 2020-06-07 at 23:04 +0000, Douglas E. Foster wrote: > I am trying to play by the rules and not chase topics outside the one > assigned, but since several have jumped on my comment, I will follow > up briefly. > > Dave Crocker wrote > Since there has been a demonstrated lack of efficacy in this sort of > display, there needs to be an objective basis for knowing that any > new such requirement will be useful. > > Every email filtering product that I have examined has provided a > user-signaling system, using one or more of the following: >  * tagging the subject,  >  * adding text as a body header or body footer >  * converting the suspect message into an attachment of  a > replacement message, >  * soft-quarantining, where the user has unrestricted control to > release the message from quarantine. > Given that market reality, I conclude that most vendors and their > customers believe that user-signalling is useful.   The signalling > system does not have to prevent every mistake for the signal to be > useful. > > The problem with all current notification methods is that they are > relatively primitive, often communicating nothing substantive about > the suspicious message characteristics.  They also work against other > security mechanisms.    >  * Any form of tagging breaks DKIM signatures, reducing the > credibility of the message if it is auto-forwarded for any reason.   >     >  * The tagging also becomes tattooed to the message and its replies, > rather than being restricted to the trust domain that assigned the > tag.   One example should suffice:  a message was tagged with [SPAM?] > because the sender had an error in his SPF record and I was trying to > enforce SPF.   Then when my staff replied, the originator treated the > reply as spam because the word SPAM was still in the subject line > when he received it!    > We need a user notification mechanism that is local to the trust > domain and does not break DKIM signatures.  You have already done the > heavy lifting for this interoperability problem with Authentication- > Results and ARC   I am not expecting a "Standard" that requires every > implementation to notify every user in the same way.   I am looking > for a guidance document that helps vendors to deliver products which > permit an organization to implement a notification policy which they > find to be effective and appropriate.   IETF is the right > organization to take this on because the email filter, the mail > system, and the multiple MUAs are almost always a multi-vendor > configuration. > > df > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Jun 8 08:03:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF9C3A0F37 for ; Mon, 8 Jun 2020 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ekDgmvWS; dkim=pass (1536-bit key) header.d=taugh.com header.b=X3y6oRNv 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 r6VPnImesSCx for ; Mon, 8 Jun 2020 08:03:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0086F3A0D2D for ; Mon, 8 Jun 2020 08:02:52 -0700 (PDT) Received: (qmail 90938 invoked from network); 8 Jun 2020 15:02:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16338.5ede531c.k2006; bh=TKeiAYFfMaojPdeIxu0R81tcS+6EOODrzxJHcXXLup4=; b=ekDgmvWSbYgIct+6kglPaOOa1VS7LP/oiEquVsEThSixuhBLEomQY4MEhsgVf9ueSi6aOEWa1OqG9tmNT3V/0TITs2kMrMXiQxZZrgXxiKnqfdMSoJM/dMSxeVZHlUMjhge+eRYyQDdwr5cRuq6JcVi+Y5CvQkulYFU1SvHqcCTQkl7yLC1TGa7pdMx+RK4NjRXdDxuGjyhkzsu8LdbP2/tMgAdAL0Q8IlM9GNeMj/YRjw+lMsp2SIEiv5muv4HW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16338.5ede531c.k2006; bh=TKeiAYFfMaojPdeIxu0R81tcS+6EOODrzxJHcXXLup4=; b=X3y6oRNviMS4UTQiTGLMupnL7JiK0+Xp6IZ0gqLnKV7UA5nZcFfqgWLFchz0KEFPusNrtEG1UY7kuBoRYkmS5o16Bw6AfyoVMyYcMl51yATBWD4uL3Dzg195GScH8rvKnVMx4NWA3LAYe/P6mRMsHm6Da41zMwsH461/q3ETbWxxZHRA4PMSS9tkdTE5n7Fx10VEgbkymY33jjmU0xetIVI3u9iUOE+pXEPXXl3mpKWAhd2h0lTeWdHrIn1NdGVb Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Jun 2020 15:02:51 -0000 Received: by ary.qy (Postfix, from userid 501) id B368E1A4BB49; Mon, 8 Jun 2020 11:02:51 -0400 (EDT) Date: 8 Jun 2020 11:02:51 -0400 Message-Id: <20200608150251.B368E1A4BB49@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 15:03:33 -0000 In article <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> you write: >Yes. I believe users are worried about spam, and want to make intelligent decisions about whether or not email >can be trusted. Unfortunately, our present software denies them access to the available information needed to make >intelligent decisions. When I said our intuitions about UI in the IETF are wrong, this is exactly what I had in mind. As others have said in more detail, there is no evidence that users make "intelligent" decisions about what is spam, and considerable evidence that they don't. We're not saying that users are stupid, beause they aren't. But we are saying that their intuitions about how to treat their incoming mail are a poor match for the reality of what's in the mail. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jun 8 09:45:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCF13A0D56 for ; Mon, 8 Jun 2020 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk 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 WK_1GZzt3bB0 for ; Mon, 8 Jun 2020 09:45:19 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110139.outbound.protection.outlook.com [40.107.11.139]) (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 6A5583A0B88 for ; Mon, 8 Jun 2020 09:45:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fTNLlWOzdGWBLAa98e+WO+08/9cS2UB4/oBQ92545cgrX+u4ZyLoXGdBj93iBafHj3lr9esAE//HgZuWLbmcmA3kWOKn1JJlWQS/r2aU6fsxzTid/qXMHMxkZ/pFYxTjTOT1B7vNPKJ+IF5tWlnYvGl4XYNJ7/MCDtN14VH27aefbPhK0ymZtE7XvnGtrH4vJZyRvxQr7dPGEubvoVhrve47xzK9AX2JGNnyM/pUDmP5tspQGlhM9wTS6UWV+CGPY6HZ0l+BlWpwtF9Mlsd/O/Rt1+H3mnMSe8zhlZZ/D2c3soNQDX9lz62t+gsCttsU94cC+k1MAcx8Godk4fABqQ== 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=SLQ9tJtUHsSzp+0gckzFm5s+FMpNg8xLIcI8vNqgrtI=; b=PZHYaxy7wC0mtWn66m1vKQAznA7XzNNbXb4mlXOylfabyvGNIi7jUC3MLN/zfauhVL/+wPaHArnUOAAYuP3HoEjMHBw2ZOeqvNi/v1iT0ZcinKNMA6S54+HKOwEKSF1MntcqZPauQwyOx+QPNnpOERz6jcBZET7dJ4DTCA+GWwP3t1XSCxHpdUI6Sf3XGsU1vybMQ0XcgVzcpzcWhKn5/SEmgYwiwWCizSouq5j9DijaQyDAUuUGRsKbbAh+rvWygKmeVF+BN3439lsb317rpV/vlgtDedfkzakQxravvrwPt+odz0k3yPIRItIHnCjxJ4HqbSUBTGxUi1W35RFsBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SLQ9tJtUHsSzp+0gckzFm5s+FMpNg8xLIcI8vNqgrtI=; b=IrUnmYq+k/7ATQGOtOHaXwJtlTF7ceXy6l28jbuxjyzVMzB8NFMGgdPXRyqOiiYRwj68t1HND1HI+p3PJVjKgDK6b5efTEWm9yPW5CP/6jGCnL93EEHxXiPGsRQX7IPrJ9Svc4b8b+NTPA9/ofo2ZS0HUAELkNJh2GRbISnBtLjqPqlNryCOkPw+1ePYLFu4XJjIeerm9AaRtmCcTNVdGzd3ZP31gkUK8vTn43HQpKn6G1MAA8fqVbXe22G9LZxph4OWGSm15uDNRxaIHUKWWuoVybNkPqFN2wHRFq8/8SI0H8jwQZGD5t1P1OL6IUisuRQ25BNHanPP9iWosN5VzQ== Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c1::23) by LO2P123MB1712.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 16:45:17 +0000 Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117]) by LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117%7]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 16:45:17 +0000 From: David I To: Seth Blank , IETF DMARC WG Thread-Topic: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC Thread-Index: AQHWPRH/HzBNi94q8kqbJc5s/vMQ66jO6pg1 Date: Mon, 8 Jun 2020 16:45:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB 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=ncsc.gov.uk; x-originating-ip: [51.141.34.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a6f254c-a5b1-45e0-e2f7-08d80bcb5304 x-ms-traffictypediagnostic: LO2P123MB1712: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2MrIdvWzlxfpovHDkz+IIMo9fkOsTRTK9XGbYy+TrRjIZu0yj8GnEqmz3vB1zS2Rx4y+W6SwT0nUxLXdw/4utNPguoSreX1V/a0PIuL4VBPZzvanmCvxski7whHayj+//fdp3EXrndnQvMRfdph42an6CA56xpwK+wQ0SR3Twt5L4hk1BbTbEStFT/4bC7nXO+mvAtF8ALLKRoCGUVUitUXi0QerxbbK0OVBr5iY7noc/NVpH7l7R9JGjeqt8AA3lmES00QdzwUAxbm85edRhd52C0JiRQUdgUn9F+6MYbyKZAtCJMSmO8Dy634bCtG54kZQcwkY2tvA1cAX22m7cYgwkN1vl3fbCRBdBX37Ze53gIlcvOSbG/+buVGIl+GPOnFQ+fyxt6tl5wBq+1Uuig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(396003)(376002)(136003)(39850400004)(186003)(52536014)(6506007)(53546011)(71200400001)(33656002)(478600001)(55236004)(86362001)(7696005)(2906002)(26005)(8936002)(76116006)(66446008)(55016002)(66476007)(966005)(9686003)(66556008)(66946007)(5660300002)(166002)(83380400001)(316002)(8676002)(19627405001)(110136005)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NLb7DuTgwtvU8mUusAD1k/ZEzg4B+1bxYrBwTW7dQMDqwgx0eNcWBZshozu4hKl6a6UMZElW+VHgzyyMIKI6tioBN3Ch3Fs5o/z28nyN9kPOKDxFpUkikWLBJ0X3gqmJtPqhWA3iyQwQ09aW+/Uyndx5CEsxvypbOlc/AyM8eGRvdSiqfcYFVVWkEhE1RTcgl76S7RmHxU0Oj47E4tidCNA9m1uZ7a+0hc/rqczdwslekGhtkhjx4WZjz0kTgexauJ7j5JiyQZRH9Q7F5Nam69EWHqBZwrlGfyuAnMfFPh11J/ubghzODuoGlecpA04/iTuUd2Nw8dH6BPA9AEHaGa8cfVw2PulwuK3l/WuFoXpe6JIu8NHTgSmtctPexq7TgiMRhqevKo0fk/ODPGaAGzBbjLuHUGOPStBtK0ln6MvSWkLij46I6O9+tun3Xo5EYVbSs48NHLz1rxkB0ABRUNWr6MmkrHZkL89LEKXeaDM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB2192FE5F479FA7FE9080925DBE850LO2P123MB2192GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 5a6f254c-a5b1-45e0-e2f7-08d80bcb5304 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 16:45:17.1221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MOMXFo8LQYn3I7bwIygQGJuyF59P+gwpKezDfyG2EUI0SKEFyRDv+z97APLo4V71dZtcEZUN9BSIHMx6P4XH1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1712 Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:45:21 -0000 --_000_LO2P123MB2192FE5F479FA7FE9080925DBE850LO2P123MB2192GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't know how to represent it in documents, but I do think there would b= e value in clearer terminology to help people trying to adopt (and buy solu= tions). I worry that there are people saying they've 'implemented DMARC' wh= o are doing one of inbound filtering, or have published a policy, but not b= oth (I think most simply aren't aware of aggregate reporting as being poten= tially a separate thing). I think issue #41 "Potentially separate reporting and policy into different= documents" might be related as if there's a separate RFC number for sendin= g aggregate reports, there's a clearer line about whether or not you've imp= lemented it? David ________________________________ From: dmarc on behalf of Seth Blank Sent: 07 June 2020 22:23 To: IETF DMARC WG Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to impleme= nt DMARC https://trac.ietf.org/trac/dmarc/ticket/66 Many different entities participate in DMARC, and to each, there is a diffe= rent definition of what is needed to "implement" or participate in DMARC. Should the spec be clear about the different participants, and what it mean= s for each to participate partially and completely? As a straw man to start conversation (assume this is all wrong): The domain owner: - partially participating: valid record? - complete participation: no part of the domain hierarchy can be spoofe= d by an unauthenticated sender? The receiver/MTA: - partially participating: validates DMARC? - complete participation: validates DMARC and ARC, and sends aggregate = reports? The intermediary (is this different than a receiver?): - partially: validates DMARC? - complete participation: validates DMARC and validates and seals ARC? -- Seth Blank | VP, Standards and New Technologies e: seth@valimail.com p: 415.273.8818 [https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS= 0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT= 2x5EcZV3rjz19-Dx9rESL] This email and all data transmitted with it contains confidential and/or pr= oprietary information intended solely for the use of individual(s) authoriz= ed to receive it. If you are not an intended and authorized recipient you a= re hereby notified of any use, disclosure, copying or distribution of the i= nformation included in this transmission is prohibited and may be unlawful.= Please immediately notify the sender by replying to this email and then de= lete it from your system. This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB2192FE5F479FA7FE9080925DBE850LO2P123MB2192GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't know how to represent it in documents, but I do think there would b= e value in clearer terminology to help people trying to adopt (and buy solu= tions). I worry that there are people saying they've 'implemented DMARC' wh= o are doing one of inbound filtering, or have published a policy, but not both (I think most simply aren't aware= of aggregate reporting as being potentially a separate thing).

I think issue #41 "Potentially separate reporting and policy int= o different documents" might be related as if there's a separat= e RFC number for sending aggregate reports, there's a clearer line about wh= ether or not you've implemented it?

David
From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Seth Blank <seth=3D40valimail.com@dmarc.iet= f.org>
Sent: 07 June 2020 22:23
To: IETF DMARC WG <dmarc@ietf.org>
Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to = implement DMARC
 
https://trac.ietf.org/trac/dmarc/ticket/66

Many different entities participate in DMARC, and to each, there is a = different definition of what is needed to "implement" or particip= ate in DMARC.

Should the spec be clear about the different participants, and what it= means for each to participate partially and completely?

As a straw man to start conversation (assume this is all wrong):

The domain owner:
    - partially participating: valid record?
    - complete participation: no part of the domain hie= rarchy can be spoofed by an unauthenticated sender?

The receiver/MTA:
    - partially participating: validates DMARC?
    - complete participation: validates DMARC and ARC, and s= ends aggregate reports?

The intermediary (is this different than a receiver?):
    - partially: validates DMARC?
    - complete participation: validates DMARC and validates = and seals ARC?


--

Seth Blank | VP, Standards and New Technologies
p: 415.273.8818



This email and all data transmitted with it contains = confidential and/or proprietary information intended solely for the use of = individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notifie= d of any use, disclosure, copying or distribution of the information includ= ed in this transmission is prohibited and may be unlawful. Please immediate= ly notify the sender by replying to this email and then delete it from your system.

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9
--_000_LO2P123MB2192FE5F479FA7FE9080925DBE850LO2P123MB2192GBRP_-- From nobody Mon Jun 8 09:54:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4113A0DCB for ; Mon, 8 Jun 2020 09:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=S0pA8pD6; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qAeV93FA 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 jFvNDtfuIKje for ; Mon, 8 Jun 2020 09:54:06 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB743A0DC5 for ; Mon, 8 Jun 2020 09:54:05 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id B6984F802BB for ; Mon, 8 Jun 2020 12:54:04 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591635244; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=x6BR/UXXZG2ng9ULvf9K4CmevCJqm3c6+fitgwY3lWQ=; b=S0pA8pD6Mr90wSjm0Mhi8zLYOQXllkZe+cql+LP7+s0WL2VmrVvvKVelMujk1epLtw+Rz h2TIfjx19ZG/oC/Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591635244; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=x6BR/UXXZG2ng9ULvf9K4CmevCJqm3c6+fitgwY3lWQ=; b=qAeV93FA0HZQMRuUi4Nr6QI01L+hyxYui4rw1iCTEYMhdMaVUKAqxS7+SGvxN5rHierlj RIfNuiQJNBUJpgMZdZKFFi/LFGPAxpVTdQyFLg9f8xvoe7ZX/1mbMGYipXdIWcxDhUeOCiq FsTWcwMZx3Ymp3bqogN4jgahvY8vY7IQwIx8yAhe5B+k97iGyiHFS6PE2wnXZxbXrHF4xLp kP/5YhlZd5o7SopkSQqxsmKu07RSmw1Axg9CIOaDkSJ+/4P6J1lnVk64aBr3Tq0FmoaGdVZ slmVIZkfzLbg48cjEs8OQdjOH9+Q8hqCwHigNKta9vHEBcYm9tVjYomVnJ4g== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 8AFCAF800A8 for ; Mon, 8 Jun 2020 12:54:04 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 08 Jun 2020 12:54:04 -0400 Message-ID: <12151352.pPdqqKU0CL@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:54:08 -0000 Conformance requirements to support contracting is not something the IETF=20 typically does. I think deferring this to a follow-on BCP is appropriate. Scott K On Monday, June 8, 2020 12:45:17 PM EDT David I wrote: > I don't know how to represent it in documents, but I do think there would= be > value in clearer terminology to help people trying to adopt (and buy > solutions). I worry that there are people saying they've 'implemented > DMARC' who are doing one of inbound filtering, or have published a policy, > but not both (I think most simply aren't aware of aggregate reporting as > being potentially a separate thing). >=20 > I think issue #41 "Potentially separate reporting and policy into differe= nt > documents" might be related as if there's a separate RFC number for sendi= ng > aggregate reports, there's a clearer line about whether or not you've > implemented it? >=20 > David > ________________________________ > From: dmarc on behalf of Seth Blank > Sent: 07 June 2020 22:23 > To: IETF DMARC WG > Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to > implement DMARC >=20 > https://trac.ietf.org/trac/dmarc/ticket/66 n.outlook.com/?url=3Dhttps%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fdmarc%2Fticket%= 2F66& > data=3D02%7C01%7Cdavid.i%40ncsc.gov.uk%7Cdea9abc7f5364bb3308308d80b2920cb= %7C14 > aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637271618558249757&sdata=3DZNzgn= rU80Q > %2F5xqAfo9Nw46I1uXqcGWPzzobISlfUQm4%3D&reserved=3D0> >=20 > Many different entities participate in DMARC, and to each, there is a > different definition of what is needed to "implement" or participate in > DMARC. >=20 > Should the spec be clear about the different participants, and what it me= ans > for each to participate partially and completely? >=20 > As a straw man to start conversation (assume this is all wrong): >=20 > The domain owner: > - partially participating: valid record? > - complete participation: no part of the domain hierarchy can be spoo= fed > by an unauthenticated sender? >=20 > The receiver/MTA: > - partially participating: validates DMARC? > - complete participation: validates DMARC and ARC, and sends aggregate > reports? >=20 > The intermediary (is this different than a receiver?): > - partially: validates DMARC? > - complete participation: validates DMARC and validates and seals ARC? >=20 >=20 > -- >=20 > Seth Blank | VP, Standards and New Technologies > e: seth@valimail.com > p: 415.273.8818 >=20 > [https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6= LS0 > Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8Ch= T2x > 5EcZV3rjz19-Dx9rESL] >=20 >=20 > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. >=20 > This information is exempt under the Freedom of Information Act 2000 (FOI= A) > and may be exempt under other UK information legislation. Refer any FOIA > queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 From nobody Mon Jun 8 10:04:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03E3A0D26 for ; Mon, 8 Jun 2020 10:04: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, FREEMAIL_FROM=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=gmail.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 HMJcmF7IgDLd for ; Mon, 8 Jun 2020 10:04:10 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 AAF643A0D21 for ; Mon, 8 Jun 2020 10:04:10 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id g5so14228525otg.6 for ; Mon, 08 Jun 2020 10:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=51w8o+9CPKzKKQBD3Y7kOUBLc2j2NAsmrJSURWKbRY4=; b=k6ByKdvqmeWUmjfsZsOLLnyZUIxdEdW8Gu3ASJFmTeaI0OaRP5RJJ/vDparGjCBx4+ xPTTn8Alqm/NgM7eC7ZUIc/vHPtNLzDDzWGqxzsJARCU+zkoP7XIZK6/a6/OFp+9/8Jh e1lepNNk5hJvVVhVS0ue4uXLAuBQUKkTowkldxdJu1sJQfssAfgpvIUDdyWWN9clxBRy rfGiNM/95LOlzrQbsDaGZVoxAIdBVEzj5fG9QE8eafxMKNDaucOUSp6iHYHBG5m8u+u/ G0b/ujcfbW6qLgu7bApzq7G1qfTQDwoO+LNH9hS4jWe2AS8E8A3EVTKzAuilF+TGYKdI hu6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=51w8o+9CPKzKKQBD3Y7kOUBLc2j2NAsmrJSURWKbRY4=; b=F51+2ok5L6SYmXxC7OTRyWb58+FraI5+Y8ICSo2dGskO9AX9Q7g5pLrZpl33ODqq9k GGUZqWJSRo3CdSJ3FuSGCsqJM7Tlc2rSeUyA06vz/3p8UlhaiIR3+w6m7+qqMB2luGR0 mFhzA30xsTJD5hl0SjolJCYuXgPspqYZqLgFJPeQd7CPuGZlSDYJXwaXsakLmKsGA0vf TYCnPNasAnoZpNa1vaYkDL96CaHp2rqIdv84KMMYaJZ02E/quMzMPGjGC8wa0TTudLLe aCr7JTRCSMPg3kUICW+q3xFOoSTzJKdu6Q4uAVu2utD8v141UaEG745rUAs9njZGFShh 2fKQ== X-Gm-Message-State: AOAM531oIkhEecLuswjnblhr+5kK98BjbUBZlGpLh3VZl4wpphp0a/q/ TuQ7IPHmh43mmQ96VrZtWbWlys3y X-Google-Smtp-Source: ABdhPJwRFJqDphZakQjXfyszrceIZzV4cHkZSTzk5l1jGrD1k5X6DeuVf9o0Q99PGpRSNJEK8bSgEA== X-Received: by 2002:a9d:104:: with SMTP id 4mr16596095otu.124.1591635849652; Mon, 08 Jun 2020 10:04:09 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:2021:7293:7b7:7a0d? ([2600:1700:a3a0:4c80:2021:7293:7b7:7a0d]) by smtp.gmail.com with ESMTPSA id q85sm1889772oic.23.2020.06.08.10.04.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 10:04:09 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <12151352.pPdqqKU0CL@sk-desktop> From: Dave Crocker Message-ID: <6e02f265-d452-9fe2-f65f-297184689d0f@gmail.com> Date: Mon, 8 Jun 2020 10:04:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <12151352.pPdqqKU0CL@sk-desktop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:04:12 -0000 On 6/8/2020 9:54 AM, Scott Kitterman wrote: > Conformance requirements to support contracting is not something the IETF > typically does. I think deferring this to a follow-on BCP is appropriate. While true, of course, there is a continuing confusion between the two sides of protocol exchanges, especially the indirect kind involving a DNS entry.  Some specification help make the distinction rather clear, such as calling one client and the other server.  DKIM distinguishes 'signing' from 'verifying'. DMARC seem to provide clear labels for making the distinction. Worse, section 8 on implementations conflates send and recieve (and doesn't even comment on the DNS record.) So public discussion might be aided by having and using some clear, consistent language, along the lines of:  1.  DMARC Owner Record  2. DMARC Report Sender  3. DMARC Report Receiver  4. ...? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 8 10:21:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24B33A0CFB for ; Mon, 8 Jun 2020 10:21:38 -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=valimail.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 uscmE1xanSEv for ; Mon, 8 Jun 2020 10:21:37 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 DFAC83A0CF4 for ; Mon, 8 Jun 2020 10:21:36 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id d128so326689wmc.1 for ; Mon, 08 Jun 2020 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/vB9mOHbR4oz6meI32JkgUWlugJiER9UDZE4UIEybP4=; b=XfJotE0twuHs2JV17ChUaItA5uuFjkNLek8Io5SLl/ZTvQ2+bOtNScsA3DexKEi2SW q7yEpbEEBSJxPi3xa2WM2XwAR7q+M64tlyXNcZ3+sWyumUOlK805beX8WXfNeX6D4x9r Io4zMxmucnsgNGa4RLz6tIX86xpau5w07RkryVQGcxDW9/JD2p9hXYjcEkaYdsRdG1Mo KnxifxBytluMX5E97frCHohJIy9+CufXPOIdhmVa1YSJd9IXWNZCFCLZR3xz+gXrBWMB 4Sj4TBz2XsIzZB7H+usirX171E81yEVtNtaUxEKdmuvV/omfeVmybKACiLhJHn71pwno PqeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/vB9mOHbR4oz6meI32JkgUWlugJiER9UDZE4UIEybP4=; b=YYDv4vqkuIPPJ6dXxGEMFK29oCrnXWLO7NtNFQhFY51bK2W2+HkrFo7ITKeIc8kPX0 ASAuWmed1/Y70gcjHBg5XfAb+YRMxmXjeonZhtWbdwMVC+BY9Z6a7hu4nvQtmPI/lKVc cAcmFslbHWO2otO4ZiyyMedPGr+lIeS5lQBkIZhwMaYVLw+dJcaJNzuK9Kj85tdvZqKa UK32tgXhruhSP1B1XEAy4DBNSXES5raJsWmvagOeROoKSZY71MPK39jgP4XOwBvO8CEw fYeCZLjMWek2d7jxbWL8VbHyzdo+1bsbR/QOCKnxyy8Zuj+SASH+Lx6mKRksy8NbNOvP CxSw== X-Gm-Message-State: AOAM531cM9dh4PSn5o34fO+LUMYjfPv/lTU3qgh2lzWCCdvuIkBuRO3c U2SZhOlMIeM+mVItUYRicbhg02eDWlnAruPY/m+1DDkDAVw= X-Google-Smtp-Source: ABdhPJwnSknL4GopynTpfnq4TRF75VlX9LUYO2JLHkLpYwBmcFGHaQj7CWQMlrlCd7Yy+8xAex34OBMYwnXt48UsfZc= X-Received: by 2002:a7b:c5d5:: with SMTP id n21mr369950wmk.106.1591636894914; Mon, 08 Jun 2020 10:21:34 -0700 (PDT) MIME-Version: 1.0 References: <12151352.pPdqqKU0CL@sk-desktop> <6e02f265-d452-9fe2-f65f-297184689d0f@gmail.com> In-Reply-To: <6e02f265-d452-9fe2-f65f-297184689d0f@gmail.com> From: Seth Blank Date: Mon, 8 Jun 2020 10:21:24 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bbb2dd05a795d7f7" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:21:39 -0000 --000000000000bbb2dd05a795d7f7 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 8, 2020 at 10:04 AM Dave Crocker wrote: > On 6/8/2020 9:54 AM, Scott Kitterman wrote: > > Conformance requirements to support contracting is not something the IETF > > typically does. I think deferring this to a follow-on BCP is > appropriate. > > > While true, of course, there is a continuing confusion between the two > sides of protocol exchanges, especially the indirect kind involving a > DNS entry. Some specification help make the distinction rather clear, > such as calling one client and the other server. DKIM distinguishes > 'signing' from 'verifying'. > > DMARC seem to provide clear labels for making the distinction. Worse, > section 8 on implementations conflates send and recieve (and doesn't > even comment on the DNS record.) > > So public discussion might be aided by having and using some clear, > consistent language, along the lines of: > > 1. DMARC Owner Record > > 2. DMARC Report Sender > > 3. DMARC Report Receiver > > 4. ...? > As Chair, what I'm hearing is that this is a real issue, and may need clarification in a BCP, not the primary document. That said, without having at least part of this conversation now (like the specificity in actors Dave has mentioned above), I don't see how we'll end up with a standards track document that is clear and has the appropriate normative language. Seth -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000bbb2dd05a795d7f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 6/8/2020 9:54 AM, Scott Kitterman wrote:
> Conformance requirements to support contracting is not something the I= ETF
> typically does.=C2=A0 I think deferring this to a follow-on BCP is app= ropriate.


While true, of course, there is a continuing confusion between the two
sides of protocol exchanges, especially the indirect kind involving a
DNS entry.=C2=A0 Some specification help make the distinction rather clear,=
such as calling one client and the other server.=C2=A0 DKIM distinguishes <= br> 'signing' from 'verifying'.

DMARC seem to provide clear labels for making the distinction. Worse,
section 8 on implementations conflates send and recieve (and doesn't even comment on the DNS record.)

So public discussion might be aided by having and using some clear,
consistent language, along the lines of:

=C2=A0=C2=A01.=C2=A0 DMARC Owner Record

=C2=A0=C2=A02. DMARC Report Sender

=C2=A0=C2=A03. DMARC Report Receiver

=C2=A0=C2=A04. ...?


As C= hair, what I'm hearing is that this is a real issue, and may need=C2=A0= clarification in a BCP, not the primary document.

That said, = without having at least part of this conversation now (like the specificity= in actors Dave has mentioned above), I don't see how we'll end up = with a standards track document that is clear and has the appropriate norma= tive language.

Seth

<= br>
--

Seth Blank | VP, Standards and New Technologies
p: 415.273.8818 =



This email and all data transmitted with it c= ontains confidential and/or proprietary information intended solely for the= use of individual(s) authorized to receive it. If you are not an intended = and authorized recipient you are hereby notified of any use, disclosure, co= pying or distribution of the information included in this transmission is p= rohibited and may be unlawful. Please immediately notify the sender by repl= ying to this email and then delete it from your system.

--000000000000bbb2dd05a795d7f7-- From nobody Mon Jun 8 10:24:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688653A0DC9 for ; Mon, 8 Jun 2020 10:24:27 -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, FREEMAIL_FROM=0.001, 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=gmail.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 gFLpv6Xj4L_R for ; Mon, 8 Jun 2020 10:24:25 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 8CF7E3A0E1B for ; Mon, 8 Jun 2020 10:24:25 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id d67so16032239oig.6 for ; Mon, 08 Jun 2020 10:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=kMqZ6wAri9A6Pu7/vZGwFVPNNx5tClUYkNSUwL/Jli4=; b=FhQJwEK5orWfSJOPsBer3Z9li8fz7JOE3NO6lXnuaS86qc+4daLjoNUsGUcdX/F/y7 sq+MeX/P3ouFUiX12TY+AGCuHsVNpRLas9KEcZ8BPfpEIkHeXMtQWaonWWLyAm1BJOCB HBZ6pnadAxpql1xAG3gTGMk/0pc2uS9RhQWuCDkgA2vJv9nMrpN1GttkmoQAA+EiOovJ +8w+bgprD2IKQzwQM5hUbIhyIRruw0DQT4wzKbvtS5j+GpICItAMXS4LD2I/t1r3KtLd Rw84BSgJJs1YCuB8sfwMV0HI2U5SRlqtG44Gv1fvKyyh1/7bbY1FQo42WY0MVJBhyu+h Maaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kMqZ6wAri9A6Pu7/vZGwFVPNNx5tClUYkNSUwL/Jli4=; b=LEx/hzdyLQ1r/Tr7ndPK6gK1SMSLrFZ4IuiJGBX//zHSYkgdHSImr6EleLbLr4achD /mQblrmG9aimtzJ9ddwP6AD+LAqUO8E8p4zOQ1Ecb8K24azfwD2CB2fTlU41dBgT5uUh 1Af1RbiaLoZax3z/jQQL+VcdvrkiFEvouMZ2904Pi2Lg8sYiDM3CtAAmIiDc/c/ZlLgr asrN4Z+Iz6hKoGoKxoJ1FxCGkOlRXGYZcMeY9k8hU10bIesNX9nYrliQ96kfur/duO4W pc8oXLQ3LLHU7xgw6qYmgHIv4hnt8sW4VvX79KbMdyyBP/E7D0Q7egeTlDZec2gBMnBa 3Cxg== X-Gm-Message-State: AOAM532SqOzn9O4MlCB0UOFDYbux9Tj8V2AcpNYJj9PRiz8UIgpPtgLu gK+Nd6H5NiG5KzfUp8b2wRKx0fyj X-Google-Smtp-Source: ABdhPJxdY7aheLmBhKcLB0X/vr+1WT9xVbZodMcsSBomAz4SDTzA4/odx5bJgYE9CW62Q0W4l6z/3g== X-Received: by 2002:aca:6008:: with SMTP id u8mr365050oib.58.1591637063977; Mon, 08 Jun 2020 10:24:23 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:2021:7293:7b7:7a0d? ([2600:1700:a3a0:4c80:2021:7293:7b7:7a0d]) by smtp.gmail.com with ESMTPSA id x191sm2535621oix.35.2020.06.08.10.24.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 10:24:23 -0700 (PDT) To: Seth Blank , IETF DMARC WG References: <12151352.pPdqqKU0CL@sk-desktop> <6e02f265-d452-9fe2-f65f-297184689d0f@gmail.com> From: Dave Crocker Message-ID: Date: Mon, 8 Jun 2020 10:24:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:24:34 -0000 On 6/8/2020 10:21 AM, Seth Blank wrote: > As Chair, what I'm hearing is that this is a real issue, and may > need clarification in a BCP, not the primary document. Assuming the base DMARC document is modified, I'd strongly suggest making these terminology distinctions in that document. Especially since it already has a section discussing 'implementation'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 8 10:49:42 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9398C3A0EC9 for ; Mon, 8 Jun 2020 10:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=lLmd87Oz; dkim=pass (2048-bit key) header.d=kitterman.com header.b=W76ec2se 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 RCsFuM3j3bRz for ; Mon, 8 Jun 2020 10:49:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110513A0ECD for ; Mon, 8 Jun 2020 10:49:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 37A4EF802BB for ; Mon, 8 Jun 2020 13:49:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591638576; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=l6RVy410/zuJv3kHADWuRV4eG8E8/laxgTdCE6+FU1g=; b=lLmd87OzZkBeeqILcIQLDR5ZmHm6iXC4nkdtvRGzAtCwuuj7d7/qCP/b2fkQgu4S/Hse6 IslRk2R6NxujMgLCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591638576; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=l6RVy410/zuJv3kHADWuRV4eG8E8/laxgTdCE6+FU1g=; b=W76ec2seWaTVEj2vv9EZOvuzpS4xx8p4pFhNOoxWcTYEv0SaiGMJz2JB6mDSSMsnTo3yA u7kmJoSvXGMy6hrn8EjnDqTHV24/mZXEtOKfcVLnIdhlhgc5XC6oDBQZgU4M5nGspb73moy A7d7os2TtbGVzzTVNTYCW30jnkcg5CU3rk+ZcWbT4elmg/rS5SJWkWnl2G9LY1S+chYtVHL uk4ZcEY1opSKyFoHEv96SE2PZeMTfSlE+rE7ob1P9b2g0l8aQA4nH77YXLdD4AwO94vaPpH M6NEQb7QMrp6unswrZ9cROEz68RVBXBpN5Vf2tstBO1/8L0WWEPyHNSghZIg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 039E9F800A8 for ; Mon, 8 Jun 2020 13:49:35 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 08 Jun 2020 13:49:35 -0400 Message-ID: <3507276.ukgILIsGJ5@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:49:41 -0000 On Monday, June 8, 2020 1:24:21 PM EDT Dave Crocker wrote: > On 6/8/2020 10:21 AM, Seth Blank wrote: > > As Chair, what I'm hearing is that this is a real issue, and may > > need clarification in a BCP, not the primary document. > > Assuming the base DMARC document is modified, I'd strongly suggest > making these terminology distinctions in that document. Especially since > it already has a section discussing 'implementation'. I think your point that the terminology needs improvement is valid, but I don't think it's this issue specifically. I think it would make this issue easier to solve in an eventual BCP, but I think it stands on it's own as something we should look into for this document, not just a future one. Scott K From nobody Mon Jun 8 10:54:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E049B3A0DF9 for ; Mon, 8 Jun 2020 10:54:56 -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, FREEMAIL_FROM=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=gmail.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 oWt8J_c1yH03 for ; Mon, 8 Jun 2020 10:54:55 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 DCF683A0DD4 for ; Mon, 8 Jun 2020 10:54:55 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id b8so16159161oic.1 for ; Mon, 08 Jun 2020 10:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KW/4GQNXUZoExIqArFEdKB40yhF3YJRRmhCPhzt0o2Y=; b=aD3iJR/DC0e01uJQPyEtzf90/QfUI80m9QbGSsKM9OdlTGUO2RaUn9sRtS6TuJzexx Dzvmz19FGJCWFdPOWUO1licXjmtC2soSHA6BMrdQcyeU/TcW9/fU5wfIODaYRCW+ImKF HdtR6MMfhtjG4kXSU7vaDETGykYljp+MCCFHzHOLjNoYpFIvlfX73gZbi4j/CIe/XagB eSJ7zkdNiEExfeFvDM+vIawiOcjLhZdL4m1kZoCB45+VPtOpcvazCpS0sKjDDjBl+RHZ +rT7IoTJMf1I9u5h8S2Zfu7DTOMUIkvy3+qpvHNlJJ7HS1cT/yR5owzLVXUfwkcSI1IC O+9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KW/4GQNXUZoExIqArFEdKB40yhF3YJRRmhCPhzt0o2Y=; b=fVQmrk3Dp4W1X8mJTdCZoOEEa/+30cwO6RU1/J3ABAY9qaX8GQM/8ls+kDR3JY0pnJ JUCxi/w0fbku5Wsb4ta6p7tBDjYjUYwab616N02qUFiALsca9RFE+C9XWfr6OZLg4Fiq x5vWJkBsfMhGonnHl9Wdsdf0k2side3mZojkiTHHOMMaZQZYlkMv08IkaAJZ2OSsCwWd U56RGPr712MY09L5xy84Zz4IXsruYZkp2numfj7IN5KncpT+Gd1ys65CWwLJwND2pu7i JuvcEdluegRdszRIzmvOdWuiy9jysD++qrKu+qlk7n+n9RsuDG6JDh0sClF1gR+VigLH PEfQ== X-Gm-Message-State: AOAM530gWTGGdeHL0lk8/ZTxcfiXV62+lp9sLFKkmPjCyBl3lpO2utpf N+VLhw8e3tMpW/xi40zarFJKmUpd X-Google-Smtp-Source: ABdhPJxv6mhlpj0uYfUGk/TfDD+T2+VpGiz4jEAJKp5UhaSGA2Y4+dY10quBR+oXZnyP/hQ5GR2BIg== X-Received: by 2002:aca:4e0d:: with SMTP id c13mr439222oib.30.1591638889325; Mon, 08 Jun 2020 10:54:49 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:2021:7293:7b7:7a0d? ([2600:1700:a3a0:4c80:2021:7293:7b7:7a0d]) by smtp.gmail.com with ESMTPSA id d3sm1660599otb.18.2020.06.08.10.54.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 10:54:48 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <3507276.ukgILIsGJ5@sk-desktop> From: Dave Crocker Message-ID: Date: Mon, 8 Jun 2020 10:54:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3507276.ukgILIsGJ5@sk-desktop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:54:57 -0000 On 6/8/2020 10:49 AM, Scott Kitterman wrote: > I think your point that the terminology needs improvement is valid, but I > don't think it's this issue specifically. I think it would make this issue > easier to solve in an eventual BCP, but I think it stands on it's own as > something we should look into for this document, not just a future one. Separating basic terminology from basic technical specification doesn't make much sense to me. Terminology and its use is established in the specification of architecture, format, and protocol, not some possible, later document about operational issues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 8 11:18:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4C13A0DB8 for ; Mon, 8 Jun 2020 11:18:55 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=m5feiQTR; dkim=pass (2048-bit key) header.d=kitterman.com header.b=PKv9QOgW 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 hRdHw5LCXILT for ; Mon, 8 Jun 2020 11:18:54 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A583A00D2 for ; Mon, 8 Jun 2020 11:18:54 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 37A82F802BB; Mon, 8 Jun 2020 14:18:53 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591640333; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ZGt35dnnkeM8h1hnT1869WAFkD8VBNsNKu5/61lQAPc=; b=m5feiQTRqbgld/QV/hzsRm6iLAjZ0Cg4isZLKCNreCpfj4+uwcO6U1vrK9Cge28UeDjSN bn8UHXvzP5+6gIaCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591640333; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ZGt35dnnkeM8h1hnT1869WAFkD8VBNsNKu5/61lQAPc=; b=PKv9QOgW7hmwnA2afVeieHeOypcp1ki3y4Ucpo/nwIjXSjviqu9bCWS1I2FrpgWGBrWF5 g7ICnbMSYWLdRvDb7dAsSviZKtqG0o7MFVTs74W+uLiuYJOSpeokI7K6EpQ5g3zoRvchZZd lfed0skKuOMw+z7RaQ8+f4I/XIpyCIw1IwOV4qbT3J2dAS+Z7mbaRYINlACujb4lZSo5Hcu m07MzGm1iaJ9gqgGn1DBv0lKlTzC7By9du1AdUVy9X7ckgmfFiK/Cz58LDXOY4MEPaupeps dmSbtMrDlqodQoLAuDl3mxlcZSUpPcT+JhNs9S80nZs13WMLJjkH4Y/2O0hw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id DAB23F800A8; Mon, 8 Jun 2020 14:18:52 -0400 (EDT) Date: Mon, 08 Jun 2020 18:18:51 +0000 In-Reply-To: References: <3507276.ukgILIsGJ5@sk-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 18:18:55 -0000 On June 8, 2020 5:54:47 PM UTC, Dave Crocker wrote: >On 6/8/2020 10:49 AM, Scott Kitterman wrote: >> I think your point that the terminology needs improvement is valid, >but I >> don't think it's this issue specifically=2E I think it would make this >issue >> easier to solve in an eventual BCP, but I think it stands on it's own >as >> something we should look into for this document, not just a future >one=2E > > >Separating basic terminology from basic technical specification doesn't > >make much sense to me=2E > >Terminology and its use is established in the specification of=20 >architecture, format, and protocol, not some possible, later document=20 >about operational issues=2E Sorry if I wasn't clear=2E I was trying to suggest that the topic of this ticket (defining conformanc= e requirements) should wait for a BCP and that as a separate topic the term= inology should be fixed in the DMARC bis effort=2E I think we agree=2E Scott K From nobody Mon Jun 8 11:41:48 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E135B3A0F04 for ; Mon, 8 Jun 2020 11:41: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, FREEMAIL_FROM=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=gmail.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 zStCeoL8rsBx for ; Mon, 8 Jun 2020 11:41:36 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 8DBD83A0836 for ; Mon, 8 Jun 2020 11:41:19 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id n70so2037506ota.5 for ; Mon, 08 Jun 2020 11:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YGJeT7kwmfMjOZU/OxrNgdw2RZgWNeD9m+SLdvrG9yA=; b=kVpYmAQF9hWqxYGBX2PlBKDygOY0wvPzGQKD4YJWBx7dPkOxoJU2Rma0BOidEkP+6u p0ckL8qZtqPkVLPB0Qt60Idcg1PeHBRcsR2+54etwuv+VcavAK1+brLa4t69FUqvbJdp +MYdlD4zH0AshZzPGPb7MQXSH32Ezms4nu+v18qA7TT7+VwUZpVw91UxmFJ9vRhhW3SX 6P8/D+tLS3/2q1AkX7ltHy+TXlm08xgZbU5E/XNQV0LmobsHrUzlVLJBkw2Hl0KDWD54 I+KVeWhqOK0ZXQXd+QPIQEizlyFN3GU6gVY1XW7+66wrZfG3Vp/w2NUYGT4x1+Af0WEz fHtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YGJeT7kwmfMjOZU/OxrNgdw2RZgWNeD9m+SLdvrG9yA=; b=b885gHV8McVHd7uBENc+3T67kHhO4RQkGxtFwzdXx9HEboMZ7+bQYgfjiVjuHFR5FU DvJTGvqfk4Gi23KsvxBcjdOAX60v4bVn11a2fvYAL4TmBT2+Twm2uq9xbPK18yXlDQg6 J0lTrxhO3DgO55U9Ye0o+exYAzBJKu4c55XvYZxlwo3/s4CtQFhCBVJ4nnf4UDVahr1d 0HT2SQhXcPa+Zz5AaLrrxsORFqeihSnitr/JrLSqpmSU0Ha0xSAjj2MZ5sqQcRLAObZ0 GGlS4kzfFemW/iIf44CnMkfLoAdF7mObb6zQ/EE5t22C2wfIFEPFD1b9lP1TeSsSqExo lpMg== X-Gm-Message-State: AOAM533MVkePJnDvUTROeOHiNAz6jyTCidgXy6UTCGx50gdzinHKTkam nlfftC7kkituA4FmlTNpjNwpezlk X-Google-Smtp-Source: ABdhPJyu90gdYrErtH1HTuUsaEC5sIo2Bmf84ArL0OFewHSzJ9nksBIAOWo0Bpxoaj/1xKldVlzcLg== X-Received: by 2002:a9d:6a87:: with SMTP id l7mr18253715otq.265.1591641678581; Mon, 08 Jun 2020 11:41:18 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:2021:7293:7b7:7a0d? ([2600:1700:a3a0:4c80:2021:7293:7b7:7a0d]) by smtp.gmail.com with ESMTPSA id k14sm2433659oof.48.2020.06.08.11.41.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 11:41:17 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <3507276.ukgILIsGJ5@sk-desktop> From: Dave Crocker Message-ID: <3d6f24c7-113d-a096-305e-1490c920c8e4@gmail.com> Date: Mon, 8 Jun 2020 11:41:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 18:41:44 -0000 On 6/8/2020 11:18 AM, Scott Kitterman wrote: > I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP and that as a separate topic the terminology should be fixed in the DMARC bis effort. > > I think we agree. ahh.  yes.  conformance is indeed quite separate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 8 11:53:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820043A0ED3 for ; Mon, 8 Jun 2020 11:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dmDsPcA0; dkim=pass (1536-bit key) header.d=taugh.com header.b=tBcTYZpX 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 IUYP3YBvL5Yk for ; Mon, 8 Jun 2020 11:53:37 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D48F23A0CAA for ; Mon, 8 Jun 2020 11:53:36 -0700 (PDT) Received: (qmail 47715 invoked from network); 8 Jun 2020 18:53:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ba61.5ede892f.k2006; bh=w+pU3/y4F+KlDn+2i02TaE1Cd/LWa6ixPkgRbCTOGf4=; b=dmDsPcA0Xv02QqwIK+TXdzixkoYovl8P9Fcd1BlClk1Zb8mijwxKQCXjBWxJT29dgCQapcb9hPfFavWzDDDB0GspQCzlLEZiVT9rqBRYxuwkGc86EZYlNeSQF+YahU+sZFZXTVc9HkGyaYQcZCcII2fv4nLSOkcYkkVCz7xvrNDsAu2n/Y52StjKseeevRgLNoyjuuvZyFm7u40DwdcQdmmWVxLMkrVn/PW7gKKxeDHWgpoIsgiwxgapfdf7Edt7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ba61.5ede892f.k2006; bh=w+pU3/y4F+KlDn+2i02TaE1Cd/LWa6ixPkgRbCTOGf4=; b=tBcTYZpXrHnUBDlCkmmYeZP4jG3/xlJ/7u0rvK3j1vh4Qh98vG3luzdPxfH4NHMF/rM0ijQKkkkPXZXYHdXT/Vc0UIXo74L3fHEfKaR98sr9Ku9rrXggRQqOP7A2gijn1+WV6es/P36l3LIqR36c4NiR171YsdqLd+Y0YkysVJKzfJSSQjBM7PjlWaqfGRuPxHjUpmyIeo9LJ6eOvYquvJ+YZp4kEWNbXmOFQaXxd9LloDCJzgGW448Dk8Fgi471 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Jun 2020 18:53:35 -0000 Received: by ary.qy (Postfix, from userid 501) id 1AF571A4DCB9; Mon, 8 Jun 2020 14:53:35 -0400 (EDT) Date: 8 Jun 2020 14:53:35 -0400 Message-Id: <20200608185335.1AF571A4DCB9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: <3d6f24c7-113d-a096-305e-1490c920c8e4@gmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 18:53:40 -0000 In article <3d6f24c7-113d-a096-305e-1490c920c8e4@gmail.com> you write: >On 6/8/2020 11:18 AM, Scott Kitterman wrote: >> I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP >and that as a separate topic the terminology should be fixed in the DMARC bis effort. >> >> I think we agree. > >ahh.  yes.  conformance is indeed quite separate. Agreed. Quick, let's declare victory and move on to the next ticket. R's, John From nobody Mon Jun 8 14:17:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69EF3A00B3 for ; Mon, 8 Jun 2020 14:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=LQoIQS1G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eXdl+7PQ 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 vLKQOR4Zq_1p for ; Mon, 8 Jun 2020 14:17:34 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879483A00C4 for ; Mon, 8 Jun 2020 14:17:34 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DA0E45C00EB for ; Mon, 8 Jun 2020 17:17:33 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Mon, 08 Jun 2020 17:17:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=9pbahZ21xwLzkmNfd0mdQGh6UUIVFtP 8T3sAtGMC/8k=; b=LQoIQS1Gqw48tdPnqzZrnJayDpfnh9oqFBRJPesv8mMZCmE NbStt6CauzqSE38MaQ62JV7tcGI/GJmmL0w9Fpjkso+Jd6IpfGDyjxEf44gh3r/j tYo0Rxq1ZyQzbLP+O+MHep1Xd15/AXf17vPSPGD3Dw3dB4EvxHA5I/3HWTgj9M2/ /WS0xRGWtF1gpzegLf1rOKxuKyyy6TkjFIK0+JGQiXHMbYAewZc5M63dA6q2XF+4 ZoWZxeZXSUEIoTG/mirt2sh0GdGUwP4Wk8rIdAXNDIvIwn9deSz1CLwSOz2aPVzh 0gfqehRttKBNq+XbZzbnVQzL7sNFP5+jhLBNG1g== 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=fm3; bh=9pbahZ 21xwLzkmNfd0mdQGh6UUIVFtP8T3sAtGMC/8k=; b=eXdl+7PQyEkE1e9vJAToUw 9MEs3ZagaN7++Uk2pfiohk7LN5e0UKrAMLOr3Qz5T//OcM9QXCJOMs6rh8/h6QrZ BVckKagPviuI751Dsub/+XK6iOKdAzfQDhFpSlC+/e4B7g+UwKioMdyOrOMt3aQ9 2x81/iBZJxEpTDsww9+6lxSYi/Y9jXWz+c5zBaAAZI/E4miOHb0rY4wVd5KC9PgU kh/C49P5mhwd13A0ZScjX8tNBjLZI7xKpiju59H31CGY0pHUyZXeJ0AW+2w0dC/i XROf8XJ8dHH0M/7u55tZB/Hd+oOWCXnz+RUFCYuZRFunoiQBEpGL6jPmIR6UKwaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehvddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucggtffrrghtthgvrhhnpeeuie egleevvdegtdefhfffhfekhedtuedvueeikeduueevfeetffelgeehhffhvdenucffohhm rghinhepuhhsrggslhgvshgvtghurhhithihrdhorhhgpdhivghtfhdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 808851400A7; Mon, 8 Jun 2020 17:17:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <03782197-b1b7-4218-9382-a92259bec048@www.fastmail.com> In-Reply-To: <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> References: <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> <33b12416-cd41-4826-9950-3afc9fdb83bf@www.fastmail.com> <3eb519fc08214b4bb23ed00737cdc0db@bayviewphysicians.com> Date: Mon, 08 Jun 2020 17:17:08 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=812ae218b7d540d7b66536f0a0aa78a3 Archived-At: Subject: Re: [dmarc-ietf] About user notification in the MUA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 21:17:37 -0000 --812ae218b7d540d7b66536f0a0aa78a3 Content-Type: text/plain On Mon, Jun 8, 2020, at 2:03 AM, Douglas E. Foster wrote: > Stan Kalisch asks: And you propose the average user can understand, much less take the time to understand, the substance? > > Yes. I believe users are worried about spam, and want to make intelligent decisions about whether or not email can be trusted. Unfortunately, our present software denies them access to the available information needed to make intelligent decisions. See, I believe they want to, too, but, anecdotally, I can think of a number of intelligent people I can't explain DMARC to in a substantive manner in a short period of time. And the research bears these kinds of anecdotes out. What I've tried to establish here is that you really have to take the initiative if you want to come up with a system that can present the kind of data you want presented to the users. You're missing the point that a number of people with a great deal of experience have tried, and think it's either impossible or very unlikely. So simply asking the community to come up with a solution won't be enough, because the community has labored to find a solution for a very long time. A good place for you to begin would probably be this paper: http://www.usablesecurity.org/emperor/ Stan > > Dave Crocker observes: There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful. > > I was not talking about the sender. I was talking entirely about the receiving organization: its spam filter communicating to its MUA to communicate information to the end user based on its local policy. > > Dave Crocker also observes about end-user signaling failures: It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years and none has demonstrated efficacy. > > Then lets restate that assertion in all its ugly elitism, and put it into an RFC: > > Incontrovertible research shows that humans will always act on malicious email, and cannot be taught to do otherwise. Organizations should deploy email if and only if they have automated tools which provide perfect protection from unwanted email. End user training is useless. > > I have a higher opinion about my users than that. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --812ae218b7d540d7b66536f0a0aa78a3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Jun 8, 2020, at 2:03 AM, Douglas E. Foster wr= ote:
Stan Kalisch asks:  And yo= u propose the average user can understand, much less take the time to un= derstand, the substance?

Yes.   I believe users are worried about spam, and want t= o make intelligent decisions about whether or not email can be trusted. =  Unfortunately, our present software denies them access to the avai= lable information needed to make intelligent decisions.
<= /blockquote>

See, I believe they want to, too, but, anecdotally, I = can think of a number of intelligent people I can't explain DMARC to in = a substantive manner in a short period of time.  And the research b= ears these kinds of anecdotes out.

What I've tried to est= ablish here is that you really have to take the initiative if you want t= o come up with a system that can present the kind of data you want prese= nted to the users.  You're missing the point that a number of peopl= e with a great deal of experience have tried, and think it's either impo= ssible or very unlikely.  So simply asking the community to come up= with a solution won't be enough, because the community has labored to f= ind a solution for a very long time.

A good place for you= to begin would probably be this paper:


Stan

=

Dave Crocker observes:=       There is no basis for believing that requests abou= t MUA display will achieve meaningful support on the receive side, never= mind whether they would be at all useful. 

=
I was not talking about the sender. &nb= sp; I was talking entirely about the receiving organization:   &nbs= p;its spam filter communicating to its MUA to communicate information to= the end user based on its local policy.

Da= ve Crocker also observes about end-user signaling failures:    = ;   It's not that it 'seems to be'. It isn't nearly that soft. &nbs= p;It is that there have been multiple efforts over the years and none ha= s demonstrated efficacy.

    Then= lets restate that assertion in all its ugly elitism, and put it into an= RFC:
   
Incontrovertible research shows that humans will always act on malic= ious email, and cannot be taught to do otherwise.   Organizations s= hould deploy email if and only if they have automated tools which provid= e perfect protection from unwanted email.     End user trainin= g is useless.

I= have a higher opinion about my users than that.

_______________________________________________
dmarc mailing list
<= div>

<= /body> --812ae218b7d540d7b66536f0a0aa78a3-- From jasper@pointless.net Tue Jun 9 15:22:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE013A0798 for ; Tue, 9 Jun 2020 15:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pointless.net 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 PS0kaLM5M2Vm for ; Tue, 9 Jun 2020 15:22:12 -0700 (PDT) Received: from thingy.pointless.net (monstrosity.pointless.net [IPv6:2001:470:1f09:1caf::1]) (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 4B5E53A0794 for ; Tue, 9 Jun 2020 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pointless.net; s=main; h=Content-Type:MIME-Version:Message-ID:Subject:To: From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zx4C93/3XZcXhOHsk+7jsFB22weNPiXled1MQpZNy+A=; b=TURhl0Dm8l6JWpOQI7K1rxCa7u 62LdFssaQjR0H7inr7dHwuPB/RDzAKPDxFkD4GO9awE9+gvcXRHsQ2aONaHpf93MJESt+2vPwAGGL W0kf5ZTIuxYk36IP/YurkWTfGRwmvY2KRfq2m/KNqzllCZX7CCMWsh3eN5rs6ksyh14I=; Received: from 3.8.a.f.7.5.1.a.0.2.0.d.8.a.5.c.8.7.2.4.6.6.b.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:b66:4278:c5a8:d020:a157:fa83]:56926) by thingy.pointless.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jimdE-0005S1-Tl for dmarc@ietf.org; Tue, 09 Jun 2020 23:22:09 +0100 Date: Tue, 9 Jun 2020 23:22:08 +0100 (BST) From: Jasper Wallace To: dmarc@ietf.org Message-ID: X-OpenPGP-Key-ID: 0x416333590FC0E569 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] DMARC Feedback report test emails? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 22:28:47 -0000 Hi, I'm doing some work on updating and maintaining a python package for getting info from dmarc reports. At the moment I'm adding more test cases. I can find (and I get sent!) loads of aggregate reports, but I've not found any feedback reports. I can find many ARF reports on github, but none of them seem to be a complete DMARC feedback report - e.g. missing the Identity-Alignment field, even when Feedback-Type == auth-failure and Auth-Failure == dmarc So does anyone have any that the are willing to share? They will end up on github so please remove any PPI or anything confidential from them. Thanks, Jasper -- [http://pointless.net/] [0x416333590FC0E569] From nobody Tue Jun 9 17:14:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E93A0D05 for ; Tue, 9 Jun 2020 17:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=vVlloQlP; dkim=pass (1536-bit key) header.d=taugh.com header.b=KcvgtPpY 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 5vlHu7nGn0is for ; Tue, 9 Jun 2020 17:14:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D25303A0CF4 for ; Tue, 9 Jun 2020 17:14:12 -0700 (PDT) Received: (qmail 72136 invoked from network); 10 Jun 2020 00:14:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=119c4.5ee025d3.k2006; bh=ErtimtgVIkwmcr+zAf7MsJ1wdC+TP63TK9MawIBQXJY=; b=vVlloQlPgnNhEFthnCU3wT2D1ZtI7Zd0Jetk4iGpDExa6/whkYKraAoIjUVpSZGvdHxXFV4vLddEMMILd8Ig4ZBFGh9ezBXlmz5+Qy0haCFkyOTaHseO0xolFrvoLL7CaoI0ajEXiUM8X+YhFWa82T1a+jC08mW0e9lspVRMFunRL8jMWxIdyqs0wyGmT+ibPSBiXE4B1+pMZsDpEBle2j2A41tX1kBzRvaG3qf/0/nl2ktlJO7/st+xAkPGjWDA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=119c4.5ee025d3.k2006; bh=ErtimtgVIkwmcr+zAf7MsJ1wdC+TP63TK9MawIBQXJY=; b=KcvgtPpYafvYtABsNwt1FtOvgdQBw9EKQDusfQDfpQbaOr29+Jq83Yv2U/9lD+KM+KFyg1C+ytVXiUAxaI1Rlpf6jqxtbEJNyLmGnmNB83bJwEuC0YV39w0OqSEfpy81mb6eOShWNgCqQ85IGa9JOKTCqaf9G7GPYv3GhJk7p/F5T2UOimo8ZeADm5hNhupjVrz9l3jU2X00jmsLd6VlAXZOoxQSexHYsLi2JprucrfqSyKu/aDHLKzYyySPeMmU Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Jun 2020 00:14:11 -0000 Received: by ary.qy (Postfix, from userid 501) id 34B981A5809F; Tue, 9 Jun 2020 20:14:11 -0400 (EDT) Date: 9 Jun 2020 20:14:11 -0400 Message-Id: <20200610001411.34B981A5809F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jasper@pointless.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC Feedback report test emails? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 00:14:21 -0000 In article you write: >So does anyone have any that the are willing to share? They will end up on >github so please remove any PPI or anything confidential from them. I have 80,000 of them but most of them are copies of actual messages people sent to mailing lists, so no such luck. Publish a DMARC record with a "ruf" clause and you'll get a trickle pretty soon. Linkedin sends a lot of them, utterly unredacted. From nobody Thu Jun 11 11:28:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87E3A0C0A for ; Thu, 11 Jun 2020 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=crash.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 AR-ma1dOua3q for ; Thu, 11 Jun 2020 11:28:24 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 796313A082A for ; Thu, 11 Jun 2020 11:28:24 -0700 (PDT) Received: from [10.10.10.124] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 05BISDca031748 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 11 Jun 2020 18:28:22 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 05BISDca031748 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1591900102; bh=t+0D+nXvUWlCGk9Kc8ChyfMjF338cPtFdOz+MW6JGG8=; h=To:From:Subject:Date; b=i0NrXkl5ac6VN6vMdiYOjZLvmULcN2SPkoANegpB0czSvrW4Tlpfru0sm/uxQIR9k 0S59g3BsLrH9CQbJBiX7PMOwa76NxfY/Hf5R+Gq4wy5Fhv2N/D3P6PRZ4rKV4hbL/e RJXSsfga3ApYTnJjdcHEidNrHNKBbw1Ufjq/vADpMIjnmYrpuqx0RflhmvFOPUSLhn KF/L+ZIzt3YOQkn5uRmqHhaSJ9p6P0cCOuKqOUhGV/ugGPuh+PdgE6RRI2hS73S/eG O5K/gZxuJ2PwhpMTiZ1hjfgvyupJuG51DapZa425SEWruDgRDggAn+cYvkN8x7ImYS xIP7WCgzbhvZQ== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.124] To: "dmarc@ietf.org" From: Steven M Jones Organization: Crash Computing Message-ID: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> Date: Thu, 11 Jun 2020 11:28:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Thu, 11 Jun 2020 18:28:22 +0000 (UTC) Archived-At: Subject: [dmarc-ietf] More redacted RUF reports better than no RUF reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 18:28:26 -0000 In the WG Interim Session, I had given a "+1" to Autumn Tyr-Salvia's comment about redacted failure reports being better than no failure reports. I also suggested that perhaps potential failure report generators would be encouraged if they could see examples of reports with different levels of redaction. This would be as opposed to only seeing "reports SHOULD include as much of the message and message header as is reasonable" in RFC7489 section 7.3, and deciding to avoid a potential headache. Whether these examples would best be delivered through the DMARCbis appendix, the DMARC Usage draft (currently "parked"), or an effort more aligned with the ARF family of specs, I am not sure. If there's a desire to see this, I'm willing to try to put something together. --S. From nobody Thu Jun 11 17:22:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AC3A0CA5 for ; Thu, 11 Jun 2020 17:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=VF+P6orh; dkim=pass (2048-bit key) header.d=kitterman.com header.b=JRj1BmPi 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 eh29cyH15rGc for ; Thu, 11 Jun 2020 17:22:18 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348383A0CA1 for ; Thu, 11 Jun 2020 17:22:18 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 23580F8028D; Thu, 11 Jun 2020 20:22:17 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591921336; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=CVEiVqmimnMcbER+ojMUdj0GWWgtO4IPHL1x/mimOVs=; b=VF+P6orhTmBfKe3+lvyD4GkxAR1G2lOxpEMmBhshPnx2yhwUvZZFFSEfZNqFEX25N2tn/ 2hblD5EhYNDeLYoCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591921336; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=CVEiVqmimnMcbER+ojMUdj0GWWgtO4IPHL1x/mimOVs=; b=JRj1BmPipeNYzKq7pApQIk0yhRmedo/ZD/sBtCxIv1n6CTJHnC9OzPq78yoxIqonucv1N slsQLmbe7aGf5dp+v1dw+TjU4v70ZqMRtgJwIWVyJ2YXPTid78f3VPpIbQ8jCW2BfaAp9w5 w0gaPYCSVC3yIx8D95/9AsTzQroY8KYpETJbbYHwQl63omW77/ib8WMUxByMKoSpEfXMu96 J+Dapng5Q0lvWu63XHh5E+coHjlVY8PYgIatIqi/oL909cceRxj9/iUkGBnNjnzuw+ah330 mE/4tCffYjt51zsQKGw4Os0Hxxt6WDbflElsU2SHYxyyocil1/PjbXBJieDg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id A60C3F8021A; Thu, 11 Jun 2020 20:22:16 -0400 (EDT) Date: Fri, 12 Jun 2020 00:22:15 +0000 In-Reply-To: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> References: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <57F84F35-4BB0-4D8E-8BE8-3FAA31631C4A@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:22:20 -0000 On June 11, 2020 6:28:13 PM UTC, Steven M Jones wrote: >In the WG Interim Session, I had given a "+1" to Autumn Tyr-Salvia's=20 >comment about redacted failure reports being better than no failure >reports=2E > >I also suggested that perhaps potential failure report generators would > >be encouraged if they could see examples of reports with different=20 >levels of redaction=2E This would be as opposed to only seeing "reports= =20 >SHOULD include as much of the message and message header as is=20 >reasonable" in RFC7489 section 7=2E3, and deciding to avoid a potential= =20 >headache=2E > >Whether these examples would best be delivered through the DMARCbis=20 >appendix, the DMARC Usage draft (currently "parked"), or an effort more > >aligned with the ARF family of specs, I am not sure=2E > >If there's a desire to see this, I'm willing to try to put something=20 >together=2E I think it's entirely sensible to assess demand before investing a lot of = time in this=2E I do not, however, think all opinions are equal on this to= pic=2E We know senders would like to see the feedback=2E Autumn Tyr-Salvi= a's presentation of the issue during the interim was clear and concise=2E = I think the real question on this issue is for receivers=2E Is there anyon= e working that side of the equation that would be inspired to send some kin= d of limited feedback report where they send none now is they had clearer e= xamples to work from=2E Scott K From nobody Thu Jun 11 20:40:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC953A03F6 for ; Thu, 11 Jun 2020 20:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=crash.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 O7vUeDzWSH2s for ; Thu, 11 Jun 2020 20:40:31 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 8EF273A03FF for ; Thu, 11 Jun 2020 20:40:31 -0700 (PDT) Received: from [10.10.10.124] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 05C3eLgl002071 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 12 Jun 2020 03:40:30 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 05C3eLgl002071 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1591933230; bh=W+AwfQHc2Ilfc8MfSQUGssvGaC4FsWyXxbcdOqlhmXU=; h=Subject:To:References:From:Date:In-Reply-To; b=YOlHbxm6tmng6c4sMiBnNIO+sCZJtQERYUhkQE4c1eIxEv5+1EJbp/mCs5U64Tc/C NhgIVuBxp2zclRlHQhqH92nHil13pnVAjKcld3rrNLxYsPVs6tWn6WvN4RJzrgtDjI /FBwV2Z3PfhAWfXZ1TiKTkCVh2dHS8VIxxZNRwY7ncmwF+7e/ohl1bLLzaV9OvtTdI YV/tj2iraJf9vgF5V8x/vTCMyIfMfinF1G43wugZphOdoBXbldj4yT0nOFMue1xpAN mmYJd4kaVX9/zBfUIUGNUAKf7lpWt6CYUf8nUrnG2VDnaYYHmoOeeiLSPXauD4i/qX ND/3Y0F4ZThTA== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.124] To: dmarc@ietf.org References: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> <57F84F35-4BB0-4D8E-8BE8-3FAA31631C4A@kitterman.com> From: Steven M Jones Organization: Crash Computing Message-ID: Date: Thu, 11 Jun 2020 20:40:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <57F84F35-4BB0-4D8E-8BE8-3FAA31631C4A@kitterman.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Fri, 12 Jun 2020 03:40:30 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 03:40:33 -0000 On 6/11/20 5:22 PM, Scott Kitterman wrote: >> On June 11, 2020 6:28:13 PM UTC, Steven M Jones wrote: >> ... I also suggested that perhaps potential failure report generators >> would be encouraged if they could see examples of reports with >> different levels of redaction. > > I think it's entirely sensible to assess demand before investing a lot of time in this. ... I think the real question on this issue is for receivers. Is there anyone working that side of the equation that would be inspired to send some kind of limited feedback report where they send none now is they had clearer examples to work from. I should have said "I speculated," I suppose... While listening to Autumn I couldn't recall having seen such examples, so I threw the idea out there. Anyway yes, we should be guided by data where we can get it. But if we're looking for something better than "anecdata," at the moment I can only imagine getting that through a careful survey of a large number of non-reporting receivers. And I don't see that happening unless it covers a lot more questions than just whether examples of redacted failure reports would have changed the decision not to send failure reports... If there's no sense that it would be useful, no need for further discussion. --S. From nobody Fri Jun 12 01:02:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021313A0CF1 for ; Fri, 12 Jun 2020 01:02:36 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 jJJARRUOkFOa for ; Fri, 12 Jun 2020 01:02:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E27BF3A0CF0 for ; Fri, 12 Jun 2020 01:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591948947; bh=rbNh7Wi550jZw9mMxxxIikvbfHw6kwYoEKY7iqBx0+U=; l=1448; h=To:From:Date; b=BC0CLM6CrBSj0eSO7RNIT3+CwXZjn17W8ws6DY/zMgw5HKS9xLO4VmN2cW1jFXV1M W4P+QYam1fQbut6/0hEJWZXJrupmP+FB6C6RIZ3B/3HmAIF30kMiY5vtG13UC0g6B/ aJv7mpCMIKrvBrbOBVPpj0BdYsAduhmJghaqDHh9yqmjJY6zXVleDiCL7HNs7 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005EE33693.0000257B; Fri, 12 Jun 2020 10:02:27 +0200 To: dmarc-ietf From: Alessandro Vesely Message-ID: Date: Fri, 12 Jun 2020 10:02:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 08:02:36 -0000 Hi all, I'm sorry I didn't queue to talk yesterday. After so many months without speaking one word of English, I really didn't feel like... *Why ARC cannot solve the mailing list problem* =============================================== Assume all mailing lists in the world duly did ARC. Somewhat science-fictitious, given that some of them are not even able to add valid DKIM signatures. Let's hypothesize they all did ARC, anyway. Would the mailing list problem be solved? No, because recipients cannot blindly accept DMARC failures just because there is an ARC-chain claiming authenticity. Doing so would completely defeat DMARC, because ARC chains can be forged. In order to safely override a reject or quarantine policy based on ARC, a receiver needs a complete list of legitimate mailing lists. Conversely, having such a list, a receiver can override DMARC failures also based on DKIM or SPF authentication. ARC adds nothing to the mailing list problem. (However, huge mailbox providers do have a complete list of legitimate MTAs. That's where ARC is useful, AIUI.) *From rewriting is the real thing* ================================== Rewriting From: is the de-facto standard. In a (science-fictitious) scenario where all mailing lists rewrite the From: header field, DMARC would just work smoothly. Hence, we have to specify an acceptable way to rewrite From:. I'd have said so. Best Ale -- From nobody Fri Jun 12 05:58:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022493A045B for ; Fri, 12 Jun 2020 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=globalcyberalliance.org 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 vDDlMa05tpzh for ; Fri, 12 Jun 2020 05:58:24 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 72DA93A0FB9 for ; Fri, 12 Jun 2020 05:58:24 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id z47so3172120uad.5 for ; Fri, 12 Jun 2020 05:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalcyberalliance.org; s=gca; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tMYnZBSqQ749lHOgYTxYBQ6sFp9VSKmJcEDQc1hZuQ0=; b=ju8kFcM9xzM+Vzb2FN8X3F0JbG9QjtGxMXT1dazyiNUfy14/4/TKGNBQu3Tw3GQu6A iOEaAT0uY0YwK1ZNMGEfKR7PBMWWQ0SJO/jz8X26v6L+rwf9zLGKz46HSIFizeU7kIDu bnqtURWjqzYL0deRAgJObnQt+lXde5EB/iSLU= 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=tMYnZBSqQ749lHOgYTxYBQ6sFp9VSKmJcEDQc1hZuQ0=; b=jbw+O45U7kRt4WaYnw2tTV3hPX0eCSMVBkeXU/+WsCd4x2Wge5zqS7wexWZaJAb5f2 kN/X4xrTQDmE+6lAmeS2jW2u5oXt56EjqlmAJ26zqmRhbCg6YSNt6boOp3p/74UPEDmz 6FG+hV6IG1+1giruErcv/I++ZLztOnve64wXwPqhgfKpCHXJD26CN9EaKdrWm/avAkDL qA1NCInLTCEhi7cZlP8LKxjpPSeFWEFhpsgDfq4KrxXD18nYdRy4DIm4hxJZH4xAZoV1 7st2JOoF37oTpmGJ8euoBh4ElgJIDhjeq2YB18+P4+RCa4Oib+mrShYmbJG+bJbUyaQq 0daQ== X-Gm-Message-State: AOAM532aOQbomNQthOrvoSYf1PxkbfUBe+FsePnYfYOST4dECqeepIpo 5xu4E/EBIRQ8j7J7rIF1+Lszq3fU5pOKl8jHhCwniEqUvAASZw== X-Google-Smtp-Source: ABdhPJx9wvnlopELi3wpouw+Bx6Pmr51uCuzKkETZoJQaWTxua7k4iCGsF93VpzUIHx48FdqbmijJrYGsbDRy70eQlg= X-Received: by 2002:ab0:72d2:: with SMTP id g18mr5398347uap.27.1591966703134; Fri, 12 Jun 2020 05:58:23 -0700 (PDT) MIME-Version: 1.0 References: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> <57F84F35-4BB0-4D8E-8BE8-3FAA31631C4A@kitterman.com> In-Reply-To: From: Shehzad Mirza Date: Fri, 12 Jun 2020 08:58:12 -0400 Message-ID: To: Steven M Jones Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5bde905a7e2a1c4" Archived-At: Subject: Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 12:58:27 -0000 --000000000000d5bde905a7e2a1c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I've been following conversations as best I can via the digest (which was a bad idea), so switched to single emails. Based on what I've heard from those just starting off with DMARC and have received very few failure reports, it's actually useful to get some form of them (redacted or not). In one case, all the failure reports were spam messages. This helped to push the org to get to a policy of reject as soon as they could. For other organizations, which were not getting any failure reports, the question continuously comes up on how can they determine which messages are the ones that are failing (and not having to try and dig through a day's worth of messages to try and figure it out). I think this is where the failure reports can help to some extent. Just my 2 cents, for what it's worth. - Shehzad =E2=80=A2 =E2=80=A2 =E2=80=A2 =E2=80=A2 Shehzad Mirza Director of Operations Global Cyber Alliance smirza@globalcyberalliance.org (+1) 646 677 5535 (Option 3) [image: GCA Website] [image: GCA Twitter] [image: GCA Facebook] [image: GCA LinkedIn] [image: GCA YouTube] [im= age: GCA GitHub] [image: GCA Email Signup] [image: GCA Instagram= ] [image: GCA Forums] GCA takes your privacy seriously. To review our privacy policy, please click here . On Thu, Jun 11, 2020 at 11:40 PM Steven M Jones wrote: > On 6/11/20 5:22 PM, Scott Kitterman wrote: > >> On June 11, 2020 6:28:13 PM UTC, Steven M Jones wrote: > >> ... I also suggested that perhaps potential failure report generators > >> would be encouraged if they could see examples of reports with > >> different levels of redaction. > > > > I think it's entirely sensible to assess demand before investing a lot > of time in this. ... I think the real question on this issue is for > receivers. Is there anyone working that side of the equation that would = be > inspired to send some kind of limited feedback report where they send non= e > now is they had clearer examples to work from. > > > I should have said "I speculated," I suppose... While listening to > Autumn I couldn't recall having seen such examples, so I threw the idea > out there. > > Anyway yes, we should be guided by data where we can get it. But if > we're looking for something better than "anecdata," at the moment I can > only imagine getting that through a careful survey of a large number of > non-reporting receivers. And I don't see that happening unless it covers > a lot more questions than just whether examples of redacted failure > reports would have changed the decision not to send failure reports... > > If there's no sense that it would be useful, no need for further > discussion. > > --S. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d5bde905a7e2a1c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I've been following conversati= ons=C2=A0as best=C2=A0I can via the digest (which was a bad idea), so switc= hed to single emails.=C2=A0

Based on what I've heard fro= m those just starting off with DMARC and have received very few failure rep= orts, it's actually useful to get some form of them (redacted or not).= =C2=A0 In one case, all the failure reports were spam messages.=C2=A0 This = helped to push the org to get to a policy of reject as soon as they could.= =C2=A0=C2=A0

For other organizations, which were not getting= any failure reports, the question continuously=C2=A0comes up on how can th= ey determine which messages are the ones that are failing (and not having t= o try and dig through a day's worth of=C2=A0messages=C2=A0to try and fi= gure it out).=C2=A0 I think this is where the failure=C2=A0reports can help= =C2=A0to some extent.

Just my 2 cents, for what=C2=A0it'= s worth.

- Shehzad

=C2=A0
=E2=80=A2=C2=A0=E2=80=A2=C2=A0=E2=80= =A2=C2=A0=E2=80=A2=C2=A0
Sh= ehzad Mirza
Director of Operations
Global Cyber = Alliance
smirza@globalcyberal= liance.org
(+1) 646 677 5535 (Option 3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0=
3D"GCA3D"GCA3D=3D"GCA=3D"GCA3D"GCA=3D"GCA=3D"GCA

GCA takes your priva= cy seriously. To review
our privacy policy, please=C2=A0click here.

<= /td>




On Thu, Jun 11, 2020 at 11:40 PM Steven M J= ones <smj@crash.com> wrote:
<= /div>
On 6/11/20 5:22 PM, = Scott Kitterman wrote:
>> On June 11, 2020 6:28:13 PM UTC, Steven M Jones<smj@crash.com>=C2=A0 wrote:
>> ... I also suggested that perhaps potential failure report generat= ors
>> would be encouraged if they could see examples of reports with
>> different levels of redaction.
>
> I think it's entirely sensible to assess demand before investing a= lot of time in this.=C2=A0 ...=C2=A0 I think the real question on this iss= ue is for receivers.=C2=A0 Is there anyone working that side of the equatio= n that would be inspired to send some kind of limited feedback report where= they send none now is they had clearer examples to work from.


I should have said "I speculated," I suppose... While listening t= o
Autumn I couldn't recall having seen such examples, so I threw the idea=
out there.

Anyway yes, we should be guided by data where we can get it. But if
we're looking for something better than "anecdata," at the mo= ment I can
only imagine getting that through a careful survey of a large number of non-reporting receivers. And I don't see that happening unless it cover= s
a lot more questions than just whether examples of redacted failure
reports would have changed the decision not to send failure reports...

If there's no sense that it would be useful, no need for further discus= sion.

--S.


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d5bde905a7e2a1c4-- From nobody Fri Jun 12 06:06:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7243A08C5 for ; Fri, 12 Jun 2020 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_REMOTE_IMAGE=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=cert.ee header.b=r4gAZQWG; dkim=pass (2048-bit key) header.d=cert.ee header.b=PXE7LY0K 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 6g5_SoXRkV8T for ; Fri, 12 Jun 2020 06:06:29 -0700 (PDT) Received: from smtp-out.cert.ee (smtp-out.cert.ee [46.226.143.37]) (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 1204D3A08AC for ; Fri, 12 Jun 2020 06:06:29 -0700 (PDT) Received: from mail.cert.ee (mail.cert.ee [46.226.143.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp-out.cert.ee (Postfix) with ESMTPS id 6A7C43F88B for ; Fri, 12 Jun 2020 16:06:24 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.ee; s=mail; t=1591967184; bh=3DH7993lkpQp+5zFlD4AtGtVLTiQ92InaPzZSJDZv1c=; h=To:References:From:Date:In-Reply-To; b=r4gAZQWG7fKYG1eFPO+Cr5tsH1v7lbDuC1wAAN/djE5yY9d5GYsOwRhmSMsW3CBxh ijfN2V6NW/m4eQ7oS3kIMXR2CCInk+aj1vFiWB2/5qX1n/PTDV7UCkUpmEwgZWd1el w3O5ui1YC02ReoDT09FJM8a0k0HMCgNUnlhUbCmDtsiI/jTQ+i3A5y5eepYEB989fc fpsQnm1Y8LtM8nMKi07993PJbKI1oiYJR1d8gK5ehf2JEVCXALJsCqJlVQoG3Ojmtt EkWEJLgZ/xlHQbd/qQ80yP73VIIGw5akAvRoiyx9DSz/bK8ZSdj/XQYIB7cTx7RqTp c4BbfPFB93T9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.ee; s=mailcertee; t=1591967184; bh=3DH7993lkpQp+5zFlD4AtGtVLTiQ92InaPzZSJDZv1c=; h=To:References:From:Date:In-Reply-To; b=PXE7LY0KUoCELh8u5QrEz2HG/diq3fH4LJkbc9mqdDktwFwqcI314+MjLZaLdaJWH +BuvhxCYv3PcisIyhcy3mDKcNZ8kQ7FqxaisoL9zdpqIl2plUDXqRV/hswVOdz39J4 e3ahfHKCY6riBA34cvtsRaz1S2m5EhhgiYogEuj21hQGAdIef+euIRxKkiXJ+0IvfK hlfd8MLQhLtjvuSKElPnWRVw9tKZjIRN63YSxvqO9DXNEni1oQED5N4K1ofLU4qLLy s4DLgA3r1s1Nl4fWAI6nk9JXeREpBmMmjYSr0EdKuMoGmcJ/Ww9P16JRkx6sDlB11K hdhmXfzVWng8Q== To: dmarc@ietf.org References: <0eed1def-de0e-2055-151b-57f0b52738d3@crash.com> <57F84F35-4BB0-4D8E-8BE8-3FAA31631C4A@kitterman.com> From: =?UTF-8?Q?T=c3=b5nu_Tammer?= Autocrypt: addr=tonu@cert.ee; keydata= mQINBFsX3wABEADx8PMtzm0dHjVdKRZgJDV4By1jS5f5awn7znEh0YM+crfm4zyEmQlZWfbo avIEJQDwGlUrA/FHdqdYdXI42fuPgmVkdSAynXZu5Upze/israDjKxBcQUIZ3eLr2BpJYNkq CaBdnueT5dmyRGwV0X9z8HFtvfQiompKewIC37NBlCxSBvC0ZHVQFQwV/6fR1PR6AeSqnHw9 QVj5AHxK1LebVyrzTRF4BGJRIjcd5tYdUVrCpeZ2/vXZpsG5buvDoD/HFelM8JvghRu2zsPn 8flsca4pMSMWrMxXe0gRtmxzOuI7IRw+fzaz2+BG/ja4ytt4aKBQ793PPy++BI6+wCsJ92St pFKfj85Bp2v0f94GHnQrAgrqXqpYd5btvwZZVjY+oaTGardLf5YlKBChoRDF0FdMfCTpfTDV /VFVVZGl1VS/mzabypVdSYJjU1lIw0X3PBcN+35Ta7rcEUFAwJW575MMS7EASlVN8Co5tz1y YMhjNtUDMnK+Rld/oIiqVLYNsQKavLyn/WvCwL+V01Uy9/u6pXbiVwR+bNGMHWJZoz9Lf35k ULVmyjhpSo/1LN2aqJy2kpV9qOM/EzkPDubBHgsvTpO92cQO+mFHGAoVextMSh36nsX+u3rN Kqqk1MSQWZmxMENNu0e5lLDVsCtEwuPhmLnu6mE81v/poYEQGQARAQABtBtUw7VudSBUYW1t ZXIgPHRvbnVAY2VydC5lZT6JAlQEEwEIAD4WIQSUd2uGah6Em8RWRtacqJ5Bd6iZewUCWxff AAIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCcqJ5Bd6iZe82WD/9+zAIf AwGB7gVHFFyMhNWnYftfdnM0loIfcVUgSpQhE62N/P1Ox64ams7R2jAXMEh/kvq+OWSYWcD1 rY7AC1mo2ViOLN62tx04bkWvrFRu883H1M+cEPc1JPM9br4ocWZB3XCbt3r4vm47ZYB2UmyL K+YGlJS2nbyRQ7THIrTbI4KkekgFr16YG3qR3v46VekYfpEpJ1m3JlkqZO5jV8fpsbi37W58 aVfeH4at/65Qa7uO59bFhWeWPnDMW9IQHMkg9IBQUzBmGjWX9rNonCTV7dkfrcLPK1by0eZd U71sRMVUG6TNxUFshoTDinBJOW99JCEpzkwhlFRF/sm8osNRPNXSFV/OG7xF0OE9vdlYHi4J g2aQNrTkmHFYybQgBP58QPoKj1EE5VvIsEvlpvfbsb3wu34RmjQTbqhIpSJ6cA5e9fwW2cCd NmVzsNhULQrGF6i+wV+b+b7MHQJ+C53LdH//xkfWB2RYaWgAbbcowVSSWoCTkfOF2D31Skct YIXJpVLiNzG60sTtiiinw5OdnV8P7EwR65mwJsC/uugY3YTzQbx/G2z4IvE/qAPoKnLOPMb2 Ec1rLIEs8Dfa7cM5C6/D+PS8SlE4JVPIXgyFGimlJeJaaldADCAQ567f17gmj5ZEL6uvLFEY FmB7SSJjOLqnFabr13zV94el7sOZt7kCDQRbF98AARAAnRG/CV2sJXh6hM9JYx4KnFs6ZUC0 kFq8lj72raBTx/rEggecwsj9r5hxJi0EyRD4Apid1K3vybiKZLEXE1VTZOZq0gxNw74IUOPy G1UCx3AGMZXKMVoCP+zYvNchlP4Xcsmpn7bLmklZy4xFM1jJTbBWP5znEIBRq9weVrcVQASz BTk3qC6/i4IfL3sAVvKrW2wNJ5jaaSifpn5t9SP8/hvinUeDk7VsCUQyyXaGDKGnf+2NixXd kYdJE/WQ+jOhNT5ujgC9mdCCPYwzC27+9eKzMcC3n4NdrBS+VUmfsM87hpER1dL+33WO8gUa H4KMNhOJ517v4Z/EXyWFez9a4oo9A4IPWXz1Z95NYd8x7KLb2XTr5qdKKSSD5TCCgzaXPR5W 2ivxWnQkxhfCwnT1tzZDAyvNbhwTUb0ggf5Tr478RLpofuMnluxe30/gcqFkE/4dFjo8sEks yBjTaXVJXFi39d0SGjjsHxsEUAu3YCQMBB+436uDdc8yb4yzKpiPja1jYGnfKKpcw1p33WaN VN6QnWzx3+dY9M7xouS8LKcITUB0VgsD/hwJdZcsjIT3BUZob7jbgaZAamuL0C8qvHuvNfwH f2o0ca7jZDNKm2qyZ8f4Oe9/XkqmOY3x6+zgIlpdH1Docdvh1RGv52eZx0tMd/OIMJHVLc6C OcQmdZEAEQEAAYkCPAQYAQgAJhYhBJR3a4ZqHoSbxFZG1pyonkF3qJl7BQJbF98AAhsMBQkJ ZgGAAAoJEJyonkF3qJl72YUP/j5PBqco2JYNpw/DGf9yqlmnPsPxBenv7Uz/MBNffIEZAh9h BlJ8oEfqzW+gCB+hyrPv/50pAp3Gn0QlYNAofk2djyXcK6g3LjC5MLWWpO0NZWum82UE/edq 25CJwaOcxvWMewMyrzNr8UVTeJfxaZ8khVaOB9H1NfUscIc0UvjMxCAQA6YuXA+DSheiQc6E Lm4lKA6cQIlKSMHvt72Cg7kknC+exVxKr14DWYQptfptP9LRaYq9I4FUucJfj7K7ZbN04+di jyYmk0AU0J9tpmTUTQcczqZwoOqhYWBAnWqqN0mGgiEU/AusTfgRb9DYFkogiCzthXPvKmmz RqiLmJkfxrQaV5uSOf7Bl4W1uATVHbLWlVhf4KnJWRGkE5u/HSoy7A2N/Spl1aT8bgsByqAT jXa9iYf3KcfNh4V45MzowvvaBjRXvAOZJl99dXtBKL0AFxCOKOp+k+FAPK4W+RvoDwP0tGPU YzReevXdM5maWRdJfBl7zi6PS5fQQFg3qJnmCoCY74GTIQJEKltj+HpcJbPt5dC3ifTCTXhP RX2CE9tRHkcMJWHlm8mpWZ+cKgoxUqu4+K5VfVsCPxx2sDKIk1MuEecVVlzpoNiaWqYpTMmQ or0hIzBhl+AFR27KMxG+9OK/tb5tVCMjcwdUuJJvQ7afI+JPmI/5/SwVcACg Message-ID: Date: Fri, 12 Jun 2020 16:06:23 +0300 BIMI-Selector: v=BIMI1; s=default; MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D67E0D31BE8EE44E52752442" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 13:06:33 -0000 This is a multi-part message in MIME format. --------------D67E0D31BE8EE44E52752442 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, RUF reports are useful for the organizations to understand that an attack has actually begun (i.e. phishing of bank). This is extremely useful and helpful tool for security teams. It helps them to act faster in reacting to such events i.e. via take down requests of phishing sites.= =C2=A0 Kind regards, --=20 T=C3=B5nu Tammer CERT-EE juht / Executive Director of CERT-EE Riigi Infos=C3=BCsteemi Amet / Estonian Information System Authority Email: tonu@cert.ee Mobile: +372 53 284 054 Web: https://cert.ee PGP:0x77A8997 / 9477 6B86 6A1E 849B C456 46D6 9CA8 9E41 77A8 997B On 12.06.2020 15:58, Shehzad Mirza wrote: > Hi All, > > I've been following conversations=C2=A0as best=C2=A0I can via the diges= t (which > was a bad idea), so switched to single emails.=C2=A0 > > Based on what I've heard from those just starting off with DMARC and > have received very few failure reports, it's actually useful to get > some form of them (redacted or not).=C2=A0 In one case, all the failure= > reports were spam messages.=C2=A0 This helped to push the org to get to= a > policy of reject as soon as they could.=C2=A0=C2=A0 > > For other organizations, which were not getting any failure reports, > the question continuously=C2=A0comes up on how can they determine which= > messages are the ones that are failing (and not having to try and dig > through a day's worth of=C2=A0messages=C2=A0to try and figure it out).=C2= =A0 I think > this is where the failure=C2=A0reports can help=C2=A0to some extent. > > Just my 2 cents, for what=C2=A0it's worth. > > - Shehzad > > =C2=A0 > =E2=80=A2=C2=A0=E2=80=A2=C2=A0=E2=80=A2=C2=A0=E2=80=A2=C2=A0 > Shehzad Mirza > Director of Operations > Global Cyber Alliance > smirza@globalcyberalliance.org > (+1) 646 677 5535 (Option 3) > GCA Website > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 > GCA Twitter GCA Facebook > GCA LinkedIn > GCA YouTube > GCA GitHub > GCA Email Signup > GCA Instagram > GCA Forums > > > GCA takes your privacy seriously. To review > our privacy policy, please=C2=A0click here > . > > > =09 > =09 > =09 > =09 > =09 > > > > > > > On Thu, Jun 11, 2020 at 11:40 PM Steven M Jones > wrote: > > On 6/11/20 5:22 PM, Scott Kitterman wrote: > >> On June 11, 2020 6:28:13 PM UTC, Steven M Jones >=C2=A0 wrote: > >> ... I also suggested that perhaps potential failure report > generators > >> would be encouraged if they could see examples of reports with > >> different levels of redaction. > > > > I think it's entirely sensible to assess demand before investing > a lot of time in this.=C2=A0 ...=C2=A0 I think the real question on= this > issue is for receivers.=C2=A0 Is there anyone working that side of = the > equation that would be inspired to send some kind of limited > feedback report where they send none now is they had clearer > examples to work from. > > > I should have said "I speculated," I suppose... While listening to > Autumn I couldn't recall having seen such examples, so I threw the > idea > out there. > > Anyway yes, we should be guided by data where we can get it. But if= > we're looking for something better than "anecdata," at the moment > I can > only imagine getting that through a careful survey of a large > number of > non-reporting receivers. And I don't see that happening unless it > covers > a lot more questions than just whether examples of redacted failure= > reports would have changed the decision not to send failure reports= =2E.. > > If there's no sense that it would be useful, no need for further > discussion. > > --S. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------D67E0D31BE8EE44E52752442 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

RUF reports are useful for the organizations to understand that an attack has actually begun (i.e. phishing of bank). This is extremely useful and helpful tool for security teams. It helps them to act faster in reacting to such events i.e. via take down requests of phishing sites. 

Kind regards,

-- 
Tõnu Tammer
CERT-EE juht / Executive Director of CERT-EE
Riigi Infosüsteemi Amet / Estonian Information System Authority

Email: tonu@cert.ee
Mobile: +372 53 284 054
Web: https://cert.ee

PGP:0x77A8997 / 9477 6B86 6A1E 849B C456  46D6 9CA8 9E41 77A8 997B


On 12.06.2020 15:58, Shehzad Mirza wrote:
Hi All,

I've been following conversations as best I can via the digest (which was a bad idea), so switched to single emails. 

Based on what I've heard from those just starting off with DMARC and have received very few failure reports, it's actually useful to get some form of them (redacted or not).  In one case, all the failure reports were spam messages.  This helped to push the org to get to a policy of reject as soon as they could.  

For other organizations, which were not getting any failure reports, the question continuously comes up on how can they determine which messages are the ones that are failing (and not having to try and dig through a day's worth of messages to try and figure it out).  I think this is where the failure reports can help to some extent.

Just my 2 cents, for what it's worth.

- Shehzad

 
• • • • 
Shehzad Mirza
Director of Operations
Global Cyber Alliance
smirza@globalcyberalliance.org
(+1) 646 677 5535 (Option 3)
GCA Website
                                                                                                        
GCA Twitter GCA Facebook GCA LinkedIn GCA YouTube GCA GitHub GCA Email Signup GCA Instagram GCA Forums

GCA takes your privacy seriously. To review
our privacy policy, please click here.









On Thu, Jun 11, 2020 at 11:40 PM Steven M Jones <smj@crash.com> wrote:
On 6/11/20 5:22 PM, Scott Kitterman wrote:
>> On June 11, 2020 6:28:13 PM UTC, Steven M Jones<smj@crash.com>  wrote:
>> ... I also suggested that perhaps potential failure report generators
>> would be encouraged if they could see examples of reports with
>> different levels of redaction.
>
> I think it's entirely sensible to assess demand before investing a lot of time in this.  ...  I think the real question on this issue is for receivers.  Is there anyone working that side of the equation that would be inspired to send some kind of limited feedback report where they send none now is they had clearer examples to work from.


I should have said "I speculated," I suppose... While listening to
Autumn I couldn't recall having seen such examples, so I threw the idea
out there.

Anyway yes, we should be guided by data where we can get it. But if
we're looking for something better than "anecdata," at the moment I can
only imagine getting that through a careful survey of a large number of
non-reporting receivers. And I don't see that happening unless it covers
a lot more questions than just whether examples of redacted failure
reports would have changed the decision not to send failure reports...

If there's no sense that it would be useful, no need for further discussion.

--S.


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


  


--------------D67E0D31BE8EE44E52752442--


From nobody Fri Jun 12 09:10:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95C3A0FBE; Fri, 12 Jun 2020 09:10: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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=ERywzfb7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mjdLldeY
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 y2XB12CHjnLE; Fri, 12 Jun 2020 09:10:30 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE1C3A0E22; Fri, 12 Jun 2020 09:10:29 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2967D5C01F0; Fri, 12 Jun 2020 12:10:29 -0400 (EDT)
Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Fri, 12 Jun 2020 12:10:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:cc:subject:content-type; s= fm3; bh=YILJctFL5WkbtZTNEqkB+r2RoztkIDjG6cCv6uq+2LY=; b=ERywzfb7 wR+G+PvVwh97pLFVc5mk3K4ID1aNOqaPeolDtIUIeFVs4drQvNjgE/VW1Kpv2Ral d5T3xavXqjc6zzd8l8WQbZ+2vy/DtmcrZaHdhW7pOz2iIG512PuxqnXui5/Q7MCM 1sPzi45BELTJyT/qcx3wbdIZbwjfgyS/u7gtyXm8bm/GTHAV9TQDrUczPeLa0BaV ydBi4bG1mXHG1IC9H6+pXy7OMe4SCisCCBADG9Jn5gE6YD/WUOdVMLgpM+b+35bO isiSjYt27uQtrIlMV2IxyH2burQygAzTsA5oMFA5T6z7o2ADvc9z83enm6AIKjNx lVoMBwa5BzoEZA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=YILJctFL5WkbtZTNEqkB+r2RoztkI DjG6cCv6uq+2LY=; b=mjdLldeYzoN1tEwamcV8pCOQChEh8DbcTnXpKbNMaVvnc 3TH/sc9S66nnZo/n5KEX3vDfNtVeOQN9LeAJ2dA0cPNleNfuSKdiwq6FOnhz3PaY pSoSzDz0gL1yBLJxO4DR3OKOmZdqw6g8ELGuUiWx71wO1B+f6IGkapUdzjfOf4my 3Yf1mqBIYHFi61f/oeRx/yuRDENvwW8hUCKSIWmikfBzCXhyhEf7u3P84i3vY3wA jR1gmvWZJI0/F/lJq2I7JNr4XWQeXt99hpRgBdkjN5v8qqGXPvo07Cw1TGJ8j90T RZg1gKuKmwAaHUSn0Fjnatedg4nqBcldSCbAZMNcg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeiuddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepheefvdelhf dthfekveeilefgtdelffegueejuddttefhieegjeekiedtkedtjefgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvse hfrghsthhmrghilhdrfhhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 205D6660081; Fri, 12 Jun 2020 12:10:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: 
Date: Fri, 12 Jun 2020 17:09:41 +0100
From: "Alexey Melnikov" 
To: dmarc@ietf.org
Cc: dmarc-chairs@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jun 2020 16:10:31 -0000

Hi all,

On behalf of DMARC chairs I would like to ask for volunteers to edit future revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the current document into multiple drafts that can be progressed in parallel, so we are seeking multiple editors to help with this.

If you are interested or know somebody who might be interested, please email dmarc-chairs@ietf.org directly. Also feel free to email dmarc-chairs@ietf.org if you have questions about expectations, time commitment, process, etc.

Best Regards,
Alexey, as DMARC co-chair


From nobody Fri Jun 12 09:51:24 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2243A118C; Fri, 12 Jun 2020 09:51: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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 byBrZtnda9D6; Fri, 12 Jun 2020 09:51:19 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 F0A503A0F02; Fri, 12 Jun 2020 09:51:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1591980674; bh=67JrBylmUWPKhshAr1l1qtbaq1z1t/bDtdTKdhuvl5Y=; l=875; h=To:Cc:References:From:Date:In-Reply-To; b=BH9bv6Ud2aKoJHCyg+eI76w0cctaKgVduMY8xcWqqrQSBzbvdMFV0udD0eTcMuxTm 6+hjSj8yKeXWsFaQsYjQ28ZphouJm13qlaCxf3/5cTGhAe/7YFdSEzFncznZWhmYs/ heA3btC2trOw/0pCIVdgqwupUOAL7lJGmxp+juyaGrRoPDDlEdYotTy6xhWOx
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B0.000000005EE3B282.0000677F; Fri, 12 Jun 2020 18:51:14 +0200
To: Alexey Melnikov , dmarc-chairs@ietf.org
Cc: dmarc@ietf.org
References: 
From: Alessandro Vesely 
Message-ID: 
Date: Fri, 12 Jun 2020 18:51:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jun 2020 16:51:22 -0000

Hi,

On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:
> 
> On behalf of DMARC chairs I would like to ask for volunteers to edit future revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the current document into multiple drafts that can be progressed in parallel, so we are seeking multiple editors to help with this.


Is it already defined which and how many I-Ds will the WG do?


> If you are interested or know somebody who might be interested, please email dmarc-chairs@ietf.org directly. Also feel free to email dmarc-chairs@ietf.org if you have questions about expectations, time commitment, process, etc.


I'd be interested, if there are no better editors...

I know Tim is maintaining a draft on GitHub[*].  Is that the doc to be split?

Best
Ale
-- 

[*] https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis


























From nobody Fri Jun 12 10:50:27 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8D3A1283; Fri, 12 Jun 2020 10:50:25 -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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=bGlODuxr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=drtzpEeX
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 bCwVe3LKCXEs; Fri, 12 Jun 2020 10:50:24 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FDB3A1281; Fri, 12 Jun 2020 10:50:24 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7F5945C015A; Fri, 12 Jun 2020 13:50:23 -0400 (EDT)
Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Fri, 12 Jun 2020 13:50:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=BISSkF0nDKZpjXRhnUpmP2ElNuXC0+B DbCmAY+tWHEM=; b=bGlODuxrkhjyUnKE/tc6HVCeeqZi30mddWu8H4kFdTXj6ph XJjAt73NiHL9WJltDlHR6oZj7I7wDmKqaH1MWss6SrkbjMqj4ghwSki1GmJ1dGia dQfmnYYg1NcK+98MliL3orDH+GXOIjh0rsKpOe1der4/om/W+XUqOFBbJ3kWU5Q9 N7CPQz4omEA1RgX+m8sMb/TgK26ThZ7AIm42HzJy6QpkaeQZLjwV+QtkTZj9cJV1 Zb+NaLCZAK1A4kdQg1fGwdvwzSt/ZhmGVxkOi3RqPw69PnMtv+SLRK6WJfYCbqk3 c3fPgDTD48CsCDbZDKvegG5tdGjVcuTVzNe53hA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=BISSkF 0nDKZpjXRhnUpmP2ElNuXC0+BDbCmAY+tWHEM=; b=drtzpEeXnuYAEubeIOnVdY +XOPqMWL//Bgxz5shD4cM29o5mXuT2I91lQM1m/QrFyv1IzSaPorFic7P0Iw3Xjf UyLlk9ZknT2NBgbXZ/yNPFajoMzejS5frGSQPHLmtfMDIY3VMiO9XqawGi/2050N IFj3ixeEGf53B6INe3RDEavfqrQQsyzLvna9PqBb6Jx5yH8eD71wBfnqDPcQWpLo 91LyquuhjwJYdtO3us5Ul/qnYM22PKLEqAc4ghYraV5REu7Bz7y89UBi2cfsk2Di ovyC09Cz4Rf/z3ci3PXGjrQjlHqWF2irWPoZrRchS0cfpFJnEaxpRvrNWLbBaGEg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeiuddguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeelfeejtefgtdehkeekffegueevveduffetffef udeihfejueeiuddvffffvdejteenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhn ihhkohhvsehfrghsthhmrghilhdrfhhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0BE06660081; Fri, 12 Jun 2020 13:50:23 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <8a575da6-bc37-4824-9166-b68bfa430013@www.fastmail.com>
In-Reply-To: 
References:  
Date: Fri, 12 Jun 2020 18:49:36 +0100
From: "Alexey Melnikov" 
To: "Alessandro Vesely" , dmarc-chairs@ietf.org
Cc: dmarc@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jun 2020 17:50:26 -0000

Hi Alessandro,

On Fri, Jun 12, 2020, at 5:51 PM, Alessandro Vesely wrote:
> Hi,
> 
> On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:
> > 
> > On behalf of DMARC chairs I would like to ask for volunteers to edit future revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the current document into multiple drafts that can be progressed in parallel, so we are seeking multiple editors to help with this.
> 
> 
> Is it already defined which and how many I-Ds will the WG do?

We (chairs) only had a preliminary discussion. I think at least 3 (aggregated reports, failure reports, the rest).

> 
> > If you are interested or know somebody who might be interested, please email dmarc-chairs@ietf.org directly. Also feel free to email dmarc-chairs@ietf.org if you have questions about expectations, time commitment, process, etc.
> 
> 
> I'd be interested, if there are no better editors...
> 
> I know Tim is maintaining a draft on GitHub[*].  Is that the doc to be split?

Yes.

> 
> Best
> Ale
> -- 
> 
> [*] https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis

Best Regards,
Alexey


From nobody Fri Jun 12 16:33:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1C13A1651 for ; Fri, 12 Jun 2020 16:33:29 -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 (1024-bit key) header.d=drkurt.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 qluZ2JK3wwr2 for ; Fri, 12 Jun 2020 16:33:28 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 AB1823A164E for ; Fri, 12 Jun 2020 16:33:28 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id q8so12043224iow.7 for ; Fri, 12 Jun 2020 16:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7a6wTEW8XClNf3jFgiyPZ3yXPy5YdJT9w7qlRqFVGT0=; b=dlk/pK+YTaDXbaum8Oas4UQhmsiAJXKebz9QCKAQIUQtrqRxSdAsk5qDXhP6uGk+Fh pHp1lWS7kwwmsO89c2dXhsC53nIu1lOqUY60s3EzqJkvIFdLg5h1bTzpWsUdlRg8xXdB M+NLefuEjT2dPAqIXM6GBlS4pXOa4Td1/L6+w=
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=7a6wTEW8XClNf3jFgiyPZ3yXPy5YdJT9w7qlRqFVGT0=; b=MLGbXdz9khXd4xWUsoNbckYvUwUwXC0gGlFx2mu10XHqFqy80WR6hoNksYROxu5cvb dxAbfxULBeu+K824Jim8Vyj1w5LcUzbToxQku8a/DXRzwnGzuLNQHWnNMirmu7ChMGlm YRQ9PAojO4EFNnM/iWsRpQF4npSM2HavYl4eX3pCwhVNHCCQadEEr7qWsJc5VgRDFLLD qt71BswHahi/3k3ruuRKXemG7KjihGI4gGsVydUNaOcqKF6CFAfA5Vf8EEMQxarVpE8Q uVYaSJ9bEtld5rTvzunhxFrgjq/B9eArqjNFS1wy1j27nRcAtwSRevWXogHGvPXmtO8M 7fvQ==
X-Gm-Message-State: AOAM5326twa8nFT1BZGGBjqtexF87Ceq8LDasnrW55g1h0VAA1JefEa4 sLLO2FGk1ehuwPy1hcEao5Kgl5djeb0cbWiRov3VvkRm
X-Google-Smtp-Source: ABdhPJyv5ROhfZyaSvUQt9GEJXM0en5uYkzR6Z60OE+kFNXlORKVjizF3M+3mmt9iFyiTzKgwDQSDMtprVPktrPHQWQ=
X-Received: by 2002:a05:6602:2fcb:: with SMTP id v11mr16157251iow.121.1592004807813;  Fri, 12 Jun 2020 16:33:27 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: "Kurt Andersen (b)" 
Date: Fri, 12 Jun 2020 16:33:13 -0700
Message-ID: 
To: Alessandro Vesely 
Cc: dmarc-ietf 
Content-Type: multipart/alternative; boundary="0000000000000d0dc505a7eb8135"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jun 2020 23:33:30 -0000

--0000000000000d0dc505a7eb8135
Content-Type: text/plain; charset="UTF-8"

I would like to understand what you mean by:

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely  wrote:

> . . . ARC chains can be forged.
>

--Kurt

--0000000000000d0dc505a7eb8135
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I would like to understand what you mean =
by:=C2=A0

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely <vesely@tana.it> wrote:
. . . ARC chains can be forged.

--Kurt=C2=A0


--0000000000000d0dc505a7eb8135--


From nobody Fri Jun 12 17:02:23 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2553A0A32 for ; Fri, 12 Jun 2020 17:02:22 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 RDzCHko7YTw2 for ; Fri, 12 Jun 2020 17:02:20 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 C46113A0A2A for ; Fri, 12 Jun 2020 17:02:20 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:c71:680a:a32:86fc]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05D02IX4016964 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 12 Jun 2020 17:02:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592006540; bh=IkcrhYvjPyndcp7SAcMAhzemmyn85Wkz1lVoAqC+E4o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dB/2s9m96P9qKCO/Q9ZQa/P6/gN0UYDnrmAyOxGcKQ2BKtEcmZbdTtB1ghB+btu43 1n5CsnBrXmwvHTDnp7ns5xHye8tQS5S+FT5IhBJKrVBr/yUY4KHIqrGhqEDFqmyI2N YsIvAm0iWya1sX9bBJ31VQSG2PzOoxekDsRIQIgA=
To: dmarc@ietf.org
References:   <8a575da6-bc37-4824-9166-b68bfa430013@www.fastmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <58be1989-18ab-e151-e411-47f357719d27@bluepopcorn.net>
Date: Fri, 12 Jun 2020 17:02:13 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <8a575da6-bc37-4824-9166-b68bfa430013@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 00:02:23 -0000

On 6/12/20 10:49 AM, Alexey Melnikov wrote:
> Hi Alessandro,
>
> On Fri, Jun 12, 2020, at 5:51 PM, Alessandro Vesely wrote:
>> Hi,
>>
>> On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:
>>> On behalf of DMARC chairs I would like to ask for volunteers to edit =
future revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to spli=
t up the current document into multiple drafts that can be progressed in =
parallel, so we are seeking multiple editors to help with this.
>>
>> Is it already defined which and how many I-Ds will the WG do?
> We (chairs) only had a preliminary discussion. I think at least 3 (aggr=
egated reports, failure reports, the rest).

About a year ago, I had suggested [1] that the reporting and policy
mechanisms of DMARC be split, and was, I think, the only one supporting
that idea. There were quite a few comments along the line of, "it's not
broken, so why should we go to the trouble?"

Although you have only had a preliminary discussion, do you have in mind
an editorial split (different functional pieces, but DMARC is still one
thing) or an actual split into separate specifications?

Someone (not sure who) said in yesterday's interim that DMARC could run
into trouble in IETF Last Call or in IESG review because of the breakage
to mailing lists, etc. If we had independent specifications, at least
the reporting pieces could proceed. So I (still) support the split.

-Jim

[1] https://mailarchive.ietf.org/arch/msg/dmarc/HJwOvLspQKo-_GuW7W9xZPvv3=
70/




From nobody Fri Jun 12 17:06:23 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166093A0A5F for ; Fri, 12 Jun 2020 17:06:23 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=UX5Epb+6; dkim=pass (2048-bit key) header.d=kitterman.com header.b=lysLrXKq
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 KNjV-86k-kV9 for ; Fri, 12 Jun 2020 17:06:21 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204F03A0A55 for ; Fri, 12 Jun 2020 17:06:21 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 7FF50F802E4; Fri, 12 Jun 2020 20:06:18 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1592006778; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=I0NtsCTfbMVkAz1UFiHp3qE1wgrfKMzQAqZHwd+JmPQ=; b=UX5Epb+66+Z0DarImSJZjWddSZZ7GpO9ulnNyfLVvKLrQBgx31V5HZnamMnY/pMbGvJVg ZbBVM8iHUohV0XcDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1592006778; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=I0NtsCTfbMVkAz1UFiHp3qE1wgrfKMzQAqZHwd+JmPQ=; b=lysLrXKq65XOGP+r9876jSWbQiUFsZjFw2GS4eVbLZTyACrffQ0qZE4booaEQt3IBd5tT BtqaOtI6kmk1z99yuClwPyZal0dzxJA5LErLLCMLX6WH+mDVGtuBu5F9eetaliWqyuUgEKn cwJfTcwG4pv1dcDDz/QUi8bBmpxDdU5ulQyx/MFluyUf1gLtncjsfoPDWyWafopGJcaGSHI 4+K/f+hCA0uiADHqbKdOIWWLYKsGK47WSma8RVRfiMsexjwV52Tv7XxKV5HLAfOmiX8SDp+ o3MtNzohWP60C7ApZW9xwa+uzni+Tw9sdnYKQJMe8ItVWP4jqh6qfbNwacGw==
Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 0DF7BF801EF; Fri, 12 Jun 2020 20:06:18 -0400 (EDT)
Date: Sat, 13 Jun 2020 00:06:16 +0000
In-Reply-To: 
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman 
Message-ID: <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com>
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 00:06:23 -0000

On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" =
 wrote:
>I would like to understand what you mean by:
>
>On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
>wrote:
>
>> =2E =2E =2E ARC chains can be forged=2E

Not sure what is confusing about that=2E  There's no requirement that sign=
atures from previous hops still verify, so anyone can build an ARC chain th=
at claims they got something from an arbitrary source=2E  ARC is only usabl=
e if you know you trust the source=2E

Which still leaves the question of what the value proposition is since if =
you trust the source, what more does ARC really do (I suspect that the answ=
er is more tokens to run through your bayesian or whatever filter)?

Scott K


From nobody Fri Jun 12 17:19:36 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274753A166B for ; Fri, 12 Jun 2020 17:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level: 
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv4XfyOpMHWj for ; Fri, 12 Jun 2020 17:19:33 -0700 (PDT)
Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 2A20C3A166A for ; Fri, 12 Jun 2020 17:19:33 -0700 (PDT)
Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id C248E7FA47 for ; Sat, 13 Jun 2020 00:19:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=23; q=dns/txt; s=default; t=1592007571; h=from : subject : date : to; bh=RdRhcP6juWvzjBvH7mI/nH7nIdGy4fjEgTUcfp4f010=; b=kq2nbMJVbnszAznrWoH+Mve3c7unRN67IFHil9sPgiAAeinLudGPlgjkvSB7HAlm0id9z jCdUZ0ikljJ2B2I9A7RVivPHk7vD7LupsVJCPo8zFr1c2nU0pSwTUfdtQukksGSid03E6rK sF+R6a8V79uJBXJCzc7zCuUZL/xoq30=
Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id AB8E27FA34 for ; Sat, 13 Jun 2020 00:19:31 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 13 Jun 2020 02:19:31 +0200
From: Benny Pedersen 
To: dmarc-ietf 
User-Agent: Roundcube Webmail/1.4.4
Message-ID: <183dcf567d0d8d02919e6a3d02a9f76c@junc.eu>
X-Sender: me@junc.eu
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dmarc-ietf] spf helo considered in arc ?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 00:19:35 -0000

i just like to know


From nobody Fri Jun 12 17:45:39 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72DF3A1678 for ; Fri, 12 Jun 2020 17:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Q0brPWkc; dkim=pass (1536-bit key) header.d=taugh.com header.b=kagY+PCd
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 xDWRq7nOTyYL for ; Fri, 12 Jun 2020 17:45:37 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 612983A1675 for ; Fri, 12 Jun 2020 17:45:37 -0700 (PDT)
Received: (qmail 28042 invoked from network); 13 Jun 2020 00:45:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6d87.5ee421b0.k2006; bh=8f+wmSAsVb2s10yWBOT1WjzM/iNOBUsVuFHViLhNKg0=; b=Q0brPWkckB8ptN9YuZd4ISSuh7wW69bV463fPw8ap8Em+nLwsaRdlvJIlaNzeCegkKtBbW66zXHW2vFHz11gFGCXWTlkWqNoXWeKXJvM3AKdGik1jfqMGj/njpN5YsyDDf5Ni8I8G1Fqd7v+3VFETX5LUyfzKQMGzRa9KwdpJ5oR2Dc0PHWhW4a/qf7R5MY9HiBay0vrL7hnXC0Uzxa6/2hU7XAWxVPyPhZ4MCdlmKnHBcllD6EGrssMbsLIMBSX
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6d87.5ee421b0.k2006; bh=8f+wmSAsVb2s10yWBOT1WjzM/iNOBUsVuFHViLhNKg0=; b=kagY+PCdnHD5QSQP4TINGbAS5qyV9HwbkoVBm/MaLNMA3jn4v3qbnav/b7k6ZjKRVjdaw3GsUJWyBrWEVtQnVZ7sncGocSPIlRso4kAaYurCWpTvH+FiAe+T6vQl30ss8excUn5nMFid6LPaAz/ZTyodl5uTKVd2T49F8bDeoOJjaAlAjgLC4a6WPtmt2VMwakWkvb1f2apxT1tl/dndp1JmgBhbHNQbyNHL0ZoXQii2qA9vvAvQWpZLgUJAn6qf
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Jun 2020 00:45:36 -0000
Received: by ary.qy (Postfix, from userid 501) id 1D4F01A883A1; Fri, 12 Jun 2020 20:45:36 -0400 (EDT)
Date: 12 Jun 2020 20:45:36 -0400
Message-Id: <20200613004536.1D4F01A883A1@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: sklist@kitterman.com
In-Reply-To: <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 00:45:39 -0000

In article <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com> you write:
>Which still leaves the question of what the value proposition is since
>if you trust the source, what more does ARC really do (I suspect that
>the answer is more tokens to run through your bayesian or whatever
>filter)?

When I asked that a while ago I got a quite reasonable response.

Mailing lists do a lousy job of spam filtering, often only checking
that the From: address is a subscriber, and it is quite common for a
legit list to start leaking or even gushing spam. I've often seen it
when someone's address book gets stolen, spammers start taking 
(from, to) from) pairs from the address book, and one of the pairs happens
to be (another subscriber, list).

ARC lets the recipient look back and retroactively do the filtering
the list didn't. As a concrete example, I find that it is extremely
rare for legit mail coming into a list to be DMARC unaligned (as
opposed to mail coming out of the list) so if you can look back at the
ARC chain and demote mail which failed DMARC coming in, you will catch
a lot of spam without a lot of mistakes.

R's,
John


From nobody Fri Jun 12 17:51:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743763A167A for ; Fri, 12 Jun 2020 17:51:57 -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, FREEMAIL_FROM=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=gmail.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 zVIfmT7nRoTj for ; Fri, 12 Jun 2020 17:51:56 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 6C2DC3A1679 for ; Fri, 12 Jun 2020 17:51:56 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id a137so10426235oii.3 for ; Fri, 12 Jun 2020 17:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=2lN/jvebbsRNHMNJ6Dl8sjglyeMsyugN2ReqEKH1tXc=; b=Sfnm0f6H8Az4B4q9T8sOlX4g07bCJjsgV3lr3FUZOpSy86apXnhTa/8HvwnkSmFXW8 NmmL1QmiG45BJuw/5ioq6Zz7HjKabggQumGqY/FbEo/cD1HNP384yjB9rff8GhpabhyI 1uZtTOVyh/Oul9C0XPSI14XzHC9z9pXXHtX02R+PRodRfeIUnRrueu+M8/VoV34yrlSo uMt2dzNqHCTBAg47YqO5GE13T358B6cIGMtJyRBCfYL4mM9DmvRT3Ap0jelU2xdXB6Dg p8jPPRYMuBz2l2Efg9wrvxY7RWX1BKTuAxW/V3Dny0laUQhF+OGux9bcy3HtMgwOgqRE /9fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2lN/jvebbsRNHMNJ6Dl8sjglyeMsyugN2ReqEKH1tXc=; b=uT/fN0J+ehI4sigEEaK+L1attIHCnchh+Y0vAREeLm/BUW3107LSuXScuGFXaLQkN+ vtXiyjg0pDiUpnBs/+LhzyNHOUrSb21+qB82uwNvRdoS6IBkuADPTj0OtGTLw8t7x4Z9 RbN39u4/+E4K6Qxa7E7LWyRqPaONFR71JFjoFHRGJ0UjI6Q5H6dyr5YWwIgwDAMPEh+h 1La6Amo/RdUAWNCdendgoH9SuE6Ez18NIoRYOPc8CGkk9LBjpDgcOb0tpRNLmOsm4EY5 uv2hde7IDyI8AWTiG1IemeVMT82pwcPCyumfadGxe4ubWoeaxHvt3uAmrG4QWBW+I0d5 2HuQ==
X-Gm-Message-State: AOAM533WIxrOYQ+wwZY8bTUAK5Z37U3oTx+KWSzX3a1YyNK8Az33dxiR jKqtMKzOsViNNCgQMoQwFjcGtWIB
X-Google-Smtp-Source: ABdhPJxSmykbDTyE5JBF7AjwZiUS1EWhFBVWjQwWwY8p1bBzTEVbWM1h8u+kaWHmAWjF1XRz6Nuvnw==
X-Received: by 2002:a05:6808:988:: with SMTP id a8mr1239129oic.19.1592009515599;  Fri, 12 Jun 2020 17:51:55 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:e8a4:f2d2:307:c9bd? ([2600:1700:a3a0:4c80:e8a4:f2d2:307:c9bd]) by smtp.gmail.com with ESMTPSA id 4sm1707306otm.14.2020.06.12.17.51.54 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 17:51:55 -0700 (PDT)
To: dmarc@ietf.org
References: <20200613004536.1D4F01A883A1@ary.qy>
From: Dave Crocker 
Message-ID: <91cfbb70-caff-863b-15b0-61785227e13d@gmail.com>
Date: Fri, 12 Jun 2020 17:51:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200613004536.1D4F01A883A1@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 00:51:57 -0000

> ARC lets the recipient look back and retroactively do the filtering
> the list didn't.

The concern about the creator of an ARC chain spoofing the purported 
origin of a message is valid.  The above statement is correct, but needs 
to be augmented:

      Based on the reputation of the creator of an ARC chain, ARC let's 
the receiving filtering engine do filtering based on the proffered 
address of the originator.

(Recipient end-users are irrelevant to this process.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 12 21:37:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6A3A0867 for ; Fri, 12 Jun 2020 21:37:57 -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, HTML_MESSAGE=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=crash.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 1amDpWAYU_Au for ; Fri, 12 Jun 2020 21:37:55 -0700 (PDT)
Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 4960E3A0861 for ; Fri, 12 Jun 2020 21:37:55 -0700 (PDT)
Received: from [10.10.10.124] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 05D4bgPX028607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 13 Jun 2020 04:37:51 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 05D4bgPX028607
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1592023072; bh=tZ0Ziw1nqNIV/hiTXN3ot0ayhu7fJUJyfIs/2uKmVLA=; h=Subject:To:References:From:Date:In-Reply-To; b=DNmbOLvu/sicpLpNtiQM0H04x8KunrTdUS6MrCIGGbplAVKmxl7BX680PJ+b8RN/0 6+GzQtaFrUiT7+2+jroU9htPzvdLEf+z2db8wFYUa/Mjjdg2O2Fzqn/rvSnu5AuaTr hRnwdNci69X9ClL634CBUz8b+VL7fvgj4Bs9MX+H1U/5rNSuFYpzG8VPwGULR+orV7 MGFxOIfXKm8igw5ux/UKYUM7fW32i8AcaBnWNpgq1iTvpPB7DcFPmcTp21GofXi+Bv UT8kbNwlQ93BMBe4739b0xcyVYZjJkFj9Bjt55/anqH05hjnfRKeZZEnnuZ8gkAel0 Eui4AO+lz2ArQ==
X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.124]
To: dmarc@ietf.org
References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com>
From: Steven M Jones 
Organization: Crash Computing
Message-ID: <91ec8475-2a4c-03b4-4485-fc8866792a54@crash.com>
Date: Fri, 12 Jun 2020 21:37:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com>
Content-Type: multipart/alternative; boundary="------------BBAB40D2A482E2AA0C3DB342"
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 13 Jun 2020 04:37:51 +0000 (UTC)
Archived-At: 
Subject: [dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 04:37:57 -0000

This is a multi-part message in MIME format.
--------------BBAB40D2A482E2AA0C3DB342
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/2/20 5:45 PM, Douglas E. Foster wrote:
>
> As to visibility: The business world still runs on Microsoft Outlook, 
> and **Outlook presents the From Address** when a message is read. So 
> it is odd to assert that no one ever sees that data.

[Emphasis added]

Regarding this and a subsequent message in this thread from Ale, that 
may be true in the message body display, but usually not in folder 
views. Once the message is opened the body pane may show the full fields 
or not, but often a hasty or preoccupied user is busy reading and 
engaging with the content, and it's too late.

Also, I believe this is relatively recent behavior for Outlook. My 
recollection is that for many years Outlook was notorious for only 
showing the display name (or perhaps in some cases certain Active 
Directory fields it looked up) even in the body view. This has changed 
at some point but I believe it was true during the original DMARC 
effort, and I believe it was still true while this WG was working on the 
drafts that led to RFC7489.

However, the versions of Outlook I just checked (Outlook/macOS and 
Outlook Web Access) do show both rfc5322.From display name and address 
field in the body view  some of the time, perhaps most of the time -- 
but not all of the time. Viewing two messages from the same mailing list 
in OWA, one showed both fields and one only showed the display name. 
Window size did not appear to be a factor. The same applied for a 
periodic message sent from a vendor - both fields displayed in 
Outlook/macOS, only the display name in OWA.

And consider the fact that today mobile devices are the MUA of choice 
for many/most end users. Mobile MUAs are much less likely to show an 
rfc5322.From address field even in the message body view.

--S.




--------------BBAB40D2A482E2AA0C3DB342
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 6/2/20 5:45 PM, Douglas E. Foster
      wrote:

    

    

      
      


        
As to visibility: The business world still runs on
          Microsoft Outlook, and *Outlook presents the From Address*
          when a message is read. So it is odd to assert that no one
          ever sees that data. 

        

      

    

    
[Emphasis added]

    
Regarding this and a subsequent message in this thread from Ale,
      that may be true in the message body display, but usually not in
      folder views. Once the message is opened the body pane may show
      the full fields or not, but often a hasty or preoccupied user is
      busy reading and engaging with the content, and it's too late.

    

    
Also, I believe this is relatively recent behavior for Outlook. My
      recollection is that for many years Outlook was notorious for only
      showing the display name (or perhaps in some cases certain Active
      Directory fields it looked up) even in the body view. This has
      changed at some point but I believe it was true during the
      original DMARC effort, and I believe it was still true while this
      WG was working on the drafts that led to RFC7489.

    

    
However, the versions of Outlook I just checked (Outlook/macOS
      and Outlook Web Access) do show both rfc5322.From display name and
      address field in the body view  some of the time, perhaps most of
      the time -- but not all of the time. Viewing two messages from the
      same mailing list in OWA, one showed both fields and one only
      showed the display name. Window size did not appear to be a
      factor. The same applied for a periodic message sent from a vendor
      - both fields displayed in Outlook/macOS, only the display name in
      OWA.

    
And consider the fact that today mobile devices are the MUA of
      choice for many/most end users. Mobile MUAs are much less likely
      to show an rfc5322.From address field even in the message body
      view.

    

    
--S.

    


    

    


    

  


--------------BBAB40D2A482E2AA0C3DB342--


From nobody Fri Jun 12 22:19:33 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6320C3A08CA for ; Fri, 12 Jun 2020 22:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=KxAJxn4s; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=pBTqK6i+
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 1_08uYRZ0MGo for ; Fri, 12 Jun 2020 22:19:29 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 DB5E63A08C5 for ; Fri, 12 Jun 2020 22:19:28 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2138; t=1592025558; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=G3yVPshSV2dz9j5rZbHnY8/h25I=; b=KxAJxn4sNAz3K1kGi9SiFsc4zUzhungjNo7zcJ9/jCnrZ/FYkScxrKF+Uc5JKs I9Pb5jWxwpzKcuDJr+da+V0GtNgucoLZEU/1Ir+YCYJh3JYvXgShvl5TgrYZwfK9 Y36O7zLee448Nes5GCnaTLSoz4ptLm1mwXrgp4nNVaNH0=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:19:18 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2752862763.1.7444; Sat, 13 Jun 2020 01:19:17 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2138; t=1592025518; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Dv3j4bB j2JwSjQLYg9lB8Pd1QFHrx99/n6qTC8Pwl60=; b=pBTqK6i+Eb7zkEVmnqaGPGF xOAzkVl7RF5EN1ju2kB/Sl+bbsmlYW81p5Kx3KWlyaJc8vjfGyaVZRyAiMpYOPhP mA5216SU2c66UZIEcNKfZeaYmjrJKmjMRPj9MQ1OfrvvYeMgQyjpd2skbYN8gD3Z L0Mp9va+mAUNT11bWjnc=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:18:38 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3759214390.1.40800; Sat, 13 Jun 2020 01:18:38 -0400
Message-ID: <5EE461D9.5060704@isdg.net>
Date: Sat, 13 Jun 2020 01:19:21 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 05:19:31 -0000

On 6/12/2020 4:02 AM, Alessandro Vesely wrote:
> Hi all,

>
> *From rewriting is the real thing*
> ==================================
>
> Rewriting From: is the de-facto standard.

I don't support it.

> In a (science-fictitious) scenario where all mailing lists
>rewrite the From: header field, DMARC would just work
> smoothly.

Occam's razor. The simplest and most honorable protocol solution is to 
follow the specs.  DMARC will work just fine without tampering with 
headers if the list server simply honored the restrictive policy. It 
works greats!!

A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains, 
just like it is done here:

https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with 
restrictive domains. The existing subscriber becomes a read-only 
subscriber.

We had very little complaints at the beginning. But the member, for is 
own domain protection, had to use another list restrictive domain to 
participate. Right now, it works this way and it works without complaints.

> Hence, we have to specify an acceptable way to rewrite From:.

This is no acceptable way to tamper the mail in this way.  But I did 
suggest with following. For an example of what it did to my headers:

X-Original-From: Hector Santos 
From: Hector Santos 

In order to close the loophole the rewriting has opened, in addition, 
to falsely associate my name with dmarc.ietf.org domain,  the rewriter 
needs to use a signer domain that matches the original protection.

dmarc.ietf.org is currently using::

v=DMARC1; p=none; 
rua=mailto:dmarc_agg@vali.email,mailto:dmarc-report@ietf.org

The dmarc.ietg.org policy should be, at a minimum, p=quarantine. 
dmarc.ietf.org is only used for rewriting when the submission has a 
restrictive author domain, so the dmarc.ietf.org should be restrictive.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Fri Jun 12 22:23:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070463A08D2 for ; Fri, 12 Jun 2020 22:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=dGA+IQ7/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=oueB7fyy
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 U-g6oIUUUBzt for ; Fri, 12 Jun 2020 22:22:58 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 0A5343A08CF for ; Fri, 12 Jun 2020 22:22:57 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=843; t=1592025772; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=B+W4DbpNEikbUgDFQDj3Q64BhpA=; b=dGA+IQ7/rIgx+yPjnNIoiAKmRK9zObL/4Zi+cssea5NA2o4GkDlJYqc/MbZteM F3MCnSgZQV6Ha8Plnn7NthsVXWyy76ZFI1c+1AtewaPw6brkjunvRk0N9emzavjT fsiSFagFNOxyRxgfTVP/ay0iqG0EgAaOGxUJtC+kXboTE=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:22:52 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2753077826.1.7028; Sat, 13 Jun 2020 01:22:52 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=843; t=1592025736; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fakgyT2 B3Dh+vw59kl1P9WE2xYelyQxC7aM2ZuTwCvQ=; b=oueB7fyyZBjszHs8gEHbT2e DwYNXOo0ygTNCcBOILirtkWWjzJXLq4Yrf4UdbHfFWsCfuEbGLX8ykVACrewGb9e +7Wi6lh84Ogk+L0iuCB86bVgUAc2TgAxhqzaA0f+r3spSOBNlG7/2u2ti1SkMOU2 bf9asufmkTLhyNtn99DA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:22:16 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3759432046.1.41480; Sat, 13 Jun 2020 01:22:16 -0400
Message-ID: <5EE462B3.6090505@isdg.net>
Date: Sat, 13 Jun 2020 01:22:59 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References:  <5EE461D9.5060704@isdg.net>
In-Reply-To: <5EE461D9.5060704@isdg.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 05:23:00 -0000

On 6/13/2020 1:19 AM, Hector Santos wrote:
> A DKIM Policy compliant list server simply needs to do two things:
>
> 1) Prohibit new subscribers using addresses with restrictive domains,
> just like it is done here:
>
> https://secure.winserver.com/public/code/html-subscribe?list=winserver
>
> 2) Prohibit submission from existing subscribers using addresses with
> restrictive domains. The existing subscriber becomes a read-only
> subscriber.
>
> We had very little complaints at the beginning. But the member, for is
> own domain protection, had to use another list restrictive domain to
> participate. Right now, it works this way and it works without
> complaints.

That should be "another less restrictive or non-restricted domain"

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Fri Jun 12 22:32:21 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC523A08E6 for ; Fri, 12 Jun 2020 22:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=SFeDijSr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Xsdf/wv/
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 CLzNthj3F_nV for ; Fri, 12 Jun 2020 22:32:18 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 1E56B3A08E5 for ; Fri, 12 Jun 2020 22:32:18 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=752; t=1592026333; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=gD/WEuHrO4GurHQrcbNKnijYrGo=; b=SFeDijSrYsBwJu9Ae6Qr9jloyr/LUnP7OpTPeaY5yxpvKCe+T9TKqjV1avexx+ 8M6tRPH3zw+bcajxSvRZpNoPjFPKsq54WZuLQi6sib/L+CsDQ9F9pdrtO2/p6s6v 7TveyoJXQltqZK2E7tpM2LURi3nfTTfcAR7O0PDEG5StI=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:32:13 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2753637870.1.3848; Sat, 13 Jun 2020 01:32:12 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=752; t=1592026294; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uVnIsn3 glEs6tWPkaVx7XTJ68JD+fzFaQaAnkYhTPv8=; b=Xsdf/wv/eqyPwNklXtjJyAj b+xOd/aAuIdprVyVd/49QIX5iG7Nnkv/3US+zP6pB+1gAxdUKX94RCECgKLiwu7O SyGyyHGz9Wv4lIa5EnCmZiEcKULci47wJdGV7wQ/9k/TjBVnd+w3NuysWjTG8FVx LNFGx1sn8dY+N4mjuEXg=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:31:34 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3759990031.1.40948; Sat, 13 Jun 2020 01:31:34 -0400
Message-ID: <5EE464E1.7060700@isdg.net>
Date: Sat, 13 Jun 2020 01:32:17 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <215ef4b3387e4cf79d4512dcb60c83f4@bayviewphysicians.com> <91ec8475-2a4c-03b4-4485-fc8866792a54@crash.com>
In-Reply-To: <91ec8475-2a4c-03b4-4485-fc8866792a54@crash.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 05:32:20 -0000

On 6/13/2020 12:37 AM, Steven M Jones wrote:
> On 6/2/20 5:45 PM, Douglas E. Foster wrote:
>
> And consider the fact that today mobile devices are the MUA of choice
> for many/most end users. Mobile MUAs are much less likely to show an
> rfc5322.From address field even in the message body view.

On my iPhone, All I had to do is tap the from field and it shows up.
On Tbird, I hover of the From and its shown.

I think the concern with this is a bit overblown, however, if we 
continue to do allow and accept things like Rewriting in lieu of 
simply honoring the policy, then we have open the door for "bad guy" 
do the same thing.

Honor the policy.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Fri Jun 12 22:52:34 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80013A088E for ; Fri, 12 Jun 2020 22:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=b6peSNog; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AeW4CV7Y
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 X_m2NzwKQ97l for ; Fri, 12 Jun 2020 22:52:28 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 920373A0881 for ; Fri, 12 Jun 2020 22:52:28 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1458; t=1592027538; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=JgyjYhS84LsABKReuoxNeCpeXMk=; b=b6peSNogcC9ujqp6UvepSBnADPcg29ONRBnXTfru5CbClWlwHYgkiOe9wSTk/R pRC1xD+ufpPR8CRoNLCQ5Irf02CDhmHiegRe8uhzkUfXim64c5WlE96bjCJvmFl6 ASbyPe97rJ9KPHNx5IfRi/Y7oLlp27YsSVcy4VMuvErNU=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:52:18 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2754843009.1.8052; Sat, 13 Jun 2020 01:52:17 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1458; t=1592027498; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uCcO/K2 zn3fr1rcTXghEqwJd4gOo0Mbxc458RcYv2eo=; b=AeW4CV7Yp0s539vOA74vBxU rDfggHnyNH8NcW0MSXsN4PoVZUl1nsUU8i3/B3oAqD9arX6vlTWJO987U1Z+Sufs qQVWtNzSPOA0DNRmhp6VKgW7h3BFxK46bkpwPEhhBX/8sTO3Jzspik7M1iIODQIn +1QwTWwXBgjAw8CO+NkA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 13 Jun 2020 01:51:38 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3761193093.1.41484; Sat, 13 Jun 2020 01:51:37 -0400
Message-ID: <5EE46994.1090309@isdg.net>
Date: Sat, 13 Jun 2020 01:52:20 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References:   <8a575da6-bc37-4824-9166-b68bfa430013@www.fastmail.com> <58be1989-18ab-e151-e411-47f357719d27@bluepopcorn.net>
In-Reply-To: <58be1989-18ab-e151-e411-47f357719d27@bluepopcorn.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 05:52:32 -0000

On 6/12/2020 8:02 PM, Jim Fenton wrote:
> On 6/12/20 10:49 AM, Alexey Melnikov wrote:
>
> About a year ago, I had suggested [1] that the reporting and policy
> mechanisms of DMARC be split, and was, I think, the only one supporting
> that idea.

Jim, I supported the proposal as well.

https://mailarchive.ietf.org/arch/msg/dmarc/s-UTti8Hlye6mYSMODDoYvfvKCs/

We even exchanged emails about it.

> Although you have only had a preliminary discussion, do you have in mind
> an editorial split (different functional pieces, but DMARC is still one
> thing) or an actual split into separate specifications?
>
> Someone (not sure who) said in yesterday's interim that DMARC could run
> into trouble in IETF Last Call or in IESG review because of the breakage
> to mailing lists, etc. If we had independent specifications, at least
> the reporting pieces could proceed. So I (still) support the split.
>
> [1] https://mailarchive.ietf.org/arch/msg/dmarc/HJwOvLspQKo-_GuW7W9xZPvv370/

+1, I also support the split. It worked with DKIM, separating your SSP 
Policy as a proposed standard allowing us to move forward with 
DKIM-base as a STD.  Unfortunately, ADSP was never completed and dropped.

I see the following:

DMARC-Base   proposed standard
DMARC-Reporting proposed standard
DMARC-TPA (Third Party Authorization) Experimental

Get it done.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Sat Jun 13 02:32:01 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C63A0AE1 for ; Sat, 13 Jun 2020 02:32:00 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 B-fkLE1lZU2H for ; Sat, 13 Jun 2020 02:31:58 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 8BD1B3A0ADE for ; Sat, 13 Jun 2020 02:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592040714; bh=oO6/aToNeCqyHdTo5t0r70GBl9J9OL6q2fFShd1hxsg=; l=1417; h=To:References:From:Date:In-Reply-To; b=BxFt/fwMD5HekbbdYxjhxiueQ2CgtGQVUCZNoXN9HAlabtKdtsFl7BKEd/CTil1oN GuZqbwyJ57bmVP5pWFX5reUNi0omKOTfcbATesP7IHrJtgaNAPcS0dJw5qTQHLNA9i 0juh3e9b4VC0QWfN2VLAVUks+3Bo3xnJwY83yKRsyY3U8XlVZ+8n9WrHw1vKD
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005EE49D09.00000EB5; Sat, 13 Jun 2020 11:31:53 +0200
To: dmarc@ietf.org
References: <20200613004536.1D4F01A883A1@ary.qy>
From: Alessandro Vesely 
Message-ID: <4cbf3d03-8efb-a474-1be8-46153e84a955@tana.it>
Date: Sat, 13 Jun 2020 11:31:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200613004536.1D4F01A883A1@ary.qy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 09:32:00 -0000

On Sat 13/Jun/2020 02:45:36 +0200 John Levine wrote:
> In article <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com> you write:
>> Which still leaves the question of what the value proposition is since
>> if you trust the source, what more does ARC really do (I suspect that
>> the answer is more tokens to run through your bayesian or whatever
>> filter)?
> 
> [...]
> 
> ARC lets the recipient look back and retroactively do the filtering
> the list didn't. As a concrete example, I find that it is extremely
> rare for legit mail coming into a list to be DMARC unaligned (as
> opposed to mail coming out of the list) so if you can look back at the
> ARC chain and demote mail which failed DMARC coming in, you will catch
> a lot of spam without a lot of mistakes.


Most of us keep p=none because we'd likely loose deliverability with a strict 
policy.  In particular, lists' functioning is smoother that way.  When DMARC 
takes root, non-aligned messages could be filtered inbound by the list 
themselves.  In this respect, strict policies are more effective, and we should 
consider strategies to get there.

I'd guess ARC has more arrows than just retroactive filtering.  Anyway, it 
remains a tool for very large operators.  Mailing lists cannot afford to lose 
participation by small operators.  Therefore they won't give up rewriting 
From:.  ARC doesn't help DMARC adoption.


Best
Ale
-- 


































From nobody Sat Jun 13 02:32:08 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6EB3A0B14 for ; Sat, 13 Jun 2020 02:32:02 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 h-FnajJUua7m for ; Sat, 13 Jun 2020 02:32:01 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 218E33A0ADD for ; Sat, 13 Jun 2020 02:32:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592040720; bh=W6zlOF9SF6JU5o150tz/pKRXhNge1Vj2anG6H4w3wrE=; l=2136; h=To:References:From:Date:In-Reply-To; b=CUa0OiR6t1vaFbYhByUWYXCBa13zJ9EixDe1Jvts0PoHHeTVY4kqf+4DnLq5NJlvJ fPTprNh+U2BVUJfSB++R9sFrzDY9vHG2mWJt4bSE11TJuVTNg5rbDuYEU6OO1bZ6JO 4Tls0nZumhsTKQXobj6kMzEDspzz2IoW4SYxFzbiaqbwlAE+k4q15Z7h67reb
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B6.000000005EE49D10.00000EC9; Sat, 13 Jun 2020 11:32:00 +0200
To: dmarc@ietf.org
References:  <5EE461D9.5060704@isdg.net>
From: Alessandro Vesely 
Message-ID: <8a484bad-428d-bb94-cff5-fcbdf836228b@tana.it>
Date: Sat, 13 Jun 2020 11:32:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5EE461D9.5060704@isdg.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 09:32:07 -0000

On Sat 13/Jun/2020 07:19:21 +0200 Hector Santos wrote:
> On 6/12/2020 4:02 AM, Alessandro Vesely wrote:
>>
>> *From rewriting is the real thing*
>> ==================================
>>
>> Rewriting From: is the de-facto standard.
> 
> I don't support it.
> 
>> In a (science-fictitious) scenario where all mailing lists
>> rewrite the From: header field, DMARC would just work
>> smoothly.
> 
> Occam's razor. The simplest and most honorable protocol solution is to follow 
> the specs.  DMARC will work just fine without tampering with headers if the 
> list server simply honored the restrictive policy. It works greats!!
> 
> A DKIM Policy compliant list server simply needs to do two things:
> 
> 1) Prohibit new subscribers using addresses with restrictive domains, just like 
> it is done here:
> 
> https://secure.winserver.com/public/code/html-subscribe?list=winserver
> 
> 2) Prohibit submission from existing subscribers using addresses with 
> restrictive domains. The existing subscriber becomes a read-only subscriber.


Restricting mailing list usage to domains with no DMARC policy is a hindrance 
to DMARC effectiveness.  Those mailing list cannot filter out unauthenticated 
spammers.


>> Hence, we have to specify an acceptable way to rewrite From:.
> 
> This is no acceptable way to tamper the mail in this way.  But I did suggest 
> with following. For an example of what it did to my headers:
> 
> X-Original-From: Hector Santos 
> From: Hector Santos 


Why is that unacceptable?

After all, the message comes from dmarc.ietf.org.  They are responsible for 
filtering.  The message comes from them.  You just authored it —compare with 
digest mode.

I like to see the author's name displayed in the folder view.  However, 
choosing how to rewrite should be an author's decision.

For another effect, if the list broadcasted messages maintaining the original 
From:, then isdg.net would receive an explosion of rows in the aggregate 
report, loosing the ability to match it with the mail they actually sent.


Best
Ale
-- 

























From devel2020@baptiste-carvello.net  Sat Jun 13 03:22:15 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BCC3A03F6 for ; Sat, 13 Jun 2020 03:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 Jxm7ZJYChqwq for ; Sat, 13 Jun 2020 03:22:13 -0700 (PDT)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) (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 987763A0366 for ; Sat, 13 Jun 2020 03:22:13 -0700 (PDT)
Received: from [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4] (unknown [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4]) (Authenticated sender: baptiste.carvello) by smtp2-g21.free.fr (Postfix) with ESMTPSA id B23AA200401 for ; Sat, 13 Jun 2020 12:22:07 +0200 (CEST)
To: dmarc@ietf.org
References: 
From: devel2020@baptiste-carvello.net
Message-ID: <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr>
Date: Sat, 13 Jun 2020 12:22:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr-FR
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Sat, 13 Jun 2020 05:04:01 -0700
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 10:30:41 -0000

Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or 
consensual solution. Header munging is inadequate because:

1) It makes the wrong tradeoffs. DMARC started as a solution for a very 
specific problem (phishing targetting high impact domains) and made 
tradeoffs accordingly. Now that it is deployed as a general anti-spam 
tool, the appropriate tradeoffs are different: most users are willing to 
live with some degree of spam rather than have their communication 
tampered with and their name associated with random intermediaries. 
"Fait accompli" is not acceptable, even if you call it "de-facto standard".

2) It buys you nothing. As was discussed last week, DMARC by design 
relies on the expectation that users (or their MUA's adress book) will 
recognize legitimate From addresses. If you teach users that "Joe User 
by Random Intermediary" is the same as "Joe User", this expectation is 
doomed.

Cheers,
Baptiste

Le 12/06/2020 à 10:02, Alessandro Vesely a écrit :
> Hi all,
> I'm sorry I didn't queue to talk yesterday.  After so many months without
> speaking one word of English, I really didn't feel like...
> 
> 
> *Why ARC cannot solve the mailing list problem*
> ===============================================
> 
> Assume all mailing lists in the world duly did ARC.  Somewhat
> science-fictitious, given that some of them are not even able to add valid DKIM
> signatures.  Let's hypothesize they all did ARC, anyway.  Would the mailing
> list problem be solved?  No, because recipients cannot blindly accept DMARC
> failures just because there is an ARC-chain claiming authenticity.  Doing so
> would completely defeat DMARC, because ARC chains can be forged.
> 
> In order to safely override a reject or quarantine policy based on ARC, a
> receiver needs a complete list of legitimate mailing lists.  Conversely, having
> such a list, a receiver can override DMARC failures also based on DKIM or SPF
> authentication.  ARC adds nothing to the mailing list problem.  (However, huge
> mailbox providers do have a complete list of legitimate MTAs.  That's where ARC
> is useful, AIUI.)
> 
> 
> *From rewriting is the real thing*
> ==================================
> 
> Rewriting From: is the de-facto standard.  In a (science-fictitious) scenario
> where all mailing lists rewrite the From: header field, DMARC would just work
> smoothly.
> 
> Hence, we have to specify an acceptable way to rewrite From:.
> 
> 
> I'd have said so.
> 
> Best
> Ale
> 


From btv1==433a7111340==fosterd@bayviewphysicians.com  Sat Jun 13 08:19:34 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1EA3A08D8 for ; Sat, 13 Jun 2020 08:19:34 -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 (1024-bit key) header.d=bayviewphysicians.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 D3XigvuwSsmO for ; Sat, 13 Jun 2020 08:19:32 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565963A0933 for ; Sat, 13 Jun 2020 08:19:32 -0700 (PDT)
X-ASG-Debug-ID: 1592061564-11fa313a10133ba0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 2iHintfiKApgHF3S (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 13 Jun 2020 11:19:24 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=FT61UD68+knAucSK7dmcLHvz/pMZ/WATaesTR84KCrU=; b=owOGuA9CLbvRJ7BIBkvYgd04g0A5IsQEZKS0igGgVSYbL+nZ8TWbir4mZFAjFEyfK CIdP/wa3RX6Vx8HdU66XkgFfcQeAXPHBxP8kwZCd93Wx6K+BGaSP22hwypg+phRPU +tFVJXWKt3ZgnJ/DaHzgdwlZwM/cQA/Igpgbooy1I=
From: "Douglas E. Foster" 
To: 
Date: Sat, 13 Jun 2020 15:19:15 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Reply-To: fosterd@bayviewphysicians.com
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=6d1f6bef4c5e4681b719948a3806d6c0
In-Reply-To: <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr>
References:  <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr>
X-Exim-Id: be18fcd0e41344fab50cee7d4b3a8c0c
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592061564
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 10600
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82524 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 16:09:48 -0000

This is a multipart message in MIME format.

--6d1f6bef4c5e4681b719948a3806d6c0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable



About this comment
  
         If you teach users that "Joe User by Random Intermediary" is the s=
ame as "Joe User", this expectation is doomed.

Based on the response to my previous post, "Trained User" is not a meaningf=
ul concept, for purposes of this discussion.   However, a user who subscrib=
es to a mailing list should be able to recognize its distinctive message ch=
aracteristics, so I think training is not a significant issue.   I have had=
 fun looking at the different ways that IETF mailing list entries are prese=
nted in my different MUAs.

More to the point:  

I suggest that the "Mailing List Problem" is a problem that does not need t=
o be solved (and evidence suggests that it cannot be solved.)   I can think=
 of no purpose served by a public mailing list, like this one, which is not=
 be better solved by a community forum website with user login.   Even in i=
ts heyday, I think mailing list subscribers were a narrow subset of email u=
sers, heavily skewed toward Unix-oriented technology people.   Solving the =
mailing list problem seems like saying, "I want a secure and reliable way t=
o order my Walmart groceries using the text feature of my flip-phone."  It =
is time for a different technology.

There are other indirect mail scenarios that are problematic, but these see=
m well understood and I do not see that any improvement is available.   The=
se include:
DKIM (configured at the sender), SRS Encoding (configured at the forwarder)=
, and Trusted forwarder registration or another exception mechanism (config=
ured at the recipient filter).    Incoming email filters have inadequacies =
when looking backward on a forwarded message, but this mailing list is not =
concerned with specifying the desired features of incoming mail filters.
DF

----------------------------------------
From: devel2020@baptiste-carvello.net
Sent: 6/13/20 8:04 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing li=
st problem
Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or
consensual solution. Header munging is inadequate because:

1) It makes the wrong tradeoffs. DMARC started as a solution for a very
specific problem (phishing targetting high impact domains) and made
tradeoffs accordingly. Now that it is deployed as a general anti-spam
tool, the appropriate tradeoffs are different: most users are willing to
live with some degree of spam rather than have their communication
tampered with and their name associated with random intermediaries.
"Fait accompli" is not acceptable, even if you call it "de-facto standard".

2) It buys you nothing. As was discussed last week, DMARC by design
relies on the expectation that users (or their MUA's adress book) will
recognize legitimate From addresses. If you teach users that "Joe User
by Random Intermediary" is the same as "Joe User", this expectation is
doomed.

Cheers,
Baptiste

Le 12/06/2020 =C3=A0 10:02, Alessandro Vesely a =C3=A9crit :
> Hi all,
> I'm sorry I didn't queue to talk yesterday. After so many months without
> speaking one word of English, I really didn't feel like...
>
>
> *Why ARC cannot solve the mailing list problem*
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Assume all mailing lists in the world duly did ARC. Somewhat
> science-fictitious, given that some of them are not even able to add vali=
d DKIM
> signatures. Let's hypothesize they all did ARC, anyway. Would the mailing
> list problem be solved? No, because recipients cannot blindly accept DMAR=
C
> failures just because there is an ARC-chain claiming authenticity. Doing =
so
> would completely defeat DMARC, because ARC chains can be forged.
>
> In order to safely override a reject or quarantine policy based on ARC, a
> receiver needs a complete list of legitimate mailing lists. Conversely, h=
aving
> such a list, a receiver can override DMARC failures also based on DKIM or=
 SPF
> authentication. ARC adds nothing to the mailing list problem. (However, h=
uge
> mailbox providers do have a complete list of legitimate MTAs. That's wher=
e ARC
> is useful, AIUI.)
>
>
> *From rewriting is the real thing*
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Rewriting From: is the de-facto standard. In a (science-fictitious) scena=
rio
> where all mailing lists rewrite the From: header field, DMARC would just =
work
> smoothly.
>
> Hence, we have to specify an acceptable way to rewrite From:.
>
>
> I'd have said so.
>
> Best
> Ale
>

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--6d1f6bef4c5e4681b719948a3806d6c0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable



About this comment
  
  &nbs=
p;      If you teach users that "Joe User by Random Intermed=
iary" is the same as "Joe User", this expectation is doomed.

=

Based on the response to my previous post, "Trained User" is not=
 a meaningful concept, for purposes of this discussion.   However, a u=
ser who subscribes to a mailing list should be able to recognize its distin=
ctive message characteristics, so I think training is not a significant iss=
ue.   I have had fun looking at the different ways that IETF mailing l=
ist entries are presented in my different MUAs.

Mo=
re to the point:  

I suggest that the "Mailin=
g List Problem" is a problem that does not need to be solved (and evidence =
suggests that it cannot be solved.)   I can think of no purpose served=
 by a public mailing list, like this one, which is not be better solved by =
a community forum website with user login.   Even in its heyday, I thi=
nk mailing list subscribers were a narrow subset of email users, heavily sk=
ewed toward Unix-oriented technology people.   Solving the mailing lis=
t problem seems like saying, "I want a secure and reliable way to order my =
Walmart groceries using the text feature of my flip-phone."  It is tim=
e for a different technology.

There are other indi=
rect mail scenarios that are problematic, but these seem well understood an=
d I do not see that any improvement is available.   These include:
  • DKIM (configured at the sender), 
  • SRS Encoding (conf=
igured at the forwarder), and 
  • Trusted forwarder registration =
or another exception mechanism (configured at the recipient filter).  =
  Incoming email filters have inadequacies when looking backward on a =
forwarded message, but this mailing list is not concerned with specifying t=
he desired features of incoming mail filters.
DF

<=
div>From: devel2020@baptiste-carvello.net
Sent: 6/13/20 8:04 AM
To: dmarc@ietf.org
<=
strong>Subject: Re: [dmarc-ietf] Header munging, not ARC, can solv=
e the mailing list problem
Hi,

I'=
m but a mere user, but I cannot let this be presented as an obvious or
consensual solution. Header munging is inadequate because:
=

1) It makes the wrong tradeoffs. DMARC started as a solution=
 for a very
specific problem (phishing targetting high impact dom=
ains) and made
tradeoffs accordingly. Now that it is deployed as =
a general anti-spam
tool, the appropriate tradeoffs are different=
: most users are willing to
live with some degree of spam rather =
than have their communication
tampered with and their name associ=
ated with random intermediaries.
"Fait accompli" is not acceptabl=
e, even if you call it "de-facto standard".

2) It =
buys you nothing. As was discussed last week, DMARC by design
rel=
ies on the expectation that users (or their MUA's adress book) will
recognize legitimate From addresses. If you teach users that "Joe User
by Random Intermediary" is the same as "Joe User", this expectatio=
n is
doomed.

Cheers,
Baptiste<=
/div>

Le 12/06/2020 =C3=A0 10:02, Alessandro Vesely a =
=C3=A9crit :
> Hi all,
> I'm sorry I didn't =
queue to talk yesterday. After so many months without
> speaki=
ng one word of English, I really didn't feel like...
>
>
> *Why ARC cannot solve the mailing list problem*
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>
> Assume all mailing lists in the world dul=
y did ARC. Somewhat
> science-fictitious, given that some of t=
hem are not even able to add valid DKIM
> signatures. Let's hy=
pothesize they all did ARC, anyway. Would the mailing
> list p=
roblem be solved? No, because recipients cannot blindly accept DMARC
<=
div>> failures just because there is an ARC-chain claiming authenticity.=
 Doing so
> would completely defeat DMARC, because ARC chains =
can be forged.
>
> In order to safely override a =
reject or quarantine policy based on ARC, a
> receiver needs a=
 complete list of legitimate mailing lists. Conversely, having
&g=
t; such a list, a receiver can override DMARC failures also based on DKIM o=
r SPF
> authentication. ARC adds nothing to the mailing list p=
roblem. (However, huge
> mailbox providers do have a complete =
list of legitimate MTAs. That's where ARC
> is useful, AIUI.)<=
/div>
>
>
> *From rewriting is the real th=
ing*
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
&=
gt; Rewriting From: is the de-facto standard. In a (science-fictitious) sce=
nario
> where all mailing lists rewrite the From: header field=
, DMARC would just work
> smoothly.
>
&=
gt; Hence, we have to specify an acceptable way to rewrite From:.
>
>
> I'd have said so.
>
<=
div>> Best
> Ale
>

__=
_____________________________________________
dmarc mailing list<=
/div>
dmarc@ietf.org


--6d1f6bef4c5e4681b719948a3806d6c0--


From nobody Sat Jun 13 09:28:04 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5423E3A0A39; Sat, 13 Jun 2020 09:28:02 -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, FREEMAIL_FROM=0.001, 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=gmail.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 eovLqrPJlIkB; Sat, 13 Jun 2020 09:28:00 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 AA7293A0A34; Sat, 13 Jun 2020 09:28:00 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id b18so9780828oti.1; Sat, 13 Jun 2020 09:28:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=GKxa+jbictDm8rmLu1R4woR84VIwYu9HKjVxrXkN9c8=; b=QDLe8P6rmOJ3BVmsAbWkmL/84i8LjvTSgK7pr9Tgpsv86B47MJJVCRRoXOAhBehpiw +J88gIRkHf3Q7HEe5L9Bpv8cl+Mg3KT/b3UG8jRSmOSvY1+JOf2enuCiW1xgXUxQCNwv cdnehYrYuiDpXuq0JXAjenT92VMyl7wsEExff0YbdG2M0/p6oIPzMDCn7nB6bT1BcL6C cox5j/S6M8Cb7ZY4PIQwePG+/SicveJ7W0MzGNYD/upcfB6I8S3nYlMUO96I9V/jmI1l Arm6xDNo5+zuvMGq3F/qn5mhgSD2wDCHvYK9hcWlUlgQZEA9wBzaoXdX7sD9M8X0kneB vFZQ==
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:cc; bh=GKxa+jbictDm8rmLu1R4woR84VIwYu9HKjVxrXkN9c8=; b=cU2zy8726vqQ5DNUtxvzxzGrj79cCJyv3xxgVQJIAJ6Nf/bcw1gI6L3JDqmMcEL149 XVT6pGQDmJfhc5lMqOu3bz0Eg9tqMn/3THjy7OgJ1mzb0TZmmTSrO9FlVUeHlI9tpQZ4 pa7vEDcJGFHeNcqEvsD26UK1gLT3kb5Spe6G6iu8EaxVuc3/qM9Jcib326w6y6Z/SeZI 3NnHrykYNcokv02TETBv4BcwYD44INMIJWmI019zgEhJEwKgQHZk98/lZFg4MxHOVjdS h0S52aFtRF86fhWVUnsseEDVMNCsevmUKfMKbjDQnoGLLlKh5flOvQUCM4W3dPWKmHOb Bflw==
X-Gm-Message-State: AOAM530rCQ6nMe5RGDLfcdN83u7M1pTJFGK6TxaUoxvdX0DlHk3HITBR +ae2Aw3sIOEid3wnOmLu22dgivx88f05KGCJK8K8geigzRg=
X-Google-Smtp-Source: ABdhPJyXJltEvR6cNPW3zaTIq2sulKypyxguWlHH+WI6fjW8W0OjmScx4vfQYXlDMivRdEKRH/gqqdLrBJuyo03o8VA=
X-Received: by 2002:a05:6830:4008:: with SMTP id h8mr15374817ots.158.1592065679897;  Sat, 13 Jun 2020 09:27:59 -0700 (PDT)
MIME-Version: 1.0
From: Tim Wicinski 
Date: Sat, 13 Jun 2020 12:27:48 -0400
Message-ID: 
To: IETF DMARC WG 
Cc: dmarc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004f39f705a7f9ad10"
Archived-At: 
Subject: [dmarc-ietf] Minutes from Interim uploaded
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 16:28:02 -0000

--0000000000004f39f705a7f9ad10
Content-Type: text/plain; charset="UTF-8"

All

The minutes from the Etherpad have been uploaded into the meeting
materials. You can review them here:

https://datatracker.ietf.org/doc/minutes-interim-2020-dmarc-01-202006111600/

If there are any incorrect statements please let the chairs know.
Alternatively, a pull request will also work:

https://github.com/ietf-wg-dmarc/wg-materials/blob/master/interim-2020-dmarc-01/interim-2020-dmarc-01-minutes.txt

thanks
tim

--0000000000004f39f705a7f9ad10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All
The minutes from the Etherpad have been uploaded into the=C2=A0meeting ma=
terials. You can review them here:

https://datatracker.ietf.org/doc/minut=
es-interim-2020-dmarc-01-202006111600/

If there are any incorrect statements ple=
ase let the chairs know.=C2=A0 Alternatively, a pull request will also work=
:

https://github.com/ietf-wg-dmarc/wg=
-materials/blob/master/interim-2020-dmarc-01/interim-2020-dmarc-01-minutes.=
txt

t=
hanks
tim=




--0000000000004f39f705a7f9ad10--


From nobody Sat Jun 13 09:43:05 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26CB3A0859 for ; Sat, 13 Jun 2020 09:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SxHeZP3J; dkim=pass (1536-bit key) header.d=taugh.com header.b=IxRaUiWt
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 I-cSWBne4jXd for ; Sat, 13 Jun 2020 09:43:02 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 077EA3A0853 for ; Sat, 13 Jun 2020 09:43:01 -0700 (PDT)
Received: (qmail 29220 invoked from network); 13 Jun 2020 16:42:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7221.5ee50211.k2006; bh=7nJiDg8QW/dofwktaMVrimT+cqa47e30eQ7cSRXmFMU=; b=SxHeZP3JCWIjJQ3qwXBkfXk8JBkKOJftrovlMAsm4LkVXAK92QuKYChOBraqLVbn1WD+sxPImfPgfzLhK2sgLEIOug1+gcAz3fZpGYPN8PC9Xrze5LSvtiTCTON4QhAYe31enGtnrFLjzM6MO61QoppsRk3b+6aWOl90ycinBQwN+CLUePM/eDjA8M9YiA4LQlBPZUQ86I+VhtXVhMczygTB4QakyrIZTLPaPy7tqKo/btnj3vIhR1dA5p6J66Rt
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7221.5ee50211.k2006; bh=7nJiDg8QW/dofwktaMVrimT+cqa47e30eQ7cSRXmFMU=; b=IxRaUiWtKNcXI8KYtuncGmIIORTYX3OeHCq6ygPkx+6THZR7Hke4aJcOu3SGa25mM2E0i9k9AEmoQgv4I4M6cha+SWG4De0K91u8DE5PJtmiHuysjitPt0CludJCxOavRY3lkDsODap0IhPcGfS8yCE5M/r38jDO2RZ0G3FVlanu8ex6STkM6vCp1f1GjN3/qICsAKvcLyajBizFI9Xe05S6yVCJFGwXZ2ENK8ljjkBc9kHnZJpgXGqgG6+Ur+nS
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Jun 2020 16:42:56 -0000
Received: by ary.qy (Postfix, from userid 501) id 8CF941A99AA9; Sat, 13 Jun 2020 12:42:56 -0400 (EDT)
Date: 13 Jun 2020 12:42:56 -0400
Message-Id: <20200613164256.8CF941A99AA9@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 16:43:04 -0000

In article  you write:
>I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.)   I
>can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user
>login. ...

That's OK, the rest of us can.

R's,
John


From nobody Sat Jun 13 10:39:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4F13A0ADD for ; Sat, 13 Jun 2020 10:39:30 -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 (1024-bit key) header.d=bayviewphysicians.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 WU5BivXLYMbu for ; Sat, 13 Jun 2020 10:39:29 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6037A3A0ADC for ; Sat, 13 Jun 2020 10:39:29 -0700 (PDT)
X-ASG-Debug-ID: 1592069967-11fa313a101343e0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id iEeHf3q4vIRDjmbI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 13 Jun 2020 13:39:27 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=Ysl0scWMI4p5cVV2rPbBkgYYv2JWLzvM/qD+tARaPK8=; b=js7WGlJZ1Sf98435ifVmceBPyrRFUdtVDhMvlwBEsmyS6e2d8gGyr+HgHh2kmAbYC +swV+mrwzBI4J/vpISAPNlxql913kQLn88zKzWBlMOgznimIJ1N3ZnShGUlgIVnwH vLf9JPDkhnlsjCXLO9l/LZFbdWB6WjdV3els1oeTM=
From: "Douglas E. Foster" 
To: 
Date: Sat, 13 Jun 2020 17:39:18 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <2bf78d7529ba4c5e935315d767783883@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=99c8b6af8311472eae239f88453a92c5
In-Reply-To: <20200613164256.8CF941A99AA9@ary.qy>
References: <20200613164256.8CF941A99AA9@ary.qy>
X-Exim-Id: 2bf78d7529ba4c5e935315d767783883
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592069967
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 1506
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82525 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing   list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 17:39:31 -0000

This is a multipart message in MIME format.

--99c8b6af8311472eae239f88453a92c5
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

The "mailing list problem" was introduced into this discussion as an object=
ion to DMARCs progresss, by implication suggesting that DMARC must be delay=
ed until a solution is found which creates no inconvenience to mailing list=
 operators.    

That concerns me, First, a a new solution has not really been proposed; all=
 of the discussed options are already available to mailing list operators. =
 Secondly, articulating a required mailing list operational mechanism is un=
likely to produce rapid or uniform adoption.   The supposed problem is not =
big enough to warrant that much control over this initiative.

    



--99c8b6af8311472eae239f88453a92c5
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


The "mailing list =
problem" was introduced into this discussion as an objection to DMARCs prog=
resss, by implication suggesting that DMARC must be delayed until a solutio=
n is found which creates no inconvenience to mailing list operators.  =
  

That concerns me, First, a a new solution =
has not really been proposed; all of the discussed options are already avai=
lable to mailing list operators.  Secondly, articulating a required ma=
iling list operational mechanism is unlikely to produce rapid or uniform ad=
option.   The supposed problem is not big enough to warrant that much =
control over this initiative.



<=
/div>
    



<=
/div>


--99c8b6af8311472eae239f88453a92c5--


From nobody Sat Jun 13 13:13:07 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28C23A0AB3 for ; Sat, 13 Jun 2020 13:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jDhcQq8A; dkim=pass (1536-bit key) header.d=taugh.com header.b=bjOefqK8
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 r516u3XzncXu for ; Sat, 13 Jun 2020 13:13:04 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 C1D183A0AAD for ; Sat, 13 Jun 2020 13:13:03 -0700 (PDT)
Received: (qmail 71198 invoked from network); 13 Jun 2020 20:13:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1161c.5ee5334c.k2006; bh=vfYVMxt3ZJtVoo3776S5+FOxdJbuBSFntIq2AmTHw2k=; b=jDhcQq8AN5VgKzQ1aevVZVLcHBib8G1SGWkDUjNsUEe3Yt/9Mm7TGIukt43/m/Ff0xq5HEK+JuSoTPlmWvuULSk9MEH2/orrgFsB+JkYnrdQMEjXunvAXRsS0/6JL97iWUHcjpbosTmLZ63jxZS3cRF4muoJcXCENKmMqhnhIzp+fUYH6QXUu/Kw39H+/SZukW++nvikix/Vf4A3vK3TVtd3swqfl+l/OejvNjKjfX0v7+m/NGSCFpHcjto0CJsz
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1161c.5ee5334c.k2006; bh=vfYVMxt3ZJtVoo3776S5+FOxdJbuBSFntIq2AmTHw2k=; b=bjOefqK89jLSaes0pWuYvvafZuvvcJ/mMh4AFDLkh/ZmvTZHl561keIwY633RqTAX6k6tNAnzugANIby9TIEwAGQkU19Lgq3TkC+M0sDV2o8Rk89uBfUjee354pktDhWUp2ha3w6ahgQIRnjTwahsOAVKdN4LmQRvgt9X+Ip3qF5O3DIMqs5boPDc6K8NQJyfKb4jWVm+yAuyvqN7br80HZ4Hx4yc3C6kS64GFwD2mPP74mryQAOzFTjvQ4ww/Jd
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Jun 2020 20:13:00 -0000
Received: by ary.qy (Postfix, from userid 501) id 733361A9E445; Sat, 13 Jun 2020 16:13:00 -0400 (EDT)
Date: 13 Jun 2020 16:13:00 -0400
Message-Id: <20200613201300.733361A9E445@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: <2bf78d7529ba4c5e935315d767783883@bayviewphysicians.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing   list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 20:13:06 -0000

In article <2bf78d7529ba4c5e935315d767783883@bayviewphysicians.com> you write:
>The "mailing list problem" was introduced into this discussion as an objection to DMARCs
>progresss, by implication suggesting that DMARC must be delayed until a solution is found which
>creates no inconvenience to mailing list operators.    

At this point I truly have no idea what your point is. The fact that
DMARC screws up mailing lists is enough of a problem that a lot of
people have put considerable time and money into inventing and
implementing ARC.

More than that, DMARC exists, it's deployed, it's not going to change
beyond minor tweaks to clarify unclear parts of the spec, perhaps to
deprecate minor parts that don't work the way we anticipated, and
perhaps minor additions like https reporting.

In particular, there is no chance whatsoever that any DMARC policy
will become mandatory, because the IETF doesn't do mandatory. The word
MUST only means "do this to interoperate with other systems", not do
this or else.

R's,
John


From nobody Sat Jun 13 13:46:57 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5D3A07C3 for ; Sat, 13 Jun 2020 13:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsCDi8Mo3d74 for ; Sat, 13 Jun 2020 13:46:55 -0700 (PDT)
Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 649183A07C2 for ; Sat, 13 Jun 2020 13:46:55 -0700 (PDT)
Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 1FB9B7FB0B for ; Sat, 13 Jun 2020 20:46:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=589; q=dns/txt; s=default; t=1592081214; h=from : subject : date : to; bh=z4jmyQawOHL9uhZ5QzPyEAf3tscaWe3rokWH3y7ex00=; b=l+kMUuDt8ZWRiFhDkO/5TfEXicvLdX1m9hAv7BoxdkoiatQi3lrhWf5gqGRVqtcpq1KZG /3ygKnqSi69wVNL9C6teRGQvRj4DaUkYovvKw2q2PXcNNsiDCqxTUDOu1Jh+vpgnsiQ8Iyd tpKhM776h0rHBh4KzZLmXfeX0G5WTJY=
Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 00F147FA34 for ; Sat, 13 Jun 2020 20:46:53 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 13 Jun 2020 22:46:53 +0200
From: Benny Pedersen 
To: dmarc@ietf.org
In-Reply-To: <20200613164256.8CF941A99AA9@ary.qy>
References: <20200613164256.8CF941A99AA9@ary.qy>
User-Agent: Roundcube Webmail/1.4.4
Message-ID: 
X-Sender: me@junc.eu
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 20:46:56 -0000

On 2020-06-13 18:42, John Levine wrote:
> In article  you 
> write:
>> I suggest that the "Mailing List Problem" is a problem that does not 
>> need to be solved (and evidence suggests that it cannot be solved.)   
>> I
>> can think of no purpose served by a public mailing list, like this 
>> one, which is not be better solved by a community forum website with 
>> user
>> login. ...
> 
> That's OK, the rest of us can.

if no one breaked dkim then arc would not even be needed

IMHO ietf is gone to far of fixing problems


From nobody Sat Jun 13 13:56:10 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05693A07FC for ; Sat, 13 Jun 2020 13:56:08 -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_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 111gMAPbka3y for ; Sat, 13 Jun 2020 13:56:08 -0700 (PDT)
Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 D20D43A07F9 for ; Sat, 13 Jun 2020 13:56:07 -0700 (PDT)
Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id E95D97FB13 for ; Sat, 13 Jun 2020 20:56:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=1045; q=dns/txt; s=default; t=1592081766; h=from : subject : date : to; bh=4IspuNVZIMqtJtOIzptKq1RQKCECPDIpJTaU36BfRT4=; b=OwDVzcWtjwB4AcHlMi7Xd3J47u+xahR4mVpf0AoamzH+lusEePdUccumUg/emSvs+hF5P teNqq4nLih9dGJwgBl0Vqfc4VbKpZrr9fJQpdqXcuG+71gujtwzWiPX0OFxAHuJimwvsGbT DvilT1O8V+xI3a1pQ+LI5YsVNsCsYZk=
Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id C9FC97FB0F for ; Sat, 13 Jun 2020 20:56:06 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 13 Jun 2020 22:56:06 +0200
From: Benny Pedersen 
To: dmarc@ietf.org
In-Reply-To: <20200613201300.733361A9E445@ary.qy>
References: <20200613201300.733361A9E445@ary.qy>
User-Agent: Roundcube Webmail/1.4.4
Message-ID: <2f5c19333cff74f0fe245aba992241c8@junc.eu>
X-Sender: me@junc.eu
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing   list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Jun 2020 20:56:09 -0000

On 2020-06-13 22:13, John Levine wrote:
> In article <2bf78d7529ba4c5e935315d767783883@bayviewphysicians.com> you 
> write:
>> The "mailing list problem" was introduced into this discussion as an 
>> objection to DMARCs
>> progress, by implication suggesting that DMARC must be delayed until a 
>> solution is found which
>> creates no inconvenience to mailing list operators.
> 
> At this point I truly have no idea what your point is. The fact that
> DMARC screws up mailing lists is enough of a problem that a lot of
> people have put considerable time and money into inventing and
> implementing ARC.

even if ietf tribble dkim sign mails it still gives

X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on 
localhost.junc.eu
X-Spam-Status: No, score=-9.3, required=5.0, Autolearn=unavailable
	autolearn_force=no, LastExt=4.31.198.44
X-Spam-Rules_score: DKIM_INVALID=0.1,DKIM_SIGNED=-0.1,
	HEADER_FROM_DIFFERENT_DOMAINS=0.25,LOCAL_WHITELIST_URI=-0.5,
	MAILING_LIST_MULTI=-10.1,SPF_HELO_NONE=1.1,SPF_PASS=-0.1

hmm


From nobody Sat Jun 13 19:53:56 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A363A09B8 for ; Sat, 13 Jun 2020 19:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 LPR7_NsuF9pg for ; Sat, 13 Jun 2020 19:53:53 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 A010B3A09B5 for ; Sat, 13 Jun 2020 19:53:53 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:d33:c3e8:ef46:e74b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05E2rpMd008612 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 13 Jun 2020 19:53:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592103233; bh=ESrSfcGdBflD5MDqVU4Dopp75ZkzXtq0ZFn2vjrqP1k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q2wrgDmogugQgshRHZK5IgXys5xPA3uZrC8Ywrhx9FxqGt3Enc4YAIPIqCNavJ/2I zlVn0oMd+m7k/jFKx6w7/RnTehrJoHehqV2NbkTWVd/XsHwIBnQONp7cLJ/7aliZEo QOpc6uq/JJj93sT9qFvwMgUHyx6cYzKIDos1gnZE=
To: dmarc@ietf.org
References: <20200613201300.733361A9E445@ary.qy>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: 
Date: Sat, 13 Jun 2020 19:53:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200613201300.733361A9E445@ary.qy>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 02:53:55 -0000

On 6/13/20 1:13 PM, John Levine wrote:
> In particular, there is no chance whatsoever that any DMARC policy
> will become mandatory, because the IETF doesn't do mandatory.=20

Alas, others do, apparently because they see that DMARC has an RFC
number (even though it's informational). For example, in
https://cyber.dhs.gov/bod/18-01/ :

"All agencies are required to...enhance email security by...Within one
year after issuance of this directive, setting a DMARC policy of
=E2=80=9Creject=E2=80=9D for all second-level domains and mail-sending ho=
sts."



From nobody Sat Jun 13 20:18:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A303A09D2 for ; Sat, 13 Jun 2020 20:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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=gmail.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 7s0ObAtBHcMV for ; Sat, 13 Jun 2020 20:17:59 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 BD56C3A09D1 for ; Sat, 13 Jun 2020 20:17:59 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id bh7so5379427plb.11 for ; Sat, 13 Jun 2020 20:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FE83+fEdrU1DA0focgk9g8YqFdcsvug/4K4UdEEaFL4=; b=EJjKas0w9/qFK6+Es4A+7/P3qy/ypxzv1O1BA61t658lKADFwLgINkA4JNHncSf9LX qEVXuFeq45FtxoymfJKMo1BkgrGu3XQkb38uSpDJC/pg+8MWEEjU4x1Vl5a9+FruZpQG Z/8ZzRrFtvRsmF/nxOrHW5+9LntylIx1BOGt/uKzx7ELphgCdWkj/27OYQ1TRA/S/f6J Q5TCqsnfSKFX9Z74+Sa0Fz6rZTOIJrLG+hUQy+NxGrbRZsf2Ol0Uunbya2OeKfek/M3s SS3U44QIfNIslz6aJGwWqA+qXhVhRMWt0B6IZ2CHCfrR43rEwNlwGbcHvdqzjKqScM2H a0Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FE83+fEdrU1DA0focgk9g8YqFdcsvug/4K4UdEEaFL4=; b=Z0FwV2cgVdrbQ/vFu7mKA3q1kSDZrq5lCImZaOHp+ygmEIWit30pFmXxmJqzFSEztH BjISAeGbc4aLmpAEpjn80ck5TmZcaiGDUPS2LuC3aiYyT8al8IZvwOqFCovewmSPi2zr bVEarHfqBkM2pz5AR5fESSiFjQPt0bXeToErIeJWj4h8b9wEwOg8zPtTJUOXFlYztjfs bYZyG+/pJzizeSAii/GcR/3NG8vwbnU7KKGrWjdvu9NPkVhE5XET82kilvw4ku6Ul3cm Gg4NpAwX01ZQVjhWTjBjYQJyibxR6LLePP37Wo4fyVAvubc2avRwNMwIjDFn2VjT2pdT wLsg==
X-Gm-Message-State: AOAM533Frumc08eaELae3CooeaFlmBHM+JzV7LgZ1yvMd9uxN3mrBXUe sIcWJrxUfnRROt6k+MOVZ2qMd0SR
X-Google-Smtp-Source: ABdhPJzGvkGsReLO5QSB7HTZLElMgEiL8PiTVxN1czGAHz1T/1RjBbGzncgftFTWEIpMDZrUgzmQGA==
X-Received: by 2002:a17:902:8f83:: with SMTP id z3mr16683314plo.203.1592104678890;  Sat, 13 Jun 2020 20:17:58 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a417:10ec:9fb0:8b82? ([2600:1700:a3a0:4c80:a417:10ec:9fb0:8b82]) by smtp.gmail.com with ESMTPSA id d67sm10198004pfc.63.2020.06.13.20.17.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Jun 2020 20:17:58 -0700 (PDT)
To: Jim Fenton 
References: <20200613201300.733361A9E445@ary.qy> 
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com>
Date: Sat, 13 Jun 2020 20:17:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 03:18:01 -0000

On 6/13/2020 7:53 PM, Jim Fenton wrote:
> Alas, others do,

Other groups do all sorts of things.  They once mandated OSI, for example.

Please explain how that is relevant, here and now.

Are you perhaps suggesting that the technical work of the IETF should 
worry less about technical quality and more about possible use/abuse by 
other agencies?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Sat Jun 13 22:16:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722743A0AA1 for ; Sat, 13 Jun 2020 22:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=FkqJ9UnE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=U/JXV5Dw
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 LsW9cD5Q1Bq2 for ; Sat, 13 Jun 2020 22:16:25 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 9705D3A0AA0 for ; Sat, 13 Jun 2020 22:16:25 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=630; t=1592111780; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Mt2lR/4Y0XXD3/nVFmmEED5kJcA=; b=FkqJ9UnEaJnZayOTuynAH3z6pNmw0CwkXS6V7EblcbdZpChkLnha/Nl/8zmj/n UkuddwT9249LHg8C85SbvRVPoPGd57DJ2Ku61dsxznQ4EiSv4JZD0AILAqCueKEG jYT+h3hggIlItr4IvFtERpxFtb+mPzXxiE/hLHvn+etXg=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 14 Jun 2020 01:16:20 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2839083939.1.5740; Sun, 14 Jun 2020 01:16:19 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=630; t=1592111737; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=SCGrjDF 7hviLey3cdJc7osfSJ5Lev1uSS0aVCvXSXjw=; b=U/JXV5DwFQ960R47chzdlZl 1ukqvuifXgfBXXau/NFblxa+k9YWWxfye56llhlUXF3p3WFdqfrbmatmxeR2MBXe mwecXrydGMyB9pZCRUaZRopwL/nL+bb3k4L2v5Ki92Lz7wskIsjWVgbz/rTYKkD0 +n66nE3r5UD8oh+SWzUU=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 14 Jun 2020 01:15:37 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3845431828.1.43444; Sun, 14 Jun 2020 01:15:35 -0400
Message-ID: <5EE5B29B.3020001@isdg.net>
Date: Sun, 14 Jun 2020 01:16:11 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200613201300.733361A9E445@ary.qy>  <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com>
In-Reply-To: <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 05:16:27 -0000

On 6/13/2020 11:17 PM, Dave Crocker replied to Jim Fenton wrote:
>
> Are you perhaps suggesting that the technical work of the IETF should
> worry less about technical quality and more about possible use/abuse
> by other agencies?

Dave,

It didn't look good when the IETF officially abandoned the ADSP 
protocol citing technical quality issues, yet helped a special 
interest group reintroduce "Super ADSP" under a different name with 
the same exact technical quality issues and fast tracked it as an 
informational RFC proposal.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Sun Jun 14 07:09:06 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05623A0D09 for ; Sun, 14 Jun 2020 02:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 rkkzA4Shzw3K for ; Sun, 14 Jun 2020 02:24:49 -0700 (PDT)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (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 402883A0D07 for ; Sun, 14 Jun 2020 02:24:48 -0700 (PDT)
Received: from [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4] (unknown [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4]) (Authenticated sender: baptiste.carvello) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 0FD562003CE for ; Sun, 14 Jun 2020 11:24:42 +0200 (CEST)
To: dmarc@ietf.org
References:  <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr> 
From: devel2020@baptiste-carvello.net
Message-ID: 
Date: Sun, 14 Jun 2020 11:24:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr-FR
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Sun, 14 Jun 2020 07:09:06 -0700
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 09:24:51 -0000

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
> About this comment
>  
>     If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed.
>
> Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this 
> discussion [...]

That's not my point. My point is: this working group needs to make a 
determination whether From addresses being displayed to the users 
matters to DMARC or not, and then follow up consistently.

If it is, then don't break From addresses with munging.

If it is not, then use Sender field as a fallback for alignment, and 
don't break From either.

> [...] > I suggest that the "Mailing List Problem" is a problem that does not 
need to be solved (and evidence suggests that it> cannot be solved.)   I 
can think of no purpose served by a public mailing list, like this one, 
which is not be better > solved by a community forum website with user 
login.

Thanks for you honesty. Then the relevant question is whether open and 
interoperable standards still matter, or if they should be replaced by 
proprietary web apps one feature at a time.

Cheers,
Baptiste


From nobody Sun Jun 14 10:07:52 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF503A0812 for ; Sun, 14 Jun 2020 10:07:50 -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 (1024-bit key) header.d=drkurt.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 P4SuBdPdpojp for ; Sun, 14 Jun 2020 10:07:49 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 6815A3A0811 for ; Sun, 14 Jun 2020 10:07:49 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id c8so15370983iob.6 for ; Sun, 14 Jun 2020 10:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AdIshWFzkYPAtwyYPyamHIj0w8dJwx8PWC1wzpOs3Tc=; b=ZT+I/P9Xr780W1ihzVL5xJi+zjx50uFGY4+s1rAOo0jldT5a8/F2cyHScUJVg29PnH L7ZdoLlehhVh/Byoxtm0Bekrp7tijnubwB/FZwG0t986hSofUDS/BiWxWa8nC9HeY8Vz 32irRNYYnpvt+5PxplYR++AUa7XtPCG7AA1s4=
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=AdIshWFzkYPAtwyYPyamHIj0w8dJwx8PWC1wzpOs3Tc=; b=b73KIIzbnCy1ZPijeoG0kS5zJlfmViUuROdHiljHcH7t0qgWhBI+Ie8NQN7dA5hy02 cFqMkXEhYwg+2NoJ06asfsjoG/Agx4YFgxla6tIAtNXnTrIeBe60IHjOZUXh3rcfpdoo ZVR0oSsAnCJy3K/i1DBYC7rSLlp1Y0AJAa9/pXjaMJui9XeC4g8wkJfAndQdTDh4ZK6y 3KLG7oe5eGGtqPhJbKIp8v3LcQ4ne3KE6bZJNhaXgDbVmkNr6wgd7i+dhRsfFjvoIFPA WdpyoNLsQODqAGxPLCJfs7w2MV0xQsxbNNRFicZgLEGpQwnUBBmcyLu88B4+uLJGd05e +M3w==
X-Gm-Message-State: AOAM530kU2jL/3AYDUC68VWJcBdWFGtsIWLoyA7bFjuMGZIEgENFiHX/ e2/59u9Q40FJ+hkFUG4nfW5byGGYcDtSJxSmbCeIbg==
X-Google-Smtp-Source: ABdhPJy5x00ofC/6vJQnTWVST9xLlA3XnVB64z74lvYtSK5yWyiJiC8bHaZ+UJYsnvwr5jOKbFtCF99G8Oln/H4v3g4=
X-Received: by 2002:a05:6602:2fcb:: with SMTP id v11mr23952625iow.121.1592154468583;  Sun, 14 Jun 2020 10:07:48 -0700 (PDT)
MIME-Version: 1.0
References:   <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com>
In-Reply-To: <45AF2D9B-A2D9-4D5C-B1FD-AAE906D3A8A3@kitterman.com>
From: "Kurt Andersen (b)" 
Date: Sun, 14 Jun 2020 10:07:37 -0700
Message-ID: 
To: Scott Kitterman 
Cc: "dmarc@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000087211f05a80e59fa"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 17:07:51 -0000

--00000000000087211f05a80e59fa
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman 
wrote:

>
> On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" 
> wrote:
> >I would like to understand what you mean by:
> >
> >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
> >wrote:
> >
> >> . . . ARC chains can be forged.
>
> Not sure what is confusing about that.  There's no requirement that
> signatures from previous hops still verify, so anyone can build an ARC
> chain that claims they got something from an arbitrary source.  ARC is only
> usable if you know you trust the source.
>

Perhaps we are debating semantics here, but a wholesale replacement of the
message content within the bounds of an ARC-chain-span is not what I would
call "forgery". One can not simply "build an ARC chain" because each
ARC-Seal header is cryptographically created by the entities which control
the respective private keys.

Trust matters, but really has nothing to do with the interoperability or
validity of the chain itself.

--Kurt

--00000000000087211f05a80e59fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Jun 12, 2020 at 5:06 PM Scott Kit=
terman <sklist@kitterman.com=
> wrote:


On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> wro=
te:

>I would like to understand what you mean by:

>

>On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely <vesely@tana.it>

>wrote:

>

>> . . . ARC chains can be forged.



Not sure what is confusing about that.=C2=A0 There's no requirement tha=
t signatures from previous hops still verify, so anyone can build an ARC ch=
ain that claims they got something from an arbitrary source.=C2=A0 ARC is o=
nly usable if you know you trust the source.

Perhaps we are debating semantics here, but a wholesale replacement o=
f the message content within the bounds of an ARC-chain-span is not what I =
would call "forgery". One can not simply "build an ARC chain=
" because each ARC-Seal header is cryptographically created by the ent=
ities which control the respective private keys.=C2=A0

=

Trust matters, but really has nothing to do with the interoperability =
or validity of the chain itself.

--Kurt=C2=A0


--00000000000087211f05a80e59fa--


From nobody Sun Jun 14 10:18:49 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAC63A081C for ; Sun, 14 Jun 2020 10:18:47 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=fcgn+USb; dkim=pass (2048-bit key) header.d=kitterman.com header.b=I1SEi8yr
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 ylCp1sEN487R for ; Sun, 14 Jun 2020 10:18:46 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0716D3A0818 for ; Sun, 14 Jun 2020 10:18:45 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 4A742F80211 for ; Sun, 14 Jun 2020 13:18:44 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1592155124; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=M8bvRKOfvgIXsuKK+mJCSp8kDDKSPfn+q/qNMJDLhgg=; b=fcgn+USbtIg1cJV+870RaI5M3nXSlPI7q9HB2GwVkkfpIPpw84kbjHDOBrxvTOZrnRUAh wp0ubrr3wVxJOp6DA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1592155124; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=M8bvRKOfvgIXsuKK+mJCSp8kDDKSPfn+q/qNMJDLhgg=; b=I1SEi8yrONreJs950fhylds23Cs2UAK9Og/EyrHR5RlzQ6LCW4lGLWGltvsMxVFjs3tKT M8rrORZx9KPGImIYvlrz0tfyIYwLKDhshW59JL0KSBYUWV+2VVPfOyCQsN9D9nsH96SXahP 1tlfrROTFFEZ1nC0JpWMnCYBwSt1zLqD4I/31yOQR0YQlVkZDA/INdy/4CkJWeR4vVYWDSm YHb5Duo/N+HzCIWsiCSAHyVzxvH17E6qEcu8qMdU0C+vNQmg0kXfTZWJV9Ml5U9FD+QIDCY +A3LkW6YfuxxauBSgAekx4/LINQHf0PfgnfOGxy39qG2tmLxSnwGUWTH0T3A==
Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 0F30CF800A8 for ; Sun, 14 Jun 2020 13:18:44 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Sun, 14 Jun 2020 13:18:43 -0400
Message-ID: <6370085.sLrAyzsJJq@sk-desktop>
In-Reply-To: 
References:   
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 17:18:48 -0000

On Sunday, June 14, 2020 5:24:42 AM EDT devel2020@baptiste-carvello.net wro=
te:
> Le 13/06/2020 =E0 17:19, Douglas E. Foster a =E9crit :
> > About this comment
> >=20
> >     If you teach users that "Joe User by Random Intermediary" is the sa=
me
> >     as "Joe User", this expectation is doomed.>=20
> > Based on the response to my previous post, "Trained User" is not a
> > meaningful concept, for purposes of this discussion [...]
>=20
> That's not my point. My point is: this working group needs to make a
> determination whether From addresses being displayed to the users
> matters to DMARC or not, and then follow up consistently.
>=20
> If it is, then don't break From addresses with munging.
>=20
> If it is not, then use Sender field as a fallback for alignment, and
> don't break From either.

I don't think that's the question at all.

Whether user's knowledge of the from address has any bearing on anti-abuse=
=20
methods or not, it has plenty of value for other purposes.  DMARC is not al=
l=20
of email.

=46rom rewriting is a gross hack that exists only due to dire necessity.  I=
f=20
this working group can't move the space towards a more usable solution, I'm=
=20
not at all sure DMARCbis is worth the trouble.

Scott K




From nobody Sun Jun 14 10:23:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237FB3A081F for ; Sun, 14 Jun 2020 10:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=FUy9mh1o; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=rk55W1Gn
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 9ISkK7Z4lwNT for ; Sun, 14 Jun 2020 10:23:39 -0700 (PDT)
Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (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 0EFEA3A081D for ; Sun, 14 Jun 2020 10:23:38 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3630; t=1592155416; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Q96AXKF8UsAk/a60uidozy+ZXAo=; b=FUy9mh1oe0GAgsmvZphbF1heXGNWYQ7SDlpKbzX8309j/nlq4EzYg/WXnY5OIh O99qmaLzkuPj4ehY9cLtwfSw4oI68eo6ic1PECBhBa+7kCK90OfmvDyGN+Dlkbpx QesJhLa24yaPFcSDFMMGLoueiv3+jgtW0rnVu6a9bnaqc=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 14 Jun 2020 13:23:36 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2882719197.1.5088; Sun, 14 Jun 2020 13:23:35 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3630; t=1592155372; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Yc7WID9 Slp7KiadFEmLVc5m6wllgk7DjAwDL9H6pMSQ=; b=rk55W1Gn21tTO43HPCSD5rb xsJ0L2YgcnBBgYU6o8MK75/mxAhrZtSquPpg2AJbLneBuJ6/tynSY+pIMcIZ4Iot TAPqbNfPQmRqwTArP6dc/BtZKHr8WZpv8B/+foG+DGjtcI4OHG+r+BWrP5N3CuwU KnotnDI6wpzXKJ+jJjdI=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 14 Jun 2020 13:22:52 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3889067859.1.43484; Sun, 14 Jun 2020 13:22:51 -0400
Message-ID: <5EE65D11.3050107@isdg.net>
Date: Sun, 14 Jun 2020 13:23:29 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: "dmarc@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 17:23:41 -0000

When we look at DKIM and the DMARC protocol by exposing the boundary 
conditions of the protocol, it helps with laying the groundwork for a 
protocol-complete model.

DKIM has three possible signature states:

- NONE (no valid signature)
- 1PS (1st party valid signature, Author.domain == Signer.domain)
- 3PS (3rd party valid signature, Author.domain != Signer.domain)

DMARC has three polices:

- none
- quarantine
- reject

With these 3x3=9 states, the following table with the boundary 
conditions of the protocol is established with the expected and 
potential actionable result:

                         DMARC POLICY
      +===================================================+
      |////// | p=NONE     | p=QUARANTINE  | p=REJECT     |
      |===================================================|
   D  | NONE  | fail-pass  | fail-filter   | fail-reject  |
   K  |-------+------------+------------------------------|
   I  | 1PS   | pass       | pass          | pass         |
   M  |-------+------------+------------------------------|
      | 3PS   | fail-pass  | fail-filter   | fail-reject  |
      +===================================================+

Note: I intentionally left out SPF conditions for NONE, NEUTRAL, 
SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states. 
  For this exercise, we are assuming DMARC/SPF alignment is in play 
and failure can be for any DMARC known reason including the 3PS failed 
states.

The states for DKIM none and 1PS are expected protocol conditions. 
DMARC describes these conditions. But the DKIM 3PS conditions are not 
described and are subject to questionable actions because of the 
possible false positives results.

The 3PS failures occur because of the dearth for an Authorized Third 
party Signature protocol.  DMARC does not offer 3rd party signature 
solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But 
they did not restrict an ADD-ON extension to the protocol.

ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and 
when DMARC replaced ADSP, it equally applies to DMARC as well as an 
extension.  We do not need to get into the specific ATPS protocol 
details on how to authorize a 3rd party signer. Any "ATPS-like" 
protocol will only need to answer one question:

   Is the 3rd party (re)signer authorized?   Yes or NO

With this consideration, the table has one additional 3PS-AUTH row 
meaning Yes, the 3rd party (re)signer domain was authorized by the 
author domain.


                    DMARC POLICY W/ ATPS
      +======================================================+
      |//////    | p=NONE     | p=QUARANTINE  | p=REJECT     |
      |======================================================|
   D  | NONE     | fail-pass  | fail-filter   | fail-reject  |
   K  |----------+------------+------------------------------|
   I  | 1PS      | pass       | pass          | pass         |
   M  |----------+------------+------------------------------|
      | 3PS      | fail-pass  | fail-filter   | fail-reject  |
      |----------+------------+------------------------------|
      | 3PS-AUTH | pass       | pass          | pass         |
      +======================================================+

Overall, as it was originally conceived, the DKIM Policy model can not 
ignore ATPS conditions because as you can see above, it would not be 
protocol-complete -- it is missing the 3PS-AUTH conditions.

While ADSP is a specific RFC proposed protocol, I am using it as an 
acronym for any authorizing third party signature concept:

    Result = DKIM_ATPS(author.domain, signer.domain)

Lets finish that part of the DKIM model.

Thanks

[1] https://tools.ietf.orgy/html/rfc5617
[2] https://tools.ietf.org/html/rfc6541

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos





From nobody Sun Jun 14 10:25:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832363A081F for ; Sun, 14 Jun 2020 10:25:30 -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 (1024-bit key) header.d=drkurt.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 z_t5WqY4wnXd for ; Sun, 14 Jun 2020 10:25:29 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 434D13A081D for ; Sun, 14 Jun 2020 10:25:29 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id r77so15384740ior.3 for ; Sun, 14 Jun 2020 10:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uox+nZf9xdmgjRyLVGVoQ8Lj4Y8qaPGZsVYMD8tELl8=; b=VZvaXbx2DSDATL/tOG9h/CFO1mN4dCDc9w7ZfbyS+dIjVolE1+NJCOyVuSCeTsjVCx QCvu5ht0qUI/kMQvyoFjTrkEyrAdecOYR5whFbPPIndmZoYefXRuvXiaT7aOm7gmdszv 9sXA2Jzo3ZvIQDunO2tkNhWy308MVGdNUmIeE=
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=uox+nZf9xdmgjRyLVGVoQ8Lj4Y8qaPGZsVYMD8tELl8=; b=Dmi0UDtHcoyZxtoaN3EgkU1/jYaWHcYlkErnHvp/B9eUA8zPx1mBGAe3ZCVZpPMBuE Cz365MG6/cZLrBJbs46NeXQfOgZVf7+SkopC3/oucnc7s89j9JvKANFzBwzFS/dTX6D9 5ltC776ZxVwj8ttZCrfpgRTqHJX0OMf/82ejBMtiLWX/vuQnxMD+rmwyXYFdVRD5XjPB 1oHAc6bPs06qwrzD8Yz+3tgHUndAOqO5sbwzCfN/j/VFGhrU/p4f9Pb4mOlNawv0RG8X nNR/o17G3kU3ArWQizpG3yQn0a/hr+TtBh5IfGCGieCgETm7YlpNaT9L/KQewIKg19lq Zc6A==
X-Gm-Message-State: AOAM533cGF9CNMTad6YH5IA7zf0yROgziCo+uWyZD/+NZ2MbUiIgeCMk ZgnwroU3pNXkVCjSASuyV7X0wNffNsQ6w0bgfoJL0HGM
X-Google-Smtp-Source: ABdhPJw1ARv5/i58yA7UTYkk9mp99cnbCNg+lssU1U4fuuSAXYi3l+E2bS6mkpydxtIQ56lpvGq0SpCFUheAYTpvrkw=
X-Received: by 2002:a05:6602:2fcb:: with SMTP id v11mr24018159iow.121.1592155528367;  Sun, 14 Jun 2020 10:25:28 -0700 (PDT)
MIME-Version: 1.0
References: <20200613004536.1D4F01A883A1@ary.qy> <91cfbb70-caff-863b-15b0-61785227e13d@gmail.com>
In-Reply-To: <91cfbb70-caff-863b-15b0-61785227e13d@gmail.com>
From: "Kurt Andersen (b)" 
Date: Sun, 14 Jun 2020 10:25:17 -0700
Message-ID: 
To: Dave Crocker 
Cc: "dmarc@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b220b605a80e9879"
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 17:25:31 -0000

--000000000000b220b605a80e9879
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker  wrote:

>
> > ARC lets the recipient look back and retroactively do the filtering
> > the list didn't.
>
> The concern about the creator of an ARC chain spoofing the purported
> origin of a message is valid.
>

By "creator" do you mean "initiator" (aka, the source of the first ARC set,
i=1)?

In general ARC chains are the product of a series of co-creators through
the handling sequence for the message, so I think that "creator" in a
singular sense is a little misleading.

--Kurt

--000000000000b220b605a80e9879
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Jun 12, 2020 at 5:52 PM Dave Croc=
ker <dcrocker@gmail.com> wr=
ote:


> ARC lets the recipient look back and retroactively do the filtering
> the list didn't.



The concern about the creator of an ARC chain spoofing the purported 

origin of a message is valid.=C2=A0=C2=A0

By "creator" do you mean "initiator" (aka, the sourc=
e of the first ARC set, i=3D1)?=C2=A0

In general A=
RC chains are the product of a series of co-creators through the handling s=
equence for the message, so I think that "creator" in a singular =
sense is a little misleading.

--Kurt=C2=A0


--000000000000b220b605a80e9879--


From nobody Sun Jun 14 10:47:58 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F923A0064 for ; Sun, 14 Jun 2020 10:47:57 -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, FREEMAIL_FROM=0.001, 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=gmail.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 ctgLeonsXfji for ; Sun, 14 Jun 2020 10:47:56 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 462733A0062 for ; Sun, 14 Jun 2020 10:47:56 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id k15so11337484otp.8 for ; Sun, 14 Jun 2020 10:47:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=QOKH7tLZtJxo56wHRKQmImxtbFsdSVps1ceOu+fT0is=; b=hCefLtvYvUlhLyH6QN9o5Gh6+RCCyX2f+ZAI6bU830bhiz6e22B7n8Ps6tjP3DpDOh 5E2boSKNY/ynT8jibfPAatC2rOyQci6U0/oTb0gR4RlOENOwno9cm+wDy3n7DvP6U2QH uEffQONV3IKVFsq9QjDtY9TfS86Qu7zjS/mJ8EXrylBbuVrdvyAudmSeLtK3AvO28YWE vf9jzPT79zfPYlD/699bmjQ5851MmolINYev9smNDPc6Slg5+kfw8fGBqAokTsK4zN/F 4wLX0INbsHj99GAoiAnyV/RpHk1HCgz0XOgYMtY8QF72+f3DvavQ9DgRInm+7+edouqN EHCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QOKH7tLZtJxo56wHRKQmImxtbFsdSVps1ceOu+fT0is=; b=Ta3vMxmsH9QluxhhvTVfkTrGeC54z1gr6/dkxD6sTUc3gqKC0lqaWvPPVarhC3M0bc enywk7i+JdsqQ2mG7hT7FnvflbumUTl2elj2/4ThIbXwVexBnnVYI5+kWr7ZpwLD7EAx cQCsqCdEo5NUyPbGundHH3k1/0gPgx9KxXnyxeVhCbeZ6DbrudBSn4yFNPGmyKvalO4y SlrqleTrhOPMa7V9BBXKiysWOm95VUJHoCv92UIoBAuJTfUIxW9iT+OK3PhtozQfWF5N ZIiFJdV0snJPl1j6ftXmmwjkiOamooaGqS/Qb/fzW9j1HlBBzZwdtxG2DK+1yg2wWxEx EkFw==
X-Gm-Message-State: AOAM533MeHsxrwLsJ0saVMHFEeDxjPCtcnELyyq/YNP9m90vpXeOAqBi OOUQQiERp3tFgy76ZoqjYAgr43vz
X-Google-Smtp-Source: ABdhPJzs4A3dGs9Z9/IeX91sHVYAo32TYuGCxJjQykBRCQ0cxQttVnGtVttr9qaht32q2CxP78d4uw==
X-Received: by 2002:a9d:6f12:: with SMTP id n18mr19863910otq.100.1592156875251;  Sun, 14 Jun 2020 10:47:55 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:ad03:f15c:2e58:3cfe? ([2600:1700:a3a0:4c80:ad03:f15c:2e58:3cfe]) by smtp.gmail.com with ESMTPSA id r10sm2393714ooh.20.2020.06.14.10.47.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2020 10:47:54 -0700 (PDT)
To: "Kurt Andersen (b)" 
Cc: "dmarc@ietf.org" 
References: <20200613004536.1D4F01A883A1@ary.qy> <91cfbb70-caff-863b-15b0-61785227e13d@gmail.com> 
From: Dave Crocker 
Message-ID: 
Date: Sun, 14 Jun 2020 10:47:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FCEB176882E43C8F474EE864"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 17:47:57 -0000

This is a multi-part message in MIME format.
--------------FCEB176882E43C8F474EE864
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/14/2020 10:25 AM, Kurt Andersen (b) wrote:
> On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker  > wrote:
>
>
>     > ARC lets the recipient look back and retroactively do the filtering
>     > the list didn't.
>
>     The concern about the creator of an ARC chain spoofing the purported
>     origin of a message is valid.
>
>
> By "creator" do you mean "initiator" (aka, the source of the first ARC 
> set, i=1)?

yes.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------FCEB176882E43C8F474EE864
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 6/14/2020 10:25 AM, Kurt Andersen
      (b) wrote:

    

    

      
      

        
On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker <dcrocker@gmail.com>
          wrote:

        

        

          


            > ARC lets the recipient look back and retroactively do
            the filtering

            > the list didn't.

            

            The concern about the creator of an ARC chain spoofing the
            purported 

            origin of a message is valid.  

          

          


          

          
By "creator" do you mean "initiator" (aka, the source of
            the first ARC set, i=1)? 

          

        

      

    

    
yes.

    

    d/

    


    

    
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

  


--------------FCEB176882E43C8F474EE864--


From nobody Sun Jun 14 11:43:05 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96073A0831 for ; Sun, 14 Jun 2020 11:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=pXeOK2Of; dkim=pass (1536-bit key) header.d=taugh.com header.b=MutWyMxb
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 7BXRPgoIQH9b for ; Sun, 14 Jun 2020 11:43:03 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E84253A0829 for ; Sun, 14 Jun 2020 11:43:02 -0700 (PDT)
Received: (qmail 55531 invoked from network); 14 Jun 2020 18:43:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d8db.5ee66fb4.k2006; bh=vKG7N+WJxr3bCse3ENl/0TOcLqp+740zQxyXk4cTgsY=; b=pXeOK2Of4Hr90qb5sn4HTsh/h9Bb5QzPEl9ucuC01sXXbdY9LtZsxBvoMHKk951LVfgzH6m2WQuqwqmekVN7mT4pSJJIlk4ExsmXyLypWV3+x3+ARLpLFhNml4lVI8W+zVcgZfPioe5swFuoIqmi95BkkxLQr3wyPf7UiM5TJQNKtP/Ei+yzeU2aryYBxrF2CkPtuGRT+2FvqJJMU47DkNcpvGBZvB72UqB3DynPSbtTyN+YopLzKS0O2wMcbBP2
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d8db.5ee66fb4.k2006; bh=vKG7N+WJxr3bCse3ENl/0TOcLqp+740zQxyXk4cTgsY=; b=MutWyMxbfcVrP54gH4ucP/30hAWhfS38APrCaUwiGFSxVXC/R4zTO7Gr5oKGWP6gGegGc+/SvUQwny6zezxF+fhZwPEodx+/UOg1xKunDS++wVoYpzWb1CFS86Dub71s7lOe+yR1UbL05VQKKWUsRkS5K7+xuPpLh8CZXg0ckvHqKmku7lRGZ5FuOyqoSTxHZDPvavGYPXDig57qo5aVOPPVx4neqVyHw4uSMCO5aBEFMtfT7U/9FlcuyW+GcCao
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 14 Jun 2020 18:42:59 -0000
Received: by ary.qy (Postfix, from userid 501) id C22951AB79FE; Sun, 14 Jun 2020 14:42:59 -0400 (EDT)
Date: 14 Jun 2020 14:42:59 -0400
Message-Id: <20200614184259.C22951AB79FE@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: kboth@drkurt.com
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] why ARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jun 2020 18:43:05 -0000

In article  you write:
>-=-=-=-=-=-
>> > ARC lets the recipient look back and retroactively do the filtering
>> > the list didn't.
>>
>> The concern about the creator of an ARC chain spoofing the purported
>> origin of a message is valid.
>
>By "creator" do you mean "initiator" (aka, the source of the first ARC set,
>i=1)?

I think it't the other way around. Let's say you get a message with
three ARC seals. For i=3 both the AMS and AS headers should validate,
since the message came directly from the entity that put on that seal.
For i=1 and i=2 the AS should validate but the AMS probably won't. The
cv= tag in each AS header tells us whether the AMS was good when it
arrived at that intermediary, so the i=1 and i=2 seals are only as
good as the i=3 signer's reputation.

I were a certain kind of bad guy, I would take the two seal ARC chain
from a message from a virtuous sender, replace the message body and
>From and Subject line with my spam, add a fresh new i=3 seal and blast
it out. That ARC chain is 100% valid, even though the messsage is
spam.

That's why (as Kurt knows) you only pay attention to ARC seals from
senders that are otherwise credible.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Sun Jun 14 22:30:08 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4F3A09C4 for ; Sun, 14 Jun 2020 22:30:06 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 38TIv4JQC_0S for ; Sun, 14 Jun 2020 22:30:05 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 103B73A09C0 for ; Sun, 14 Jun 2020 22:30:04 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:7d43:9fe9:e329:3b0a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05F5U1cf031994 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 14 Jun 2020 22:30:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592199003; bh=sAiT6pY0dTQW0GHekQ80EybsWSOtTKlBBwKYv1QSehE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lormveKVRGkt4Qrg9AxW/TQV89W5PKWEuHc+fyaGKmJ4QSgpee6YSRL0+p4a6sqpT j0IEZAvNG6h4pEkOPXCM+I9ssWOL1e5P8E/BE498FEsiYh1G0IPBQBO+6VKn2ub1bH 6OzWAnr3EK7gRQG9k6tTBxusOCyJ/L4b4bq38wuM=
To: Dave Crocker 
Cc: dmarc@ietf.org
References: <20200613201300.733361A9E445@ary.qy>  <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <35bcb4ad-b2d2-01d7-20b6-d07ac19a26e8@bluepopcorn.net>
Date: Sun, 14 Jun 2020 22:29:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 05:30:06 -0000

On 6/13/20 8:17 PM, Dave Crocker wrote:
> On 6/13/2020 7:53 PM, Jim Fenton wrote:
>> Alas, others do,
>
> Other groups do all sorts of things.=C2=A0 They once mandated OSI, for
> example.
>
> Please explain how that is relevant, here and now.
The WG needs to consider the operational impact of DMARC deployment if
it is going to publish DMARC as a WG document.
>
> Are you perhaps suggesting that the technical work of the IETF should
> worry less about technical quality and more about possible use/abuse
> by other agencies?

That is a false dilemma. We can (and should) consider possible use/abuse
of specifications we publish, but that does not imply worrying less
about technical quality.

-Jim




From nobody Mon Jun 15 00:33:45 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B057A3A0A8B for ; Mon, 15 Jun 2020 00:33:43 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 aaf8K0thy1dR for ; Mon, 15 Jun 2020 00:33:42 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 37D423A0A86 for ; Mon, 15 Jun 2020 00:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592206417; bh=QLqCZ4qQhgA/eZSm0yhBtoglzCus+YcomIaqW27tBAU=; l=2524; h=To:References:From:Date:In-Reply-To; b=DAYfZt6EBpIFk0OE1Ar42GxlOVfcggBd5Xzib1+ag86B94z5ivdGVAB/BJ9kjP63S Dy53e/ifqpFLwh3Y9cjb5+dN00oKjjnBfmKynCHYGdD3sP+vLjiImU/W9GHiAhp/M/ 1DUi5afU5SgAKLH99SZHutxexmB2kpt2Lm7tCln+Kon19a16H3or12glVNAfs
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EE72450.00001AD7; Mon, 15 Jun 2020 09:33:36 +0200
To: dmarc@ietf.org
References:    <6370085.sLrAyzsJJq@sk-desktop>
From: Alessandro Vesely 
Message-ID: 
Date: Mon, 15 Jun 2020 09:33:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <6370085.sLrAyzsJJq@sk-desktop>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 07:33:44 -0000

On Sun 14/Jun/2020 19:18:43 +0200 Scott Kitterman wrote:
> On Sunday, June 14, 2020 5:24:42 AM EDT devel2020@baptiste-carvello.net wrote:
>> Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
>>> About this comment
>>> 
>>>     If you teach users that "Joe User by Random Intermediary" is the same
>>>     as "Joe User", this expectation is doomed.> 
>>> Based on the response to my previous post, "Trained User" is not a
>>> meaningful concept, for purposes of this discussion [...]
>> 
>> That's not my point. My point is: this working group needs to make a
>> determination whether From addresses being displayed to the users
>> matters to DMARC or not, and then follow up consistently.
>> 
>> If it is, then don't break From addresses with munging.
>> 
>> If it is not, then use Sender field as a fallback for alignment, and
>> don't break From either.
> 
> I don't think that's the question at all.


+1, we're not going to reinvent DMARC, just elucidate it.


> Whether user's knowledge of the from address has any bearing on anti-abuse
> methods or not, it has plenty of value for other purposes.  DMARC is not all
> of email.
> 
>  From rewriting is a gross hack that exists only due to dire necessity.  If
> this working group can't move the space towards a more usable solution, I'm
> not at all sure DMARCbis is worth the trouble.


Let me quote a list of nineteen usable solutions:

     1 Sending side workarounds
         1.1 Exclude domains that require alignment
         1.2 Turn off all message modifications
         1.3 Replace address with a generic one
         1.4 Add fixed string such as .invalid to addresses
         1.5 Rewrite addresses to forwarding addresses
         1.6 Message wrapping
         1.7 Mandatory digests
         1.8 Ignore DMARC bounces
         1.9 Third Party Authorization
     2 Recipient workarounds
         2.1 Forwarder whitelist
     3 Cooperative solutions
         3.1 Shared whitelist
         3.2 Per sender whitelist
         3.3 Original-Authentication-Results header
         3.4 Forwarding token
     4 Authorization approaches
         4.1 Authenticated Received Chain (ARC)
         4.2 Signing key delegation
         4.3 Relay through author domain server
         4.4 Relay one copy through author domain server
         4.5 Have author domains sign camera-ready posts
     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]

That page hasn't been updated since 2016.  I don't think we can devise any new 
solution now.  There's been a natural selection.  Solution 1.3 prevailed, with 
a minority of lists opting for 1.2.  Let's face facts.


Best
Ale
-- 








































From nobody Mon Jun 15 05:48:47 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0853A0D93 for ; Mon, 15 Jun 2020 05:48: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, FREEMAIL_FROM=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=gmail.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 psXiyZ92VCIc for ; Mon, 15 Jun 2020 05:48:38 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 16DEC3A0D82 for ; Mon, 15 Jun 2020 05:48:38 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id g18so12385719qtu.13 for ; Mon, 15 Jun 2020 05:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Tmw6WEuJVVdSop4D8QUxPD+DYRtm1jKmvDcfSso1+/E=; b=oSrfzc+Cx+HowN+1XVzwivdnnQdjGzLNFxhYs7U/3LSsZDX1+pxbZAlEoz6fmZBxhi HLnAKuvwpKskBkRm1adR8T7s0EmKMlBOqkbkujnMVqo6ylBUEM1PBNbuVFVjHm9z1gUS 3PzIzpGrLnt1fD/DwL/r4DTuBcWB4McOB4JFKrjRnWu6Ov6s3Oo1mL0yoZu9a/efxSWk 6NBmUOCkBALjXOUq3LKKmDpGaPvq1SgRzPE62Whn7dm5qPCGuS0mwEAxoQcIBsy3Mtg7 pvHaIKkxf3wypNU2NZPXrsdSUwpW161o20kQ0+U4O8Vj7ZlZP8oMLmdcPdJ8Y3uYA5ez GWQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Tmw6WEuJVVdSop4D8QUxPD+DYRtm1jKmvDcfSso1+/E=; b=oBu78iePQw0bH0H38IeQFl3RV/1NldvGibi/wnTWJa3mqefknuBLwgmHqRvjapXvsf LmEucG7GO+sbCSTflfJYLai4KsZDWxWwbbIYO1125vcnT6pShHpcGVcKo39IzifItAEt PGdeDFltK72tp862VKWkXwPNvjxubQMH0dVs8U1yyHNEmNfSFmX3ToDVF7bL6qWLP0tz ETnBSyjdpQ+2mHDvn4eZndaZFqNVf1q7Ooq819YvXqDlYN0ge+WMB/OaywKJoGAExjSB hox2e90nYc/uMYUxGKuLx2WC1CeFF3Ts+6jf+XQvizEuJXT+HQk832lU9h6yKEMdldUw qu2Q==
X-Gm-Message-State: AOAM533SKhCMLFyPKD/7kGzWji2xflknNcybqdwm1Av16w+DGAWtYBaq 1150f5GFLjdcy7he/YktieGYiDCR
X-Google-Smtp-Source: ABdhPJyoguryvoDGnopGluE1WHZSRNejb/hrBYjHPQf/8VRFRvoGcMdqbkWhsWG+J6MeplCKeNVTYQ==
X-Received: by 2002:ac8:768b:: with SMTP id g11mr16271005qtr.249.1592225315397;  Mon, 15 Jun 2020 05:48:35 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:e9ed:aa2a:71f6:bfbe? ([2600:1700:a3a0:4c80:e9ed:aa2a:71f6:bfbe]) by smtp.gmail.com with ESMTPSA id h5sm11348881qkk.108.2020.06.15.05.48.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 05:48:34 -0700 (PDT)
To: Jim Fenton 
Cc: dmarc@ietf.org
References: <20200613201300.733361A9E445@ary.qy>  <6af0efe0-da7e-e91a-c022-77b339475cd8@gmail.com> <35bcb4ad-b2d2-01d7-20b6-d07ac19a26e8@bluepopcorn.net>
From: Dave Crocker 
Message-ID: 
Date: Mon, 15 Jun 2020 05:48:32 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <35bcb4ad-b2d2-01d7-20b6-d07ac19a26e8@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 12:48:45 -0000

On 6/14/2020 10:29 PM, Jim Fenton wrote:
> On 6/13/20 8:17 PM, Dave Crocker wrote:
>> On 6/13/2020 7:53 PM, Jim Fenton wrote:
>>> Alas, others do,
>> Other groups do all sorts of things.  They once mandated OSI, for
>> example.
>>
>> Please explain how that is relevant, here and now.
> The WG needs to consider the operational impact of DMARC deployment if
> it is going to publish DMARC as a WG document.
>> Are you perhaps suggesting that the technical work of the IETF should
>> worry less about technical quality and more about possible use/abuse
>> by other agencies?
> That is a false dilemma. We can (and should) consider possible use/abuse
> of specifications we publish, but that does not imply worrying less
> about technical quality.


Some people send spam.  We'd better deprecate all the email specifications.

Some agencies make silly or terrible rules.  And there are so many 
agencies. We'd better shut down the IETF because any specification can 
be abused and probably will be.

Perhaps you can offer a rather more focused, specific and deterministic 
concern?

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Jun 15 06:56:23 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783AA3A0D98 for ; Mon, 15 Jun 2020 06:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jl8SLPNk; dkim=pass (1536-bit key) header.d=taugh.com header.b=cIaAiKP+
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 fnmszWl4hq4c for ; Mon, 15 Jun 2020 06:56:20 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 EF3A13A0D9A for ; Mon, 15 Jun 2020 06:56:19 -0700 (PDT)
Received: (qmail 86242 invoked from network); 15 Jun 2020 13:56:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=150e0.5ee77e02.k2006; bh=MEQA2QqgQtOPe8ZEVf8EGS2XGNVNVeMtQypGfH21F50=; b=jl8SLPNkTUl23hW5KttiOAdle9coLlSvCicxh7pnR5ZEh9tiR+j/jhKOcacKL0r9csnTATZr1U4GRPGRf22PNx8MrN2ZzHQRBAEErP7A5D4Y0r/HSvTo21+RwrnXUsji89w0PFj0oD5MnJSop6qilf6BlLf0xVJJc1om52+CY517vFRmnqvCVnXfFQ1D20ZW9xIOsTu1mVh7A/E4b15/z6Au9+Thi7vRIwi6Ww1W0IXxf5GVCi+kcXTFXKTInju8
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=150e0.5ee77e02.k2006; bh=MEQA2QqgQtOPe8ZEVf8EGS2XGNVNVeMtQypGfH21F50=; b=cIaAiKP+6n8xvVH95dGYQIRVZalgAu4tMaYXtkuN04RBEEG9V0PQFnaNAGG/xZRg9vro4zGgwfsNK4O1V1ZSRbhlzOo7XfFb56v7u4fh0TqwERJGg4PRpBJdtgtFZflyJfObG8pABtMn6R68GbRHzQcwwzQP2UAEIpvpdb8hu1Ftpk2v9zCCMXLLL3/8STXLfMDDSIMDBMFTHojBoMVKL75dW2+F5PQ64kfuGv8Xv+OM66tmb1+4+oXMeJ3R8eH0
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Jun 2020 13:56:17 -0000
Received: by ary.qy (Postfix, from userid 501) id D526E1ABE349; Mon, 15 Jun 2020 09:56:17 -0400 (EDT)
Date: 15 Jun 2020 09:56:17 -0400
Message-Id: <20200615135617.D526E1ABE349@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: vesely@tana.it
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 13:56:21 -0000

In article  you write:
>Let me quote a list of nineteen usable solutions:

I wouldn't call them all usable.  Proposed, perhaps.

>     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]
>
>That page hasn't been updated since 2016. 

If anyone has any new bright ideas, let me know and I'll send you a
password so you can update the wiki.

R's,
John
-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Mon Jun 15 10:08:09 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A643A00B3 for ; Mon, 15 Jun 2020 10:08:07 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 ajuMMY8o9lOv for ; Mon, 15 Jun 2020 10:08:06 -0700 (PDT)
Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 ECD273A0063 for ; Mon, 15 Jun 2020 10:08:05 -0700 (PDT)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QBZ02LF28XFGR80@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 15 Jun 2020 12:08:04 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.15.170017, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.5.21.5740001, SenderIP=[104.47.55.103]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mx2sAWVk8hNaWBHbcTddAsUVL519cmkoCqHbKQRadY5RDTdMMo2ja9y/jC3zxxdiFIOkwVfolVQdhbgTfmtJlRMrEW1w5yG9l0NbDCMA2oFnNRxuOCyqKM7kAGquksd1xgH1JTQHUaAJ360TC1WOmfFpuXpnbEOqtoIinWcGIGF5g1J33CAREM0iRq2eQ5eQQn9cOQoiyAylxd5Acf4e42RsgKtQ9NhgJnYI5QeepRbQ7WydnxZlXvadOdmlz1dleCxBkjY17TSrIpOmfYewzoiaZFVrV2yKw51fG4qpmQ+T7yKmubaymDCVFF+bYEAwnsRK002R8sQoCdL6B75a5g==
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=gzz6OhVkoGbT5q0JkC2fJC4MjsqF6YhxdQm9e4sPUXI=; b=WomY3Ynck14F8gYQsdYC83eQM4725eTENMTO2fks0rj4fbI0thG4yRnvnw9qr1AjIBc0OBDDCcEI1mmZnd47bgVclnY2aDkkCvLOKz8jS9LfAnCaEDipDINWhnSUcHcI3J04aHYQlMEfCKlUULLsIo/OOkMETl4PbfshohG8By0HwhrXhGZZUN5RtC+4irSTVCz2GLFM5H9w8EEU5KrjbCrEFz2LBdvU7/O3r9QrayOCvPFOkJJUn+DGWYtJDloeQ351GPZV0hNdF1jdk+ooiJfBhbeEOl+tvDf7Lwa2B5ac9HQBWAyTOL4u+RVTDL9dbSQIv5N1zGk6GvZy5fV6cg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gzz6OhVkoGbT5q0JkC2fJC4MjsqF6YhxdQm9e4sPUXI=; b=Xmr869e6nNm13sZykiSz2LSLf0tivirGM6RYmQ8v+vqkIbkoRSSq9vhzl09/M7B9uvmlH+4CeLwg3w6Diaj1WnUZnth6u9axBHJyghMuOn/qttBbAZGxeCNr/TF7mMbk4n8NXvCnd7FMqIo39pHTetKFcxETduObb0guk2iGN10=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB2890.namprd06.prod.outlook.com (2603:10b6:3:11f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Mon, 15 Jun 2020 17:08:02 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 17:08:02 +0000
To: dmarc@ietf.org
References:    <6370085.sLrAyzsJJq@sk-desktop> 
From: Jesse Thompson 
Message-id: <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu>
Date: Mon, 15 Jun 2020 12:08:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: 
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 8bit
X-ClientProxiedBy: CH2PR16CA0018.namprd16.prod.outlook.com (2603:10b6:610:50::28) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.0.2.111] (47.12.96.133) by CH2PR16CA0018.namprd16.prod.outlook.com (2603:10b6:610:50::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 17:08:02 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 7fece60e-2bb2-4785-d01f-08d8114ea9ac
X-MS-TrafficTypeDiagnostic: DM5PR06MB2890:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-Forefront-PRVS: 04359FAD81
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: jTPrlbcNImrMa8g29rGG4IODkAL2tzF56Z1tfUrJkVjasv3VAgWiEzT3ESwtYcdSp70UEfTQnd81famyBvbNfwIrBWARPP+WU8zk3hjY4D4rFXXsEypn8CIWxPVR6sLRer0k2etJtKpGYEbwtfspuTBbtdur8pWzoiuOVaCXEqSjfpJtGhiqT9HKXN5SxxLplZZNXzGR5eA9Cqejw2yvAFj6t3uVRlIhDWZXeDXWW7X7hudoHZT2lruaJfUBikt3QmBzqkddqoWPkGfZ1Ad9zYPP42T697dCYBs+/z3BZW+zMPFmJ8B3ZWWI6cRhhnL9a+/RsLvNIAXOPX4rf9pP5yWBdHh12GZztj+O3Q3GLwGKaoKvnfyLeiAskNYekJdgL5MYmWk9RIJ2erTL6kH03HgyumzeKi/e1xO2wzmISYr/FJAeiehr4yUbANPNAjxakiiRuNUS/qCsclZmv0jq8WQP5rsOWbC2V3rZ90DfhXg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(136003)(39860400002)(346002)(376002)(366004)(396003)(36756003)(75432002)(86362001)(186003)(956004)(8936002)(44832011)(53546011)(66946007)(66556008)(6916009)(5660300002)(26005)(31696002)(2906002)(2616005)(45080400002)(478600001)(16526019)(66476007)(31686004)(6486002)(83380400001)(786003)(16576012)(316002)(8676002)(223123001)(130980200001)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: 86isv8UUdpkEMm6mMBs7TFRT0ItMTZM38PXlMQVPhHPqfe0qVDXKKEgY3+XFiWAxW6wNmhmsA0TPvwyAgcUeFxA8aOgTRugNcuNu+nWVJd/K+UqhuBGY+H6HC4MfuNPXbrfNLs20fU/4ploaJ0rzxmVUCbovYda9vWu6nsJC4ul3akC6KDAXK2wGZYBdHE0dNMY+4FmG+ilvjXHa+yoHctk5FW3XH8yn+a/mLEziEfMwoDPDNmL6CHYvyuXcrbY4cGMJ3qWH6AHLLT0m6aLyRLPSVP3LMLDCd+F/gZGEQEt2GLsOIlPBUPi9+n99toqiJaFFf2x5hh7Ze1TbQtf5I+Z8N5zkKe5esZZJYXHWo/UKJXUuELwCViuB1lX7qt8ZIgXb1kf3xsK3gu86iUOcQYC4B+LBvWHm42yEDIVCBfyKk/l7P0A6sUSwiu2hAI2FCM2eRHgkFtiSph7Ms+RZZp8p534oxMTCaoQoPnp8ED8=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fece60e-2bb2-4785-d01f-08d8114ea9ac
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 17:08:02.6590 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SgTLv2hZMluvuOzloRYd1Yo5UNjLkyMg8lv4DYPjNArinA25kNoHnk3eHGXVEig7TLNvyPfBsjjuvbtpDVrDFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2890
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 17:08:07 -0000

On 6/15/20 2:33 AM, Alessandro Vesely wrote:
> Let me quote a list of nineteen usable solutions:
> 
>     1 Sending side workarounds
>         1.1 Exclude domains that require alignment
>         1.2 Turn off all message modifications
>         1.3 Replace address with a generic one
>         1.4 Add fixed string such as .invalid to addresses
>         1.5 Rewrite addresses to forwarding addresses
>         1.6 Message wrapping
>         1.7 Mandatory digests
>         1.8 Ignore DMARC bounces
>         1.9 Third Party Authorization
>     2 Recipient workarounds
>         2.1 Forwarder whitelist
>     3 Cooperative solutions
>         3.1 Shared whitelist
>         3.2 Per sender whitelist
>         3.3 Original-Authentication-Results header
>         3.4 Forwarding token
>     4 Authorization approaches
>         4.1 Authenticated Received Chain (ARC)
>         4.2 Signing key delegation
>         4.3 Relay through author domain server
>         4.4 Relay one copy through author domain server
>         4.5 Have author domains sign camera-ready posts
>     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]
> 
> That page hasn't been updated since 2016.  I don't think we can devise any new solution now.  There's been a natural selection.  Solution 1.3 prevailed, with a minority of lists opting for 1.2.  Let's face facts.

Precisely.  Let's work from a basis of reality.

I'm representing an EDU here.  Mailing lists are still heavily used in EDU for cross-institution and cross-sector collaboration.  They aren't going to be replaced by web forums or Yammer (or whatever corporate enterprise aspire to do) because faculty are open and collaborative by their nature.

We have over $1bn in research expenditures, most of which are funded by federal grants, and so we need to receive mail (sometimes indirectly) from federal agencies who are adhering to BOD 18-01.  A growing number of universities are publishing DMARC policies, and an unknown but presumably growing number of universities and agencies are enforcing DMARC policies for other domains.  It's becoming increasingly difficult to ignore DMARC.

Given that Microsoft and Google have essentially soaked up the entire EDU email market (hey, the price is right), let's say for sake of argument[*] that most EDUs are faced with 2 choices for their MLM:  Google Groups and Microsoft 365 Groups.

Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

We can delve into *why*, but the reality is that we have failed with using Microsoft 365 Groups with external collaborators from domains that have adopted DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily use Microsoft 365 Groups for internal collaboration.  

Given that choice in this context, I believe that Google Groups will be chosen as their MLM by anyone taking DMARC into consideration.  I would not be surprised if Microsoft falls in line with solution 1.3.

So, solution 1.3 has been naturally selected.  Does it need to be standardized, or is a BCP good enough?  I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and consistent way.  Is that where ARC comes in?

Thanks,
Jesse

[*] Glossing over the fact that a university is not a single entity.  There are hundreds of entities within a university that all may individually choose their own solution.


From nobody Mon Jun 15 10:15:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBB23A0403 for ; Mon, 15 Jun 2020 10:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IcmHNySaoGQ5 for ; Mon, 15 Jun 2020 10:15:37 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 E92BE3A0366 for ; Mon, 15 Jun 2020 10:15:34 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id s6so919274vkb.9 for ; Mon, 15 Jun 2020 10:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ID6i7fbgjTt46X/ZvHYfVyfvzhGvXvBg1NPEFaCEAyY=; b=V8qYa79Rxt7FGy2Srb3DZHXpkULQyHs0LXCUKs0ol/+opjP2yyLICuiNz5nP0N2Ao4 UdHIacsy7RCF6j2EzPpU7ge74SKzcP0doleQ1KM4fy+duSM61xmxW5g+ImKxTGc4DbO9 ZprMX26xhPAm/6mR1BJYYe8gkpYGkIF3xnCLT1FrAQBy0CG182vAaLJkOMx7Sama3zO7 QsLioQfVlYvk1yGPxsxsY4un3hm/LwhWiZ7CjOuSgTujyUfdyYYeXNaU9LzKBd8oQWI3 fQINU3ucXcT4CP0TESdHUGEw6SYZAvouVk5PwFM0pKf2YVWqUK+FTMwY5BSnxCOPJcWH 2rzQ==
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=ID6i7fbgjTt46X/ZvHYfVyfvzhGvXvBg1NPEFaCEAyY=; b=HERN2zffwMgBcjKl8CJ97EmtoLliUG9kmpVMK9zTQx5ZxeT++yr5VRsL8tlfiPaURf IjKcbkbYMGJ2laCJ5KLs8p9QWB4z22HIWY8Ee2nsrJJ5wm4O53lN6BpDKmGE8NxJpp7f P4EDrRbn8jUpTDCjb2256LUbfq9Zp/AbxmihF+BpRWhkCNE39vYEP9xvpW+f0THo81oc Lb+cRMeO7+/pFvIxnOHuw4EUPRg8KsW5lWTxRJUIRybB0ljxiJ3xMmeCx3ML+VkNjCG4 4ymv6E2QjricKxWmNiTLrN1jZOAeREFjkiT2E76rG6AQZOgzPoADUV00hkUaBA6EkjGK 0hOQ==
X-Gm-Message-State: AOAM532IsaKZZveMlnkcWLmMG0bPCM49I1rfmrYXqK3MbiL0SUYZRV4v H8LQlW2CAwvqr6lsbC3ItjMZ71nF0G9R0CKzzmpCl4v/Hg==
X-Google-Smtp-Source: ABdhPJze7UG+kHHVPwaCkH1t/kGHp4HVXMbj5dnfY9QH0FfKQma+NkrQjZCJJiofG29zzxEMnJ4gUBOw8wjdH3CedhQ=
X-Received: by 2002:a1f:4185:: with SMTP id o127mr19096788vka.45.1592241333379;  Mon, 15 Jun 2020 10:15:33 -0700 (PDT)
MIME-Version: 1.0
References: <5EE65D11.3050107@isdg.net>
In-Reply-To: <5EE65D11.3050107@isdg.net>
From: Brandon Long 
Date: Mon, 15 Jun 2020 10:15:20 -0700
Message-ID: 
To: Hector Santos 
Cc: "dmarc@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000013394a05a822934b"
Archived-At: 
Subject: Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 17:15:40 -0000

--00000000000013394a05a822934b
Content-Type: text/plain; charset="UTF-8"

I don't understand what adding authorized third party signatures will add.

For a corporation, it may be possible to validate and approve a number of
third party signers... right now, that's done via DNS by either extending
SPF to include the third party, or giving the third party a DKIM key (or
better, mapping a key into your domain name space with CNAME)... or even
by smarthosting.

Any email sending vendor has to support this at this point.  However, this
doesn't handle the external mailing list case, or at best it works with just
the largest providers or some limited number of lists, but I doubt our
security department would approve some random open source list to send mail
as the company.

For a large mailbox provider, the set of potential third party vendors is
very large, and would require an extensive vetting process to make it work,
and even then, you've opened it up to security issues at the weakest link.
This is basically Google's OAUTH API Verification process with estimates
that the vendor security audit cost of $15-75k... and still wouldn't handle
small mailing list providers.

The reason third party signatures don't work for mailing lists is because
they are a relay, not an origination service, and fundamentally third party
signatures only work with origination services.

One could say that the third party auth problem is the same with ARC, but
there are two major differences.  For one, the question of whether to
accept an ARC hop as valid is on the receiver, not the sender, which allows
it to work with relays which are more known to the receiver than the sender.
For two, ARC is saying something very different.  Third party auth is
saying "this service can act as me" while ARC is saying "this service
relayed the message
without substantive changes".  It remains to be seen whether ARC is
successful at this, of course.

So, at best, third party auth for DKIM wil be a "new" way of giving a
service access that no one will support for a long time, while there are
existing
mechanisms which work today for that.

Brandon

On Sun, Jun 14, 2020 at 10:23 AM Hector Santos  wrote:

> When we look at DKIM and the DMARC protocol by exposing the boundary
> conditions of the protocol, it helps with laying the groundwork for a
> protocol-complete model.
>
> DKIM has three possible signature states:
>
> - NONE (no valid signature)
> - 1PS (1st party valid signature, Author.domain == Signer.domain)
> - 3PS (3rd party valid signature, Author.domain != Signer.domain)
>
> DMARC has three polices:
>
> - none
> - quarantine
> - reject
>
> With these 3x3=9 states, the following table with the boundary
> conditions of the protocol is established with the expected and
> potential actionable result:
>
>                          DMARC POLICY
>       +===================================================+
>       |////// | p=NONE     | p=QUARANTINE  | p=REJECT     |
>       |===================================================|
>    D  | NONE  | fail-pass  | fail-filter   | fail-reject  |
>    K  |-------+------------+------------------------------|
>    I  | 1PS   | pass       | pass          | pass         |
>    M  |-------+------------+------------------------------|
>       | 3PS   | fail-pass  | fail-filter   | fail-reject  |
>       +===================================================+
>
> Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
> SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states.
>   For this exercise, we are assuming DMARC/SPF alignment is in play
> and failure can be for any DMARC known reason including the 3PS failed
> states.
>
> The states for DKIM none and 1PS are expected protocol conditions.
> DMARC describes these conditions. But the DKIM 3PS conditions are not
> described and are subject to questionable actions because of the
> possible false positives results.
>
> The 3PS failures occur because of the dearth for an Authorized Third
> party Signature protocol.  DMARC does not offer 3rd party signature
> solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But
> they did not restrict an ADD-ON extension to the protocol.
>
> ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and
> when DMARC replaced ADSP, it equally applies to DMARC as well as an
> extension.  We do not need to get into the specific ATPS protocol
> details on how to authorize a 3rd party signer. Any "ATPS-like"
> protocol will only need to answer one question:
>
>    Is the 3rd party (re)signer authorized?   Yes or NO
>
> With this consideration, the table has one additional 3PS-AUTH row
> meaning Yes, the 3rd party (re)signer domain was authorized by the
> author domain.
>
>
>                     DMARC POLICY W/ ATPS
>       +======================================================+
>       |//////    | p=NONE     | p=QUARANTINE  | p=REJECT     |
>       |======================================================|
>    D  | NONE     | fail-pass  | fail-filter   | fail-reject  |
>    K  |----------+------------+------------------------------|
>    I  | 1PS      | pass       | pass          | pass         |
>    M  |----------+------------+------------------------------|
>       | 3PS      | fail-pass  | fail-filter   | fail-reject  |
>       |----------+------------+------------------------------|
>       | 3PS-AUTH | pass       | pass          | pass         |
>       +======================================================+
>
> Overall, as it was originally conceived, the DKIM Policy model can not
> ignore ATPS conditions because as you can see above, it would not be
> protocol-complete -- it is missing the 3PS-AUTH conditions.
>
> While ADSP is a specific RFC proposed protocol, I am using it as an
> acronym for any authorizing third party signature concept:
>
>     Result = DKIM_ATPS(author.domain, signer.domain)
>
> Lets finish that part of the DKIM model.
>
> Thanks
>
> [1] https://tools.ietf.orgy/html/rfc5617
> [2] https://tools.ietf.org/html/rfc6541
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

--00000000000013394a05a822934b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't understand what adding authorized third party =
signatures will add.

For a corporation, it may be possible to valid=
ate and approve a number of third party signers... right now, that's do=
ne via DNS by either extending
SPF to include the third party, or=
 giving the third party a DKIM key (or better, mapping a key into your doma=
in name space with CNAME)... or even
by smarthosting.
<=
br>
Any email sending vendor has to support this at this point.=
=C2=A0 However, this doesn't handle the external mailing list case, or =
at best it works with just
the largest providers or some limited =
number of lists, but I doubt our security department would approve some ran=
dom open source list to send mail
as the company.

<=
/div>
For a large mailbox provider, the set of potential third party ve=
ndors is very large, and would require an extensive vetting process to make=
 it work,
and even then, you've opened it up to security issu=
es at the weakest link.=C2=A0 This is basically Google's OAUTH API Veri=
fication process with estimates
that the vendor security audit co=
st of $15-75k... and still wouldn't handle small mailing list providers=
.

The reason third party signatures don't work for mailin=
g lists is because they are a relay, not an origination service, and fundam=
entally third party
signatures only work with=C2=A0origination se=
rvices.

One could say that the third party auth problem is the same =
with ARC, but there are two major differences.=C2=A0 For one, the question =
of whether to
accept an ARC hop as valid is on the receiver, not =
the sender, which allows it to work with relays which are more known to the=
 receiver than the sender.
For two, ARC is saying something v=
ery different.=C2=A0 Third party auth is saying "this service can act =
as me" while ARC is saying "this service relayed the message
without substantive changes".=C2=A0 It remains to be seen whethe=
r ARC is successful at this, of course.

So, at bes=
t, third party auth for DKIM wil be a "new" way of giving a servi=
ce access that no one will support for a long time, while there are existin=
g
mechanisms which work today for that.

=
Brandon

On Sun, Jun 14, 2020 at 10:23 AM Hector Santos <hsantos=3D<=
a href=3D"mailto:40isdg.net@dmarc.ietf.org">40isdg.net@dmarc.ietf.org&g=
t; wrote:
When w=
e look at DKIM and the DMARC protocol by exposing the boundary 

conditions of the protocol, it helps with laying the groundwork for a 

protocol-complete model.



DKIM has three possible signature states:



- NONE (no valid signature)

- 1PS (1st party valid signature, Author.domain =3D=3D Signer.domain)

- 3PS (3rd party valid signature, Author.domain !=3D Signer.domain)



DMARC has three polices:



- none

- quarantine

- reject



With these 3x3=3D9 states, the following table with the boundary 

conditions of the protocol is established with the expected and 

potential actionable result:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0DMARC POLICY

=C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 |////// | p=3DNONE=C2=A0 =C2=A0 =C2=A0| p=3DQUARANTINE=
=C2=A0 | p=3DREJECT=C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D|

=C2=A0 =C2=A0D=C2=A0 | NONE=C2=A0 | fail-pass=C2=A0 | fail-filter=C2=A0 =C2=
=A0| fail-reject=C2=A0 |

=C2=A0 =C2=A0K=C2=A0 |-------+------------+------------------------------|<=
br>
=C2=A0 =C2=A0I=C2=A0 | 1PS=C2=A0 =C2=A0| pass=C2=A0 =C2=A0 =C2=A0 =C2=A0| p=
ass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|

=C2=A0 =C2=A0M=C2=A0 |-------+------------+------------------------------|<=
br>
=C2=A0 =C2=A0 =C2=A0 | 3PS=C2=A0 =C2=A0| fail-pass=C2=A0 | fail-filter=C2=
=A0 =C2=A0| fail-reject=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+



Note: I intentionally left out SPF conditions for NONE, NEUTRAL, 

SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states. 

=C2=A0 For this exercise, we are assuming DMARC/SPF alignment is in play 
and failure can be for any DMARC known reason including the 3PS failed 

states.



The states for DKIM none and 1PS are expected protocol conditions. 

DMARC describes these conditions. But the DKIM 3PS conditions are not 

described and are subject to questionable actions because of the 

possible false positives results.



The 3PS failures occur because of the dearth for an Authorized Third 

party Signature protocol.=C2=A0 DMARC does not offer 3rd party signature 
solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But 

they did not restrict an ADD-ON extension to the protocol.



ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and 

when DMARC replaced ADSP, it equally applies to DMARC as well as an 

extension.=C2=A0 We do not need to get into the specific ATPS protocol 

details on how to authorize a 3rd party signer. Any "ATPS-like" <=
br>
protocol will only need to answer one question:



=C2=A0 =C2=A0Is the 3rd party (re)signer authorized?=C2=A0 =C2=A0Yes or NO<=
br>


With this consideration, the table has one additional 3PS-AUTH row 

meaning Yes, the 3rd party (re)signer domain was authorized by the 

author domain.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DMARC=
 POLICY W/ ATPS

=C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 |//////=C2=A0 =C2=A0 | p=3DNONE=C2=A0 =C2=A0 =C2=A0| p=
=3DQUARANTINE=C2=A0 | p=3DREJECT=C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|

=C2=A0 =C2=A0D=C2=A0 | NONE=C2=A0 =C2=A0 =C2=A0| fail-pass=C2=A0 | fail-fil=
ter=C2=A0 =C2=A0| fail-reject=C2=A0 |

=C2=A0 =C2=A0K=C2=A0 |----------+------------+-----------------------------=
-|

=C2=A0 =C2=A0I=C2=A0 | 1PS=C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =C2=A0 =
=C2=A0| pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|

=C2=A0 =C2=A0M=C2=A0 |----------+------------+-----------------------------=
-|

=C2=A0 =C2=A0 =C2=A0 | 3PS=C2=A0 =C2=A0 =C2=A0 | fail-pass=C2=A0 | fail-fil=
ter=C2=A0 =C2=A0| fail-reject=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 |----------+------------+-----------------------------=
-|

=C2=A0 =C2=A0 =C2=A0 | 3PS-AUTH | pass=C2=A0 =C2=A0 =C2=A0 =C2=A0| pass=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+



Overall, as it was originally conceived, the DKIM Policy model can not 

ignore ATPS conditions because as you can see above, it would not be 

protocol-complete -- it is missing the 3PS-AUTH conditions.



While ADSP is a specific RFC proposed protocol, I am using it as an 

acronym for any authorizing third party signature concept:



=C2=A0 =C2=A0 Result =3D DKIM_ATPS(author.domain, signer.domain)



Lets finish that part of the DKIM model.



Thanks



[1] https://tools.ietf.orgy/html/rfc5617

[2] https://tools.ietf.org/html/rfc6541



-- 

Hector Santos,

https://secure.santronics.com

https://twitter.com/hectorsantos









_______________________________________________

dmarc mailing list

dmarc@ietf.org

https://www.ietf.org/mailman/listinfo/dmarc




--00000000000013394a05a822934b--


From nobody Mon Jun 15 10:44:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83003A07C0 for ; Mon, 15 Jun 2020 10:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=YuCGgfuX; dkim=pass (1536-bit key) header.d=taugh.com header.b=EKdxcAi6
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 yevI1_2vWPLO for ; Mon, 15 Jun 2020 10:44:25 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D2A173A0823 for ; Mon, 15 Jun 2020 10:44:24 -0700 (PDT)
Received: (qmail 28976 invoked from network); 15 Jun 2020 17:44:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=712e.5ee7b377.k2006; bh=oxkc9cclVprBv/Qb/QOsh9CF5qFCj38okKGT5PIzu8M=; b=YuCGgfuXY5RimuiVMTV90iwV/S89pgqF7vx3kP0MAA1rM7/7B9E6aqCp8NT+SQH2TFo64cgZZPzMITrhsGcPCdPXrhpS7V6euW5bUWTzPWTWASvb3osiNwpU0Aq6m3hf2A8rvkavIQleTW1cFtwBAxD50Z8TFPQ4+3d76/MHj4DOSsmOcRMrociLkeIMH2sYQv2dOYbzeUnWiySIEjHUjukcLBeJmFjY3Y4DzvUNQNRSGeo7YM1BJ8vvfeGzc82a
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=712e.5ee7b377.k2006; bh=oxkc9cclVprBv/Qb/QOsh9CF5qFCj38okKGT5PIzu8M=; b=EKdxcAi6h6DS5mgyC/XkSVz7V+hx2jTH/NOvnGGyYLOUMtfn0bX8y2FmTdMC5Mlvsy5BNuuqHrHqgwiKDAsbygTJJeGR0xuLPpSow/cj6wko5x4OKfFwpz2uCEPdlbpAVtzaIp7ygHmNrQRkSPqDHEqKzB0KblBc1EygWI8fMYxAgH2Qqp2QKclR+cLlP5BMTbt4TNxfv7Kr8PK+1CmJlVC3FHGcjxVB0qTUQsB+u8EvmQt7PO0gyztN0VUEjO/7
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Jun 2020 17:44:22 -0000
Received: by ary.qy (Postfix, from userid 501) id 9405A1ABFF41; Mon, 15 Jun 2020 13:44:22 -0400 (EDT)
Date: 15 Jun 2020 13:44:22 -0400
Message-Id: <20200615174422.9405A1ABFF41@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: jesse.thompson@wisc.edu
In-Reply-To: <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 17:44:27 -0000

In article <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> you write:
>On 6/15/20 2:33 AM, Alessandro Vesely wrote:
>> Let me quote a list of nineteen usable solutions:
>>         1.2 Turn off all message modifications
>>         1.3 Replace address with a generic one
>>         1.5 Rewrite addresses to forwarding addresses

>> That page hasn't been updated since 2016.  I don't think we can devise any new solution now.  There's
>been a natural selection.  Solution 1.3 prevailed, with a minority of lists opting for 1.2.  Let's face
>facts.

Here in the IETF we use 1.5 but, yes.

>Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
>Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

They both claim they're working on ARC.

>So, solution 1.3 has been naturally selected.  Does it need to be standardized, or is a BCP good enough? 
>I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and
>consistent way.  Is that where ARC comes in?

No.  ARC lets mail systems accept list mail without munging.

R's,
John


From nobody Mon Jun 15 11:18:34 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D953A0887 for ; Mon, 15 Jun 2020 11:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 x3oBEOkIVr4i for ; Mon, 15 Jun 2020 11:18:31 -0700 (PDT)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 5D29D3A0885 for ; Mon, 15 Jun 2020 11:18:31 -0700 (PDT)
Received: by mail-vk1-xa2f.google.com with SMTP id i1so4169628vkp.8 for ; Mon, 15 Jun 2020 11:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YGSssMSkWpWyT6X5brnSukmkJW7BywJBfgUhYo8YzHs=; b=O0LclkwbRiJn/isc7SkpDflZx0G/aENuGNL0QGYmPAWWHQXGsuXqmM9wH0x459keVK UKVpOXGR7dQ02y9yasr/fiKhhuf6KguFWc1hgy9IfSOqcqudvoo9KL38JHYHjQ80B2D9 aoKUw0keE7r3WCqZEY4dzB/qEDFG3a3AdQwxD9oGB/SsjO6aCI+sj8RsC2TYCw0dx0Pd mm0b3F9jHMPYsKMxM2fGpJv4ZM3rrKCaxRPWXkPKp4IsQy0F1VIU9w3mx3CbU2/w9MUx S3JFJ+swI5xCM4waMUEeweCV/TQmNhxkXmZsYnzuautnhqXgXfsf767vjN23+3tCczqT MtRQ==
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=YGSssMSkWpWyT6X5brnSukmkJW7BywJBfgUhYo8YzHs=; b=HpMToSXXb/psagjFAxNBF0jvYyDqnH97LPTJPZsqmwMbLN/ffl1MTc8FzF4LIu3CIP O2AA2xyNQEY3EEoQIeB/PtumkcmPOEHcMaD20uiXvJdGHJh8oFEfTRgeEssLqW0PbLNb VBxuYX1NLxbvj8YQTgZIs+gYDEq3dU8inYO3shh2Ttll0/z4rb1kPQ/DpNYIg03ybFun F4/70BjJl3bqzkqnOXPb3T3d2YvPbm3P69MzzMeM4SQy7jRCNQQcSC/gTXwOF+tqG0FB b8A9jcJBMsWLM9awosjGMv2PKd4nsiwM0BKcsmtOhwZkadUCVJTU2QSmaIBgBt4v2Ekd M6bw==
X-Gm-Message-State: AOAM533FeTBbRzrS8FrtBpTkm22/VJMiYohNPM629y+FutwEkRDgFLgl e8u4nkc7/Ud8t0TMHv8nMiu2b4MS6sbGJFpFwuW0PXY=
X-Google-Smtp-Source: ABdhPJyOsCtkSfU8ZYvZyh1JK7sbpupec5iPwF/C811ML5dajRD9b85iEULFh3znHDMfR2D78J46EdggJ1ta4OaGO9Q=
X-Received: by 2002:a1f:bd87:: with SMTP id n129mr19107095vkf.48.1592245109780;  Mon, 15 Jun 2020 11:18:29 -0700 (PDT)
MIME-Version: 1.0
References: <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> <20200615174422.9405A1ABFF41@ary.qy>
In-Reply-To: <20200615174422.9405A1ABFF41@ary.qy>
From: Brandon Long 
Date: Mon, 15 Jun 2020 11:18:16 -0700
Message-ID: 
To: John Levine 
Cc: IETF DMARC WG , Jesse Thompson 
Content-Type: multipart/alternative; boundary="0000000000002aa77205a823749a"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 18:18:33 -0000

--0000000000002aa77205a823749a
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 15, 2020 at 10:44 AM John Levine  wrote:

> In article <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> you write:
> >On 6/15/20 2:33 AM, Alessandro Vesely wrote:
> >> Let me quote a list of nineteen usable solutions:
> >>         1.2 Turn off all message modifications
> >>         1.3 Replace address with a generic one
> >>         1.5 Rewrite addresses to forwarding addresses
>
> >> That page hasn't been updated since 2016.  I don't think we can devise
> any new solution now.  There's
> >been a natural selection.  Solution 1.3 prevailed, with a minority of
> lists opting for 1.2.  Let's face
> >facts.
>
> Here in the IETF we use 1.5 but, yes.
>
> >Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
> >Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or
> p=reject)
>

We sometimes use a different solution that isn't listed, which is basically
where internal groups have access to the
domain DKIM key, so they just re-sign.  Those aren't really an interesting
case, though.

Also, we chose that due to expediency at the time with the possible theory
of doing 1.5... and I don't imagine at this
point doing 1.5 will ever be high enough on the list to be done.

They both claim they're working on ARC.
>

Honestly, ARC is probably going to be used for things besides mailing lists
first, since the main challenge is that there are a
lot of places where 1.2 isn't maintained during relaying which may never be
fixed (or can not be).  We're already
using it to know when not to trust SPF, for example.  I imagine the ability
to handle third party security filters better
will also happen before mailing lists.  In some respects, using it to make
local receiving decisions is easier than knowing
when it's possible for a mailing list to rely on ARC being implemented by
it's receivers and to stop using one of the other
work arounds.

Brandon

--0000000000002aa77205a823749a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jun 15, 2020 at 10:44 AM John=
 Levine <johnl@taugh.com> wrot=
e:
In article &l=
t;1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> you write=
:

>On 6/15/20 2:33 AM, Alessandro Vesely wrote:

>> Let me quote a list of nineteen usable solutions:

>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.2 Turn off all messag=
e modifications

>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.3 Replace address wit=
h a generic one

>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.5 Rewrite addresses t=
o forwarding addresses



>> That page hasn't been updated since 2016.=C2=A0 I don't th=
ink we can devise any new solution now.=C2=A0 There's

>been a natural selection.=C2=A0 Solution 1.3 prevailed, with a minority=
 of lists opting for 1.2.=C2=A0 Let's face

>facts.



Here in the IETF we use 1.5 but, yes.



>Microsoft's solution: 1.2 (conditionally, based on some logic, it s=
eems)

>Google's solution: 1.3 (conditionally, based on DMARC p=3Dquarantin=
e or p=3Dreject)

We sometimes use a dif=
ferent solution that isn't listed, which is basically where internal gr=
oups have access to the
domain DKIM key, so they just re-sign.=C2=
=A0 Those aren't really an interesting case, though.

Also=
, we chose that due to expediency at the time with the possible theory of d=
oing 1.5... and I don't imagine at this
point doing 1.5 will =
ever be high enough on the list to be done.


They both claim they're working on ARC.

=

Honestly, ARC is probably going to be used for things besides mailing =
lists first, since the main challenge is that there are a
lot of =
places where 1.2 isn't maintained during relaying which may never be fi=
xed (or can not be).=C2=A0 We're already
using it to know whe=
n not to trust SPF, for example.=C2=A0 I imagine the ability to handle thir=
d party security filters better
will also happen before mailing l=
ists.=C2=A0 In some respects, using it to make local receiving decisions is=
 easier than knowing
when it's possible for a mailing list to=
 rely on ARC being implemented by it's receivers and to stop using one =
of the other
work arounds.

Brandon
=



--0000000000002aa77205a823749a--


From nobody Mon Jun 15 11:19:29 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08893A0843 for ; Mon, 15 Jun 2020 11:19:28 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 omrjHEGNLe_o for ; Mon, 15 Jun 2020 11:19:27 -0700 (PDT)
Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 38F9F3A0840 for ; Mon, 15 Jun 2020 11:19:27 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QBZ00ON7C8DTH30@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 15 Jun 2020 13:19:26 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.15.181217, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.5.21.5740001, SenderIP=[104.47.55.169]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bt0PgDwvJ7MbF64Nt0DW1ZPM8XhKx4oGfyhGgzNgdsVGzymENo4iDBy0bb3qGKLv/GR3hZMyotqU9CFnT13PVium6pAJWDHtA7KBEFOFsVEYEzUc10J0qrmb6VMUAcOcpcKDbRcOjENzoVwc5ovYlWepdp8BmH96MVvFTBiaLJPF0a3izhblHV6BO7cy7qnl4SXZTD8zNbr9PPPBXb9hY/xKuRfyDGRqlVO3QxI10Rztqwcoge8Ys+Z+bwu6XDhJMoZ713DJ+blK2fYTVNAcIPCthYWcWvnNj8vwJ0Eax3tjuJUXxYKXmGar/B3yagKBNDrrv1L6gmMQybNTda7nIA==
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=m1MO+gzpbwEUCD45A8cOkSVUAHG6h1xEo42BJAzsiAw=; b=lUZD+vcHDPJVRGhqLm5N2LcRUw2YfCDJD/xUXQk4xkWsp+uBqGMnLExomNkMzRv7HKS76+bXIVlus0f4HPP6p8iN8KiM6Eb2Jl3g8YRRf1Crrdx6DvHRwIQfDf0Ab0S2phXmyJeEHabjQzAQRN0hH0uZqngdj5Yz+DnnemVHFqOvHOU6iWo8T9/zzAGNfjxOx09jmHM2eFUPOrz0Js+1PvkMXy9m6yoIVQAkXdRtFutNdG43cIitLtPM+MQ2QZ36tl7woGoGcO7GJXNQP2k5v4oWn5AQscyrpIMyIV1AQM6RGAICe+0vn0G0c93TsGR8S4ZVGHPFijadedASeaSpLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m1MO+gzpbwEUCD45A8cOkSVUAHG6h1xEo42BJAzsiAw=; b=d4G4kU3URyzr8/UIbktblkG/jE7D2SCi20l0GZGhQNhRhkC1fwS3N5uhkZbg8MSDZBjWFlWcAMPK+lz4GIe8DZIrqQ2Wbs5kUSWmsMtBt5Y7KV7jP8/W/EXi57ciSF11Ax+PCnbxFhWyTTJ3zy+tBkd7MlvHHZkLkXS6X1KsT8w=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB5450.namprd06.prod.outlook.com (2603:10b6:5:3c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Mon, 15 Jun 2020 18:19:25 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 18:19:24 +0000
To: John Levine , dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>
From: Jesse Thompson 
Message-id: 
Date: Mon, 15 Jun 2020 13:19:22 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: <20200615174422.9405A1ABFF41@ary.qy>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 7bit
X-ClientProxiedBy: CH2PR20CA0025.namprd20.prod.outlook.com (2603:10b6:610:58::35) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.0.2.111] (47.12.96.133) by CH2PR20CA0025.namprd20.prod.outlook.com (2603:10b6:610:58::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Mon, 15 Jun 2020 18:19:24 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 60546d4e-a6db-447c-2637-08d81158a212
X-MS-TrafficTypeDiagnostic: DM6PR06MB5450:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-Forefront-PRVS: 04359FAD81
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: fc3l3737JEr0Ul0iP8v6D7atnlrsSKQ2WAzmNUFHvVMBzGf6PGZO9xr9DHbz7iUM8gNtTqByom7/EXUgknadB+jHDN200QVfKZ/hV3LJyd1gC/9x14WXNfS+JN/DVVRWm8w/G188RzyWpEIcOcMQ7g7TSX7xsR4QAKRptZSnEJNhj6YFVJDqiaf97TT9Cli5np43A15g/6ssR0pCHB20HGjdBvVa7vAt+qWNiJNDQHHu7slEvJo7mGGovF1z5rR1dRsb9Ec5hIDljJAfgjEvVJsKelpN1AETGjlnNTCgMTvXJ37l5SqErLlMWQixhhB+n9RB/hDCDFuORPl/OhjcyqLtiORqKI9L4uwshZuGt/TJ3dNmS7DBBERxvrh3xBLPl2ewAoEIaN9rpqyKxwRfXzqW7d1HfQfwlnod+b75Y2qWuFFxfGQ62rGOnKpIt+Xb
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(396003)(376002)(346002)(136003)(366004)(31686004)(2906002)(478600001)(5660300002)(186003)(4744005)(16526019)(786003)(44832011)(36756003)(66946007)(26005)(8676002)(86362001)(53546011)(75432002)(16576012)(316002)(31696002)(83380400001)(66556008)(6486002)(956004)(2616005)(66476007)(8936002)(223123001)(130980200001)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: WwrKg0m0HS5lMlugaWOqXHlNcbeVE0Fr1y3B+kFNvXWhOq4okjb4l6rsTNp61X0bP2igbcB9DMnvFnAxJoLKUwNRDnTr5gutMD1MSsr/wh5pgJe/OeGNUeyawD5owPls2s/TMAYPYKu+wJ14eyVlzyPQ919DzAut+W5mJuTUG0quYUKrZd6c65vscN7dmIiyvUWTz0zh6fyRLp35JcV6e+lMT4iVZaH1rehe2fOua7wzJVTY7OE29Cenc3B0pKKCjS6//nNI7QM11ly+C5kPGiFuqGvaBdtPeitFX63v6rTUJHmJJaUt6c+Nq7zvPdqjGBksXzAiOYEipi98CGgHzOK0lOurGFOFEbFjAbdCATYF8nfotzTe/wZqHgIwa9FH2qZZnezOo8+BgmkAAx42XFhxhnBFjHrwejDwvlnNqBf1I0fso79BXreTJ4pLWWvaZpUVR7JeSrbO5oFC+oow/TSN77as6J7FaEgNcXG2s9I=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 60546d4e-a6db-447c-2637-08d81158a212
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 18:19:24.7977 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: iOLSiglsAhb9e1n9jEpM/H9+3+7vLm8y/fUq/5c1pbuqh1pAFb0saVhAu7kKac8CLE7b9eAoSNGZw7UvPi3LSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5450
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 18:19:29 -0000

On 6/15/20 12:44 PM, John Levine wrote:
> In article <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> you write:
> They both claim they're working on ARC.
> 
>> So, solution 1.3 has been naturally selected.  Does it need to be standardized, or is a BCP good enough? 
>> I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and
>> consistent way.  Is that where ARC comes in?
> 
> No.  ARC lets mail systems accept list mail without munging.

How will a random intermediary know if random destination has implemented ARC and will trust their claim?  Even domains hosted by SaaS providers will have their own ARC reputation to manage, and might have to do things like configure munging on a per-recipient/domain basis, assuming the SaaS provider grants that level of control.  It's safer and easier to munge everything.  

Even if you ignore my line of reasoning, I think that Ale made in the OP a compelling case that the practice of From rewriting is here to stay.

Jesse


From nobody Mon Jun 15 11:22:40 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0353A0840 for ; Mon, 15 Jun 2020 11:22:38 -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, FREEMAIL_FROM=0.001, 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=gmail.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 kqEpU3BNDUR2 for ; Mon, 15 Jun 2020 11:22:37 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 36C263A07CA for ; Mon, 15 Jun 2020 11:22:37 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id t25so16776046oij.7 for ; Mon, 15 Jun 2020 11:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hub9/zsWVf5g4D2s3N0GcEaZUEcAyPmUPMhYG1/R5rQ=; b=oxZsxfmkOQwaxA6QLN28aQchne0bCevUMvV5wN6qjBBaDwMibKcNCY609SjTrLDRtU ZiYBOIRUg0cJGGdJLGku89yP3QWV58qje/mDxi6TZIvy0Ih/2IZsP3sVciskBsWe/BbR jsbH0pR/aGBdF0/dxtpbnImunYrOFAIaROUXb6HpN1d8ESXHCPHy7RwpONbAwVifB4cF gHzNQfkeWlYqVVv5W9uQeldYqc2yKN2PizaIBE/VY4uoHDgPx28Odr3QHSrHDQXlH4wR hqMixUva2W8IpxFBY3kG7qYI0i+5P/W7pOWPXtURuRbElk1Q5M7MExR2L0mMF3EN7IUQ MYJw==
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=hub9/zsWVf5g4D2s3N0GcEaZUEcAyPmUPMhYG1/R5rQ=; b=NaUWz8MnVC2CQUDxQN1jP8xfhtk6kSx/5DAax/STLxnaZc1TEReIdaajomHKD+wL/G 6RBixFqfpEDoooTfT6NTnlEB20xWwvOhBjf1Ux8RfGqe20eygSv8RraJZEhj1EylZ83N 70NWIaOTjqDuoNdSI9aHv7gdR6cUBfxhkM0+gpV7iXFSNdyo34n/rJDflgff52fBQsJL vcqnACxJVWDfRsEa1/sMxDCURDVfKMTGESW3lBdPX/RSjrIwbFvaZskDslLLRyz1ut8G qP1V5OES9htiiKhsgfEBa84sOZI+Do2UdIisKsorxfKC/5RAaUUFPqKgodSKiWZCTCpI i5ew==
X-Gm-Message-State: AOAM530NUZ6gQYo3Fz741aFoos1WdQLr5KtNo4vt468W5VwX+fnUBMhy OAEWJKfv5qshj8VjO9I0zKP/hCy+/0Brrp5jI9M=
X-Google-Smtp-Source: ABdhPJxTHgzLGYq6eXkbHvlOpy7Xg8KPAc4wVn9shc7KqUHMpyTq4pDKs7s9erXqey8ZWZ2+Cyco5lZofCnJFIDvfio=
X-Received: by 2002:aca:1b13:: with SMTP id b19mr558032oib.132.1592245356538;  Mon, 15 Jun 2020 11:22:36 -0700 (PDT)
MIME-Version: 1.0
References: <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> <20200615174422.9405A1ABFF41@ary.qy> 
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 15 Jun 2020 14:22:25 -0400
Message-ID: 
To: Brandon Long 
Cc: John Levine , IETF DMARC WG ,  Jesse Thompson 
Content-Type: multipart/alternative; boundary="000000000000df2f4705a823822f"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 18:22:38 -0000

--000000000000df2f4705a823822f
Content-Type: text/plain; charset="UTF-8"

(no hats)

On Mon, Jun 15, 2020 at 2:18 PM Brandon Long  wrote:

>
> We sometimes use a different solution that isn't listed, which is
> basically where internal groups have access to the
> domain DKIM key, so they just re-sign.  Those aren't really an interesting
> case, though.
>
>
I used to encourage creating CNAMEs to DKIM keys that internal groups
managed themselves.
(DNS things like that are like nice BCP for DMARC deployment.)

Large corporations with legacy domains and multiple business units
operating semi-independently
are the same problem space as Jesse's University case.

tim

--000000000000df2f4705a823822f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


(no hats)

On Mon, Jun 15, 2020 at 2:18 PM Brandon =
Long <blong=3D40google.co=
m@dmarc.ietf.org> wrote:

=

We sometimes use a different solution that isn't listed, which is =
basically where internal groups have access to the
domain DKIM ke=
y, so they just re-sign.=C2=A0 Those aren't really an interesting case,=
 though.


I used to encourage =
creating CNAMEs to DKIM keys that internal groups managed themselves.=C2=A0=
=C2=A0
(D=
NS things like that are like nice BCP for DMARC deployment.)

Large corporations with leg=
acy domains and multiple business units operating semi-independently
<=
div class=3D"gmail_default" style=3D"font-family:monospace">are the same pr=
oblem space as Jesse's University case.=C2=A0 =C2=A0

tim



--000000000000df2f4705a823822f--


From nobody Mon Jun 15 11:27:12 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA763A0845 for ; Mon, 15 Jun 2020 11:27:11 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=dqfJvBnF; dkim=pass (2048-bit key) header.d=kitterman.com header.b=erhYa/8X
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 kZ0MKzJt08Pj for ; Mon, 15 Jun 2020 11:27:10 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF5D3A0837 for ; Mon, 15 Jun 2020 11:27:10 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id B2C7AF80304 for ; Mon, 15 Jun 2020 14:27:08 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1592245628; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=7ZWqY7MJ7XFodoMKhhyKeZcO7xi6JhhRpXH/BNa47K8=; b=dqfJvBnFFRLq9AUiEN8cUD2qT9cwsBcQ4E9d7MwE/PttXiDCetg4D6BUchSHhQ3KGjy7Q j4dqLP5afQ3o/37CQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1592245628; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=7ZWqY7MJ7XFodoMKhhyKeZcO7xi6JhhRpXH/BNa47K8=; b=erhYa/8XIQYXiCXQZ14KYsR2f6T9Z1lNS8EXPQqtNuFXOQovAv6kOnOYTX5Vh3HBCuB/X wbHPIFm5SYI4gYkCEzFNRhqgZtDLBhHcXIETPAR1nmnMmfLaV5gKYx7X8WTVXoTh6TaMoE1 2cR1YLceBu2vUqoTIO1d2VgOGakOODJl9Q+Y6hyizuhOBD6RRqqt1S5R2LrXD6FcHiOgcZN qsHx3ebRiurwOphWDpjmpnY0qDFaCtgkugao82kUqOoE2i8yiR7sJvgGu9Oc1ick4v/796f hmMPt9Ja1GEwIUeOP1m03a8E9eluGDNaiMrHEPhNayvM1YDyPEHBAt0VGvGQ==
Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 7FC81F800A8 for ; Mon, 15 Jun 2020 14:27:08 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Mon, 15 Jun 2020 14:27:08 -0400
Message-ID: <2598929.Ph2NfEyP8u@sk-desktop>
In-Reply-To: 
References: <20200615174422.9405A1ABFF41@ary.qy> 
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 18:27:12 -0000

On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
> On 6/15/20 12:44 PM, John Levine wrote:
> > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab193d@wisc.edu> you write:
> > They both claim they're working on ARC.
> > 
> >> So, solution 1.3 has been naturally selected.  Does it need to be
> >> standardized, or is a BCP good enough? I'd still like to see a solution
> >> for receivers to "un-munge" trustworthy messages in a safe and
> >> consistent way.  Is that where ARC comes in?
> > 
> > No.  ARC lets mail systems accept list mail without munging.
> 
> How will a random intermediary know if random destination has implemented
> ARC and will trust their claim?  Even domains hosted by SaaS providers will
> have their own ARC reputation to manage, and might have to do things like
> configure munging on a per-recipient/domain basis, assuming the SaaS
> provider grants that level of control.  It's safer and easier to munge
> everything.

They won't.  Bypassing DMARC based on ARC requires some level of trust in the 
source of the message.

> Even if you ignore my line of reasoning, I think that Ale made in the OP a
> compelling case that the practice of From rewriting is here to stay.

As a practical matter, that's certainly true for the short to medium term, but 
it doesn't follow that the IETF should standardize the practice.

To follow-up on Brandon's note about Google's use of ARC, it's bigger than 
mailing lists and so is this problem.  It's any intermediary that modifies a 
message in such a manner that DKIM fails (SPF is only useful for direct source 
ADMD to destination ADMD tranmissions).

I suspect that by hyper focusing on mailing lists, we're missing part of the 
problem.

Scott K



From nobody Mon Jun 15 11:30:51 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ED33A0843 for ; Mon, 15 Jun 2020 11:30:49 -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, FREEMAIL_FROM=0.001, 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=gmail.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 qmE7wzoHy88t for ; Mon, 15 Jun 2020 11:30:48 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 961663A0838 for ; Mon, 15 Jun 2020 11:30:48 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id e5so13855058ote.11 for ; Mon, 15 Jun 2020 11:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjuzlSOC6BcSePlMuS2L4XiU8rR0dW/rIlGHo7OlX2k=; b=jE6MNggQ/EqoogjhmAThofs/xRkazxStoKPC0GPGB8mVQFsjOSM4Iq/rFuQ12bLtIu CEi/kaNMDIe3vBsYsv2mfJpNRJn79wluU6nfJE789vigZcSIg3k9lcz6ioT5Su189nc5 yats0QXQAbf6ss6EP/qOHNiZ9KyCO8mFrX+RBZIYtZIYR937fMTZu/tWrtj2LaLXMrNI h/GCXMp0nlUaQgskzXmG3X4sgRiaoNZRJpSMdgq8LDUbVRRRMzTkcW4pNNfCV5FcJTLK WomUSLHZ63b+117fZzfiH3DRaM+hFJB8tjJ1PQ4B6RHNBDZEF809OEi6O2uj7IQIvgLM VsRQ==
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=KjuzlSOC6BcSePlMuS2L4XiU8rR0dW/rIlGHo7OlX2k=; b=MAq3F4zFNOdl8Ld6J5gN/G9r/UzYPSEwgtDsj0l6w/WcvOL2nXjMLmUXfrLPmf4lIL du1oiBM7ABxJ/4HHSfF/vbnbKMYOo1E9jDbRisakEPN2FmKqIUZ2Oygoz+Q2GxLsMWlQ ++FLwFlAmjD6sJUafs6c60wehSx4wDWtTvNj917Cy/8l1zvZgyZkU70ASit+9iIDUMxQ HIseW0ZzhgZI5NyNHprjtg6NlQQiyqaDB1FM/hdVLzgC9mlwxGnbkE17xAVW6Gdo5lWz ozTLxYWSPxiXJp8CHx4JqoWhsBvN1VkGk8ztKqrgJ8ErcFGGqTCeSh7HOsmXsUvvwcrj CrGg==
X-Gm-Message-State: AOAM531H94O2W26lqZIqtDcLs8zTmQqX9hfDSK8ZUYg0j8XlvlTF/0CI ywT5yTURq0etx8xB2NzvwiH5GOxg/NRFjAYaH2w=
X-Google-Smtp-Source: ABdhPJwjGkZt/KRjl2IlmHV4ySG/mEGN+ne8VJ6xtdRJ7HFqqTCT2fQzakd/XXR9HclMlAWCh5jB/Ofd6xygnEOc3ME=
X-Received: by 2002:a05:6830:3109:: with SMTP id b9mr21689443ots.41.1592245847771;  Mon, 15 Jun 2020 11:30:47 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop>
In-Reply-To: <2598929.Ph2NfEyP8u@sk-desktop>
From: Tim Wicinski 
Date: Mon, 15 Jun 2020 14:30:36 -0400
Message-ID: 
To: Scott Kitterman 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000026cd3905a823a032"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 18:30:50 -0000

--00000000000026cd3905a823a032
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
wrote:

>
> To follow-up on Brandon's note about Google's use of ARC, it's bigger than
> mailing lists and so is this problem.  It's any intermediary that modifies
> a
> message in such a manner that DKIM fails (SPF is only useful for direct
> source
> ADMD to destination ADMD tranmissions).
>
> I suspect that by hyper focusing on mailing lists, we're missing part of
> the
> problem.
>
> Scott K
>
>
I think the mailing list issue looms so large as to block out everything
else.  We (probably the chairs) should make sure we don't miss the the
non-mailing list part of this problem.

tim

--00000000000026cd3905a823a032
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterm=
an <sklist@kitterman.com>=
 wrote:



To follow-up on Brandon's note about Google's use of ARC, it's =
bigger than 

mailing lists and so is this problem.=C2=A0 It's any intermediary that =
modifies a 

message in such a manner that DKIM fails (SPF is only useful for direct sou=
rce 

ADMD to destination ADMD tranmissions).



I suspect that by hyper focusing on mailing lists, we're missing part o=
f the 

problem.



Scott K


I think the mailing list issue looms so large =
as to block out everything=C2=A0
else.=C2=A0 We (probably the chairs) should make su=
re we don't miss the the
non-mailing list part of this problem.

tim



--00000000000026cd3905a823a032--


From nobody Mon Jun 15 13:57:27 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F93A0F66 for ; Mon, 15 Jun 2020 13:57:22 -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 (1024-bit key) header.d=drkurt.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 TJKarw1boQCD for ; Mon, 15 Jun 2020 13:57:21 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 325173A0F49 for ; Mon, 15 Jun 2020 13:57:21 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id t9so19521181ioj.13 for ; Mon, 15 Jun 2020 13:57:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3kBF+UTCggFc8ZSTNrDbHIDw9tQXYDeKjKkP5XBfR/s=; b=LvqmaL0xAoGdYztmK8/ZVwjEeav98I6aTM9eX2bBhLE6XAvEiqA4xoopJFe4F65Bvb C0Ispwd22EvEEX1bpaWl4t8KY/p6aX8wAmz15RuXoqFlq6V4Y0d4V30RP6umMZsBCrju CRXtuvlGkgxVEDKhgDDjdKehejgmzXYcmN8yo=
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=3kBF+UTCggFc8ZSTNrDbHIDw9tQXYDeKjKkP5XBfR/s=; b=WD33f0Qy3lcv2cl+hsrPXXSMxiDoO1dFqkNK3C0G+mxASTuemh9+lF/1X0EHgUutVZ /hVx0+IlMmdwjX+TLAGM8obmpnIp/CW4O8HP7fAJudzesG0R9rnLsjGcWj3OfAv1c5Xr 0YZgBBZwW6Wcv7ZXjOQjHWdvnb5+C6E1N2UMYJV0KR25J7S5uwxFihf6r49T6o271WZ4 8XQ675ehFqEKOnwJsuzxxf4jqGn1Sqm8hdzU61WkUmgfpWkveumZFU6z7/Ho5hIeEMde 6AswBi8MtUY+rl7sAiQ9blnQ8EMGc8ftiCvadQTNwVVz1Dvn1iN79RgniIEyhIHxb4yp Dw7g==
X-Gm-Message-State: AOAM530dwa+pARLP3+cy63zb5/IiTX/Y7tq0cIJb2m99KqCSWn3ic92p nsAwd+Tt6a0L9hu/u1RE4nKPMTLdhtzIS5BFAMPgcg==
X-Google-Smtp-Source: ABdhPJwzpVo7fLe4Mq8z4Kol1aglkJI82oWupJpyHrDSZcE5t9jJ9o5VeS8bcs7uDoirZlH8yUUG0S1Fq+H+AatJBPI=
X-Received: by 2002:a02:6a4d:: with SMTP id m13mr22706853jaf.19.1592254640184;  Mon, 15 Jun 2020 13:57:20 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> 
In-Reply-To: 
From: "Kurt Andersen (b)" 
Date: Mon, 15 Jun 2020 13:56:55 -0700
Message-ID: 
To: Tim Wicinski 
Cc: Scott Kitterman , IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000038777e05a825ac1c"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 20:57:26 -0000

--00000000000038777e05a825ac1c
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski  wrote:

>
> On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
> wrote:
>
>>
>> To follow-up on Brandon's note about Google's use of ARC, it's bigger
>> than
>> mailing lists and so is this problem.  It's any intermediary that
>> modifies a
>> message in such a manner that DKIM fails (SPF is only useful for direct
>> source
>> ADMD to destination ADMD tranmissions).
>>
>> I suspect that by hyper focusing on mailing lists, we're missing part of
>> the
>> problem.
>>
>> Scott K
>>
>>
> I think the mailing list issue looms so large as to block out everything
> else.  We (probably the chairs) should make sure we don't miss the the
> non-mailing list part of this problem.
>

That's what RFC 7960 (the first work product from this group) was all about.

--Kurt

--00000000000038777e05a825ac1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski=
 <tjw.ietf@gmail.com> wrote=
:

On Mon, Jun =
15, 2020 at 2:27 PM Scott Kitterman <sklist@kitterman.com> wrote:



To follow-up on Brandon's note about Google's use of ARC, it's =
bigger than 

mailing lists and so is this problem.=C2=A0 It's any intermediary that =
modifies a 

message in such a manner that DKIM fails (SPF is only useful for direct sou=
rce 

ADMD to destination ADMD tranmissions).



I suspect that by hyper focusing on mailing lists, we're missing part o=
f the 

problem.



Scott K


I think the mailing list issue looms so large as to block out everythi=
ng=C2=A0
else.=C2=A0 We (probably=
 the chairs) should make sure we don't miss the the
non-mailing list part of this problem.

That's what RFC 7960 (the first wo=
rk product from this group) was all about.

--Kurt=
=C2=A0


--00000000000038777e05a825ac1c--


From nobody Mon Jun 15 14:20:31 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F53A117C for ; Mon, 15 Jun 2020 14:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=myYXk6qH; dkim=pass (2048-bit key) header.d=kitterman.com header.b=g2LEuXrM
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 VP2wcoh_5XaH for ; Mon, 15 Jun 2020 14:20:27 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B525B3A116F for ; Mon, 15 Jun 2020 14:20:27 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 00FA3F80304 for ; Mon, 15 Jun 2020 17:20:26 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1592256025; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UwwQe9wCQXal1vC3GAjU9IDgpVo7LCUyFG7U0IvpBg0=; b=myYXk6qHKEj+wx/9Gk5jVeTZVUv2Dd9xLdxg5CuG8gXCbCqPdciuDnJXTrVOVgBRoG0Zz HZQhHz6vh0UNp5rDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1592256025; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UwwQe9wCQXal1vC3GAjU9IDgpVo7LCUyFG7U0IvpBg0=; b=g2LEuXrMTFAm+1V7EoIr1aEipaketbNxs1iHHBqrqBxmIC0mm1xK6fNYfBcNaQTbdtA0k q7srdZMMFzWuHWi9rQswhwZIiteAfnR2Tbp8fvNWAjk0vEsyfuyasuNQgbYenym95M3twFX gfZBdMog6W+TJ9dAKQu2DHAUqnsdUO+jEIPCyhDsLRZqgC/hBAioB4L+6S5xaSnxn817YKm 1rQN4Pk5+fj2JnyJ45w1wwNN+wLO0RgPPl83r/7PAHoOzD/MMCkmiuBNmwVfCnHSLWrQeaN j0jcroFERTHoyhl97dUY4VbJ8UOJOwYDqbKhf3gJTDg7wENOSavVQe6ezhNA==
Received: from localhost.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id C5C08F800A8 for ; Mon, 15 Jun 2020 17:20:25 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Mon, 15 Jun 2020 17:20:25 -0400
Message-ID: <5608000.6bWcHqoX70@localhost>
In-Reply-To: 
References: <20200615174422.9405A1ABFF41@ary.qy>  
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 21:20:30 -0000

On Monday, June 15, 2020 4:56:55 PM EDT Kurt Andersen (b) wrote:
> On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski  wrote:
> > On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
> > 
> > wrote:
> >> To follow-up on Brandon's note about Google's use of ARC, it's bigger
> >> than
> >> mailing lists and so is this problem.  It's any intermediary that
> >> modifies a
> >> message in such a manner that DKIM fails (SPF is only useful for direct
> >> source
> >> ADMD to destination ADMD tranmissions).
> >> 
> >> I suspect that by hyper focusing on mailing lists, we're missing part of
> >> the
> >> problem.
> >> 
> >> Scott K
> > 
> > I think the mailing list issue looms so large as to block out everything
> > else.  We (probably the chairs) should make sure we don't miss the the
> > non-mailing list part of this problem.
> 
> That's what RFC 7960 (the first work product from this group) was all about.
> 
So problem solved?  No need to revisit?

Scott K



From nobody Mon Jun 15 14:43:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3163A13FB for ; Mon, 15 Jun 2020 14:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=aZHnmSXd; dkim=pass (1536-bit key) header.d=taugh.com header.b=ht/MToX4
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 UoQuekj9aoFq for ; Mon, 15 Jun 2020 14:43:40 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F0E583A13F8 for ; Mon, 15 Jun 2020 14:43:39 -0700 (PDT)
Received: (qmail 81404 invoked from network); 15 Jun 2020 21:43:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13dfa.5ee7eb88.k2006; bh=TTybbkarmvbg+zxWGYuHNjq/EoiOonPDIj/28eLvNp4=; b=aZHnmSXd1qX1f9n4rlxQ69kxXcE59oin94Rai9pSTegc0TnKsXB7OTXQiPwFsA2TjAU5ET9cVd1II3+9Pc4RsGqZ8Stfd7kDIq3BhvDR0Hossfx2Vcc2N687B/6NrcMgh+h+gncudVgZ6k+K9sh7SbgW8h9jVGc+rtM3cmdKFau1pN4pZyrn5oWFYJg9pSUxfOAkBMNnfWSyVO64d/BXVc+KqQLaE0uQUaqvnQQaiqL8NHr9lDan1tdpxbuzguY4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13dfa.5ee7eb88.k2006; bh=TTybbkarmvbg+zxWGYuHNjq/EoiOonPDIj/28eLvNp4=; b=ht/MToX4pF5/06fGDZSVKgm9L/llVQq77HpW1UZDbSh5k05Ap2qZdqzEm7+x2Qdmp4TgGF3KpDQWolAJDTMN6GSG6aJChonW/qeOvPxpgK2zumDvbW2dG48MlMVodwAM5z4qiPrDxq0Cf5J09BluuTS84L418ENwmUmJwMO3evUkPEwghIjMrvNZtmwfIMjmJHxubJrhe9J1wpIGv6BTnahrC99/TU5AIxd20EnM39rSN1omvnhvuuBovJ/glgxi
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Jun 2020 21:43:35 -0000
Received: by ary.qy (Postfix, from userid 501) id BF92E1AC1FBB; Mon, 15 Jun 2020 17:43:35 -0400 (EDT)
Date: 15 Jun 2020 17:43:35 -0400
Message-Id: <20200615214335.BF92E1AC1FBB@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: sklist@kitterman.com
In-Reply-To: <5608000.6bWcHqoX70@localhost>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 21:43:42 -0000

In article <5608000.6bWcHqoX70@localhost> you write:
>> That's what RFC 7960 (the first work product from this group) was all about.
>> 
>So problem solved?  No need to revisit?

The only indirect flows it talks about in any detail is mailing lists.

It's worth a look to see if there are others we understand well enough
to describe.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From btv1==4368773aa5b==fosterd@bayviewphysicians.com  Mon Jun 15 20:25:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195C93A0FE3 for ; Mon, 15 Jun 2020 20:25:59 -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 (1024-bit key) header.d=bayviewphysicians.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 TMMlQxi_VCdj for ; Mon, 15 Jun 2020 20:25:57 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CF83A0FE1 for ; Mon, 15 Jun 2020 20:25:57 -0700 (PDT)
X-ASG-Debug-ID: 1592277952-11fa313a1015a310001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 1Pq33Z7FDkMtm0Ne (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 15 Jun 2020 23:25:52 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=DKMpZVMz5nytqIF6CXgGJxG0rmfoZzg22HSwhraVkps=; b=Y0+/qOK/iaPcKUXTfKeneYuBZR3WQ6ghdiCWEHwXf1UFRwsmoGx1xHxhJI5YtmJII Q+E4Wy+0gLbxFhnZ9zIXCnqRSeAIUQaQCw7844flYlv7qKxbSNl6KaPTtai13X8OA BJe5AEJPwp97CMpvZkKPt7HHjv8DixTcc9av7e6tk=
From: "Douglas E. Foster" 
To: 
Date: Tue, 16 Jun 2020 03:25:43 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <7b2851e74ed5405e90bdfdcbe0747a50@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=c5411e534be64fcca287fd5a6562b657
In-Reply-To: <20200615214335.BF92E1AC1FBB@ary.qy>
References: <20200615214335.BF92E1AC1FBB@ary.qy>
X-Exim-Id: 7b2851e74ed5405e90bdfdcbe0747a50
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592277952
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 6708
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82581 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 03:27:17 -0000

This is a multipart message in MIME format.

--c5411e534be64fcca287fd5a6562b657
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Other uses of indirect mail:

My university offered an alumni account implemented as a relay to whatever =
hosting service I was using at the moment.   Never took them up on it, and =
glad that I did not.   Perhaps RFC 7960 talked about that scenario, because=
 I think I have seen it mentioned in an IETF document.

Header munging vs Alternatives:

Header munging vs.  Perfect author attribution

I have been considering an alternative world where header munging is elimin=
ated because author content is not modified and therefore author identified=
 is fully verifiable using DKIM and DMARC.   Several concerns come to mind:

We do a fair amount of geographic filtering, so some of the postings to thi=
s list would be blocked, because of coming from countries where we do not d=
o business.  Header munging provides a single point of origin; if one messa=
ge is allowed through the geographic filters, then all messages will be all=
owed through.   If an exception is needed, the list member and system manag=
er can be confident that only a single exception is necessary.

One of the reasons that IETF breaks DKIM is because it converts everything =
to a plain text.   This is a significant security benefit, by lowering the =
threat potential of the message.  It makes the IETF messages more trustwort=
hy than if they came to me directly from the author.   Other mailing lists =
may use other criteria, but they should all use some sort of filtering to p=
rotect their reputation and their members.  Header munging allows me to dis=
tinguish between IETF-filtered traffic and other traffic.

As an extension of that point, successful sender authentication establishes=
 identity, but it does not establish trust.   Trust is assigned by the reci=
pient, largely based on experience, so message from unrecognized senders is=
 given a low trust level by default.    I know how to trust IETF.   I do no=
t know whether to trust the next random person who contributes to this mail=
ing list.   

ARC assumes that after a user subscribes to a mailing list, he negotiates w=
ith his I.T. staff to have the mailing list operator authorized.   I expect=
 this to be problematic for many users.
To mitigate these concerns, the non-munging solution would presume that rec=
ipient systems have the ability to filter differently between ( unknown sen=
der + known mailing list ) and ( unknown sender without mailing list ).    =
To prevent spoofing of the mailing list, list identity would need to be ver=
ified as well as author identity.   As we add complexity to the inbound mai=
l process design, some extra processing logic is applied to all messages, n=
ot just the mailing list messages.   How many filtering solutions will be u=
nable or unwilling to add this complexity?    

Others have already noted that the mailing list operator must choose a conf=
iguration without knowledge of what capabilities will exist in the receivin=
g system message filter.   This seems to limit the range of possible soluti=
ons.

Given all of that, I think a non-munging solution would be more problematic=
 for me than what IETF is already doing.

DF 



--c5411e534be64fcca287fd5a6562b657
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Other uses of indi=
rect mail:

My university offered an alumni account=
 implemented as a relay to whatever hosting service I was using at the mome=
nt.   Never took them up on it, and glad that I did not.   Perhap=
s RFC 7960 talked about that scenario, because I think I have seen it menti=
oned in an IETF document.


Header mu=
nging vs Alternatives:


Header mungi=
ng vs.  Perfect author attribution

I have bee=
n considering an alternative world where header munging is eliminated becau=
se author content is not modified and therefore author identified is fully =
verifiable using DKIM and DMARC.   Several concerns come to mind:

  • We do a fair amount of geographic filtering, so som=
e of the postings to this list would be blocked, because of coming from cou=
ntries where we do not do business.  Header munging provides a single =
point of origin; if one message is allowed through the geographic filters, =
then all messages will be allowed through.   If an exception is needed=
, the list member and system manager can be confident that only a single ex=
ception is necessary.

  • One of the reasons that IETF breaks D=
KIM is because it converts everything to a plain text.   This is a sig=
nificant security benefit, by lowering the threat potential of the message.=
  It makes the IETF messages more trustworthy than if they came to me =
directly from the author.   Other mailing lists may use other criteria=
, but they should all use some sort of filtering to protect their reputatio=
n and their members.  Header munging allows me to distinguish between =
IETF-filtered traffic and other traffic.

  • As an extension of=
 that point, successful sender authentication establishes identity, but it =
does not establish trust.   Trust is assigned by the recipient, largel=
y based on experience, so message from unrecognized senders is given a low =
trust level by default.    I know how to trust IETF.   I do =
not know whether to trust the next random person who contributes to this ma=
iling list.   

  • ARC assumes that after a user subscribe=
s to a mailing list, he negotiates with his I.T. staff to have the mailing =
list operator authorized.   I expect this to be problematic for many u=
sers.
To mitigate these concerns, the non-munging solution wo=
uld presume that recipient systems have the ability to filter differently b=
etween ( unknown sender + known mailing list ) and ( unknown sender without=
 mailing list ).    To prevent spoofing of the mailing list, list=
 identity would need to be verified as well as author identity.   As w=
e add complexity to the inbound mail process design, some extra processing =
logic is applied to all messages, not just the mailing list messages.  =
; How many filtering solutions will be unable or unwilling to add this comp=
lexity?    

Others have already noted th=
at the mailing list operator must choose a configuration without knowledge =
of what capabilities will exist in the receiving system message filter. &nb=
sp; This seems to limit the range of possible solutions.

Given all of that, I think a non-munging solution would be more prob=
lematic for me than what IETF is already doing.

DF=
 



--c5411e534be64fcca287fd5a6562b657--


From nobody Mon Jun 15 22:39:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754353A1072 for ; Mon, 15 Jun 2020 22:39:01 -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, FREEMAIL_FROM=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=gmail.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 fPHa4aZbB67G for ; Mon, 15 Jun 2020 22:39:00 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 537573A1070 for ; Mon, 15 Jun 2020 22:39:00 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id c9so6493623uao.11 for ; Mon, 15 Jun 2020 22:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O9UTO6kOoJO7/ko6nE8bxy38iKrh4HqZ6NKTsZ/TC0k=; b=RiV4XsEQE6JafuTDp0HaT6TNOBwxUmID/ueOErgRaWNZOC1OGtKP8lG+Ic46SqyLUd 7HXgTGQ2jKZFywjIfBpgoo+0pMOYDz756kgYUeshLouzcFO3flv5S0ckRy3l0XXZd+53 y/2YLoqlZaLbQRfdqxTgBDmFJ/FOkZEmbrExIJgkCE179LdFLrtrZGifTX0ASero+tzL 25YgK0UCGCBYYM1Tdk2UjjJ0pm/vQXAgXd7o/BPSSOgS1QnvjpvWk6CuAK+PKPK3G02f 8CHAIMdtup5PJwxrL2p+y+Mu0vRU08O6YhffMM76lBcv8f7QwT5UT8ppSrqxLlLdXGKi 3AOg==
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=O9UTO6kOoJO7/ko6nE8bxy38iKrh4HqZ6NKTsZ/TC0k=; b=Cm8ZnxJqCiEk0aHqRsMwgKX+asXpAxjka09WEE1cpg9YZmhs44omdAQeoNYitn9Q/5 DlwtOz43gQHK4JeSMo0KYVa4tv1gP8Ozhnw5MqV9A1/nLKMCykFTsfMiVLW7QBGvJTXG mviYqrbebfjN7n6Zops4SPQjEMMXDpF6DVfwO3RdfeMI7xCdaTesG5wFzo7NvPLvacKH GKtMCKqattplY4gpGI4Zixt9FRQ07x0pfJd/Sc4ru20S4QwMye0SSXhIoufz8XETqvVQ 7Oob5OKXuyDmZLJ891VpjG4CkHH/kTlEaUrch/b3rdW6tW5SFnMkubyakZ8VTXX7GG33 bCYg==
X-Gm-Message-State: AOAM5309vpsAyKDZ1oLtWyzsOCvfwDAjw4mE9c519DiwgDlss9ZyM6c+ 3PDHuVhICSUiOvObxPSIDTCsCUHqtnklrSkKDG9G+w==
X-Google-Smtp-Source: ABdhPJx6fudMxuKLOoGM36b+2/TjOUyxlh+qm5362TBxdT8RrjzWDdM1h9Y5PgdCDDTsmfIwdU5wEvFdzHIPBmuUi/A=
X-Received: by 2002:ab0:21c5:: with SMTP id u5mr660523uan.101.1592285939220; Mon, 15 Jun 2020 22:38:59 -0700 (PDT)
MIME-Version: 1.0
References:   <8a575da6-bc37-4824-9166-b68bfa430013@www.fastmail.com> <58be1989-18ab-e151-e411-47f357719d27@bluepopcorn.net>
In-Reply-To: <58be1989-18ab-e151-e411-47f357719d27@bluepopcorn.net>
From: "Murray S. Kucherawy" 
Date: Mon, 15 Jun 2020 22:38:48 -0700
Message-ID: 
To: Jim Fenton 
Cc: IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 05:39:01 -0000

On Fri, Jun 12, 2020 at 5:02 PM Jim Fenton  wrote:
> About a year ago, I had suggested [1] that the reporting and policy
> mechanisms of DMARC be split, and was, I think, the only one supporting
> that idea. There were quite a few comments along the line of, "it's not
> broken, so why should we go to the trouble?"

If I was not on the record before as believing such a split is a good
idea, I am now.

-MSK, just participating


From nobody Mon Jun 15 23:01:15 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF363A1088 for ; Mon, 15 Jun 2020 23:01:13 -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, FREEMAIL_FROM=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=gmail.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 jOeC5PdzOFEa for ; Mon, 15 Jun 2020 23:01:12 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 01DE23A1089 for ; Mon, 15 Jun 2020 23:01:11 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id v25so6520977uau.4 for ; Mon, 15 Jun 2020 23:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fwwBXmQ/6F5R9kwnZHqc1nSwPPgO1fD9e677akUA4xc=; b=nYO5lDcdCpy71t700ulccoUnHXZaemSFm3WqCn6JejsVBgU/U0xluqmgxJbpydlyhm jFmR1HaYIYNDzHVUuZA8cCE2cDit3cGT9yf+wfJuGA1CEl1vqbFLQY31qeV+TRI18dpJ 6/NcTmsGO4IYGfvBVqLnYppCyR8Dd0yPyvuzBYUjNnRotm0/o4Xall+ixX+FaMja5wEH VhS6VcTkzpIJnEDzZf6yVyyt64eYn+3/pHq3wcq9ARS8AFna5lVcKKQQUJBJ7yUS4JWe p+s6gPuTcZGos4XSuI+/r/od/JtwwbeG6ijaVKent5Mcb8MgdjNvQEoiV/zP64O8CRRo r9wg==
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=fwwBXmQ/6F5R9kwnZHqc1nSwPPgO1fD9e677akUA4xc=; b=EEEGLeFSi+Jr+aTAZe0q+G44nASMzRJ31a7Dgg29Wi45/RihF9SwXt1Mo3DMpeCphk FdgliODa7U5FQSy38ohWXXWSg94aI5c2D9dd1htnTsI/Xgc977PT3gRFQvaxW/AcQEC6 wScyKI4sPdAnTk4UtEhSVdwQObx4Q6H8WPmR+qQsrqyF0nyyzVR6QcxyxFbk3lyl/TUd JHlGbgSvrcnDPzHu4urCFwrJ7l58UHJShtPRD5q2oBG+vTdzgW7/NwfPeeuQ14eDaPc0 qParn+WPDn3/GZGazEOI7usysD8/mjfrNz8O1ESM8XDzQZFDmIsmLGgQu6cSXtUIqj9J UX5A==
X-Gm-Message-State: AOAM533muW3rhe0uZ/ycH1u1jJxJd6sR1NXpaatqxV1zpS0FTHKc1iDP rD7Ih+U93m86FgB2KZz+uaQ6yWnRRRMw160pdb8Pzw==
X-Google-Smtp-Source: ABdhPJz6a93e/IbNCn0xIamPHJdsBGZzIxkASpbA5HzKiD3sUscMKHcaXkx26ccic4Ev2BYES1gDsUHRNSb/cmgQ0IM=
X-Received: by 2002:ab0:300c:: with SMTP id f12mr684731ual.76.1592287270939; Mon, 15 Jun 2020 23:01:10 -0700 (PDT)
MIME-Version: 1.0
References:  <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr>  
In-Reply-To: 
From: "Murray S. Kucherawy" 
Date: Mon, 15 Jun 2020 23:00:59 -0700
Message-ID: 
To: devel2020@baptiste-carvello.net
Cc: IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 06:01:14 -0000

On Sun, Jun 14, 2020 at 7:09 AM  wrote:
> Thanks for you honesty. Then the relevant question is whether open and
> interoperable standards still matter, or if they should be replaced by
> proprietary web apps one feature at a time.

Both have been around for a long time now and I've seen no evidence
that the Internet public at large is keen to make such a wholesale
migration.

We apparently really, really like our mailing lists.

-MSK, hatless


From nobody Tue Jun 16 10:26:43 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5E03A0793 for ; Tue, 16 Jun 2020 10:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=ScNzCish; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=xxVvBbie
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 gaSEvLBP7VHI for ; Tue, 16 Jun 2020 10:26:40 -0700 (PDT)
Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 B984E3A078A for ; Tue, 16 Jun 2020 10:26:39 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7550; t=1592328394; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=sBdDK+tlAR6LbctI0fjCLymqF08=; b=ScNzCisha0EopHdgLmEhmAQaLxUYSKZcMLldpmsvtHnXJCHoVPnL4H2fakNlKy 7efx0RdqsE47GYmbOrlM04gOLNNrvFd5SWRKWUST+3ZiBiazM60B1ihgl7V5xF6n DlfyObFJdNWmWdLEvLtqYKeGZRgKStmZcvMWKervy3qFw=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 16 Jun 2020 13:26:34 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3055696054.1.7152; Tue, 16 Jun 2020 13:26:34 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7550; t=1592328350; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hMH6FEV u8MShA29f5w+7XPgFNZBozBlr+D6j8Kubni8=; b=xxVvBbieNwut5q0zftI9mc4 9Y5tRnNOa++SsZWVmmhovPRmuWhXAPdYMbuuX590mACxB4XUSQcfto9WJNkWYeTY FCFApFMbm5KMZeCIng+Ru+Ukx0EcfbpLrD9Kh8HqHSTgAl8iDJ85WRjmRittTBA6 GkKzRGrGDVdH9PdAUYsA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 16 Jun 2020 13:25:50 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4062045156.1.38496; Tue, 16 Jun 2020 13:25:49 -0400
Message-ID: <5EE900C8.5050507@isdg.net>
Date: Tue, 16 Jun 2020 13:26:32 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <5EE65D11.3050107@isdg.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 17:26:43 -0000

Hi Brandon, some quick points:

1) I was 100% concentrating on the technical protocol aspects to make 
DMARC protocol complete. DMARC is currently not protocol complete. It 
does not address the failure scenarios related to 3rd party 
re(signers). It left loopholes that need to be closed.  The 
application aspects for administration is, in my technical view, a 
secondary consideration.  The protocol's framework need to complete.

2) If you suggest there are existing solutions to fill in the holes, 
then they need to be documented in the DMARC proposed standard.It 
can't be intentional "ignorant" about it.  This ignorance did not work 
with ADSP and it did not work with DMARC.

Based on your comments there would be a total of four methods to 
consider for implementors to offer:

1) Honor the DMARC policy. No Subscriptions, nor submissions from 
restrictive domains. Gandfather current members from restrictive 
domains as read-only members.

2) Give DKIM private Key to authorized (re)signer,

3) Use CNAME to share a key with authorized (re)signer, and

4) Use ATPS RFC6541

Note, I intentionally left out the horrible rewriting kludge. I would 
not encourage it.  Provide good protocol-complete solutions and 
kludges won't be necessary.


Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

On 6/15/2020 1:15 PM, Brandon Long wrote:
> I don't understand what adding authorized third party signatures will add.
>
> For a corporation, it may be possible to validate and approve a number of
> third party signers... right now, that's done via DNS by either extending
> SPF to include the third party, or giving the third party a DKIM key (or
> better, mapping a key into your domain name space with CNAME)... or even
> by smarthosting.
>
> Any email sending vendor has to support this at this point.  However, this
> doesn't handle the external mailing list case, or at best it works with just
> the largest providers or some limited number of lists, but I doubt our
> security department would approve some random open source list to send mail
> as the company.
>
> For a large mailbox provider, the set of potential third party vendors is
> very large, and would require an extensive vetting process to make it work,
> and even then, you've opened it up to security issues at the weakest link.
> This is basically Google's OAUTH API Verification process with estimates
> that the vendor security audit cost of $15-75k... and still wouldn't handle
> small mailing list providers.
>
> The reason third party signatures don't work for mailing lists is because
> they are a relay, not an origination service, and fundamentally third party
> signatures only work with origination services.
>
> One could say that the third party auth problem is the same with ARC, but
> there are two major differences.  For one, the question of whether to
> accept an ARC hop as valid is on the receiver, not the sender, which allows
> it to work with relays which are more known to the receiver than the sender.
> For two, ARC is saying something very different.  Third party auth is
> saying "this service can act as me" while ARC is saying "this service
> relayed the message
> without substantive changes".  It remains to be seen whether ARC is
> successful at this, of course.
>
> So, at best, third party auth for DKIM wil be a "new" way of giving a
> service access that no one will support for a long time, while there are
> existing
> mechanisms which work today for that.
>
> Brandon
>
> On Sun, Jun 14, 2020 at 10:23 AM Hector Santos  40isdg.net@dmarc.ietf.org> wrote:
>
>> When we look at DKIM and the DMARC protocol by exposing the boundary
>> conditions of the protocol, it helps with laying the groundwork for a
>> protocol-complete model.
>>
>> DKIM has three possible signature states:
>>
>> - NONE (no valid signature)
>> - 1PS (1st party valid signature, Author.domain == Signer.domain)
>> - 3PS (3rd party valid signature, Author.domain != Signer.domain)
>>
>> DMARC has three polices:
>>
>> - none
>> - quarantine
>> - reject
>>
>> With these 3x3=9 states, the following table with the boundary
>> conditions of the protocol is established with the expected and
>> potential actionable result:
>>
>>                           DMARC POLICY
>>        +===================================================+
>>        |////// | p=NONE     | p=QUARANTINE  | p=REJECT     |
>>        |===================================================|
>>     D  | NONE  | fail-pass  | fail-filter   | fail-reject  |
>>     K  |-------+------------+------------------------------|
>>     I  | 1PS   | pass       | pass          | pass         |
>>     M  |-------+------------+------------------------------|
>>        | 3PS   | fail-pass  | fail-filter   | fail-reject  |
>>        +===================================================+
>>
>> Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
>> SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states.
>>    For this exercise, we are assuming DMARC/SPF alignment is in play
>> and failure can be for any DMARC known reason including the 3PS failed
>> states.
>>
>> The states for DKIM none and 1PS are expected protocol conditions.
>> DMARC describes these conditions. But the DKIM 3PS conditions are not
>> described and are subject to questionable actions because of the
>> possible false positives results.
>>
>> The 3PS failures occur because of the dearth for an Authorized Third
>> party Signature protocol.  DMARC does not offer 3rd party signature
>> solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But
>> they did not restrict an ADD-ON extension to the protocol.
>>
>> ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and
>> when DMARC replaced ADSP, it equally applies to DMARC as well as an
>> extension.  We do not need to get into the specific ATPS protocol
>> details on how to authorize a 3rd party signer. Any "ATPS-like"
>> protocol will only need to answer one question:
>>
>>     Is the 3rd party (re)signer authorized?   Yes or NO
>>
>> With this consideration, the table has one additional 3PS-AUTH row
>> meaning Yes, the 3rd party (re)signer domain was authorized by the
>> author domain.
>>
>>
>>                      DMARC POLICY W/ ATPS
>>        +======================================================+
>>        |//////    | p=NONE     | p=QUARANTINE  | p=REJECT     |
>>        |======================================================|
>>     D  | NONE     | fail-pass  | fail-filter   | fail-reject  |
>>     K  |----------+------------+------------------------------|
>>     I  | 1PS      | pass       | pass          | pass         |
>>     M  |----------+------------+------------------------------|
>>        | 3PS      | fail-pass  | fail-filter   | fail-reject  |
>>        |----------+------------+------------------------------|
>>        | 3PS-AUTH | pass       | pass          | pass         |
>>        +======================================================+
>>
>> Overall, as it was originally conceived, the DKIM Policy model can not
>> ignore ATPS conditions because as you can see above, it would not be
>> protocol-complete -- it is missing the 3PS-AUTH conditions.
>>
>> While ADSP is a specific RFC proposed protocol, I am using it as an
>> acronym for any authorizing third party signature concept:
>>
>>      Result = DKIM_ATPS(author.domain, signer.domain)
>>
>> Lets finish that part of the DKIM model.
>>
>> Thanks
>>
>> [1] https://tools.ietf.orgy/html/rfc5617
>> [2] https://tools.ietf.org/html/rfc6541
>>
>> --
>> Hector Santos,
>> https://secure.santronics.com
>> https://twitter.com/hectorsantos



From nobody Tue Jun 16 11:17:43 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EDC3A082B for ; Tue, 16 Jun 2020 11:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xtKbDlsrJSVY for ; Tue, 16 Jun 2020 11:17:41 -0700 (PDT)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 D53B03A0829 for ; Tue, 16 Jun 2020 11:17:40 -0700 (PDT)
Received: by mail-vk1-xa34.google.com with SMTP id e1so5042642vkd.1 for ; Tue, 16 Jun 2020 11:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SvKcaoqo5oUoomBjgLF8Aj9rirunEbG/6tnLoZAsL+c=; b=TthA0jjSGDzwXI1Qvk9V+1ZtL4Z+6xIr4akdCQlGDrG9cRqJPB6sgeR0ZleZnmcqcB dFR1b4A+nQuD5zPb9aM02NO/l31/7jRL5nSORoV/r0kDwNVA3WVjE6/kTnoHt3kpjWwd ZtgswSckddGcHTHbVjUAB1LGd5g9Srea4MSToU4G+YLKrXV3SHCE7S87jqtXAIAqtxfh aRQlUiiCiMcT3qVzD1QtbiDsr3EJQ1a0ThxgvMA0oAcYSkYVScrsBPmJlmk8xxwu/jEe +AbxpqskrFI4ZPVH4uruFMuWkDRTGEEKzpNnhXr1JdHNwo8UTjOhgILYLBJnjkqdg0Vj +1+A==
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=SvKcaoqo5oUoomBjgLF8Aj9rirunEbG/6tnLoZAsL+c=; b=PC1rZaNbgRwFLlDMXarAB5fVtcpv8HXc1O/gYjMcEm8Rx7ERtc+DYMJp3PUCFSmPtY /MlQR5ZNluJfbf3K6qQecQjy+syAL2+D2qZiKW9usq8TLT+zLKYgEUAfsXjB9Z3zMZdL OlGC9mZ4hkcnIB717jZWhhd/nBiPH99AqNwHEEXPp9dTBR9bDAbApGwhVNJKWeuj4/4p NS5z8sYoTkKv/jBVo3hTfsA435TGmIJS0kiJeyLhcS/kbyXhWZMAdU0sxbmLReiOV7lT JLEDO+f6Wid0kzTrjgNhIqOdtJ4pSnM7UCnnyeh9pWCOIcWL8jPtF2rEVDwB5E5pFEAH Gr9Q==
X-Gm-Message-State: AOAM532KOjPa64MB5a7/vDJ5S7Pvg0fr6G9Ecg5UJ/4Ps0Pjss2O5L/+ qn7xBfvsp29Rr/dj1nGv1T4WSjWlsOPnLWC2gXwE
X-Google-Smtp-Source: ABdhPJx3ejXB+/zg4EMQRcVtT+Fp8sdaSsvfjYwjeiFNhvlVYowLzJ+PFQJHnLTKV1RwdMBnUavaFz+c9QDenfRo06g=
X-Received: by 2002:a1f:5cd0:: with SMTP id q199mr2847559vkb.34.1592331459285;  Tue, 16 Jun 2020 11:17:39 -0700 (PDT)
MIME-Version: 1.0
References:  <54cde9ba-317c-f921-647a-76cbcd3d5854@free.fr>   
In-Reply-To: 
From: Brandon Long 
Date: Tue, 16 Jun 2020 11:17:27 -0700
Message-ID: 
To: "Murray S. Kucherawy" 
Cc: devel2020@baptiste-carvello.net, IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000ff5a3605a8378e9b"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 18:17:42 -0000

--000000000000ff5a3605a8378e9b
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 15, 2020 at 11:01 PM Murray S. Kucherawy 
wrote:

> On Sun, Jun 14, 2020 at 7:09 AM  wrote:
> > Thanks for you honesty. Then the relevant question is whether open and
> > interoperable standards still matter, or if they should be replaced by
> > proprietary web apps one feature at a time.
>
> Both have been around for a long time now and I've seen no evidence
> that the Internet public at large is keen to make such a wholesale
> migration.
>
> We apparently really, really like our mailing lists.
>

I for one am always amazed how much people use web forums, which are almost
all universally worse at providing a reading interface or keeping people
up-to-date on new messages... which might be why most of the one's I look
at are nearly dead, maybe there are better ones that are active.

Brandon

--000000000000ff5a3605a8378e9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jun 15, 2020 at 11:01 PM Murr=
ay S. Kucherawy <superuser@gmail.=
com> wrote:
On Sun, Jun 14, 2020 at 7:09 AM <devel2020@baptiste-carvello.net> wr=
ote:

> Thanks for you honesty. Then the relevant question is whether open and=


> interoperable standards still matter, or if they should be replaced by=


> proprietary web apps one feature at a time.



Both have been around for a long time now and I've seen no evidence

that the Internet public at large is keen to make such a wholesale

migration.



We apparently really, really like our mailing lists.
<=
br>
I for one am always amazed how much people use web forums, wh=
ich are almost all universally worse at providing a reading interface or ke=
eping people up-to-date on new messages... which might be why most of the o=
ne's I look at are nearly dead, maybe there are better ones that are ac=
tive.

Brandon=C2=A0


--000000000000ff5a3605a8378e9b--


From nobody Tue Jun 16 11:19:43 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB33A0833 for ; Tue, 16 Jun 2020 11:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CAJa8y8Fmbu5 for ; Tue, 16 Jun 2020 11:19:39 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 DEC043A07E6 for ; Tue, 16 Jun 2020 11:19:38 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id x14so3679580uao.7 for ; Tue, 16 Jun 2020 11:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ijtcig4JIpxhSRFETuJLJNxilY3NSbo3flQxGS8nSJo=; b=DmUvFzUCLHce5EE5YDnd/7d1Oa52A30rt14MDqvCciqzSH+/ZwjTxytV8bkgdfuuaU SRyud3mgMi2TZphn9JHYEsLu/1bWrbKY9xMVkgpxL4D/OW/id8psu01bqTk3s3YkCI5a +/3AlKMDVyxdvDvBazubsO3foGl6iTg8NysC+zz+9EPw66FDj+rtsPODDMIcifuCZco8 uXzbxG3OCFopvW1p0CJjJtS5y1qpHC9hP8PqK65U34pDjHKWFmnDXMqorPzfFK8ZUJvm r32vbm/++BRas1TXfoiQc0l9qWHdxqhRntmTpo2XuECAc6OgaEPadCUfX6VArRWh0FXa L1IQ==
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=Ijtcig4JIpxhSRFETuJLJNxilY3NSbo3flQxGS8nSJo=; b=c0kY0Whv601WYLc3nATT14vlV4upDyjiGvsCU/lWqP1V8WMJM4y5bGbP3B9kWM8Wy7 i9XzUaJOKqE0Wq6wU2HaDGX/2++Qg4lweZY3g+/H8y6iE3ZuraSBFsfZqPn0jxF+RL3m rNlaojdEnrbYwPLe+WDfnIfyZ6gy8gmk+JWkB6nruafYJkHWft4DU4c0PZHQlMPu0v65 Tmn8cFoLt+VD3G5j1Xu31YhrxOh3Tw0IGvQIV6X6UuGEM+qaw6DXZ3wYKSRLJReGc/v8 Iep4+H6Yz2qeC/VxJT3PKGYunPRheJPkbifTTNLl9/rHnZ+aDWzGi7j8B9rxnASBjs1D gCBw==
X-Gm-Message-State: AOAM533UtoLNjlWBhRo1slKR6N0DNpzbdS0lGyGUWhoLsmI+SgX3hTFf Qmc5l9/TbJO+jvReEOQLbgTlvjDBTiIj3Y8xgLdZalQFVw==
X-Google-Smtp-Source: ABdhPJyHO8dyk/FRlNN8iVEQGhhbbYYHt/99P2O3htLIkKNfxN/ibuvXL0ptGUQzLucL2oFsovByLs1ouB9CJeoPxAU=
X-Received: by 2002:ab0:5642:: with SMTP id z2mr3197458uaa.6.1592331577470; Tue, 16 Jun 2020 11:19:37 -0700 (PDT)
MIME-Version: 1.0
References: <5EE65D11.3050107@isdg.net>  <5EE900C8.5050507@isdg.net>
In-Reply-To: <5EE900C8.5050507@isdg.net>
From: Brandon Long 
Date: Tue, 16 Jun 2020 11:19:25 -0700
Message-ID: 
To: Hector Santos 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000000ac37f05a837960b"
Archived-At: 
Subject: Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 18:19:41 -0000

--0000000000000ac37f05a837960b
Content-Type: text/plain; charset="UTF-8"

So you think we should include
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in
the actual spec?

Brandon

On Tue, Jun 16, 2020 at 10:26 AM Hector Santos  wrote:

> Hi Brandon, some quick points:
>
> 1) I was 100% concentrating on the technical protocol aspects to make
> DMARC protocol complete. DMARC is currently not protocol complete. It
> does not address the failure scenarios related to 3rd party
> re(signers). It left loopholes that need to be closed.  The
> application aspects for administration is, in my technical view, a
> secondary consideration.  The protocol's framework need to complete.
>
> 2) If you suggest there are existing solutions to fill in the holes,
> then they need to be documented in the DMARC proposed standard.It
> can't be intentional "ignorant" about it.  This ignorance did not work
> with ADSP and it did not work with DMARC.
>
> Based on your comments there would be a total of four methods to
> consider for implementors to offer:
>
> 1) Honor the DMARC policy. No Subscriptions, nor submissions from
> restrictive domains. Gandfather current members from restrictive
> domains as read-only members.
>
> 2) Give DKIM private Key to authorized (re)signer,
>
> 3) Use CNAME to share a key with authorized (re)signer, and
>
> 4) Use ATPS RFC6541
>
> Note, I intentionally left out the horrible rewriting kludge. I would
> not encourage it.  Provide good protocol-complete solutions and
> kludges won't be necessary.
>
>
> Thanks
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
> On 6/15/2020 1:15 PM, Brandon Long wrote:
> > I don't understand what adding authorized third party signatures will
> add.
> >
> > For a corporation, it may be possible to validate and approve a number of
> > third party signers... right now, that's done via DNS by either extending
> > SPF to include the third party, or giving the third party a DKIM key (or
> > better, mapping a key into your domain name space with CNAME)... or even
> > by smarthosting.
> >
> > Any email sending vendor has to support this at this point.  However,
> this
> > doesn't handle the external mailing list case, or at best it works with
> just
> > the largest providers or some limited number of lists, but I doubt our
> > security department would approve some random open source list to send
> mail
> > as the company.
> >
> > For a large mailbox provider, the set of potential third party vendors is
> > very large, and would require an extensive vetting process to make it
> work,
> > and even then, you've opened it up to security issues at the weakest
> link.
> > This is basically Google's OAUTH API Verification process with estimates
> > that the vendor security audit cost of $15-75k... and still wouldn't
> handle
> > small mailing list providers.
> >
> > The reason third party signatures don't work for mailing lists is because
> > they are a relay, not an origination service, and fundamentally third
> party
> > signatures only work with origination services.
> >
> > One could say that the third party auth problem is the same with ARC, but
> > there are two major differences.  For one, the question of whether to
> > accept an ARC hop as valid is on the receiver, not the sender, which
> allows
> > it to work with relays which are more known to the receiver than the
> sender.
> > For two, ARC is saying something very different.  Third party auth is
> > saying "this service can act as me" while ARC is saying "this service
> > relayed the message
> > without substantive changes".  It remains to be seen whether ARC is
> > successful at this, of course.
> >
> > So, at best, third party auth for DKIM wil be a "new" way of giving a
> > service access that no one will support for a long time, while there are
> > existing
> > mechanisms which work today for that.
> >
> > Brandon
> >
> > On Sun, Jun 14, 2020 at 10:23 AM Hector Santos  > 40isdg.net@dmarc.ietf.org> wrote:
> >
> >> When we look at DKIM and the DMARC protocol by exposing the boundary
> >> conditions of the protocol, it helps with laying the groundwork for a
> >> protocol-complete model.
> >>
> >> DKIM has three possible signature states:
> >>
> >> - NONE (no valid signature)
> >> - 1PS (1st party valid signature, Author.domain == Signer.domain)
> >> - 3PS (3rd party valid signature, Author.domain != Signer.domain)
> >>
> >> DMARC has three polices:
> >>
> >> - none
> >> - quarantine
> >> - reject
> >>
> >> With these 3x3=9 states, the following table with the boundary
> >> conditions of the protocol is established with the expected and
> >> potential actionable result:
> >>
> >>                           DMARC POLICY
> >>        +===================================================+
> >>        |////// | p=NONE     | p=QUARANTINE  | p=REJECT     |
> >>        |===================================================|
> >>     D  | NONE  | fail-pass  | fail-filter   | fail-reject  |
> >>     K  |-------+------------+------------------------------|
> >>     I  | 1PS   | pass       | pass          | pass         |
> >>     M  |-------+------------+------------------------------|
> >>        | 3PS   | fail-pass  | fail-filter   | fail-reject  |
> >>        +===================================================+
> >>
> >> Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
> >> SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states.
> >>    For this exercise, we are assuming DMARC/SPF alignment is in play
> >> and failure can be for any DMARC known reason including the 3PS failed
> >> states.
> >>
> >> The states for DKIM none and 1PS are expected protocol conditions.
> >> DMARC describes these conditions. But the DKIM 3PS conditions are not
> >> described and are subject to questionable actions because of the
> >> possible false positives results.
> >>
> >> The 3PS failures occur because of the dearth for an Authorized Third
> >> party Signature protocol.  DMARC does not offer 3rd party signature
> >> solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But
> >> they did not restrict an ADD-ON extension to the protocol.
> >>
> >> ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and
> >> when DMARC replaced ADSP, it equally applies to DMARC as well as an
> >> extension.  We do not need to get into the specific ATPS protocol
> >> details on how to authorize a 3rd party signer. Any "ATPS-like"
> >> protocol will only need to answer one question:
> >>
> >>     Is the 3rd party (re)signer authorized?   Yes or NO
> >>
> >> With this consideration, the table has one additional 3PS-AUTH row
> >> meaning Yes, the 3rd party (re)signer domain was authorized by the
> >> author domain.
> >>
> >>
> >>                      DMARC POLICY W/ ATPS
> >>        +======================================================+
> >>        |//////    | p=NONE     | p=QUARANTINE  | p=REJECT     |
> >>        |======================================================|
> >>     D  | NONE     | fail-pass  | fail-filter   | fail-reject  |
> >>     K  |----------+------------+------------------------------|
> >>     I  | 1PS      | pass       | pass          | pass         |
> >>     M  |----------+------------+------------------------------|
> >>        | 3PS      | fail-pass  | fail-filter   | fail-reject  |
> >>        |----------+------------+------------------------------|
> >>        | 3PS-AUTH | pass       | pass          | pass         |
> >>        +======================================================+
> >>
> >> Overall, as it was originally conceived, the DKIM Policy model can not
> >> ignore ATPS conditions because as you can see above, it would not be
> >> protocol-complete -- it is missing the 3PS-AUTH conditions.
> >>
> >> While ADSP is a specific RFC proposed protocol, I am using it as an
> >> acronym for any authorizing third party signature concept:
> >>
> >>      Result = DKIM_ATPS(author.domain, signer.domain)
> >>
> >> Lets finish that part of the DKIM model.
> >>
> >> Thanks
> >>
> >> [1] https://tools.ietf.orgy/html/rfc5617
> >> [2] https://tools.ietf.org/html/rfc6541
> >>
> >> --
> >> Hector Santos,
> >> https://secure.santronics.com
> >> https://twitter.com/hectorsantos
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

--0000000000000ac37f05a837960b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


So you think we should include=C2=A0https://wiki=
.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail=C2=A0in th=
e actual spec?

Brandon

On Tue, Jun 16, 2020 at 10:2=
6 AM Hector Santos <hsantos=3D40isdg.net@dmarc.ietf.org> wrote:
Hi Brandon, some quick points:



1) I was 100% concentrating on the technical protocol aspects to make 

DMARC protocol complete. DMARC is currently not protocol complete. It 

does not address the failure scenarios related to 3rd party 

re(signers). It left loopholes that need to be closed.=C2=A0 The 

application aspects for administration is, in my technical view, a 

secondary consideration.=C2=A0 The protocol's framework need to complet=
e.



2) If you suggest there are existing solutions to fill in the holes, 

then they need to be documented in the DMARC proposed standard.It 

can't be intentional "ignorant" about it.=C2=A0 This ignoranc=
e did not work 

with ADSP and it did not work with DMARC.



Based on your comments there would be a total of four methods to 

consider for implementors to offer:



1) Honor the DMARC policy. No Subscriptions, nor submissions from 

restrictive domains. Gandfather current members from restrictive 

domains as read-only members.



2) Give DKIM private Key to authorized (re)signer,



3) Use CNAME to share a key with authorized (re)signer, and



4) Use ATPS RFC6541



Note, I intentionally left out the horrible rewriting kludge. I would 

not encourage it.=C2=A0 Provide good protocol-complete solutions and 

kludges won't be necessary.





Thanks



-- 

Hector Santos,

https://secure.santronics.com

https://twitter.com/hectorsantos



On 6/15/2020 1:15 PM, Brandon Long wrote:

> I don't understand what adding authorized third party signatures w=
ill add.

>

> For a corporation, it may be possible to validate and approve a number=
 of

> third party signers... right now, that's done via DNS by either ex=
tending

> SPF to include the third party, or giving the third party a DKIM key (=
or

> better, mapping a key into your domain name space with CNAME)... or ev=
en

> by smarthosting.

>

> Any email sending vendor has to support this at this point.=C2=A0 Howe=
ver, this

> doesn't handle the external mailing list case, or at best it works=
 with just

> the largest providers or some limited number of lists, but I doubt our=


> security department would approve some random open source list to send=
 mail

> as the company.

>

> For a large mailbox provider, the set of potential third party vendors=
 is

> very large, and would require an extensive vetting process to make it =
work,

> and even then, you've opened it up to security issues at the weake=
st link.

> This is basically Google's OAUTH API Verification process with est=
imates

> that the vendor security audit cost of $15-75k... and still wouldn'=
;t handle

> small mailing list providers.

>

> The reason third party signatures don't work for mailing lists is =
because

> they are a relay, not an origination service, and fundamentally third =
party

> signatures only work with origination services.

>

> One could say that the third party auth problem is the same with ARC, =
but

> there are two major differences.=C2=A0 For one, the question of whethe=
r to

> accept an ARC hop as valid is on the receiver, not the sender, which a=
llows

> it to work with relays which are more known to the receiver than the s=
ender.

> For two, ARC is saying something very different.=C2=A0 Third party aut=
h is

> saying "this service can act as me" while ARC is saying &quo=
t;this service

> relayed the message

> without substantive changes".=C2=A0 It remains to be seen whether=
 ARC is

> successful at this, of course.

>

> So, at best, third party auth for DKIM wil be a "new" way of=
 giving a

> service access that no one will support for a long time, while there a=
re

> existing

> mechanisms which work today for that.

>

> Brandon

>

> On Sun, Jun 14, 2020 at 10:23 AM Hector Santos <hsantos=3D

> 40isdg.=
net@dmarc.ietf.org> wrote:

>

>> When we look at DKIM and the DMARC protocol by exposing the bounda=
ry

>> conditions of the protocol, it helps with laying the groundwork fo=
r a

>> protocol-complete model.

>>

>> DKIM has three possible signature states:

>>

>> - NONE (no valid signature)

>> - 1PS (1st party valid signature, Author.domain =3D=3D Signer.doma=
in)

>> - 3PS (3rd party valid signature, Author.domain !=3D Signer.domain=
)

>>

>> DMARC has three polices:

>>

>> - none

>> - quarantine

>> - reject

>>

>> With these 3x3=3D9 states, the following table with the boundary
>> conditions of the protocol is established with the expected and
>> potential actionable result:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DMARC POLICY

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |////// | p=3DNONE=C2=A0 =C2=A0 =C2=A0|=
 p=3DQUARANTINE=C2=A0 | p=3DREJECT=C2=A0 =C2=A0 =C2=A0|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|

>>=C2=A0 =C2=A0 =C2=A0D=C2=A0 | NONE=C2=A0 | fail-pass=C2=A0 | fail-f=
ilter=C2=A0 =C2=A0| fail-reject=C2=A0 |

>>=C2=A0 =C2=A0 =C2=A0K=C2=A0 |-------+------------+-----------------=
-------------|

>>=C2=A0 =C2=A0 =C2=A0I=C2=A0 | 1PS=C2=A0 =C2=A0| pass=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|

>>=C2=A0 =C2=A0 =C2=A0M=C2=A0 |-------+------------+-----------------=
-------------|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 3PS=C2=A0 =C2=A0| fail-pass=C2=A0 | f=
ail-filter=C2=A0 =C2=A0| fail-reject=C2=A0 |

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

>>

>> Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
>> SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total stat=
es.

>>=C2=A0 =C2=A0 For this exercise, we are assuming DMARC/SPF alignmen=
t is in play

>> and failure can be for any DMARC known reason including the 3PS fa=
iled

>> states.

>>

>> The states for DKIM none and 1PS are expected protocol conditions.=


>> DMARC describes these conditions. But the DKIM 3PS conditions are =
not

>> described and are subject to questionable actions because of the
>> possible false positives results.

>>

>> The 3PS failures occur because of the dearth for an Authorized Thi=
rd

>> party Signature protocol.=C2=A0 DMARC does not offer 3rd party sig=
nature

>> solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. Bu=
t

>> they did not restrict an ADD-ON extension to the protocol.

>>

>> ATPS RFC6541 [2] was one such add-on proposed extension to ADSP an=
d

>> when DMARC replaced ADSP, it equally applies to DMARC as well as a=
n

>> extension.=C2=A0 We do not need to get into the specific ATPS prot=
ocol

>> details on how to authorize a 3rd party signer. Any "ATPS-lik=
e"

>> protocol will only need to answer one question:

>>

>>=C2=A0 =C2=A0 =C2=A0Is the 3rd party (re)signer authorized?=C2=A0 =
=C2=A0Yes or NO

>>

>> With this consideration, the table has one additional 3PS-AUTH row=


>> meaning Yes, the 3rd party (re)signer domain was authorized by the=


>> author domain.

>>

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 DMARC POLICY W/ ATPS

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |//////=C2=A0 =C2=A0 | p=3DNONE=C2=A0 =
=C2=A0 =C2=A0| p=3DQUARANTINE=C2=A0 | p=3DREJECT=C2=A0 =C2=A0 =C2=A0|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|

>>=C2=A0 =C2=A0 =C2=A0D=C2=A0 | NONE=C2=A0 =C2=A0 =C2=A0| fail-pass=
=C2=A0 | fail-filter=C2=A0 =C2=A0| fail-reject=C2=A0 |

>>=C2=A0 =C2=A0 =C2=A0K=C2=A0 |----------+------------+--------------=
----------------|

>>=C2=A0 =C2=A0 =C2=A0I=C2=A0 | 1PS=C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =
=C2=A0 =C2=A0 =C2=A0| pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|

>>=C2=A0 =C2=A0 =C2=A0M=C2=A0 |----------+------------+--------------=
----------------|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 3PS=C2=A0 =C2=A0 =C2=A0 | fail-pass=
=C2=A0 | fail-filter=C2=A0 =C2=A0| fail-reject=C2=A0 |

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------+------------+--------------=
----------------|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 3PS-AUTH | pass=C2=A0 =C2=A0 =C2=A0 =
=C2=A0| pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | pass=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

>>

>> Overall, as it was originally conceived, the DKIM Policy model can=
 not

>> ignore ATPS conditions because as you can see above, it would not =
be

>> protocol-complete -- it is missing the 3PS-AUTH conditions.

>>

>> While ADSP is a specific RFC proposed protocol, I am using it as a=
n

>> acronym for any authorizing third party signature concept:

>>

>>=C2=A0 =C2=A0 =C2=A0 Result =3D DKIM_ATPS(author.domain, signer.dom=
ain)

>>

>> Lets finish that part of the DKIM model.

>>

>> Thanks

>>

>> [1] https://tools.ietf.orgy/html/rfc5617

>> [2] https://tools.ietf.org/html/rfc6541

>>

>> --

>> Hector Santos,

>> https://secure.santronics.com

>> https://twitter.com/hectorsantos





_______________________________________________

dmarc mailing list

dmarc@ietf.org

https://www.ietf.org/mailman/listinfo/dmarc




--0000000000000ac37f05a837960b--


From nobody Tue Jun 16 11:46:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080B23A1231 for ; Tue, 16 Jun 2020 11:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=h1tzC/Hc; dkim=pass (1536-bit key) header.d=taugh.com header.b=B3/uKKPd
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 Sk9ytultqEzq for ; Tue, 16 Jun 2020 11:46:30 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F1EC53A1230 for ; Tue, 16 Jun 2020 11:46:29 -0700 (PDT)
Received: (qmail 36067 invoked from network); 16 Jun 2020 18:46:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8ce1.5ee91384.k2006; bh=fONHDBZUHKQ6sVUtl4GhpaSwQxsNVoB56V7iyL9/oMI=; b=h1tzC/HcgvSfmCCZhl0fQ2a8An+vRDbRRTog67AnWyJEnLJiui6d/hKT7KO39okO8mx+wYuA5Gffzfq2LPWbixJ0d6GuMGvEh+lAofQZ9EhJoE6w9Y2l5Cw2m13H1IvbKxXTPgtz+LC7ycLSX8/lFgpEBSarsNBD5WFxHkHvNHsPQrqblzmblRsgb1QCVnoDrfdXzQzVZd+mN/Aq6soOtCrJxOZnGU04hfoT4IB3NFD/toOlle/MjnYgprF2QxN+
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8ce1.5ee91384.k2006; bh=fONHDBZUHKQ6sVUtl4GhpaSwQxsNVoB56V7iyL9/oMI=; b=B3/uKKPdUGeXFLT9rUIc7m2nuxUQDKi++V9i6mfx/3KZmhG0UaRSOOTfuPlYO8ICxfFfK0qT1OKa0uwGjCLkTSmZSnoJTLWp0WIcluY7IeqQXqCNuap0WaBHBualjZUfRstWAHZ2F3zX7uezAfCSWKJhbtYrjYHTegx8xvjePLu6XQAOVh04HrZM3hzLNBi9b8suNziKgOVh1BKFA+sjK4GPs+qydTUZe22eDQIEpUo9kc+DwJhVcfH25cMu3/i9
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jun 2020 18:46:27 -0000
Received: by ary.qy (Postfix, from userid 501) id 511851AC9337; Tue, 16 Jun 2020 14:46:28 -0400 (EDT)
Date: 16 Jun 2020 14:46:28 -0400
Message-Id: <20200616184628.511851AC9337@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: blong@google.com
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 18:46:32 -0000

In article  you write:
>I for one am always amazed how much people use web forums, which are almost
>all universally worse at providing a reading interface or keeping people
>up-to-date on new messages... which might be why most of the one's I look
>at are nearly dead, maybe there are better ones that are active.

Well, there's Reddit, and um, er.  Flyertalk, I guess.

One thing web forum fans seem to miss is how poorly they scale. I
subscribe to at least 150 mailing lists, most of which are only active
occasionally. As mailing lists, that works fine. The busier ones go
into separate folders, less busy into a general folder, and MUAs tell
me which folders have new messages so I can scan through all of my
list mail about as fast as I can hit the tab key to move on to the
next message. This works equally well for public and private lists.

In theory RSS or Atom does this for web forums, in practice, it's
amazing how lousy their RSS support is and how lame RSS readers are
for public fora, and hopeless for private ones where you have to log in. 

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Tue Jun 16 12:09:16 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB23A125E for ; Tue, 16 Jun 2020 12:09:14 -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, 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 (1024-bit key) header.d=mrochek.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 aG-rbvDGaJHu for ; Tue, 16 Jun 2020 12:09:13 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 54DFE3A125C for ; Tue, 16 Jun 2020 12:09:13 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RM53NJ6XXS006TH4@mauve.mrochek.com> for dmarc@ietf.org; Tue, 16 Jun 2020 12:04:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712;  t=1592334250; bh=6lp6eU5ONpDgLprTadpWHn65RnzfwEqXLsRDKS/DSwE=;  h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=Bk2V4ftNsKXdHcwL7aI/4NaX6MkGv6wUp1XBHX3H2nvcbBol8jBzPfVGCCbCYcNuL rLRNVdO7XOP4Ofgwyx8sQ0FlAqUYukDVbpSMco9FXNc6Bk6p0N6IKh8zsPqygVAzIF 2YwcuFYOZvsgj/GJ78Og0IlCPbMWfC4LPbiBmUjE=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RM15IA1CK0000059@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 16 Jun 2020 12:04:07 -0700 (PDT)
From: ned+dmarc@mrochek.com
Cc: dmarc@ietf.org, blong@google.com
Message-id: <01RM53NHOQG0000059@mauve.mrochek.com>
Date: Tue, 16 Jun 2020 11:53:22 -0700 (PDT)
In-reply-to: "Your message dated Tue, 16 Jun 2020 14:46:28 -0400" <20200616184628.511851AC9337@ary.qy>
References:  <20200616184628.511851AC9337@ary.qy>
To: John Levine 
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 19:09:14 -0000

> In article  you write:
> >I for one am always amazed how much people use web forums, which are almost
> >all universally worse at providing a reading interface or keeping people
> >up-to-date on new messages... which might be why most of the one's I look
> >at are nearly dead, maybe there are better ones that are active.

> Well, there's Reddit, and um, er.  Flyertalk, I guess.

> One thing web forum fans seem to miss is how poorly they scale. I
> subscribe to at least 150 mailing lists, most of which are only active
> occasionally. As mailing lists, that works fine. The busier ones go
> into separate folders, less busy into a general folder, and MUAs tell
> me which folders have new messages so I can scan through all of my
> list mail about as fast as I can hit the tab key to move on to the
> next message. This works equally well for public and private lists.

> In theory RSS or Atom does this for web forums, in practice, it's
> amazing how lousy their RSS support is and how lame RSS readers are
> for public fora, and hopeless for private ones where you have to log in.

And that assumes the site supports RSS/Atom. Many don't.

The other problem with all of these tools is that someone else gets to
decide how to organize your life. If you decide that two different fora
should be grouped together, good luck getting your reader to do that for
you.

But Slack is the true nadir of usability in this regard. I have dozens of
channels I need to monitor, the breakdown of same is not remotely aligned with
how I would prefer to consume them. Add in a complete crap UI, and I honestly
can't think of a mail UI I've used that's worse. Not ever.

				Ned


From nobody Tue Jun 16 16:16:18 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4423A0A3B for ; Tue, 16 Jun 2020 16:16:16 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=dWlTXLVB; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mtAHx5g5
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 xyy3R4gpExhd for ; Tue, 16 Jun 2020 16:16:15 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BF73A0A38 for ; Tue, 16 Jun 2020 16:16:15 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 1C338F802B2 for ; Tue, 16 Jun 2020 19:16:14 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1592349373; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fJou5CDFnqfKaGprjXr63NFPJ/xRTtYjsBYVbO0ytgY=; b=dWlTXLVBzC55lBsYB9bmJmp4D1F9YXYosAJnUrtovBazs9Oitvvr+sDVPh3FnBuvTpUBb 3mPT2Kd6VYj8RI0DA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1592349373; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fJou5CDFnqfKaGprjXr63NFPJ/xRTtYjsBYVbO0ytgY=; b=mtAHx5g5mLtK1TFR4pee5BAOzC9BSUO/1Dqe2WYgnOKBeTyfCLYg4NCHz6ifV1PNTMgpH 2jGv1vooYWI28MSuFTAKqNKlVTMHHChKq8sMUTKk0bYOB8RotZ3RD3N/uIowBJPQ0d+38AB IaiUQGTgkFj7oF99/uy0/C3m7rgU7kyauvKWEMxo2Ko5tO78iKLkmq9hTSR/SbhPzO4u5Rp HTZG0qR3aTkYji8+XbByaHSP+pVZymYK8EXrQXdZREJWrt+14B6ERJ3PsQEQGCw8Di5btue hg3q9HoJyNkKoukHpaB/Xd4Te82RseoWg5bwqXh7o+YhAm/ArfxcnwaxanNQ==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id CDA8DF800A8 for ; Tue, 16 Jun 2020 19:16:13 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Tue, 16 Jun 2020 19:16:13 -0400
Message-ID: <4994686.lTFntC5mhR@zini-1880>
In-Reply-To: <01RM53NHOQG0000059@mauve.mrochek.com>
References:  <20200616184628.511851AC9337@ary.qy> <01RM53NHOQG0000059@mauve.mrochek.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 23:16:17 -0000

On Tuesday, June 16, 2020 2:53:22 PM EDT ned+dmarc@mrochek.com wrote:
> > In article 
 you 
write:
> > >I for one am always amazed how much people use web forums, which are
> > >almost
> > >all universally worse at providing a reading interface or keeping people
> > >up-to-date on new messages... which might be why most of the one's I look
> > >at are nearly dead, maybe there are better ones that are active.
> > 
> > Well, there's Reddit, and um, er.  Flyertalk, I guess.
> > 
> > One thing web forum fans seem to miss is how poorly they scale. I
> > subscribe to at least 150 mailing lists, most of which are only active
> > occasionally. As mailing lists, that works fine. The busier ones go
> > into separate folders, less busy into a general folder, and MUAs tell
> > me which folders have new messages so I can scan through all of my
> > list mail about as fast as I can hit the tab key to move on to the
> > next message. This works equally well for public and private lists.
> > 
> > In theory RSS or Atom does this for web forums, in practice, it's
> > amazing how lousy their RSS support is and how lame RSS readers are
> > for public fora, and hopeless for private ones where you have to log in.
> 
> And that assumes the site supports RSS/Atom. Many don't.
> 
> The other problem with all of these tools is that someone else gets to
> decide how to organize your life. If you decide that two different fora
> should be grouped together, good luck getting your reader to do that for
> you.
> 
> But Slack is the true nadir of usability in this regard. I have dozens of
> channels I need to monitor, the breakdown of same is not remotely aligned
> with how I would prefer to consume them. Add in a complete crap UI, and I
> honestly can't think of a mail UI I've used that's worse. Not ever.

It's like someone took IRC and decided to actively worsen it.

Scott K




From nobody Wed Jun 17 02:23:37 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D383A083D for ; Wed, 17 Jun 2020 02:23:34 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 bBIjhDvDs2oi for ; Wed, 17 Jun 2020 02:23:33 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 4F3BA3A083C for ; Wed, 17 Jun 2020 02:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592385810; bh=pCHuSaFrY48TmveX7u5uJ+r/IvmvV38NKd3auwR+NIU=; l=1572; h=To:References:From:Date:In-Reply-To; b=CkZ1ybkpOnGRolFLXbIX3nWpvrA9ffkmLAo7/pI+xFRjzH42CIisgw/OFPmWhRcV6 mtsbXaRJ73N9r9bzVcSq5pqXF4bLbktZcv4PW1c8Q2pmjHJuSk+9Hq+1nf+dpRi5HQ t4z5Dcwm5Tnu/BVnNJEIe5UeEghFmkWpVI62si29hOQQNJEvPS0iAGadUkfQ/
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005EE9E112.00005C7F; Wed, 17 Jun 2020 11:23:30 +0200
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop>
From: Alessandro Vesely 
Message-ID: <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it>
Date: Wed, 17 Jun 2020 11:23:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2598929.Ph2NfEyP8u@sk-desktop>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 09:23:35 -0000

On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote:
> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
> 
>> Even if you ignore my line of reasoning, I think that Ale made in the OP a
>> compelling case that the practice of From rewriting is here to stay.
> 
> As a practical matter, that's certainly true for the short to medium term, but
> it doesn't follow that the IETF should standardize the practice.


There are a few shortcomings of From: rewriting, which could be mitigated 
adopting suitable conventions.  For example, MUAs' replying to author, or 
storing rewritten addresses in address books.

As evidenced in the page cited[*], methods 1.* are characterized by being MLM 
side workarounds[†].  That is, they can be applied unilaterally, without 
collaboration nor mutual support.  A state of affairs dictated by the lack of 
standardization.

Now, if we make a semantic effort, we must recognize that the address of From: 
as a matter of fact refers to the "managing editor" of the corresponding mail 
flow, whereas the display name may indicate the actual author.  To say nothing 
of the Sender: field, which wasn't designed for that role anyway.  That's how 
email has evolved after introducing authentication.  I'd hope rfc5322bis will 
recognize those changes.  Meanwhile, if we gather consensus on how to do it 
better, it'd be fair to write it down, no?


Best
Ale
-- 

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

[†] Hm... except for 1.9 TPA.  It should be moved downward, methinks.





























From nobody Wed Jun 17 09:31:35 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C053A0A25 for ; Wed, 17 Jun 2020 09:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MDxRdPzs; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=prVd1sTN
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 jsVte-yDudZp for ; Wed, 17 Jun 2020 09:31:32 -0700 (PDT)
Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (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 3D6983A0A20 for ; Wed, 17 Jun 2020 09:31:31 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1297; t=1592411481; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=hXnPM5+w4V7Q7Mn6zbpustM27TA=; b=MDxRdPzsWBZtxH99TcMUUhAkGGVosqGdEFGc17K8Z/Zo2Wy1xzO6ZH+PC/iDX0 X7nknGw73/so71rkT5fa99mqrEhtYEhwkC7UOXtnmixfMmszSLoXh14YCFeARkur NyhhjXCwAUInLE2oZI0V3AC9DopfqFe7piWgq2TtyA7I4=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 17 Jun 2020 12:31:21 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3138781859.1.3984; Wed, 17 Jun 2020 12:31:20 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1297; t=1592411436; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=d6BPqvU oLuqVJ/hYyYo9UiJd765L5GKZ78yjJxF6xZo=; b=prVd1sTN3mjmN/rCAJitVjX LX9eWTcu/5rG3IYsXTWOOxUQTe91Y3YaWwYMaOyu3hEccX2Win5hMLH96ItGZrxS TmAAV1lSYy/QOVCwBQd5Ewcj4BIkn64DD1gjVC0guIUpM358ru1yP64eZuumX8un IhBdNle5UMYwhSkiam4I=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 17 Jun 2020 12:30:36 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4145131296.1.47904; Wed, 17 Jun 2020 12:30:35 -0400
Message-ID: <5EEA4559.2070903@isdg.net>
Date: Wed, 17 Jun 2020 12:31:21 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <5EE65D11.3050107@isdg.net>  <5EE900C8.5050507@isdg.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 16:31:35 -0000

On 6/16/2020 2:19 PM, Brandon Long wrote:
> So you think we should include
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in
> the actual spec?

In essence, with IETF review to update, clarify, extract parts, 
simplify, I think there are elements that are candidates as a MUST 
addition to the spec. They would address the remaining states in the 
protocol's framework.

With a quick review, my direct involvement experience with the WG ATPS 
vs TPA proposals, I would take exception to the statement "TPA is 
intended to replace RFC6541."  While it may be the wiki author's 
opinion, it was not what I experienced in the WG.  I found the TPA 
proposal to be complex and a hard to read draft. I believe it also 
included trust assessment concepts as well.  ATPS was 16 pages. TPA is 
40 pages.  ATPS was a much simpler protocol to implement asking the 
basic question "Is this 3rd party (re)signer domain authorized?"  ATPS 
was implemented in my product line, not TPA. I don't know where TPA 
was implemented.  With the TPA proposal's author MIA today, how would 
it work? Someone else take it over? Nonetheless, it should be added to 
the list of solutions to review.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Wed Jun 17 09:56:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098373A0A8D for ; Wed, 17 Jun 2020 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Pm1WCkWfS79I for ; Wed, 17 Jun 2020 09:56:38 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1C23A0A8B for ; Wed, 17 Jun 2020 09:56:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id E58D2B107533; Wed, 17 Jun 2020 11:56:31 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwazHylsPcws; Wed, 17 Jun 2020 11:56:29 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 4A53EB107520; Wed, 17 Jun 2020 11:56:29 -0500 (CDT)
From: "Pete Resnick" 
To: "Alessandro Vesely" 
Cc: dmarc@ietf.org
Date: Wed, 17 Jun 2020 11:56:07 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net>
In-Reply-To: <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 16:56:40 -0000

On 17 Jun 2020, at 4:23, Alessandro Vesely wrote:

> There are a few shortcomings of From: rewriting, which could be 
> mitigated adopting suitable conventions.  For example, MUAs' replying 
> to author, or storing rewritten addresses in address books.

As soon as you start down that path, you have eliminated one of the 
purported values of From: alignment: MUAs will start using those 
conventions (X-Original-From:, decoding encoded Froms) and display that 
information to the user instead of what's in the From: field, in which 
case you're going to need X-Original-From: alignment, and down the 
spiral we go. (For those who are amused by such things, do a web search 
for "X-X-Sender".) I am not convinced by many of the arguments for From: 
alignment, and think the problems lie with the lack of semantics able to 
be conveyed by a DMARC record in these cases, but I seem to be in the 
rough on these points. But there is no magic bullet in "suitable 
conventions".

> Now, if we make a semantic effort, we must recognize that the address 
> of From: as a matter of fact refers to the "managing editor" of the 
> corresponding mail flow, whereas the display name may indicate the 
> actual author.

No, the semantics of From: have not changed generally. It's that some 
mailing lists have to change the semantics of From: in the face of the 
inability of DMARC to express the semantics that they want. I can get 
together with a group of my friends and decide that the word "sunny" 
really means "cloudy", but unless the whole English-speaking world is on 
board with me, communication is bound to have problems.

> To say nothing of the Sender: field, which wasn't designed for that 
> role anyway.

Sender: has had pretty much the same definition back to RFC 733. It was 
perfectly designed for "the thing that sent the message, independent of 
the author."

> That's how email has evolved after introducing authentication.

For most email, the meanings haven't changed at all. For a certain class 
of mail, authentication of a certain sort has forced arbitrary changes 
that have made the semantics ambiguous as compared to the past.

> I'd hope rfc5322bis will recognize those changes.

I sure hope not.

> Meanwhile, if we gather consensus on how to do it better, it'd be fair 
> to write it down, no?

Assuming you can gather consensus. I'm not convinced you can.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Wed Jun 17 09:58:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9803A0A92 for ; Wed, 17 Jun 2020 09:58:24 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 uM67a-Wt1enn for ; Wed, 17 Jun 2020 09:58:22 -0700 (PDT)
Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 93B9A3A0A8D for ; Wed, 17 Jun 2020 09:58:22 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2050.outbound.protection.outlook.com [104.47.44.50]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QC200Z3EXT8JT10@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 17 Jun 2020 11:58:21 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.17.164817, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.5.21.5740001, SenderIP=[104.47.44.50]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N3yItYMt7+bBq7mirRgPycnArE5sV7fOD/BDrrngAJWnZLpyf8TCSaimUYBn8ah8N/KiCu9TGIujoqXdRbYG8wenWen9bEfJemSCBaUSSP/eBlDLwRfrWGZ8CymmWZqyLIWp5Mx3xJ9Ge0qNzSlob6pdyTKSgKtJDLT0rcZdE5wCeFaHyfbrA6vCctfTRl+fwrVa6ZXOsOmEZWnw5283W7kj8cYvIjFgIKQQu5nWc/e9ZE+hAgrlKRK6i3jRW8Qj7cH2mfKX1szWMtePVyu5wWr2fuelCK668SeFdks7ub7y/8h7iSn7Bri74wc9I3NTL/g1aceUckZRQB5tOBVFPQ==
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=ooGm3Puq0beEyF8L2EBczGpVFbkN+i6R7LawaZ7Q4S8=; b=EoO5X0A/btrjZFWOsFQgZsoqTgUr7Jus5dI2lFJhp+CN6T8LkdcKIc5A7mZfYyhq53NPxZfWGAOGV4u00Y94ZowD6GAIbzh6WMk9iohrfVo8U0PDQgiP38EBVjo0TKQbqfHP60PMJrYJ7HFfSWigullwTZpS/sJ2FcXQ2llw0F6qzFvNuqirIZHRtK1e78P8bFMS5qLOTcx7N4/4CjL50DVjVQipaHTtqZrxszSnL170Bs6S0N6DtwP+sf6mEInL7vovHcjn2V79HwwJNY7yF2bjRBtXljaPOqGT+z3mdadknmsz+xD+WmI30uRZuDYbi8pTurxSlhPCh7/j2Bh1Xw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ooGm3Puq0beEyF8L2EBczGpVFbkN+i6R7LawaZ7Q4S8=; b=J/5IZs766wUUhcOCXm9nf2u+fKDi+y2RyuIQgKfSNu10IActPEqKVR1Z1jrFfmIhYKQLCDFmmCCX5v3yjrzKSCoKrVQz7/qD2RUNS57TNnm3qcHbfaMwPFr/iw7kD9og3xhDIUheOp5ifkJRkzdH1zR4WMIz2za7ortQ5v9Qbi4=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4539.namprd06.prod.outlook.com (2603:10b6:5:19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 17 Jun 2020 16:58:20 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3088.028; Wed, 17 Jun 2020 16:58:20 +0000
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it>
From: Jesse Thompson 
Message-id: 
Date: Wed, 17 Jun 2020 11:58:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 8bit
X-ClientProxiedBy: CH2PR02CA0021.namprd02.prod.outlook.com (2603:10b6:610:4e::31) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [146.151.213.183] (146.151.213.183) by CH2PR02CA0021.namprd02.prod.outlook.com (2603:10b6:610:4e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Wed, 17 Jun 2020 16:58:19 +0000
X-Originating-IP: [146.151.213.183]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 362eb8dd-7090-44b3-0fd6-08d812dfa336
X-MS-TrafficTypeDiagnostic: DM6PR06MB4539:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 04371797A5
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Aqg2n/koRCZGuY9L398Vvu8jCFPpOmcCS2Jyu/nsyujx4cu2MYrGjnIRUYLSQzlG073cPBcs1CfxnCUVl0mFhPs9P27bxqZuWXJT6aXPJh092Pv8QW3Qmh27e+4C8bTXgDYJdIhqxcMoD4KsjumJt+fat4RQTIQUuKDr1LH8kyTeleWXZ/vmebZ52UaD4oHy5co2Q4gmDR22LbWjX77D7MqR0kOvUsCl9ZuwKfxn/tHYdjU9EFdoLYs+C+R6y/tw8ISd41YM24SnKURfL32tKHikvJ96AqGvQ4wDwiFYD+f8sCa4Uf7LGrsewaZmiXFPHvEVnZ/b1wNy+MSgnNeQgO3jKWPXYQUVoF6fGM+gL1cT2938d7KRK3vgYov0BsPVSUVN85Sn44b+0UiKW1fOeKsaFufil0F6uCvyrFhfNL2Dx5cfSESDOh3aAGHnWdLXt2SdeWKVtpFHPdswpw/URKjGnOgMjdyeWq/hqxIfJ/rNXyv+ffmHkVnCU/4Vo3f/
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(346002)(136003)(396003)(376002)(366004)(39860400002)(6486002)(83380400001)(2616005)(956004)(53546011)(75432002)(478600001)(8676002)(44832011)(6916009)(36756003)(86362001)(31686004)(31696002)(6706004)(8936002)(16526019)(186003)(26005)(966005)(2906002)(786003)(316002)(66946007)(66556008)(66476007)(5660300002)(16576012)(3940600001)(223123001)(43740500002)(130980200001); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: VWY/XJBit2jqXTnHDhGB3h607N4DrbZiX0FdMGlEChiQJm8Zxml3ds+U5EISKAOG9pHb1a9oRYte5+uPD2WouR/Al5byO7hwWp4r1SsB4WYM9wYN7HFLddGpEElpwyRU1djXjtEp8/OMH93ng59wzcXVraeDIfPoAwqgL0RqjP8NCadZ60H3G7wTLnFFAofBdrnM24aCWy1+h/U9sdulqtYOBCW9dZjLowQU+u3UVONKE/dDvlYD+hVzzJMWVJO5x9JlpWai/qRYAKmNUIooqCqWKg4+Ms0bcgxxHoLsT38X64HKyRCUcObgpHqARXs8+lNtG+HKpJHLzYn8gCUB/+xAxEGTHFM0o572E2Xl2qXIy3K93tRgfybkXahkOtUxluBbrHgQQzqVjNXhZqrP/9M/4/ImUWhEJqesXegtVDVs/A2PG8pZeJa70LAUb5DTb5NsxSansQgQnpquhAZV//PLpPRYDECgo0mgd01pxAY79I4+zXPGCt4TJG65i9UB
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 362eb8dd-7090-44b3-0fd6-08d812dfa336
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2020 16:58:20.0260 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rSB7+3yNh2/sdGRGjslWGXo2q4Z14z5YORfwYyLIEGSmi/3EG+hahQNQj+6/A0MRl5TgUXMMk8e/P8NjE7GIYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4539
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 16:58:24 -0000

On 6/17/20 4:23 AM, Alessandro Vesely wrote:
> On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote:
>> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
>>
>>> Even if you ignore my line of reasoning, I think that Ale made in the OP a
>>> compelling case that the practice of From rewriting is here to stay.
>>
>> As a practical matter, that's certainly true for the short to medium term, but
>> it doesn't follow that the IETF should standardize the practice.
> 
> 
> There are a few shortcomings of From: rewriting, which could be mitigated adopting suitable conventions.  For example, MUAs' replying to author, or storing rewritten addresses in address books.
> 
> As evidenced in the page cited[*], methods 1.* are characterized by being MLM side workarounds[†].  That is, they can be applied unilaterally, without collaboration nor mutual support.  A state of affairs dictated by the lack of standardization.
> 
> Now, if we make a semantic effort, we must recognize that the address of From: as a matter of fact refers to the "managing editor" of the corresponding mail flow, whereas the display name may indicate the actual author.  To say nothing of the Sender: field, which wasn't designed for that role anyway.  That's how email has evolved after introducing authentication.  I'd hope rfc5322bis will recognize those changes.  Meanwhile, if we gather consensus on how to do it better, it'd be fair to write it down, no?

There at least needs to be a consensus and an official-looking place that we can point intermediaries when they're getting hit by the DMARC train; as policy publication and enforcement accelerates.  A M3AAWG BCP, perhaps?

Some MLM operators think that setting the Sender header is recommended/good enough.  Some MUAs display the Sender instead of the From if it's set, which is why I think some people think it's equivalent to changing the From header.  That wiki[*] doesn't even mention the Sender header, so it doesn't really serve as a mechanism to dissuade the notion.

If there is no consensus on a single recommendation, then perhaps there needs to be more than one recommendation articulated in a preferential, guided, fashion:
1) If 100% of receivers will trust ARC from the intermediary - do X
2) If DKIM signing and intermediary survival is 100% - do Y
3) Else, do Z
etc...
Along with recommendations for each party regarding what they should do in each situation. 

Those of us who are opinionated about this topic can focus our arguments on the order/criteria/nuances of the recommendations rather than trying to agree on a single one.

The main benefit to making the recommendation(s) more standard is that it will serve to help intermediaries configure things in a "DMARC compatible" fashion and justify any change as necessary to skeptical stakeholders.  It will also serve as a way for IT staff to evaluate alternative software/services if they are considering upgrades vs. replacement.


> [†] Hm... except for 1.9 TPA.  It should be moved downward, methinks. 

Seems in the Cooperative category.  Maybe there needs to be a distinction between Sending (user/MSA vs domain owner?) vs Intermediary solutions?  Or a matrix to capture different qualities.  I don't know, there's a lot about that doc that makes it hard for an average person even know where to start tackling the problem.  Most people don't have years of experience in the email domain to understand all of the nuances.

Jesse

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail


From nobody Wed Jun 17 11:00:50 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC503A0B04 for ; Wed, 17 Jun 2020 11:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=d1p3ulF6; dkim=pass (1536-bit key) header.d=taugh.com header.b=JZ3iFbtS
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 2hcWAnz7L64Y for ; Wed, 17 Jun 2020 11:00:35 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9246A3A0AE1 for ; Wed, 17 Jun 2020 11:00:35 -0700 (PDT)
Received: (qmail 8874 invoked from network); 17 Jun 2020 18:00:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=22a8.5eea5a42.k2006; bh=5eAQidEI8qKEcg70Z3UPQ+ptcsDLYh6u3xVXYlvAkdQ=; b=d1p3ulF6VLQTx3UR8vxvmI+rDneKo+MCXZLSc9P80jWRnvEMvKhp70v9Tt66mrX/UpXZhoTDe9ETFRUcehOvchxdhRWRpG2V7L4xB4HIVvgUsSn70Nf+kQHuYMxxjx1F+T0sJlhnH347dWCsKu3cP9fF0+W3YzpSHlGV/Q8NnRAJhuMOBb65vxPOw8ZT1hJcKfno5gYIyoPBOU8GekWbqHJ82SEqqtE+5rRE9SUTGT9U679O7eL3ryPhKLXk50EC
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=22a8.5eea5a42.k2006; bh=5eAQidEI8qKEcg70Z3UPQ+ptcsDLYh6u3xVXYlvAkdQ=; b=JZ3iFbtS+6tLJdtSt3JmHk7V8PiXXxM3JRf2Y7MS0l5bQnmolA7eJ5OW+WCzjh5KJhRfXIf8sA6Tk/YDcjkktT6WM3Rk2A56MH/2x3M/OCyTqSOEqNSnZU0n+kEOgL1iuUpfJ2UgjEjOVgxC26tQ2JNd9WghCTb4k7Ol+y7wslTnXFkz6Ghhjwsq68UZF1Ncn46Koh7ObPOyPTBAi4r8Gp37OPj2gQef9NCojRMsuU2trVC5dohlHd8H5DlTeZk8
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Jun 2020 18:00:34 -0000
Received: by ary.qy (Postfix, from userid 501) id BF4581B233F0; Wed, 17 Jun 2020 14:00:33 -0400 (EDT)
Date: 17 Jun 2020 14:00:33 -0400
Message-Id: <20200617180033.BF4581B233F0@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: resnick@episteme.net
In-Reply-To: <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 18:00:49 -0000

In article <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> you write:
>No, the semantics of From: have not changed generally. It's that some 
>mailing lists have to change the semantics of From: in the face of the 
>inability of DMARC to express the semantics that they want. ...

I'm with Pete here.  Please leave this bunch of worms in the can.

R's,
John


From nobody Wed Jun 17 11:27:51 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D753A0AE1 for ; Wed, 17 Jun 2020 11:27:49 -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, FREEMAIL_FROM=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=gmail.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 Zf-k9MYfgmIB for ; Wed, 17 Jun 2020 11:27:48 -0700 (PDT)
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 56FEA3A0ADB for ; Wed, 17 Jun 2020 11:27:48 -0700 (PDT)
Received: by mail-oo1-xc2f.google.com with SMTP id 18so616931ooy.3 for ; Wed, 17 Jun 2020 11:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CIn2yJtxlv6g8H0q56Jtlv59fBeiq6VnTP581jUATPQ=; b=YYT0XjHkTAvcOWtFRNW7UbZt1rxdfUplyuw2FDJinEMknRrCoNoHKmPa/qEvZ/0cRY DwITCujuLahSBcrJ9XOzDo4PlMtr8ItOCjsu2FFxw+8ZWa/o/RZdHxEByP/SXaegVeWG QTXI9Tqn1VwiUkGv3k1fmkXtsghxFc+hQHEEpId17OOtMiB4NS7ojtPePAAA0wOCV2Fs fh3rJEcS4mqZ03jxc7beK9CvQGmpPp5NgqztX07Cx34Lp3sIff7YKT729pi9498h4CjL /MVW/zuXaA6WGzjTctbi4mniGG2JJI1jTXejVYC0axRaG9r+possdrdHA7/F0pCO/nDk rqbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CIn2yJtxlv6g8H0q56Jtlv59fBeiq6VnTP581jUATPQ=; b=a+PkaTYhTLAkE+mwVkrMtW+/kXYFZ2fRYZF9ZIfiCDL54DsAgguie6/s05jJm+INaj n2TczRVXtuVFNRmTY+JefuVgVEiBAvc195Z9RldLZL4taQSmcVe6P7pV4kRXcWQYM1Yt ZSwsO4DhbGVYRpxrgjczlKQttV2guCS5VerQE80Tu03izqY/FFZekVXTUvxJGTpbHzme thh0F2dhkqVN+0XysP6fVCKR9PCC6w6Vd7mX66oZb249nddfrGKx+gVYQKWELZncQrqM /Rkjsmc8npeq+ZuvMJo4paX2wgC14SLALObFdn8JqKT6bsT55mC6f8t4kdshQy79ZcPT 1Gng==
X-Gm-Message-State: AOAM530zJ9MaMcYtl5N+SXXnTdvu4hhrf/nAYZ27A8UePMZgYGuKpDAT a4n7jaRstJK1Wuf57824d1GIMyEZ
X-Google-Smtp-Source: ABdhPJwXVQJ6HFz6MlCUTFVulwp8JC5flZI6lPnTWyeNaS7hcsQtbkLK7eEJUXngzsb/tQNmCBnhTA==
X-Received: by 2002:a4a:221a:: with SMTP id f26mr664502ooa.69.1592418467057; Wed, 17 Jun 2020 11:27:47 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:95dc:2663:4d62:d307? ([2600:1700:a3a0:4c80:95dc:2663:4d62:d307]) by smtp.gmail.com with ESMTPSA id f19sm134875ooh.10.2020.06.17.11.27.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2020 11:27:46 -0700 (PDT)
To: Pete Resnick , Alessandro Vesely 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net>
From: Dave Crocker 
Message-ID: <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>
Date: Wed, 17 Jun 2020 11:27:44 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 18:27:50 -0000

On 6/17/2020 9:56 AM, Pete Resnick wrote:
> No, the semantics of From: have not changed generally. It's that some 
> mailing lists have to change the semantics of From: in the face of the 
> inability of DMARC to express the semantics that they want. 


The two sentences seem to be in conflict. If there is a degree of 
practice that creates a different semantic for the field, then its 
semantics have changed, at least for the portion of email traffic.


Here's a simple operational test:  MUAs typically can aggregate messages 
'from' the same author.  After all, that's always been the primary role 
of From, to indicate who created the content. Such aggregation is 
usually found to be helpful.

Historically -- for 40+ odd years -- this has worked for mail going 
through mailing lists.  Now it usually doesn't. I'd appreciate an 
explanation of how that does not constitute a change in semantics.

Have a folder with a variety of messages from correspondents, where some 
of a person's messages are sent directly to you and some of their 
messages are sent through mailing lists that adapt the From: field 
content in order to avoid DMARC rejection.  The MUA will handle mail 
from the same person, but that went through these two different paths, 
as being from different sources.


DMARC relies on From: because it is the only field with an identifier 
that is always present. Sender is not reliably present, except 
virtually.  The nature of what DMARC is actually doing looks more like 
relying on the operations-related Sender: field than the author-related 
From: field.

DMARC has nothing to do with display of author information to a 
recipient, and everything to do with differential handling by a 
receiving filtering engine.  Were the Sender: field always present, that 
would be the one that DMARC should have used.

So, really, DMARC has altered the semantics of the From: field to be the 
Sender: field.  The nature of the hack that mailing lists do, when 
altering the From: field, makes this clear:  They alter information 
about the operator handling the message, destroying the original 
information about content authorship.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Jun 17 12:11:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D383A0D31 for ; Wed, 17 Jun 2020 12:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZNVTcoxwXbI3 for ; Wed, 17 Jun 2020 12:11:39 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568933A0D36 for ; Wed, 17 Jun 2020 12:11:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 9DB6EB10A582; Wed, 17 Jun 2020 14:11:33 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Py55qiQEbC; Wed, 17 Jun 2020 14:11:32 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 64C98B10A579; Wed, 17 Jun 2020 14:11:32 -0500 (CDT)
From: "Pete Resnick" 
To: "Dave Crocker" 
Cc: "Alessandro Vesely" , dmarc@ietf.org
Date: Wed, 17 Jun 2020 14:11:31 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 19:11:40 -0000

On 17 Jun 2020, at 13:27, Dave Crocker wrote:

> On 6/17/2020 9:56 AM, Pete Resnick wrote:
>> No, the semantics of From: have not changed generally. It's that some 
>> mailing lists have to change the semantics of From: in the face of 
>> the inability of DMARC to express the semantics that they want.
>
> The two sentences seem to be in conflict. If there is a degree of 
> practice that creates a different semantic for the field, then its 
> semantics have changed, at least for the portion of email traffic.

You'll note the word "generally". Most of my email carries the same 
semantics it always has in From:. There is a small subset that doesn't. 
But (and not to get too philosophical here), even when the semantics 
aren't the same, it is often a surprise: I find that something didn't 
match my expectations, only to discover that the originator of the email 
didn't use the same semantics I was expecting as recipient. That doesn't 
necessarily constitute a change in semantics for the email, but a 
mismatch: The originator said "sunny" and I thought that meant "without 
clouds". Even if I figure out the mismatch, I might not agree to "the 
semantics changed"; I might prefer to go with, "The originator made a 
mistake." In the present case, some mailing lists are using the same old 
semantics and some are using a new set; that doesn't convince me that we 
have an interoperable semantics to which we have "changed".

> Here's a simple operational test:  MUAs typically can aggregate 
> messages 'from' the same author.  After all, that's always been the 
> primary role of From, to indicate who created the content. Such 
> aggregation is usually found to be helpful.
>
> Historically -- for 40+ odd years -- this has worked for mail going 
> through mailing lists.  Now it usually doesn't. I'd appreciate an 
> explanation of how that does not constitute a change in semantics.

Of course, I'd be interested in the "usually" part. It's not true of my 
mailstore, but my mailstore is far from average. I do know that even on 
the local non-profit board to which I belong (and had no hand in setting 
up), the Outlook server uses the semantics to which I am accustomed, 
though maybe having a smaller list where most people using their gmail 
addresses makes it equally "not average".

> Have a folder with a variety of messages from correspondents, where 
> some of a person's messages are sent directly to you and some of their 
> messages are sent through mailing lists that adapt the From: field 
> content in order to avoid DMARC rejection.  The MUA will handle mail 
> from the same person, but that went through these two different paths, 
> as being from different sources.

I'm sure that happens.

> DMARC relies on From: because it is the only field with an identifier 
> that is always present. Sender is not reliably present, except 
> virtually.  The nature of what DMARC is actually doing looks more 
> like relying on the operations-related Sender: field than the 
> author-related From: field.
>
> DMARC has nothing to do with display of author information to a 
> recipient, and everything to do with differential handling by a 
> receiving filtering engine.  Were the Sender: field always present, 
> that would be the one that DMARC should have used.

It could have chosen the more complicated, "Sender unless not present, 
in which case From". But yes, this bit I get. That said, there are 
people who have argued that From: was chosen because Sender: was not 
displayed. I think that's a silly argument, but it's one that people 
still believe.

> So, really, DMARC has altered the semantics of the From: field to be 
> the Sender: field.

Wait a minute: I think this point needs some clarification. We know that 
the pre-DMARC semantics of the From: field are "the entity that authored 
the message". Originators were expressing that meaning and recipients 
were interpreting that meaning. My understanding of the meaning that 
DMARC added was, "The author of this message, as expressed in the From: 
field, always has their messages properly signed by the domain in the 
 From: address." You seem to be saying that, no, what DMARC did was 
changed the semantic to be, "The From: field now represents the 
transmitter of the message (as used to be expressed in the Sender: field 
when present), not the author, and that transmitter always has their 
messages properly signed by the domain in the From: address". Do I have 
that right? (And I presume that either way, these are de facto 
semantics, not intentional ones that are documented anywhere, right?)

> The nature of the hack that mailing lists do, when altering the From: 
> field, makes this clear:  They alter information about the operator 
> handling the message, destroying the original information about 
> content authorship.

Mailing lists that make other choices (throwing away messages from DMARC 
reject senders, denying subscriptions from them, or simply ignoring them 
and ending up with bad consequences) have obviously not gone along with 
the certain forms of the semantic change.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Thu Jun 18 00:46:56 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17263A0F07 for ; Thu, 18 Jun 2020 00:46:54 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 JKf4V0ZhRClB for ; Thu, 18 Jun 2020 00:46:53 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2FCF73A0F06 for ; Thu, 18 Jun 2020 00:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592466408; bh=HD/lpnF2z3M8s35JAF0EigD/kYV0xQCp20vCp6+nlF8=; l=3470; h=To:Cc:References:From:Date:In-Reply-To; b=ARMhLlWHjWU1DW0L/727PWTyp9TuSr7SJkihGCUYYtX1hYUOFUHSD8oa/HAyRcdKB Tc09lN/AB1ZKhgqT5R8YxeNd+50acz/rEaFOCyzKbVWxF5xHDOpkqxtJW0ymvMM8Gd BH7OQA0l67Sfj/0Edi0yu+C2ZQVA2B7epPK9m8icP/IPhOicN+ymwyyBCo8vo
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EEB1BE8.0000435D; Thu, 18 Jun 2020 09:46:48 +0200
To: Pete Resnick , Dave Crocker 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com> 
From: Alessandro Vesely 
Message-ID: <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
Date: Thu, 18 Jun 2020 09:46:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 07:46:55 -0000

On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:
> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>> On 6/17/2020 9:56 AM, Pete Resnick wrote:
>>> No, the semantics of From: have not changed generally. [...]
> 
>> So, really, DMARC has altered the semantics of the From: field to be the 
>> Sender: field.
> 
> Wait a minute: I think this point needs some clarification. We know that the 
> pre-DMARC semantics of the From: field are "the entity that authored the 
> message".


"Authoring" can have subtly different acceptations, though.  The exact sentence is:

              The "From:" field specifies the author(s) of the message,
    that is, the mailbox(es) of the person(s) or system(s) responsible
    for the writing of the message.
                    [https://tools.ietf.org/html/rfc5322#section-3.6.2]

That is not so far from real.  The term "writing" sounds ambiguous, as it is 
not clear whether it means "typing" or "publishing", in the case of public 
mailing lists.  Given that Sender: is dedicated to the typist, I'd opt for the 
latter interpretation.

For a newspaper, if you pardon the analogy, the masthead is more visible than 
columnist signatures at the end of the articles.  For a mailing list, publisher 
visibility used to be provided by subject tags, leaving the From: intact.  Why? 
  Presumably, because it just worked that way.  However, if the MLM is the 
system responsible for writing, not modifying From: should be considered a 
violation.


> My understanding of the meaning that DMARC added was, "The author of this
> message, as expressed in the From: field, always has their messages properly
> signed by the domain in the From: address." You seem to be saying that, no,
> what DMARC did was changed the semantic to be, "The From: field now
> represents the transmitter of the message (as used to be expressed in the
> Sender: field when present), not the author, and that transmitter always has
> their messages properly signed by the domain in the From: address".

Sender: was not meant to be the transmitter in that sense.  It was meant to be 
the secretary who writes on behalf of a responsible person or system.  It never 
had traction, AFAIK.  Most clients don't allow secretaries to add their mailbox 
to the messages they write.  Google «How do I change the sender in Outlook?»

Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to introduce 
the concept of an entity responsible for the last hop.  DMARC requires that the 
last hop is also the first one, or else that the forwarding is mechanically 
smooth, an unparticipated transmission which breaks no signatures.

Mailing lists match neither case.  Couldn't we consider From: rewriting a sort 
of message/rfc822-wrap lite?

It may well be that X-Original-From: is not a good convention.  There's a bunch 
of questions to clarify, such as whether users see the domain part of a mailbox 
address, whether they can tell authenticated messages, or whether they should 
be trusted at all.  However, unlike Sender ID, DMARC seems to have enough 
success to cause a semantic shift.  If it can result in a simplified filtering, 
I'd accept it.

RFC 5322 says display names are "associated" to a mailbox.  Certainly, changing 
just the addr-spec breaks the association and wreaks havoc to address books. 
The convention to write "MLM on behalf of" seems sound, but it takes sixteen 
columns of real estate in the folder view.  Can't we do better?


Best
Ale
-- 





































From nobody Thu Jun 18 12:02:18 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A603A0E87 for ; Thu, 18 Jun 2020 12:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=OTCF38zO; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ulceJ1Ta
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 IduwSwtbh7Ez for ; Thu, 18 Jun 2020 12:02:15 -0700 (PDT)
Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) (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 186DD3A0E74 for ; Thu, 18 Jun 2020 12:01:31 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5929; t=1592506889; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=lMzpTBMC8H9ZuWpZ+we/TskP5Qo=; b=OTCF38zOqZ8SiEiik4H/v0YYn17MWGtfl4XO9gRVEN1wnFZO/i2n8SWMQXiPDd u4gJa6iL5BC6OAcG3r9GXvjkGmtp3O2l41+uq+gAqG7DLV72pMswjHLxSINc71Lr 5MXOqKYO8z5HhENMk0ZvvE19NtUE2urW9Udu+Ywpu0+QU=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 15:01:29 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3234187858.1.4404; Thu, 18 Jun 2020 15:01:27 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5929; t=1592506840; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jZMJTWZ CKsqk/KLgG/K0J4uZFBcSaWsIo2LGfldX4+I=; b=ulceJ1TapjUVxcWXXyODvw2 o+zd6tDHhcaB7ovZKQTkiRt6pl8bmf2svsaNLlrMwGpC1XRtlYj0K+pjgQ5xNlhA e4H2OlfVF4FQlbdPbIFcd4MC+Wh6cDjz09rN5HaqRdFwoU88hjubBWaSmIrjdubz O1AJB7cF3206ICpNF8QU=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 15:00:40 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4240535687.1.47260; Thu, 18 Jun 2020 15:00:39 -0400
Message-ID: <5EEBBA09.8070207@isdg.net>
Date: Thu, 18 Jun 2020 15:01:29 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
In-Reply-To: <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 19:02:18 -0000

Alessandro,

There are long time solid reasons why the "Local.From" field needs to 
be stable. In particular, with local messaging, unless the local 
system allows for anonymous entry of the Local.From field when 
creating a Local message, there is a MUST for a 1 to 1 association 
with the account.

If local mail is exported for a external network, it doesn't matter 
what mail network it is, you really don't want to introduce the idea 
of allowing the changing of the Network.from field and making it 
anonymous or disassociated with the original source. The domain is 
associated with the source of the message, and the user part of the 
address reflects the user account at the domain.  There are good 
reasons for that.   Lets say the user is causing a problem on a remote 
system. Using the network.From, the remote system could contact the 
original system and issue a complaint.  If we were "free" to remove 
that idea, it be would harder to trace it.   DKIM allows you to lock 
that field down so that it can't be tampered with.

You have to understand the long time pov of developers that have been 
at this for 40 years.  Every system I have worked, the different 
networks, it was the same thing -- leave the from field alone! Do not 
make it "anonymous" or capable of being an "unknown."

Its the same for Instant Messaging, for Chatting, the TELEPHONE, the 
Caller ID, etc, it is a TABOO to change the "From" entity.

If you want to continue your line of logic to rationalize Rewriting, 
then you need to make it "protocol complete"  to help keep the 
association of the From field with the original source intact. But 
more importantly, it should have get permission from the original 
domain in order to rewrite. This can be done with a DMARC tag extension:

DMARC p=reject|quarantine ... rewrite=0|1

The default sides with highest security -- No Rewriting. But if the 
domain wishes to allow for rewriting, then it should explicitly state 
it in this policy record, rewrite=1.

This is something I could possibly support IFF the originating domain 
allows it. There would other things to consider to tie the loose ends, 
but the #1, would be the rewrite=1 tag.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


On 6/18/2020 3:46 AM, Alessandro Vesely wrote:
> On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:
>> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>>> On 6/17/2020 9:56 AM, Pete Resnick wrote:
>>>> No, the semantics of From: have not changed generally. [...]
>>
>>> So, really, DMARC has altered the semantics of the From: field to
>>> be the Sender: field.
>>
>> Wait a minute: I think this point needs some clarification. We know
>> that the pre-DMARC semantics of the From: field are "the entity that
>> authored the message".
>
>
> "Authoring" can have subtly different acceptations, though.  The exact
> sentence is:
>
>               The "From:" field specifies the author(s) of the message,
>     that is, the mailbox(es) of the person(s) or system(s) responsible
>     for the writing of the message.
>                     [https://tools.ietf.org/html/rfc5322#section-3.6.2]
>
> That is not so far from real.  The term "writing" sounds ambiguous, as
> it is not clear whether it means "typing" or "publishing", in the case
> of public mailing lists.  Given that Sender: is dedicated to the
> typist, I'd opt for the latter interpretation.
>
> For a newspaper, if you pardon the analogy, the masthead is more
> visible than columnist signatures at the end of the articles.  For a
> mailing list, publisher visibility used to be provided by subject
> tags, leaving the From: intact.  Why?  Presumably, because it just
> worked that way.  However, if the MLM is the system responsible for
> writing, not modifying From: should be considered a violation.
>
>
>> My understanding of the meaning that DMARC added was, "The author of
>> this
>> message, as expressed in the From: field, always has their messages
>> properly
>> signed by the domain in the From: address." You seem to be saying
>> that, no,
>> what DMARC did was changed the semantic to be, "The From: field now
>> represents the transmitter of the message (as used to be expressed
>> in the
>> Sender: field when present), not the author, and that transmitter
>> always has
>> their messages properly signed by the domain in the From: address".
>
> Sender: was not meant to be the transmitter in that sense.  It was
> meant to be the secretary who writes on behalf of a responsible person
> or system.  It never had traction, AFAIK.  Most clients don't allow
> secretaries to add their mailbox to the messages they write.  Google
> «How do I change the sender in Outlook?»
>
> Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to
> introduce the concept of an entity responsible for the last hop.
> DMARC requires that the last hop is also the first one, or else that
> the forwarding is mechanically smooth, an unparticipated transmission
> which breaks no signatures.
>
> Mailing lists match neither case.  Couldn't we consider From:
> rewriting a sort of message/rfc822-wrap lite?
>
> It may well be that X-Original-From: is not a good convention.
> There's a bunch of questions to clarify, such as whether users see the
> domain part of a mailbox address, whether they can tell authenticated
> messages, or whether they should be trusted at all.  However, unlike
> Sender ID, DMARC seems to have enough success to cause a semantic
> shift.  If it can result in a simplified filtering, I'd accept it.
>
> RFC 5322 says display names are "associated" to a mailbox.  Certainly,
> changing just the addr-spec breaks the association and wreaks havoc to
> address books. The convention to write "MLM on behalf of" seems sound,
> but it takes sixteen columns of real estate in the folder view.  Can't
> we do better?
>
>
> Best
> Ale




From nobody Thu Jun 18 14:11:06 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ADF3A0F9B for ; Thu, 18 Jun 2020 14:11:05 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 89jpTANm8QQn for ; Thu, 18 Jun 2020 14:11:01 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 1D4AF3A0F8F for ; Thu, 18 Jun 2020 14:11:01 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05ILAmae018427 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2020 14:10:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592514649; bh=F3AaWBChYtytMWR05YUnTDwtZRiIs1TISd+I84BIIi4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ljFKCLBHvW/ybUSG4HYVfeV0+xL8jLlAq7vMZWg2G5BaQjoukWITde54MVTo0vknJ AbrHxhqFHp+nR2WXOKSQLrvkxNuIt9W7QfOxaWndsDVImzdm/y+6Hvn/5TJSYPQWPv 3E7v7gUWa8rDpqzjm/PPA+LVaibpDZCqmcGTquFY=
To: Pete Resnick , Dave Crocker , dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com> 
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net>
Date: Thu, 18 Jun 2020 14:10:43 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 21:11:05 -0000

On 6/17/20 12:11 PM, Pete Resnick wrote:
> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>
>> DMARC has nothing to do with display of author information to a
>> recipient, and everything to do with differential handling by a
>> receiving filtering engine.=C2=A0 Were the Sender: field always presen=
t,
>> that would be the one that DMARC should have used.
>
> It could have chosen the more complicated, "Sender unless not present,
> in which case From". But yes, this bit I get. That said, there are
> people who have argued that From: was chosen because Sender: was not
> displayed. I think that's a silly argument, but it's one that people
> still believe.


I'm trying to understand why alignment to any header field is important
to DMARC in that case. If whatever it's aligning to is not visible, the
sender can trivially achieve alignment by choosing the From: (or
Sender:, whatever) address to match the domain of the DKIM signature
and/or envelope-from address. I don't see how that contributes at all to
differential handling by a receiving filtering engine. If it's because
From: is visible, the address part of From is getting to be a lot less
visible, plus typical users will ignore the address anyway.

And if From: alignment doesn't matter, the mailing list can just sign
the message and no rewriting is needed.

-Jim




From btv1==438c622ac45==fosterd@bayviewphysicians.com  Thu Jun 18 14:13:48 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F323A0FC1 for ; Thu, 18 Jun 2020 14:13:48 -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 (1024-bit key) header.d=bayviewphysicians.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 OqG61WfOm60J for ; Thu, 18 Jun 2020 14:13:46 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D963A0FA3 for ; Thu, 18 Jun 2020 14:13:45 -0700 (PDT)
X-ASG-Debug-ID: 1592514824-11fa313a101c02c0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Kqx6SRfHd2R2b0Uc (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 18 Jun 2020 17:13:44 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=ZfX//opMo14AkBj/nyrCmSg7aXJ96vmB6qOE9XowkOQ=; b=fN7wOt2YFZ7wEKiYVFUH1veuVqjq3PxNKRGpViUkJ+5h3yVj9uT3eIiWixdEawd8i FEECIuG/cdJ7O+xYd/EMgTC13uzDQAJIreYl8Jyh51EOmh+TfrDH8iE6yPShsdGZe 1+cQeeI4ZA4A9ykY3vIbpqz/R56/m1BbapTQ1fSxQ=
From: "Douglas E. Foster" 
To: 
Date: Thu, 18 Jun 2020 21:13:35 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
Reply-To: fosterd@bayviewphysicians.com
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=03f78902e7e3481fb61d5459669ac1f3
In-Reply-To: <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
X-Exim-Id: e7a0e1df6457451c8fdd52011e8ae95a
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592514824
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 10930
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82645 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing   list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 21:19:03 -0000

This is a multipart message in MIME format.

--03f78902e7e3481fb61d5459669ac1f3
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

There are some basic principles that need to be considered:.

DMARC did not break mailing list privileges, unwanted mail did.

A fully legitimate message has these characteristics:
Intended by the originatorAcceptable to the policies of the domain owner, w=
hich are partially implemented in its outbound mail filterDesired by the re=
cipientAcceptable to the recipient domain owner, as partially implemented i=
n its inbound mail filter.
One example of a message that is not acceptable to the originator is a mess=
age spoofed by an authorized server.   This is one of the problems addresse=
d by DMARC.

More specifically, what characteristics make a message acceptable to the re=
cipient:
A recognized / trusted senderA message which looks like previous-good messa=
gesA message with no identifiable risk factors.
To elaborate, incoming mail filters separate mail into three buckets:
Probably unwantedUnknown and hopefully harmlessDefinitely wanted

The administrators of the incoming mail filter will be continually seeking =
to move traffic from bucket 2 to bucket 1 or bucket 3, so a strategy based =
on bucket 2 is not guaranteed to work indefinitely.

>From the viewpoint of the inbound mail filter, forwarded mail is indistingu=
ishable from spoofed mail using an open relay.   In a world where all mail =
was wanted mail, mailing lists could do what they want.  But we are not on =
Arpanet anymore, and unwanted mail is a huge problem.

If a mailing list is violating DMARC, it is likely to be put in bucket 1.  =
 Once one message ends up in bucket 1, all messages from that source are li=
kely to be blocked as well.

For a sender to be promoted from bucket 1 to bucket 2, messages need to dis=
tinguish themselves from untrusted email.   Preserving DKIM signatures is o=
ne way of doing so.  Header munging is another way of doing so.

To move into bucket 3, the forwarder needs to obtain a sponsor to negotiate=
 with the recipient organization's email security team..

For two messages from the same forwarder to land in the same bucket, both m=
essages must have similar qualifying characteristics.

An Example

Consider the risk profile of a request to auto-forward from UserA@DomainA t=
o UserB@DomainB

This request could reflect a range of behaviors from low risk to high risk.
UserB actually wants the forward to occur.UserB is the accidental victim of=
 a typing error.UserA is going to be used as a proxy to attack UserB.Forwar=
ding to UserB is contrary to DomainA policy because it is likely to permit =
violation of DomainA's regulatory obligations under GDPR, PCI DSS, HIPPA, S=
arbanes-Oxley or something else.Forwarding to UserB is in conflict with Dom=
ainB policy for whatever reason.UserA is an inside attacker seeking to exfi=
ltrate data to an external accomplice.
So both DomainA and DomainB administration have reasons to be involved in t=
his request.   Even for legitimate requests, DomainA does not want to forwa=
rd traffic to DomainB if it is unwanted, since unwanted mail may impact the=
 reputation of DomainA, and likely cause unwanted blacklisting of other mes=
sages.

Therefore, the wisest procedure is as follows:
DomainA detects the forward request and begins an approval workflow.DomainA=
 reviews the request to see if they are willing to grant internal approval.=
Postmaster@DiomainA contacts UsersB@DomainB asking them to submit the reque=
st to their email security team for approval.Administrators for DomainA and=
 DomainB communicate to discuss the administrative controls at DomainA as w=
ell as the fingerprint characteristics of the incoming mail.Upon approval, =
DomainB administration gives DomainA administration permission to proceed. =
 DomainA activates the forwarding and notifies the user.DomainA monitors th=
e outbound mailstream for deliverability and terminates the forwarding if r=
epeated failures occur, or upon request from DomainB administration or User=
B@DomainB.
I suspect most mailing systems would need a lot of new code to implement a =
workflow like this, but my perspective is limited and may be wrong.

The mailing list scenario is not much different, except that the request pr=
ocess begins when UserB@DomainB attempts to subscribe to the mailing list, =
and the approval process involves both the handling of messages coming from=
 the list as well as messages going to the list.

The process may be limited by the features of the DomainB email filter.   W=
ithout header munging, fingerprinting the mailing list will require combini=
ng the list headers with forward confirmed host names, or something along t=
hose lines.    Low-end email filters may be unable to filter on list name, =
or filter on multiple attributes together.

Getting prior approval will be a lot of work, and i wonder how many lists w=
ill be willing to try.     In the absence of prior approval, I see no solut=
ion better than header munging.   Header munging is an inferior solution be=
cause neither sender policies nor receiver policies are evaluated or respec=
ted, but it is the path of least resistance.



--03f78902e7e3481fb61d5459669ac1f3
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


There are some bas=
ic principles that need to be considered:.

DMARC d=
id not break mailing list privileges, unwanted mail did.

A fully legitimate message has these characteristics:
  1. I=
ntended by the originator
  2. Acceptable to the policies of the domain =
owner, which are partially implemented in its outbound mail filter
  3. =
Desired by the recipient
  4. Acceptable to the recipient domain owner, =
as partially implemented in its inbound mail filter.
One exam=
ple of a message that is not acceptable to the originator is a message spoo=
fed by an authorized server.   This is one of the problems addressed b=
y DMARC.

More specifically, what characteristics m=
ake a message acceptable to the recipient:
  • A recognized / trus=
ted sender
  • A message which looks like previous-good messages
    • A message with no identifiable risk factors.
To elaborate, =
incoming mail filters separate mail into three buckets:
  1. Probab=
ly unwanted
  2. Unknown and hopefully harmless
  3. Definitely wante=
d

The administrators of the incoming mail filt=
er will be continually seeking to move traffic from bucket 2 to bucket 1 or=
 bucket 3, so a strategy based on bucket 2 is not guaranteed to work indefi=
nitely.

From the viewpoint of the inbound mail fil=
ter, forwarded mail is indistinguishable from spoofed mail using an open re=
lay.   In a world where all mail was wanted mail, mailing lists could =
do what they want.  But we are not on Arpanet anymore, and unwanted ma=
il is a huge problem.

If a mailing list is violati=
ng DMARC, it is likely to be put in bucket 1.   Once one message ends =
up in bucket 1, all messages from that source are likely to be blocked as w=
ell.

For a sender to be promoted from bucket 1 to =
bucket 2, messages need to distinguish themselves from untrusted email. &nb=
sp; Preserving DKIM signatures is one way of doing so.  Header munging=
 is another way of doing so.

To move into bucket 3=
, the forwarder needs to obtain a sponsor to negotiate with the recipient o=
rganization's email security team..

For two messag=
es from the same forwarder to land in the same bucket, both messages must h=
ave similar qualifying characteristics.

An Example=


Consider the risk profile of a request to auto-fo=
rward from UserA@DomainA to UserB@DomainB

This req=
uest could reflect a range of behaviors from low risk to high risk.
  • UserB actually wants the forward to occur.
  • UserB is the accid=
ental victim of a typing error.
  • UserA is going to be used as a prox=
y to attack UserB.
  • Forwarding to UserB is contrary to DomainA polic=
y because it is likely to permit violation of DomainA's regulatory obligati=
ons under GDPR, PCI DSS, HIPPA, Sarbanes-Oxley or something else.
  • F=
orwarding to UserB is in conflict with DomainB policy for whatever reason.<=
/li>
  • UserA is an inside attacker seeking to exfiltrate data to an extern=
al accomplice.
    • So both DomainA and DomainB administration hav=
e reasons to be involved in this request.   Even for legitimate reques=
ts, DomainA does not want to forward traffic to DomainB if it is unwanted, =
since unwanted mail may impact the reputation of DomainA, and likely cause =
unwanted blacklisting of other messages.

    Therefore=
, the wisest procedure is as follows:
    1. DomainA detects the forw=
ard request and begins an approval workflow.
    2. DomainA reviews the re=
quest to see if they are willing to grant internal approval.
    3. Postma=
ster@DiomainA contacts UsersB@DomainB asking them to submit the request to =
their email security team for approval.
    4. Administrators for DomainA =
and DomainB communicate to discuss the administrative controls at DomainA a=
s well as the fingerprint characteristics of the incoming mail.
    5. Upo=
n approval, DomainB administration gives DomainA administration permission =
to proceed. 
    6.  DomainA activates the forwarding and notifi=
es the user.
    7. DomainA monitors the outbound mailstream for deliverab=
ility and terminates the forwarding if repeated failures occur, or upon req=
uest from DomainB administration or UserB@DomainB.
    I suspect =
most mailing systems would need a lot of new code to implement a workflow l=
ike this, but my perspective is limited and may be wrong.

    The mailing list scenario is not much different, except that the re=
quest process begins when UserB@DomainB attempts to subscribe to the mailin=
g list, and the approval process involves both the handling of messages com=
ing from the list as well as messages going to the list.

    The process may be limited by the features of the DomainB email filt=
er.   Without header munging, fingerprinting the mailing list will req=
uire combining the list headers with forward confirmed host names, or somet=
hing along those lines.    Low-end email filters may be unable to=
 filter on list name, or filter on multiple attributes together.
    =

    Getting prior approval will be a lot of work, and i wonder h=
ow many lists will be willing to try.     In the absence of prior=
 approval, I see no solution better than header munging.   Header mung=
ing is an inferior solution because neither sender policies nor receiver po=
licies are evaluated or respected, but it is the path of least resistance.<=
/div>





    <=
/div>
    

--03f78902e7e3481fb61d5459669ac1f3--


From nobody Thu Jun 18 14:29:31 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3A3A0FB5 for ; Thu, 18 Jun 2020 14:29:30 -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, FREEMAIL_FROM=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=gmail.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 GYWLAIeiyR9i for ; Thu, 18 Jun 2020 14:29:29 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 939BD3A0FB2 for ; Thu, 18 Jun 2020 14:29:29 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id a3so6494317oid.4 for ; Thu, 18 Jun 2020 14:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=xEQxvzTSs0oKq48XoIM2vL8TBs61xPgnic42zUN0s7k=; b=Cs+iqGhKvglSv7iXU4ZD/YC7qXKvBVXCW2CrXYyrOUWxrghW1ohrX7Vil0ZP+p8K2I wbZ1sq1SiDuQCoQBCK529wVmfCSTWRvDug0uNYu3KneDysf+g67kE+OQRDVToFHmqS3Q BN6sTyAKswZC58kNlSpyP+Rsq8ynvzqCrk3WbPZJr8tRsf+QgLyKAbLAQiWfrnhFHK1b 95ICnA4ocEUQ6sL47C6my0r+LFRg+CtNKZbfDDMHgbTjeby7siAagqd3TbSSS+c6OAvY HAtzfVO3OmS2fUnSrFyo7WtYV0B8fsyT/jUb7VT60kq3kc5JGL1a1R4cts9b86hLVSJv E39g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xEQxvzTSs0oKq48XoIM2vL8TBs61xPgnic42zUN0s7k=; b=tfm8YlmBy4x3/1Dg3gAN/eyUlXWK567paVT2TXJswM/tkjNtp5FlTf8X5cX0JySOD4 ONalSN/3p4NihLM4Hp1qET2AfR9Zu42BSLXlqooswqtXPL6eAceAJ6esobK/n1x+s31W WWXdCBYS5hyaWwYhD5gWw8Dh5G4MLX0V8YVPbVvx6Tpf7XTtONEM8GB1C5D0NnXOq5mI EXcC/HKRp4t+6RSntgBWEoPqZwIaEZom/vhEmDUhAxS8q6eZHf9N16m9TGUnbCE9Q8cx TiA1CuOwjupXmvOjkJAp7Mo0162KhO1at4fZsXNO1m3lsFMzsh6YTC624WJaGm/SSzp3 vfbw==
X-Gm-Message-State: AOAM531wA/CE1gwBg9z86G3IJV4a5CwArlmMtuHgVSR9nkcuPfC04E5A x/nOodYl0UX9qkb0NQAwzofxa+fp
X-Google-Smtp-Source: ABdhPJyYYU1BDJXR6RdlhNuzGCjjnJyyun3xgbtvyd0O6mj8YXvWnFQ1DZG4cpQGDARdeSeghtgdiA==
X-Received: by 2002:a05:6808:487:: with SMTP id z7mr757300oid.166.1592515768371;  Thu, 18 Jun 2020 14:29:28 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a51b:a5c4:93c:41be? ([2600:1700:a3a0:4c80:a51b:a5c4:93c:41be]) by smtp.gmail.com with ESMTPSA id v2sm967802otb.70.2020.06.18.14.29.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 14:29:27 -0700 (PDT)
To: Jim Fenton 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com>
Date: Thu, 18 Jun 2020 14:29:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 21:29:31 -0000

On 6/18/2020 2:10 PM, Jim Fenton wrote:
> On 6/17/20 12:11 PM, Pete Resnick wrote:
>> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>>> DMARC has nothing to do with display of author information to a
>>> recipient, and everything to do with differential handling by a
>>> receiving filtering engine.  Were the Sender: field always present,
>>> that would be the one that DMARC should have used.
>> It could have chosen the more complicated, "Sender unless not present,
>> in which case From". But yes, this bit I get. That said, there are
>> people who have argued that From: was chosen because Sender: was not
>> displayed. I think that's a silly argument, but it's one that people
>> still believe.
> I'm trying to understand why alignment to any header field is important
> to DMARC in that case.


Because operators have found useful correlations in distinguishing 
between messages that are aligned and being 'genuine' versus ones that 
are not aligned.

In the abstraction of theory, you are correct that it shouldn't matter.  
In the brutality of practice, it appears that it does.


d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 18 15:24:20 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC193A1036 for ; Thu, 18 Jun 2020 15:24: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, 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 (1024-bit key) header.d=bluepopcorn.net
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 OhI4o7_ajftw for ; Thu, 18 Jun 2020 15:24:17 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 523123A1033 for ; Thu, 18 Jun 2020 15:24:17 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05IMOEbJ019495 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2020 15:24:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592519056; bh=zdDFCHDpFNQVqVWMLHZyZjYi7Oxg3XHILeiOkWgfLPg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=uZXXRWL1bEmU7turDtK5NaDe9VqLbIsZo6rdoUDdHKxZTJC05K+SXY6bqSZTu4M/1 hXGZCTul7AUKJjY7buwDPO5VMzdOKd/thR2QyVWG5bnONbSqQbEtIzzqAE8KVU9Bme 8fsbqEnAlXrC5rLUuaZKLZAElH2Iu63EDccSeaS0=
To: Dave Crocker 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>
Date: Thu, 18 Jun 2020 15:24:09 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 22:24:19 -0000

On 6/18/20 2:29 PM, Dave Crocker wrote:
> On 6/18/2020 2:10 PM, Jim Fenton wrote:
>> On 6/17/20 12:11 PM, Pete Resnick wrote:
>>> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>>>> DMARC has nothing to do with display of author information to a
>>>> recipient, and everything to do with differential handling by a
>>>> receiving filtering engine.  Were the Sender: field always present,
>>>> that would be the one that DMARC should have used.
>>> It could have chosen the more complicated, "Sender unless not present,
>>> in which case From". But yes, this bit I get. That said, there are
>>> people who have argued that From: was chosen because Sender: was not
>>> displayed. I think that's a silly argument, but it's one that people
>>> still believe.
>> I'm trying to understand why alignment to any header field is important
>> to DMARC in that case.
>
>
> Because operators have found useful correlations in distinguishing
> between messages that are aligned and being 'genuine' versus ones that
> are not aligned.
>
> In the abstraction of theory, you are correct that it shouldn't
> matter.  In the brutality of practice, it appears that it does.
>
We need to consider not just what's a useful correlation today, but what
will continue to be so. As soon as the {spammers, phishers, etc.} catch
on that they can achieve alignment at will, it will cease to be a useful
correlation. History teaches us that will happen quickly.



From nobody Thu Jun 18 15:26:15 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9142A3A103C for ; Thu, 18 Jun 2020 15:26:13 -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, FREEMAIL_FROM=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=gmail.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 IIAsYjw16EWX for ; Thu, 18 Jun 2020 15:26:12 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 9193D3A103B for ; Thu, 18 Jun 2020 15:26:12 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id a137so6624932oii.3 for ; Thu, 18 Jun 2020 15:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7EY/Fo1kgox6jf6vnnjiiQVwEGt93hKRQ8Al16p7CEc=; b=rI6F7LioaUMFiYdrW7nb13sqVXMugig1KgyPiIpJzFVkRdwbFIJXBriBUwM/OWgXR6 HHsRfjK8dqOOtr2EtcLQhcC1kQPjrUhAATXNMjKuKs7696OF/fwZEl3AZVcX6jQMyFmc uplevbS8tiw6sAcnVaHoEjdge3t2RgYGUBbIwZflBisPSRIgaTwb7HKBaxlfJj/3Yd6y iHCDtn7qJjePxcskHR6/k9qoBHT4tL3mNdAiR1+PRgOU46dHdw+fNYFR6tqvj5paQPIG xxj/kezj0e1eEzk9hB8GU3xClKb0DsYqOiwQFw3Yy3Qy4lo3o/k3qXSgsxFwW/Ta5wqI uD5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7EY/Fo1kgox6jf6vnnjiiQVwEGt93hKRQ8Al16p7CEc=; b=nzg/pz0rt7RQKy7DddBaKgK8AAOIZ9vudf5YyoF8NM7Fr196g8rCC3z2PcwL0A3lSE gZ4IkfAVwXSVXW+AHccASKKchIHZ92dW54QM8fuUnRWrJ9GJO3nyVYhVRVNdU9zIsgdd av8m3RAeEoyzqRIHtE/HY5pgYs7AibPhoePglFnhd+FqDwwxAqEuoNpPZ3BKphZtE1U2 YBzbE6tzbMwaqSCofjVY8vIY0B5DdiB5Ja4TCCoIOixXPd9F0d+gRFjn7Qamzw+KpyLw scRpxLQWOkmRw+oPXIqRXFHVBB3tp2U+XfbuNbKbeVCK1xuInueughe3GZYwoyo4YgPA +m/w==
X-Gm-Message-State: AOAM530FWB6Ed45kJFyuP2l9V1BHBTT7g3nEtIhNGtGiey6eFFDtPSk8 OBzq/kkKWasjH/7AgdloN/DmzVF3
X-Google-Smtp-Source: ABdhPJzfvd7CekGwdnbfIR9etMTcNUlwd99P/ajj1tsd0snItVAWIvd/0e1ss6snhmFacllCfQRicw==
X-Received: by 2002:aca:d884:: with SMTP id p126mr959845oig.4.1592519171603; Thu, 18 Jun 2020 15:26:11 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a51b:a5c4:93c:41be? ([2600:1700:a3a0:4c80:a51b:a5c4:93c:41be]) by smtp.gmail.com with ESMTPSA id g2sm1041997oou.0.2020.06.18.15.26.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 15:26:11 -0700 (PDT)
To: Jim Fenton 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>
From: Dave Crocker 
Message-ID: 
Date: Thu, 18 Jun 2020 15:26:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 22:26:14 -0000

On 6/18/2020 3:24 PM, Jim Fenton wrote:
> We need to consider not just what's a useful correlation today, but what
> will continue to be so.

Oh good.  Let's predict the future.  That should be fun.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 18 15:28:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F7A3A1040 for ; Thu, 18 Jun 2020 15:28:17 -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, FREEMAIL_FROM=0.001, 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=gmail.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 RPY6DjHGeyiT for ; Thu, 18 Jun 2020 15:28:16 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 7736E3A103E for ; Thu, 18 Jun 2020 15:28:16 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id j189so6600172oih.10 for ; Thu, 18 Jun 2020 15:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ltl/tpL0VUbli8fkLasSp6T7pnvdZtgYkXdR++o7nU=; b=RoXUsa3DhVKj08cJ5GqF+oQ/M+eU+ZB3dF110kfxGXrewaIcmdJolyM6ZUA8TdmhwP 1Aa2YgTjwfPLjpxZvALJEQIYo8GhrJmz0w+v7xfAFe2XpG/44yfYGKQZqN4spgz/M5Yz DO9k2ObuzGIp7bkHnfo3EGi1sB7RbD1aMeXryWXrhUbQaJoAwRy/5fEXVbiVoUmBjEDO NNWhOW/DvntnFmrW7tv0pZX713utYTugOOl44AbOwMpODXIns/yoASDq3C8pWQRwBge8 hNkccZrYU5QcgHo2G9VF+LBsRbVbKeprrBWFVEgpDDKImU9aItCgdCJsrIACUGXyjW8i YBTg==
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=5ltl/tpL0VUbli8fkLasSp6T7pnvdZtgYkXdR++o7nU=; b=P4tpBFQSs18Op87+99gUtaTIUGIT/yfbeMHOa/sYStX9WjTmnh71CkFcIAfS2OEdbQ 0pS+aXlBW8F53kQBUUw/2j8nv4pChs3nMwqegW4sThyvxH2X3mzPlzhdXysTLcUlq8QY zJfOwWy04TDvoQ9ovPULHiTNPQpY+/H+elsXw3hSUYMD6zy+jypD7/SEUAvAqeyLIxZl 7FaUi48kp8dEYG7f44x1b20VEd7ClMwmuOKzv6YnEa9JrUFK0YGuIw7sKpSXTfoCn/1R HQSxd0WmUzrTfcvAsBvc1twM+lj7jgflEs/eK0poxlmrJG2vG3IiINajDXfnwu05nlY1 RAnw==
X-Gm-Message-State: AOAM530ycgP4Tj/fxV9Hzj+CuioGNCRgwQqoFAiF6HpXZAWnoXKma5zZ 24SVIU9mWYQMNGILwrgv6UP1H/NtqNC6k1jTtqo=
X-Google-Smtp-Source: ABdhPJwB6UyK9gVtwFUQiwH9FUZsnkBZtKcx4/1A1m5zweRHX2yz7ygm2He2mcBU2OEU3ntv6H7aXRU0cOpVpvoPjio=
X-Received: by 2002:aca:1b13:: with SMTP id b19mr944187oib.132.1592519295866;  Thu, 18 Jun 2020 15:28:15 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net> 
In-Reply-To: 
From: Tim Wicinski 
Date: Thu, 18 Jun 2020 18:28:04 -0400
Message-ID: 
To: Dave Crocker 
Cc: Jim Fenton , IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000ed9b8d05a8634ad3"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 22:28:18 -0000

--000000000000ed9b8d05a8634ad3
Content-Type: text/plain; charset="UTF-8"

Have to agree with Dave here.   We have to accept it's a
constantly moving target.

On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker  wrote:

> On 6/18/2020 3:24 PM, Jim Fenton wrote:
> > We need to consider not just what's a useful correlation today, but what
> > will continue to be so.
>
> Oh good.  Let's predict the future.  That should be fun.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

--000000000000ed9b8d05a8634ad3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



    H=
ave to agree with Dave here.=C2=A0 =C2=A0We have to accept it's a=C2=A0=

    constant=
ly moving target.=C2=A0

    On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker =
<dcrocker@gmail.com> wrote:=

    On 6/18/2020 3:=
24 PM, Jim Fenton wrote:
    
> We need to consider not just what's a useful correlation today, bu=
t what
    
> will continue to be so.
    

    
Oh good.=C2=A0 Let's predict the future.=C2=A0 That should be fun.
    

    
d/
    

    
-- 
    
Dave Crocker
    
Brandenburg InternetWorking
    
bbiw.net
    

    
_______________________________________________
    
dmarc mailing list
    
    dmarc@ietf.org
    
https://www.ietf.org/mailman/listinfo/dmarc
    

    

--000000000000ed9b8d05a8634ad3--


From nobody Thu Jun 18 15:42:27 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468EC3A104E for ; Thu, 18 Jun 2020 15:42:25 -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, FREEMAIL_FROM=0.001, 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=gmail.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 6b6YHb2mzMli for ; Thu, 18 Jun 2020 15:42:24 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 1D8773A104B for ; Thu, 18 Jun 2020 15:42:24 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id u23so5854245otq.10 for ; Thu, 18 Jun 2020 15:42:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=O+FLZAGnnVY4OSjfUbQeTWzb0Y+ZpwjY+Xgrn4EK6oE=; b=A/c7F7TisUtF8KG65Sjop1XactzfxhIfkl6FiUf4ZRzdsMgkD2LZ6P/rpvkWwW8SPt z80TKehaiDB095W05wl7QCetvo/eps4SPaqI/Dif2XcgqlV1Fi5lm1wFV8I9dq21Xvat Ps3hivy/Zi3LQV61hYl1+gepmD4+qnJ4sgYB9i03pPxwFNQuvQwD5hy40PBWgGRCJONR rWNxWDT4u92ywU2ZclWLd+i6dxPWBWW597BM89OH5EMAVIGGsHHFGETzU1RJWTdJX3Py AEBNG+SL4bLVZPseY8ucWSMErq8YbKeqWdIbQHD++AWYJ76IM2U0ldHAwW8aZJxZOtAj RcBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=O+FLZAGnnVY4OSjfUbQeTWzb0Y+ZpwjY+Xgrn4EK6oE=; b=oXcMfFHtINd/8ygh/rsSyKhVR1IBTOWxjhSq+E+8NjqAaYb5ToH/8CcPznaSgL1QY0 omBuV4C7TMMFqM/qcA7mR2E3vjmysPFxW1K4eYH5AHrFlKszxv6F9JFfloulLlzt9f6a 8PBLcm/Rr7UgVIEeGnLtwzJCzU9qvS52+2IDPtE2o0smBdTlPyYTxIQ5pk5hjK6voigk UeI6RP1k80Vl9mkdql4XVU3L0QszNb83mOR8x1kvR8oA27/l8PDYrGzhm+D2KZjpYKhh Gw0fuzVincDtorIweKKvSAteMAu+We/221paSNrEaEjP0A7F+ovJq/e4upA6ZoKm2Xr4 0otQ==
X-Gm-Message-State: AOAM532qf4DbJcKbGtxa4HaYVtblq2fGuDF3GCQOoVsyM++eKQJ8r7Sf 9v5bqILDTmswm9y+7UPIr+289dUD
X-Google-Smtp-Source: ABdhPJwWYq6e6urj3l3WHKFUs8HFFLNG152O6D+/62eNphWXJ+v6T8UdK1u0zy1nphxYLx0SYKlQpQ==
X-Received: by 2002:a9d:6c03:: with SMTP id f3mr781557otq.291.1592520143201; Thu, 18 Jun 2020 15:42:23 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a51b:a5c4:93c:41be? ([2600:1700:a3a0:4c80:a51b:a5c4:93c:41be]) by smtp.gmail.com with ESMTPSA id l24sm1007580otf.79.2020.06.18.15.42.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 15:42:22 -0700 (PDT)
To: Tim Wicinski 
Cc: IETF DMARC WG 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>  
From: Dave Crocker 
Message-ID: <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com>
Date: Thu, 18 Jun 2020 15:42:21 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DEB9B5512679B7F66E2A9FBC"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 22:42:25 -0000

This is a multi-part message in MIME format.
--------------DEB9B5512679B7F66E2A9FBC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/18/2020 3:28 PM, Tim Wicinski wrote:
> Have to agree with Dave here.   We have to accept it's a
> constantly moving target.


And now I'll note that when DMARC moved from being a way to authenticate 
a tightly controlled mail stream, as was originally discussed during its 
development, into its broader role, I expressed the same concern that a 
correlation not inherently tied to the misbehavior is one easily routed 
around.

However, there is too much industry force behind this broader use of 
DMARC for such simple logic to have any useful effect.  Rather, we'll 
just have to wait for the bad actors to catch on.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------DEB9B5512679B7F66E2A9FBC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/18/2020 3:28 PM, Tim Wicinski
      wrote:
    
    
    
    
    
      
    Have to
        agree with Dave here.   We have to accept it's a 
    
      
    constantly
        moving target. 
    
    
    
    

    
    
    
    
    And now I'll note that when DMARC moved from being a way to
      authenticate a tightly controlled mail stream, as was originally
      discussed during its development, into its broader role, I
      expressed the same concern that a correlation not inherently tied
      to the misbehavior is one easily routed around.  
    
    
    
    
    However, there is too much industry force behind this broader use
      of DMARC for such simple logic to have any useful effect.  Rather,
      we'll just have to wait for the bad actors to catch on.  
    
    
    
    
    d/
    
    
    
    
    -- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  


--------------DEB9B5512679B7F66E2A9FBC--


From nobody Thu Jun 18 16:01:35 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25263A1067 for ; Thu, 18 Jun 2020 16:01:34 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 IKXVeunO0oOC for ; Thu, 18 Jun 2020 16:01:33 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 931AB3A1066 for ; Thu, 18 Jun 2020 16:01:33 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05IN1VFg020034 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 18 Jun 2020 16:01:33 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592521293; bh=AMk7WXxpI3sNPHm7g9VsXFQxPzqmj9/IWkOO7N6148k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q6KGs0IDKSeqvaTVnfMH0APtBjgudMprBO4GeO5x4BVK3p3Aed4eQmQaGqx39etXA X1fph+pR3MomlYbYkU1Nz7h13g8lTrgqNFTcE/86rOjHy8LsdHUcIBeq9Wl3d8bPnn 4hP4cgdOExUWozkDBtXH64oKYRo+VlKMokuPOsTI=
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>   <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <7b86d6ca-a803-0559-8da2-717a1d78ad18@bluepopcorn.net>
Date: Thu, 18 Jun 2020 16:01:26 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jun 2020 23:01:35 -0000

On 6/18/20 3:42 PM, Dave Crocker wrote:
>
> And now I'll note that when DMARC moved from being a way to
> authenticate a tightly controlled mail stream, as was originally
> discussed during its development, into its broader role, I expressed
> the same concern that a correlation not inherently tied to the
> misbehavior is one easily routed around. 
>
> However, there is too much industry force behind this broader use of
> DMARC for such simple logic to have any useful effect.  Rather, we'll
> just have to wait for the bad actors to catch on. 
>

It would be remarkable for IETF to achieve rough consensus on a
specification with a known vulnerability while we "wait for the bad
actors to catch on." Particularly when that vulnerability relates to an
aspect of the specification that has caused widespread deployment problems.



From nobody Thu Jun 18 19:26:57 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268E43A10D9 for ; Thu, 18 Jun 2020 19:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jkarcQpG; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=JeYw/RqI
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 GLW3uFeyZxv7 for ; Thu, 18 Jun 2020 19:26:48 -0700 (PDT)
Received: from mail.winserver.com (unknown [76.245.57.69]) (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 539C93A10B0 for ; Thu, 18 Jun 2020 19:26:43 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1169; t=1592533599; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=tNoj9BVbgX7VJ0ThHw+jerrJXeQ=; b=jkarcQpG6ago0aBqofemfbe0qJ4Sao+4zCLKEAM6Fzby+9m7iiiCo5xKYhpZ0o F7nMgCj2NSOPZXX3pyb+Jsxcunl8pBhnI1HRuiNdsaL3aYXlC8AHkuZMMNY00JK3 GqFgGclMee9KUuQ8uNLRuOqZjR17u59a53nwgR6u5tPfo=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 22:26:39 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3260898146.1.7028; Thu, 18 Jun 2020 22:26:38 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1169; t=1592533553; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZEt0YH1 Durx5PBMReoG0Llm7zjt2QDGwXGGqGLs0oIg=; b=JeYw/RqI8qp16F1CsY2JZX2 eB7JPvtGviYrsIjfhKByAKG4CzY9Z1dyDMpmSVDgeMoGfdQv2bcz400ImW4am45b jGRD61rNUIYLGhpLUujh9+oupkwWH+mVKWhreEnT4oPSjOUKM0L+TpmlyJjbdmss 1PwJpVuvLBuhXQUZUhOE=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 22:25:53 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4267248078.1.47644; Thu, 18 Jun 2020 22:25:52 -0400
Message-ID: <5EEC2262.4080706@isdg.net>
Date: Thu, 18 Jun 2020 22:26:42 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 02:26:56 -0000

On 6/17/2020 3:11 PM, Pete Resnick wrote:
> On 17 Jun 2020, at 13:27, Dave Crocker wrote:

>> The nature of the hack that mailing lists do, when altering the
>> From: field, makes this clear:  They alter information about the
>> operator handling the message, destroying the original information
>> about content authorship.
>
> Mailing lists that make other choices (throwing away messages from
> DMARC reject senders, denying subscriptions from them, or simply
> ignoring them and ending up with bad consequences) have obviously not
> gone along with the certain forms of the semantic change.
>

+1.

I preferred the "let's honor the policy" list system adaption 
approach.  It was the simplest, less programmatic approach. I did get 
some initial complaints from users who wanted to continue using their 
"junk" ESP email addresses like yahoo.com, aol.com and now icloud.com 
accounts and other larger esp domain accounts with restrictive mail 
policies who switched to restrictive policies. They understood the 
dilemma and used other domains - problem solved.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Thu Jun 18 19:36:04 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6F93A1054 for ; Thu, 18 Jun 2020 19:36:02 -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, FREEMAIL_FROM=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=gmail.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 z8wuWsrMpJMT for ; Thu, 18 Jun 2020 19:36:01 -0700 (PDT)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 455B73A1053 for ; Thu, 18 Jun 2020 19:36:01 -0700 (PDT)
Received: by mail-oi1-x236.google.com with SMTP id c194so7147232oig.5 for ; Thu, 18 Jun 2020 19:36:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BNsjWkA0w/UVWBHU3nMz1s7tAOn9dNkSVHCsCIDNizA=; b=fzjKNU1IX1Q++69kpWg/1ghcE18zQ6Id6QBEOj4Cusc38eS5hhbMVXYFoY0IUzjISz 0yQHiuZcyE4gU7AC+pRcwnfed++/5rqwdKVbXxOFTva0CEtdftYnAZ8Jk8sGT01/tkIT daaNYCBmRABApesZminJEjl9SgqEMoxXdR5hEf7SZ995CMN/zlk5kjzSbcG+h1jd4mjY gmrLzsNJD/5zhPxgyR+eQ4fBF6VDfzOdo1shd+4H1eP42YFqMrwR4l3ya/4YIpXdcOwG mLkuUg/BlE4k94A1mqXCEwJkpMj4AxKvDIxhrjRIwkHMB+fnHLktFEpx6kfUDsOQaYQ1 eCRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BNsjWkA0w/UVWBHU3nMz1s7tAOn9dNkSVHCsCIDNizA=; b=FEeepwgMpAMkAFC4oZcA1kgaDv/oziubPpK6HuVzakCPdQx0Esm5Xw99A654MjbgUZ I2MmWN7f/BC6Xy0e0ilknlCnXX87gKcv7vByQj7vQm+vy3u+6MBTaBYR8lfWFxAL6ZNV veurqIaUWqe3JOioXTqIyQFFeHeharbLVmEMkQsMoneqIPa6th1qpvr2rwW2CIh4x09l ANWgHY0jn+QBbufbMiXtHGqpXl8UtOQOkTf1fHPtW3vevZsXqiEeHjsG89BRLZ2L6/G5 bCdjAjmn82AGqNsAMkDLkXxcqT5NgqjfFA/mY4RfZRnSMY9sPFVI4y6tjuqnZcBnhc2a a6Vw==
X-Gm-Message-State: AOAM531fEbSDMCiNo/y3SZeP5xzH+nxpppxa8iE9aRUk61EIDCJdNPPP 5zeh2vp2pIjH47QIg+f00S+KoxPn
X-Google-Smtp-Source: ABdhPJzbEofNb1AihwdjPP9mK2iCowJOk0Pi2UPmxt4DsgxuByN6FXrwWwhpw/KPUWN+g1Yy2AifXA==
X-Received: by 2002:aca:c711:: with SMTP id x17mr1542879oif.73.1592534160244;  Thu, 18 Jun 2020 19:36:00 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a51b:a5c4:93c:41be? ([2600:1700:a3a0:4c80:a51b:a5c4:93c:41be]) by smtp.gmail.com with ESMTPSA id p13sm1133288otp.58.2020.06.18.19.35.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 19:35:59 -0700 (PDT)
To: Jim Fenton , dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>   <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com> <7b86d6ca-a803-0559-8da2-717a1d78ad18@bluepopcorn.net>
From: Dave Crocker 
Message-ID: <0418eeb2-5753-2029-c32d-d76dfac40715@gmail.com>
Date: Thu, 18 Jun 2020 19:35:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <7b86d6ca-a803-0559-8da2-717a1d78ad18@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 02:36:02 -0000

On 6/18/2020 4:01 PM, Jim Fenton wrote:
> It would be remarkable for IETF to achieve rough consensus on a
> specification with a known vulnerability while we "wait for the bad
> actors to catch on." Particularly when that vulnerability relates to an
> aspect of the specification that has caused widespread deployment problems.

vulnerability?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 18 19:54:39 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC853A0B0C for ; Thu, 18 Jun 2020 19:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Q7NYD6Qd; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Lku6blFG
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 4Tjew8GCeJQk for ; Thu, 18 Jun 2020 19:54:35 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [76.245.57.69]) (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 DFE9E3A107C for ; Thu, 18 Jun 2020 19:54:34 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1097; t=1592535264; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=X7cHNhR61NOexsU0ESEFJUtQi5Y=; b=Q7NYD6Qd/qFvn60Qndwbck9DSWt7XMegK1Uphcf28mUM5Pyq8v9FW8lZq8u3mO FuMCrmALT5gAPO4WHy59XVMCo6JMtGQo/FaqKyQ3WTefPCVEJe64EJfsrUeIc+Hg jcO1dL7a/WI0Y4WZLyBAjKfjxcXUlDn0LDULs+2wWq3Mc=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 22:54:24 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3262563301.1.7908; Thu, 18 Jun 2020 22:54:23 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1097; t=1592535216; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2UHtz38 +gLhb9QyrmFZSjA7ZdwUZizvmzP8RPMOQPLU=; b=Lku6blFGTXsOZUOcFlhzlUu JggBV3evhPzY+yN3l9AQxVQpRZfq0w8PtTJJXixwel+dIxmHJAxJvSqptokNXI/E VjntyPR+kW7lODGrlfPRPmQHM0dsuS7fHd5f/bAZ82stANqkSU0ta6eKV1Vz44wz MmHT2fwYj1bkMWnbtYTA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 18 Jun 2020 22:53:36 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4268911796.1.48332; Thu, 18 Jun 2020 22:53:35 -0400
Message-ID: <5EEC28E2.7010302@isdg.net>
Date: Thu, 18 Jun 2020 22:54:26 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 02:54:37 -0000

On 6/18/2020 6:28 PM, Tim Wicinski wrote:
> On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker wrote:
>>
>> Oh good.  Let's predict the future.  That should be fun.
>
> Have to agree with Dave here.   We have to accept it's a
> constantly moving target.

We, as engineers, do believe we are making the proper decisions, and a 
good bit of the time, we are correct, otherwise we are worthless.

Its called IETF Engineering. I also called it striving to "Getting it 
Right ... the First Time." -- old Westinghouse QA Engineering motto, 
not about perfection but just at least to do it correct and fairly to all.

We have allowed for some real bad decisions to take place within the 
IETF-DKIM work in the last 15+ years.

That is my assessment.

I am seriously hoping through this IETF/DMARC work rendition some real 
solid outcomes can be reached that the entire IETF community, not just 
the self-interest groups behind the scenes, benefit.

No offense to anyone, 15 yrs on this, is not a good thing.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Thu Jun 18 22:16:43 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054A33A0E34 for ; Thu, 18 Jun 2020 22:16:41 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 I_fa-z6NK0QI for ; Thu, 18 Jun 2020 22:16:40 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 EE8683A0E33 for ; Thu, 18 Jun 2020 22:16:39 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05J5GZD2025263 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2020 22:16:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592543797; bh=toN1sxhXHQjjBkaCOn3YWwY3be8ouO19+hXRgJNjgFw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FEVM+M4/JhhIADVu31tz+IVsyqmUS5c7Gy/9W/Iru6brloA0cHMZ2S79s/yYWQu3v iph4rwOrw1NN8B+gubNK9oTwWGKLjhEPbgxsFumgsOHmoTQ1WIJy2WAouP4EOr/7+s B2sF5ZixIihAizyjO7JCrCUiTQHV9sBkVYRWhtyc=
To: Dave Crocker , dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>   <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com> <7b86d6ca-a803-0559-8da2-717a1d78ad18@bluepopcorn.net> <0418eeb2-5753-2029-c32d-d76dfac40715@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <94eb1bb4-4af8-31d3-1737-f59f5baa0222@bluepopcorn.net>
Date: Thu, 18 Jun 2020 22:16:30 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0418eeb2-5753-2029-c32d-d76dfac40715@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 05:16:41 -0000

On 6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to a=
n
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.



From nobody Fri Jun 19 00:00:14 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA13A05DC for ; Fri, 19 Jun 2020 00:00: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, FREEMAIL_FROM=0.001, 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=gmail.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 ciLA6y8bQ5dM for ; Fri, 19 Jun 2020 00:00:11 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 DB8943A053F for ; Fri, 19 Jun 2020 00:00:10 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id u17so5042060vsu.7 for ; Fri, 19 Jun 2020 00:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CpNSNHN7iyjXg1K4YEPKoCSbFfGvMjONAejk27OZ7g4=; b=Gg5PFKsylg5VaqHdBwsYmnUiyCaK9mVxNCIAzICeRkz3ulv2luzPC4F4MncvUEYOc2 xCl7mRL83qAG/gK3lmxSYUUNAXBy3clruO21wfNp87mu+PFbwzJQaYfo1Ehoctj3MT7H Upo2V3myPIPPzustYTMEIyzgSHC+zAAL1xNSHwyKXZd3xqk+m4dcj1zrdTn4QwXylUEH sW6fbsdKiGrMoe4Iq/7q0HQ2sinRoMMlPj2DppyWcZaCyRowDfue7d/Wm7YSiI5bki/D nH7nfETrZad1pXC6NUSIPhHIP8+6hcxy7TDmETMJH2Tb3mLaLi5CiuPqHmKhy8tIuPGN VWJg==
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=CpNSNHN7iyjXg1K4YEPKoCSbFfGvMjONAejk27OZ7g4=; b=dLnwPM6e8zO7pH4WVTNIcstBf7loCv+1Ng2xVTO8CikrcnNJqWl70Tka0/L/aX81oF jhuKENK05vzk/hGpYIcs0hIJmVw8O80Vdfmyz+7BkfvT5vNMa0rcH3LJZazs6CRE5daT 70YueoRHoni7lY1MbzmenoDeHJOxR0/PX7wgKxuqgilIS3THdzMhKotoieL92JpwawMa myg6QBipRpvBCOJ+ABt1bG/1SAITHdi882eC8XQhPyDrOeLdbKFsbZfSGln4zJmjKqiW LRNI3U+yoyio/kE80YYaYkNX1VcqdiblnDtYXwuiWThiWhZ8JQB702glfPQ6Z8vZa4u7 RIfg==
X-Gm-Message-State: AOAM531ZSI22l0eepeTnK16sgWnDHtx/wcjb6T3WiZZ5/pQoFI6BmhMS 05LThyqA8QOk7yrriau0v2scwIr5mkRsg1b/KVs=
X-Google-Smtp-Source: ABdhPJwV4N1JTkoGy4QSFgWTleE8LhZvAfIx+H4s8neFsyXQrDWthMxmFygqjrAozYyEVf8rskLxI6iCBNcoBXTT5u8=
X-Received: by 2002:a67:7dcd:: with SMTP id y196mr6421791vsc.13.1592550009590;  Fri, 19 Jun 2020 00:00:09 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>
In-Reply-To: <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>
From: "Murray S. Kucherawy" 
Date: Thu, 18 Jun 2020 23:59:57 -0700
Message-ID: 
To: Jim Fenton 
Cc: Dave Crocker , IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 07:00:12 -0000

On Thu, Jun 18, 2020 at 3:24 PM Jim Fenton  wrote:
> We need to consider not just what's a useful correlation today, but what
> will continue to be so. As soon as the {spammers, phishers, etc.} catch
> on that they can achieve alignment at will, it will cease to be a useful
> correlation. History teaches us that will happen quickly.

RFC 7489 was published just over five years ago now.  I would imagine
that if Jim is correct, we would see evidence of it by now.

So to those of you with access to such (e.g., M3AAWG regulars among
us), is there evidence in the wild of spammers and phishers using
discardable (ahem) domains to achieve alignment and improve their
delivery success stories?

-MSK, sans chapeau


From nobody Fri Jun 19 00:41:07 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD54E3A07BB for ; Fri, 19 Jun 2020 00:41:06 -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 (1024-bit key) header.d=wordtothewise.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 kbxr8Ukj0_Ol for ; Fri, 19 Jun 2020 00:41:05 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 770E43A07BA for ; Fri, 19 Jun 2020 00:41:05 -0700 (PDT)
Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 55B259F149; Fri, 19 Jun 2020 00:41:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1592552464; bh=yKz/h6b1lcoM3+vX67ulURmT/ZamNRJOAzQpb35sLPk=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hRb3gbXrl0xDb1Gi5J+KW1UF8qJdCEHw0rfCYV2SFzFvhEpHgIq0ue9lKCphmrW+a CAlQ9S9KgyhEKpGakoUXRwYLGoML5y7wQPh/068YBoGTETwZJ3FL1C75Ip8TaP3isf iMPiuKoJSM/N5yV3QU+yyU2pWFSAXeM5pLmJd8Fo=
From: Laura Atkins 
Message-Id: <358A1939-06A8-4FE9-8AB8-8B45867030B9@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_17D7074A-9087-4942-A21F-B903035C23CA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 19 Jun 2020 08:40:59 +0100
In-Reply-To: 
Cc: Jim Fenton , Dave Crocker , IETF DMARC WG 
To: "Murray S. Kucherawy" 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 07:41:07 -0000

--Apple-Mail=_17D7074A-9087-4942-A21F-B903035C23CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 19 Jun 2020, at 07:59, Murray S. Kucherawy  =
wrote:
>=20
> So to those of you with access to such (e.g., M3AAWG regulars among
> us), is there evidence in the wild of spammers and phishers using
> discardable (ahem) domains to achieve alignment and improve their
> delivery success stories?

There is certainly ample evidence that spammers are: sing disposable =
domains / rotating through domains and aligning authentication so that =
they will pass DMARC.=20

But DMARC alignment alone is not sufficient for reaching the inbox. Ask =
all of my non spamming clients who manage to screw up their delivery.=20

laura=20

--=20
Having an Email Crisis?  We can help! 800 823-9674=20

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741	=09

Email Delivery Blog: https://wordtothewise.com/blog=09








--Apple-Mail=_17D7074A-9087-4942-A21F-B903035C23CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



    On 19 Jun 2020, at 07:59, Murray S. Kucherawy <superuser@gmail.com>=
 wrote:

    So to those =
of you with access to such (e.g., M3AAWG regulars among
    us),=
 is there evidence in the wild of spammers and phishers using
    discardable (ahem) domains to achieve alignment and improve =
their
    delivery success stories?

    There =
is certainly ample evidence that spammers are: sing disposable domains / =
rotating through domains and aligning authentication so that they will =
pass DMARC. 

    But DMARC =
alignment alone is not sufficient for reaching the inbox. Ask all of my =
non spamming clients who manage to screw up their =
delivery. 

    laura 

    

    -- 
    Having an Email Crisis? =
 We can help! 800 823-9674 

    Laura Atkins
    Word =
to the Wise
    laura@wordtothewise.com
    (650) =
437-0741		=


    Email Delivery Blog: https://wordtothewise.com/blog	=







    

    

    =

--Apple-Mail=_17D7074A-9087-4942-A21F-B903035C23CA--


From nobody Fri Jun 19 05:36:40 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F13A0982 for ; Fri, 19 Jun 2020 05:36:38 -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, FREEMAIL_FROM=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=gmail.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 ZziVBFP6-s90 for ; Fri, 19 Jun 2020 05:36:37 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 0A7203A097C for ; Fri, 19 Jun 2020 05:36:36 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id z1so7023673qtn.2 for ; Fri, 19 Jun 2020 05:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=+VfztAEN1voa6tsKkEH/mv+i1lXR+6ohpbNkSMLjDVg=; b=oOEqNEN+pH3veHGfcI6MgHvgYmQLSvo+sYuSETtsG7fFLQrtmg7K3ZccTOZqWuMFZ8 Lehp91TbmWRwUnpQG06itfaZcxzBb+h3n2cClztmHL+o9sEBhFfiXFe3Yv38Fk4aZyL6 u1eVpTxfjAFL2gBrSQ22dvPNpDx0grfh+ut+1BqF11hZi64AZmTZ2HtPdVFPmQR4N4AM GuIEdJAi+NxZHu47OeabtHdUBAYJEWAKBej9xs6+Di7b4qOJLh3eY/rJrhfTf+AWv3VT fK25rhmB+7sJZyLxJuNo9t3M1V/8OHXHZXIHwJG6fkjKQNDkHFrhpIOroySkN2XENlAd S+fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+VfztAEN1voa6tsKkEH/mv+i1lXR+6ohpbNkSMLjDVg=; b=qg4TFAl1iEramRHAhyRrI1BZmKdfdOWvX8cce8Z3Ftxe401wdpsKO7WrVhncLq9J8M /4x0yrN0q+L4R4czRM5QC7/yIVpncSlNOtjDONlIaqJsmbZ4i0lSB76BXW72Hl67vz7N Fm/572pimWejiefrZpcgTvZ1wPL5RQ+Ry1wSx/AoB+e3rrpN7Q8av/Of1P6JkDLD4X9b ooqveofp9mtED3GdsXvNmMd1bPZEY4v8WFau1GHcQ53SlcsrqzSJPFMbFS/9fEzhWkJd E6xUNPoagOBGt/0lmARJAlMrcSb5bGtg8v8Yf8j4esE40lDBVyxaN06VF0729b0KMoZw VvlQ==
X-Gm-Message-State: AOAM532Aq4mioTH3rkWLMSH6ji30sSBY35N/d0A40x2ctks/nqiODW0l U+MYsbLA8sO4n6876gZIYzGYkip5
X-Google-Smtp-Source: ABdhPJxLKfTht6wMJX5nWW+V6mcK1ODAsZYbrkjkOlk9bso8+KWd/1j0iA1f1LQ0OOlrxEfQ27oRrQ==
X-Received: by 2002:aed:396a:: with SMTP id l97mr3048039qte.10.1592570195857;  Fri, 19 Jun 2020 05:36:35 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a0ea:5919:94e4:7b06? ([2600:1700:a3a0:4c80:a0ea:5919:94e4:7b06]) by smtp.gmail.com with ESMTPSA id w204sm6199116qka.41.2020.06.19.05.36.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 05:36:35 -0700 (PDT)
To: Jim Fenton 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>   <4f03abd6-2a8a-02c1-1da4-272552d88d93@gmail.com> <7b86d6ca-a803-0559-8da2-717a1d78ad18@bluepopcorn.net> <0418eeb2-5753-2029-c32d-d76dfac40715@gmail.com> <94eb1bb4-4af8-31d3-1737-f59f5baa0222@bluepopcorn.net>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <4ce984fd-0643-e34d-25db-8a9cf02e96c2@gmail.com>
Date: Fri, 19 Jun 2020 05:36:32 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <94eb1bb4-4af8-31d3-1737-f59f5baa0222@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 12:36:38 -0000

On 6/18/2020 10:16 PM, Jim Fenton wrote:
> On 6/18/20 7:35 PM, Dave Crocker wrote:
>> vulnerability? 
> Yes. When bad actors (your choice of words) can work around an aspect of
> the specification that is depended upon to enable differential handling
> by a receiving filtering engine (again your choice of words), that is a
> vulnerability.


Thanks for explaining what vulnerability means, but my question was 
meant to prod you to explain what vulnerability you claim is there.

I've looked over your postings of the last few days and somehow I'm not 
seeing that described.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From btv1==439fc1c7bf8==fosterd@bayviewphysicians.com  Fri Jun 19 06:06:33 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BFC3A09EB for ; Fri, 19 Jun 2020 06:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 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, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 llf3_1Bwcn59 for ; Fri, 19 Jun 2020 06:06:32 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512C03A099B for ; Fri, 19 Jun 2020 06:06:32 -0700 (PDT)
X-ASG-Debug-ID: 1592571991-11fa313a101c6010001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id XUEA9EUOFUpsYmeX (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 19 Jun 2020 09:06:31 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=ZygonuuZxZMtuUQVrvcSS7zbIUs2YaWlXoYWE8I9sIo=; b=c5XirPEEtuu1MQb0n7LgcafAJdP8dMQFMVjtgl1CMT+P5sWy0qb19hp0w9qrNYR98 BkTVS4MyTAZRD3TsaZyHl4W96tqNl2DvLfxZ/cYwrwAe6RULq6Z+xHbLyDLBbUHUG /jbBnBjNwNEzoPq9U38f0+vRnLt2Jgz1DMCbcCp2M=
Received: by webmail.bayviewphysicians.com via HTTP; Fri, 19 Jun 2020 09:06:24 -0400
To: dmarc@ietf.org
Date: Fri, 19 Jun 2020 09:06:20 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/multipart; boundary=78ed938d7fa7441a84687fb0297fc1b8
X-Android-Message-ID: 
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
From: "Douglas E. Foster" 
X-Exim-Id: b4c01619-4e34-48c7-b31a-77b2b4579c5b
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592571991
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 2785
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82660 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 13:13:38 -0000

This is a multipart message in MIME format.

--78ed938d7fa7441a84687fb0297fc1b8
Content-Type: multipart/alternative; boundary=f33537d2639149f2b702cd98b4ca6086

--f33537d2639149f2b702cd98b4ca6086
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

DMARC helps establish a verified identity.  Delivery is based on 
reputation.  The two are very different. 

Unwanted mail with DMARC validation will be blocked on the same basis is 
unwanted mail without it.

But a verified identity is helpful for ensuring that wanted mail is not 
blocked.

There is no vulnerability created by DMARC.

On Jun 19, 2020 1:17 AM, Jim Fenton  wrote:On 
6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to an
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--f33537d2639149f2b702cd98b4ca6086
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


    DMARC helps establish a verified identity.  Delivery=
 is based on reputation.  The two are very different. 

    Unwanted mail with DMARC validation will=
 be blocked on the same basis is unwanted mail without it.

    But a verified ide=
ntity is helpful for ensuring that wanted mail is not blocked.

    There is no vulnerability created by=
 DMARC.

    On Jun 19, 2020 1:17 AM, Jim Fenton <fenton@bluepopcorn.net> =
wrote:
    On 6/18/20 7:35 PM, Dave Crocker wrote:> On 6/18/2020 4:01 PM, Jim Fenton wrote:
    >> It would be remarkab=
le for IETF to achieve rough consensus on a
    >> specification with a =
known vulnerability while we "wait for the bad
    >> actors to catch on=
." Particularly when that vulnerability relates to an
    >> aspect of t=
he specification that has caused widespread deployment
    >> problems.<=
br>>
    > vulnerability?

    Yes. When bad actors (your choice of wo=
rds) can work around an aspect of
    the specification that is depended upo=
n to enable differential handling
    by a receiving filtering engine (again=
 your choice of words), that is a
    vulnerability.


    ____________=
___________________________________
    dmarc mailing list
    dmarc@ietf.org=

    https://www.ietf.org/mailman/listinfo/dmarc

    

--f33537d2639149f2b702cd98b4ca6086--

--78ed938d7fa7441a84687fb0297fc1b8--


From nobody Fri Jun 19 08:18:52 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7591A3A081C for ; Fri, 19 Jun 2020 08:18:51 -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=valimail.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 sbeIpNwdjgLc for ; Fri, 19 Jun 2020 08:18:49 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 9B5543A07F9 for ; Fri, 19 Jun 2020 08:18:49 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id u17so7471556qtq.1 for ; Fri, 19 Jun 2020 08:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4xzRqPyyJ/29uM/yEuYNfiQHWKBAZ+Gnry56Ht5ss/A=; b=gZdFO9v9qNJOHCZR7iu5TzjwwIKKwPtzGr4kvXK/zAO+STIrDc91yl90ohJtgkjHb6 N2P32nSB8Jbu0cDcqKYaEKnV5w1Xs/+HXrE2GW1dtTxCcMI9h3xWpMRwLITtlJnhsC9G bgQhZHYYUJZMW4gyoseYahp57tt0sKsu1QqnRDMWIYWxJFCGdWytOl1BkHpjcYB330/Q IaFd4V4ckDLJf6kWrDkaP0tKc/LMwFEh1CGwj98ftQOWYHXewf65IQjRDiPRTY3bM09b +JD/zAcqsjK/XKVYq1105iqk7vUlOFREaofsf9xfq+LjQt7/dYeWIMKPRzqLu93a+dQ4 i1mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4xzRqPyyJ/29uM/yEuYNfiQHWKBAZ+Gnry56Ht5ss/A=; b=iX/ivNHDQNox2kAhxR0PrYzgaZo6hRbqSLGnZGGVL0seBzT5pSM8W2S8rycX3MNi1w TrrMQgnsIojpi9nT4dfoyHBeDlMUQ2ilnEMA0sgwwGlwrPxxUj+/QiAF/CcT6vBW0Qj+ nDwASEKoDUzdlCa+tvrfNJ2bhNwi8FO+5cTWnhP51Ek8DevNbwLcmeadumhu2tT9Z4LX GGxz9zQMKm+TC/nqwmW0+aWDl9wwKIgufYZUXJ+WuH8m3WunrkmhhuVnpVKYTXmOOMZG JVZqgQ4oI7A0Enn/8xrsU/Sf+z8vAW+pMLi5yrbi1tjKeH/gtNraOU/lqXKc6aaK1Dyv jnKQ==
X-Gm-Message-State: AOAM530Hjf618+9wq7UoqWagOt+zUa+re8BfmoD64Ku4cyWNTloyggdX Lx5OrNhGoAJLyZHHSMeLcukgRXhdFh/ZA0r//lZc2SUt6kg=
X-Google-Smtp-Source: ABdhPJz0LtwTc2TilL2NeXc1P4tXI4OKDSIZ6sjjA4fcpxsPWfkzDaIRjFti27Nn0H0SxQqcfVwm/JWloAMZ1ekB8wQ=
X-Received: by 2002:aed:2237:: with SMTP id n52mr3715376qtc.83.1592579927899;  Fri, 19 Jun 2020 08:18:47 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Todd Herr 
Date: Fri, 19 Jun 2020 11:18:36 -0400
Message-ID: 
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e1149405a87168ea"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 15:18:52 -0000

--000000000000e1149405a87168ea
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 9:13 AM Douglas E. Foster <
fosterd@bayviewphysicians.com> wrote:

> DMARC helps establish a verified identity.  Delivery is based on
> reputation.  The two are very different.
>

Laura Atkins wrote:

> DMARC alignment alone is not sufficient for reaching the inbox. Ask all of
> my non spamming clients who manage to screw up their delivery.


I cannot agree more with both of these statements.

There are countless entities in the email ecosystem, both legit senders and
bad actors, who believe that authentication alone is enough to earn the
privilege of delivery to the inbox, and they continue to be misinformed on
that point.

Authentication allows the receiving entity to reliably apply to the message
in question any reputation information that the receiving entity has
accumulated for the verified identity.

A published DMARC policy allows the domain owner to request treatment by
the receiving entity for mail that does not pass authentication checks; the
receiving entity can honor this request or not based on their own local
policies.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@valimail.com
*p:*


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

--000000000000e1149405a87168ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Fri, Jun 19, 2020 at 9:13 AM Douglas E=
. Foster <fosterd@bayvi=
ewphysicians.com> wrote:
    DMARC helps es=
tablish a verified identity.=C2=A0 Delivery is based on reputation.=C2=A0 T=
he two are very different.=C2=A0

    Lau=
ra Atkins wrote:
    DMAR=
C alignment alone is not sufficient for reaching the inbox. Ask all of my n=
on spamming clients who manage to screw up their delivery.=C2=A0

    I cannot agree more with both of these statements.=C2=
=A0

    There are countless entities in the email ecos=
ystem, both legit senders and bad actors, who believe that authentication a=
lone is enough to earn the privilege of delivery to the inbox, and they con=
tinue to be misinformed on that point.

    Authenticat=
ion allows the receiving entity to reliably apply to the message in questio=
n any reputation information that the receiving entity has accumulated for =
the verified identity.=C2=A0

    A published DMARC pol=
icy allows the domain owner to request treatment by the receiving entity fo=
r mail that does not pass authentication checks; the receiving entity can h=
onor this request or not based on their own local policies.

    <=
/div>
    --=C2=A0
    Todd Herr<=
/span> | Sr. Technical Program Manager
    p:  

    This em=
ail and all data transmitted with it contains confidential and/or proprieta=
ry information intended solely for the use of individual(s) authorized to r=
eceive it. If you are not an intended and authorized recipient you are here=
by notified of any use, disclosure, copying or distribution of the informat=
ion included in this transmission is prohibited and may be unlawful. Please=
 immediately notify the sender by replying to this email and then delete it=
 from your system.
    

--000000000000e1149405a87168ea--


From nobody Fri Jun 19 08:38:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0523A0B45 for ; Fri, 19 Jun 2020 08:38:16 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 IUuAq1w6C2kd for ; Fri, 19 Jun 2020 08:38:15 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 36BB93A0C70 for ; Fri, 19 Jun 2020 08:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592581091; bh=tWEhurArd/iu82f5g4Ix8twbAX6S3u03xGpu7iwatsk=; l=3155; h=To:References:From:Date:In-Reply-To; b=AdNaAbT7vuarVpRnOyVhj4XjtZNUbxQqXCWiznfX8GAaAof3gUpQaAUDIp0Ol/kJz 99cEaWm+LfFu6YPRKRVT4LBA49eu72Sh1nIZql8/8DQEdwwS5kQW5owkF/UQ0e8aTa zi2+khroc9R8hcL/rIrrWXhn2Ap/RihFo9cG/NNTNer3ZhGDP14zgKdqjuj6O
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.170.96.64]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EECDBE2.000069A8; Fri, 19 Jun 2020 17:38:10 +0200
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net>
From: Alessandro Vesely 
Message-ID: <2a33d668-61f9-1059-319b-3088568e0127@tana.it>
Date: Fri, 19 Jun 2020 17:38:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5EEBBA09.8070207@isdg.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 15:38:28 -0000

Hector,

consider a mailing list as a publishing organization, which is what it
is.  If article submission happened via HTTP, say, like in web fora,
there would be no reason to talk about From: rewriting.  The
fortuitous circumstance that both article submission and the final
distribution happen through SMTP generated the current conundrum.

It presumably seemed to be easier or less intrusive to tag the
Subject: and leave the From: unaltered.  The correct approach should
have been to use the publishing organization's own From:, possibly
adding the author's name or initials to the Subject:.  We only realize
that mistake now, after the introduction of email authentication.

Yes, we kept using the wrong arrangement for 40+ years.  That is not a
good reason to persevere.


Best
Ale
-- 


On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote:
> Alessandro,
> 
> There are long time solid reasons why the "Local.From" field needs to
> be stable. In particular, with local messaging, unless the local
> system allows for anonymous entry of the Local.From field when
> creating a Local message, there is a MUST for a 1 to 1 association
> with the account.
> 
> If local mail is exported for a external network, it doesn't matter
> what mail network it is, you really don't want to introduce the idea
> of allowing the changing of the Network.from field and making it
> anonymous or disassociated with the original source. The domain is
> associated with the source of the message, and the user part of the
> address reflects the user account at the domain.  There are good
> reasons for that.   Lets say the user is causing a problem on a remote
> system. Using the network.From, the remote system could contact the
> original system and issue a complaint.  If we were "free" to remove
> that idea, it be would harder to trace it.   DKIM allows you to lock
> that field down so that it can't be tampered with.
> 
> You have to understand the long time pov of developers that have been
> at this for 40 years.  Every system I have worked, the different
> networks, it was the same thing -- leave the from field alone! Do not
> make it "anonymous" or capable of being an "unknown."
> 
> Its the same for Instant Messaging, for Chatting, the TELEPHONE, the
> Caller ID, etc, it is a TABOO to change the "From" entity.
> 
> If you want to continue your line of logic to rationalize Rewriting,
> then you need to make it "protocol complete"  to help keep the
> association of the From field with the original source intact. But
> more importantly, it should have get permission from the original
> domain in order to rewrite. This can be done with a DMARC tag extension:
> 
> DMARC p=reject|quarantine ... rewrite=0|1
> 
> The default sides with highest security -- No Rewriting. But if the
> domain wishes to allow for rewriting, then it should explicitly state
> it in this policy record, rewrite=1.
> 
> This is something I could possibly support IFF the originating domain
> allows it. There would other things to consider to tie the loose ends,
> but the #1, would be the rewrite=1 tag.
> 


From nobody Fri Jun 19 08:48:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A223A07A0 for ; Fri, 19 Jun 2020 08:48:26 -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 (1024-bit key) header.d=drkurt.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 EFjRN8a3TWuZ for ; Fri, 19 Jun 2020 08:48:24 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 8FA403A0795 for ; Fri, 19 Jun 2020 08:48:24 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id l6so9686574ilo.2 for ; Fri, 19 Jun 2020 08:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RxkAECcykggM40DT9nPy5JwyVyUr8lY9mZ7yvC6iQwk=; b=cfvvkkzMyS2BC/y8TD8XzTRGvzHjDVNYBeZmF7SnM/vtkgpwfGvIStj1tMdRJSiMQo JMXjp0KJcQYeUOb64xac4UySlrpe86k1qigUIIV/wMJzi+HwQQNRUCyFVJARyM6nXrJp EJxeQ1mnAuN5eFPGmlmvA7QEy9jSn175Jbv9s=
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=RxkAECcykggM40DT9nPy5JwyVyUr8lY9mZ7yvC6iQwk=; b=eEmZtUVSoeR93tptp0DsLa+p0TFArLt83Wbp9WwGpw9G2BEutfr+lB2EEkD6joTKMj L+3/3I3kzlRl9yx2Tl9j3Qwr2EAq7wExQjYkrLfG1Tk0pRUrMx1dCL120G5Y0aTPq7ti W/f+cFneoWah/vajmKf3XpJK91827WB1TfouZ/nwVbnl5e7pgoD0SqPwUqe436i+3Ax9 A7ZQg+tHn2F8YGTfyAFFIOhgXSAFOv3RRCCh8pcIb3aeqN94hS940hlci/rppCneFzYk xCpmC+5/zk824iURii+1IIfSszx9Bp9+mAwZGnloBkByIlhiIpsKJS8zZUEWiLQ9aj2V uhfg==
X-Gm-Message-State: AOAM531JdvHUSXAD4utN4byYB3YITYJYkpFZ5EtIuDLvzQNT1/nFZEzP 7nAVZQPrcn8Qtv5ByJ0rbtX+WoQ6VulNPVZkytAItQ==
X-Google-Smtp-Source: ABdhPJzL+GKqGucVJTp9N+Uuh21QbThLCtww1ccb7Kqr20B7Dh8C9PBG0TDk44fw2ypwSLVEqPW8E9lgbdrZZapm7DI=
X-Received: by 2002:a92:5e59:: with SMTP id s86mr4251497ilb.104.1592581703764;  Fri, 19 Jun 2020 08:48:23 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <05516d64-96ef-767e-f94e-c4c54412209b@bluepopcorn.net> <546bee8d-265e-e6e7-2d27-feaf8fd09c2a@gmail.com> <18eb8c4c-4b76-8b74-38fe-aaacf23b3bbe@bluepopcorn.net>  <358A1939-06A8-4FE9-8AB8-8B45867030B9@wordtothewise.com>
In-Reply-To: <358A1939-06A8-4FE9-8AB8-8B45867030B9@wordtothewise.com>
From: "Kurt Andersen (b)" 
Date: Fri, 19 Jun 2020 08:47:56 -0700
Message-ID: 
To: Laura Atkins 
Cc: "Murray S. Kucherawy" , Jim Fenton ,  Dave Crocker , IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000baa49f05a871d29e"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 15:48:26 -0000

--000000000000baa49f05a871d29e
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins 
wrote:

> On 19 Jun 2020, at 07:59, Murray S. Kucherawy  wrote:
>
> So to those of you with access to such (e.g., M3AAWG regulars among
> us), is there evidence in the wild of spammers and phishers using
> discardable (ahem) domains to achieve alignment and improve their
> delivery success stories?
>
>
> There is certainly ample evidence that spammers are: sing disposable
> domains / rotating through domains and aligning authentication so that they
> will pass DMARC.
>

Here's an article citing exactly such an example from today's headlines:
https://threatpost.com/bofa-phish-gets-around-dmarc-other-email-protections/156688/
Sadly, the explanation of what DMARC is/does is botched. (related original
article:
https://www.armorblox.com/blog/blox-tales-7-bank-of-america-credential-phishing/
which details the specifics of the phishing attack - sent from Yahoo,
misleading display name, misleading newly registered domain and URL)

--Kurt

--000000000000baa49f05a871d29e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Fri, Jun 19, 2020 at 12:41 AM Laura At=
kins <laura@wordtothewise.com=
> wrote:
    On 19 Jun 2020, at 07:59, Murray S. Kucherawy <=
;superuser@gmail.c=
om> wrote:

    So to those of you with access to such=
 (e.g., M3AAWG regulars among
    us), is there evidence in the wild of spam=
mers and phishers using
    discardable (ahem) domains to achieve alignment =
and improve their
    delivery success stories?
    =


    There is certainly ample evidence that spammers are: si=
ng disposable domains / rotating through domains and aligning authenticatio=
n so that they will pass DMARC.=C2=A0
    Here's an article citing exactly such an example from toda=
y's headlines:=C2=A0https://threatpost.com/bofa-ph=
ish-gets-around-dmarc-other-email-protections/156688/ Sadly, the explan=
ation of what DMARC is/does is botched. (related original article:=C2=A0https://www.armorblox.com/blog/blox-tales-7-bank-of-america-=
credential-phishing/ which details the specifics of the phishing attack=
 - sent from Yahoo, misleading display name, misleading newly registered do=
main and URL)
    =C2=A0
    --Kurt
    

--000000000000baa49f05a871d29e--


From nobody Fri Jun 19 09:41:23 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63833A0CC4 for ; Fri, 19 Jun 2020 09:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2-Nniu5QvHIv for ; Fri, 19 Jun 2020 09:41:19 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDCE3A0CC2 for ; Fri, 19 Jun 2020 09:41:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id A0AFDB149FDF; Fri, 19 Jun 2020 11:41:14 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1P0cuXwA9bJ; Fri, 19 Jun 2020 11:41:12 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 12E22B149FD2; Fri, 19 Jun 2020 11:41:11 -0500 (CDT)
From: "Pete Resnick" 
To: "Alessandro Vesely" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 11:40:27 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net>
In-Reply-To: <2a33d668-61f9-1059-319b-3088568e0127@tana.it>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 16:41:22 -0000

On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:

> consider a mailing list as a publishing organization, which is what it
> is.

No, it isn't. It is a Mediator. See RFC 5598.

> If article submission happened via HTTP, say, like in web fora,
> there would be no reason to talk about From: rewriting.

Take my particular case: I don't get SMTP email from IETF mailing lists. 
I point my email client to imap.ietf.org and read the messages directly 
out of the mailboxes there. As people send email to the list, the 
messages are deposited into the appropriate IMAP mailbox for the list. 
Some of the messages (mistakenly IMO) have their Subject's munged, but 
not on all lists, and certainly not on the main IETF list. Usually, only 
trace info (Received: fields), a set of List-*: fields, an Archived-At: 
field, and similar are added, but otherwise, the contents of the message 
(including the normal headers) are unadulterated. That's good: I can 
reply to the author directly, reply to the list, or reply all as I see 
fit, or I can check S/MIME signatures, or I can use the "Add person to 
my address book" feature of my client, etc. It all works because nothing 
is munged. It is as it should be.

> The
> fortuitous circumstance that both article submission and the final
> distribution happen through SMTP generated the current conundrum.

Why should using SMTP for *message* (not "article") distribution change 
anything in the example above?

And let's not pretend that it is just mailing lists that have this 
problem. The "resend" feature on my email client breaks if servers honor 
p=reject and can't be bothered to check the Resent-*: fields and realize 
that I am a legit sender. Alias expansion breaks. The problem is that a 
whole set of legitimate and documented features in email were simply 
dismissed as unimportant to keep in the first round of DMARC (or, more 
fairly, probably weren't properly considered).

> It presumably seemed to be easier or less intrusive to tag the
> Subject: and leave the From: unaltered.

No, that's rewriting history. The presumption of all Mediator-type 
transactions was that the receiving email client was to deal with the 
message (the thing with the identical Message-ID) with its original 
semantics, adding only Resent-*: or List-*: fields to add the semantic 
of the mediation event. Even rewriting Subject: is a problematic hack 
which the List-*: fields were created to avoid.

> The correct approach should
> have been to use the publishing organization's own From:, possibly
> adding the author's name or initials to the Subject:.  We only realize
> that mistake now, after the introduction of email authentication.
>
> Yes, we kept using the wrong arrangement for 40+ years.  That is not a
> good reason to persevere.

No, sorry, you've got the history entirely on its head. For 40+ years, 
we had a set of features of the email system which allowed an email 
message to be copied and/or moved around in loads of different ways (in 
archives, in IMAP stores, in mail clients), and one of those ways was 
always "reintroduce the message back into the transport system" using 
trace info in the message header to see the details of that 
reintroduction. DMARC came along and decided that that particular set of 
features was not worth addressing, or too hard to address, or maybe 
didn't realize that such features were going to be a problem.

Maybe it's time to abandon that set of features. I personally don't 
think so, but I could be in the rough part of the rough consensus. But I 
do think that set of features can be preserved with a bit of work, and I 
think that work is worth doing. But if we are going to abandon those 
features, a better argument will need to be made than "Oh, in retrospect 
we realize that email was doing it wrong for 40+ years." That argument 
is bogus.

pr

> On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote:
>> Alessandro,
>>
>> There are long time solid reasons why the "Local.From" field needs to
>> be stable. In particular, with local messaging, unless the local
>> system allows for anonymous entry of the Local.From field when
>> creating a Local message, there is a MUST for a 1 to 1 association
>> with the account.
>>
>> If local mail is exported for a external network, it doesn't matter
>> what mail network it is, you really don't want to introduce the idea
>> of allowing the changing of the Network.from field and making it
>> anonymous or disassociated with the original source. The domain is
>> associated with the source of the message, and the user part of the
>> address reflects the user account at the domain.  There are good
>> reasons for that.   Lets say the user is causing a problem on a 
>> remote
>> system. Using the network.From, the remote system could contact the
>> original system and issue a complaint.  If we were "free" to remove
>> that idea, it be would harder to trace it.   DKIM allows you to 
>> lock
>> that field down so that it can't be tampered with.
>>
>> You have to understand the long time pov of developers that have been
>> at this for 40 years.  Every system I have worked, the different
>> networks, it was the same thing -- leave the from field alone! Do not
>> make it "anonymous" or capable of being an "unknown."
>>
>> Its the same for Instant Messaging, for Chatting, the TELEPHONE, the
>> Caller ID, etc, it is a TABOO to change the "From" entity.
>>
>> If you want to continue your line of logic to rationalize Rewriting,
>> then you need to make it "protocol complete"  to help keep the
>> association of the From field with the original source intact. But
>> more importantly, it should have get permission from the original
>> domain in order to rewrite. This can be done with a DMARC tag 
>> extension:
>>
>> DMARC p=reject|quarantine ... rewrite=0|1
>>
>> The default sides with highest security -- No Rewriting. But if the
>> domain wishes to allow for rewriting, then it should explicitly state
>> it in this policy record, rewrite=1.
>>
>> This is something I could possibly support IFF the originating domain
>> allows it. There would other things to consider to tie the loose 
>> ends,
>> but the #1, would be the rewrite=1 tag.
>>


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 09:46:18 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE703A0B45 for ; Fri, 19 Jun 2020 09:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 iUJB7CCux2JB for ; Fri, 19 Jun 2020 09:46:15 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC25A3A0AFE for ; Fri, 19 Jun 2020 09:46:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id CF59CB14A231; Fri, 19 Jun 2020 11:46:14 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnz0gQzzuMZI; Fri, 19 Jun 2020 11:46:13 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 74EEBB14A227; Fri, 19 Jun 2020 11:46:12 -0500 (CDT)
From: "Pete Resnick" 
To: "Alessandro Vesely" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 11:46:11 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 16:46:17 -0000

On 19 Jun 2020, at 11:40, Pete Resnick wrote:

> The presumption of all Mediator-type transactions was that the 
> receiving email client was to deal with the message (the thing with 
> the identical Message-ID) with its original semantics, adding only 
> Resent-*: or List-*: fields to add the semantic of the mediation 
> event.

That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:

"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 10:09:05 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1E3A0C89 for ; Fri, 19 Jun 2020 10:09:03 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 PR0m_s1-Y_4f for ; Fri, 19 Jun 2020 10:09:01 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 8A8C63A0C9C for ; Fri, 19 Jun 2020 10:09:01 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05JH8wkR005381 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 19 Jun 2020 10:08:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592586539; bh=BFf/YRB7edjR5hrl8PuV6+ovSsSKQA+RYJPAvRx8Ifc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MPHpxK2ujBCyKsKYuxYIhJozV/sHct5jN3TfpDyhQzkhjd2ysEfQi7MqtmDlwDGpF 0aZa49t7CqFT+B8C9NK2PNZzzxng1f8JrThwxrjALRF9LOAU64jjddrKKCvTVMCre9 CTPGJLn791FTTiAESDAv9IXenrY+MKKHzHTDWHlg=
To: "Douglas E. Foster" , dmarc@ietf.org
References: 
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>
Date: Fri, 19 Jun 2020 10:08:52 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 17:09:04 -0000

On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> DMARC helps establish a verified identity. Delivery is based on
> reputation. The two are very different.
>
> Unwanted mail with DMARC validation will be blocked on the same basis
> is unwanted mail without it.
>
> But a verified identity is helpful for ensuring that wanted mail is
> not blocked.

A verified identity is established by DKIM and/or SPF. What is DMARC
adding in this respect?



From nobody Fri Jun 19 10:21:03 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848523A0996 for ; Fri, 19 Jun 2020 10:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 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, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 UNc-CM4Kb0Sa for ; Fri, 19 Jun 2020 10:21:00 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8473A095C for ; Fri, 19 Jun 2020 10:20:59 -0700 (PDT)
X-ASG-Debug-ID: 1592587258-11fa313a101ce060001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Mqq0I37r44XyC4Y4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 19 Jun 2020 13:20:58 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=JtiyAxJvmf/XJK0iXKH92jtFXDEiLcRpF2PVPmGHVs8=; b=j7HdR8W8x+v7aMesq0RqUwRAjxw+pVEahMevfWo88wPyKUmD4jUJqEMulZa0E2SGR ifE9OxuXAKG6wau5fbAsakUBaE1FoibHD7vhcswIBmstAVUk8t8N+sQddWOMdMBZM Pdv7HoByn/Ui+5DwjWW3NxFmFitslvWObqea4+oLg=
Received: by webmail.bayviewphysicians.com via HTTP; Fri, 19 Jun 2020 13:20:50 -0400
To: dmarc@ietf.org
Cc: Karen Foster 
Date: Fri, 19 Jun 2020 13:20:47 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/multipart; boundary=7899a12191c0460d9bd412dfae5a885e
X-Android-Message-ID: 
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
From: "Douglas E. Foster" 
X-Exim-Id: e9f1b4e0-1a57-4e03-83e5-dd91d6d6753d
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592587258
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 3812
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82664 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 17:21:02 -0000

This is a multipart message in MIME format.

--7899a12191c0460d9bd412dfae5a885e
Content-Type: multipart/alternative; boundary=c8315a9f55ef46c0be66d445aac44d68

--c8315a9f55ef46c0be66d445aac44d68
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Pete;you have not explained how my inbox filter recignizes a legitimate 
forward of a legitimate message instead of an illegitimate forward or a 
fraudulently manufactured Received-header sequence.

We only have this problem 
with lists that alter the original to destroy DKIM validity.   When this is 
done, the list becomes the author snd the headers should reflect as much.

The referenced spam analysis article notes that infequently seen message 
sources are high probability spam.   If the list postings are from many 
individuals instead of one IETF address, the likelihood of blocked posts is 
significant.  Thus should ne a concern whether DJIM is preserved or not.

On Jun 19, 2020 12:46 PM, Pete Resnick  wrote:On 19 
Jun 2020, at 11:40, Pete Resnick wrote:

> The presumption of all Mediator-type transactions was that the 
> receiving email client was to deal with the message (the thing with 
> the identical Message-ID) with its original semantics, adding only 
> Resent-*: or List-*: fields to add the semantic of the mediation 
> event.

That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:

"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--c8315a9f55ef46c0be66d445aac44d68
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


    Pete;
    you have not explained how my inbo=
x filter recignizes a legitimate forward of a legitimate message instead of=
 an illegitimate forward or a fraudulently manufactured Received-header seq=
uence.

    We only have this=
 problem 
    with lists that alter the original to=
 destroy DKIM validity.   When this is done, the list becomes the=
 author snd the headers should reflect as much.

    =

    The referenced spam analysis article notes that inf=
equently seen message sources are high probability spam.   If the=
 list postings are from many individuals instead of one IETF address, the l=
ikelihood of blocked posts is significant.  Thus should ne a concern w=
hether DJIM is preserved or not.

    =

    On Jun 19, 2020 12:46 PM, Pete Resnick <resni=
ck@episteme.net> wrote:
    On 19 Jun 2020, at 11:=
40, Pete Resnick wrote:

    > The presumption of all Mediator-type tra=
nsactions was that the 
    > receiving email client was to deal with the =
message (the thing with 
    > the identical Message-ID) with its original=
 semantics, adding only 
    > Resent-*: or List-*: fields to add the sema=
ntic of the mediation 
    > event.

    That sentence got munged due to=
 cuts and pastes that didn't all add up. 
    It should read:

    "The pr=
esumption of all Mediator-type transactions was that the 
    receiving emai=
l client was to deal with the message (the thing with the 
    identical Mes=
sage-ID) with its original semantics, with the sender 
    adding only Resen=
t-*: or List-*: fields to add the semantic of the 
    mediation event."
    =


    -- 
    Pete Resnick https://www.episteme.net/
    All connections to=
 the world are tenuous at best

    _____________________________________=
__________
    dmarc mailing list
    dmarc@ietf.org
    https://www.ietf.org/=
mailman/listinfo/dmarc

    

--c8315a9f55ef46c0be66d445aac44d68--

--7899a12191c0460d9bd412dfae5a885e--


From nobody Fri Jun 19 10:23:20 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1A53A0996 for ; Fri, 19 Jun 2020 10:23:18 -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, FREEMAIL_FROM=0.001, 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=gmail.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 ubEruDZK3hwV for ; Fri, 19 Jun 2020 10:23:17 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 3F15F3A095C for ; Fri, 19 Jun 2020 10:23:17 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id g18so1364892wrm.2 for ; Fri, 19 Jun 2020 10:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dkl0BEQpLLj7GnzZrAKuXMz2BppIBZ2dp0VQ33Ao2Jw=; b=F2xEw++HhZjrc0mxWtRKFM5zLdC8O6NsKm4uaSnKCOSWYqQ9Qc+V0ZQP0xF8s7mwc5 XVvixRhRXrZKOY2aMSYfiUA+v2LDkw+qdbkAlGDrQmDcZ3UnX4VkbMT7OdPkURLIWRRF SOxk0aOYo3q33fnSX1sHRBtrLbZbW/SOIzvOVNpS2zhxWK0NlInaiesqv7xqwrRYZ+BR JDbLpjMvo3HO/2doc7QYPVDtHR6gEhRcl6fmDx7e9eEaihbrGy5SceF1bFhNTgjxduCr ckH9HVf5gMeAiMtUOwdBAChv0U1Y/oKEBblwQnU0PhhSpfjA+A+s3GjenDYltxFFVQaK r3Ng==
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=Dkl0BEQpLLj7GnzZrAKuXMz2BppIBZ2dp0VQ33Ao2Jw=; b=X5tNWlhb4c4AypJeVMiswVnJarca+2aCqXehlzbVl1HlDU6pWRCEeRba8J2GCsO8wX +JdRPQH3zinVd7U4h8UwShy08/K3+xfzDdkNK3EdHJEZGhZLTIiqt8F9B1vozhJ4zSF2 Sal+UE6prXH1WZmuAEOSFB8vhFYiWoe8WxxYz0JPRX1Qyh5pfXHPhmthQVMSZZH/1Ea4 sCifKPn+GRwuAMxdAqTcxD+M6lprjLfwpSYT8V6gr9FhhAFlFe3W8/bvV17RaJF874L0 rIUkvoWtQeGKVdiXXkxKbQWnNKwQadkAkI2KgpuRAVNzJ4rYrMy/b4YNX31NMb2WNeh9 DSDg==
X-Gm-Message-State: AOAM5316X2THpGbz1UnuhtTJ0s/H5CMA9STIuzTtPzeWtLxDe46vuynU AiqqEiuMmD6Ky11PfvQqgJicpw9FgeMavbqBQjg=
X-Google-Smtp-Source: ABdhPJyJR3BdT4qT5xT8PgV0be0e1AA6hb5TrHYeQwhL+hCVKpKZmM2scSfzPC0hzMOTKjZolUZmfMIgAM4sWfgj0Oo=
X-Received: by 2002:a5d:69ca:: with SMTP id s10mr5383211wrw.203.1592587395654;  Fri, 19 Jun 2020 10:23:15 -0700 (PDT)
MIME-Version: 1.0
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>
In-Reply-To: <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>
From: Dotzero 
Date: Fri, 19 Jun 2020 13:23:01 -0400
Message-ID: 
To: Jim Fenton 
Cc: "Douglas E. Foster" , IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000fdee7d05a8732561"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 17:23:19 -0000

--000000000000fdee7d05a8732561
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton  wrote:

> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> > DMARC helps establish a verified identity.  Delivery is based on
> > reputation.  The two are very different.
> >
> > Unwanted mail with DMARC validation will be blocked on the same basis
> > is unwanted mail without it.
> >
> > But a verified identity is helpful for ensuring that wanted mail is
> > not blocked.
>
> A verified identity is established by DKIM and/or SPF. What is DMARC
> adding in this respect?
>
> Policy expressed by the  domain owner/administrator based on some
combination of DKIM and/or SPF and the feedback loop.

Michael Hammer

--000000000000fdee7d05a8732561
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--000000000000fdee7d05a8732561--


From nobody Fri Jun 19 10:41:40 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0F3A0CD9 for ; Fri, 19 Jun 2020 10:41: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=valimail.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 SH3cem8AnIHQ for ; Fri, 19 Jun 2020 10:41:37 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 51AC03A0CC2 for ; Fri, 19 Jun 2020 10:41:37 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id c185so9710640qke.7 for ; Fri, 19 Jun 2020 10:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=t8HP5XKtAdx7XFN9QDXtL91Y0XqmhgHzGJWE1vXRVyk=; b=SNcHXv0TfGAK/vPY2XctCJevAmmxNRAd0Dz5m4YN2Sz4WrBIXJ1Az53MSuotVo5EbV K0lBUZvH/THp0d2PgAGrPyiQR5tJjxWoMPxuU6OPD2PrAH2L33u/fAjadfu/cS7pp5tx Izlnjy6qqtz1D3/+/K0+at3xHh+E8Ujg5kDEJB2MEj/Y3wbM9NlntJp2LcaL9IjLdWzL D2WpKasq5rtlEqtR7RQY4cvmxc8MjbWn44fM8O8p3KxkPzTTGWBbSFHt7xOqqXxnuTul f9A20ssPg9YJ22k70OhTTxI+y8/VD05Alr7yjwZGMHsiuHFLZ9ElF7AAcEtQJbnpUkoD ZS5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=t8HP5XKtAdx7XFN9QDXtL91Y0XqmhgHzGJWE1vXRVyk=; b=rBrDWAIcSwYtGLgMt90Ud0omFyytraV3rxEVyqz4vFZnSAn+dp7c1hGhIiVYjsaPsk ztcyoWkxavd0Cwwd6aAAao3Jr1nFOegBe28M/bE21BzKforNO2Wv6JD0Qnfh3NFngU1k mZ9B0e2im92FjzL7j9RTyEMhDflVCVe6YnaImWjQPri+ZNVHDRSeIYblc48vIKkvnIm3 jriEsvkGznAqBhxUwsKhLv1RExC+vRZaMOUGS2FD/EgNmgvlIA6ODFUW8pCSEjwamcjc GQY814JXhve9B9U31HdGG2JEdcPOTn224rbm5ktCcHTfGyZqDStK76UPc3wUVzGyxqRF yXEA==
X-Gm-Message-State: AOAM530fhCGxUoV0QXm5P5XvGTaHmzuMaR2yETuCFWS9oW1MSRPBQf50 WbER5eS3FTfkCoyH2n10jOq+P5D9FXnv1ma2nuUzdNcx
X-Google-Smtp-Source: ABdhPJzWbdyDh1s92+aMEuPnxyjG3H7gdCFFQAcCcH1BNruHUVA24QvfuyhPwignYX9K+eD4obFbHs73yQQs9X1BrNI=
X-Received: by 2002:a37:9cb:: with SMTP id 194mr4577165qkj.456.1592588496039;  Fri, 19 Jun 2020 10:41:36 -0700 (PDT)
MIME-Version: 1.0
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net> 
In-Reply-To: 
From: Todd Herr 
Date: Fri, 19 Jun 2020 13:41:24 -0400
Message-ID: 
To: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000094858b05a8736728"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 17:41:39 -0000

--00000000000094858b05a8736728
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 1:23 PM Dotzero  wrote:

>
>
> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton  wrote:
>
>> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
>> > DMARC helps establish a verified identity.  Delivery is based on
>> > reputation.  The two are very different.
>> >
>> > Unwanted mail with DMARC validation will be blocked on the same basis
>> > is unwanted mail without it.
>> >
>> > But a verified identity is helpful for ensuring that wanted mail is
>> > not blocked.
>>
>> A verified identity is established by DKIM and/or SPF. What is DMARC
>> adding in this respect?
>>
>> Policy expressed by the  domain owner/administrator based on some
> combination of DKIM and/or SPF and the feedback loop.
>
>
Not only that, but DMARC is the only one of the three that is necessarily
tied to the domain in the (usually) visible in the MUA From header.


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@valimail.com
*p:*


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

--00000000000094858b05a8736728
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Fri, Jun 19, 2020 at 1:=
09 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
    On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> DMARC helps establish a verified identity.=C2=A0 Delivery is based on<=
br>
> reputation.=C2=A0 The two are very different.=C2=A0
    
>
    
> Unwanted mail with DMARC validation will be blocked on the same basis<=
br>
> is unwanted mail without it.
    
>
    
> But a verified identity is helpful for ensuring that wanted mail is
> not blocked.
    

    
A verified identity is established by DKIM and/or SPF. What is DMARC
    
adding in this respect?

    Policy expressed by the=C2=
=A0 domain owner/administrator based on some combination of DKIM and/or SPF=
 and the feedback loop.

    <=
br>
    Not only that, but DMARC is the only one of the three that is=
 necessarily tied to the domain in the (usually) visible in the MUA From he=
ader.


    -- 
    Todd Herr | Sr. Technical Progra=
m Manager
    p:  
    <=
img src=3D"https://vm-img.s3-us-west-1.amazonaws.com/rsz_2vml-rainbow-logo_=
1.png" style=3D"border: none; height: 26px; width: 180px;">

    This email and all data transmitted with it contains confi=
dential and/or proprietary information intended solely for the use of indiv=
idual(s) authorized to receive it. If you are not an intended and authorize=
d recipient you are hereby notified of any use, disclosure, copying or dist=
ribution of the information included in this transmission is prohibited and=
 may be unlawful. Please immediately notify the sender by replying to this =
email and then delete it from your system.
    

--00000000000094858b05a8736728--


From nobody Fri Jun 19 10:44:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5B13A0D35 for ; Fri, 19 Jun 2020 10:44: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 (1024-bit key) header.d=wordtothewise.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 n5P2AhB8aooe for ; Fri, 19 Jun 2020 10:44:36 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9C60E3A0D2F for ; Fri, 19 Jun 2020 10:44:36 -0700 (PDT)
Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 2C6C09F149; Fri, 19 Jun 2020 10:44:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1592588675; bh=egWEg41W4zz+fRM19D8ZlTIL2asX1MgwHkvknPsO5tc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=GZt5GLtfNQ2clu6ZVbp/ZUd5PKFm94M60v5MdNv61ywRldyGc2hLGVBKlj0zr+Abp 4wxCYwUzx0Go0sr7H+A3THLKA54PSvBd/G5+uP+s0tAZdF1GnbDw2ku/yW85xJlgoH A4eNuvOr0W28k/ves6NKQ9OhoBodw4LDDQ+AMz5o=
From: Laura Atkins 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_980F8F3E-DBFF-4A90-A45E-6236700E57D2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 19 Jun 2020 18:44:33 +0100
In-Reply-To: <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>
Cc: "Douglas E. Foster" , dmarc@ietf.org
To: Jim Fenton 
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 17:44:40 -0000

--Apple-Mail=_980F8F3E-DBFF-4A90-A45E-6236700E57D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 19 Jun 2020, at 18:08, Jim Fenton  wrote:
>=20
> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
>> DMARC helps establish a verified identity.  Delivery is based on
>> reputation.  The two are very different.=20
>>=20
>> Unwanted mail with DMARC validation will be blocked on the same basis
>> is unwanted mail without it.
>>=20
>> But a verified identity is helpful for ensuring that wanted mail is
>> not blocked.
>=20
> A verified identity is established by DKIM and/or SPF. What is DMARC
> adding in this respect?

It=E2=80=99s pushing the verified identity out to bits of the email that =
the end user (sometimes) sees.=20

laura=20

--=20
Having an Email Crisis?  We can help! 800 823-9674=20

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741	=09

Email Delivery Blog: https://wordtothewise.com/blog=09








--Apple-Mail=_980F8F3E-DBFF-4A90-A45E-6236700E57D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



    On 19 Jun 2020, at 18:08, Jim Fenton <fenton@bluepopcorn.net> wrote:

    On =
6/19/20 6:06 AM, Douglas E. Foster wrote:
    DMARC helps establish a verified =
identity.  Delivery is based on
    reputation.  The =
two are very different. 

    Unwanted mail =
with DMARC validation will be blocked on the same basis
    is =
unwanted mail without it.

    But a verified =
identity is helpful for ensuring that wanted mail is
    not =
blocked.

    A verified identity =
is established by DKIM and/or SPF. What is DMARC
    adding in =
this respect?

    It=E2=80=99s pushing the verified identity out to =
bits of the email that the end user (sometimes) =
sees. 

    laura 

    

    -- 
    Having an Email Crisis? =
 We can help! 800 823-9674 

    Laura Atkins
    Word =
to the Wise
    laura@wordtothewise.com
    (650) =
437-0741		=


    Email Delivery Blog: https://wordtothewise.com/blog	=







    

    

    =

--Apple-Mail=_980F8F3E-DBFF-4A90-A45E-6236700E57D2--


From nobody Fri Jun 19 11:22:27 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB73A0D52; Fri, 19 Jun 2020 11:22:26 -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 (1024-bit key) header.d=bluepopcorn.net
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 91u6PdTtrPB0; Fri, 19 Jun 2020 11:22:24 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 63F183A0CCE; Fri, 19 Jun 2020 11:22:21 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:390e:9259:ed9c:abe]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05JIMJf4006414 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 19 Jun 2020 11:22:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592590940; bh=QAISRtg0YO6Pkm/zaOMz4XJNlMD//3iot+F+cv9UaCo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aiBrjm/Y3cyKK1xJjiN/Cz+FqSBdrj7obC4UsNgFUuf5giJy0uDmiJQct8mC+iiUG ZlRMDXENTNzh7z+H+QfuKD78Oucm6tPw7hP/pFZZOIVpOOj/414qVbHaPANia7hG8r NWUzfQUfccuzYMNNQSg+3tU6TNd6cWuruFyl62Mk=
To: Todd Herr , IETF DMARC WG 
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>  
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: 
Date: Fri, 19 Jun 2020 11:22:13 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CF7B2D58C5C9B8F356960743"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 18:22:27 -0000

This is a multi-part message in MIME format.
--------------CF7B2D58C5C9B8F356960743
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/19/20 10:41 AM, Todd Herr wrote:
> On Fri, Jun 19, 2020 at 1:23 PM Dotzero  > wrote:
>
>
>
>     On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton      > wrote:
>
>         On 6/19/20 6:06 AM, Douglas E. Foster wrote:
>         > DMARC helps establish a verified identity.=C2=A0 Delivery is =
based on
>         > reputation.=C2=A0 The two are very different.=C2=A0
>         >
>         > Unwanted mail with DMARC validation will be blocked on the
>         same basis
>         > is unwanted mail without it.
>         >
>         > But a verified identity is helpful for ensuring that wanted
>         mail is
>         > not blocked.
>
>         A verified identity is established by DKIM and/or SPF. What is
>         DMARC
>         adding in this respect?
>
>     Policy expressed by the=C2=A0 domain owner/administrator based on s=
ome
>     combination of DKIM and/or SPF and the feedback loop.
>
Both policy and the feedback loop are actions taken on the basis of
verification of the identity (or lack thereof). They do not establish
the identity themselves.
>
> Not only that, but DMARC is the only one of the three that is
> necessarily tied to the domain in the (usually) visible in the MUA
> From header.
>
That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.

-Jim



--------------CF7B2D58C5C9B8F356960743
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/19/20 10:41 AM, Todd Herr wrote:
    
    
    
    
    
      
      
    
        
    On Fri, Jun 19, 2020 at 1:23 PM Dotzero <dotzero@gmail.com>
          wrote:
    
        
    
        
    
          
    
            
    
              

    
              
    
              
    
              
    
                
    On Fri, Jun 19, 2020
                  at 1:09 PM Jim Fenton <fenton@bluepopcorn.net>
                  wrote:
    
                
    
                
    On 6/19/20 6:06 AM, Douglas E.
                  Foster wrote:
    
                  > DMARC helps establish a verified identity. 
                  Delivery is based on
    
                  > reputation.  The two are very different. 
    
                  >
    
                  > Unwanted mail with DMARC validation will be
                  blocked on the same basis
    
                  > is unwanted mail without it.
    
                  >
    
                  > But a verified identity is helpful for ensuring
                  that wanted mail is
    
                  > not blocked.
    
                  
    
                  A verified identity is established by DKIM and/or SPF.
                  What is DMARC
    
                  adding in this respect?
    
                  
    
                
    
                
    Policy expressed by the  domain owner/administrator
                  based on some combination of DKIM and/or SPF and the
                  feedback loop.
    
                

    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    Both policy and the feedback loop are actions taken on the basis of
    verification of the identity (or lack thereof). They do not
    establish the identity themselves.
    
    
    
      
    
        
    
          

    
          
    
          
    Not only that, but DMARC is the only one of the three
            that is necessarily tied to the domain in the (usually)
            visible in the MUA From header.
    
        
    
        

    
        
    
      
    
    
    
    
    That comes back to the question of whether the domain in the From
      header is visible in the MUA, and if visible, does it alter user
      behavior (e.g., discourage users from clicking phish links).
      Different people have different opinions on that. A couple of
      messages back on this thread, the blocking of email was discussed
      and that does not relate to visibility of the domain in the MUA.
    
    
    -Jim
    
    
    
  


--------------CF7B2D58C5C9B8F356960743--


From nobody Fri Jun 19 11:38:08 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0181B3A0AA2 for ; Fri, 19 Jun 2020 11:38:07 -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, FREEMAIL_FROM=0.001, 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=gmail.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 K-fBCWwNOqZ7 for ; Fri, 19 Jun 2020 11:38:05 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 7F7C13A0CDD for ; Fri, 19 Jun 2020 11:38:05 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id q8so9852055qkm.12 for ; Fri, 19 Jun 2020 11:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=S9j7tVNgDmVIjbAkndRe2qyhSpzFxp4BCLbra+Usojo=; b=VtkInW41V5LOSP4YcYgc+++i+1I6c5a5baPjpjAJsM7PseFATXZwITQaipK6N9z6dA sk+BP5FwjqHU6S1zCFxw0FOQK71V8JSQHTLyMI69+/DvKzg6H64TtLdjc+WZZ7kDhlb5 noWBMTpaPQ/rxvnEoFDMxUu4GDb4DdV1H8fAxfN2l+vXLEzmDMDgn0d6vvFAckMFSgSE oz+7Dr2nbYEjfkvGS7gOYGC3a9uWh+eSZw2f/Sc2eVsr+h6GRqK2HdyNieo92pfyq2lx UT+jEvV4aQY3h2GwvypxWVhAoxb/Rjrf6LYJ7aQ7TqpUelKazn+eVA/BCNUwzutZhERg IVbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=S9j7tVNgDmVIjbAkndRe2qyhSpzFxp4BCLbra+Usojo=; b=gU+fI+YFqnzaicPt0+gcu34BtEO9S4bxrDQflNTpkvsK8FZdAajjRTlkFEYdu6EdeA UneQtVIpwQ/5t7Jte4gpE60tntosmfrSWYCtOj2PENPYXfUs60eejQppY6jG/2REY8h6 TuLG3rOWGd8aXCq2FU4WV/NBONKMRlQnS/rhLIh/XqCJvkDShR3YlPxfshjD7ITsC+Ks 2XpzsiEU+sDVi06+DbFuZph2vyMhgQfLxRj/3a8qJqmJcTEcFl/LqxdS3+sza9KU82qm E9ZFu/S4EPV2GwmBw07fcltJhWBNaATU1uoU8ebBZX9zZKbKDHXF5+ChiaqrQdhdPLO1 cNTA==
X-Gm-Message-State: AOAM532sHW3/hRSZ7doLZIjt91H98BMeWK+tSmh2kT7HNu/Yxnk75TmW HhEm+TEQPr/A++CO8ILGpjUrKC5V
X-Google-Smtp-Source: ABdhPJzhWCSTS7lG6swGJJtMv9ILRp5Z/GPjdikPk2GYrnE2zlJ+ko9Qdjvr9IEU1/1LW1m9ooLc0A==
X-Received: by 2002:a37:4753:: with SMTP id u80mr4832784qka.178.1592591884317;  Fri, 19 Jun 2020 11:38:04 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id y16sm7679946qty.1.2020.06.19.11.38.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 11:38:03 -0700 (PDT)
To: Pete Resnick 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net>
From: Dave Crocker 
Message-ID: <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>
Date: Fri, 19 Jun 2020 11:38:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net>
Content-Type: multipart/alternative; boundary="------------45AEB93FD8C65F7AD203B2CB"
Content-Language: en-US
Archived-At: 
Subject: [dmarc-ietf] Mediation (was: Re:  Header munging, not ARC, can solve the mailing list problem)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 18:38:07 -0000

This is a multi-part message in MIME format.
--------------45AEB93FD8C65F7AD203B2CB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/19/2020 9:40 AM, Pete Resnick wrote:
> On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:
>
>> consider a mailing list as a publishing organization, which is what it
>> is.
>
> No, it isn't. It is a Mediator. See RFC 5598.


The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:

>
>       5.3 . Mailing Lists
>
>     ...
>     In addition to sending the new message to a potentially large number
>     of new Recipients, the Mailing List can modify content, for example,
>     by deleting attachments, converting the format, and adding list-
>     specific comments.

Note that in terms of email transport, it is posting a new message.

Mediators really have complete freedom to do whatever they want. If 
describing the full range of what a publisher might do, it would cover 
the same range.

But typical mediators are trying to maintain a sense and ability for the 
original author and the final recipient to experience an end-to-end 
message exchange.  The degree to which the mediator asserts itself more 
visibly to the recipient is probably the degree to which it looks more 
like a publisher and less like a simple relaying service.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------45AEB93FD8C65F7AD203B2CB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/19/2020 9:40 AM, Pete Resnick
      wrote:
    
    
    
    
    On 19
      Jun 2020, at 10:38, Alessandro Vesely wrote:
      
    
      
    
      
    consider a mailing list as a publishing
        organization, which is what it
        
    
        is.
        
    
      
    
      
    
      No, it isn't. It is a Mediator. See RFC 5598.
      
    
    
    
    

    
    
    
    
    The description of what a Mediator might do is not incompatible
      with also viewing it as having characteristics of a publisher:
    
    
    
      
    
        
    5.3.  Mailing Lists
       ...
   In addition to sending the new message to a potentially large number
   of new Recipients, the Mailing List can modify content, for example,
   by deleting attachments, converting the format, and adding list-
   specific comments.  
    
      
    
      
    
    
    
    
    Note that in terms of email transport, it is posting a new
      message.
    
    
    Mediators really have complete freedom to do whatever they want. 
      If describing the full range of what a publisher might do, it
      would cover the same range.  
    
    
    
    
    But typical mediators are trying to maintain a sense and ability
      for the original author and the final recipient to experience an
      end-to-end message exchange.  The degree to which the mediator
      asserts itself more visibly to the recipient is probably the
      degree to which it looks more like a publisher and less like a
      simple relaying service.
    
    
    
    
    d/
    
    
    
    
    -- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  


--------------45AEB93FD8C65F7AD203B2CB--


From nobody Fri Jun 19 11:40:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5593A0DA0 for ; Fri, 19 Jun 2020 11:40:15 -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, FREEMAIL_FROM=0.001, 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=gmail.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 xmXwa0v_degD for ; Fri, 19 Jun 2020 11:40:14 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 722CB3A0D98 for ; Fri, 19 Jun 2020 11:40:13 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id q198so2073626qka.2 for ; Fri, 19 Jun 2020 11:40:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=u77Ydz7hSP9dF9Ix9gllNex7TL2LkZWGEQM6Y6zfLIY=; b=TELuR9bCbYUwAl7sp8hyDL8Bikyl0T9D4AMAFfTg9EIY1X11l2hPo1whcgP0ST83oy i/rhb/2ZWKYpqSFTnGufD+yGr90ozt8c6SVD4jpm8p4+49unimOMf4ZG7UpmzsqixiEo Y6c+uQaS1uEwU+PWWVZmDeIgHTAObNflt3/yji7Czgm739/UNA5ZFTb5B7GkVY6jkD+V 1hYkd35jprIG6l4AyYiFs/GiQGMz0ypYa8z96sSk4aXbTbFMYGiM/UScYmuViWLDnv52 w0V+OxzJouHZL5nKpi7gdcpZHSWyIHqB4mWx8KgQehjDWS1cju/s7scVpV5CxpMVLr8z K8DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=u77Ydz7hSP9dF9Ix9gllNex7TL2LkZWGEQM6Y6zfLIY=; b=Oq59w+yn9KParHACxTByHi4nsgbfsHi6Axgw3UFX7FxOr7VR+UPDWULYMRNXR3yiuv E8h234bgmhpZKs7QwJwZe2NtZlGMOUo+UpZPD/ld60DcPjmQmiLDQso5rgStxFOliR8O egK40GSSK5hVEXMLzheS9vjHZfU7clf423A38KzQCCGF/7UHLFEKNoXEDoJj21GZD31c AwJ9/3+afpdf72WHgD/GTFG7JiVt4F4niU3Vr/B0GeKnMRRQlp3DknF75c2LuNxOrE1B QZioY4Bm/vL2MjicpC6XtuEozhZr/bJqH8mpli/7geojvJQ6clgC1ZUvyFGbWSkCoRJ6 tm7w==
X-Gm-Message-State: AOAM531+juo4U8KD7FMw7MK0GguXWJRIRCSZfwtSdPiS8kRdo7ZJ9AOE zgw6qtk3pal9bNN+9h/gjbpPzwab
X-Google-Smtp-Source: ABdhPJwWadWDBveBedT3+sF1vMTAFItJRtSzEUylQxor5VIZPQwRD0FF35BHO0d7a044f94BjJtzSg==
X-Received: by 2002:ae9:c30b:: with SMTP id n11mr5149496qkg.9.1592592009784; Fri, 19 Jun 2020 11:40:09 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id u205sm6906995qka.81.2020.06.19.11.40.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 11:40:09 -0700 (PDT)
To: Todd Herr , IETF DMARC WG 
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>  
From: Dave Crocker 
Message-ID: 
Date: Fri, 19 Jun 2020 11:40:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 18:40:19 -0000

On 6/19/2020 10:41 AM, Todd Herr wrote:
> Not only that, but DMARC is the only one of the three that is 
> necessarily tied to the domain in the (usually) visible in the MUA 
> From header.

Todd,

There is no evidence that end-users are relevant to 
manipulated/fraudulent From: fields or that DMARC's "certifying" the 
domain name of the From: field is relevant to reducing end-user 
vulnerability.

There is quite a bit of evidence that improving trust signals to end 
users has no significant effect.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 19 11:43:08 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8CA3A0D4F for ; Fri, 19 Jun 2020 11:43:07 -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, FREEMAIL_FROM=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=gmail.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 A8R3BJkS9cVb for ; Fri, 19 Jun 2020 11:43:06 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 0F3433A0D31 for ; Fri, 19 Jun 2020 11:43:06 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id k22so7941220qtm.6 for ; Fri, 19 Jun 2020 11:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=px2YwO32RgD+zgyqdK8db/5zI7p5E3YYx7wlyyHUYxU=; b=MwEDfPPxeEBtSp9dJOjlQ84qytC8qBWRZ+o9FoC12YmZcYbfl0HIr9mXi0/yVZCo+M DarcEpBpXrog9nrknrvy0KvxPZzCCm+1xWknBiXBRzShPslIGcb8MlWW+iopeG3R5SGR SIILW8uhfBRIOpHUxFPuqQLalRR6ccPBUIIKAl34mSQTVEHFh9xBywI9lQQrFGzhbG3b d7F/db+cHPksg8iNsM53dzt0zBfXgpRERbJKqKbK+bJQZanYmNfSwK1wJAZfP8oEujx5 T2Teo4Ms7NWPUNzxe9XWs64P8AjLITITGQ1Tw5GnbjV+4RyzSeABwEsSQjpQd76+hxPQ t0Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=px2YwO32RgD+zgyqdK8db/5zI7p5E3YYx7wlyyHUYxU=; b=efLZhP2Fx4IXsGnM9Gi8m4cuG/tmPUeGyzmgMQJfUVORDpOZoL7hHMOyjv0kiK9dN+ hgeGbGsjmYdI7xkkqUzcpUnxaNAJoEqIw8G1TqQPpfGN9/z0AQ+DVmhnRRZt+CCGzYum BVPY7cDeckkwOHokQP+NdcJkq26Zy3kRXhzYat+NcgtSWf3c3AECdtWw987uvjvtbivQ xgPf3SOduNuvflkj96cyKtejyTOSrIXgZfgsCl1nibrcgzxdojASx9PCWWB+gBcLZeaG xIVeoGMfXDhHnKrm0rRoQZEnnY8B/RNfOSoiR3pwKISMugbgfQp1DXzIggAST+S/O4ef YBew==
X-Gm-Message-State: AOAM532/Ihp6dcGGpz2HqOORK7ZmoR+zB1yGD/335a5vW5Gq7UI7nOyp Dy5FHYSS8CdFfudfOFoQubQwGWqK
X-Google-Smtp-Source: ABdhPJz+RKwNkRO4Gh+LBZMCPXYgb0H6iDxBwpLeB0gBVvJf7LXNTo65PO8l+rXbaU5LTfTIJIqVcA==
X-Received: by 2002:ac8:a45:: with SMTP id f5mr5061660qti.116.1592592184752; Fri, 19 Jun 2020 11:43:04 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id u5sm6942119qke.32.2020.06.19.11.43.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 11:43:04 -0700 (PDT)
To: Jim Fenton 
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>   
Cc: IETF DMARC WG 
From: Dave Crocker 
Message-ID: <219c8512-6b3c-50ff-1052-3e759d621486@gmail.com>
Date: Fri, 19 Jun 2020 11:43:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 18:43:07 -0000

On 6/19/2020 11:22 AM, Jim Fenton wrote:
> That comes back to the question of whether the domain in the From 
> header is visible in the MUA, and if visible, does it alter user 
> behavior (e.g., discourage users from clicking phish links). Different 
> people have different opinions on that. 


A small point that keeps being ignored is that there is quite a bit of 
objective information showing that it does NOT have an effect.  As far 
as I'm aware, there is no objective data that it DOES have an effect.

So, no, this is not just a matter of differing 'opinions'.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 19 12:02:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586363A0DCB for ; Fri, 19 Jun 2020 12:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bfUkA48qXEJ2 for ; Fri, 19 Jun 2020 12:02:13 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5BB3A0DAE for ; Fri, 19 Jun 2020 12:02:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 8085CB14D2D7; Fri, 19 Jun 2020 14:02:09 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_nBCzD4duEg; Fri, 19 Jun 2020 14:02:08 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 33CF1B14D2CE; Fri, 19 Jun 2020 14:02:08 -0500 (CDT)
From: "Pete Resnick" 
To: "Dave Crocker" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 14:02:07 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation (was: Re:  Header munging, not ARC, can solve the mailing list problem)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 19:02:26 -0000

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

> The description of what a Mediator might do is not incompatible with 
> also viewing it as having characteristics of a publisher:
>>
>> ### [5.3](). Mailing 
>> Lists
>>
>>
>>        ...
>>        In addition to sending the new message to a potentially large 
>> number
>>        of new Recipients, the Mailing List can modify content, for 
>> example,
>>        by deleting attachments, converting the format, and adding 
>> list-
>>        specific comments.

Fair enough, but as you mention below, in the case of the common mailing 
list, the intent is simply to redistribute the message with minimal 
change (hence the retention of the Message-ID: and the From:). That 
said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.

> Note that in terms of email transport, it is posting a new message.

Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:

       Note: There are many instances when messages are "changed", but
       those changes do not constitute a new instantiation of that
       message, and therefore the message would not get a new message
       identifier.  For example, when messages are introduced into the
       transport system, they are often prepended with additional header
       fields such as trace fields (described in section 3.6.7) and
       resent fields (described in section 3.6.6).  The addition of such
       header fields does not change the identity of the message and
       therefore the original "Message-ID:" field is retained.  In all
       cases, it is the meaning that the sender of the message wishes to
       convey (i.e., whether this is the same message or a different
       message) that determines whether or not the "Message-ID:" field
       changes, not any particular syntactic difference that appears (or
       does not appear) in the message.

> Mediators really have complete freedom to do whatever they want.  If 
> describing the full range of what a publisher might do, it would cover 
> the same range.  

Well, "complete freedom" in the sense that no Internet police prevent 
such actions. But for most mediators, large substantive (for interesting 
definitions of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not being 
a mediator." Certainly that would happen in the case of an alias or a 
resender.

> But typical mediators are trying to maintain a sense and ability for 
> the original author and the final recipient to experience an 
> end-to-end message exchange.

Yep. That's the point I was trying to make.

> The degree to which the mediator asserts itself more visibly to the 
> recipient is probably the degree to which it looks more like a 
> publisher and less like a simple relaying service.

And eventually, I would contend, less like a mediator.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 13:05:17 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3D63A0E25 for ; Fri, 19 Jun 2020 13:05:15 -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=valimail.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 JS2zCVVDO84R for ; Fri, 19 Jun 2020 13:05:13 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 EE3863A0DFC for ; Fri, 19 Jun 2020 13:05:12 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id dp10so5043782qvb.10 for ; Fri, 19 Jun 2020 13:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=s81TG0p9A8kwiYKovPno6iKyWlE3Pv7vKjM72+GHIlw=; b=UR2VU3xG5GB8mD6pNE13Bd0318mMIRB1Q/piGQf++fg2Nmmuw9HsgVnaYWb7BitvDp D3qUSjTZP7+S90PLoGhzop69B5weHIp1JcJoWSpidzis3IWJoOLgY36JowB/BkzbZfk0 ShgOdzacPDDtybSe9bftrSAREcIC9o+/tL9ob0fJ41WFWLTywK8UKPdQlGlXv6104CJp rmk4XUKwByBPvnFOzThR9ZZpWT5seBa0OfdwRxsDreUBW5wR9cg29l0fD0iq1Vd2iS2V TmK7sEzjmxq7Z+7gV9tp6ipVlj4lsxtJ5uyaE8SNkmq5YipiGfxidiWDsxRytYGrUQnx R3Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=s81TG0p9A8kwiYKovPno6iKyWlE3Pv7vKjM72+GHIlw=; b=TYrZn60jbOuIoeTW9edeWvR1zlz9b/V0FxB3zUReIn3hj4jdMFa11rNICrcnEA9tMm Gx/1/+HM2RoEy0x6NK50jiAJhKKoi3KuR8ghm2bRZEnD5h3n8Kung4w5FhkOYqhZbZbq eLTZWpUJ7IZLFAhfxgnckzyMbfydJulHBDcHt05gvF+o63971MFZw1KEUMxxGo3Fyoda tcwqVgCeZCk3DtJydZHa7/QzGBgkfo6QfoH+VWdxQPRsDic0USvS17y3MoRt40RyMsH4 HdjPnhoPJn0QYQqTqiY3fFQW8ZeErnPspKJ3MIsG6+ZasPoewnrYrxq0Y6t2vUhFzA1s rLgQ==
X-Gm-Message-State: AOAM533apDzE5/k8RB+Wdj/lJrMJ+P0mtWxquq8KcWSvCOVx7cmFFUGF eygMakNL5gfz5Cjd9yoBNSTPnIE5QVAecsxBJIlQ6VcNrrc=
X-Google-Smtp-Source: ABdhPJzi2oaNboc0gHlx9F4WrnMdByTApAX3sY/xgR6vJs+i/i9Mn+BJJbVupSEAiO3XwXn3IGpKosiT1dbu5DnCMp8=
X-Received: by 2002:a0c:fd41:: with SMTP id j1mr10681767qvs.107.1592597111538;  Fri, 19 Jun 2020 13:05:11 -0700 (PDT)
MIME-Version: 1.0
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>   
In-Reply-To: 
From: Todd Herr 
Date: Fri, 19 Jun 2020 16:05:00 -0400
Message-ID: 
To: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000001a987e05a87569b0"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 20:05:15 -0000

--0000000000001a987e05a87569b0
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 2:22 PM Jim Fenton  wrote:

> On 6/19/20 10:41 AM, Todd Herr wrote:
>
> On Fri, Jun 19, 2020 at 1:23 PM Dotzero  wrote:
>
>>
>>
>> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton 
>> wrote:
>>
>>>
>>> A verified identity is established by DKIM and/or SPF. What is DMARC
>>> adding in this respect?
>>>
>>> Policy expressed by the  domain owner/administrator based on some
>> combination of DKIM and/or SPF and the feedback loop.
>>
>> Both policy and the feedback loop are actions taken on the basis of
> verification of the identity (or lack thereof). They do not establish the
> identity themselves.
>
>
> Not only that, but DMARC is the only one of the three that is necessarily
> tied to the domain in the (usually) visible in the MUA From header.
>
> That comes back to the question of whether the domain in the From header
> is visible in the MUA, and if visible, does it alter user behavior (e.g.,
> discourage users from clicking phish links). Different people have
> different opinions on that. A couple of messages back on this thread, the
> blocking of email was discussed and that does not relate to visibility of
> the domain in the MUA.
>
>
>
Dave Crocker wrote:

> There is no evidence that end-users are relevant to
> manipulated/fraudulent From: fields or that DMARC's "certifying" the
> domain name of the From: field is relevant to reducing end-user
> vulnerability.
> There is quite a bit of evidence that improving trust signals to end
> users has no significant effect.


Nowhere have I made any claim regarding the alteration of user behavior; I
am speaking solely to the idea of DMARC being used to verify an identity,
specifically the domain in the From header. It's my assumption that this
verification is likely to be done by someone other than the user,
specifically their mailbox provider, whom I further assume will make
acceptance and folder placement decisions for a message based on a
combination of factors, including, but definitely not limited to, the
results of all applicable authentication checks. We don't ask users to
perform SPF or DKIM validation checks, so I don't believe that my
assumptions are inconsistent here.

While it's true to say a verified identity is established by DKIM and/or
SPF, which identity is established by these protocols? I've got mail in my
inbox right now that has:

   - in.constantcontact.com as the Return-Path domain; SPF verdict was
   pass, so in.constantcontact.com was verified as being authorized to send
   from the host that originated the message; if we want to call this the
   verification of an identity, so be it.
   - auth.ccsend.com as the DKIM signing domain; DKIM verdict was pass, so
   auth.ccsend.com was verified as the signer, but definitely not the
   purported author, per RFC 6376, section 1.2
   - $MYGOLFCLUB.com as the From domain; no DMARC policy published, so the
   identity was not verified, but I can tell from the content of the message
   that it's legitimate

Now, this mail was wanted mail, so I'm thankful in this case that the
domain doesn't publish a DMARC policy, or else I might not have gotten the
message. Maybe if they did, Constant Contact would enforce a policy of DKIM
signing with $MYGOLFCLUB.com; I don't know how things work at CC. However,
such a tuple of three unaligned domains isn't unheard of, and it is to me a
textbook case of the need for some mechanism for receiving domains to use
to verify the identity associated with the From header. Without such a
mechanism, then there is nothing, save the Acceptable Usage Policy enforced
by my connectivity provider, to prevent me from sending an unlimited amount
of mail using $MYGOLFCLUB.com in the From domain, along with those
disposable domains mentioned upthread for SPF and DKIM. (Whether or not
such messages reach their destination is an open question, based on the
filtering policies in place at the target domains.)

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@valimail.com
*p:*


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

--0000000000001a987e05a87569b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Fri, Jun 19, 2020 at 2:22 PM Jim Fento=
n <fenton@bluepopcorn.net&=
gt; wrote:
    
 =20
   =20
 =20
  
    
    
    On 6/19/20 10:41 AM, Todd Herr wrote:
    
    
    
    
    
     =20
      
    
        
    On Fri, Jun 19, 2020 at 1:23 PM Dotzero <dotzero@gmail.com>
          wrote:
    
        
    
        
    
          
    
            
    
              

    
              
    
              
    
              
    
                
    On Fri, Jun 19, 2020
                  at 1:09 PM Jim Fenton <fenton@bluepopcorn.net>
                  wrote:
    
                  
    
                  A verified identity is established by DKIM and/or SPF.
                  What is DMARC
    
                  adding in this respect?
    
                  
    
                
    
                
    Policy expressed by the=C2=A0 domain owner/administrat=
or
                  based on some combination of DKIM and/or SPF and the
                  feedback loop.
    
                

    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    Both policy and the feedback loop are actions taken on the basis of
    verification of the identity (or lack thereof). They do not
    establish the identity themselves.
    
    
    
      
    
        
    
          

    
          
    
          
    Not only that, but DMARC is the only one of the three
            that is necessarily tied to the domain in the (usually)
            visible in the MUA From header.
    
        
    
        

    
        
    
      
    
    
    
    
    That comes back to the question of whether the domain in the From
      header is visible in the MUA, and if visible, does it alter user
      behavior (e.g., discourage users from clicking phish links).
      Different people have different opinions on that. A couple of
      messages back on this thread, the blocking of email was discussed
      and that does not relate to visibility of the domain in the MUA.
    
    


    Dave Crocker wrote:
    There is no evidence =
that end-users are relevant to
    manipulated/fraudulent From: fields or th=
at DMARC's "certifying" the
    domain name of the From: field=
 is relevant to reducing end-user
    vulnerability.
    There is quite a bit=
 of evidence that improving trust signals to end
    users has no significan=
t effect.=C2=A0
    =C2=A0
    Nowhere have I made any c=
laim regarding the alteration of user behavior; I am speaking solely to the=
 idea of DMARC being used to verify an identity, specifically the domain in=
 the From header. It's my assumption that this verification is likely t=
o be done by someone other than the user, specifically their mailbox provid=
er, whom I further assume will make acceptance and folder placement decisio=
ns for a message based on a combination of factors, including, but definite=
ly not limited to, the results of all applicable authentication checks. We =
don't ask users to perform SPF or DKIM validation checks, so I don'=
t believe that my assumptions are inconsistent here.

    While it's true to say a verified identity is established by DKIM an=
d/or SPF, which identity is established by these protocols? I've got ma=
il in my inbox right now that has:
    • in.constantcontact.com as the Return-Path domain; S=
PF verdict was pass, so in.consta=
ntcontact.com was verified as being authorized to send from the host th=
at originated the message; if we want to call this the verification of an i=
dentity, so be it.
    • auth.ccsend.c=
om as the DKIM signing domain; DKIM verdict was pass, so auth.ccsend.com was verified as the signer, but de=
finitely not the purported author, per RFC 6376, section 1.2
    • $MYGOL=
FCLUB.com as the From domain; no DMARC policy published, so the identity wa=
s not verified, but I can tell from the content of the message that it'=
s legitimate
    Now, this mail was wanted mail, so I'm thankful i=
n this case that the domain doesn't publish a DMARC policy, or else I m=
ight not have gotten the message. Maybe if they did, Constant Contact would=
 enforce a policy of DKIM signing with $MYGOLFCLUB.com; I don't know ho=
w things work at CC. However, such a tuple of three unaligned domains isn&#=
39;t unheard of, and it is to me a textbook case of the need for some mecha=
nism for receiving domains to use to verify the identity associated with th=
e From header. Without such a mechanism, then there is nothing, save the Ac=
ceptable Usage Policy enforced by my connectivity provider, to prevent me f=
rom sending an unlimited amount of mail using $MYGOLFCLUB.com in the From d=
omain, along with those disposable domains mentioned upthread for SPF and D=
KIM. (Whether or not such messages reach their destination is an open quest=
ion, based on the filtering policies in place at the target domains.)
    =


    -- 
    Todd Herr<=
/span> | Sr. Technical Program Manager
    p:  

    This em=
ail and all data transmitted with it contains confidential and/or proprieta=
ry information intended solely for the use of individual(s) authorized to r=
eceive it. If you are not an intended and authorized recipient you are here=
by notified of any use, disclosure, copying or distribution of the informat=
ion included in this transmission is prohibited and may be unlawful. Please=
 immediately notify the sender by replying to this email and then delete it=
 from your system.
    

--0000000000001a987e05a87569b0--


From nobody Fri Jun 19 13:08:29 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377513A0E3F for ; Fri, 19 Jun 2020 13:08:27 -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, FREEMAIL_FROM=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=gmail.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 Lx52FB00D4ZU for ; Fri, 19 Jun 2020 13:08:25 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 321FB3A0E3A for ; Fri, 19 Jun 2020 13:08:02 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id q14so8138984qtr.9 for ; Fri, 19 Jun 2020 13:08:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jn5wKtZEI8hz4CKkrJ/CosmgQtcWFIP+S9gbHf4Lu4g=; b=ncWs3oSqrrOEHbSaXlMRZ4ezUwxvfRSLRjEP3DE8LmoJocN6QdmZY1sgOjOEo3lceI Oy8JFknguEhRloAppngExDRT3iFgb0LdBpbj667nRFeZGh2UON9OkfIu9nJOF808Fy/W r6LU6lpJIQaqorFJujkfc2TSlH3RLzKDqUYDTFjSJsd9rZZYpl8A0Q1Z1xvoHeKLknD0 Ue1rzHEOtQ35nSPAbBmBIGpZ9fzC1eakjlO+5MoXp60djP7WKXfRWblgDuBIR1tm23Xx lqoSFM1yLOa0qlleMp5g+c1OPeIcMOonXlmGP7OnHkJ3FxThrJacfu14b1/tP21OSNnp Hdzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jn5wKtZEI8hz4CKkrJ/CosmgQtcWFIP+S9gbHf4Lu4g=; b=GoM+9wY7Y2TOTU4IdaJC3iz/MSLerjFSgGoJHu+WbAuFdrspwBnG6ksTMflHAngK7M GNBZiIzHDreZWi4bTKy2pFB482jbzQ7u9n6LiUji3fcA8TiHAlobJu5CYHIB+DI6oLGz u5/S/KdJqTkvY3Z+nFiLw8Gi5P0zNEtgdOd3Kx73luKzl8G6oUSsIfkwwIa5zZ4oxiP3 g2czfX7hg5+RRLXOB91Ga7KAv1hAX0xcZ4diZckQTc79VJGOMv7QJi9xbDvZlh/bWam1 VvVqxj0HKiEKHyC4MHTxoafYhKOnGOVXzBnR2fi+1itBBwsFftBn/oVoFHBMcyzUJs8V iFGA==
X-Gm-Message-State: AOAM530rcFVEL09yZMYs+iFNuE/RyCoJPaRIX7nks2NdRjPip7j75Aw2 d7gkU0Gdoneot9AUpS3cja9k4cEz
X-Google-Smtp-Source: ABdhPJze93r8ArZROEV08tTzRkwChr/mAzMx2lFtFzsRaMX7bOwPpFt0WIyVM91w7UBdCcm8tMTLjg==
X-Received: by 2002:ac8:2aed:: with SMTP id c42mr5065211qta.202.1592597280991;  Fri, 19 Jun 2020 13:08:00 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id r125sm4210008qkb.42.2020.06.19.13.08.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 13:08:00 -0700 (PDT)
To: Pete Resnick 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com> 
From: Dave Crocker 
Message-ID: <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>
Date: Fri, 19 Jun 2020 13:07:59 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 20:08:27 -0000

On 6/19/2020 12:02 PM, Pete Resnick wrote:
> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>
>> The description of what a Mediator might do is not incompatible with 
>> also viewing it as having characteristics of a publisher:
>>>
>>> ### [5.3](). 
>>> Mailing Lists
>>>        ...
>>>        In addition to sending the new message to a potentially large 
>>> number
>>>        of new Recipients, the Mailing List can modify content, for 
>>> example,
>>>        by deleting attachments, converting the format, and adding list-
>>>        specific comments.
>
> Fair enough, but as you mention below, in the case of the common 
> mailing list, the intent is simply to redistribute the message with 
> minimal change (hence the retention of the Message-ID: and the From:). 

While, yes, that's the goal of some and probably most lists, that isn't 
quite what I said.

Please re-read my text, which notably did not contain the word 'minimal' 
and frankly had a different focus. That focus doesn't exclude 
minimality, but it wasn't the point.


> That said, I do disagree with the reasoning given with regard to why 
> 5321.MailFrom has changed: It's not because of the authorship, but 
> rather because it is responsible for the submission onto the network, 
> just as the ReSender is in 5.2.

I did not anything about MailFrom, or for that matter anything about any 
field with an identifier.

I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets handling 
error messages?  That issue and behavior predates DMARC by a lot.  
Probably two decades. Maybe more.


>> Note that in terms of email transport, it is posting a new message.
>
> Strictly in terms of transport, yes. But in terms of the layer above 
> (the 5322 layer), it is usually the same message; see the second Note: 
> in RFC 5322 section 3.6.4:
>
>       Note: There are many instances when messages are "changed", but
>       those changes do not constitute a new instantiation of that
>       message, 

Except that there are many instances when messages might be changed that 
DO constitute a new instantiation of that message, and 5322 gives no 
guidance about what determine one versus the other.

None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the messages 
it is re-posting.  That most seek to preserve essentially all of the 
author's text is fine, but whether and how much is more of a 'business' 
decision than a technical one.


>> Mediators really have complete freedom to do whatever they want.  If 
>> describing the full range of what a publisher might do, it would 
>> cover the same range.
>
> Well, "complete freedom" in the sense that no Internet police prevent 
> such actions.

I didn't mean anything so nit-picky.  I mean that they are providing a 
value-added service to users and have their own agency to decide what 
that service looks like. If they want to do assorted message 
modifications that are substantial, and if users of the service like the 
nature of those modification, the service is free to do them.  There is 
no specifications that dictate or even suggest, what one of the services 
must, or even should, do. So your reference to Internet police is 
ironic, because there is nothing to guide enforcement.


> But for most mediators, large substantive (for interesting definitions 
> of "substantive") changes are outside of the scope of their 
> definitions, and would probably invite someone to say, "That's not 
> being a mediator." Certainly that would happen in the case of an alias 
> or a resender.

If there is a specification that would move such a declaration out of 
people's personal opinions and into objective, technical assessment, I 
apologize that I don't know what it is.


>> But typical mediators are trying to maintain a sense and ability for 
>> the original author and the final recipient to experience an 
>> end-to-end message exchange.
>
> Yep. That's the point I was trying to make.

Except you seem to be pressing this as essentially a requirement they 
have whereas I'm pressing it as a business decision, not something 
inherent in the nature of mailing list behavior.


>> The degree to which the mediator asserts itself more visibly to the 
>> recipient is probably the degree to which it looks more like a 
>> publisher and less like a simple relaying service.
>
> And eventually, I would contend, less like a mediator.

I probably wouldn't like it either, but we don't have objective criteria 
for accurately and reliably applying or withholding the term, do we?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 19 13:13:51 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F43A0E57 for ; Fri, 19 Jun 2020 13:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level: 
X-Spam-Status: No, score=0.278 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 v9-Nxh0ou8WW for ; Fri, 19 Jun 2020 13:13:49 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACEA3A0E55 for ; Fri, 19 Jun 2020 13:13:49 -0700 (PDT)
X-ASG-Debug-ID: 1592597628-11fa313a101d3af0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id B4zIE0FLg7PyxOxP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 19 Jun 2020 16:13:48 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:message-id:subject; bh=5FGG2r445YPd0IJXZi3+AxVJKxskVXQsWYswDJiCRXg=; b=W8AMinddEheYfvdCzYH4GhyguraOP/hXB64ste7xtnITJkgLQnRSot0dmJSh+Pjpb 8TLhQxM8EyNIo2V6a9iZ9BVGc19UoEd4N1br+s3X+OGCAkZkCKLWbMWWVJ92OVb0G 3tCT72B1A5OWUj49TMGhUszHAl7r0vVdlx9nh5234=
Date: Fri, 19 Jun 2020 16:05:48 -0400
Message-ID: <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com>
X-ASG-Orig-Subj: Re: [dmarc-ietf] Mediation (was: Re:  Header munging, not ARC, can solve the mailing list problem)
X-Android-Message-ID: <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com>
To: Pete Resnick 
Cc: Dave Crocker , dmarc@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
From: "Douglas E. Foster" 
X-Exim-Id: 4b20eff9-0979-4695-a984-133e330e97f6
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592597628
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 458
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.60
X-Barracuda-Spam-Status: No, SCORE=0.60 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=COMMA_SUBJECT, HTML_MESSAGE,  MIME_HTML_ONLY, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82667 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts 0.60 COMMA_SUBJECT          Subject is like 'Re: FDSDS, this is a subject' 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation (was: Re:  Header munging, not ARC, can solve the mailing list problem)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 20:13:50 -0000

PGRpdiBkaXI9J2F1dG8nPjxkaXY+V2h5IGlzIHRoZSBzdGF0ZSBvZiB0aGUgbWVzc2FnZS1pZCBp
bXBvcnRhbnQ/Jm5ic3A7ICZuYnNwO1lvdSBoYXZlIG1lbnRpb25lZCBpdCB0d2ljZS48L2Rpdj48
ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JdCBpcyBub3QgYSByZXF1
aXJlZCBoZWFkZXIuJm5ic3A7IEl0IG9mdGVuIHVzZXMgYSBkb21haW4gcG9ydGlvbiB0aGF0IGlz
IG5vdCBhIHJlZ2lzdGVyZWQgbmFtZS4mbmJzcDsgJm5ic3A7VGhlIHJlY2lwaWVudCBoYXMgbm8g
d2F5IHRvIGtub3cgd2hldGhlciBvciBub3QgaXQgaGFzIGJlZW4gY2hhbmdlZCBkdXJpbmcgZm9y
d2FyZGluZy4mbmJzcDsgSSBoYXZlIHRyaWVkIHRvIGltYWdpbmUgYSB3YXkgdG8gdXNlIG1lc3Nh
Z2UtaWQgaW4gbWVzc2FnZSBldmFsdWF0aW9uLCBidXQgaGF2ZSBnaXZlbiB1cC48L2Rpdj48L2Rp
dj4=


From nobody Fri Jun 19 14:11:35 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9EB3A0E93 for ; Fri, 19 Jun 2020 14:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2cVEbHNnwiXZ for ; Fri, 19 Jun 2020 14:11:31 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40413A0E92 for ; Fri, 19 Jun 2020 14:11:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 72D06B14FFFE; Fri, 19 Jun 2020 16:11:30 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6f8-CTTFS7C; Fri, 19 Jun 2020 16:11:28 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 95E65B14FFF5; Fri, 19 Jun 2020 16:11:28 -0500 (CDT)
From: "Pete Resnick" 
To: "Dave Crocker" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 16:11:27 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: <79EA93D8-7075-417F-8613-177BE16E3018@episteme.net>
In-Reply-To: <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 21:11:34 -0000

We seem to be having a discussion with some premises misunderstood, so 
let me attempt to answer your message upside down, in hopes of undoing 
that:

On 19 Jun 2020, at 15:07, Dave Crocker wrote:

> On 6/19/2020 12:02 PM, Pete Resnick wrote:
>> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>>
>>> But typical mediators are trying to maintain a sense and ability for 
>>> the original author and the final recipient to experience an 
>>> end-to-end message exchange.
>>
>> Yep. That's the point I was trying to make.
>
> Except you seem to be pressing this as essentially a requirement they 
> have

Ah, no, I think that's the crux of the misunderstanding: I was 
responding to Alessandro, who I interpreted to be saying that *all* 
mailing lists were, by definition, publishers, defining a publisher like 
a newspaper, where the true author of the content are the folks in the 
masthead, even though they acknowledge individual authors in the 
by-line. I disagree with that view. Indeed, I think for most of the 
mailing lists we have been referring to in this discussion, they are not 
publishers in Alessandro's sense, but rather view themselves as 
redistributors of author messages. As 5598 points out, there is variance 
in how much "editing" is done by any given mailing list, but again, for 
the discussion we've been having about how the From: field should be 
used, we've been talking about mailing lists which do the sort of 
minimal editing of messages.

(For mailing lists that do more substantial editing, I may not be as 
motivated to keep the From: field unchanged. If we get more deeply into 
the discussion, it might be useful to start drawing more distinct 
circles around types of mailing lists.)

So the purpose of pointing to 5598 was simply to explain to Alessandro 
that redistribution of messages through the transport system does not 
ipso facto make something a publisher.

> whereas I'm pressing it as a business decision

I'm not really sure what that means or how it is relevant to the 
discussion, but again, I think we've been talking past eachother for the 
last two messages.

> not something inherent in the nature of mailing list behavior.

No, sorry. I meant to simply point out the converse: That becoming a 
publisher is not in the nature of mailing list behavior.

>> That said, I do disagree with the reasoning given with regard to why 
>> 5321.MailFrom has changed: It's not because of the authorship, but 
>> rather because it is responsible for the submission onto the network, 
>> just as the ReSender is in 5.2.
>
> I did not anything about MailFrom, or for that matter anything about 
> any field with an identifier.

I didn't say you had. I brought it up only because I re-read the section 
in 5598 on mailing lists, and it makes this claim. Just objecting in 
passing (because it seems to support Alessandro's view), not because I 
thought you were making some claim about it.

> I'm guessing that your reference is to the fact that a mailing list 
> service might put its own address into the MailFrom, so it gets 
> handling error messages?  That issue and behavior predates DMARC by a 
> lot.  Probably two decades. Maybe more.

I agree. Which is why I thought it relevant to the overall discussion. 
It was not directed at a particular statement of yours.

>> But in terms of the layer above (the 5322 layer), it is usually the 
>> same message; see the second Note: in RFC 5322 section 3.6.4:
>>
>>       Note: There are many instances when messages are 
>> "changed", but
>>       those changes do not constitute a new instantiation of 
>> that
>>       message,
>
> Except that there are many instances when messages might be changed 
> that DO constitute a new instantiation of that message, and 5322 gives 
> no guidance about what determine one versus the other.

That's not true. In what you elided:

       In all
       cases, it is the meaning that the sender of the message wishes to
       convey (i.e., whether this is the same message or a different
       message) that determines whether or not the "Message-ID:" field
       changes, not any particular syntactic difference that appears (or
       does not appear) in the message.

It doesn't give any algorithmic guidance, if that's what you meant.

> None of which is relevant to the point that a mailing list service has 
> its own agency and is free to do what it wishes to and with the 
> messages it is re-posting.

Well, it seems exactly to that point. See above.

> That most seek to preserve essentially all of the author's text is 
> fine, but whether and how much is more of a 'business' decision than a 
> technical one.

We appear to be in violent agreement, as the quip goes. Importantly, I 
think we agree that if a mailing list decides to preserve the original 
 From: field, in an attempt to preserve all of the author's semantics, 
they are not "doing it wrong", as Alessandro's message appears to claim.

> I didn't mean anything so nit-picky.  I mean that they are providing 
> a value-added service to users and have their own agency to decide 
> what that service looks like.

Again, exactly supporting my point: If a mailing list desires to provide 
the service of redistributing mail with its original semantics, that's a 
fine thing for it to do, and not something that should be rejected as 
having been done wrong for the past 40+ years.

> If they want to do assorted message modifications that are 
> substantial, and if users of the service like the nature of those 
> modification, the service is free to do them.

Of course. And the protocols we produce should be able to support both 
scenarios, not dismiss one (rather widespread) way of doing things.

>> But for most mediators, large substantive (for interesting 
>> definitions of "substantive") changes are outside of the scope of 
>> their definitions, and would probably invite someone to say, "That's 
>> not being a mediator." Certainly that would happen in the case of an 
>> alias or a resender.
>
> If there is a specification that would move such a declaration out of 
> people's personal opinions and into objective, technical assessment, I 
> apologize that I don't know what it is.

I believe 5322 makes quite clear what a resender mediator is. For alias 
mediators, I'd have to go look if there is anything beyond 5598's 
description. We have historically been quite resistant about defining 
mailing list behaviors, for assorted reasons.

>>> The degree to which the mediator asserts itself more visibly to the 
>>> recipient is probably the degree to which it looks more like a 
>>> publisher and less like a simple relaying service.
>>
>> And eventually, I would contend, less like a mediator.
>
> I probably wouldn't like it either, but we don't have objective 
> criteria for accurately and reliably applying or withholding the term, 
> do we?

I'm not sure if "liking" it has any bearing on the discussion, and I'm 
pretty sure we don't have criteria that will take any arbitrary behavior 
and count it as in or out, but I think I can give you examples of action 
which you (and most of us) would agree would not fall into the criteria 
and others that would. Just because a definition is fuzzy doesn't make 
it useless.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 14:15:30 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462643A0E90 for ; Fri, 19 Jun 2020 14:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 o68bEsLrz92X for ; Fri, 19 Jun 2020 14:15:28 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F523A0D26 for ; Fri, 19 Jun 2020 14:15:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 5E252B1501FF; Fri, 19 Jun 2020 16:15:27 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwUsHdd1u_5l; Fri, 19 Jun 2020 16:15:26 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 8A128B1501F6; Fri, 19 Jun 2020 16:15:26 -0500 (CDT)
From: "Pete Resnick" 
To: "Dave Crocker" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 16:15:25 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 21:15:29 -0000

[Offlist]

On 19 Jun 2020, at 15:07, Dave Crocker wrote:

> Please re-read my text...

> If there is a specification ... I apologize that I don't know what it 
> is.

These little passive-aggressive turns of phrase are not useful habits to 
teach to others on the list.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 14:21:00 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892AE3A0E96 for ; Fri, 19 Jun 2020 14:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 39YCFCrz9q7Y for ; Fri, 19 Jun 2020 14:20:55 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FE93A0E95 for ; Fri, 19 Jun 2020 14:20:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 05C4BB150332; Fri, 19 Jun 2020 16:20:55 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjXx2HpQk75h; Fri, 19 Jun 2020 16:20:54 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 7D188B15032B; Fri, 19 Jun 2020 16:20:54 -0500 (CDT)
From: "Pete Resnick" 
To: "Dave Crocker" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 16:20:53 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 21:20:58 -0000

On 19 Jun 2020, at 16:15, Pete Resnick wrote:

> [Offlist]

Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.

(*Sigh*)

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 15:01:45 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38B33A0EB6 for ; Fri, 19 Jun 2020 15:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 I4bg3gdDgzmu for ; Fri, 19 Jun 2020 15:01:42 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A9E3A0EB5 for ; Fri, 19 Jun 2020 15:01:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 1838FB151201; Fri, 19 Jun 2020 17:01:37 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffdX_610R1fc; Fri, 19 Jun 2020 17:01:36 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 09B97B1511F8; Fri, 19 Jun 2020 17:01:35 -0500 (CDT)
From: "Pete Resnick" 
To: "Douglas E. Foster" 
Cc: dmarc@ietf.org
Date: Fri, 19 Jun 2020 17:01:34 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: <9CA32160-CEDA-46F3-A758-9249FBDAF431@episteme.net>
In-Reply-To: <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com>
References: <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation (was: Re:  Header munging, not ARC, can solve the mailing list problem)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 22:01:44 -0000

On 19 Jun 2020, at 15:05, Douglas E. Foster wrote:

> Why is the state of the message-id important?   You have mentioned 
> it twice.

So, we've been talking about the semantics of messages sent by a mailing 
list. My contention has been that for many mailing lists, and 
particularly the ones we've been talking about, the intent is that the 
mailing list is simply resending messages on to the subscribers to the 
list. The semantics of the message are revealed in the headers: The 
 From: header indicates who the author of the message is. And the 
message-id is a way for the resender of a message to indicate that it is 
"the same message" as a previous one that it received, and can used when 
"threading" messages in a conversation view or deleting duplicates for 
display purposes.

> It is not a required header.

Well, kinda sorta. My apologies if you already know this; perhaps useful 
to others:

Be careful about MUST/SHOULD/MAY in IETF documents. Of Message-ID:, RFC 
5322 says:

    Though listed as optional in the table in section 3.6, every message
    SHOULD have a "Message-ID:" field.  Furthermore, reply messages
    SHOULD have "In-Reply-To:" and "References:" fields as appropriate
    and as described below.

And if you have a look at RFC 2119:

    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Which is to say, "SHOULD" means "MUST unless you really know what you're 
doing". We don't do requirements the way other standards folks do. Also 
from 2119:

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

We don't do "conformance" in IETF by using MUSTs and SHOULDs and MAYs. 
It's all about interoperability.

In this case, read the sentence as, "Use a Message-ID:, because if you 
don't you may screw up what the receiver of the message needs to do. 
That said, there might be circumstances where you simply can't produce 
one, and the recipient is going to have deal with that possibility, but 
you had better have a pretty good reason."

> It often uses a domain portion that is not a registered name.

It needn't be registered to be useful; only unique. That said, I'm not 
sure about "often".

> The recipient has no way to know whether or not it has been changed 
> during forwarding.

It could be signed, could it not?

> I have tried to imagine a way to use message-id in message evaluation, 
> but have given up.

Back to your original question: My comment about Message-ID: was not 
about whether it was particularly useful for DKIM/DMARC, but more about 
how its semantics are reflected in mailing list email messages.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Fri Jun 19 15:13:56 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882203A0ECE for ; Fri, 19 Jun 2020 15:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 A3SxitIsjDwD for ; Fri, 19 Jun 2020 15:13:52 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 CE3113A0ECB for ; Fri, 19 Jun 2020 15:13:52 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id l10so6442495vsr.10 for ; Fri, 19 Jun 2020 15:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jeyPBYQRB4cQjwSyJDEjXa6rnvuhRk5+tGEJfRw53yE=; b=W+haU1jVmolMjQo6GAiVtWYpoHl9eRkRk1FaPgBLanpYUzB8LJ/XCQ1zZMpLtQ9s3W h4H22T02vVSX4BYgm3CdGE0aEPqvK7bkQoFVX7criSO7JHnSuHoKPqfz7jQp1XAxNVs3 CsfdoBPf4mlZcryhJrJISD5hhmtmJGmQSW8ySTJbLBFQfOOq0R9KqHBARThI6JAK/ot6 x12wgXXcWVOEXLNHwf6TkUwxf/bZiiREvvwkAcywGuBxv5V19/5dtlPpWqnZPB+BP9K4 N/zdOTfOf/srTbV4SWxYkkvlaoUs7X5Iq7Ssbz3NtgI2ez/mTS/JO0psp8jZXIMqISol 0IYA==
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=jeyPBYQRB4cQjwSyJDEjXa6rnvuhRk5+tGEJfRw53yE=; b=TxyYbb8dQq8GQHJVYVq1j0KNEDiiMc3oinS4s5PE1HDiqk40OHx25BY4o5JrVraXFw kL1nhQ3WmhU3JjY3uEZpbi45dS1oEFWax04wVF+MYBXNeQ++5pplEf4oISxDsCckCPHT YWobB5Ot8bSQyGUFs6M0zWfsYmtE+UynIO4BPkTPjRGH/Uk8WJJPOQFd4iigyruJRlIl rt3PM2dRCedjmUYf5Rqm0jGhQH9yrZz5aa/gRb8Z6cmf1fBO553HMonyztOxYuNdqavR ZdBGa8+05kXSuKx3FgERMNOR6Q+7n7jNVhj8VU+OD/oyw23dMxI42h/Dbp8UihIXh3z7 8AuQ==
X-Gm-Message-State: AOAM532D9jPlGeE8gsoEvgRjnhhp5L+Fd5ykw5kb0FpHtyqiIxeU5z13 YbDODudQ9A4hWrWr0rQPK4/i1126b1cQ450GB4mA
X-Google-Smtp-Source: ABdhPJzPzBPqGMZPbHjtS+apnyCPzKnKRah/anv/wOaCU3ONSFG5ZBxsaFAFbMJuPwyJtfB5qz2Mw0jOQDx7JsndtFA=
X-Received: by 2002:a67:e451:: with SMTP id n17mr9401917vsm.238.1592604831465;  Fri, 19 Jun 2020 15:13:51 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com> 
In-Reply-To: 
From: Brandon Long 
Date: Fri, 19 Jun 2020 15:13:39 -0700
Message-ID: 
To: Pete Resnick 
Cc: Dave Crocker , IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000003fce6505a8773538"
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 22:13:55 -0000

--0000000000003fce6505a8773538
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 19, 2020 at 12:03 PM Pete Resnick  wrote:

> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>
> > The description of what a Mediator might do is not incompatible with
> > also viewing it as having characteristics of a publisher:
> >>
> >> ### [5.3](). Mailing
> >> Lists
> >>
> >>
> >>        ...
> >>        In addition to sending the new message to a potentially large
> >> number
> >>        of new Recipients, the Mailing List can modify content, for
> >> example,
> >>        by deleting attachments, converting the format, and adding
> >> list-
> >>        specific comments.
>
> Fair enough, but as you mention below, in the case of the common mailing
> list, the intent is simply to redistribute the message with minimal
> change (hence the retention of the Message-ID: and the From:). That
> said, I do disagree with the reasoning given with regard to why
> 5321.MailFrom has changed: It's not because of the authorship, but
> rather because it is responsible for the submission onto the network,
> just as the ReSender is in 5.2.
>
> > Note that in terms of email transport, it is posting a new message.
>
> Strictly in terms of transport, yes. But in terms of the layer above
> (the 5322 layer), it is usually the same message; see the second Note:
> in RFC 5322 section 3.6.4:
>
>        Note: There are many instances when messages are "changed", but
>        those changes do not constitute a new instantiation of that
>        message, and therefore the message would not get a new message
>        identifier.  For example, when messages are introduced into the
>        transport system, they are often prepended with additional header
>        fields such as trace fields (described in section 3.6.7) and
>        resent fields (described in section 3.6.6).  The addition of such
>        header fields does not change the identity of the message and
>        therefore the original "Message-ID:" field is retained.  In all
>        cases, it is the meaning that the sender of the message wishes to
>        convey (i.e., whether this is the same message or a different
>        message) that determines whether or not the "Message-ID:" field
>        changes, not any particular syntactic difference that appears (or
>        does not appear) in the message.
>
> > Mediators really have complete freedom to do whatever they want.  If
> > describing the full range of what a publisher might do, it would cover
> > the same range.
>
> Well, "complete freedom" in the sense that no Internet police prevent
> such actions. But for most mediators, large substantive (for interesting
> definitions of "substantive") changes are outside of the scope of their
> definitions, and would probably invite someone to say, "That's not being
> a mediator." Certainly that would happen in the case of an alias or a
> resender.
>

And if we knew how to encode and verify that the mediator sticks to that,
we could
enforce it with policy.

There were several attempts to come up with alternative signing schemes
that would
allow messages to pass through mailing lists and still be verified as
"untampered" with,
and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, and
that would have been
sufficient and a better solution than From header rewriting.  Everyone has
their opinion on the must
haves for mailing list message modification, and it becomes quickly
intractable.

Brandon

--0000000000003fce6505a8773538
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    =

    On Fri, Jun 19, 2020 at 12:03 PM Pete=
 Resnick <resnick@episteme.net> wrote:
    On=
 19 Jun 2020, at 13:38, Dave Crocker wrote:
    

    
> The description of what a Mediator might do is not incompatible with <=
br>
> also viewing it as having characteristics of a publisher:
    
>>
    
>> ### [5.3](<    https://tools.ietf.org/html/rf=
c5598#section-5.3>). Mailing 
    
>> Lists
    
>>
    
>>
    
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
    
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 In addition to sending the new message =
to a potentially large 
    
>> number
    
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 of new Recipients, the Mailing List can=
 modify content, for 
    
>> example,
    
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 by deleting attachments, converting the=
 format, and adding 
    
>> list-
    
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specific comments.
    

    
Fair enough, but as you mention below, in the case of the common mailing 
list, the intent is simply to redistribute the message with minimal 
    
change (hence the retention of the Message-ID: and the From:). That 
    
said, I do disagree with the reasoning given with regard to why 
    
5321.MailFrom has changed: It's not because of the authorship, but 
    
rather because it is responsible for the submission onto the network, 
    
just as the ReSender is in 5.2.
    

    
> Note that in terms of email transport, it is posting a new message.

    
Strictly in terms of transport, yes. But in terms of the layer above 
    
(the 5322 layer), it is usually the same message; see the second Note: 
    
in RFC 5322 section 3.6.4:
    

    
=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: There are many instances when messages are=
 "changed", but
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0those changes do not constitute a new instantiat=
ion of that
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0message, and therefore the message would not get=
 a new message
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier.=C2=A0 For example, when messages are=
 introduced into the
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0transport system, they are often prepended with =
additional header
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0fields such as trace fields (described in sectio=
n 3.6.7) and
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0resent fields (described in section 3.6.6).=C2=
=A0 The addition of such
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0header fields does not change the identity of th=
e message and
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore the original "Message-ID:" f=
ield is retained.=C2=A0 In all
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0cases, it is the meaning that the sender of the =
message wishes to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0convey (i.e., whether this is the same message o=
r a different
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0message) that determines whether or not the &quo=
t;Message-ID:" field
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0changes, not any particular syntactic difference=
 that appears (or
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0does not appear) in the message.
    

    
> Mediators really have complete freedom to do whatever they want.=C2=A0=
 If 
    
> describing the full range of what a publisher might do, it would cover=
 
    
> the same range.=C2=A0=C2=A0
    

    
Well, "complete freedom" in the sense that no Internet police pre=
vent 
    
such actions. But for most mediators, large substantive (for interesting 
definitions of "substantive") changes are outside of the scope of=
 their 
    
definitions, and would probably invite someone to say, "That's not=
 being 
    
a mediator." Certainly that would happen in the case of an alias or a =

    
resender.

    And if we knew how to encode =
and verify that the mediator sticks to that, we could
    enforce it =
with policy.

    There were several attempts to come u=
p with alternative signing schemes that would
    allow messages to p=
ass through mailing lists and still be verified as "untampered" w=
ith,
    and we were unable to come up with such a thing.
    <=
br>
    Perhaps we could have constrained ourselves to a 80 or 90% so=
lution, and that would have been
    sufficient and a better solution=
 than From header rewriting.=C2=A0 Everyone has their opinion on the must
    haves for mailing list message modification, and it becomes quickl=
y intractable.

    Brandon
    

--0000000000003fce6505a8773538--


From nobody Fri Jun 19 15:29:24 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05433A0EF1 for ; Fri, 19 Jun 2020 15:29:22 -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, FREEMAIL_FROM=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=gmail.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 GFl9d9nFb1Sj for ; Fri, 19 Jun 2020 15:29:21 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 A09C63A0EED for ; Fri, 19 Jun 2020 15:29:21 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id er17so5236723qvb.8 for ; Fri, 19 Jun 2020 15:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JgAWqo1g0zLi295ypLfGtB2TskXu4EMdCLaJIjAJSt0=; b=OU3VvAAsbZoPakHPtooIbtKWSdKh6vrUUYRtXt3CrDphNthJsPQJq7ICUnfCQSEwvP qzPjCs1kUvFp2Sluz4KE1qVRriDf7ZGU9XyenVIvgTwPErXjYuelW47sGeZoPJ/et/CF PeEiKH11XVFL+oqiSsZlPpf8t8F6f+Lfi/ovk5vk5sx2CC+Qe3hcN6puweCuW2n8aK4i WsQVK9XkKRkH39g+zzyCmD73tZtkyKWmRcqU8IJU7pF1dZwc7ChL/3AmlYbOok/BjVj2 /iB5Hk/xztBYpeo1CcxT1PY1BrKUoM+3q+W6+xqN9iZ7tIeXKNWe9y9yHBptOWOiQoCw laWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JgAWqo1g0zLi295ypLfGtB2TskXu4EMdCLaJIjAJSt0=; b=gZeJNcsZbuXd4bMP99TOZO8sJrM7DL5Xw8mS6UmJCi4tWdAzNjwUsT3PgRjwZIHEyp zz7zZ+0SuEU8MtDlTIS09doNSk8Vf2F5hPRO+saENMJFrpFwT29aaQi9PolQaD3N116P TakjwdBprWqBEDIrhRVCw91MqlSa7aIKgQ9Pukh/5pgVB1FJ9dW7A25idWRuIUgCopxt 6kBVpDWqQUkbdfzWzIZqHM9Ufo0eL2WPXGJvJP8Cx6yHiu0W+CtCCSAAE7vU43HIBIJ0 xBpLlWUoJmFa8Wd275g+uuiSHQI2zJW7C2mxtQqu3Xl8bPYj9xIlzwlX2tKbeUbNISKn 65xQ==
X-Gm-Message-State: AOAM5316U1i9Y5v6Y+8u702AgzWz8Ju0mouip2RY1ZyHjp9ScOTGy/O+ HnzjU4sVbz0EhC4itMT/rqLPsS0+
X-Google-Smtp-Source: ABdhPJyogpoM6yd8OM+YYgPaKjMIJNjJKYRuXj76nCSlFf/UVIrP7Dsn6BHoY9VTu0M/t8VT4viEzA==
X-Received: by 2002:ad4:55eb:: with SMTP id bu11mr11136349qvb.182.1592605760392;  Fri, 19 Jun 2020 15:29:20 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id o66sm7305830qka.60.2020.06.19.15.29.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 15:29:19 -0700 (PDT)
To: Pete Resnick 
Cc: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>  
From: Dave Crocker 
Message-ID: <6bc17bd8-deec-21ee-467c-b315a5a87412@gmail.com>
Date: Fri, 19 Jun 2020 15:29:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 22:29:23 -0000

On 6/19/2020 2:20 PM, Pete Resnick wrote:
> Crap. My deepest apologies to Dave. I am very embarrassed by fat 
> fingering that. It is not the worst private thing I've ever sent to a 
> list, but still.


A bigger concern should be with thinking that such paternalism is 
appropriate.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 19 15:32:39 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B03A0EF3 for ; Fri, 19 Jun 2020 15:32:37 -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, FREEMAIL_FROM=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=gmail.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 btZ-ktdM_3I6 for ; Fri, 19 Jun 2020 15:32:36 -0700 (PDT)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 48BC13A0EF2 for ; Fri, 19 Jun 2020 15:32:36 -0700 (PDT)
Received: by mail-qv1-xf34.google.com with SMTP id p15so5237715qvr.9 for ; Fri, 19 Jun 2020 15:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=rh1nUuhUGDyuBRoOsGkK0gPZ0yBFgvjI/NRVSTdS92w=; b=WTAxBy2xDRJRo55t096dSD5UdZTVD2zBXgJy6OdXAUDZlW95RZEzd1yTwmA2A1ZEXa u7rStfzBubYLh862l9qctekiDSJvKKo3y9EmNzGy58ovTWp/Ymie+vMzqsfKVoYzIF6y w0NTV0W46Gax7PqCIiPu9P/5wum/fzZpHjVg4CLZd1X/aE8ysanzddAMS6AhflVh9v0v kOKIH4FjNoeYhbbM95OhjWvnL7vD2gzQA6PI2j8oSzO5mxl15jbwPCpI9IKFlF6rGRKE BG9Nzirj0reyMK2VTd1I1rk7zthbtbHv7tJZfB4Ltf1mNiLTciu4mLkMG1sxUgltK1N8 bvWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rh1nUuhUGDyuBRoOsGkK0gPZ0yBFgvjI/NRVSTdS92w=; b=ofNaGuk13defdIZgThv14FgIbGc9n/JRpJRQaha5WAz1cby3iS18ftnca5PLMywl4q VaPy4yTLxGmpSwcVMl/IECnBNmi54Hzt8+iCRehjQj9uFRvkWS4aY+5iKZGnYw72d92W W9U3vwo1oIo6Zb9rPrgSIsKRn6rYa5JLG1ab79mbCM7R4qyVu6cGW2gkuT+XVdSOId/h 4RN1gMVUrflM/Bze265Wfde5Ak/RrojcqMFKt7Y3Xf1j1Ls46hsFdv6UOuURusECvyYu 7RfUbCRbxF4EDb69kHAAxWTaf0cY3+tAY0Tkzl1MzWrARf4vXXoSqM6z8o5POdnX9dFQ rInw==
X-Gm-Message-State: AOAM5338wlKS8lDYo+wuPRs+dTvDvC8V0Hm0y0qT9ittWWGsWlI8nuCM K6ELFLTkid4czwtP1mWPcRfvS4kw
X-Google-Smtp-Source: ABdhPJysubKhI3JcJdkPPZyE+z7qbbLWX/ysa/E5SOyg6Slu1Kz9bYS0CfCta1n9s2G79zg2Agcp1g==
X-Received: by 2002:a05:6214:1545:: with SMTP id t5mr11093169qvw.53.1592605955110;  Fri, 19 Jun 2020 15:32:35 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id i3sm7330503qkf.39.2020.06.19.15.32.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 15:32:34 -0700 (PDT)
To: Brandon Long 
Cc: IETF DMARC WG 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  
From: Dave Crocker 
Message-ID: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com>
Date: Fri, 19 Jun 2020 15:32:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jun 2020 22:32:38 -0000

On 6/19/2020 3:13 PM, Brandon Long wrote:
> There were several attempts to come up with alternative signing 
> schemes that would
> allow messages to pass through mailing lists and still be verified as 
> "untampered" with,
> and we were unable to come up with such a thing.
>
> Perhaps we could have constrained ourselves to a 80 or 90% solution, 
> and that would have been
> sufficient and a better solution than From header rewriting. Everyone 
> has their opinion on the must
> haves for mailing list message modification, and it becomes quickly 
> intractable.


There's a chance that it is possible to specify a small range of 
modifications and arrange a style of signing that could survive them.  
So for originating and mediating sites that conform to that range, a 
'preserved' original authentication might be possible.

However...

I don't remember enough detail from the original dmarc discussions, so I 
don't remember how much of this was discussed, but I vaguely think it 
was covered.

Anyhow, there is a long track record of difficulties getting mailing 
list systems and operators to adopt external standards, and it isn't 
clear (to me) that the small range would be useful enough.  These risk 
factors do not encourage pursuing the complexities and costs of a global 
standard.

That leaves just a staged trust model, establishing a basis of 
accountability (and reputation) for the mediator sequence. Hence, ARC.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Jun 19 17:09:06 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987C63A0F75 for ; Fri, 19 Jun 2020 17:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=l/0uMHVd; dkim=pass (1536-bit key) header.d=taugh.com header.b=iGz2rq3H
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 VtmVaBeL1zvh for ; Fri, 19 Jun 2020 17:09:03 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2189C3A0F74 for ; Fri, 19 Jun 2020 17:09:02 -0700 (PDT)
Received: (qmail 36065 invoked from network); 20 Jun 2020 00:09:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8cde.5eed539d.k2006; bh=vKzZ2ITRNz6UmSRKkqERyV2nS/tT8a+qbw62rLZ5gHQ=; b=l/0uMHVdhu2WvlTSlxBjqPwts3M4n8zPK9Qdc/PvSQ5FuNFmAHRGejS87fkYzM0mtzQgsvRvpf0aso6lMVC+8CueEteI1d81zIsDjvC2+7Xu/qxyNkf0TMxYSsMIHVoWgXhyHJ9Lk4een4uYP1qPcFbFsuU0QByIiyFst/s7FL8ZQhzuA4DodpVTb3Am5V7gVEBJm5WrGWDkyShTYoSsw83X0MxdM4hD7FMrxab9//O1HpZWw6vIQvqlHXA//uhx
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8cde.5eed539d.k2006; bh=vKzZ2ITRNz6UmSRKkqERyV2nS/tT8a+qbw62rLZ5gHQ=; b=iGz2rq3HVJykh/QYtfH2Iwcbz3o6b6pN6iF6CJ9yiBzBI80jg/vkV53aD2agiwVimFBow0+dxY0yldBegMAev3I4nsuk+DIRe2nsJKa0PVOIygXR8pdf5S4Ipa/xeCZKyHwhwonbnkxLuN87WnqhGbFT3RbQJ7MJxwnxSEktbDRB/DvypQ3JSmHw9PbM0+XmzT0Sk+uOwo/6QJB7EqOyR2xYJVmH7PRJMvQ9RhwMRKNrNsV0VPCwsIBRF81c2Mc/
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Jun 2020 00:09:01 -0000
Received: by ary.qy (Postfix, from userid 501) id 2AC2E1B389B6; Fri, 19 Jun 2020 20:09:02 -0400 (EDT)
Date: 19 Jun 2020 20:09:02 -0400
Message-Id: <20200620000902.2AC2E1B389B6@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: dcrocker@gmail.com
In-Reply-To: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 00:09:05 -0000

In article <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> you write:
>There's a chance that it is possible to specify a small range of 
>modifications and arrange a style of signing that could survive them.  
>So for originating and mediating sites that conform to that range, a 
>'preserved' original authentication might be possible.
>
>However...
>
>I don't remember enough detail from the original dmarc discussions, so I 
>don't remember how much of this was discussed, but I vaguely think it 
>was covered.

It definitely came up in DKIM.  It rapidly became clear that there
are many things that lists do that have simple user semantics but
are hopeless to describe in terms of bytes in the message, e.g.,
reordering or deleting MIME parts.

>That leaves just a staged trust model, establishing a basis of 
>accountability (and reputation) for the mediator sequence. Hence, ARC.

Agreed, it seems unlikely we can do any better.

R's,
John


From nobody Fri Jun 19 17:12:12 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E783A0849 for ; Fri, 19 Jun 2020 17:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=V4weaCen; dkim=pass (1536-bit key) header.d=taugh.com header.b=f/wdw8PB
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 MFQ42P6qBAnR for ; Fri, 19 Jun 2020 17:12:09 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 441A93A0F76 for ; Fri, 19 Jun 2020 17:12:09 -0700 (PDT)
Received: (qmail 36449 invoked from network); 20 Jun 2020 00:12:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8e5f.5eed5458.k2006; bh=eZ4Qc7RvOiv4FdTyMgm+BgdLgcen0K/a1MR8eDUMZnQ=; b=V4weaCenVxWfMFVlYTv9imxid7OqX/K9eHYOzgh7QFjMow2nC+7lwpsnXdGzjL4ofeZlGTgaGiqd2Wy+vSrTTlKHDXpnWVa126IZYSX4GGbgsGk/iNQR2ddpB4M6o5/UTZXtBKwkXuqzNWtFKzseS4WjGTKNvCmtKUdDOuHyBVlhgpg0v1rVRyIkI3FuxfQo8lmxiiN1bUebAQi6rqh33HMAZVCMnX+4DbarE9cheSBMtUv8hQeXiU/UTSxSzgxP
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8e5f.5eed5458.k2006; bh=eZ4Qc7RvOiv4FdTyMgm+BgdLgcen0K/a1MR8eDUMZnQ=; b=f/wdw8PBOJuBaL8UZClVAy09f7BVozaw9VSQId53+H1zPIPf8+tOsBavVZBXuUSxHg0B0Xc8qnRly/muf6Rm4oZwMf8Ye5H9uuS4/pPdlceF0luoVrczCtMf/t7whOTJGgRK0eaK7NA4uHiuPhnxWCpvupr0lX7QGpvBimr35osokMYVIcmRCuLKvueS6m5DrAK44rF+LuxvQcKLOD2sBfCqvrjDmP5O1CmCdC2LfsvDrIBMtpuh39Gk9PV/PENJ
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Jun 2020 00:12:07 -0000
Received: by ary.qy (Postfix, from userid 501) id AC1871B389DF; Fri, 19 Jun 2020 20:12:08 -0400 (EDT)
Date: 19 Jun 2020 20:12:08 -0400
Message-Id: <20200620001208.AC1871B389DF@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Message-ID, was Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 00:12:11 -0000

In article <4b20eff9-0979-4695-a984-133e330e97f6@email.android.com> you write:
>Why is the state of the message-id important?   You have mentioned it twice.

A great deal of mail software assumes that if two messages have the
same message-ID, they're the same message. We use this to avoid
showing the user the same message twice, e.g., if one copy arrives
directly and another via a list.

This has been standard practice for decades. I'm surprised you're not
familiar with it.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Fri Jun 19 17:48:24 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273323A0F99 for ; Fri, 19 Jun 2020 17:48:22 -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, FREEMAIL_FROM=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=gmail.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 pUaJsJhy0XHs for ; Fri, 19 Jun 2020 17:48:21 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 E293B3A0F98 for ; Fri, 19 Jun 2020 17:48:20 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id o15so6559903vsp.12 for ; Fri, 19 Jun 2020 17:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NxelHjdG518dov5Su2ZhKrHD0Ownlx+Q9juS56JWG3k=; b=ELn9iBtv+iRMhZZklqeS0Kux354daJBv2NNmCAPGzFz/Y6XZrI7H265J3lxoNCQOJW KuC5tytIcKGmMJIi3bi5xxnOeaLiow8dIKyisRPPDgHo6b6DzRAYag009yiMWM8olmGg 9hehTBgwaXWiwmM9+Na8w40lUtrM5n5mvvtakXkfw2eUgWTw9jid8xyYGnNHoH6aKFkZ pXj0GutIxcuKyOboss+wGMLyqtyY1Zsl76SdcGLF0Q9vw5KlRGivKhSgUYvE+XBr3Eu4 wM3Ze59bgXljH41KwpxeR7TaUKCWRwrcg08Yy78ZQf72IDp9z1calZvzN2jiUsEB3Ojc DGNg==
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=NxelHjdG518dov5Su2ZhKrHD0Ownlx+Q9juS56JWG3k=; b=AmEMRp+bKO7dmb3GEHpKeEvycJpvta2VR4yrX881ScS0sgfIn2rFm1zhp3UY5b4npp 6H+YnoqjnESFKyiLSTOF4nsotqRVkOjpRMpO8R8twWYJXC3wQ89uf/q2hNyZCHSe+7o+ 5NJ2hhbUS36Q0vT7MjHWM9tQjRyNPRQkzva/gWvwO/Oaboh4QNHngzlCs1BOiYCsiJRp kjX39irgd1tsbCmkyNnKwC4cTSqJKLgNQNKafVAlMC2IvOXVG5rVe/WnVqXv6Erm1dzh d/O6yo3NE8E8H3D/tGIh8s6xBxZ0ENSZzRxj2N/7/s1x6ITHwcHeublFYmno7dHgySt/ xslQ==
X-Gm-Message-State: AOAM5304jE3UVIHgZSb3JMw6MZPXBwV9agunZ9NieEjX0CeDDiZGBM/s UR6krhtvUdfD4HMmJ+lleMxKK4cdOZXRQnIe1Qk=
X-Google-Smtp-Source: ABdhPJxGjcHsqlBKwz/+JqXINvrqZowUd+r96S5EvbN73zOfa99obACFkbMNaeA2hGbLMYgMcXkVxx8gb3tea1/MmmU=
X-Received: by 2002:a67:7dcd:: with SMTP id y196mr9467562vsc.13.1592614099916;  Fri, 19 Jun 2020 17:48:19 -0700 (PDT)
MIME-Version: 1.0
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>
In-Reply-To: <20200620000902.2AC2E1B389B6@ary.qy>
From: "Murray S. Kucherawy" 
Date: Fri, 19 Jun 2020 17:48:07 -0700
Message-ID: 
To: John Levine 
Cc: IETF DMARC WG , Dave Crocker 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 00:48:22 -0000

On Fri, Jun 19, 2020 at 5:09 PM John Levine  wrote:
> >There's a chance that it is possible to specify a small range of
> >modifications and arrange a style of signing that could survive them.
> >So for originating and mediating sites that conform to that range, a
> >'preserved' original authentication might be possible.
> >
> >However...
> >
> >I don't remember enough detail from the original dmarc discussions, so I
> >don't remember how much of this was discussed, but I vaguely think it
> >was covered.
>
> It definitely came up in DKIM.  It rapidly became clear that there
> are many things that lists do that have simple user semantics but
> are hopeless to describe in terms of bytes in the message, e.g.,
> reordering or deleting MIME parts.

A number of drafts were floated, as I recall.  I had a couple.

In one case, I think it was a new DKIM signature tag.  The idea was to
place a small annotation on the message of some kind that effectively
meant something like "MTA X asserts that it added '[foobar]' to the
Subject: field".  Another might be the usual "--" followed by a short
signature added to a plain text (or maybe non-MIME) body.  A validator
could then try undoing that and repeating validation to see if the
author signature then verified.  At the time, the feedback was that
this was too fragile to get right, but I don't think anyone ever
looked at it in the 80-20 sense.  I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.

-MSK


From nobody Fri Jun 19 17:52:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF65A3A0FA1 for ; Fri, 19 Jun 2020 17:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HJI+P9OU; dkim=pass (1536-bit key) header.d=taugh.com header.b=YUPjuw3c
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 sxjzrC5n0zCb for ; Fri, 19 Jun 2020 17:52:57 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 349453A0FA0 for ; Fri, 19 Jun 2020 17:52:56 -0700 (PDT)
Received: (qmail 43332 invoked from network); 20 Jun 2020 00:52:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a941.5eed5de6.k2006; i=johnl-iecc.com@submit.iecc.com; bh=9e8w5c4Xz+sjCooCNr5K/kspcmQ8thADFLBWZ8b4TGE=; b=HJI+P9OUkbyIEEELlgk1NiGsv1IGqybvItqC26k6l9JaJa90VU7XNDBzjvwDnKAE7DDfN7WHTYArhW53VrLdcy0s/vPzc1bfE8utxA242sswB5Qq0cF9oci+w/Bm6AsYTkRf1C0NXmhafX2NEAGZW1PfTKiJn1cyr/lrAVbnIxcD5AsrfsSN0zd2f1IArnlQMCJNVD0DS9lLhbsJNZSN8ZSnLSrrBkH8R5M0dHcXrtKw0vpAtGxmzIHEtJB6mOIu
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a941.5eed5de6.k2006; olt=johnl-iecc.com@submit.iecc.com; bh=9e8w5c4Xz+sjCooCNr5K/kspcmQ8thADFLBWZ8b4TGE=; b=YUPjuw3cEXgdnJ2i1o7eKab8LPQfM/KxvnCWL4e37p7S0YinMRyWO6leQjhP4crGKsim95dfW/QzMNMkqicS3vEEe+MrlKtgHBlTQ/HUpvKAIoHPhRg1KxH9pqniOMwrJVrSVEvxFbworwcoZDnJM6SP9WEPbjled5ZmYsUBPdshxofsXaiy/kt4YAxdLchJ/7iCto4nkNoP0jhJ9iEDTCx5nA2i0NhCXRMdB4X7J+v/WBFF1WhIcMHMHR8hCBld
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 20 Jun 2020 00:52:54 -0000
Date: 19 Jun 2020 20:52:55 -0400
Message-ID: 
From: "John R Levine" 
To: "Murray S. Kucherawy" 
Cc: "IETF DMARC WG" 
In-Reply-To: 
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 00:52:59 -0000

On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
>>> There's a chance that it is possible to specify a small range of
>>> modifications and arrange a style of signing that could survive them.

> A number of drafts were floated, as I recall.  I had a couple.

There's always my conditional signing hack, in which one puts a very weak 
signature on the message which says it only counts if it's resigned by X, 
where X is the expected mediator.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Fri Jun 19 17:54:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6B3A0F7A for ; Fri, 19 Jun 2020 17:54:58 -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, FREEMAIL_FROM=0.001, 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=gmail.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 epLNBZKCKG5Y for ; Fri, 19 Jun 2020 17:54:58 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 CDA883A0F74 for ; Fri, 19 Jun 2020 17:54:57 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id h23so1499160qtr.0 for ; Fri, 19 Jun 2020 17:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=YwaLA/AjryLADWg29tiSbbmvU7LKpj0PG48h9/vQSps=; b=VEdmwimu34R0E/8s2A8x/HNY8DQwjqno8OqZPl+yCphiiZuOfsdmAWLrXR+IjpWykz CNYAnAHaXeFgMLqeXu+MJclXo0aF0Pn/zl/vtJvisBq3mFZu70asczPoPEpWtxniO5PM oM6y2JQ1aDUlZNvxVADCQzHqhmCoGyLuMWHhXqQJueAfRgvR4gSq7rz3mWmPJSqP2k8e u4nZNg0pGAiruaGDXBfWqFDH9dAY5RX4hDnsXcllKnWYEzXBt318Cf/yfjka4+hhD81I r83FtmcNYphSYEJqxIZ4uNzpjRF2bYQRsvjQID/4DhIzs8pcHIzNNrBagA3ucGHp8E3Z nS+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YwaLA/AjryLADWg29tiSbbmvU7LKpj0PG48h9/vQSps=; b=hhk+RhRPBwxu7B7nlZsG1sYdmBkj/b8x8uZWw4Q3HFHqLV9Op08ky6mbICa/KRC8Lx CvbS5XhMESNWJ3cPXpxT1tKKX22y4tnCJoXv2u2XmeH2E54P5HthyVmJ8c0Q4AV4g9Kh yNaEzRny1KCtZTxhB/P2VQL77dWWU+TNsM44U/P9wjYKLhS02fFiIm0PshLHhSFUYvm4 dyRilNz6qBPLWuyTzqsKAN/LykXJK9mhtbPmaxxd7yjG2D/6bjZzxQRfaSPQp/yxZBDn eyAgVqKuw5RvxHM7optEEDQ2B3hfrbbXD+y/CBLdzDj7BA6Y0+qOYjIsUZGFMgkPJKVV khwA==
X-Gm-Message-State: AOAM530ULB6+fFzW8XR5ia4lc7jLkHBRZL6+psHXvMSCEoXL0xBZ4s5E yH6rdD3//4f4hj6tFDY7KXhFWup5
X-Google-Smtp-Source: ABdhPJyd2sXMMn+Oe/8M+IloyWOEre0odreTkQFBosPBO3fgMb0Yf0z4ZXZFmh7YEq7BQXfNFdZaXQ==
X-Received: by 2002:aed:2253:: with SMTP id o19mr6324084qtc.236.1592614496722;  Fri, 19 Jun 2020 17:54:56 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:756d:69e8:3f23:90cf? ([2600:1700:a3a0:4c80:756d:69e8:3f23:90cf]) by smtp.gmail.com with ESMTPSA id y19sm7350432qki.19.2020.06.19.17.54.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 17:54:56 -0700 (PDT)
To: "Murray S. Kucherawy" 
Cc: IETF DMARC WG 
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy> 
From: Dave Crocker 
Message-ID: <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com>
Date: Fri, 19 Jun 2020 17:54:54 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 00:54:59 -0000

On 6/19/2020 5:48 PM, Murray S. Kucherawy wrote:
> I wish in hindsight I'd tried it
> anyway as an experiment, with maybe a couple of senders, receivers,
> and mailing lists as participants.

While I can imagine devising something that would look appealing, I 
believe it would have had a foundation of sand, in terms of operational 
realities, since none of what it would be relying on was documented 
standards and, again, there was (and I suspect remains) a view that 
mailing list operators did not make good candidates for reliable 
adherence to IETF 'standards'.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Sat Jun 20 04:13:12 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607693A098E for ; Sat, 20 Jun 2020 04:13:10 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 rVAN_8dF2SDi for ; Sat, 20 Jun 2020 04:13:08 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 7DE083A098D for ; Sat, 20 Jun 2020 04:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592651583; bh=wEmmxEzbBLU5NgQ49LF021nhj75slZ9IlK6EgaDVrZY=; l=708; h=To:References:From:Date:In-Reply-To; b=CnqOYSdKlQ2d+cXO6iNmzKrzQaejhE19cJtDknDJQ02mKk+wSWc0oOkDfMVKttUPK ohmMAdWHmSi196XjBvnwMIt2j+g64QA2V5sn5cY03pNloqQ3hCR/97wKFmXBlXYgX8 9r0xdqDwBHXJ1GnkUOok969Yd9K0e366jrLMO5ZAmlYzivEwOUs4RkrDPOaZX
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.9.151]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EEDEF3F.0000176F; Sat, 20 Jun 2020 13:13:03 +0200
To: dmarc@ietf.org
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>  
From: Alessandro Vesely 
Message-ID: 
Date: Sat, 20 Jun 2020 13:13:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 11:13:10 -0000

On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
> 
>> A number of drafts were floated, as I recall.  I had a couple.
> 
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.


Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.


Best
Ale
-- 



























From nobody Sat Jun 20 04:33:05 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB363A113C for ; Sat, 20 Jun 2020 04:33:03 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 1NGZl7NtB1-x for ; Sat, 20 Jun 2020 04:33:02 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2682B3A113B for ; Sat, 20 Jun 2020 04:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592652779; bh=4V3gjAdF8kp2dv/c0vj0BJ/XLrV34y2cBLmeGm3mOXI=; l=3470; h=To:References:From:Date:In-Reply-To; b=DSo4P3fics5qvi5dj5AP5eLXINQG3UAym8gqiq+49VwqWqCzfHoxLpIFbkGzA4LsF 2MWZejDd16w9oD9fz2foj3cPUDs0Yufpt+8PHVCi7LRHBMUiZQhuI/E91Q3/T2muPU 6yy37u6rpI34SPj0qwW78l3Omk2EZJ83giVXlyTIaXJ2CvVpACy/DmzttQQM8
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.9.151]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EEDF3EB.000019AC; Sat, 20 Jun 2020 13:32:59 +0200
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com> <79EA93D8-7075-417F-8613-177BE16E3018@episteme.net>
From: Alessandro Vesely 
Message-ID: <9f1b2f24-0f95-552a-7a74-34aeddd14bff@tana.it>
Date: Sat, 20 Jun 2020 13:32:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <79EA93D8-7075-417F-8613-177BE16E3018@episteme.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 11:33:04 -0000

On Fri 19/Jun/2020 23:11:27 +0200 Pete Resnick wrote:
> On 19 Jun 2020, at 15:07, Dave Crocker wrote:
>> On 6/19/2020 12:02 PM, Pete Resnick wrote:
>>> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>>>
>>>> But typical mediators are trying to maintain a sense and ability
>>>> for the original author and the final recipient to experience an
>>>> end-to-end message exchange.
>>>
>>> Yep. That's the point I was trying to make.
>>
>> Except you seem to be pressing this as essentially a requirement
>> they have
> 
> Ah, no, I think that's the crux of the misunderstanding: I was
> responding to Alessandro, who I interpreted to be saying that *all*
> mailing lists were, by definition, publishers, defining a publisher
> like a newspaper, where the true author of the content are the folks
> in the masthead, even though they acknowledge individual authors in
> the by-line. I disagree with that view. Indeed, I think for most of
> the mailing lists we have been referring to in this discussion, they
> are not publishers in Alessandro's sense, but rather view themselves
> as redistributors of author messages. As 5598 points out, there is
> variance in how much "editing" is done by any given mailing list, but
> again, for the discussion we've been having about how the From: field
> should be used, we've been talking about mailing lists which do the
> sort of minimal editing of messages.


First, although the emphasis was on publishers, I didn't mean *all*
mailing lists.  Options 1.2 (Turn off all message modifications) and
4.5 (Have author domains sign camera-ready posts), with all in-between
variations (e.g. have users manually add the subject tag on new
messages, or attach a footer) are all valid alternatives.  And there
may be more (for this list in particular, it'd be enough for me to
convert the body to base64 before signing.)

Second, looking closely a the roles, what all mailing list do is
keeping the list of recipients.  Authors have no say on that, albeit
they can add a few "direct" recipients themselves.  Defining the end
points is an essential point in communication, which prevents from
considering the authors as agents.  Also consider that authors have to
keep on-topic, or they'd get reproached by the chairs.


> (For mailing lists that do more substantial editing, I may not be as
> motivated to keep the From: field unchanged. If we get more deeply
> into the discussion, it might be useful to start drawing more distinct
> circles around types of mailing lists.)


100% agreed.  We should also loosely consider that in most countries
there are legal constraints which practically force the addition of a
footer.  There are "informal" mailing list which ignore that pressure.

There will always also be mailing lists which ignore DMARC.  I don't
think the latter should be among the possibilities specified in a
standard.

>> That most seek to preserve essentially all of the author's text is
>> fine, but whether and how much is more of a 'business' decision than
>> a technical one.
> 
> We appear to be in violent agreement, as the quip goes. Importantly, I
> think we agree that if a mailing list decides to preserve the original
> From: field, in an attempt to preserve all of the author's semantics,
> they are not "doing it wrong", as Alessandro's message appears to claim.


What is wrong is to wittingly break DMARC.  I just try for rationale.


Best
Ale
-- 


























From btv1==440ca368280==fosterd@bayviewphysicians.com  Sat Jun 20 04:47:36 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBC33A081D for ; Sat, 20 Jun 2020 04:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 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, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 NSaBBBc3kaQy for ; Sat, 20 Jun 2020 04:47:35 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF9C3A0781 for ; Sat, 20 Jun 2020 04:47:35 -0700 (PDT)
X-ASG-Debug-ID: 1592653629-11fa313a101dfee0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 40mFd3gFGPaTps7d (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sat, 20 Jun 2020 07:47:09 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=itg7T9hlLmQ0B3e1Cw4aZH2JjO3dU3YmRZF0WkpFjCw=; b=NnsrQFzXd3IstOn1PNZp9nmo/i5VzJRdyO9P4vySdzf15qNSueFf3gzOpIJ9sQtVg UjvfHk/bpgAlSgqfi938lsC7W3QC/oZ3kTuU+lPGtELwJdH8EA6Jj5GLWPWVCTYQJ U24N273JygrALNA/zsdg01XqyW7V2/g3luNYfVTCI=
Received: by webmail.bayviewphysicians.com via HTTP; Sat, 20 Jun 2020 07:47:01 -0400
To: Alessandro Vesely 
Cc: dmarc@ietf.org
Date: Sat, 20 Jun 2020 07:46:58 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Mediation and controlled forwarding
Message-ID: <63ffc5ec-f5e3-4e15-9a1f-09bf000364d9@email.android.com>
MIME-Version: 1.0
Content-Type: multipart/multipart; boundary=c894c46e26c343e4b5fc022524b49dee
X-Android-Message-ID: <63ffc5ec-f5e3-4e15-9a1f-09bf000364d9@email.android.com>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
From: "Douglas E. Foster" 
X-Exim-Id: 63ffc5ec-f5e3-4e15-9a1f-09bf000364d9
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592653629
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 3388
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82683 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 11:58:23 -0000

This is a multipart message in MIME format.

--c894c46e26c343e4b5fc022524b49dee
Content-Type: multipart/alternative; boundary=2e0eeb399f534bfea36e2ffe9283e8d3

--2e0eeb399f534bfea36e2ffe9283e8d3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If conditional signatures require the participatuon of the author's MTA, th=
en the consent of the domain owner is implied.   DKIM scopes already provid=
e a solution for delegating authority, but the MLM problem stems from not w=
anting to seek domain owner involvement.

Just as significantly, tbe MLM does not want to sign the same document as w=
hat was signed by the author.  If the document is unchanged, a conditional =
signature is not needed.  If tbe document is alrered after the first signat=
ure, the first signsture is not applicable to the second signature.

On Jun 20, 2020 7:13 AM, Alessandro Vesely  wrote:On Sat 20=
/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
> 
>> A number of drafts were floated, as I recall.=A0 I had a couple.
> 
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.


Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.


Best
Ale
-- 


























_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--2e0eeb399f534bfea36e2ffe9283e8d3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


    If conditional signatures require the participatuon of th=
e author's MTA, then the consent of the domain owner is implied.  &nbs=
p;DKIM scopes already provide a solution for delegating authority, but the =
MLM problem stems from not wanting to seek domain owner involvement.

    Just as significantly, tbe MLM does =
not want to sign the same document as what was signed by the author.  =
If the document is unchanged, a conditional signature is not needed.  =
If tbe document is alrered after the first signature, the first signsture i=
s not applicable to the second signature.

    On Jun 20, 2020 7:13 AM, Alessandro Ves=
ely <vesely@tana.it> wrote:
    On Sat 20/Jun/2=
020 02:52:55 +0200 John Levine wrote:
    > On Fri, 19 Jun 2020, Murray S.=
 Kucherawy wrote:
    > 
    >> A number of drafts were floated, as I r=
ecall.=A0 I had a couple.
    > 
    > There's always my conditional sign=
ing hack, in which one puts a very
    > weak signature on the message whi=
ch says it only counts if it's
    > resigned by X, where X is the expecte=
d mediator.


    Conditional signatures should be paired with a mecha=
nism that tells
    the author's MTA when to apply them.  For example, a wat=
er tight
    opt-in protocol whereby author, MLM, and author's MTA can do a<=
br>three-hand handshake.  Without that, we're back to depending on
    reput=
ation, for which simple whitelisting suffices.


    Best
    Ale
    --=
 

























    _________________________________________=
______
    dmarc mailing list
    dmarc@ietf.org
    https://www.ietf.org/mail=
man/listinfo/dmarc
    

--2e0eeb399f534bfea36e2ffe9283e8d3--

--c894c46e26c343e4b5fc022524b49dee--


From nobody Sat Jun 20 07:55:03 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845223A00C9 for ; Sat, 20 Jun 2020 07:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=PJ1EqAKW; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=zC4tpdz2
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 paDX4duXL0xx for ; Sat, 20 Jun 2020 07:54:59 -0700 (PDT)
Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) (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 2F4613A00C4 for ; Sat, 20 Jun 2020 07:54:58 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3615; t=1592664892; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=tJxwy2cTBgL1Nt0q6pnJbAec+WU=; b=PJ1EqAKWrvPDSzzdQJ6ZXaWaZgLk07766rUmbl7yzVK0N4JzS1qo5NN0D8GOQE XHL8aUxfB2kAgWkmhB4JLhGZT1cn4y5N5wOODPEvp+DqZnmXbXTXyjkr/mMf47fd SLAPO6qqrvij6iAOGHugHmO0JFHZBnQ4dJIu/SxJkLpgA=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 10:54:52 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3392189430.1.5428; Sat, 20 Jun 2020 10:54:51 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3615; t=1592664839; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5v6K3h5 l21pYnW3KGS7WPK6LCUa/yibLkCszjmYIFjk=; b=zC4tpdz2/Ir6plmi7OVsWmT XziLQthh4Jh4IqMHv559e/+IhQ8qRVrcSFwh/M/exKAHA1lRKe1qoVmKYOurZmRU JxaX+MFCgsY2EhHGlcucJCDX/iVLLp/aHITh8Ccnx7bTdQUuyxAb8Dtj8gkMX8U2 kj29xEleecFVdbsctIe4=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 10:53:59 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 103567657.1.47340; Sat, 20 Jun 2020 10:53:58 -0400
Message-ID: <5EEE233E.90105@isdg.net>
Date: Sat, 20 Jun 2020 10:54:54 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References:  <9cec7d52-bf44-4bdb-180b-0968c7e76eff@bluepopcorn.net>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 14:55:02 -0000

On 6/19/2020 2:22 PM, Jim Fenton wrote:

> That comes back to the question of whether the domain in the From header
> is visible in the MUA, and if visible, does it alter user behavior
> (e.g., discourage users from clicking phish links). Different people
> have different opinions on that. A couple of messages back on this
> thread, the blocking of email was discussed and that does not relate to
> visibility of the domain in the MUA.


As an "MUA" author/developer, this is a matter on how aggressive the 
end-user client software wishes is to be.  We have seen this evolved 
and increasingly employed over the years.  I can them "Scare Tactics 
Ponzi Schemes."

o Code Signing: Today, developers are being forced to fork up money to 
order to stop scaring users that they are to install "uncertified" 
software.  While I believe this has good reason for FIRST TIME 
installations, I considered it unethical, unfair for established 
developers when the software is already installed and user is merely 
upgrading.

o Self-signed SSL certs:  Today, the browsers, especially Chrome, are 
scaring the "manure" of the laymen users with FALSE complex page 
display indications that they domain just intended to reach is not 
secured. That is false.  The target and common name match and it is 
not expired. What remains is, once again, the lack of an authorized 
3rd party signature requirement.  The domain simply did not wish to 
pay extortion fees to a CA that has a mechanism for an SSL trusted 
chain.  Thanks to Let's Encrypt, this is less of an issue today.

So do we consider advising MUA to add or don't add "Scare Tactics?"

I believe the MUA must begin to become proactive with assisting users 
with the mails DKIM Policy and Trust-based indicators.  I know some 
cites have explored this that was before DKIM POLICY took how. How 
will it play to today with DMARC.  Overall, as a MUA developer, who 
does have new MUA projects in the works, the perpetual mantra that "we 
did that and it didn't work" and the idea that one size (one protocol) 
must fit all and that is must scale, otherwise its useless, doesn't 
really apply anymore.

We need to allow systems who are capable of giving the user more 
confidence with what their eyeballs are seeing explore the considerations.

My take with all this since the beginning was since we don't know all 
the answers on how people will use protocols, we should at least 
provide the considered possible options for them to explore using 
DMARC Tag Extensions.   Here are few that can apply:

Proposed Tag Extensions:

-Rewrite=0|1  if 1, authorize any list system to rewrite 5322.From, 
using the a "standardized" approach that helps keep the domains 
original security.

-atps=0|1  if 1, the domain supports RFC6541 "DomainKeys Identified 
Mail (DKIM) Authorized Third-Party Signatures"

and this one I just came up with to address this MUA display question, 
just winging it now:

-MUA.From={logic to offer MUA on what to display}

The MUA can do its own lookup to see domain's desire to what to 
display. Maybe the options can be:

-MUA.From=0 No advice (default)
-MUA.From=1 Display the Address with User Name
-MUA.From=2 Display just the address
-MUA.From=3 Only Display address when signer domain differs

Of course, with change comes new opportunity.  If the MUA was updated 
to support this tag, then we may not need the tag and just advise the 
MUA to prominently display the address and/or when we have a 3rd party 
resigner involved.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Sat Jun 20 08:25:12 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E343A07A1 for ; Sat, 20 Jun 2020 08:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=GfaF7OQm; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Jkpski4Y
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 Ilys0gDpVpOT for ; Sat, 20 Jun 2020 08:25:09 -0700 (PDT)
Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) (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 BAEFC3A07A0 for ; Sat, 20 Jun 2020 08:25:08 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=429; t=1592666707; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vFL49tcVS5eJ7N4h/Ni0qkoyeBQ=; b=GfaF7OQmtWVq2mthLt3kx2koyRbYHEPEYKdbf2DDjKo58aAwl/jzEFGhYkAPa2 IhnFyBbFC3hZpiPqb9lnypbinon4mHEKqDrncJP8mKPPq8oOcZMhcfCAXT724ajl 8F9wQDNmON5EMg5qm4VLpWg/+npiKpdL/m59++kAT+HGs=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 11:25:07 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3394004611.1.3108; Sat, 20 Jun 2020 11:25:06 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=429; t=1592666657; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cySKP8V QUCqb193IDBuqC4KTBDUIz20yLcmWsIr6vhA=; b=Jkpski4YX5AhJ4WIl6YhrtF LnceIoC1+H4M25d4mWRh6j6aOF643NOo+GnzrcuB3yozo4VnVu7w5af3DFGg+ZHT r7irKKF6Kg9qrPOVZgtRjbB1NBpOGDLfHBtaR6xAHuvwacVN1qHBpaOgKcnFxErD waOjON1zvv1bfxvqWceE=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 11:24:17 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 105385266.1.47668; Sat, 20 Jun 2020 11:24:16 -0400
Message-ID: <5EEE2A57.2010709@isdg.net>
Date: Sat, 20 Jun 2020 11:25:11 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Pete Resnick 
CC: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <5EEBBA09.8070207@isdg.net> <2a33d668-61f9-1059-319b-3088568e0127@tana.it> <7C51E834-5298-46C3-844F-08FB8B27FD8A@episteme.net> <0082bfe5-ce2e-f0c5-58b5-9fbe24f10e5d@gmail.com>  <2c13b743-8862-ddeb-9355-b75edddacf02@gmail.com>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 15:25:11 -0000

Pete, you should see my draft folder! 

On 6/19/2020 5:20 PM, Pete Resnick wrote:
> On 19 Jun 2020, at 16:15, Pete Resnick wrote:
>
>> [Offlist]
>
> Crap. My deepest apologies to Dave. I am very embarrassed by fat
> fingering that. It is not the worst private thing I've ever sent to a
> list, but still.
>
> (*Sigh*)
>
> pr

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Sat Jun 20 08:48:14 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43393A07D0 for ; Sat, 20 Jun 2020 08:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=TBlrlese; dkim=pass (1536-bit key) header.d=taugh.com header.b=CXeL+NA/
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 YSo4ZKM37KAt for ; Sat, 20 Jun 2020 08:48:11 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9D7913A07CB for ; Sat, 20 Jun 2020 08:48:11 -0700 (PDT)
Received: (qmail 56186 invoked from network); 20 Jun 2020 15:48:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=db78.5eee2fb9.k2006; bh=ifs8oa9K7x5YktdUQzrTwahaHdMrWXwY+hmFbySs194=; b=TBlrleseCdECol6VNclFKsH55nhkIYlAmHZZmptOKmox/B920xKktgutUezu9lLogQdIh4CBvtwuENG5D1qz4CSgxG8rtn0AGR2AvRLhgeNoZ0tB7/IPDRNw45g+aOuw8i2QHNW17w+PQLTyUzhfqScaqamHaXb11J4c/heq2zHTBThGb9eegGAwoBDuH6Ca6X5RHh9lvOe6RYMWJYSqkH8g+KBPTf2vDzVLzwQynuwv6cfdzTFbZ84mVO8f4FkM
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=db78.5eee2fb9.k2006; bh=ifs8oa9K7x5YktdUQzrTwahaHdMrWXwY+hmFbySs194=; b=CXeL+NA/Wf5sAI1w10UUVZSW3ao9MrVXbxXPAcnNpvzykNtvdS/i5mCn23xp91G6hsY3XsOrmnSCCySHre0Juf39+qrF1LWaIk93kQk69YPyA6CcWAzm2yQGzEV9IRFJfix5QaMOIzDzeB9o2wHaOPJegk0+AGxk8mUxz8/RSO6HpJHfr1FkBXzQWW51AvEe5pJyJcbb2dIYChDC72VPpEI+WvBKYi6cxVrMoKOPQU4Fugq7HnQWlJHwJjdTbt0h
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Jun 2020 15:48:09 -0000
Received: by ary.qy (Postfix, from userid 501) id 6AA0E1B3D60F; Sat, 20 Jun 2020 11:48:09 -0400 (EDT)
Date: 20 Jun 2020 11:48:09 -0400
Message-Id: <20200620154809.6AA0E1B3D60F@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: vesely@tana.it
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 15:48:14 -0000

In article  you write:
>For example, a water tight opt-in protocol ...

There's no such thing, unless you can somehow ensure that the list
never sends anything that any of the subscribers don't expect.

> Without that, we're back to depending on
>reputation, for which simple whitelisting suffices.

No, please see my message a few days ago about why ARC works the way
it does.


From nobody Sat Jun 20 08:53:29 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FB23A07D8 for ; Sat, 20 Jun 2020 08:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GwHxyvph; dkim=pass (1536-bit key) header.d=taugh.com header.b=UrchwTNM
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 L9UMatAiTKVY for ; Sat, 20 Jun 2020 08:53:25 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A91313A07D7 for ; Sat, 20 Jun 2020 08:53:25 -0700 (PDT)
Received: (qmail 57391 invoked from network); 20 Jun 2020 15:53:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e02d.5eee30f4.k2006; bh=1+9EZgOPStaO2Vfi+OwOKbnBYMJv4tyPGpQQNsk6pNI=; b=GwHxyvphwBvNLjIFB7oj2jOWHkGckRKiHtrcKmi4B81V/rfX3mLAvxmI7fX5zMBORwdkkBImrzDZ0CdTriTLl8kLwj4acu3Z6TOHlTY0orCKK5jluoXTrGX+YXEsoUvyMBSoeN9pNkaVYbNfxUu4wnnikkPjGY842c9WCyarifDyi5Vin5cr/B94a4Mic+bJdnGYOgUsYVbypWQENSlSEjPsPNFc30MpCHPCPXatYql5CiRhcMGYkW76kLJ87xgj
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e02d.5eee30f4.k2006; bh=1+9EZgOPStaO2Vfi+OwOKbnBYMJv4tyPGpQQNsk6pNI=; b=UrchwTNMstvH8h2CO6lqIisAGHcdUc3f2aPgwQb9CqDv9hrAYklDpitcE1M3w/rYMYMeuYf+Eh/ZZnYaBVPUm4dAMa9uh0QRHSy2fcecNRkK7uIAzwgX8+EEeDTdwc03ePaKZiVs8txHqlNW2nYYzWsPeG34XDmTV84Qnk8VCxFy3HZDp2N3Qg6E6VaFLHaPP1wlWpbRQDwsu+H82BmCQjMuhTq+ai38CL35ETJW37z6xgAKrMgHoSPUVO/+1Hyf
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Jun 2020 15:53:23 -0000
Received: by ary.qy (Postfix, from userid 501) id ECC211B3D6B2; Sat, 20 Jun 2020 11:53:23 -0400 (EDT)
Date: 20 Jun 2020 11:53:23 -0400
Message-Id: <20200620155323.ECC211B3D6B2@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: <63ffc5ec-f5e3-4e15-9a1f-09bf000364d9@email.android.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 15:53:28 -0000

In article <63ffc5ec-f5e3-4e15-9a1f-09bf000364d9@email.android.com> you write:
>Just as significantly, tbe MLM does not want to sign the same document as what was signed by the author.  If the document is unchanged, a conditional
>signature is not needed.  If tbe document is alrered after the first signature, the first signsture is not applicable to the second signature.

It would be nice if you'd looked at my conditional signing drafts
before guessing (wrong) about what they say.

Here's the 2014 version:

https://datatracker.ietf.org/doc/draft-levine-may-forward/

And the improved 2018 version:

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

R's,
John


From nobody Sat Jun 20 10:49:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9183A0887 for ; Sat, 20 Jun 2020 10:49:00 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 3QFhxWMVq8r0 for ; Sat, 20 Jun 2020 10:48:58 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 390613A0886 for ; Sat, 20 Jun 2020 10:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592675334; bh=GddHHqnVa7qMqfqikImqmLMYqVMHnvHWIoQvR8sSPRc=; l=1557; h=To:References:From:Date:In-Reply-To; b=BlwFbObv/0eG1/y8xD66WNzvACqxr9tvyVUlHQA3t+paLtmJBTG6s9/qt0z74C50Z c8Q80UqQg+Ej/YIwCsATMj2A0fpKbVnDQGj1/VP+ZL07e+YPils9tDwsHu10MydoYM llUPbmUxkyx/Nhtrpy1O16BI69gm8G6gdTbT+9NjprjKBrV07ZY1ax+29gSve
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.9.151]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005EEE4C06.00003E29; Sat, 20 Jun 2020 19:48:54 +0200
To: dmarc@ietf.org
References: <20200620154809.6AA0E1B3D60F@ary.qy>
From: Alessandro Vesely 
Message-ID: 
Date: Sat, 20 Jun 2020 19:48:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200620154809.6AA0E1B3D60F@ary.qy>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 17:49:00 -0000

On 2020-06-20 5:48 p.m., John Levine wrote:
> In article  you write:
>> For example, a water tight opt-in protocol ...
> 
> There's no such thing, unless you can somehow ensure that the list never sends anything that any of the subscribers don't expect.


Small MTAs can trust their (not anonymously registered) users, so they could blindly accept to weakly sign messages destined to a MLM that a user of theirs has implicitly recommended by starting such a (yet unspecified[*]) water tight opt-in.


>> Without that, we're back to depending on reputation, for which simple whitelisting suffices.> 
> No, please see my message a few days ago about why ARC works the way it does.


Do you mean https://mailarchive.ietf.org/arch/msg/dmarc/gll_AD80SzysVJi9GDeKM12OslA ?

That message proves that ARC depends on reputation too.  I mentioned whitelisting because it's simpler than ARC.

My point is that, if an MTA is not Google, Yahoo, or some such, that is if it doesn't have the list of all MTAs worldwide, then the mailing list problem precludes reliable DMARC inbound filtering.

I don't think, as Douglas suggests, that the MLM problem stems from not wanting to seek domain owner involvement.  IMHO, it stems from domain owners not being able to maintain a global reputation list.  The MTAs who can do that can do ARC, can whitelist, can do DMARC filtering; they don't have a "mailing list problem".


Best
Ale
-- 

[*] See rough ideas at http://fixforwarding.org/wiki/Water_tight_opt-in




























From nobody Sat Jun 20 13:08:21 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26963A0951 for ; Sat, 20 Jun 2020 13:08:20 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TvgTWaLDdDTV for ; Sat, 20 Jun 2020 13:08:19 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 B27963A094E for ; Sat, 20 Jun 2020 13:08:19 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id a10so4346661uan.8 for ; Sat, 20 Jun 2020 13:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JVkjZkVb3jGh6VpM/CsRr7qEdS17rjqUWTQl0CAeXUM=; b=bGMX41lvuvjeDPPuPCoD7GTy2VBhyzovEjPGWGFAV/1pYA6nfyb/uAT0aI8Aqcd9X4 cDCLRpMEBoGt47CHl797XCTrIg7XLTai6rLX7XKJmuPHkBMQ5VqwS+BSV3019k3PNE5h yKsvLp9C+clH4nWQLcqOKGYPcQyD5c21P2ne8WpZvHZueFcUoE4Lw4+RLEXYgVW5l0Ck 1M88b/zllzSjJR18Mz2ZBHSatqbLkuEmpOwJa+/OAEKuwSS4D9+snDzv1HcdYq4laiuv wf14Tu0V7D+UGCdPN01SWqhcOfQqljMkQZnY5fp7XMMxQXzFSZSiPgReTdCyjaPcNA4n vBeg==
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=JVkjZkVb3jGh6VpM/CsRr7qEdS17rjqUWTQl0CAeXUM=; b=kwUyeFAe8Us8/Nv0zJRfg+PlYg8M6xdZ82XpKVN21uFBlfv4jeFL+ENhU/tAYVrJ/6 g8/0WDIuBV2XeRwUU3AqtTdxN1vpdsAZ8BX4gy1mEFwahfTU52xw29VfTYJzG1OGL2OZ /RqrpvWn0oyOpDWa7MiR8sntoMQs/t+3L5OQ1opO05ntXrn++VWCnQfNEQilED3BfsGi 24Lfwvni6ceY9s+9ASDyZ7ueMtqv7CUSoiC5eq78oT29xOpjmifKiH2ToQtsVhmUe6FQ VlIPXK8iZdw4d60hPmWmA+bxHxUwrjdMU8ZElVVLYntp+GHh+63CbhRTnsHtwH/o/fni sqyA==
X-Gm-Message-State: AOAM530LCLFnskSVI8VjpqSUOIFRAH5pWcgBUQT2ZD/Vk3zVh+ncuOeN oecDj0XE3KW3ZXpMeeZmQ42MsFo2shXyEl9gZZs=
X-Google-Smtp-Source: ABdhPJwUiHXFUJ2oJFNwvTUyxKb57Kp2v8eZQ1mY8bcvpmCLPUPfdwUspgN2BuBFBI+4bvC2drqUIfWlfTC0bC28QPA=
X-Received: by 2002:ab0:a81:: with SMTP id d1mr7051271uak.67.1592683698656; Sat, 20 Jun 2020 13:08:18 -0700 (PDT)
MIME-Version: 1.0
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>  <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com>
In-Reply-To: <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com>
From: "Murray S. Kucherawy" 
Date: Sat, 20 Jun 2020 13:08:07 -0700
Message-ID: 
To: Dave Crocker 
Cc: IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 20:08:21 -0000

On Fri, Jun 19, 2020 at 5:54 PM Dave Crocker  wrote:
> > I wish in hindsight I'd tried it
> > anyway as an experiment, with maybe a couple of senders, receivers,
> > and mailing lists as participants.
>
> While I can imagine devising something that would look appealing, I
> believe it would have had a foundation of sand, in terms of operational
> realities, since none of what it would be relying on was documented
> standards and, again, there was (and I suspect remains) a view that
> mailing list operators did not make good candidates for reliable
> adherence to IETF 'standards'.

All true, but if it had yielded useful results, there might have been
encouragement to change that.  Then, suddenly, there would be common
ground from which to do future work such as this.

It wouldn't be hard to put a draft together that described the trivial
things like Subject field tagging and "two dashes at the end mark the
start of a signature', and maybe a couple of popular and mostly
harmless mutations the popular list servers do.  I might know someone
who could help with such a publication.

(I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)

-MSK


From nobody Sat Jun 20 13:24:09 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548173A095D for ; Sat, 20 Jun 2020 13:24:08 -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, FREEMAIL_FROM=0.001, 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=gmail.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 aWtYwtSDJW3L for ; Sat, 20 Jun 2020 13:24:07 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 EACE63A095B for ; Sat, 20 Jun 2020 13:24:06 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id h23so2748347qtr.0 for ; Sat, 20 Jun 2020 13:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Ht9+QtmKnrAI3KjE+qYJGwJEKsXSWggIOlgiTctaCwQ=; b=WsAKjFbkkmQR+heoEFG/L5IOjhKrqcvht+JeCxi6sizwFwynP+wmyvisqizsHQdlBS umlBT6J44LBpWBhqM1Bm7FMuB4bv7l8zRAOb7v8mQrApaYYYun8QpAhZeNToNdsnFQxZ xnaN4+gB9x3K/jeTQ98bkj+qp5hO4wVunpaF5ar2A+CA025dAtYgUxOGcnstEq8aAgbe Ph+SzTJgH9o4NED42aloJZbn1O/FORnqgtB1m7nwetVNamQNseLUet7ySanrIQIF3aMU VLczFwmkbDmXchBUmpz4buO7FlrprBQJ+M7tysTHEzvQ1RaPQCVHY+vl3XAI0fhxkppk G0+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Ht9+QtmKnrAI3KjE+qYJGwJEKsXSWggIOlgiTctaCwQ=; b=kqB2C6AtGsBr2cr6Tao80KLVHyx7DT0lfvuyZ4IH+ViVO77HHUXO5eKy+KDfNt0WMT x/rPQoggMqX2IhCFE/RyT6oozEylyJkxB4vPb834GAps5QbrJ9rhVi6lIplI0JQIr1eL BrzApV+TFkXe8rK9eAyHoSjMW2FzoZsjgdS1V9NY0WOuk8TJ8Lm21NwFK61bdItxkmbQ gl3J07eUFrap/4LZesgAYcKFsWABp8ZPgBzKvWC9KM4UMzYx+JKRIEHVFZLvNzEzXKrY 31pXMxM8+lp3/BuSsWhdyDktYCy3nng9EsBfZR0/tQPYugN6zkRHIPlwtrOn7wN+qwkJ jwUA==
X-Gm-Message-State: AOAM533zCwxQ1x6PXWQtCd2hOYothcJvApt/mxslA3apr9j/oVuT3s64 zjiUzK5dZ7QywzLe7e6fHR6UkFKL
X-Google-Smtp-Source: ABdhPJzw+h64beqS8541u7ARAvza0zZSaiMbT5kB59DXKzMIFRWtjey0YRK6FjgcI0V370ZoM4o/Gw==
X-Received: by 2002:ac8:6f1a:: with SMTP id g26mr9317492qtv.121.1592684645583;  Sat, 20 Jun 2020 13:24:05 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:1d22:ec69:c4fc:9284? ([2600:1700:a3a0:4c80:1d22:ec69:c4fc:9284]) by smtp.gmail.com with ESMTPSA id p16sm9467283qkg.63.2020.06.20.13.24.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Jun 2020 13:24:05 -0700 (PDT)
To: "Murray S. Kucherawy" 
Cc: IETF DMARC WG 
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>  <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com> 
From: Dave Crocker 
Message-ID: 
Date: Sat, 20 Jun 2020 13:24:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8FCA4A6042AF80E0624C6D40"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jun 2020 20:24:08 -0000

This is a multi-part message in MIME format.
--------------8FCA4A6042AF80E0624C6D40
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/20/2020 1:08 PM, Murray S. Kucherawy wrote:
> It wouldn't be hard to put a draft together that described the trivial
> things like Subject field tagging and "two dashes at the end mark the
> start of a signature', and maybe a couple of popular and mostly
> harmless mutations the popular list servers do.  I might know someone
> who could help with such a publication.
>
> (I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)


Were I to chortle about any of this, it would be at the idea that any 
serious effort associated with email authentication could be considered 
altruistic...

In terms of pragmatics, I think the issues here are time and risk.  To 
get to a useful point will take too long for the current working group 
effort, and, given history and environment, its likelihood of being 
successful seems pretty low.

That doesn't mean that none of it is worth pursuing, but rather than it 
might be worth considering independently of the current work and 
initially as IRTF-ish work, rather than IETF-ish.

Perhaps if the effort were viewed as a staged sequence, over an extended 
time.  Staging along the lines of:

  * Document a modest number of highly common 'patterns' of mailing list
    patterns.
  * Get reasonable community support (rough consensus) for the document
    -- including from MLM developers and operators
  * Formulate survivable authentication choices
  * Get reasonable community support for that approach
  * ...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------8FCA4A6042AF80E0624C6D40
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/20/2020 1:08 PM, Murray S.
      Kucherawy wrote:
    
    
    
    
    
      
    It wouldn't be hard to put a draft together that described the trivial
things like Subject field tagging and "two dashes at the end mark the
start of a signature', and maybe a couple of popular and mostly
harmless mutations the popular list servers do.  I might know someone
who could help with such a publication.

(I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)
    
    
    
    

    
    
    
    
    Were I to chortle about any of this, it would be at the idea that
      any serious effort associated with email authentication could be
      considered altruistic...
    
    
    In terms of pragmatics, I think the issues here are time and
      risk.  To get to a useful point will take too long for the current
      working group effort, and, given history and environment, its
      likelihood of being successful seems pretty low.
    
    
    That doesn't mean that none of it is worth pursuing, but rather
      than it might be worth considering independently of the current
      work and initially as IRTF-ish work, rather than IETF-ish.
    
    
    
    
    Perhaps if the effort were viewed as a staged sequence, over an
      extended time.  Staging along the lines of:
    
    
      
      
    • Document a modest number of highly common 'patterns' of
        mailing list patterns.  
      
      
      • 
      
    • Get reasonable community support (rough consensus) for the
        document -- including from MLM developers and operators
      • 
      
    • Formulate survivable authentication choices
      • 
      
    • Get reasonable community support for that approach
      • 
      
    • ...
      • 
    
    
    d/
    
    
    -- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  


--------------8FCA4A6042AF80E0624C6D40--


From nobody Sat Jun 20 17:52:35 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2603A07EC for ; Sat, 20 Jun 2020 17:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=H0oxrPo2; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=e8t4jpwo
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 bphTmIAyIfSr for ; Sat, 20 Jun 2020 17:52:32 -0700 (PDT)
Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 F37793A079D for ; Sat, 20 Jun 2020 17:52:31 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2366; t=1592700742; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vZjeI/+vJex3bLGQ0gKy7APUI5k=; b=H0oxrPo2E0c4cPOauVt4wuZ42fKftTRfODYy+eP1BOmYvKZ5KQm3p5x9vIDjld wX2XhRNErYYl0EdlP+PEcPQv6FuUWVK8QBQSYzhhf4OWhor+QJQ7UZUmGeNHsyWE MwRoA/O4EHcSZcOPHO5lXxvW2dEjCWgZUL6atOeE1LVJg=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 20:52:22 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3428040145.1.4352; Sat, 20 Jun 2020 20:52:22 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2366; t=1592700692; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GzgqdBA 85AO+ZbKSPvRg0jU6ckvLCQ77WeFgRTsaWaw=; b=e8t4jpwopVTTOiqTjpR2+ZA pvC8h7OpKbiM8Q7pYdcvMfY693RXSyppmBHbCnh3PnF52afRUxr4oWmOrSzDI4lp m4Kyl3i+UtbtrT9aFjfQ4obp0l5C1fz0AfAxa7HblH8n88MfkvcdGeMtaUq41LgY PATnCUter2X3Ru/Yuv0Y=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 20 Jun 2020 20:51:32 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 139420110.1.29052; Sat, 20 Jun 2020 20:51:31 -0400
Message-ID: <5EEEAF4B.9000201@isdg.net>
Date: Sat, 20 Jun 2020 20:52:27 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200620155323.ECC211B3D6B2@ary.qy>
In-Reply-To: <20200620155323.ECC211B3D6B2@ary.qy>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation and controlled forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jun 2020 00:52:34 -0000

On 6/20/2020 11:53 AM, John Levine wrote:
>
> It would be nice if you'd looked at my conditional signing drafts
> before guessing (wrong) about what they say.
>
> Here's the 2014 version:
>
> https://datatracker.ietf.org/doc/draft-levine-may-forward/
>
> And the improved 2018 version:
>
> https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Does this mean, the author, nows support and is going to champion his 
proposal?

I seem to recall in 2014, the author citing a lack of interest to 
pursue this and felt it would cause problems. As stated in the 2014 
security conditions, he wrote:

6.  Security Considerations

    DKIM was designed to provide assurances that a message with a valid
    signature was received in essentially the same form that it was sent.
    The forwarding signature condition deliberately circumvents that
    design, to create a loophole for messages intended to be forwarded by
    entities that edit the message.  It opens up a variety of obvious
    replay attacks that may or may not be important depending on both the
    selection of target domains for messages to be forwarded, and the
    behavior of forwarders that receive messages with conditional
    signatures.

I felt then it was another "poison pill" to kill the 3rd party 
authorization effort. I was not impressed but this so I putted on the 
proposal.

Now I read in the improved 2018 version:

6.  Security Considerations

    DKIM was designed to provide assurances that a message with a valid
    signature was received in essentially the same form that it was sent.
    The forwarding signature condition deliberately creates a loophole
    for messages intended to be forwarded by entities that edit the
    message.  It opens up a variety of obvious replay attacks that may or
    may not be important depending on both the selection of target
    domains for messages to be forwarded, and the behavior of forwarders
    that receive messages with conditional signatures.

    A sender can limit the conceptual size of the loophole by being
    selective about what other domains it allows in its !fs tags, and by
    using the x= tag to limit the time during which forwarded signatures
    are valid.

If the author still believes this loophole exist, why are we bothering?


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Sun Jun 21 10:32:34 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A693A0784 for ; Sun, 21 Jun 2020 10:32:31 -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, FREEMAIL_FROM=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=gmail.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 4NsCt1Li_nFm for ; Sun, 21 Jun 2020 10:32:30 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 E97B23A077D for ; Sun, 21 Jun 2020 10:32:29 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id t6so11239511otk.9 for ; Sun, 21 Jun 2020 10:32:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=jtC9zceZ2+Res4/G20zXGvKa4PAe+ew5a5l3T9asfiQ=; b=YVm2DUEqJFy72S+dpVDxaBOKRD6/jKov8/CE6nrwVNl47sBbctLvRVcwj5nHkLGhw/ 2bNMdD/235Bh1TOJRWnsE/rRjcnTI/8XGKryEk0xDXFAjQvrk5FiRe01Y7Yu1LF3YVxA ov9VQ+iKeHLTwV7Yp2mOHkpZMwFfjZiMplnJjl+5EsPJTgAwU+lV6mu+8yGjpgfpSfz2 F5ugN9itLXo4sDGM91XBY9Nl2deqGj82VBZ4xEE/hevmqgda+4AKid1+Fu4x9ERNyXDx xqrdjSJbeb5rfSlxN2yuOUFrw8Z3B6JH7rcbckzdwiVyT6hWEkPnD7wbbcZ2Kp74Bv3C //5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jtC9zceZ2+Res4/G20zXGvKa4PAe+ew5a5l3T9asfiQ=; b=D7+zSULt7GE3xKMiULlWKQThl+Qq6/CaGTpWfq/TMaszd29HaMWxK2/ov7m61Wrrcn tzFpMiJ2xr8KqfOtdpOQmUBrMtRMaMzQkfPaEZ2XZv6zZUKT0xKUysBgMYcmYeEMU9WO lCJbyB2Akkp3+NML0Klj2abusFnKD7z16ike7iEizznJxgZ6Y2TsHSm9QnnZSXWIfFRo /9WQgt6da0gXWSQySiu/tAEkYM1p3tQy8S6O3m2pACgf5N7nMLN46veGiEGj4COlhHaO aISSlz6/1QIIdP337znXInTDXSDXehHzlAzoWNQmmoPOQGtkvwtJI3wVvUXmQ/EJbhKq 6fag==
X-Gm-Message-State: AOAM531sigt96KkZfdax7ysYW/VQ1LD6zsqabsxYoQzzxtvbuMYMnDUq 7OdctL+2afGcEzFW25YEOHdgkqiw
X-Google-Smtp-Source: ABdhPJxLhOXNlDc5Wky0EVnnvsHrjChqKhdqi95VhDKflzOdl1ymzYsNas7aQMdrumf7tbG2ITfQVQ==
X-Received: by 2002:a05:6830:18c8:: with SMTP id v8mr11324923ote.119.1592760748723;  Sun, 21 Jun 2020 10:32:28 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:94c1:b41a:9f34:3d23? ([2600:1700:a3a0:4c80:94c1:b41a:9f34:3d23]) by smtp.gmail.com with ESMTPSA id l11sm2681786oic.15.2020.06.21.10.32.27 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jun 2020 10:32:27 -0700 (PDT)
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
From: Dave Crocker 
Message-ID: <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>
Date: Sun, 21 Jun 2020 10:32:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jun 2020 17:32:32 -0000

On 6/18/2020 12:46 AM, Alessandro Vesely wrote:
> "Authoring" can have subtly different acceptations, though.  The exact 
> sentence is:
>
>              The "From:" field specifies the author(s) of the message,
>    that is, the mailbox(es) of the person(s) or system(s) responsible
>    for the writing of the message.
> [https://tools.ietf.org/html/rfc5322#section-3.6.2]
>
> That is not so far from real.  The term "writing" sounds ambiguous, as 
> it is not clear whether it means "typing" or "publishing", in the case 
> of public mailing lists.  Given that Sender: is dedicated to the 
> typist, I'd opt for the latter interpretation.

In simple terms, author is the creator of the content and sender is the 
agent for getting the content processed.  The latter was distinguished 
to provide a means of improving accountability if there were problems.  
When SMTP was created, later, MailFrom was added as an address for 
sending message handling reports.

When first specified, Sender: was to cover the case of someone doing the 
online work, on behalf of  authors who weren't online, or at least not 
online for processing the message.  Back in those days, that was not 
uncommon.  Even if the author officially had an online presence, they 
often did not do the typing.

(To underscore this a bit: in most of the business world, knowing how to 
type was deemed a menial, secretarial skill and not appropriate for an 
executive. To carry this a bit further: around the time RFC733 was 
developed, in 1977, I managed to get the person in charge of department 
administration functions to authorize my getting a desk with a 
right-hand return, where a secretary's typewriter would go, and where I 
put my terminal. This was extremely unusual and the immediate, similar 
requests from all the other staff like me were rejected. Also, when I 
announced my departure, the next year, the admin was instantly flooded 
with requests for my desk...)

For most email, From: and Sender: are the same person (and the same 
email address.)  This fact was the reason the original specification of 
Sender: in RFC 733 only required an explicit Sender: field be present 
when the addresses are different.

For today, these same abstract constructs have -- or should have -- only 
slightly different application.  From: is still supposed to be the 
author, which remains the creator of the (original) content.  Sender: 
could be any separate party responsible for processing the message.

So, in abstract terms, if I go to a greeting card site and have it send 
a greeting on my behalf, the From: field should be my own email address 
and Sender: should an address at the greeting card company.  But I said 
'abstract' because current realities mean this isn't as useful an 
arrangement as the theory intended.

I believe this is because Sender: is not reliably present. Hence, it 
literally cannot be relied upon.  The Sender field is not created 
reliably to indicate such distinctions and the receive side does not 
reliable note the distinctions.


> For a newspaper, if you pardon the analogy, the masthead is more 
> visible than columnist signatures at the end of the articles.  For a 
> mailing list, publisher visibility used to be provided by subject 
> tags, leaving the From: intact.  Why?  Presumably, because it just 
> worked that way.  However, if the MLM is the system responsible for 
> writing, not modifying From: should be considered a violation.

If a Mediator makes 'substantial' changes to a message, then it can be 
considered a new and different message?  Yes, but note that we have no 
objective criteria for this.  That's why I class this reference to 
'publisher' as a business issue rather than a technical one.  (And an 
ethical one, as some wayward journalists discover when they claim to be 
quoting someone but it turns out the reporter invented the content.)

However I think that referencing the role of an MLM as 'publisher' can 
be helpful to remind us that MLMs have their own agency and can, 
legitimately, make all sorts of changes.  Whether authors and recipients 
like those changes is a non-technical matter.

The practical problem with From: field munging by MLMs that are 
otherwise trying to relay a largely-unmodified messages, is that they 
effective destroy author information, by putting in a different email 
address.

In practical terms, today, the MLMs arguably don't have a choice.  But 
it still can be helpful to understand the problems created by this 
alternation.


>> My understanding of the meaning that DMARC added was, "The author of 
>> this
>> message, as expressed in the From: field, always has their messages 
>> properly
>> signed by the domain in the From: address." You seem to be saying 
>> that, no,
>> what DMARC did was changed the semantic to be, "The From: field now
>> represents the transmitter of the message (as used to be expressed in 
>> the
>> Sender: field when present), not the author, and that transmitter 
>> always has
>> their messages properly signed by the domain in the From: address".

For reference, I consider this an accurate summary of why I say that the 
From: field semantic is changed as a result of DMARC. Specifically so 
that mailing list mail can be delivered.


> Sender: was not meant to be the transmitter in that sense.  It was 
> meant to be the secretary who writes on behalf of a responsible person 
> or system.
RFC 5322 has preserved the semantic of the Sender: field:

      "The "Sender:" field specifies the mailbox of the agent 
responsible for the actual transmission of the message. "

I consider that to be exactly the role the MLM is performing.


> RFC 5322 says display names are "associated" to a mailbox.

I don't see such language in RFC 5322.  In fact, other than the ABNF for 
display-name, I don't see any explanation of its semantic.


> Certainly, changing just the addr-spec breaks the association and 
> wreaks havoc to address books. 

Exactly.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From btv1==4415af57938==fosterd@bayviewphysicians.com  Sun Jun 21 12:44:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1497B3A082E for ; Sun, 21 Jun 2020 12:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level: 
X-Spam-Status: No, score=0.278 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 d8gvKuAO_P8L for ; Sun, 21 Jun 2020 12:44:18 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF88C3A082F for ; Sun, 21 Jun 2020 12:44:17 -0700 (PDT)
X-ASG-Debug-ID: 1592768656-11fa313a101e6870001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id RafA5VHPs3pRNOs8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 21 Jun 2020 15:44:16 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:message-id:subject; bh=LJWfg1m5Ip0kE9IOVIKgpXRz8vhOJX8hLtoNZ6VaWNc=; b=I/htQo8y3++bZ8txH8diKA6EeRlH8YSeolxnoa/leAwfimXikMWkqrlkDhYVgb29b Z81XcoQwLZO0AXwRsDnHwaO7r2mF1srU96UC8YwIFH8jPZj1ee7l+fSuTjjTLN5AU ZMtuq1OW1pLgVdasz+/NwlZH9k8j1HTxQ/CJ7mHNs=
Date: Sun, 21 Jun 2020 15:44:06 -0400
Message-ID: 
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-Android-Message-ID: 
To: dmarc@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
From: "Douglas E. Foster" 
X-Exim-Id: dc7b79c3-58d2-4c05-a777-c1e5f3fcb84f
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592768656
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 3671
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82711 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jun 2020 19:55:39 -0000

PGRpdiBkaXI9J2F1dG8nPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIiBkaXI9ImF1dG8iPjxkaXYg
Y2xhc3M9ImdtYWlsX3F1b3RlIj5EYXZlIENyb2NrZXIgd3JpdGVzOjwvZGl2PjxkaXYgY2xhc3M9
ImdtYWlsX3F1b3RlIiBkaXI9ImF1dG8iPjxicj48YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0
eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n
LWxlZnQ6MWV4Ij5UaGUgcHJhY3RpY2FsIHByb2JsZW0gd2l0aCBGcm9tOiBmaWVsZCBtdW5naW5n
IGJ5IE1MTXMgdGhhdCBhcmUgPGJyPm90aGVyd2lzZSB0cnlpbmcgdG8gcmVsYXkgYSBsYXJnZWx5
LXVubW9kaWZpZWQgbWVzc2FnZXMsIGlzIHRoYXQgdGhleSA8YnI+ZWZmZWN0aXZlIGRlc3Ryb3kg
YXV0aG9yIGluZm9ybWF0aW9uLCBieSBwdXR0aW5nIGluIGEgZGlmZmVyZW50IGVtYWlsIDxicj5h
ZGRyZXNzLjxicj4mbmJzcDs8YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjxkaXYgZGlyPSJh
dXRvIj5UaGlzIGlzIGhlbHBmdWwgZm9yIGlkZW50aWZ5aW5nIHRoZSB0aHJlZSBrZXkgc3Rha2Vo
b2xkZXIgbmVlZHM6PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0
byI+MSkgTUxNJ3Mgc3VjaCBhcyBJRVRGIHdhbnQgdG8gYWx0ZXIgdGhlIGF1dGhvcidzIHN1Ym1p
c3Npb24uJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRp
cj0iYXV0byI+MikgQXV0aG9ycyBsaWtlIEhlY3RvciB3YW50IHRoZWlyIHN1Ym1pc3Npb24gbGVm
dCB1bm1vZGlmaWVkPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0
byI+MykgVXNlcnMgbGlrZSBEYXZlIHdhbnQgYWNjdXJhdGUgYXV0aG9yIGluZm9ybWF0aW9uIGlu
IHRoZSBNVUEuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+
PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGVyZSBpcyBubyBsZWdhbCBjb3JvbGxhcnkgZm9y
ICJsYXJnZWx5LXVubW9kaWZpZWQiLiZuYnNwOyBJZiBJIHVzZSB3aGl0ZW91dCBvbiBhIHNpZ25l
ZCBkb2N1bWVudCwgc3BpbGwgYW4gaW5rIGJvdHRsZSBvbiBoYWxsZiBvZiB0aGUgc2lnbmF0dXJl
LCBvciByZXBsYWNlIHRoZSBzcGVjaWFsIGxhd3llci1vbmx5IHN0YXBsZXMgd2l0aCBzdGFuZGFy
ZCBzdGFwbGVzLCB0aGUgZG9jdW1lbnQgY2Vhc2VzIHRvIGJlIHRydXN0ZWQgYW5kIGlzIHByb2Jh
Ymx5IHVuZW5mb3JjYWJsZS4mbmJzcDsgJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48
L2Rpdj48ZGl2IGRpcj0iYXV0byI+VGhlIG5hdHVyZSBvZiB0aGUgY2hhbmdlcyBtYWRlIGJ5IHRo
ZSBJRVRGIG1haWxpbmcgbGlzdCByZW5kZXJzIHRoZSByZXZlcnNlIHRyYW5zZm9ybWF0aW9uIGlt
cG9zc2libGUsIHNvIHRoZXJlIGlzIG5vIHdheSB0byB2YWxpZGF0ZSB0aGUgdHJhbnNmb3JtZWQg
ZG9jdW1lbnQgYWdhaW5zdCB0aGUgb3JpZ2luYWwgdW5sZXNzIHRoZSBvcmlnaW5hbCBpcyBvYnRh
aW5lZCwgeWV0IHRoZSBwdXJwb3NlIG9mIHRoZSB0cmFuc2Zvcm1hdGlpbiBpcyB0byBoaWRlIHRo
ZSBvcmlnaW5hbC4mbmJzcDsgQSByZWFsIHNvbHV0aW9uIGhhcyB0byBlbGltaW5hdGUgdGhpcyBv
cGVyYXRpb24uJm5ic3A7IEhlY3RvciBpcyByaWdodC48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJy
PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5NTE1zIGNvdWxkIGNvbXBhcmUgYSBzdWJtaXNzaW9uIGFn
YWluc3QgdGhlaXIgc2NyZWVuaW5nIGNyaXRlcmlhIGFuZCByZWplY3Qgc3VibWlzc2lvbnMgcmF0
aGVyIHRoYW4gdHJhbnNmb3JtaW5nIHRoZW0uJm5ic3A7ICZuYnNwO0lFVEYgd2FudHMgdGV4dC1v
bmx5IHN1Ym5pc3Npb25zLiZuYnNwOyBXaHkgbm90IHNpbXBseSByZXF1aXJlIHRleHQtb25seT8m
bmJzcDsgJm5ic3A7QmVjYXVzZSB3ZSBoYXZlIGEgTVVBIHByb2JsZW06Jm5ic3A7IFNvbWUgTVVB
cywgaW5jbHVkaW5nIHRoZSBvbmUgSSBhbSB1c2luZywgZG8gbm90IHByb3ZpZGUgYW4gb3B0aW9u
IGZvciBzZW5kaW5nIHRleHQgb24gbHkuJm5ic3A7ICZuYnNwO0ZpeCB0YmUgc3VibWl0dGVyIE1V
QSBhbmQgeW91IGVsaW1pbmF0ZSB0aGUgbmVlZCBmb3IgTUxNIHJlYXV0aG9yaW5nLjwvZGl2Pjxk
aXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlRoZSByZWNpcGllbnQgbmVl
ZCBpcyBpcm9uaWMuJm5ic3A7ICZuYnNwO1dlIGhhdmUgZXN0YWJsaXNoZWQgdGhhdCB0aGUgTVVB
J3MgaGFuZGxpbmcgb2YgRnJvbSBpcyB1bmltcG9ydGFudCBhcyBpdCBoYXMgbm8gZWZmZWN0IG9u
IHVzZXIgYmVoYXZpb3IsIGFuZCBEYXZlIGhhcyBiZWVuIGZvcmNlZnVsIG9uIHRoaXMgcG9pbnQu
Jm5ic3A7ICZuYnNwO0J1dCBub3cgRGF2ZSBhbmQgb3RoZXJzIGFyZ3VlIHRoYXQgRnJvbSByZXdy
aXRlIGlzIGEgcHJvYmxlbSBiZWNhdXNlIGl0IHJlZHVjZXMgdGhlIHVzYWJpbGl0eSBvZiB0aGUg
TVVBLiZuYnNwOyBUaGUgdHdvIHBvc2l0aW9ucyBuZWVkIHRvIGJlIHJlY29uY2lsZWQuPC9kaXY+
PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+SG93ZXZlciwgdGhlIHVw
c2hvdCBvZiB0aGlzIGlzc3VlIGlzIHRoYXQgRnJvbSByZXdyaXRlIGNyZWF0ZXMgYSBNVUEgcHJv
YmxlbSBhbmQgaXQgY2FuIGJlIHNvbHZlZCB3aXRoIE1VQSBjaGFuZ2VzLiBJIGhhdmUgcHJldmlv
dXNseSByZXBvcnRlZCB0aGF0IG15IDMgTVVBcyBwcmVzZW50IHRoZSBJRVRGIGhlYWRlciBpbmZv
cm1hdGlvbiBpbiAzIGRpZmZlcmVudCB3YXlzLiZuYnNwOyBUaGlzIGlzIHJpcGUgZm9yIHN0YW5k
YWRpemF0aW9uLCBhbmQgdGhlIGhlYWRlciByZXdyaXRlIG9iamVjdGlvbiBjYW4gYmUgYWRkcmVz
c2VkIGR1cmluZyB0aGF0IHByb2Nlc3MuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48
ZGl2IGRpcj0iYXV0byI+U28gd2UgaGF2ZSB0d28gTVVBIHByb2JsZW1zLiZuYnNwOyBGaXhpbmcg
dGhlIGxhdHRlciBvbmUgcHJvdmlkZXMgYSBxdWljayBmaXggd2hpbGUgaGVhZGVyIHJld3JpdGUg
Y29udGludWVzLiZuYnNwOyAmbmJzcDtGaXhpbmcgdGhlIGZvcm1lciBvbmUgYW5kIGNoYW5naW5n
IE1MTSBiZWhhdmlvciB3aWxsIHRha2UgYSBsaXR0bGUgbG9uZ2VyLCBidXQgcHJvdmlkZXMgYSBo
aWdoLWludGVncml0eSBlbmQgcmVzdWx0IG92ZXIgdGltZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+
PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JRVRGIGFsc28gYXBwbGllcyBTdWJqZWN0IHRhZ2dp
bmcsIHdoaWNoIGJyZWFrcyBES0lNIHNpZ25hdHVyZXMuJm5ic3A7IFRoZXJlIGFyZSBhbHRldG5h
dGl2ZXMgZm9yIHRoaXMgYXMgd2VsbCwgbGFyZ2VseSBpbnZvbHZpbmcgTVVBIHR3ZWFrcy48L2Rp
dj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5ERjwvZGl2PjxkaXYg
Y2xhc3M9ImdtYWlsX2V4dHJhIiBkaXI9ImF1dG8iPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIiBk
aXI9ImF1dG8iPjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu
OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjwvYmxvY2tx
dW90ZT48L2Rpdj48L2Rpdj48L2Rpdj4=


From nobody Sun Jun 21 16:35:17 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D576B3A0813 for ; Sun, 21 Jun 2020 16:35:13 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uYUa4mm72Jiz for ; Sun, 21 Jun 2020 16:35:12 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 C17423A0812 for ; Sun, 21 Jun 2020 16:35:12 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id r1so5009148uam.6 for ; Sun, 21 Jun 2020 16:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pb6/+ipJ5ChNoKaGrO0LXsp+m+twihK6MWQgFIuk4Og=; b=O1M4qFGc1huPanam8IyJ94wDD1Xd6I4aRmUFEaGIs0DbQYPqgvQLe7XsBlaPWBDqIV 2aobAWjzQPdCyvo4f44VkBI+bgTymrv5RmWb+DTF9QoYewV3JeepStzeCePX9DzPgTfj pyl+2qwBuSGXkzRoAeczo8lS0BzNXPHwFXcJSPuPfpLoyMMyIUG3yzdVhib7Ksn8i/kI zOBx5oorZLo0KSpBE/7uDvIUgqRBBg37wQsg8vO1WEfdQbMAD7JxvmbzoLExUV9N9XcP 86+NKau/a7jJDRZ5MB7/2T/da1tVOjfO0wazjW5QGpz5nH+BRBR5+uMlOd/FD+BpmOkR Mghw==
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=pb6/+ipJ5ChNoKaGrO0LXsp+m+twihK6MWQgFIuk4Og=; b=leE0esdxgAQvthEh4h5iMiegFrb+I0phlMS8vKZYkD4HD7McZLs+rmEeb3lcliE9Dx Vycnb33kLS+FPQ5jZluDsJ3dEmNH65BCvDQ4TWsONPwEGx9APcQwYUMqZKOi8UHDmgfF 9SQ81FhxKOBh8SA+K3L7asJk0JPkm4AlBq4NUVtADeeXM4kd4aDlnzcNevU/GgoQYkVs u62Z6J/CB/zusfjfXHDU+GePPh+D6KiZeo1ZlZ89ci6B23iRlAULL6hI3wmRQLKxUZ19 yDZ+jVPdk+G+CZxiN6l1tzl3Hh1Anf3BbONAlBx31ewIjmYit3HfEUeEcaROw/URZOUW dkSQ==
X-Gm-Message-State: AOAM530QXuWIorfjaik3vQ+Q9a4MxJLy2WjkthdOXH3MN1hqSV1aBH1c UdBHK4mm2sh1Yzmxy5rEZD33Hc6a7cI/BbFF8eM=
X-Google-Smtp-Source: ABdhPJy1LrC4GRTCeSMT5ltAzt04T8Dso4SigkD9le1vUGRtagfKHa1wVeEqmAOPEAV4LoH8jErclPGe968wBiV4nZg=
X-Received: by 2002:ab0:21c5:: with SMTP id u5mr9654140uan.101.1592782511729;  Sun, 21 Jun 2020 16:35:11 -0700 (PDT)
MIME-Version: 1.0
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>  <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com>  
In-Reply-To: 
From: "Murray S. Kucherawy" 
Date: Sun, 21 Jun 2020 16:35:00 -0700
Message-ID: 
To: Dave Crocker 
Cc: IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jun 2020 23:35:14 -0000

On Sat, Jun 20, 2020 at 1:24 PM Dave Crocker  wrote:
> Perhaps if the effort were viewed as a staged sequence, over an extended time.  Staging along the lines of:
>
> Document a modest number of highly common 'patterns' of mailing list patterns.
> * Get reasonable community support (rough consensus) for the document -- including from MLM developers and operators
> * Formulate survivable authentication choices
> * Get reasonable community support for that approach

I'm curious enough (and have been since the discussions that led to
draft-kucherawy-dkim-transform-00 five years ago) to give this effort
some energy orthogonal to what this working group is doing, and with
minimum distraction.

Apart from Mailman, what would be a reasonable set of MLMs to
approach?  I don't need a universal set here, just enough to get us to
at least what we are pretty sure would be 80% or better of the active
modern use cases.

Armed with such a list and a plan, I can see what the IRTF Chair
thinks of the idea.

-MSK


From nobody Sun Jun 21 16:41:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABA3A0835 for ; Sun, 21 Jun 2020 16:41:01 -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, FREEMAIL_FROM=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=gmail.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 VCbO0TgtaqeT for ; Sun, 21 Jun 2020 16:41:00 -0700 (PDT)
Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 3037D3A082F for ; Sun, 21 Jun 2020 16:41:00 -0700 (PDT)
Received: by mail-oo1-xc31.google.com with SMTP id e8so2991375ooi.11 for ; Sun, 21 Jun 2020 16:41:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=J12hNW2ZfG6eehFVIqWJ11ONeWUCUn6WMiX8CIQgYv4=; b=uDkFw4K3BBuFueAZ17xTuy/JbzmFjpQKeKlvabsLrKJSwqHQ2sj6f/qSYTeNlUIKxD ynHaiTlcYLxgFWbhBPs6/BMyRd0TFQFVTaay4AshZKpcQfonRT2kfXZbwGkzBHSadiqw CNdm5eHHaWp4zNEczplGm3wMLTTT6i5WeGAd+XovIdOED7r7NrmDEymxdYBj/BMSXWXy bWAJP0FEyxk58BtThvXQaVQIUpDoFwP5Qnp7cvWNge/BpgB8Tdegpiv8e20VGGzaLk9n /yx2k1DXob3f7+sUkdJGvynYMZUME3LAi8iErDcaCdrXJEkjOkSsys6CRwDzTggLC0y2 p0dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=J12hNW2ZfG6eehFVIqWJ11ONeWUCUn6WMiX8CIQgYv4=; b=fvy4K8u/2kfXT826pXIgSwKbdKJ/zP9z2IGzVgYWl/GX7TZII2WPhvRiOEwJUb2O4n CPqAWfY6prJvvgI7c5fo01MWOT+NBx36spMMzSraKJLJh7MP+t6qHXnSyAcayIcMmNGG ekvSmlWgEpzocGh3nh3oxqIiL8XTvXSRfoXNFDlhasohAEMT3i3kBntYOxKKS+EzRmG+ +eWtqBbhc7qvUkp8aJbTI4H6otSd0jN3bNq8lZGpt6kCwjKlc7MALvBs1hUKlx4kKZzE qFR5Cr7gLn9rkdcsHIgjf83fJenoGHO7Jp5tzhEc8Xb9dDu4iDyHAQorTfk3icvYsepI 1VUw==
X-Gm-Message-State: AOAM530CrD7ZhU9QloSED/Tl0cjyEWNc5MYNL4LkD+ZsER6pkHaxkIWB UFcmt5iAEnGSWmKhSycMVydGNI44
X-Google-Smtp-Source: ABdhPJzXmwrcJJh+lcrU6hvAcBxalIfJKa1EoiKdhHnmPVXEwMxg0CaRMjHRYZtrjXXRGbJ6fNUODQ==
X-Received: by 2002:a4a:e049:: with SMTP id v9mr12097481oos.22.1592782859166;  Sun, 21 Jun 2020 16:40:59 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:94c1:b41a:9f34:3d23? ([2600:1700:a3a0:4c80:94c1:b41a:9f34:3d23]) by smtp.gmail.com with ESMTPSA id e188sm2915552oib.18.2020.06.21.16.40.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jun 2020 16:40:58 -0700 (PDT)
To: "Murray S. Kucherawy" 
Cc: IETF DMARC WG 
References: <3efe1445-4a58-cdf2-9c06-d8ffb3ce1c6c@gmail.com> <20200620000902.2AC2E1B389B6@ary.qy>  <1e9df930-0422-5358-8a72-2500dfaa2dcf@gmail.com>   
From: Dave Crocker 
Message-ID: 
Date: Sun, 21 Jun 2020 16:40:57 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jun 2020 23:41:01 -0000

On 6/21/2020 4:35 PM, Murray S. Kucherawy wrote:
> Armed with such a list and a plan, I can see what the IRTF Chair
> thinks of the idea.

cool!

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Sun Jun 21 18:07:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB93A083B for ; Sun, 21 Jun 2020 18:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=hTHLJ4l7; dkim=pass (1536-bit key) header.d=taugh.com header.b=PxM0crXG
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 Q1AKyEF8MiP6 for ; Sun, 21 Jun 2020 18:07:28 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 385823A0828 for ; Sun, 21 Jun 2020 18:07:27 -0700 (PDT)
Received: (qmail 56430 invoked from network); 22 Jun 2020 01:07:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dc6c.5ef0044e.k2006; bh=SQzB6k3ogWtplLkYNBwm7yXwvHY9hymp5ny/Dm+sAUc=; b=hTHLJ4l79E0y9pEFczj76OIVMx2TgA712TL4v2XEmF7580icSdTDcjGXHpnz/gL2ihOUllt0bGdOqa0PdI9PLvilm01C6AESOuHCzW7MXG3Iy/xtBupG0CLRSHKGAVEdTUCvnuc6RjwVK/2eG4GjG8LEnS2QDdnFIlVJHJlmd8l2YQLaD2DM/n8IEHM+xldszrXa07IQerOk3ulOJdUEWh0hE9wCW0bi7/WpmkZJnwg2hTA+8coPRfj+RRvlglGK
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dc6c.5ef0044e.k2006; bh=SQzB6k3ogWtplLkYNBwm7yXwvHY9hymp5ny/Dm+sAUc=; b=PxM0crXG16LafS56w+yvZ1/3M3kYjAQJJqtKQTqDzfpcjLMGiHBz0jH80KlBN0SRhFRVC6/sSlxWNlRqpdvONtLqo2TNZVPo9LrX/d2xpKu6riQsjVZev1b+KHSX1czKItfNv3bhG1UKFwhtv/JaYiDpzjZX2Np7dEmaUKW7spOZgtr5JFKOapfq5QqWyv1cZKmA1UX3eJsEczXZadATPap1nqq3h6OHioXoh/fkNNo+uR//elzLSi4/OJ595Waz
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 22 Jun 2020 01:07:25 -0000
Received: by ary.qy (Postfix, from userid 501) id F224B1B4CE70; Sun, 21 Jun 2020 21:07:25 -0400 (EDT)
Date: 21 Jun 2020 21:07:25 -0400
Message-Id: <20200622010725.F224B1B4CE70@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: superuser@gmail.com
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 01:07:30 -0000

In article  you write:
>Apart from Mailman, what would be a reasonable set of MLMs to
>approach?  I don't need a universal set here, just enough to get us to
>at least what we are pretty sure would be 80% or better of the active
>modern use cases.

Mailman and Sympa seem to tbe the popular open source list managers.

LISTSERV is an expensive commercial product and is I gather popular
among users who have money to pay for an SLA.


From nobody Sun Jun 21 18:21:46 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1A3A085A for ; Sun, 21 Jun 2020 18:21:44 -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, FREEMAIL_FROM=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=gmail.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 KCgESd_52gI3 for ; Sun, 21 Jun 2020 18:21:43 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 E7F883A0859 for ; Sun, 21 Jun 2020 18:21:42 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id y123so8707238vsb.6 for ; Sun, 21 Jun 2020 18:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q0ZpLukl85MOHDdBZAzfFIp+Q28DO6jkqv0hVNppDkc=; b=Wea+7UXHrCn9x9yxdWtweec3S/x94p4TNmurwHb5eSnNJFI4yjrU5FPyhqdeUcvS4x 8HdN7dIn2VHB7hvBSTgwYDOBo6qr+9QGxFTn/3lc8L2QB3O7rF7uA1+uxnzwlncoupwM Zqt3j7EoUHCreGlu03lXoncfgfGvlSrygpTojUObZW8lbrWvUObJbPb+8M2A+hlfizlw 4NKj0Y62q97Z/TmwXdZVzrfQ/c7ggmUXdc5cJmWoFKNlwK764EWS+1hAcSUowtJy431t vXZx73OAGt5t4744M631xirnfGiD9+9GDuf97G7q8ts983pXGpFzFc/KG5MkXtKCCtbh xxzQ==
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=Q0ZpLukl85MOHDdBZAzfFIp+Q28DO6jkqv0hVNppDkc=; b=GgX5XDMlwnLSoXxDI1O7TyZI4D86ovTuYn2cZC3Sdm7vISyW9b4F/XD5tHReb7tjEy jO2IQk1kLu17dJtLihQqKr9ET4xyOnTftDIWkZ6slzxS+XcFOLQHaL0njGpO8sGqoOqw L0PRavzthw2hSNRc9KLLW/67HvElOd5cu9OpYvhOvRHRLYpzFDOL0ObMiL1/VQmbSUcp 8i2po84PbvmoXZglfQwp5iF9R6PQpwOmtIDBlnGDQ6acVAl+jBG2YOGk81KDoLttNzoR my1wD/JKaZagUSWI/mFhM8d9zOXRzlk+U6HYUTrUJ4xl1VZcCKxZLdjsrBOi6BruPaZa vkaQ==
X-Gm-Message-State: AOAM531sqroCsm0aSqttSjJvt3D7rA+iVprnxAIpr4BsdzPwiNIeUMo8 b5ekJFLMspuysf7TC5Va2kQUQXoueIqFuR6vPKc=
X-Google-Smtp-Source: ABdhPJxlUbl4TZWa2Jkgc6U+rk0cFIawUs17/Cmy6ShhP91Z3yJkeeg17lIdcVHj7j/jrEf7l6R8OjjEl6Ku30ru0Us=
X-Received: by 2002:a67:ed15:: with SMTP id l21mr14865728vsp.175.1592788901822;  Sun, 21 Jun 2020 18:21:41 -0700 (PDT)
MIME-Version: 1.0
References:  <20200622010725.F224B1B4CE70@ary.qy>
In-Reply-To: <20200622010725.F224B1B4CE70@ary.qy>
From: "Murray S. Kucherawy" 
Date: Sun, 21 Jun 2020 18:21:29 -0700
Message-ID: 
To: John Levine 
Cc: IETF DMARC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 01:21:44 -0000

On Sun, Jun 21, 2020 at 6:07 PM John Levine  wrote:
> In article  you write:
> >Apart from Mailman, what would be a reasonable set of MLMs to
> >approach?  I don't need a universal set here, just enough to get us to
> >at least what we are pretty sure would be 80% or better of the active
> >modern use cases.
>
> Mailman and Sympa seem to tbe the popular open source list managers.
>
> LISTSERV is an expensive commercial product and is I gather popular
> among users who have money to pay for an SLA.

Thanks, I've reached out to all three and will report back.

-MSK


From nobody Mon Jun 22 04:24:17 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3E3A0C11 for ; Mon, 22 Jun 2020 04:24:08 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 FmETtqcsBXC6 for ; Mon, 22 Jun 2020 04:24:07 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 9DDCB3A0C30 for ; Mon, 22 Jun 2020 04:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1592825041; bh=hrde7lx8EM6UqzKEkC4s/Ngird4+SV1/MpsjU2LjUXg=; l=8361; h=To:References:From:Date:In-Reply-To; b=CPX1ElE9DbLS63dxaXKuUIVHOWR8YkLETrqwmiiwA/8kUA7l2DXcEvObZ9sTHLM/Z V+RLVuiF9w67DzM1SvqktsLs2gqEa7l5hzF5rQQpodoTZSHOFvAtUGEevg4GFR59iw CTkZngVKEXprmmNNKy+atRKO1P742jbFx7L7u8VCxutQCBrfJHmyb8EToCfw3
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.170.193.100]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EF094D1.00000885; Mon, 22 Jun 2020 13:24:00 +0200
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>
From: Alessandro Vesely 
Message-ID: <27a30b41-220f-0dbf-c33e-e23d2fc36bae@tana.it>
Date: Mon, 22 Jun 2020 13:23:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 11:24:16 -0000

On 2020-06-21 7:32 p.m., Dave Crocker wrote:
> On 6/18/2020 12:46 AM, Alessandro Vesely wrote:
>> "Authoring" can have subtly different acceptations, though.  The
>> exact sentence is:
>>
>>              The "From:" field specifies the author(s) of the message,
>>    that is, the mailbox(es) of the person(s) or system(s) responsible
>>    for the writing of the message.
>> [https://tools.ietf.org/html/rfc5322#section-3.6.2]
>>
>> That is not so far from real.  The term "writing" sounds ambiguous,
>> as it is not clear whether it means "typing" or "publishing", in the
>> case of public mailing lists.  Given that Sender: is dedicated to
>> the typist, I'd opt for the latter interpretation.
> 
> In simple terms, author is the creator of the content and sender is
> the agent for getting the content processed.  The latter was
> distinguished to provide a means of improving accountability if there
> were problems.  When SMTP was created, later, MailFrom was added as an
> address for sending message handling reports.
> 
> When first specified, Sender: was to cover the case of someone doing
> the online work, on behalf of  authors who weren't online, or at least
> not online for processing the message.  Back in those days, that was
> not uncommon.  Even if the author officially had an online presence,
> they often did not do the typing.
> 
> (To underscore this a bit: in most of the business world, knowing how
> to type was deemed a menial, secretarial skill and not appropriate for
> an executive. To carry this a bit further: around the time RFC733 was
> developed, in 1977, I managed to get the person in charge of
> department administration functions to authorize my getting a desk
> with a right-hand return, where a secretary's typewriter would go, and
> where I put my terminal. This was extremely unusual and the immediate,
> similar requests from all the other staff like me were rejected. Also,
> when I announced my departure, the next year, the admin was instantly
> flooded with requests for my desk...)


Thank you for sharing the above historic perspective.


> [...]
> 
> So, in abstract terms, if I go to a greeting card site and have it
> send a greeting on my behalf, the From: field should be my own email
> address and Sender: should an address at the greeting card company. 
> But I said 'abstract' because current realities mean this isn't as
> useful an arrangement as the theory intended.


Agreed.  I'd derive it's time to revise the theory, however slightly.


> I believe this is because Sender: is not reliably present. Hence, it
> literally cannot be relied upon.  The Sender field is not created
> reliably to indicate such distinctions and the receive side does not
> reliable note the distinctions.


The fact that it cannot be set by a MUA implies Sender: already lost
its menial meaning.  So it became a Mediator sort of thing.  This list
sets it to "dmarc" .  Does anybody use it, or
ever happened o take a look at it?

See below for an alternative arrangement.


>> For a newspaper, if you pardon the analogy, the masthead is more
>> visible than columnist signatures at the end of the articles.  For a
>> mailing list, publisher visibility used to be provided by subject
>> tags, leaving the From: intact.  Why?  Presumably, because it just
>> worked that way.  However, if the MLM is the system responsible for
>> writing, not modifying From: should be considered a violation.
> 
> If a Mediator makes 'substantial' changes to a message, then it can be
> considered a new and different message?  Yes, but note that we have no
> objective criteria for this.  That's why I class this reference to
> 'publisher' as a business issue rather than a technical one.  (And an
> ethical one, as some wayward journalists discover when they claim to
> be quoting someone but it turns out the reporter invented the content.)


You certainly recall the level of sophistication described in Nelson's
Literary Machines.  Email is nowhere near that precision, therefore we
/have/ to relegate such issues to ethical or business ones.

As you say, an add-on to check quotation authenticity would require
access to the whole thread, and even then it wouldn't be trivial to
get it done.


> However I think that referencing the role of an MLM as 'publisher' can
> be helpful to remind us that MLMs have their own agency and can,
> legitimately, make all sorts of changes.  Whether authors and
> recipients like those changes is a non-technical matter.
> 
> The practical problem with From: field munging by MLMs that are
> otherwise trying to relay a largely-unmodified messages, is that they
> effective destroy author information, by putting in a different email
> address.
> 
> In practical terms, today, the MLMs arguably don't have a choice.  But
> it still can be helpful to understand the problems created by this
> alternation.


IMHO, the choice is how to do rewriting given the constraint that the
domain of From:'s addr-spec must match d= in MLM's signature.


>>> My understanding of the meaning that DMARC added was, "The
>>> author of this message, as expressed in the From: field, always
>>> has their messages properly signed by the domain in the From:
>>> address." You seem to be saying that, no, what DMARC did was
>>> changed the semantic to be, "The From: field now represents the
>>> transmitter of the message (as used to be expressed in the 
>>> Sender: field when present), not the author, and that
>>> transmitter always has their messages properly signed by the
>>> domain in the From: address".>
> For reference, I consider this an accurate summary of why I say that
> the From: field semantic is changed as a result of DMARC. Specifically
> so that mailing list mail can be delivered.


Yes.


>> Sender: was not meant to be the transmitter in that sense.  It was
>> meant to be the secretary who writes on behalf of a responsible
>> person or system.
> RFC 5322 has preserved the semantic of the Sender: field:
> 
>      "The "Sender:" field specifies the mailbox of the agent
> responsible for the actual transmission of the message. "
> 
> I consider that to be exactly the role the MLM is performing.


Sender ID already tried that path.  It didn't work.  Why insist?

For the rationale, that quoted sentence of RFC 5322 is followed by an
example which doesn't seem to match a Mediator role.  Why not use the
Resent-From: field and its companions instead?


>> RFC 5322 says display names are "associated" to a mailbox.
> 
> I don't see such language in RFC 5322.  In fact, other than the ABNF
> for display-name, I don't see any explanation of its semantic.


    Note: Some legacy implementations used the simple form where the
    addr-spec appears without the angle brackets, but included the
    name of the recipient in parentheses as a comment following the
    addr-spec.  Since the meaning of the information in a comment is
    unspecified, implementations SHOULD use the full name-addr form of
    the mailbox, instead of the legacy form, to specify the display
    name *associated* with a mailbox.  Also, because some legacy
    implementations interpret the comment, comments generally SHOULD
    NOT be used in address fields to avoid confusing such
    implementations.
                    [https://tools.ietf.org/html/rfc5322#section-3.4]
                    [(my emphasis)]


>> Certainly, changing just the addr-spec breaks the association and
>> wreaks havoc to address books. 
> 
> Exactly.


Here's an alternative arrangement for the fields:

An author composes a message and submits it to the MLM.  The publisher
can accept it or not.  It's their business policy whether to moderate,
blindly trust (some) authors, or whatever.  If they accept the
article, then they send it back to the author, accompanied by the
MLM's marks of acceptance for publication.  Hence, From: the MLM, To:
the author, Bcc: the rest of subscribers.

That arrangement saves the association and the ability to reply all.

There is an unusual MLM option to individually send messages To: each
recipient, which neither supports the above arrangement nor advanced
sending schemes, such as Courier-MTA's VERP SMTP extension.


Best
Ale
-- 






















From nobody Mon Jun 22 08:48:18 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43A3A0DE9 for ; Mon, 22 Jun 2020 08:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=WtpkPsl9; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=q90tu771
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 Bx--vjvv1K4Q for ; Mon, 22 Jun 2020 08:48:13 -0700 (PDT)
Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 A1E6D3A0DE7 for ; Mon, 22 Jun 2020 08:48:13 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2969; t=1592840886; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=0aAfQD87sf13GW+eewmq+Jzu/oM=; b=WtpkPsl9652ZHBDCbZMrxEoCJPRCrHInrOsOyV1s8DtaY8SUSalhzuhufWgZn9 Lq6uPklTYbpTfj1BfQa1F6WNJAlNob6noreF3uNEGfYVg335HR+qRWINl7tnLe3T gpbe3BFQFBfq0PjDxNiTcuMHAFGl12bBmzDzhQcd/h1Rg=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 22 Jun 2020 11:48:06 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3568181521.1.7156; Mon, 22 Jun 2020 11:48:05 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2969; t=1592840834; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OECijOQ FflFwwe7jxtKKStysVd7SmVQcxhKXmutE378=; b=q90tu771W9D0TCmSwqmb1fN NtdgKDjDZFK1Yxgg4a4N/i6FRVN44jfy29eOMg8GIzqzNONh6GG5KPZgcn2vjCPf AeGOmgCxe3oa5Xat/9+potTxRMXjV8JvHLzHfkv6jhnWpOhHsJQ2wRHEZ7g0eHXL 7ZSjFKvawgplpOwsDljA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 22 Jun 2020 11:47:14 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 279562329.1.49932; Mon, 22 Jun 2020 11:47:13 -0400
Message-ID: <5EF0D2B4.2080901@isdg.net>
Date: Mon, 22 Jun 2020 11:48:04 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References:  <20200622010725.F224B1B4CE70@ary.qy> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 15:48:17 -0000

>> Mailman and Sympa seem to tbe the popular open source list managers.
>>
>> LISTSERV is an expensive commercial product and is I gather popular
>> among users who have money to pay for an SLA.
>
> Thanks, I've reached out to all three and will report back.


This exchange does not read right.

Decisions like this should not be made on the basis of open source, 
nor commercial.  The magical Pareto margin with just those three 
mentioned may not be reached. There are others out there that may not 
be represented in this group, and there are those like my own 
commercial add-on product line, Wildcat! List Server, which does come 
with an optional SLA and it should not matter if it does or not, a 
smaller entity but has been "around" far longer than most except ListServ?

https://secure.santronics.com/products/winserver/wcListServer.php

I provided a guideline to a MLS approach back in the 2006 DSAP proposal:

https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DKIM signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

I have since then employed a very simple first item, Prevent 
Subscription, added preventing submissions from restrictive domains 
and avoided the more complex, integrity change part.

I understand there are those who want to bypass the DKIM Policy 
security to be able to blindly resign any domain regardless of the 
submission's direct mail policy. But my take is, if a MLS is going to 
"change" then we should recommend to consider the preemption approach 
by simply honoring the policy.

I hope to read from the report those 3 packages are willing to offer 
the option to prevent restrictive domains. Even if rewriting remains 
as an IETF "sanctioned" option (I hope not), the recommendation should 
suggest a SHOULD to incorporate it as an authorized permission concept 
with the subscriber:

Your domain has a restrictive DMARC policy. Here are your options:

1) Use another non-restrictive domain,
2) Prevent your domain from subscription and submission, or
3) Authorize the Rewriting of your secured domain to a secured 
resigner domain.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Mon Jun 22 11:05:11 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBE3A0CD6 for ; Mon, 22 Jun 2020 05:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 CaUBUbymZ-EQ for ; Mon, 22 Jun 2020 05:54:29 -0700 (PDT)
Received: from www210.your-server.de (www210.your-server.de [78.46.0.150]) (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 922F33A0C29 for ; Mon, 22 Jun 2020 05:54:29 -0700 (PDT)
Received: from sslproxy06.your-server.de ([78.46.172.3]) by www210.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jnLxy-0004Rt-Tb for dmarc@ietf.org; Mon, 22 Jun 2020 14:54:27 +0200
Received: from [109.190.207.208] (helo=[192.168.1.60]) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnLxy-000Euw-OQ for dmarc@ietf.org; Mon, 22 Jun 2020 14:54:26 +0200
To: dmarc@ietf.org
References: 
From: devel2020@baptiste-carvello.net
Message-ID: <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net>
Date: Mon, 22 Jun 2020 14:53:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: 8bit
X-Authenticated-Sender: webmaster@baptiste-carvello.net
X-Virus-Scanned: Clear (ClamAV 0.102.3/25850/Sun Jun 21 15:07:54 2020)
Archived-At: 
X-Mailman-Approved-At: Mon, 22 Jun 2020 11:05:09 -0700
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 12:54:31 -0000

Hi,

Le 21/06/2020 à 21:44, Douglas E. Foster a écrit :
> 
> There is no legal corollary for "largely-unmodified".  [...]

Then what? An overwhelming majority of users need e-mail for day-to-day
communication, not for binding legal contracts. "Largely-unmodified" as
mailing-lists have been doing it for 40 years is good enough (we usually
don't hear authors complaining that they were impersonated).

People who need a high-integrity validation for each and every message
before reading it are the minority. The rest of us would rather keep our
communication possibilities unimpaired, even if it means dealing with a
bit of spam and use cryptography or out-of-band checks for important
business.

Not to say that DMARC's validation is not valuable per se. But asking
mailing-list (or other) users to jump through hoops to simply
communicate as they have for 40 years is incredibly arrogant.

Cheers,
Baptiste

P.S.: and no, "then don't use DMARC" cannot be the answer. Some time
down the road, it will be forced on us by the large mailhosts, who have
a business interest in curbing spam. So it'd better be done right.


From nobody Mon Jun 22 11:49:57 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2C3A07BB for ; Mon, 22 Jun 2020 11:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Vg3gL7V1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=jitHT68D
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 PQzBYhwuWtIM for ; Mon, 22 Jun 2020 11:49:54 -0700 (PDT)
Received: from mail.winserver.com (listserv.winserver.com [76.245.57.69]) (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 721583A07BC for ; Mon, 22 Jun 2020 11:49:53 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3276; t=1592851791; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=QaCMruAfDhCNk26iZLkac6V41d0=; b=Vg3gL7V1xAKoIpHeTjYv1S3PTkgsEyeb9bH//RHrm0IhI1g0mC3gbdhbyBK1N8 HHJ6R3u+9BEeBZr1d3GOZY+ntz0gLvSuqLI4x5CMW8IF3FlcNXaNN1iRmN6r3Ad0 lR0vLhm17n47DJbOY/2MzxYgLvas9gBGF4kpzTjWxVk+c=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 22 Jun 2020 14:49:51 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3579086725.1.1144; Mon, 22 Jun 2020 14:49:50 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3276; t=1592851738; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=I+6ZMUp 1nzlXO3C+vtRs5dQ1iRR7tbG8pwqy8LECiHU=; b=jitHT68De8cYmOetIgbhfvu Oqlem02+eihQjw8yZdSQVnjuFZfTvRL/0jyE1F4tOin03mYy7Pebc/wUV2UWWKBr abfuNkWwjT1ZHuOJacRKwLupKmHP9RZHyIDUeI3MDOAmbAloo3iU8Mc/EcVtPTuD Y4zM6GaxFPxrWke+dmdA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 22 Jun 2020 14:48:58 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 290466016.1.3388; Mon, 22 Jun 2020 14:48:57 -0400
Message-ID: <5EF0FD4C.6080104@isdg.net>
Date: Mon, 22 Jun 2020 14:49:48 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 18:49:57 -0000

On 6/21/2020 3:44 PM, Douglas E. Foster wrote:
> Dave Crocker writes:
>
>      The practical problem with From: field munging by MLMs that are
>      otherwise trying to relay a largely-unmodified messages, is that they
>      effective destroy author information, by putting in a different email
>      address.
>
> This is helpful for identifying the three key stakeholder needs:
>
> 1) MLM's such as IETF want to alter the author's submission.
>
> 2) Authors like Hector want their submission left unmodified

List Servers has historically modified submissions, the body and 
subject line. It is part of the "package" per se.  Burned in. While 
problematic for DKIM, I doubt that will ever change.

However, my only concern has been always with the RFC5322.From address 
rewriting kludge when done in a blind way.  If the MLM is aware of 
DMARC, then it is intentional ignorant of a security protocol. While 
it may have been done in certain legacy distributions, it was not a 
common practice for List Servers to rewrite the 822/2822/5322.From 
field. What was "rewritten" was the return address for errors & 
bouncing back to the MLM list agent.

A kludge is by definition (by Google) "an ill-assorted collection of 
parts assembled to fulfill a particular purpose."  We ideally view a 
kludge as a temporary solution until a real fix is obtained. But as we 
have learned by practice, a kludge, a temporary solution left 
unaddressed, has a tendency to become permanent. So if the IETF is 
going to sanction this kludge, then we should get it officially IETF 
reviewed, documented, and not via some highly subjective wiki 
primarily authored by one person who believed this was the right thing 
to do without foreseeing the consequences.

> 3) Users like Dave want accurate author information in the MUA.
>
> There is no legal corollary for "largely-unmodified".  If I use whiteout on a
> signed document, spill an ink bottle on hallf of the signature, or replace the
> special lawyer-only staples with standard staples, the document ceases to be
> trusted and is probably unenforcable.
>
> The nature of the changes made by the IETF mailing list renders the reverse
> transformation impossible, so there is no way to validate the transformed
> document against the original unless the original is obtained, yet the purpose
> of the transformatiin is to hide the original.  A real solution has to eliminate
> this operation.  Hector is right.

Imo, the resigner performing the rewriting, SHOULD resign using a 
secured resigner domain with the same level protection sought by the 
original author domain.

This would be consistent with the ietf.org only rewriting for domains 
with a p=reject|quarantine DMARC policy. It uses _dmarc.ietf.org for 
the rewriting domain.  Since this _dmarc.ietf.org domain only exist 
for rewriting a p=reject|quarantine domain, it would be technically 
logical for _dmarc.ietf.org to also have a p=reject|quarantine policy 
as well.   This includes using _dmarc.ietf.org for the return address 
to kept with the expected DMARC alignment. That will maintain the 
DMARC aligned protection for the original submission and resigner 
distribution.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Mon Jun 22 12:44:48 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D003A1126 for ; Mon, 22 Jun 2020 12:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Ljl2uTZIdBIa for ; Mon, 22 Jun 2020 12:44:45 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 9FF143A10D1 for ; Mon, 22 Jun 2020 12:44:45 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id o15so10318926vsp.12 for ; Mon, 22 Jun 2020 12:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2J752/ZeJp0Lznl0WBYuIP8GggjPRlVtmSFGPCq8Xqk=; b=gIQCYXDgiZhsc6z4uHWR5Co7CetHV51CYN1uMXNyq1nErQVp2+Ap2O9KwJL9bUs06s f/eYdhmDOq4fRH/pKS6cOM7LZN4Dufu4fy8TEoPxJmyJ5aLVaUSabhMOa/gZ7IamMMPJ ke/V9ji+VloS5Fadix7jsU09HxyYO1VjtPtU007xZqZM4ORVoL8/IT+A/WzUom631A2f 48+r2FB9fEF8PRYQrUUKBJwWUhkVfw+hnBSuCAXa0Cjw/2NHQDF+g+9M87PgOT6bwDdF vSx1krr/bkkEZbozjSwFze5fl4Ls6nNlJXEsvqGZyrNoRgKnXepAaUtJ3vBXDBsZTH2E fsyQ==
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=2J752/ZeJp0Lznl0WBYuIP8GggjPRlVtmSFGPCq8Xqk=; b=CqC0TZ/78FUIXdmwDDKHyLqmR+w/e5E4xu1VLyRMraY7Idtwi6MvvuRxkFCN8V4tT3 WTkGrJ7uMjasi83C2YXwOt3qO72U0WNogV1v0ZINcK8Y1dtxoBVoLEWHlZ187SeqV9V0 B0g/dgKDRFqbn/1FonCFsVdUjYTn5O0kDWdgJsai9opnsooVdDjNo+O9EAZfdUa8J5Mh DlogWRXg8HmwwS5ytNl7JdNPTbPMfln0iAPciezvwc+mKdLaW91OPdZklX66nCt/aZwH 8zn6YxYIQNi5rojtlYtJNo+y0iw1ibK0dl1ARKSuZyStXL7NumPe/rl0rK4/vWKlkz36 C78A==
X-Gm-Message-State: AOAM5308wIsFoyizKMAdQgrK1HSmAXEihAqrbg7HIDDfkTXAtj+otYoA NTzVjN91dCDpltM2b/LhlEqJ5OW/IUHektoNG0gPkk4=
X-Google-Smtp-Source: ABdhPJwh2XV5Plew9nmKrzv62e3LeEtRfYXQz6SG08MearwKsvTJL9Cw3O89ngvnGnOFOJl3lw6cjk7nISpXB7X2PK0=
X-Received: by 2002:a67:fc0b:: with SMTP id o11mr16864306vsq.114.1592855084038;  Mon, 22 Jun 2020 12:44:44 -0700 (PDT)
MIME-Version: 1.0
References:  <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net>
In-Reply-To: <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net>
From: Brandon Long 
Date: Mon, 22 Jun 2020 12:44:31 -0700
Message-ID: 
To: devel2020@baptiste-carvello.net
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000772bda05a8b179a4"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 19:44:47 -0000

--000000000000772bda05a8b179a4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 22, 2020 at 11:05 AM  wrote:

> Hi,
>
> Le 21/06/2020 =C3=A0 21:44, Douglas E. Foster a =C3=A9crit :
> >
> > There is no legal corollary for "largely-unmodified".  [...]
>
> Then what? An overwhelming majority of users need e-mail for day-to-day
> communication, not for binding legal contracts. "Largely-unmodified" as
> mailing-lists have been doing it for 40 years is good enough (we usually
> don't hear authors complaining that they were impersonated).
>
> People who need a high-integrity validation for each and every message
> before reading it are the minority. The rest of us would rather keep our
> communication possibilities unimpaired, even if it means dealing with a
> bit of spam and use cryptography or out-of-band checks for important
> business.
>

It's not a minority, it's a majority.  It's the majority which are
routinely subjected
to phishing and spam messages... or at least a large enough minority (100s
of millions?)
that to say it's not important is suspect.

There's no easy way to say "just this mail is important".

If you want a minority, that's people using mailing lists... or even people
using email instead of other messaging protocols, unfortunately.

Not to say that DMARC's validation is not valuable per se. But asking
> mailing-list (or other) users to jump through hoops to simply
> communicate as they have for 40 years is incredibly arrogant.
>

There have been a large number of changes in how email works in the last 40
years,
many things that used to work no longer do.  Open relays, anyone?

P.S.: and no, "then don't use DMARC" cannot be the answer. Some time
> down the road, it will be forced on us by the large mailhosts, who have
> a business interest in curbing spam. So it'd better be done right.
>

As opposed to the small mailhosts who love letting spam and phishing
messages
rip off their customers?

Brandon

--000000000000772bda05a8b179a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    =

    On Mon, Jun 22, 2020 at 11:05 AM <=
devel2020@baptiste-carve=
llo.net> wrote:
    Hi,
    

    
Le 21/06/2020 =C3=A0 21:44, Douglas E. Foster a =C3=A9crit=C2=A0:
    
> 
    
> There is no legal corollary for "largely-unmodified".=C2=A0 =
[...]
    

    
Then what? An overwhelming majority of users need e-mail for day-to-day
    
communication, not for binding legal contracts. "Largely-unmodified&qu=
ot; as
    
mailing-lists have been doing it for 40 years is good enough (we usually
don't hear authors complaining that they were impersonated).
    

    
People who need a high-integrity validation for each and every message
    
before reading it are the minority. The rest of us would rather keep our
communication possibilities unimpaired, even if it means dealing with a
    
bit of spam and use cryptography or out-of-band checks for important
    
business.

    It's not a minority, it&#=
39;s a majority.=C2=A0 It's the majority which are routinely subjected<=
/div>
    to phishing and spam messages... or at least a large enough minor=
ity (100s of millions?)
    that to say it's not important is sus=
pect.

    There's no e=
asy way to say "just this mail is important".

    If you want a minority, t=
hat's people using mailing lists... or even people
    using email instead of other messaging protocols, unfortunately=
.

    
Not to say that DMARC's validation is not valuable per se. But asking
mailing-list (or other) users to jump through hoops to simply
    
communicate as they have for 40 years is incredibly arrogant.

    There have been a large number of changes in how ema=
il works in the last 40 years,
    many things that used to work no l=
onger do.=C2=A0 Open relays, anyone?=C2=A0

    
P.S.: and no, "then don't use DMARC" cannot be the answer. So=
me time
    
down the road, it will be forced on us by the large mailhosts, who have
    
a business interest in curbing spam. So it'd better be done right.
    <=
/blockquote>

    As opposed to the small mailhosts who love =
letting spam and phishing messages
    rip off their customers?
    =


    Brandon=C2=A0
    

--000000000000772bda05a8b179a4--


From nobody Mon Jun 22 16:34:44 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220493A1275 for ; Mon, 22 Jun 2020 16:34:43 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 CWTgeLzx3Ljt for ; Mon, 22 Jun 2020 16:34:41 -0700 (PDT)
Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 CE3603A1274 for ; Mon, 22 Jun 2020 16:34:41 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04lp2057.outbound.protection.outlook.com [104.47.45.57]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QCC00EIWPHLW110@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 22 Jun 2020 18:34:34 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.22.232717, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.16.5740001, SenderIP=[104.47.45.57]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D07Efilvt7Ktn724e4y4StRkscEtZqfyo+unNCQ0kOu58Ef4stKBI1a1zph8o8amifLqthE23ZmoXdaewm6UOHqjiQHqNMtGgVaX+8458bpNtoT9tIqRfVdzlR0bUowKC+gY876BJ/r3Vducc2LP1Ybr3gwyLMS5AGjA/sExq1NMcBQ71DUdZHHT0chFKZLO4WpCtnRiPgHOHUWdSagcgZgSGnsU5LZUtTrcmvBR3XeAVtTjWTMR4MqlLaog/U8IV7sz7PJo7wY3rz1utUIvLGy9UYOf9WG43sakqkBIwUzp+J3sTF8VBkuLLyXrfVzyMNzDLPChuLk0X/th9dxMfA==
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=Bu496fa/PvkC5VvUQ3Iqi4xWTV9N0vIRRh7jzW/R3I8=; b=EHvkZ4GuP1RM3ohXWX0rrCU59lt0KjckNkFX8UKauuoCQ7f1nWdoB+4rIyqWsvT86Kc79idJkKS5mES/8KUvuu1jQwid1ASE6mU/ArHwT/MNwcypL+wDbKg752nqFgt3qEe7hYg0BG/PazGoplF8lZRJOnGg9UK+gP2lxlX6JdfsAejDIZdFCEgN0CAhfkrZn6faF5iqOPiJ/OQVzEE9lG6LSmbLpvVAGZfXwDpRsrT0Y3ofudzmdPvkiDeQH0mivQoLKTNIIbuuarGSzfmGOHhWnnrtFma+1gQopQXVzhcyTV11bXkB+ClnJoPG3SuPI0ibNz0USKOTFBi8rEnuKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bu496fa/PvkC5VvUQ3Iqi4xWTV9N0vIRRh7jzW/R3I8=; b=T58vxdIr6g+JhGYhVlU1hfLzqK//3yhA1eHKdToanZn69P2ndQDQxnYWjiHYNj6qzwtVQrZ9Hzd867qyPv86hYJflYcbVsv+K8f5pAwCHtlnG6bdxHwIcbX4q0zkKih14FGFMOQf1odIbokvV5J1WB3T3GLM+GTgOhPHNSoEeTc=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4041.namprd06.prod.outlook.com (2603:10b6:5:8e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 23:34:33 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 23:34:33 +0000
To: dmarc@ietf.org
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com> <27a30b41-220f-0dbf-c33e-e23d2fc36bae@tana.it>
From: Jesse Thompson 
Message-id: <24c23134-c818-fc97-79fb-be4f2b9fdcca@wisc.edu>
Date: Mon, 22 Jun 2020 18:34:30 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: <27a30b41-220f-0dbf-c33e-e23d2fc36bae@tana.it>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 7bit
X-ClientProxiedBy: MN2PR03CA0002.namprd03.prod.outlook.com (2603:10b6:208:23a::7) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.24] (47.12.96.133) by MN2PR03CA0002.namprd03.prod.outlook.com (2603:10b6:208:23a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 23:34:32 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 0a5605b5-8b68-4ce7-1ad0-08d81704d124
X-MS-TrafficTypeDiagnostic: DM6PR06MB4041:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:5236;
X-Forefront-PRVS: 0442E569BC
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: NlsgPN4s6j3stFE23MMypmgF2uDjA2aU+THgMy2rz9fb/hlX7nib3IOycefWNBaWpBmeQOBVVGyhZm1x07pR2zlDPkTtJLH+Sx43iyN4jySOCAi58dkqC5BwcosQhiHnnci/38mJb0ca5CLMa/p3G8XgLCTgpeK3/DZmylLt2FUihc28iptlb3Wb/HxCZsQlw3eWHxwV9GERCOByTCcNdZtnCjRFvS8LlVBGA53/LnzJtM1+kA+QLjn2TyPNk37pVeWC4Eg2ypYTYM3HP0ZiYSt3hELNjMKG3U6IqqjCrVPYuT6GA5zCdzynX6v4iNkwbukYhs/xPmtvGYcfz+pKnmuW/BuU7Hew4zkiyubJpr0P+gBmbeIfm/rVlxMYocR+PKTSPOLJthjd8vKKiTBwfQWQHxoT2Pf+Q3/VsJ30/kq+G69KDkYYZq5OxkGK2Fnb
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(366004)(396003)(136003)(39860400002)(376002)(346002)(16576012)(316002)(786003)(75432002)(6486002)(44832011)(2616005)(478600001)(956004)(6916009)(45080400002)(66556008)(16526019)(66476007)(8936002)(26005)(66946007)(4744005)(53546011)(5660300002)(86362001)(8676002)(186003)(31696002)(31686004)(2906002)(36756003)(130980200001)(223123001)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: otMTN+upegNP9PIOA9jQN4u8U20d0+0v0zQvHVkTBtf5r+NuE9yQUMytgKHOrpGYOH0FYIlv1z3fcdu/k+YU+5QeYN+HoHDWekUGNEdP+J6CAAK0GwwTYbZ5wa0b2CfvRMD6KfWLb5LwmwCU5/j19Hn38AbY/m9tfXQEn2u7UEPVdPIgCRYdIKtOXqzZ/m/KB3cbi+ZQ5AcyFvCNXckxklRTLti3SCAQpXTkMoIrrcMNiVURX5KvtNJC+9AuZHITPLXG04kvaESffg7m7Hr5bJfkr2djjINTQYa5YgkUKP6czCUFcczvTz/4oyhrT78YTnG+lAhJSfZ1iCBSxjYj66iNrZB8GQG5idLJ39tk8Hx8OyG+oGrgDmcYGow9x1iX2EbOlg+zbfXyc/BH56QinFXkdpLAq5AIr2lfbLU2C9Lmhc02UW5W8sLsAbWHbLy27Cp/6/4VCYX2pcOP4IpABgYX6kasFmpe9DcApEg4FR0=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a5605b5-8b68-4ce7-1ad0-08d81704d124
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 23:34:33.0896 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vLBBJJwxLvxIN59MCKLxpQGyxpJ9Wp422qh+TohmfnsAa7xEi3+V7oG96wQrWmp6NHVxb36JdseQ2Onr/leT3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4041
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 23:34:43 -0000

On 6/22/20 6:23 AM, Alessandro Vesely wrote:
> The fact that it cannot be set by a MUA implies Sender: already lost
> its menial meaning.  So it became a Mediator sort of thing.  This list
> sets it to "dmarc" .  Does anybody use it, or
> ever happened o take a look at it?

Yes, and I assume that's partially why the OP (who I was posting on behalf of) brought this Sender dilemma up in the first place.

Outlook on the Web displays:

dmarc  on behalf of dcrocker@gmail.com

and for those domains that have DMARC policies

dmarc  on behalf of todd.herr=40valimail.com@dmarc.ietf.org

Jesse


From nobody Mon Jun 22 16:40:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4271F3A127A for ; Mon, 22 Jun 2020 16:40:39 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 KN-tareGNi4E for ; Mon, 22 Jun 2020 16:40:37 -0700 (PDT)
Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 D882F3A1278 for ; Mon, 22 Jun 2020 16:40:37 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2103.outbound.protection.outlook.com [104.47.70.103]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QCC00ESNPROW110@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 22 Jun 2020 18:40:36 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.22.233017, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.16.5740001, SenderIP=[104.47.70.103]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Izhsly9JfqBcZdIVNeFQyBayP2mSJsnNsTi5BWURHIL4jUX5eM5AhrZZVsnLa2S5cqR/NPtm9kkXH2OHo5xSe3oqsTvp9znS9d2OI3HAO3m+KWMc9gWRJhx7kwXpFPjOplan9ST8WKAzaH3lCd81WnRKpD4T5Hi9ZzCMWgXh4wEsoN9wR9mmWAAT8xu8WzYxygUsRwT+e2QXE56I44V9EObRZRbP8Y5rD7/xpVaTVt1Vk1nC2U61j49QfUUA1t1pqD6bLxxpCH1TI56zMN54bOanaevH4lg8ZJsaXkf812fYrYQOy+3zORjr/7l5g/0fyOzhXRcRZS+ezmZSdlFOKg==
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=qB4WgOIWrBEcj7wGQ70uZjrY38RnNj7CXV6MfjpxydM=; b=h71KGmHUmuMAmvWczjMCEOf6QgjQ4shPrF4hXOj04GJnEOexGHz//NXy6o+3/uQBnRuhP3QAK+Nm7qDjDjo1CEnye92tek3km/TT/MCgjOY3YeYis4kDgQbSTLUv4TQl0AWRSiQFIQpr0byYHVvymvMcPJgssh0Yj58VK4Da8spzEt0OUlchbwXg1He7JtzdYYv+MxVmdChAuJRgxty8Eya9uPY3X0eUnpGzk4kWLGnFzzT/+r4/SD0iWmksURD11lV+TZVOXh1bktXCBLWsFF8og77ttpA0sG6OqNILK8PbThyhnjqWIBmtyegVETKGdpSYxm84j1roPGD3YbUMSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qB4WgOIWrBEcj7wGQ70uZjrY38RnNj7CXV6MfjpxydM=; b=q/4N+NlGV8X3SVx0NXsGEVSVQ5OPvY2Z4Ky+ZpaRFgHxhmpXWqlUVaoR9wsEA/7f2ANKjLDSzmeklkcmNwT99G+L3cjZ6VQl6ArxufLg3M9m9nCXhYQgLa6egeZNdu9qfYoeNPRq7RB6WdJG89KXcBHFE3xn9GxEjmwXXs3AB/o=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB6219.namprd06.prod.outlook.com (2603:10b6:5:128::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 23:40:35 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 23:40:35 +0000
To: dmarc@ietf.org
References:  <20200622010725.F224B1B4CE70@ary.qy>  <5EF0D2B4.2080901@isdg.net>
From: Jesse Thompson 
Message-id: <91f8d8cf-9424-9aa5-f36c-85ddcfcfd4a1@wisc.edu>
Date: Mon, 22 Jun 2020 18:40:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: <5EF0D2B4.2080901@isdg.net>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 7bit
X-ClientProxiedBy: MN2PR02CA0016.namprd02.prod.outlook.com (2603:10b6:208:fc::29) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.24] (47.12.96.133) by MN2PR02CA0016.namprd02.prod.outlook.com (2603:10b6:208:fc::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 23:40:35 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: b2e60d94-f07f-403d-fb94-08d81705a92c
X-MS-TrafficTypeDiagnostic: DM6PR06MB6219:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:1148;
X-Forefront-PRVS: 0442E569BC
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8fz0odOp+Z4g/Meb19lT194cGK0hAL7aCZ5r/fGlZL0UWROPM3dHlEYfIIRhE4ust/4mIetuDreTLNyi63SBGSZGZZJ41gSDRpCLIC6aSubvk/bRiVwW0LhUm9A0UxfJEnLjm4Gk9s78Q3xxN6N6HkatLls6qlVEEE1Jh3VgjvIDVrJx1jk81pZoeJy8lO0lWEyse1OEvORMh6xj3juEsQ7a5jhj3aLIt2TG36Mtjvm9+koYb2fmf7NKKl16Df4YSjEFK98tNzY4bmP9KrLYy+P72AmrgR+bfQgM6T3art10NEip+8O0nkedRViahTUFtGyB8Xi+Yxq/TXXy8+ku0QdAKfl6SitfF9R8WVcXOmqVOw5dY3pPvN9AFh9eiDJl
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(346002)(39860400002)(396003)(366004)(376002)(136003)(53546011)(6916009)(44832011)(66476007)(66556008)(2906002)(86362001)(26005)(8676002)(8936002)(36756003)(31696002)(75432002)(478600001)(16576012)(6486002)(5660300002)(31686004)(186003)(16526019)(66946007)(316002)(786003)(4744005)(956004)(2616005)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: w7KfWAun+3vb57E/3bTGVkJXalX75TcR4QR/Eq3SG0dpADfsZXFzYg6x7xDfhCU/7iydzvgcLhpxYMFtxtwDQFsGP61b05cHf1klMib29GeIvt5t/XU4G3RCC4vZHJT7VRNRVUafhXo5OoUuHPoDGqto5sCxRINH/Z+wyLMsTp9Tvf1+IqV/Bi5i9wWRrqu4JNH5oly3CH8xM0Lyfu973l64l6tKmK3fDl6sL2Hx/KIDssTMgA9xv4rR3m5DH9N/4C/6DNmN+GKBtpcDKoaqUSSXc/ppWRWjOaPrWKqzh9u2xF5f3bJtigRXJK7jEve7j8tGBMwNXRBxGQDxs7mn8S+NDhcxhPE4zK8jgzqvH9EFDJbObkLEsC3YEoH9Hofjk7dwPO5St5IazseyfvY1tm+EI88tWpw1dN51iuzFvK29Ak2toVnL2n6gX7oY9A4qAIP1ncsAGWX4cVm9aZLOkdheoe56GTqmzP0GyMOuraY=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: b2e60d94-f07f-403d-fb94-08d81705a92c
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 23:40:35.4897 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: onHDn5KrPDyIArhkFESm15AodNZdAeLm9a3p8ZIk0L3wv3MQc0Fo6s42yBzj1tlkz6zd7FSRFqE8NMRwqhDu2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6219
Archived-At: 
Subject: Re: [dmarc-ietf] Mediation
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jun 2020 23:40:39 -0000

On 6/22/20 10:48 AM, Hector Santos wrote:
> Your domain has a restrictive DMARC policy. Here are your options:
> 
> 1) Use another non-restrictive domain,
> 2) Prevent your domain from subscription and submission, or
> 3) Authorize the Rewriting of your secured domain to a secured resigner domain.

If those were the only choices then no EDU would publish DMARC policies. 

Jesse


From nobody Mon Jun 22 18:58:14 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798133A16DB for ; Mon, 22 Jun 2020 18:58: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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=bayviewphysicians.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 HiJ5jq04L33A for ; Mon, 22 Jun 2020 18:58:10 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5364A3A16DA for ; Mon, 22 Jun 2020 18:58:10 -0700 (PDT)
X-ASG-Debug-ID: 1592877488-11fa313a10207bd0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 49H9t1bMNBP4h1EW (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 22 Jun 2020 21:58:08 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=dq3jHlAhtZ4+6oIWashZLLHWYZfSGyQad5sR4wgZH1M=; b=U67kXCD+HLP7AlLSYr5kArhoUX5DsARa3lcL3+qES9yxjp1LNRHfevI2zZBjO47e6 HSx8uQAeTUfDiTtv6BlcCGMHPMaBGq6v4LbW4L8Y8aF48ifkVQtq4nzOBJRY+pOpa FeuDvQ4V2P+iuMFozkhMrrRxhs5xQIlxNPm9r6bfA=
From: "Douglas E. Foster" 
To: "dmarc@ietf.org" , 
Date: Tue, 23 Jun 2020 01:58:00 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Reply-To: fosterd@bayviewphysicians.com
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=39cda8d87f274148b4883f8576f49e73
In-Reply-To: 
References:  <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net> 
X-Exim-Id: f678d5cf8965448c96ebe7dd8704edd9
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592877488
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 1697
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82742 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing  list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 01:58:13 -0000

This is a multipart message in MIME format.

--39cda8d87f274148b4883f8576f49e73
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

To the chairs:
It has become clear that we do not have consensus on the issue of content-a=
ltering mailing lists.

Despite the diversity of viewpoints the number of persons involve in the di=
scussion is fairly small.
Have you identified the stakeholder groups that should be represented in th=
e DMARCbis process for it to be considered sufficiently representative?
Have you made any assessment of whether all such groups are in some way rep=
resented in this discussion?
Do we need to do some outreach to ensure that all stakeholder groups are in=
volved

Of course, adding additional voices may make the consensus problem more dif=
ficult.  What is your mechanism for resolving consensus problems?

Doug Foster



--39cda8d87f274148b4883f8576f49e73
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


    To the chairs:
    It has become clear that we do not have consensus on the issue of co=
ntent-altering mailing lists.

    Despite the diversit=
y of viewpoints the number of persons involve in the discussion is fairly s=
mall.
    Have you identified the stakeholder groups that should be r=
epresented in the DMARCbis process for it to be considered sufficiently rep=
resentative?
    Have you made any assessment of whether all such gro=
ups are in some way represented in this discussion?
    Do we need to=
 do some outreach to ensure that all stakeholder groups are involved
    <=
div>
    Of course, adding additional voices may make the consens=
us problem more difficult.  What is your mechanism for resolving conse=
nsus problems?

    Doug Foster


    

--39cda8d87f274148b4883f8576f49e73--


From nobody Mon Jun 22 22:29:48 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291633A1760; Mon, 22 Jun 2020 22:29:47 -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, FREEMAIL_FROM=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=gmail.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 roKYgZlif7R8; Mon, 22 Jun 2020 22:29:46 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 1EE293A175E; Mon, 22 Jun 2020 22:29:46 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id m25so11006961vsp.8; Mon, 22 Jun 2020 22:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Whs6J+wjiFJyP/uwldlFtT8pb2DgZjkWN6l3s2Yd9w4=; b=OYLi331xIS/CzsnGlZEXZ8FMSMQ9sUQkdvV47su1qtWtorJf3tJFPpkxCQ8aX9p4yK 4spY8Rg5F7XN+QIT1Ddz1rEscr+/o5A0cz6Yi7i9uVjaNxjJxYPRBr1Fbadipq634K/Y yvepT/eEx8J0K+Rh8xOI8oISu8JubalwFDbGGmaFsfc3/QMLEfmXM8nZNhhdQePC+us4 lC4fatrWkxr74JJmYz1qEzBInsX4ovXtDiN/9sxM/vvV8NDI+x+w87y0Ij5H83UqEs/Z k27VljgLb4hxLXo+bwL+BGbb49u/D1j9hRlnpJhvi3soZoqt+RwtsI8AMKgWNzeXa+Hb b0mA==
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=Whs6J+wjiFJyP/uwldlFtT8pb2DgZjkWN6l3s2Yd9w4=; b=KCFkYbk1oFu9nE2OMlOL6QOEhX8S+Hb/81AxQ0ZLJmwJezgiXq4RgVvDKeFXV7utXU WV3JA7RHGiEhmGQBvlMq3tbGZn66xvDz+PyRB8f+poltXF+uA0iByKRtX5VRZfO0c4w/ qQBITbPKgR/EStLFPmgkXl90LVYBCL1CnD95xzlpndYpBbbM8GiArOBZco8c0shjmsv6 ix3ZZTmipPDkYLGbAH9p1VzCwCzJC9gGFcncDLNKCHXEJ+YsaqhSra/CnLa76DcH6rY7 feQB2viv7kcdKBBE6AQ8OdfQDmbkuWg0a0Emw0xRuHaQXgK7UViApzgqyNj6ZGsU8K1/ jwlg==
X-Gm-Message-State: AOAM533gDFV44TmpyK7TLfG++fIgoih6qdR/TOz6NiXwXCXL7PeJsqdk 12hd2UXmCbOJeFbxesMJq/RBHUJ3REQaWRTuiFHY6A==
X-Google-Smtp-Source: ABdhPJzHhw0aFLto/MxVn9fVOvo3QPoXlN0rVBesJq3/to7HwZHZiruO+rk/un1bGfxJuoRCY/4TRCI68Z+7fmcOw1w=
X-Received: by 2002:a67:d304:: with SMTP id a4mr19306662vsj.7.1592890184966; Mon, 22 Jun 2020 22:29:44 -0700 (PDT)
MIME-Version: 1.0
References:  <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net>  
In-Reply-To: 
From: "Murray S. Kucherawy" 
Date: Mon, 22 Jun 2020 22:29:33 -0700
Message-ID: 
To: fosterd@bayviewphysicians.com
Cc: "dmarc@ietf.org" , dmarc-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 05:29:47 -0000

On Mon, Jun 22, 2020 at 6:58 PM Douglas E. Foster
 wrote:
> [...]
> Of course, adding additional voices may make the consensus problem more difficult.  What is your mechanism for resolving consensus problems?

Are you familiar with RFC 7282?

-MSK


From nobody Tue Jun 23 07:27:01 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803F43A0D29 for ; Tue, 23 Jun 2020 07:26:59 -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, FREEMAIL_FROM=0.001, 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=gmail.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 8l6ueVHhGg9j for ; Tue, 23 Jun 2020 07:26:56 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 72E473A0C64 for ; Tue, 23 Jun 2020 07:26:56 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id h5so20765181wrc.7 for ; Tue, 23 Jun 2020 07:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zfF/FcS03nPuDKndyHLE4wFkVhW+prZbxFTl0sI4C2I=; b=b5VhkhdodU50p17jM+XejP+P/yZX19QZlIIeSAhd94UPWokC5jyA1xqiYzT03uVbJS 7aGXzJ7rp5gPKXgROVpfQW0vzsfg3EjHZxkFEhZ/vHFzpAOFnmIiFlOd4AXPa/8SJzv3 mb5JqJAkumdp0RtFokaiLG+jNndHpB8qkB5IVeXHIj3UV6A3OlVECbqUWw313PlAEelo i+wqFsdhIAw9h5M+byiq57Jg4+IHq5hbR8kLFG91hS4ql80oQhUFTxFJ2LxzeF0qQAr9 4B0Nwxnjcs9/KXhbIbFpnT5thxo3bJN/ZsGS6xqmz7aObKIcufq4oDgtgy0J68MQ3rXv cG3w==
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=zfF/FcS03nPuDKndyHLE4wFkVhW+prZbxFTl0sI4C2I=; b=XGvz7yDOsZktvHmJCOV7vbPcMPCRFY0CQdkXOh56glqcC5qhpyNtI5nw1FytjhrpSh H8dj2WryKs3neS1tIAFP5UKcArfzcjE7oDp4hRvcuCkNiRu4qYeBCr+nEmv8jrwyWSKf MY0gJFXTGp3hjZTssORN1vvxz1wSpgowiUpq+LAyfwW8VOaz6e1bTHuLRVM2IiaBno7a hDTx+ovJ6Qmg+4mvrFYA44maC69yW2b4zEEeU3iUd/4AfP5M7eo4DcOCFwse+Rcy7EFH qUtSyl63P9+l91MsZKnmW1pSH3pv9w6GeVXpXe78TY6xgR6G7CpUE7rKTgiH8D6vuaaK oDww==
X-Gm-Message-State: AOAM530WSbO/0y/y5oZRbiO0syp/0f+NkhyGMDK4PsNZM9pFMNvWXZH3 l5eSjBiKLfKC1AGt4zndoiQ7AkpHv+KVuLvbiCHGBJEL
X-Google-Smtp-Source: ABdhPJzpRCQRIXi0ZWn2+JJk7aQ2s2vV1NTuhTFqsE9DatBQ64VIpHDBtqKj6rXlDq/xNi/yq0qwT43CuqJ4PJ0Yt5A=
X-Received: by 2002:adf:de0a:: with SMTP id b10mr23060682wrm.72.1592922414299;  Tue, 23 Jun 2020 07:26:54 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>
In-Reply-To: <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>
From: Dotzero 
Date: Tue, 23 Jun 2020 10:26:42 -0400
Message-ID: 
To: Dave Crocker 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000a8bf7805a8c12661"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 14:27:00 -0000

--000000000000a8bf7805a8c12661
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker  wrote:

>
> When first specified, Sender: was to cover the case of someone doing the
> online work, on behalf of  authors who weren't online, or at least not
> online for processing the message.  Back in those days, that was not
> uncommon.  Even if the author officially had an online presence, they
> often did not do the typing.
>
> It's important to note that in those times the "Sender:" was almost
certainly in the same organization/location/address/namespace as the
author. If that were still true today we wouldn't be having this discussion
because the RH side of the email addresses would align.


> For most email, From: and Sender: are the same person (and the same
> email address.)  This fact was the reason the original specification of
> Sender: in RFC 733 only required an explicit Sender: field be present
> when the addresses are different.
>
> For today, these same abstract constructs have -- or should have -- only
> slightly different application.  From: is still supposed to be the
> author, which remains the creator of the (original) content.  Sender:
> could be any separate party responsible for processing the message


"Processing"? That covers a whole lot more than sending. A security
appliance "processes" the message but is clearly not the Sender.

> .
>
> So, in abstract terms, if I go to a greeting card site and have it send
> a greeting on my behalf, the From: field should be my own email address
> and Sender: should an address at the greeting card company.  But I said
> 'abstract' because current realities mean this isn't as useful an
> arrangement as the theory intended.
>

Now you are in a space I know a tiny bit about. There's a little bit of
history here, starting with the  FTC spam workshop in 2003 and the FTC
email authentication workshop in 2004 we saw a lot of changes starting to
occur in the email authentication space. The FTC was forcing things by
indicating that if the private sector didn't come up with solutions, the
FTC was going to regulate. SPF took a spot in the limelight and DK and IIM
were merged to create DKIM. A number of people on this list were involved
in all the happenings. Anyways, I wrote a 46 page document for internal
consumption at the greeting card company I worked for. At the time, pretty
much all greeting card companies sent email in the manner you describe
except that many didn't even bother with Sender... and the emails typically
got through to the recipient. In my analysis, I posited that there would be
drastic changes coming in practices for greeting card sites along with news
sites (share with a friend) or sites that had a refer a friend function
(and which typically sent the email using the email address of the person
doing the referring on the theory it would result in more opens. In any
event, my thesis was that all of these types of websites would have to
start sending emails as themselves rather than using an email address not
their own. This was specifically linked to these nascent email
authentication efforts. In 2007, the Storm Worm started spewing "greeting
card notifications" (along with other sites) purporting to be from a
variety of greeting card sites. The volume of these sends was orders of
magnitude greater than any greeting card site was sending itself. This
caused management to ask me what could be done about this problem. We
implemented changes like strict SPF and DKIM across the board for all our
end user facing websites (mail), moving all our employees (with the
exception of role accounts and a handful of user accounts that responded
directly to end users or partners and publicizing to receiving domains and
security companies what we were doing and that if mail claiming to be from
our domains failed to pass either SPF or DKIM, throw it away. Absent the
feed back loop and the formal definitions in the standard, this is the
essence of DMARC. If someone cares to look back in the DKIM-OPS list from
that time frame you can find posts from me making those assertions.

At roughly the same timeframe, Pat Peterson, who was still at IronPort,
organized a small group of senders (mostly financials and a greeting card
company), a couple intermediaries (like ReturnPath and eCert) and some
major receiving sites (like Yahoo! and AOL). PayPal and Yahoo! at the time
were working on a private peering solution which was successful. This all
eventually became the DMARC "team" and later dmarc.org. It is important to
remember that both SPF and DKIM function at the domain level, not the
individual account level (with the exception of edge cases like a domain
which is a personal domain with a single user account). Yes, there was the
d= vs i= debate with DKIM... and i= lost out in practice.

Today you won't find any (major) greeting card site sending email in the
way you describe. This isn't because they wanted to change. It's because
they were forced to change. Email authentication has a network effect that
in essence makes unauthenticated mail "second class" from a receivers point
of view. Yes, there are certain types of mail scenarios (MLMs for example)
that are problematic, but one always has to ask, for whom? Some in the MLM
community responded to the changing environment by saying "We were here
first so go fuck off with telling us to change how we do things". Yet MLMs
have changed in various ways in attempts to deal with the environment
presented by changing practices, particularly by major receiving sites and
the security industry.

>
> I believe this is because Sender: is not reliably present. Hence, it
> literally cannot be relied upon.  The Sender field is not created
> reliably to indicate such distinctions and the receive side does not
> reliable note the distinctions.
>

I absolutely disagree. It's not because Sender: is not reliably present but
because Sender: is inherently unreliable because unless it is in the same
domain space we have absolutely no way to validate the relationship between
Sender: and From:. This was the problem inherent in the SenderID PRA
algorithm. I could and did send emails to the folks who were promoting
SenderID at MS using their email addresses and random nonSPF publishing
domains as the Sender: to consistently achieve a neutral from the PRA
algorithm. Until and unless there is a way to specify such a link, any
proposal to rely on Sender: is doomed to failure. And no, that does not
mean I think Hector's proposals regarding Sender: are valid approaches.

>
>
> > For a newspaper, if you pardon the analogy, the masthead is more
> > visible than columnist signatures at the end of the articles.  For a
> > mailing list, publisher visibility used to be provided by subject
> > tags, leaving the From: intact.  Why?  Presumably, because it just
> > worked that way.  However, if the MLM is the system responsible for
> > writing, not modifying From: should be considered a violation.


MLMs can be both at the same time. Digests vs individual (unmodified)
messages.

>

If a Mediator makes 'substantial' changes to a message, then it can be
> considered a new and different message?  Yes, but note that we have no
> objective criteria for this.  That's why I class this reference to
> 'publisher' as a business issue rather than a technical one.  (And an
> ethical one, as some wayward journalists discover when they claim to be
> quoting someone but it turns out the reporter invented the content.)
>

The real question is what works, not whether it is a business issue vs a
technical issue. If there is a standard that works, great. If there are
heuristics or algorithms that work, they will get implemented whether they
have been standardized or not. To the extent that standards bodies provide
meaningful solutions in (somewhat)  timely manner, they will remain
relevant to a given (problem) space.

>
> However I think that referencing the role of an MLM as 'publisher' can
> be helpful to remind us that MLMs have their own agency and can,
> legitimately, make all sorts of changes.  Whether authors and recipients
> like those changes is a non-technical matter.
>

At the end of the day, mailbox providers will determine the outcome of the
subject of these discussions based on how they handle and treat mail
passing through MLMs and whether there is authentication they find useful
(as one part of determining how they will treat mail streams and individual
messages within those streams)

>
> The practical problem with From: field munging by MLMs that are
> otherwise trying to relay a largely-unmodified messages, is that they
> effective destroy author information, by putting in a different email
> address.
>

Destroy? or modify? As long as the original email address is available in
some identifiable form in the received email message then it is possible
for MLMs to work in a manner akin to how they work today. Yes it involves
rewriting code and logic to support those changes but there you have it.

>
> In practical terms, today, the MLMs arguably don't have a choice.  But
> it still can be helpful to understand the problems created by this
> alternation.
>

It's not a technical issue for MLMs, it is a business issue at its essence
- change or don't change. Such change can be on an individual basis (or
not) or it could be standardized.


> >> My understanding of the meaning that DMARC added was, "The author of
> >> this
> >> message, as expressed in the From: field, always has their messages
> >> properly
> >> signed by the domain in the From: address." You seem to be saying
> >> that, no,
> >> what DMARC did was changed the semantic to be, "The From: field now
> >> represents the transmitter of the message (as used to be expressed in
> >> the
> >> Sender: field when present), not the author, and that transmitter
> >> always has
> >> their messages properly signed by the domain in the From: address".
>
> For reference, I consider this an accurate summary of why I say that the
> From: field semantic is changed as a result of DMARC. Specifically so
> that mailing list mail can be delivered.
>

And yet Sender: can still be the transmitter as long as they are in the
same RH address space OR can sign the message with a valid DKIM key from
the From: address domain space. Of course, MLMs putting their own email
address in the From: is a change but I'm not sure it quite matches the
semantics you suggest.

>
>
> > Sender: was not meant to be the transmitter in that sense.  It was
> > meant to be the secretary who writes on behalf of a responsible person
> > or system.
> RFC 5322 has preserved the semantic of the Sender: field:
>
>       "The "Sender:" field specifies the mailbox of the agent
> responsible for the actual transmission of the message. "
>
> I consider that to be exactly the role the MLM is performing.
>

Sender: can still be a useful field but not necessarily from an
authentication POV absent some way of determining whether the purported
Author authorized the Sender to send the message on their behalf.

>
>
> > RFC 5322 says display names are "associated" to a mailbox.
>

As long as the display name is free form it is not associated with anything
in particular other than the message which contains it.

>
> I don't see such language in RFC 5322.  In fact, other than the ABNF for
> display-name, I don't see any explanation of its semantic.
>

+1

Michael Hammer

>

--000000000000a8bf7805a8c12661
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Sun, Jun 21, 2020=
 at 1:32 PM Dave Crocker <dcrocker=
@gmail.com> wrote:

    
When first specified, Sender: was to cover the case of someone doing the 
online work, on behalf of=C2=A0 authors who weren't online, or at least=
 not 
    
online for processing the message.=C2=A0 Back in those days, that was not <=
br>
uncommon.=C2=A0 Even if the author officially had an online presence, they =

    
often did not do the typing.
    

    It's important to note that in those times the &q=
uot;Sender:" was almost certainly in the same organization/location/ad=
dress/namespace as the author. If that were still true today we wouldn'=
t be having this discussion because the RH side of the email addresses woul=
d align.
    =C2=A0
    For most email, From: and S=
ender: are the same person (and the same 
    
email address.)=C2=A0 This fact was the reason the original specification o=
f 
    
Sender: in RFC 733 only required an explicit Sender: field be present 
    
when the addresses are different.
    

    
For today, these same abstract constructs have -- or should have -- only 
slightly different application.=C2=A0 From: is still supposed to be the 
author, which remains the creator of the (original) content.=C2=A0 Sender: =

    
could be any separate party responsible for processing the message

    "Processing"? That covers a whole lot mor=
e than sending. A security appliance "processes" the message but =
is clearly not the Sender.=C2=A0
    .
    

    
So, in abstract terms, if I go to a greeting card site and have it send 
a greeting on my behalf, the From: field should be my own email address 
and Sender: should an address at the greeting card company.=C2=A0 But I sai=
d 
    
'abstract' because current realities mean this isn't as useful =
an 
    
arrangement as the theory intended.

    Now=
 you are in a space I know a tiny bit about. There's a little bit of hi=
story here, starting with the=C2=A0 FTC spam workshop in 2003 and the FTC e=
mail authentication workshop in 2004 we saw a lot of changes starting to oc=
cur in the email authentication space. The FTC was forcing things by indica=
ting that if the private sector didn't come up with solutions, the FTC =
was going to regulate. SPF took a spot in the limelight and DK and IIM were=
 merged to create DKIM. A number of people on this list were involved in al=
l the happenings. Anyways, I wrote a 46 page document for internal consumpt=
ion at the greeting card company I worked for. At the time, pretty much all=
 greeting card companies sent email in the manner you describe except that =
many didn't even bother with Sender... and the emails typically got thr=
ough to the recipient. In my analysis, I posited that there would be drasti=
c changes coming in practices for greeting card sites along with news sites=
 (share with a friend) or sites that had a refer a friend function (and whi=
ch typically sent the email using the email address of the person doing the=
 referring on the theory it would result in more opens. In any event, my th=
esis was that all of these types of websites would have to start sending em=
ails as themselves rather than using an email address not their own. This w=
as specifically linked to these nascent email authentication efforts. In 20=
07, the Storm Worm started spewing "greeting card notifications" =
(along with other sites) purporting to be from a variety of greeting card s=
ites. The volume of these sends was orders of magnitude greater than any gr=
eeting card site was sending itself. This caused management to ask me what =
could be done about this problem. We implemented changes like strict SPF an=
d DKIM across the board for all our end user facing websites (mail), moving=
 all our employees (with the exception of role accounts and a handful of us=
er accounts that responded directly to end users or partners and publicizin=
g to receiving domains and security companies what we were doing and that i=
f mail claiming to be from our domains failed to pass either SPF or DKIM, t=
hrow it away. Absent the feed back loop and the formal definitions in the s=
tandard, this is the essence of DMARC. If someone cares to look back in the=
 DKIM-OPS list from that time frame you can find posts from me making those=
 assertions.

    At roughly the same timeframe, Pat Pe=
terson, who was still at IronPort, organized a small group of senders (most=
ly financials and a greeting card company), a couple intermediaries (like R=
eturnPath and eCert) and some major receiving sites (like Yahoo! and AOL). =
PayPal and Yahoo! at the time were working on a private peering solution wh=
ich was successful. This all eventually became the DMARC "team" a=
nd later dmarc.org. It is important to rem=
ember that both SPF and DKIM function at the domain level, not the individu=
al account level (with the exception of edge cases like a domain which is a=
 personal domain with a single user account). Yes, there was the d=3D vs i=
=3D debate with DKIM... and i=3D lost out in practice.

    =

    Today you won't find any (major) greeting card site sending email =
in the way you describe. This isn't because they wanted to change. It&#=
39;s because they were forced to change. Email authentication has a network=
 effect that in essence makes unauthenticated mail "second class"=
 from a receivers point of view. Yes, there are certain types of mail scena=
rios (MLMs for example) that are problematic, but one always has to ask, fo=
r whom? Some in the MLM community responded to the changing environment by =
saying "We were here first so go fuck off with telling us to change ho=
w we do things". Yet MLMs have changed in various ways in attempts to =
deal with the environment presented by changing practices, particularly by =
major receiving sites and the security industry.=C2=A0
    

    
I believe this is because Sender: is not reliably present. Hence, it=C2=A0<=
br>
literally cannot be relied upon.=C2=A0 The Sender field is not created 
    
reliably to indicate such distinctions and the receive side does not 
    
reliable note the distinctions.

    I absol=
utely disagree. It's not because Sender: is not reliably present but be=
cause Sender: is inherently unreliable because unless it is in the same dom=
ain space we have absolutely no way to validate the relationship between Se=
nder: and From:. This was the problem inherent in the SenderID PRA algorith=
m. I could and did send emails to the folks who were promoting SenderID at =
MS using their email addresses and random nonSPF publishing domains as the =
Sender: to consistently achieve a neutral from the PRA algorithm. Until and=
 unless there is a way to specify such a link, any proposal to rely on Send=
er: is doomed to failure. And no, that does not mean I think Hector's p=
roposals regarding Sender: are valid approaches.
    

    

    
> For a newspaper, if you pardon the analogy, the masthead is more 
    
> visible than columnist signatures at the end of the articles.=C2=A0 Fo=
r a 
    
> mailing list, publisher visibility used to be provided by subject 
    
> tags, leaving the From: intact.=C2=A0 Why?=C2=A0 Presumably, because i=
t just 
    
> worked that way.=C2=A0 However, if the MLM is the system responsible f=
or 
    
> writing, not modifying From: should be considered a violation.

    MLMs can be both at the same time. Digests vs indi=
vidual (unmodified) messages.=C2=A0
    =C2=A0
    
If a Mediator makes 'substantial' changes to a message, then it can=
 be 
    
considered a new and different message?=C2=A0 Yes, but note that we have no=
 
    
objective criteria for this.=C2=A0 That's why I class this reference to=
 
    
'publisher' as a business issue rather than a technical one.=C2=A0 =
(And an 
    
ethical one, as some wayward journalists discover when they claim to be 
quoting someone but it turns out the reporter invented the content.)

    The real question is what works, not whether =
it is a business issue vs a technical issue. If there is a standard that wo=
rks, great. If there are heuristics or algorithms that work, they will get =
implemented whether they have been standardized or not. To the extent that =
standards bodies provide meaningful solutions in (somewhat)=C2=A0 timely ma=
nner, they will remain relevant to a given (problem) space.
    

    
However I think that referencing the role of an MLM as 'publisher' =
can 
    
be helpful to remind us that MLMs have their own agency and can, 
    
legitimately, make all sorts of changes.=C2=A0 Whether authors and recipien=
ts 
    
like those changes is a non-technical matter.

    At the end of the day, mailbox providers will determine the outcome =
of the subject of these discussions based on how they handle and treat mail=
 passing through MLMs and whether there is authentication they find useful =
(as one part of determining how they will treat mail streams and individual=
 messages within those streams)=C2=A0
    

    
The practical problem with From: field munging by MLMs that are 
    
otherwise trying to relay a largely-unmodified messages, is that they 
    
effective destroy author information, by putting in a different email 
    
address.

    Destroy? or modify? As long as=
 the original email address is available in some identifiable form in the r=
eceived email message then it is possible for MLMs to work in a manner akin=
 to how they work today. Yes it involves rewriting code and logic to suppor=
t those changes but there you have it.=C2=A0
    

    
In practical terms, today, the MLMs arguably don't have a choice.=C2=A0=
 But 
    
it still can be helpful to understand the problems created by this 
    
alternation.

    It's not a technical i=
ssue for MLMs, it is a business issue at its essence - change or don't =
change. Such change can be on an individual basis (or not) or it could be s=
tandardized.

    

    
>> My understanding of the meaning that DMARC added was, "The au=
thor of 
    
>> this
    
>> message, as expressed in the From: field, always has their message=
s 
    
>> properly
    
>> signed by the domain in the From: address." You seem to be sa=
ying 
    
>> that, no,
    
>> what DMARC did was changed the semantic to be, "The From: fie=
ld now
    
>> represents the transmitter of the message (as used to be expressed=
 in 
    
>> the
    
>> Sender: field when present), not the author, and that transmitter =

    
>> always has
    
>> their messages properly signed by the domain in the From: address&=
quot;.
    

    
For reference, I consider this an accurate summary of why I say that the 
From: field semantic is changed as a result of DMARC. Specifically so 
    
that mailing list mail can be delivered.

    And yet Sender: can still be the transmitter as long as they are in the s=
ame RH address space OR can sign the message with a valid DKIM key from the=
 From: address domain space. Of course, MLMs putting their own email addres=
s in the From: is a change but I'm not sure it quite matches the semant=
ics you suggest.
    

    

    
> Sender: was not meant to be the transmitter in that sense.=C2=A0 It wa=
s 
    
> meant to be the secretary who writes on behalf of a responsible person=
 
    
> or system.
    
RFC 5322 has preserved the semantic of the Sender: field:
    

    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The "Sender:" field specifie=
s the mailbox of the agent 
    
responsible for the actual transmission of the message. "
    

    
I consider that to be exactly the role the MLM is performing.

    Sender: can still be a useful field but not necessar=
ily from an authentication POV absent some way of determining whether the p=
urported Author authorized the Sender to send the message on their behalf.<=
/div>
    

    

    
> RFC 5322 says display names are "associated" to a mailbox.

    As long as the display name is free form=
 it is not associated with anything in particular other than the message wh=
ich contains it.=C2=A0
    

    
I don't see such language in RFC 5322.=C2=A0 In fact, other than the AB=
NF for 
    
display-name, I don't see any explanation of its semantic.

    +1=C2=A0

    Michael Hammer
    

    

--000000000000a8bf7805a8c12661--


From nobody Tue Jun 23 11:49:22 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E419C3A0937 for ; Tue, 23 Jun 2020 11:49:17 -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, FREEMAIL_FROM=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=gmail.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 LjUKeo1LNqqj for ; Tue, 23 Jun 2020 11:49:16 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 2B2CA3A0967 for ; Tue, 23 Jun 2020 11:49:16 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id u23so17693217otq.10 for ; Tue, 23 Jun 2020 11:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=WpG1X3a373xVfl8yLidXv5br7H62wslHHIgRygB5foc=; b=L8Zgn4J98HTOnjXlu7tF17/eewQQd8RG5XmUVXpVjH4ekihe9j32Pn0NqAeSNBxCYG JnvC2yRopUOb65ZUpXZlKe7zWIcDdrDhc3upT5b74CIC6ECwoClIVPSBUamhY9XM5XTy n/3T5G1ccSYEL4VeiYLl5L+lcR46Ts6+2IhPg8n6Au8b5KrZjtn/zfLVV/1/CgTggF8/ cbJT0x3SdcVoG7SR7uu2o189YUY2jNGYPAS7mFG/0xfyTVQlSYiM6xGtxnY7E0mrDWGH w1KfuwrvuEL4dWOrbm4zVVcJTL3+MG5eBSepKbSQsnsirkXo+m5JpeRBDedlX6dp806d 3csA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=WpG1X3a373xVfl8yLidXv5br7H62wslHHIgRygB5foc=; b=qoqYf873kCui7TmXEYXr8+RANB1q4YcWWtsxU/HK8Zx27mFkM6it9bjkVA003nSah3 StLkMj/qUfGmh0AzicYkR4U5r8cwSAP78tXg626AZyHF/w1Cf7dV20U5YuH3qZPyarzx Qnlm/ySwcLK3sOnH6gkDjTWNkhL/yixqy6wK9YI4+ZTdTjFNAo4uvupi3oFWpRHlXtXj VFiOY77RYEJGzCpWD/GJjL8kg0/pLsJgIz6nLGyvWvwjZs9IYE5csAC4TviPRQqm4a92 vDjlUasoXdDqc/wAYHmHBO/RG+d2A9AHqRuO7xXZDqIB1He6vKwgnMYpqKbeeRnaCeit Mx/A==
X-Gm-Message-State: AOAM5310SVsFcCdqGilRjhleVzbbRvYWp0U4Rzyv5vxbmGXZ1stnsHe4 /TTbuJ0Fn3+DHsclWkNoc2MzcVR5
X-Google-Smtp-Source: ABdhPJzQIDmiy8g6fDyXJJ4vMdCjOrvzwF+lBnd+R7qde71PfWUp+C/cblaiKHnbpZjHUUaFZ3hEsQ==
X-Received: by 2002:a05:6830:22ee:: with SMTP id t14mr20210525otc.92.1592938154039;  Tue, 23 Jun 2020 11:49:14 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a4e4:2f6a:9ede:19d0? ([2600:1700:a3a0:4c80:a4e4:2f6a:9ede:19d0]) by smtp.gmail.com with ESMTPSA id x21sm4390141ooq.24.2020.06.23.11.49.12 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 11:49:13 -0700 (PDT)
To: IETF DMARC WG 
From: Dave Crocker 
Message-ID: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Date: Tue, 23 Jun 2020 11:49:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 18:49:21 -0000

Folks,

This note is partially triggered by Mike's note this morning, but isn't 
specifically responding to it.  Rather it tries to elaborate on a 
premise I've been implying but haven't been explicating:

      What if the rfc5322.Sender field were typically/always present?

      Or at least, what if it were always present for domains publishing
      DMARC records?


What if messages generally had Sender: fields, even when they are the 
same as the email address of the From: field?  So for such domains the 
From: really would only be the author information and the Sender: would 
be the operational handling/sending information.(*)

The thrust of my reference to making a separate Sender: field prevalent 
is an assumption that the patterns of evaluating email addresses could 
adapt to take advantage of the reliable distinction.  For one thing, it 
could clarify the nature of the information used for filtering. 
Currently we conflate 'handling agent' (or 'transmission agent') 
information with 'authoring agent' information.

This leads to statements about end-user effects that actually are 
fundamentally wrong, even as the use of supposed author address 
information is demonstrating filtering efficacy.  What would happen if 
filtering agents had an explicit distinction between 'author' and 
'sender'?

It might be claimed that they already do, since the DKIM d= field refers 
to a handling agent, rather than author, and is explicitly independent 
of any other message address information.

So, why isn't it reasonable, for example, to have DMARC publish a record 
declaring a requirement for a DKIM or SPF record, independent of From: 
field alignment?  That is, publish a record that says all mail by agents 
of that domain is always authenticated?

It's because the signature needs to be tied to a field that is already 
'interesting' and always present.  Otherwise there is no way to know 
what domain name to look for.  In practical terms, the only available 
choice has been From:.  First, it certainly has an interesting semantic 
-- but really semantic/s/ -- for the address, and second, it's always 
present.

So... what if DMARC's semantic were really for the Sender: field?  If a 
message has no separate Sender: field, then of course the domain in the 
From: field is used.

The would produce obvious possibilities:

    From: someone@goodplace.example
    Sender: someone@goodplace.example

and

    From: somone@goodplace.example
    Sender: someone@mlm.example.com

where there might be a dmarc record for mlm.example.com

The modification to DMARC would be "look for Sender: and if it isn't 
present, look for From:.

Obviously, mlm.example.com might instead be badactor.example.com.

but we already have to deal with cousin domains, and DMARC does nothing 
about them.

So if Sender: wouldn't be as useful as From:, why not?



d/



(*)  Mike took exception to my using "processing" as a term for Sender:. 
  He's probably right and it might be worth some separate discussion to 
make sure there is useful and precise language to cover what the 
semantic of Sender: should/must represent.  There is a continuing 
problem in the industry that the word "sender" is used to cover all 
sorts of agents, from author, to originating MTA, to Mediating MTA. 
Should it be 'any agent that touches the message' or 'any agent the does 
a sending operation of the message' or 'the specific agent the posts the 
message into the mail handling system' or something else?
      Note that for mail going through a mediator, there are at least 
two entities qualifying for the 'posting' definition:  The author's 
originating MSA and the MLM's MSA.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Jun 23 16:08:36 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992873A0C28 for ; Tue, 23 Jun 2020 16:08:34 -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 (1024-bit key) header.d=bayviewphysicians.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 y4aTE4XJCMuW for ; Tue, 23 Jun 2020 16:08:32 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572FB3A0C27 for ; Tue, 23 Jun 2020 16:08:32 -0700 (PDT)
X-ASG-Debug-ID: 1592953710-11fa313a10228280001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id ogH94MeTbPYufmzB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 23 Jun 2020 19:08:30 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=FbgYb77T3GNyIx8za2Dw2T83L59Ze8dwK2+LVGL30is=; b=HowPXQwg7vBOS/dFKRBlXxEnxNBi7fQ8f1+qCO9c8lSyasMZSLiywM6i9T815mq01 5834f5qmcd+/CxHNAqV3Boda/fW7Kths7oBSlqOhlvIIgJzuum0/LM5ih6M8RxTay 6h+u+n1pd7WJyfihcq8ZIBt4dSTqIpXyx5iek6k7o=
From: "Douglas E. Foster" 
To: "dmarc@ietf.org" 
Date: Tue, 23 Jun 2020 23:08:21 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging:  A solution proposal for  alternate authentication
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <6399963c834640cc8f3ba5f86924e495@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=614bced5b7184a628013bf03cd02cb5e
In-Reply-To: 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com> 
X-Exim-Id: 6399963c834640cc8f3ba5f86924e495
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1592953710
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 17273
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82762 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 23:08:35 -0000

This is a multipart message in MIME format.

--614bced5b7184a628013bf03cd02cb5e
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I believe this document provides a path forward for solving this problem, a=
nd it has relatively low complexity of implementation.

Doug Foster

 

Current situation

Incoming mail filters options when evaluating mailing list messages:Filter =
evaluates the message as if it is a direct message from the list domain    =
This is the header munging solution that creates problems for the MUA.  Thi=
s can also be achieved if the sender uses SRS encoding of the RFC5321 MailF=
rom address, and the incoming filter does no evaluation of the  =E2=80=9CFr=
om=E2=80=9D header  address.Filter evaluates the message as if it is a dire=
ct message from the originator domain, ignoring the evidence that the messa=
ge came from servers on the list domain, but accepting the message as long =
as it has a verifiable DKIM signature for the =E2=80=9CFrom=E2=80=9D header=
 address.   This is the situation when a DKIM-signed message is relayed wit=
hout modification.    Messages may be blocked by the incoming filter becaus=
e the list members are viewed as unfamiliar and therefore untrusted senders=
.

An ideal filtering configuration should recognize that there are three pote=
ntial mail flows, not two.    In an ideal world, all three should be identi=
fiable uniquely, since the recipient organization may wish to apply differe=
ntial policies:Direct messages from the list domain.Direct messages from th=
e originator domain.Forwarded messages from the originator domain through t=
he list.

As long as the mailing list applies signature-invalidating changes, Any opt=
ion requires that the incoming filter chooses to given enhanced trust to th=
e list domain.  Specific aspects of that trust:The list performs no decepti=
on.  Header records are relayed legitimately.The list inserts no malicious =
content.The list has reasonable controls on list enrollment.The list has re=
asonable controls to ensure that list submissions are really from the state=
d email address.The list applies its best effort to block content that the =
recipient systems would find objectionable.If objectionable content is dete=
cted, the fault should be attributed to the originator, not the list domain=
, so that list message from other originators will continue to be accepted.

Once trust is granted to the list, SPF and DKIM checking of the originator =
becomes relaxed:SPF and DKIM checking can be computed using relayed header =
information, because the incoming filter trusts that the headers are not fr=
audulent, orSPF and DKIM checking can be omitted, because the incoming filt=
er trusts the controls applied by the list.

A few issues remain:How does the incoming filter prove that the message is =
really from the list, rather than someone spoofing the list?   Since the RF=
C5321 M
    I believe this doc=
ument provides a path forward for solving this problem, and it has relative=
ly low complexity of implementation.

    Doug Foster

     
    Current situation
    Inco=
ming mail filters options when evaluating mailing list messages:
      Filter evaluates the message as if it is a direct message from the list do=
main    This is the header munging solution that creates problems=
 for the MUA.  This can also be achieved if the sender uses SRS encodi=
ng of the RFC5321 MailFrom address, and the incoming filter does no evaluat=
ion of the  =E2=80=9CFrom=E2=80=9D header  address.

    • Filte=
r evaluates the message as if it is a direct message from the originator do=
main, ignoring the evidence that the message came from servers on the list =
domain, but accepting the message as long as it has a verifiable DKIM signa=
ture for the =E2=80=9CFrom=E2=80=9D header address.   This is the situ=
ation when a DKIM-signed message is relayed without modification.   &n=
bsp;Messages may be blocked by the incoming filter because the list members=
 are viewed as unfamiliar and therefore untrusted senders.
    =
An ideal filtering configuration should recognize that there are three pote=
ntial mail flows, not two.    In an ideal world, all three should=
 be identifiable uniquely, since the recipient organization may wish to app=
ly differential policies:
    • Direct messages from the list domain.<=
/li>
    • Direct messages from the originator domain.
    • Forwarded messa=
ges from the originator domain through the list.
    As long as=
 the mailing list applies signature-invalidating changes, Any option requir=
es that the incoming filter chooses to given enhanced trust to the list dom=
ain.  Specific aspects of that trust:
    • The list performs no =
deception.  Header records are relayed legitimately.
    • The list =
inserts no malicious content.
    • The list has reasonable controls on l=
ist enrollment.
    • The list has reasonable controls to ensure that lis=
t submissions are really from the stated email address.
    • The list ap=
plies its best effort to block content that the recipient systems would fin=
d objectionable.
    • If objectionable content is detected, the fault sh=
ould be attributed to the originator, not the list domain, so that list mes=
sage from other originators will continue to be accepted.
    O=
nce trust is granted to the list, SPF and DKIM checking of the originator b=
ecomes relaxed:
    • SPF and DKIM checking can be computed using rela=
yed header information, because the incoming filter trusts that the headers=
 are not fraudulent, or
    • SPF and DKIM checking can be omitted, becau=
se the incoming filter trusts the controls applied by the list.
    A few issues remain:
    • How does the incoming filter prove tha=
t the message is really from the list, rather than someone spoofing the lis=
t?   Since the RFC5321 M<ail+From address and the
    • How does =
the list know that the incoming filter will allow them to bypass From-heade=
r rewrite?
    Alternate Authentication
    I begin by as=
suming that the incoming mail filter is willing to grant preferred treatmen=
t to the mailing list, and that this trust is obtained by administrative pr=
ocesses external to this document.   In the case of a new subscription=
 to a mailing list, the list may send an enrollment notice to the subscribe=
r, asking him to request preferred treatment from his email security team. =
  Once that administrative grant has been obtained, the technical side=
 can be configured to allow list authentication and originator authenticati=
on to be performed using alternate algorithms.
    I also assume that=
 messages exchanged using an alternate authentication algorithm will preser=
ve the originator value for RFC5321 MAILFROM and RFC5322 =E2=80=9CFrom=
=E2=80=9D header address.   (No SRS encoding.)  
    For li=
sts, I propose that the list source be verified by applying the LIST-ID add=
ress to the SPF algorithm. For other types of forwarders, I propose that Po=
stmaster@Helodomain be passed o the SPF algorithm.      Chec=
king for a verifiable DKIM signature which aligns with those addresses woul=
d be an additional option, or a cautious incoming filter might require both=
 SPF and DKIM to verify.  The configured requirements need not be stan=
dardized.  I tentatively call this FWDRAUTH =E2=80=93 alternate authen=
tication of a forwarder.
    Once the forwarding tests have been pass=
ed, the incoming filter has a range of options for evaluating the originato=
r:
    • No checking =E2=80=93 assume that the originator was adequate=
ly verified by the forwarding system=E2=80=99s controls.
    • DKIM =
=E2=80=93 For messages that were not altered during the forwarding process,=
 a DKIM-verified signature can be matched to the From header address.
      • <=
li>Authentication Results Chain =E2=80=93 accept ARC results provided by th=
e forwarder, describing the tests performed by the forwarder when the messa=
ge was received.
    • Inferred SPF =E2=80=93 Parse the received header c=
hain to determine when the message entered the forwarding domain, and evalu=
ate SPF based on the IP address of the server that submitted the message to=
 the forwarder.
    Again, the choice of techniques is specific=
 to the incoming filter, and need not be standardized.   All that matt=
ers is that the incoming filter has the capability to evaluate the list and=
 the originator using alternate authentication methods.  Collectively,=
 these alternate authentication algorithms allow the From address to match =
the originator without causing desired messages to be blocked.
    F=
orwarder Notification
    All of the above is useless unless the mail=
ing list or other forwarder knows that a particular subscriber can evaluate=
 messages using Alternate Authentication, so a signalling technique is need=
ed, in the form of a DNS entry , within the recipient domain, that the forw=
arder can use to verify that the recipient domain has the ability to apply =
alternate authentication.
    My current thinking is that this would =
be as simple as txt=3D=E2=80=9DFWDAUTH v-1=E2=80=9D.   It seems too co=
mplex and too risky for the receiving domain to publish the specific lists =
for which it is willing to apply alternate authentication.   But if th=
e forward detects the signal, it can invoke supporting administrative proce=
sses, including test messages, to determine if the alternate authentication=
 method is successful.
    Changes required for implementation:
  • At least some email recipient filters would need to implement the cod=
e for alternate authentication, then publish the DNS entry to indicate that=
 it is available.
  • MLMs would need to track which approach to use fo=
r each recipient:   For recipients that can use the alternate authenti=
cation method, messages would be sent without header munging.   For re=
cipients that do not use the alternate authentication method, header mungin=
g would still be needed.
    •          =
                     &nbs=
p;           

    

--614bced5b7184a628013bf03cd02cb5e--


From nobody Tue Jun 23 16:14:52 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9075C3A0C2D for ; Tue, 23 Jun 2020 16:14:50 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 7qCrUNQDJCgP for ; Tue, 23 Jun 2020 16:14:49 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 4C37C3A0C2B for ; Tue, 23 Jun 2020 16:14:49 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:e5a2:79be:9620:e0a0]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05NNEj6A032136 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 23 Jun 2020 16:14:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1592954087; bh=psr69KrY3bsab3bqNxg90Pm20HO47Q1oQtONnlp7i1g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=t/ELRPOG9NCGChCDQJrPuGQfGEUYcT60VrqvjVyKK/gEVVY/eD2LagJ8hTuyQf5HF h3+vFu1qYcbgtaxPym7Nomx5XYT7dohYSSVyDPTr4laHbrA8nzPKmDGDqwQ2fVex3o iCBYuwLdffzGBW0xuSWyGKNJmf6tjTd6c2nk9ois=
To: Dave Crocker , IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: 
Date: Tue, 23 Jun 2020 16:14:39 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2020 23:14:51 -0000

On 6/23/20 11:49 AM, Dave Crocker wrote:
> So... what if DMARC's semantic were really for the Sender: field?=C2=A0=
 If
> a message has no separate Sender: field, then of course the domain in
> the From: field is used.
>
> The would produce obvious possibilities:
>
> =C2=A0=C2=A0 From: someone@goodplace.example
> =C2=A0=C2=A0 Sender: someone@goodplace.example
>
> and
>
> =C2=A0=C2=A0 From: somone@goodplace.example
> =C2=A0=C2=A0 Sender: someone@mlm.example.com
>
> where there might be a dmarc record for mlm.example.com
>
> The modification to DMARC would be "look for Sender: and if it isn't
> present, look for From:.
>
> Obviously, mlm.example.com might instead be badactor.example.com.
>
> but we already have to deal with cousin domains, and DMARC does
> nothing about them.
>
> So if Sender: wouldn't be as useful as From:, why not?

This makes a lot of sense to me, assuming of course that the WG comes to
rough consensus that alignment specifically with the From: domain isn't
necessary. (My personal position is that it's not.)

I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
(IETF's current MLM usage may, as well). But that possible problem could
be avoided by inventing a new header field (I can't believe I'm
suggesting that), it could be DMARC-Sender: or something like that. If
we're going to avoid From: rewriting, we need to have something that
specifies where to retrieve the DMARC record from.

But as stated above, [DMARC-]Sender: could be badactor.example.com, so
it should be clear that DMARC is not going to prevent bad actors from
doing anything. It is still useful as a reporting mechanism to detect
unintended breakage of message authentication. But I can't think of a
reason that the policy mechanism is useful at all.

-Jim




From nobody Tue Jun 23 21:20:11 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9043A07F5 for ; Tue, 23 Jun 2020 21:20:04 -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, FREEMAIL_FROM=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=gmail.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 muhixn8kUabG for ; Tue, 23 Jun 2020 21:20:02 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 738CF3A07EA for ; Tue, 23 Jun 2020 21:20:02 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id t6so663084otk.9 for ; Tue, 23 Jun 2020 21:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=kgblQU/PIimoF6gh8tRxELyjktU4ag+Gyf539BDAL2I=; b=IOx2JNcmCfSejtphVSAKgGaJNWXT0e9kSoWyeSQegRuTB/5CBE7TrXNwEF75LzJOV1 d8blt0kpRT5dQfzEgNe6H6DgZ4JujnvNders1eNp+nkJswN2tUk4/6wEpmx8iy96bcVy I8EHRanbXECHPUzqrrscSTpfHKdWm+19YK1AtTr9T7cHobf7IpgBLiNNmIrLAGLTQoj6 PMqKM+vlxZtqKRt/yysQhaJ7G0/l1cPd7JHhlgj1No8mR/GOLxSaMs2pzyYq91NX9dSV 1Wdde2X0NtRUrnQMpOTMqRGEwWAvqZdKX+obHyoNd1IJA3xEd6hq11918jP8alY5H4iV ybIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kgblQU/PIimoF6gh8tRxELyjktU4ag+Gyf539BDAL2I=; b=i5gDFB9wt3mQEEMqi6bfyMrpQ9qpoMh/TOcmgDkZdwk3gi882/DEnvATyomQY+S5WM mGnNaSCrw5tr1mQsysvo4t/6orbmL5BlBxJjzUUJt62zjDKGITDLXefQIO0s9JauNFJx gYbMW+/vsnalx5/Pfg03Q/4dCS/jZ5DR4+0SymUivX3fXok/H9c1mQf+ZyFkYQDeDNDR k2Zi9L9/xd/BURrK5cumW7I/NHUx6+Kmla4JOp6Rl68Z2Thde5fjUySCO0omf4vrTa/U slTO8zVq3mcGC8PWAGmK0MdQBXQ8KY6hD40H62HMqQKyXRXjShJNkMsS0x/m7EXgP1QC YlWA==
X-Gm-Message-State: AOAM531DUkISTHZeureCk60dVa7W7oL0DWXF6MUSLEfd/hXmr9m5iX/R K3dS50VQ+jsjpBTGZXlL67pRztsT
X-Google-Smtp-Source: ABdhPJy78L7hdURlDxlj+Sfix0LTd/yMUd8NPy/1Ed6t/9knezlabdsArGY2h/P3WAH9FmpzqvYi5g==
X-Received: by 2002:a4a:d1cb:: with SMTP id a11mr9092752oos.63.1592972401476;  Tue, 23 Jun 2020 21:20:01 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a4e4:2f6a:9ede:19d0? ([2600:1700:a3a0:4c80:a4e4:2f6a:9ede:19d0]) by smtp.gmail.com with ESMTPSA id v20sm4572608otq.64.2020.06.23.21.20.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 21:20:00 -0700 (PDT)
To: Jim Fenton 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> 
Cc: IETF DMARC WG 
From: Dave Crocker 
Message-ID: <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>
Date: Tue, 23 Jun 2020 21:19:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 04:20:10 -0000

On 6/23/2020 4:14 PM, Jim Fenton wrote:
> I do have a concern about Sender:. It has existing semantics defined in
> RFC 5322 Section 3.6.2, and this proposal might conflict with that


I don't think it conflicts at all. So it will help for you to explain 
your concern in detail.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Jun 23 22:00:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF263A07E9 for ; Tue, 23 Jun 2020 22:00:26 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2DlPolfQ6Mbs for ; Tue, 23 Jun 2020 22:00:25 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 49DE93A07E8 for ; Tue, 23 Jun 2020 22:00:25 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id e15so666198vsc.7 for ; Tue, 23 Jun 2020 22:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QuVMqfaMvOWMKDtFurOZFXL1sDyZI5yICcRplTFAtLU=; b=S4/XGGizi8N8ddvBtrCoyldfgsLT9a4SJ8pyXvN1U3u2x5BoWPWGSixaUw+y+MeTOL 2v+w/lYH2hX2opJ03u1qNtfcFqwGl04T/A891Zg8NPE95kay0vy2FgyFh52fk3/e5tdC B08zd2wtw+OJMxTOosHk1sYPSCjpU7TxG8h2NHEfMS+6F930TsNSA3WqnE/rK1vC2DJK Pic4XWB7n+XzDkBi1VW8e0ddMxhA/FVeDciPCbSLscuNPWqYKXx7JqJRUOj/iByziO6c F9hi8Mn/kW+VbNqYlryL56pu0iNHaijU2Ws9a/P/wI23J1QwYCzgl/hDjq9iJGKst1r7 IIfQ==
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=QuVMqfaMvOWMKDtFurOZFXL1sDyZI5yICcRplTFAtLU=; b=UpicftGtd3xHdZrCxjjn7CD/2vP/0kr4uGTKmBGOOGt7tYm7slPOPfiBl1EqpMgnal iS3lfFF1PNwBj0028GElI8a0P8//Cj/Oan6yZu0YI6Q57Q+YrE84WpM0yQEhP1znAzhI MC6kcHnKeO6jrmtjlWZvxMRnI8ikZaarcg+Gx8+tGd7DPN9BVPa0i86MdSTSbC0ItzPk 7r/fpy2FuBvqRMHiTUru8TFHDSza+PSp+gejYCwu4QI/+GXNGpQ3vPPKrouVaLN+n8Pm lsIacmXeqj1erzow5kbwkdewdiv2Lq3foy9/tM2GgMukfZQQqePwRsg4bwGB5gne6CHZ 19DA==
X-Gm-Message-State: AOAM533Og/7WWzY1wKFeVEkmSbfH5vykthRKmKkdxzAds2Hy4migKjPy gRLVd7azEa7kUZpmFubrwyDMZwK21HkfcwaxYl0=
X-Google-Smtp-Source: ABdhPJyC/EuYxNbW7aaqeObNa97oxxRhbv0U2zaEBZxGD18LL9nyN2Xo3xz5TZjaD9WAAcoflEyPyjEQM77p63KBf2o=
X-Received: by 2002:a67:ed15:: with SMTP id l21mr22673261vsp.175.1592974824075;  Tue, 23 Jun 2020 22:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>  <6399963c834640cc8f3ba5f86924e495@bayviewphysicians.com>
In-Reply-To: <6399963c834640cc8f3ba5f86924e495@bayviewphysicians.com>
From: "Murray S. Kucherawy" 
Date: Tue, 23 Jun 2020 22:00:13 -0700
Message-ID: 
To: fosterd@bayviewphysicians.com
Cc: "dmarc@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 05:00:26 -0000

On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster
 wrote:
> A few issues remain:
>
> How does the incoming filter prove that the message is really from the list, rather than someone spoofing the list?   Since the RFC5321 M
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4C13A0CEC for ; Wed, 24 Jun 2020 02:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk
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 6V0krGLrp3tc for ; Wed, 24 Jun 2020 02:56:18 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110115.outbound.protection.outlook.com [40.107.11.115]) (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 76DD93A0BF9 for ; Wed, 24 Jun 2020 02:56:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P57wSBjDu/8vlLD0U5hxy16IlzvTJVakOKHSBUkJ5mudvnhiAyGA9T+G2V2Np5GTBeJ87pAgRP633CjWN//V0bbQ3Ec7Zm4BZpfIvkZ1OUgI0ykXihrLOYzoTWewlEP+54Ih/wooB/hlL1mNJcXqVjUUEGJDYcommB7SEbtI8gmckALJg5Z9NTTAedSKrCh8kxnjXDD7JbrxF8EarV88JnVaC/WoZ05YD1aFOXeMcIxt8lU6sLmTOYuuzK06ISrzR91ylT+V8eD1koQx4YeyXT0S89FAw2ZWznmqL5i5Z0Jtafog6w7I6XyHyrkS32jNZGL/Ch7bOcSwUCkTeW30xA==
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=5ek40KkfX7E2dxTEXOftrpGgAWiQljNyO7xvwd92LWk=; b=F3SPGYeEPowOdHKHUsiEPUPld9AqnRGtZPbKThAE77tVgc3MabZrlu04ssiRtEchpnQ87BQ1zdZv0qn+LfIUH5BAYOG31oMDrdZ5kyMe8UENPvzAs9tFHB+02kY0/uWyrjqHptrvz6iL3s4OoV4ASa32ldOeb8x6gWeHl1hOqS0KixHNYVrHanzONDLnYXh/oRK4SpyPQLoblPc9QaQdyKbJwestp3YPtK8KfyiEuz/rTOzjbMhSkuvrdnqPcrZELOFF9qdbB4b55wZZ/IyseYtTwv8HFRtPB0sqAEh2Zx2UFCZdKc7QKa7X97AdEL8vZJ3sHTdHapztHS2EEnbE1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5ek40KkfX7E2dxTEXOftrpGgAWiQljNyO7xvwd92LWk=; b=EnHlxjaGWfe9M87DyL3FEvqsWfnEUQZH4EnNF/LJsVAUgh+EDUHN8Ydf4V4CSuXweympQXc6TdYsU6hOzQaSpkzIRhmszqcKRTAzah5RkbbKS+4/tF5V+pjddXeoq9nBGYy5CVUtuTFFDgOJj6FhohaAmfRkA3v+zwDWRiqzk4oeYbAcrjcSBIU3bICCWKJGcq3BfF3oUFTjGszP25uFE4CdYUAuT8H9BPiSwHQSFvzfnDAARmrdZMBeYB1r75okZiRUShTMhCpov3aX/unSVtIa7CYvKv0aYcCzlS/hTKOJqZWSO9LmMe+moZtZc9M2E7KPf6qUz6KeAtkII31wsw==
Received: from CWLP123MB2177.GBRP123.PROD.OUTLOOK.COM (2603:10a6:401:6d::18) by CWLP123MB3235.GBRP123.PROD.OUTLOOK.COM (2603:10a6:400:53::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 24 Jun 2020 09:56:16 +0000
Received: from CWLP123MB2177.GBRP123.PROD.OUTLOOK.COM ([fe80::6d63:6f5e:210e:e83c]) by CWLP123MB2177.GBRP123.PROD.OUTLOOK.COM ([fe80::6d63:6f5e:210e:e83c%7]) with mapi id 15.20.3131.020; Wed, 24 Jun 2020 09:56:16 +0000
From: David I 
To: Dave Crocker , IETF DMARC WG 
Thread-Topic: [dmarc-ietf] What if... Sender:
Thread-Index: AQHWSY8PY6KKw8Z6qkO2oAr/+0mQJajndpXA
Date: Wed, 24 Jun 2020 09:56:16 +0000
Message-ID: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk;
x-originating-ip: [51.140.78.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e080f1e3-4da9-4186-4414-08d81824d629
x-ms-traffictypediagnostic: CWLP123MB3235:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0444EB1997
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 16PEtMXjzBr+aH6tiy6zLHcsLvtvLoDSVqecERU/z/iKPdm3+eZFbtB1Aeau+d7VEhnIhb+BqlIltoUetFjvyoL+VmvVaWXQlmwd9+YblT8XI1xXl95dqQPymMX1PM75l4y55iKb+hNRyTYEdUkiu/q4Lw1uS0yHBgPxYHjSkb0CpzQUV/56jH/yDT/WFY+725/Wzr3yHPiQuSxHtaAcJX3gdiNjbuZvbINr5sgwFD6J8r16Kqc0kBj2FPYnOyzwDttTCTikZXjPG+h35QSKwHW9/mpX5mfwTWKZakR0Jw57tTsmWnKxFW9EiS0naxcmZ3KPzmUlFrwSfowJb1lgwQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CWLP123MB2177.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39850400004)(366004)(136003)(346002)(396003)(376002)(5660300002)(66446008)(76116006)(66556008)(66476007)(66946007)(64756008)(2906002)(478600001)(33656002)(71200400001)(9686003)(55016002)(86362001)(83380400001)(186003)(55236004)(316002)(26005)(6506007)(8676002)(7696005)(110136005)(52536014)(8936002)(53546011); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: 8U+BVrWEJigwBMPDwZMVbxSxG8TLeI0jPVt28sMdbLdYLeuGkzfYvI6L1vr6LhqwxqmyeOjxe5PfDdlDgwgeRFjUeKJINnkW426LI0W/yVZ9JsFEDh2odGFKOW84QKiY+q6HER5TDLoeZwAQa7ShIG10zuIeYur/UqdUU9XNeAs2hM4yfgFx1aihoUlXfRvyBr6ncG/GfJ5pofcOP9EyBHHrVyG0PBG6VyfDwM87QEUcnXiDkNIePwAB+5l4oogPucp5HOAi1Ess/eHFIqlZMAQUCdEgjtgXH/nDaoq+il6XkW08nKGTN1zox+Gp2pYZpgD6amjKIgJGV8HEAB68ph9kKRi1ClDHOZxoZY8njGRJIo6z3OyISHeTylduyXwDLysVyY4u/2DQJOBUwcyG6qEx6iN3wSk55/u/kcLvgk+eVdqIBxPtW/pFyJlZGwl+vJDlUkEKcISzYRCeLl3RnqVKXpb8yA54/xpYy2PmHb4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CWLP123MB2177.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e080f1e3-4da9-4186-4414-08d81824d629
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 09:56:16.2813 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HbPt6obcvRFxuEfQcHAmyT3dvOMeYcXchuezMWsRnNlWgQOm+HFFwY9U/Gy6YJpuDnneRBCEAgo9VTOq8c9J7Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB3235
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 09:56:20 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNl
c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhdmUgQ3JvY2tlcg0KPiBTZW50OiAyMyBKdW5lIDIw
MjAgMTk6NDkNCj4gVG86IElFVEYgRE1BUkMgV0cgPGRtYXJjQGlldGYub3JnPg0KPiBTdWJqZWN0
OiBbZG1hcmMtaWV0Zl0gV2hhdCBpZi4uLiBTZW5kZXI6DQo+DQo+ICBbLi4uXQ0KPiBTbyBpZiBT
ZW5kZXI6IHdvdWxkbid0IGJlIGFzIHVzZWZ1bCBhcyBGcm9tOiwgd2h5IG5vdD8NCj4NCg0KSGkg
RGF2ZSwNCkkgZG9uJ3QgdGhpbmsgdGhpcyBhbGxvd3Mgc29tZSBvZiB0aGUgaW1wb3J0YW50IGF1
dG9tYXRlZCBmaWx0ZXJpbmcgd2hpY2ggYWxpZ25tZW50IG9uICdGcm9tJyBkb2VzIChwdXR0aW5n
IHRoZSB1c2VyLWltcG9ydGFuY2UgY2FuIG9mIHdvcm1zIGFib3V0IEZyb20gYXNpZGUgZm9yIGEg
bW9tZW50LCB0aG91Z2ggbm90IGNvbmNlZGluZyBpdCkuDQoNClNwZWNpZmljYWxseSwgYWxpZ25t
ZW50IG9uICdGcm9tJyBhbGxvd3MgYXV0b21hdGVkIGNoZWNrcyBhZ2FpbnN0IGFkZHJlc3NlcyBv
ZiBrbm93biwgdHJ1c3RlZCBjb250YWN0cyBmcm9tIGFkZHJlc3Nib29rcyAtIHRoYXQgYW4gZW1h
aWwgaXMgYXV0aGVudGljYXRlZCBmb3IgdGhlIGRvbWFpbiBmcm9tIHRoZSBhZGRyZXNzYm9vaywg
YW5kIGhlbmNlIGxpa2VseSB0byBhY3R1YWxseSBiZSBmcm9tIHRoZSBjb250YWN0IChzaW1pbGFy
bHksIGl0IGNhbiBiZSB1c2VkIGZvciB0cnVzdGVkL2tub3duLWRvbWFpbnMgZWcgc2FtZS1kb21h
aW4pLiBUaGlzIGNhbiBiZSB1c2VkIGZvciBhdXRvbWF0ZWQgc2NvcmluZy9maWx0ZXJpbmcgdG8g
cHJldmVudCBhIG1hbGljaW91cyAoc3BlYXIpcGhpc2hpbmcgZW1haWwgZnJvbSBhcHBlYXJpbmcg
aW4gYW4gaW5ib3guDQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBvZiBhIHZhbHVlIHdoaWNo
IGlzbid0IHJlbGF0ZWQgdG8gdGhlIGVudHJ5IGluIHRoZSBhZGRyZXNzYm9vaywgSSBkb24ndCBz
ZWUgaG93IHRoaXMga2luZCBvZiBjaGVja2luZy9maWx0ZXJpbmcgY2FuIGJlIGRvbmUsIGFuZCBz
byB3b3VsZG4ndCBiZSBhcyB1c2VmdWwuIFVubGVzcyB0aGVyZSdzIGEgd2F5IEkndmUgbWlzc2Vk
Pw0KDQpEYXZpZA0KVGhpcyBpbmZvcm1hdGlvbiBpcyBleGVtcHQgdW5kZXIgdGhlIEZyZWVkb20g
b2YgSW5mb3JtYXRpb24gQWN0IDIwMDAgKEZPSUEpIGFuZCBtYXkgYmUgZXhlbXB0IHVuZGVyIG90
aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9uLiBSZWZlciBhbnkgRk9JQSBxdWVyaWVzIHRv
IG5jc2NpbmZvbGVnQG5jc2MuZ292LnVrLiBBbGwgbWF0ZXJpYWwgaXMgVUsgQ3Jvd24gQ29weXJp
Z2h0IMKpDQo=


From nobody Wed Jun 24 05:01:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0103A0D82 for ; Wed, 24 Jun 2020 05:01:30 -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 (1024-bit key) header.d=bayviewphysicians.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 mqUdjaAQ-FbL for ; Wed, 24 Jun 2020 05:01:29 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6715C3A0D81 for ; Wed, 24 Jun 2020 05:01:29 -0700 (PDT)
X-ASG-Debug-ID: 1593000087-11fa313a1022b240001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vtUf8iO63eMxCnpu (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 24 Jun 2020 08:01:27 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=X4Cmonv0P229xty/bBMCNyZybp3Qp9ZpRVimXYkTQ28=; b=h1yC51G+pcfpR0zUsUVHjczSKYaF3aZYTikSTj9fy6KfDekpPqX8cO3at9eoQBv5h PPJtjQeQc7I2M/KHYFYTALtci6IBo0N7irmj6M6QhwbUkUFPBTByqK/aq7S4hkXQf dY5/UlrveiBK2ILRv0MHRAtXCHlS+/nHdfwmknqNg=
From: "Douglas E. Foster" 
To: "dmarc@ietf.org" 
Date: Wed, 24 Jun 2020 12:01:18 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <35e89e8b9f9846b3ab68acac4252dc09@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=35f35557aa544e999f196f0e9a31f270
In-Reply-To: 
References: <20200615174422.9405A1ABFF41@ary.qy>  <2598929.Ph2NfEyP8u@sk-desktop> <7296aa6b-1f7e-cb97-b756-857690c54bac@tana.it> <0F22234A-5A43-4473-8E67-B76C01CDA10F@episteme.net> <9f84e74a-cba5-fbd3-1e70-c60bb0848e6a@gmail.com>  <25bea41a-b165-99d8-f938-eb95225fa63c@tana.it> <39da11d2-f622-92c7-30c9-c1867e8867c4@gmail.com>  <6399963c834640cc8f3ba5f86924e495@bayviewphysicians.com> 
X-Exim-Id: 35e89e8b9f9846b3ab68acac4252dc09
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593000087
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 2300
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82775 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 12:01:31 -0000

This is a multipart message in MIME format.

--35f35557aa544e999f196f0e9a31f270
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Good question, Murray.    Please ignore the broken sentence, as I think it =
was text intended for somewhere else in the document.   I just reread and f=
ound a few other typos, but not enough to require a resend of the whole doc=
ument.   My proofreading should have been better.

Doug Foster

----------------------------------------
From: "Murray S. Kucherawy" 
Sent: 6/24/20 1:00 AM
To: fosterd@bayviewphysicians.com
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate=
 authentication
On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster
 wrote:
> A few issues remain:
>
> How does the incoming filter prove that the message is really from the li=
st, rather than someone spoofing the list? Since the RFC5321 M
    Good question, Mur=
ray.    Please ignore the broken sentence, as I think it was text=
 intended for somewhere else in the document.   I just reread and foun=
d a few other typos, but not enough to require a resend of the whole docume=
nt.   My proofreading should have been better.

    Doug Foster



    F=
rom: "Murray S. Kucherawy" <superuser@gmail.com>
    =
Sent: 6/24/20 1:00 AM
    To: fosterd@bayviewphysi=
cians.com
    Cc: "dmarc@ietf.org" <dmarc@ietf.org>Subject: Re: [dmarc-ietf] Header munging: A solution pro=
posal for alternate authentication
    On Tue, Jun 23, 2020 at=
 4:08 PM Douglas E. Foster
    <fosterd@bayviewphysicians.com> =
wrote:
    > A few issues remain:
    >
    > Ho=
w does the incoming filter prove that the message is really from the list, =
rather than someone spoofing the list? Since the RFC5321 M<ail+From addr=
ess and the

    Was there supposed to be more to this =
line?

    -MSK

    

--35f35557aa544e999f196f0e9a31f270--


From nobody Wed Jun 24 06:43:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17E43A0C55 for ; Wed, 24 Jun 2020 01:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 KQoe2dwUJCNs for ; Wed, 24 Jun 2020 01:25:03 -0700 (PDT)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) (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 41A613A0C50 for ; Wed, 24 Jun 2020 01:25:02 -0700 (PDT)
Received: from [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4] (unknown [IPv6:2001:41d0:fe87:7000:3c9e:1555:a978:e1d4]) (Authenticated sender: baptiste.carvello) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 1D0EE200381 for ; Wed, 24 Jun 2020 10:24:59 +0200 (CEST)
To: dmarc@ietf.org
References:  <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net> 
From: devel2020@baptiste-carvello.net
Message-ID: 
Date: Wed, 24 Jun 2020 10:24:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr-FR
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Wed, 24 Jun 2020 06:43:24 -0700
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 08:25:05 -0000

Hi,

just answering this one bit, which I believe is at the heart of the 
disagreement:

Le 22/06/2020 à 21:44, Brandon Long a écrit :
> 
> [...]  It's the majority which are 
> routinely subjected
> to phishing and spam messages... 

IMHO "phishing and spam messages" is way too broad a concept to permit 
useful discussion. DMARC nowadays addresses a whole range of problems of 
varying severity to the end user.

When protecting security-sensitive domains like banks, where phishing is 
a major threat to the end user, a fail-closed policy is a necessity, and 
incompatibility with some uses is acceptable.

However, mailboxes with no special security needs call for a different 
tradeoff. From the end user's point of view, spam or addressbook-based 
phishing attempts are small annoyances that they somehow deal with 
(otherwise, they couldn't be using e-mail today). The goal here is an 
incremental win over an acceptable statu quo, not a revolution. No 
legitimate communication should thus be made to ressort to tedious 
workarounds to send mail (mailing-list users having to send every 
message twice, really?) or to find out who said what.

Cheers,
Baptiste


From nobody Wed Jun 24 06:47:43 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AF93A0DD1 for ; Wed, 24 Jun 2020 06:47:42 -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, FREEMAIL_FROM=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=gmail.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 dLhkzYVyMgcD for ; Wed, 24 Jun 2020 06:47:41 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 85EB03A0D7B for ; Wed, 24 Jun 2020 06:47:41 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id w17so1162309oie.6 for ; Wed, 24 Jun 2020 06:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=n1m5pZZSbhWsLXaNHAE5XPkbY7LqShUEpdgX27PgpB4=; b=OGzpW9ebDlUGvmlhG9SgPY0DgiEbHAt0tim88a1ZpCF4oxoOp+Pnj37avrklxqWk2Q lg0Ykc/NbUIXa04EeE/DYAsMIKFBmxQQHL3/WS/tXbi64I5/4omC16svUbAS30LMXRjn Iv3jdmTx/omCX9OvKTYkx0k9Nmdh8NAR5df5S48zVpticIwgY2rBOwsaHH076fYw9uJO YvvN6l08j3gs5z1tRBWITIgjci/pSj0oqJCw6hQjJnUDB1Ofm9+e46TOQTZ5x3FmEmYG wMLxaVTUTOq2J1fjejlNnonOhjOnCXGwSjV0QyDOec9TBgtOa8qeOtYa98zmMllg8uO4 3LTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=n1m5pZZSbhWsLXaNHAE5XPkbY7LqShUEpdgX27PgpB4=; b=K0fZvZuCGyL8D9dybJj5eqVJNASg5FRMVqb/gV5eAuTO7d5wnalWhivnea+VzAMVqP PAY5aFXXuijHUiA7kCqalVEH7e0kQ5unag2fmuQg9CMLA7x1b119N+caWygaBxbwyU3O hrZrPG5XtdB9Ser0envNcnJ2uvxozfww1wixPmHkgVDoDR17lsU2B7m/kEWt78iEClvY 8rapJTEqBf1OtSU2GlLMTpbgSIUUIt86LNsB6EKZRYwoDYL30HB5HwJS7rk/fkbDGXcn hi0uoB3sibNv+PoYrQk4L0ub/ze/TAXwgRjsKuSm3xsLKK57BUMperTT2U1i1hLbO+V4 2Fpg==
X-Gm-Message-State: AOAM5302PVwMMEZcMJlQZWYDWfu2YfWw6RI0TnBHhl986fIj7zT9v4pd gciNx+Eh68c1n0Q+J+hvFLzBrU9q
X-Google-Smtp-Source: ABdhPJyuhollmXhcGM16VTL/GEU6JwGpSEr9fmr5JGlWTJSocQoIhL3CJZFNRCCZAyITVxnTolioBA==
X-Received: by 2002:aca:6142:: with SMTP id v63mr6316319oib.66.1593006460615;  Wed, 24 Jun 2020 06:47:40 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id h187sm4684405oib.7.2020.06.24.06.47.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 06:47:39 -0700 (PDT)
To: David I , IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> 
From: Dave Crocker 
Message-ID: <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>
Date: Wed, 24 Jun 2020 06:47:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 13:47:43 -0000

On 6/24/2020 2:56 AM, David I wrote:
> Specifically, alignment on 'From' allows automated checks against addresses of known, trusted contacts from addressbooks

So does alignment on Sender.  Yes, the addresses in From: vs. Sender: 
might be different, but that doesn't mean the same assessment mechanisms 
that can be used on a From: address can't also be used on a Sender: address.


> If the authentication is of a value which isn't related to the entry in the addressbook, I don't see how this kind of checking/filtering can be done, and so wouldn't be as useful. Unless there's a way I've missed?

I suspect that very little -- if any -- of the current use of DMARC 
relies on an end-user's address book.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Jun 24 07:04:54 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293373A0DC3 for ; Wed, 24 Jun 2020 07:04:52 -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, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 W_Cx1PUfWATl for ; Wed, 24 Jun 2020 07:04:51 -0700 (PDT)
Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 161DD3A0DBD for ; Wed, 24 Jun 2020 07:04:50 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QCF00O8GOG1AS20@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 24 Jun 2020 09:04:49 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.6.24.135718, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.18.5740001, SenderIP=[104.47.66.47]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jFoAlGqXKszwtfQEywZl2pYyf7Fg6+V7N8AXIjKvmX3xX47lomrbWl5GmP/rqdqL8AXrX/vvsK/7XtNZHRrlRqsiqTHLc9pC2LcO12+ruMqToE8AmYI+z9EJuoTGcurqxSGUyZh6JhRrfFMlBe3p0VKwJVZb8GteCtxtn2U3c51M14hXItx79c+5mfYglHuNEp/IKdCeNC/xwDHCj4yd+uPL/AY1qRy/pq+2SxflFoBm4Vy7YMNDkIDl9xfTU0dY9E3lU0VrJ0PTftZZvMSBv5izFkDJdw6p8FBk8gKY1z6+66APPrhO/p81fAtY6rxRsA2EZPfkBticRLcyU4+r9A==
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=DoR5+Zuv6YwywzGQicluK1UFMAZmD1Rp2T8hLpzoN4s=; b=nk0Wr9Y18ten6tUxHDEUXWQekSk67rrPXEIZBWlouwWFHt98hSHL1HNQjMHrjji2tmUwnvNg3AEDgbGBQsddKbSGIs3jvgFSeHk9ZgINOW1cynw497BDsn7PByOdbujXUCzeSuWjLZm2K55FkNJwfQo7V6Nri7jRCj5xNs+dql2v1tGDx19xhLeAalnKVr/r7xsemZGI74jJDVzXpgDJeQMUZMsxINyO3vG28XtJB06Ro7zPa6ckPG2g/hFfj3pnaGBxjAUZtghitMV8kuJwGE1VbQYlrMZmqf7QU03UK7Cmh4L6RdD8ZXajTDmQxHeXnIRCFX8op0fnf7KVD/HBsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DoR5+Zuv6YwywzGQicluK1UFMAZmD1Rp2T8hLpzoN4s=; b=pqCx+c7Dg0OJUXu5kdKMdybnXTTRUT/9N2BbgfcbrDCIKq5xxmCljP3Lif+7nD5YvyJMNigxD2oIwp+Z1X5gb+OxD9Zaf47JWn0/MWIre2/wQgxbuQWj+4FfWUhlRxXQ44bkH9I7AEljUoyrxQ8ZirX/xvHUb8ekQNJSq2xExm4=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB6218.namprd06.prod.outlook.com (2603:10b6:5:127::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Wed, 24 Jun 2020 14:04:48 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 14:04:48 +0000
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
From: Jesse Thompson 
Message-id: <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>
Date: Wed, 24 Jun 2020 09:04:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0a1
In-reply-to: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 8bit
X-ClientProxiedBy: BL0PR02CA0013.namprd02.prod.outlook.com (2603:10b6:207:3c::26) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.24] (47.12.96.133) by BL0PR02CA0013.namprd02.prod.outlook.com (2603:10b6:207:3c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Wed, 24 Jun 2020 14:04:47 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 6b6a4e67-ad0d-4bb8-d597-08d818478e34
X-MS-TrafficTypeDiagnostic: DM6PR06MB6218:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:5797;
X-Forefront-PRVS: 0444EB1997
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Chl6N1jFWFiuCl3Egrh6KUoQjMT6iCo3liTspbaNoqN/p7Xr1LDatQ7fseFP1NZ5gDAMU3dBJ6ZTf9qFkvfIqezxOLf/HwxIQDT4rIUY4Dc4KJjl3nQd0SdnG+3suBZjL1mJeuxR79Km8JUsUAV7GZJfT1uAfZzuVeOAYm3hb3y8wfCeYl6jGK8OsBaFF1qaV8l0y5otQkC4zBM1HrI3EeotELRb/4UVNNhYic716OnSQwmhQ+y+kv27mABhpTsCJukwNh6UoHOckpd293ATdEZCzKRxkDD4SfMbolkTNcNpm72rFCmHpU0WQegwb2u19hYhozCcuJiBCXWxeTRTZf04IimF5ildqktCUkSI9AYOYR7PzhtTE7HviBGpawUP
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(396003)(366004)(39860400002)(346002)(136003)(376002)(5660300002)(86362001)(31696002)(478600001)(16576012)(36756003)(31686004)(66476007)(6916009)(75432002)(2906002)(558084003)(316002)(786003)(6486002)(66556008)(44832011)(16526019)(26005)(186003)(66946007)(83380400001)(2616005)(8676002)(53546011)(956004)(8936002)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: zBwNbDvkCCYrVzE+cIuOLqFoWFfSYa2+LJ9faRcJxBdEM9TDj9x0/XnmOa8hLKl0usVf53HYScAyeFsbWfjX/StGPT/CWvlVHYEsKXcHLqI+Kve/hswhmpkbTYeHVjbCzpdNj2/VQai5C88ZrlJr7R2G8uRp9MCdzajkx9CD5FepDcMMY2J4jx7OWN6YYFIBt0NzvvEOHNdoU/4ETJlumpND8ZSS7W27LDaMweDif09v102YccXiuqJr+bdstak2EbDGAdNr8WZ6AnliS1XchTLC3KeXVbFgOlvZDR6KgXmZlcohG1gwcpq8JrO32IvgG7YorNI1chYrvBQm+dNy6LKW+KAMoyG8V9zt4QqWhPRS6N1q3bfVdkMUhtjNIVHrG1PD0i4ItOJKkAs1qwO4vt6FhzjcohkD9zhhhh2eXhbZ43oX9zMsKMIkEFhvJeaRYWSEOYEpxNM8N9s0D7QcC6kaYw+4DuFMKOFmzYl668o=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b6a4e67-ad0d-4bb8-d597-08d818478e34
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2020 14:04:48.3325 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: j6F86B84R0HRPVokb9/wUlzzUFWwxOfEjnVm+jFurBI/vsRXvzCok6emjsB4gZG6jF3jq04ebBjUnhYhtSIrEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6218
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 14:04:52 -0000

On 6/23/20 1:49 PM, dcrocker@gmail.com wrote:
> So... what if DMARC's semantic were really for the Sender: field?  If a message has no separate Sender: field, then of course the domain in the From: field is used.

Wouldn't MUAs need to consistently display Sender?

Jesse


From nobody Wed Jun 24 07:07:36 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC923A0DE5 for ; Wed, 24 Jun 2020 07:07:35 -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, FREEMAIL_FROM=0.001, 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=gmail.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 8h9hNsoMfNpz for ; Wed, 24 Jun 2020 07:07:34 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 252883A0DE7 for ; Wed, 24 Jun 2020 07:07:34 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id 72so2019349otc.3 for ; Wed, 24 Jun 2020 07:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JIoosRhAo9FxBc3/sW9QE0FRZWAgXyKuzH6ss70T6+s=; b=F6Wq5oJz/mbwe4Ycu8iSnjAKrNsfD1qyQprz/cvswjJcKPRpqoYNWcexVzjnkOGHng tnO6pi+k6BrmLmk6m/Dz2Lp01G2d4qvOIItPcYEqjEAo60SuoEeMHmGR3AMUro5Qlaaf pAungJs4CSOxCWzkiTE7P1F1FFZ5Mhu+MRQ47G7ETcIh8lD5TbpXEbutx0gDYk4ONWFK AGy7s8d649JU9qhKVNCsfnXUHbw4hEq+wooKnGbRfGT91lCaiKN43v7+6aPmNO4AW6qi UlycYoDEzHPLx0G9/Wi0pQ2oIeefouUXT7ndMnnfRWjBbtFpiMhsgTlSTc6i0l2XcsVM 7aoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JIoosRhAo9FxBc3/sW9QE0FRZWAgXyKuzH6ss70T6+s=; b=dF+odHfifpjfKuLuJasid4qSOH4NKnGTZfMAK2zlDFRKakFvf6Zxr7VNt0ar/Mgwrf gbtBvcSlQu5PeLuOS798rTQ0cVFPCfIJhOJuE4TMaZC+3q+E5AyOHrU+ByuYMJGBiU6U 7Mjh32eV7Vo/Vp79lA2M1zLMKWPG4mF+kA04dreBm7rUvAf57CwFUn+vMs9r6Db6hz4O 2G5+fUqncM2VivTuDLDurWbzrWGAhmHYdJIBB9cqy+qeBUukmGr6WSrRxOYXE/TbkH9x T4zkui8esiwflOdy4o25z7cM3ZAFWOnruBxjSCrKZ0L24HqfVl7IlCAIdD1x11iBKWe6 YXGA==
X-Gm-Message-State: AOAM533qcJGpY1fPpO4rjgblXCJWQ3+Lej8mQKv/AOb/3lENNvyLB8gT LdSN6/B0ojuwlePN85Lo1jOe/SMm
X-Google-Smtp-Source: ABdhPJzB8iYKOlbev3+2iPlY2SvX/PSoJ3bl9d7Rz7JLYm60Thh1nrV4If7PI+CApyFmHQTHltPhBg==
X-Received: by 2002:a05:6830:13d3:: with SMTP id e19mr23196012otq.290.1593007653193;  Wed, 24 Jun 2020 07:07:33 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id z5sm4826015otp.28.2020.06.24.07.07.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 07:07:32 -0700 (PDT)
To: Jesse Thompson 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: 
Date: Wed, 24 Jun 2020 07:07:29 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 14:07:36 -0000

On 6/24/2020 7:04 AM, Jesse Thompson wrote:
> On 6/23/20 1:49 PM, dcrocker@gmail.com wrote:
>> So... what if DMARC's semantic were really for the Sender: field?  If a message has no separate Sender: field, then of course the domain in the From: field is used.
> Wouldn't MUAs need to consistently display Sender?

They don't consistently display From:

More importantly, MUAs are essentially -- or completely -- irrelevant to 
the use of DMARC now.  I don't see why that should change.

Again:  end-user recipient decision-making is irrelevant to meaningful 
email abuse handling.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Jun 24 08:09:37 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38243A0ECF for ; Wed, 24 Jun 2020 08:09:34 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4FL3P9SyfZtO for ; Wed, 24 Jun 2020 08:09:31 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 69C903A0ECD for ; Wed, 24 Jun 2020 08:09:26 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id r12so2601949wrj.13 for ; Wed, 24 Jun 2020 08:09:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1RTvNFvLynIbAzzgvqEPSGy0FDDKV30nSNy3b2mpHY8=; b=U2DAkmdVtGLXMhff2/0pqY0S9xUOaxPRagE6MIjyDws+O80Vz/WCDovbS6QvUK9G8F mRtl4X/W0owa2ow+1XRHYU4WypPnSQ8T9FPkYz6838DZtaRamP09+Ns3dNeyEWETu+O8 QhDrLB0+ZxtWh6p/vOTDL3I4rriJUE+8hCcNJLRzOXTX5+fX77T2DPRWjeIhcIG1AidT Owd1GTL5oOEjMCfwY+5C0hzrn+KjIqt/sPH9WBHm6jI6r2ljfwe7iGS/lMI3ap/Q5xLk ZIA4YoACr2X/pLu/79GUHOuEpqE/fVvbh4HZWodMj7dkZxQBcOIYlUSAcap5mDInTdeD 97EQ==
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=1RTvNFvLynIbAzzgvqEPSGy0FDDKV30nSNy3b2mpHY8=; b=Kf2DWc7jS9hEMlP1BchzRScrCLHApWge3CjmI1vrSPSVEnU3j55rGs/RiGMt3SHvYb +4j5elmWLzS+RbCHecMcPeDu8sUyOi5+G4yu05ny7fQEnsVziiYM8dMaxKP3h9fl/PLU 1uVdHz3f6UEfHN9/PQfS6yI6yAqbLvSpHmhlyuzEzMxePs3OHjk46FId0XfnTzhQuASe YHEkuBERlWOLPfzYwbAn218hFSR/pO8uQJySTIDWO9Q/ZeiO+5ZlJKqKzvTokEFUN+ap uNeNziqpw6AgOGHx5ranR8xR+y91wAsg+/iMusw8K6uJRUqB5xfG/Tj9O2ZXJb51xxkr TPgg==
X-Gm-Message-State: AOAM533Z29dBPg9/fNxl85GTp+xop4/BpNS/V5FtAw9i4XSSl7Klr8Nn pF7xILL2AcLGbg8H0FeULouDWd3FgXK0tsJTm9s=
X-Google-Smtp-Source: ABdhPJzktp5saUiZbJu8XIHHDWY7PCigjvnB6G/c70WSMJFfg+6VAcXTp6V75slxvU2CeCU2QzCka5couHl1Bz2rBB0=
X-Received: by 2002:adf:f082:: with SMTP id n2mr25603255wro.326.1593011364816;  Wed, 24 Jun 2020 08:09:24 -0700 (PDT)
MIME-Version: 1.0
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu> 
In-Reply-To: 
From: Dotzero 
Date: Wed, 24 Jun 2020 11:09:12 -0400
Message-ID: 
To: Dave Crocker 
Cc: Jesse Thompson ,  IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000085eccb05a8d5dcd7"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 15:09:35 -0000

--00000000000085eccb05a8d5dcd7
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 24, 2020 at 10:07 AM Dave Crocker  wrote:

> On 6/24/2020 7:04 AM, Jesse Thompson wrote:
> > On 6/23/20 1:49 PM, dcrocker@gmail.com wrote:
> >> So... what if DMARC's semantic were really for the Sender: field?  If a
> message has no separate Sender: field, then of course the domain in the
> From: field is used.
> > Wouldn't MUAs need to consistently display Sender?
>
> They don't consistently display From:
>
> More importantly, MUAs are essentially -- or completely -- irrelevant to
> the use of DMARC now.  I don't see why that should change.
>

Sender: is completely irrelevant to the use of DMARC now. If we were to
list all things irrelevant to DMARC now, it would be a very long list. As
you have mentioned many times in the past, the burden is on the person
making the assertion. You have not provided a compelling case that Sender:
would be a more useful value to validate on than From:. We have substantial
enough experience on the value of the use of From: and the only experience
with Sender: (SenderID) was in essence a failure.

>
> Again:  end-user recipient decision-making is irrelevant to meaningful
> email abuse handling.
>

While this may in fact be true now, it may be a function of the
presentation of the information to the end user rather than the content of
the information itself. That being said, I agree that for purposes of
DMARCbis, this should be considered out of scope absent some compelling
data points.

Michael Hammer

>

--00000000000085eccb05a8d5dcd7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    =

    On Wed, Jun 24, 2020 at 10:07 AM Dave=
 Crocker <dcrocker@gmail.com&g=
t; wrote:
    On 6/24/2020 7:04 AM, Jesse Thompson wr=
ote:
    
> On 6/23/20 1:49 PM, dcrocker@gmail.com wrote:
    
>> So... what if DMARC's semantic were really for the Sender: fie=
ld?=C2=A0 If a message has no separate Sender: field, then of course the do=
main in the From: field is used.
    
> Wouldn't MUAs need to consistently display Sender?
    

    
They don't consistently display From:
    

    
More importantly, MUAs are essentially -- or completely -- irrelevant to 
the use of DMARC now.=C2=A0 I don't see why that should change.

    Sender: is completely irrelevant to the use of=
 DMARC now. If we were to list all things irrelevant to DMARC now, it would=
 be a very long list. As you have mentioned many times in the past, the bur=
den is on the person making the assertion. You have not provided a compelli=
ng case that Sender: would be a more useful value to validate on than From:=
. We have substantial enough experience on the value of the use of From: an=
d the only experience with Sender: (SenderID) was in essence a failure.
    

    
Again:=C2=A0 end-user recipient decision-making is irrelevant to meaningful=
 
    
email abuse handling.

    While this may in=
 fact be true now, it may be a function of the presentation of the informat=
ion to the end user rather than the content of the information itself. That=
 being said, I agree that for purposes of DMARCbis, this should be consider=
ed out of scope absent some compelling data points.
    =C2=A0
    <=
div>Michael Hammer
    

    

--00000000000085eccb05a8d5dcd7--


From nobody Wed Jun 24 08:22:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F93A0E15 for ; Wed, 24 Jun 2020 08:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=P2AnO+kj; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0uwb/xVv
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 Gs_RpWhERclk for ; Wed, 24 Jun 2020 08:22:39 -0700 (PDT)
Received: from mail.winserver.com (winserver.com [76.245.57.69]) (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 B72F23A0D2E for ; Wed, 24 Jun 2020 08:22:38 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3398; t=1593012150; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=z472nin0tdWNQInkom7SaqPThNM=; b=P2AnO+kjyPyNRQEH3KZa8hjPJG2Y4L5ELsmwtRemwpD0gwmtYSadPV5uKvefZO e4WqKkReTCeBJwTgsgsOVi4pl9NCF8iZXgoEIh2dduDQpo5ntA7lwfwR11S3j7Cg TiaadIFXVEYU/oKf779gJ9phMNxeAjbgiiOG85Dycp1gU=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Jun 2020 11:22:30 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3739443319.1.328; Wed, 24 Jun 2020 11:22:29 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3398; t=1593012091; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LmmL3G3 EwGjsmt0X7wASwTu8tlcOxQFnNkCy6GoKvko=; b=0uwb/xVvXWf9eEijb1D7Het oUeep95FSRxvakgXnjd51crGjd9tNaVv13IOQUvF29A6HuUprXjBawPLgl7UYHXS Iq9aeDPU6PxKrHrLdoF+pp6hi0KqL38WA7uokOEKlnVBekg1S3vepCaeR/VJLhxL JSg8gE/Zag1DRKfNhF/c=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Jun 2020 11:21:31 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 450819266.1.50468; Wed, 24 Jun 2020 11:21:30 -0400
Message-ID: <5EF36FB3.70605@isdg.net>
Date: Wed, 24 Jun 2020 11:22:27 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 15:22:41 -0000

On 6/24/2020 10:07 AM, Dave Crocker wrote:
> On 6/24/2020 7:04 AM, Jesse Thompson wrote:
>>
>> Wouldn't MUAs need to consistently display Sender?
>
> They don't consistently display From:
>
> More importantly, MUAs are essentially -- or completely -- irrelevant
> to the use of DMARC now.  I don't see why that should change.
>
> Again:  end-user recipient decision-making is irrelevant to meaningful
> email abuse handling.

As a MUA developer, I am not sure this applies as much as it did in 
the past. Namely because of the different types of MUA which 
predominately fall into three category:

1) Store and forward, offline capable MUAs where all the possible 
"decision" data is pushed to the MUA in the RFC822/2822/5322 format. 
It uses POP3 for pickup and SMTP for sending. The presumption here was 
that the backend has filtered the mail as much as it could for the 
user with using both system-wide and per-user-account policies. 
Generally, when the user picks up mail with POP3, this stream did not 
include the Spam Box.

2) The Online MUA which doesn't get the possible decision data because 
the UI is rendered by the backend. The Reader is dumb. If it was text 
based, it might ANSI/VT100 to place fields on the screens. It could be 
a web-based interface, etc, overall, offline reader has no control 
over what is displayed.

3) The Hybrid, that combines elements both 1 and 2. Exchange did this, 
IMAP does this.

The MUA 1 and 3 could do its own display but not MUA 2. The MUA 1 and 
3 could do more with email abuse handling that was missing or not done 
by the backend when it passed the data to the MUA.

Unfortunately, we can't do anything legacy systems that were abandoned 
and not possible to upgrade. But with MUA 1 and 3 types still 
supported, what we need is technical guidance.  If we keep suggesting 
that this will never work, them of course, it will continue to be an 
unknown of whats possible.

Yes, it is common for us to believe the backend should be 
"responsible" to do the dirty filtering work. But what if they are not 
doing all the dirty work? all that is possible, for whatever reason, 
like the backend doesn't believe in ATPS?  There is absolutely no 
reason why an modern, advanced MUA could not explore ATPS to fill that 
need.

One simple display tibit:

["Message signed with an Authorized domain"].Color = green.
["Message signed with an Unauthorized domain"].Color = red.

Sure, people will suggest, the user will not read this.  Would that be 
all or some users?  Maybe the MUA developers performs an UI ergonomic 
survey behind one way mirrors or employed Telemetry to learn how users 
react. Maybe they will learn simple colorization is not working well 
and instead they find a Modal Popup window is getting the user's 
attention:

----------------WARNING!-------------------[X]-
| Message signed with an Unauthorized domain  |
|    [Continue Reading] [Move to junk box]    |
-----------------------------------------------

Sure, maybe the user doesn't want to be bothered with this, so he 
turned it off in the MUA's DKIM/DMARC options under the View | 
Preference section.

[X] Display Unauthorized DKIM signer warnings

With 40 years with no MUA guidance, of course, it will continue to be 
a status quo of no progress.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Wed Jun 24 08:25:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454973A0E15 for ; Wed, 24 Jun 2020 08:25:25 -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, FREEMAIL_FROM=0.001, 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=gmail.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 R-7mNozYDNfa for ; Wed, 24 Jun 2020 08:25:24 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 B94423A0D2E for ; Wed, 24 Jun 2020 08:25:23 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id u26so4750503wmn.1 for ; Wed, 24 Jun 2020 08:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=39IfCB6BVSzFNhqvwTDJHBNDzvOnKhA4gjpK9gNJfkE=; b=PV4SDLDLcJeJNl425ixgd8EckroE7aSGBrkp5HbIe+0ZE4RaVNXd5a1UoHY1CF8lqb 7cvafbOqW7BM+y4qEBpWtgF+lVs1KrAZIo8N88T6fIo1D8AUC2tFSEtlxGlrR0cbXYoa DWo9bv34/sO1TXTHKR/VutCxqoQ8+q/CPlcWkSbw5Tflgkg9eIO1soQzpLzr8SOGTDID BCk1T4cKdUBixAKVIe97vRknnEbARavkle5tdcixVROWyvk7PNEPfC94nyTgwl7E0Ij9 8kyb2RJoZU7LH2F5IEKn55JDgtPRDuuOeZ7eLB6Xzw1YQwtGwiBFhoubEWChQRaLNl7g /RIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=39IfCB6BVSzFNhqvwTDJHBNDzvOnKhA4gjpK9gNJfkE=; b=tLZCiNrapAfHZcQ1ndyLeazwGciFj33TXoI+QvzQq5cl7KfvL8k6zXztclxigiKhX0 9bCfBP+N5DoR0CZ+ybSvICbsaALToGw3CXQ7hQVO0eQFcG+kZjGcW1xVy3hsrwhFdfxR ACVaj7UVugZXUkolV5UG72efMnVAXHkIEEQSgsOPVUZnwzOxzmqxkz7qen7g+v5/8qW+ oT/UkmLC/OGzIfarEL/CHFPi8AUXkJdxMxT/DgqqukyEKueyNNUnNKdjHTYy67k0G8P2 kY31OcYMjl/hb15ua8kFFfQ1l+9529bYkPLoI1tubOba5s8fJqFlbEVhBsptVHiHZT9a tu2g==
X-Gm-Message-State: AOAM530YkRENq0bO3oWonI0Kj5tMUnAznSVno25hGOjiUiLZHN83rmmM +kehadMimWZbZLbv7/6ctIoCkjodnW9ZoOd7zC4coaak
X-Google-Smtp-Source: ABdhPJzafqTF5Tu7JAmSB3OOp0phfHiSheT22mCCqv3mavfz/824JhGVHPlXwKdH7PP4N6CqX0QTNJpEMxdTwUvjbtc=
X-Received: by 2002:a1c:964d:: with SMTP id y74mr31889928wmd.154.1593012320523;  Wed, 24 Jun 2020 08:25:20 -0700 (PDT)
MIME-Version: 1.0
References:  <95c9baa5-7342-0e84-0791-5938d7310a48@baptiste-carvello.net>  
In-Reply-To: 
From: Dotzero 
Date: Wed, 24 Jun 2020 11:25:08 -0400
Message-ID: 
To: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000007cdbc805a8d61518"
Archived-At: 
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 15:25:25 -0000

--0000000000007cdbc805a8d61518
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 24, 2020 at 9:43 AM  wrote:

> Hi,
>
> just answering this one bit, which I believe is at the heart of the
> disagreement:
>
> 
>
> IMHO "phishing and spam messages" is way too broad a concept to permit
> useful discussion. DMARC nowadays addresses a whole range of problems of
> varying severity to the end user.
>

I'm curious, could you please provide us with the " whole range of
problems" which you believe DMARC addresses? As far as I know, it only
addresses the problem of direct domain abuse, nothing more and nothing less.

Michael Hammer

--0000000000007cdbc805a8d61518
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Wed, Jun 24, 2020=
 at 9:43 AM <devel202=
0@baptiste-carvello.net> wrote:
    Hi,
    

    
just answering this one bit, which I believe is at the heart of the 
    
disagreement:
    

    <SNIP>
    

    
IMHO "phishing and spam messages" is way too broad a concept to p=
ermit 
    
useful discussion. DMARC nowadays addresses a whole range of problems of 
varying severity to the end user.

    I'=
;m curious, could you please provide us with the " whole range of prob=
lems" which you believe DMARC addresses? As far as I know, it only add=
resses the problem of direct domain abuse, nothing more and nothing less.

    Michael Hammer=C2=A0
    

--0000000000007cdbc805a8d61518--


From nobody Wed Jun 24 08:38:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B53A0F91 for ; Wed, 24 Jun 2020 08:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=J82tk5td; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=MBVdmh6V
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 FhX_DHe6Lp6U for ; Wed, 24 Jun 2020 08:38:38 -0700 (PDT)
Received: from mail.winserver.com (winserver.com [76.245.57.69]) (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 1CD863A0F7A for ; Wed, 24 Jun 2020 08:38:37 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2149; t=1593013115; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=38yaXVLtMDGOPoiopa1U4htA1Ak=; b=J82tk5tdL/pQ4GNrjy+dUvJe2zjaJKAxltYmv1ztDAJ6D3M4dsdQ+KXyjyOxuR kovH+PQp6O/htXGRjCyrzFIGnErJTKiypijbLRd+LyW2pLZtKHn10cu5cqgiwKH7 o1JME71xlrAiOiZTNtUHezu+i+Nue70dHz5aCxeu5IJq0=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Jun 2020 11:38:35 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3740408825.1.4628; Wed, 24 Jun 2020 11:38:34 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2149; t=1593013060; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5ogY0F0 XinJ8Mby/CZXxdVaPVHBFy832WNvi1vCB10Q=; b=MBVdmh6VGupS9RW4VV/Ouu9 Uw4uTjZdMWHNUCsclJ7ztgSaLbSEEdGTtVsDqA2Lxv57hNG36FpONdCn/fwAzRn/ n03G+eLvCINJ7CmkGMOvuBlwMNM7M2+/jgWAoKDqPwV226XUkRulznkLvJ7makMz CkF7K6ReIFG69H0YthOk=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Jun 2020 11:37:40 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 451788063.1.49568; Wed, 24 Jun 2020 11:37:39 -0400
Message-ID: <5EF3737C.9010200@isdg.net>
Date: Wed, 24 Jun 2020 11:38:36 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 15:38:41 -0000

On 6/23/2020 2:49 PM, Dave Crocker wrote:
>
> The would produce obvious possibilities:
>
>     From: someone@goodplace.example
>     Sender: someone@goodplace.example
>
> and
>
>     From: somone@goodplace.example
>     Sender: someone@mlm.example.com
>
> where there might be a dmarc record for mlm.example.com

This still presents the unsolved 3rd Party Signature (3PS) 
authorization concept again.  The problem has always been since Day 1, 
"Does goodplace.example authorized mlm.example.com to be a resigner on 
its behalf?"

> The modification to DMARC would be "look for Sender: and if it isn't
> present, look for From:.

Doesn't solve the 3PS problem. Do you know how ATPS worked?   It works 
like this:

googleplace.example will create a DNS lookup record representing 
mlm.example.com.  The ATPS algorithm for the DNS record is:

base32(sha1(SIGNER-DOMAIN))._atps.example.com

So for this example, a DMARC extension tag "atps=1" is added to 
goodplace.example DMARC record, telling verifiers to test for ATPS 3rd 
party signers.  The zone node record will be (in MS DNS format)

6f4dvf2bygvf6zkq6kiktk53oajhfvhe._atps  TXT ("v=atps01; 
d=mlm.example.com;")

Now the 3rd party is authorized deterministically, and if we did this 
with the Signer Domain, which I presume would be mlm.example.com then 
the same ATPS record will apply and the verifier does not have to deal 
with the 5322.Sender header.

> Obviously, mlm.example.com might instead be badactor.example.com.
>
> but we already have to deal with cousin domains, and DMARC does
> nothing about them.

Well, there would not be any 1st party authorization for the 3rd party 
"badactor.example.com" so for restrictive DMARC records, it would be a 
highly detectable deviation of the experted norm offering a negative 
classification, i.e. rejection or quarantine.

> So if Sender: wouldn't be as useful as From:, why not?

Because we still do not have protocol that can test the assertion that 
the 3rd party Sender is authorized by the 1st party.  It is the same 
problem.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Wed Jun 24 09:31:54 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C53A1004 for ; Wed, 24 Jun 2020 09:31:53 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 kK5wCmCt8xIO for ; Wed, 24 Jun 2020 09:31:51 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 821E53A1005 for ; Wed, 24 Jun 2020 09:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593016308; bh=uUd84HQCEkBNL6OgomVeSrh2D7bhFVfDKCocpi/iBOQ=; l=972; h=To:References:From:Date:In-Reply-To; b=AnLmHBnIPfs+LOvPFtoLesiBEhE6nmM7rLB+Q2kizqF+Jq+kvblw5wFCQL6yRXBg7 C/pwy2DJ6Bx3I8OLU3Wc06cUBpUjC3VKwMOWN9q6r2oe4ZMySjDN894GeP4NkR8LKb EZ8aImCz8VYcAU2sB++h4AAK0pxnQFPyrsueNFBkZcO2LzzWl5teLXRqXUBqm
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.89.134]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005EF37FF2.00004683; Wed, 24 Jun 2020 18:31:45 +0200
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
From: Alessandro Vesely 
Message-ID: <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it>
Date: Wed, 24 Jun 2020 18:31:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 16:31:53 -0000

On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
> So if Sender: wouldn't be as useful as From:, why not?


I'm a bit skeptic.

The assertion that "DMARC protects the domain name in the address part
of the From:" would have to be dropped.  The requirement that From:
domain be "the identifier used for all message validation operations,
as it is the single identifier in the message likely to be visible to
the user" was among the founding intuitions of DMARC.  We used to
blame MUAs which don't display such datum...  Don't we risk to loose
design consistency with that move?

Sender: has a display name and an address, just like From:.  Don't we
risk to double phishing opportunities?

If Sender: and From: domains disagree, are both going to get reports?

Would that become v=DMARC2, or shall believers of strict From: have no
chance?  Modifying the protocol for such a minor issue as mailing
lists sounds a bit of an overkill.


Best
Ale
-- 























From nobody Wed Jun 24 10:19:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585623A1055 for ; Wed, 24 Jun 2020 10:19:01 -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, FREEMAIL_FROM=0.001, 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=gmail.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 WCVDtzxkN_yD for ; Wed, 24 Jun 2020 10:19:00 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 F157E3A104A for ; Wed, 24 Jun 2020 10:18:59 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id s10so2257739oih.10 for ; Wed, 24 Jun 2020 10:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=1xFLLr+rTwkxqKu00c8en2OiziePFyrwHT0I+5VhCto=; b=XWkN38tDrQe0JEJlKZ2QrCBPCzsWm4GUmaUlXkvy3yutJk5wu8z7M0BkYPd/QHKDuA K8PlRtOHnmF3wV+bvN3+CeHSQ8O2f5noOhvZ0WbNNndwL3EaPk/1Hi0v34D1FWhCIoqn k/UP5TyFzw0fpJEs3zmQW4YeaW/V8UDTVuVZmtjhK99UkAb26BMPdPljPwjfOxe5PDrb oha02h9gaVbCrooU34Utz4clk8wIvAWvP2XUmrZMsIDVQ7J0zxMBFIVSSbRRekuTMpH0 xceU0Q8fW0fAsDl1rVgEPR3ryEkOfvC0PlxIDYY8Kqg4Hz/Jnzzp5HkZZw5v+z8ucLg6 tmXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=1xFLLr+rTwkxqKu00c8en2OiziePFyrwHT0I+5VhCto=; b=B6nEIS8rPUZE2M7oXLW7mXRqv+r81orKwDJjMxXYA5whCLHSYr6Ege3OT3k5ZBLLLX NZHGMj26Pn/a9IPflwIZWNuf1xHEfjv+pqGdH9nc70SiheLBAQfIJRq2uREGhEVWVeu4 We7Jls2zekKln3ZpdhNu3I9lJ5QkWsBjRblqH31CH0CG0F69BQFYgv8IV1Fh6hbIVSIE /NjyuyKqYLarRj0mV9fSxbRQgISpQrsD5Icuiw0XOUmjw4ErW6oDPjTJ8vcCpD3FbYGC cz/Cix6ginpP6UR8ApyiBjoi/fasmxdXSTYNcv7eyjARQZT7v+44th4KOyiU/OBerR9f BlPQ==
X-Gm-Message-State: AOAM530Xq3V96g1cAIDwuVeg5ErpJsMGMd3huikypfc/wbpIh26hFEqi s528vXKPaumLFGGTVipPa1UDszhS
X-Google-Smtp-Source: ABdhPJz4DPaAC9vPR5IxJ8Ne3E+oZ2prhafr4Bj1d6BE1tnYJAQ2qFrfBgrKI7SjQ9qU1BT2we57PQ==
X-Received: by 2002:aca:4c15:: with SMTP id z21mr15270896oia.85.1593019139108;  Wed, 24 Jun 2020 10:18:59 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id 1sm4925257otr.30.2020.06.24.10.18.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 10:18:58 -0700 (PDT)
To: Dotzero 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>  
From: Dave Crocker 
Message-ID: <06825918-642e-0a21-2976-55a17ff8854f@gmail.com>
Date: Wed, 24 Jun 2020 10:18:57 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A31945C249A40CD111E215D6"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 17:19:01 -0000

This is a multi-part message in MIME format.
--------------A31945C249A40CD111E215D6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/24/2020 8:09 AM, Dotzero wrote:
> Sender: is completely irrelevant to the use of DMARC now.

Actually, I'm claiming it isn't.

Or rather, I'm claiming there is a failure to appreciate that it is 
really Sender information that is important, not author information.

The fact that DMARC only has to do with a domain name tells us that this 
is about an organizational actor and not a person.  My claim is that it 
is sufficient to focus on the operations actor rather than the author actor.

Again, note that RFC 733 (on up through RFC 5322) permit Sender: and 
From: to be conflated.  I'm suggesting making sure they are separated, 
and then adjusting the DMARC focus -- and especially discussion -- from 
author to operator. (Well, not so much adjusting the focus as correcting 
the error of thinking that it's the author that matters.)


> As you have mentioned many times in the past, the burden is on the 
> person making the assertion. You have not provided a compelling case 
> that Sender: would be a more useful value to validate on than From:. 
> We have substantial enough experience on the value of the use of From: 
> and the only experience with Sender: (SenderID) was in essence a failure.

We know that the use of From: causes some serious problems. Using 
Sender: would eliminate them.

I'm not clear why that seems an insufficient justification. (Unless 
there a demonstration that using Sender: rather than From: alters 
DMARC's observable -- rather than supposed -- efficacy.)


>
>     Again:  end-user recipient decision-making is irrelevant to
>     meaningful
>     email abuse handling.
>
>
> While this may in fact be true now, it may be a function of the 
> presentation of the information to the end user rather than the 
> content of the information itself.

I think I don't understand what that means.


d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------A31945C249A40CD111E215D6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/24/2020 8:09 AM, Dotzero wrote:
    
    
    
    
    
      
      
    
        
    
          
    Sender: is completely irrelevant to the use of DMARC now.
          
    
        
    
      
    
    
    
    
    Actually, I'm claiming it isn't.  
    
    
    
    
    Or rather, I'm claiming there is a failure to appreciate that it
      is really Sender information that is important, not author
      information.
    
    
    The fact that DMARC only has to do with a domain name tells us
      that this is about an organizational actor and not a person.  My
      claim is that it is sufficient to focus on the operations actor
      rather than the author actor.
    
    
    
    
    Again, note that RFC 733 (on up through RFC 5322) permit Sender:
      and From: to be conflated.  I'm suggesting making sure they are
      separated, and then adjusting the DMARC focus -- and especially
      discussion -- from author to operator. (Well, not so much
      adjusting the focus as correcting the error of thinking that it's
      the author that matters.)
    
    
    
    

    
    
    
    
    
      
    
        
    
          
    As you have mentioned many times in the past, the burden
            is on the person making the assertion. You have not provided
            a compelling case that Sender: would be a more useful value
            to validate on than From:. We have substantial enough
            experience on the value of the use of From: and the only
            experience with Sender: (SenderID) was in essence a failure.
    
        
    
      
    
    
    
    
    We know that the use of From: causes some serious problems. 
      Using Sender: would eliminate them.
    
    
    I'm not clear why that seems an insufficient justification. 
      (Unless there a demonstration that using Sender: rather than From:
      alters DMARC's observable -- rather than supposed -- efficacy.)
    
    

    
    
    
    
    
      
    
        
    
          

    
            Again:  end-user recipient decision-making is irrelevant to
            meaningful 
    
            email abuse handling.
    
          
    
          

    
          
    
          
    While this may in fact be true now, it may be a function
            of the presentation of the information to the end user
            rather than the content of the information itself.
    
        
    
      
    
    
    
    
    I think I don't understand what that means.
    
    
    
    
    d/
    
    
    -- 
    
    
    Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  


--------------A31945C249A40CD111E215D6--


From nobody Wed Jun 24 10:37:52 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7C3A10A7 for ; Wed, 24 Jun 2020 10:37:51 -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, FREEMAIL_FROM=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=gmail.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 YAWrqBGfXmfz for ; Wed, 24 Jun 2020 10:37:49 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6C93A10AE for ; Wed, 24 Jun 2020 10:37:49 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id i74so2574158oib.0 for ; Wed, 24 Jun 2020 10:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wREPav/IVtwIgJ9AV4qmBvDE3mXQKGkLO8NDfIU0Ebg=; b=qzjt7KMXQTBvV+gBxOmGGei2n9z98ty0Bkh2GfxgLlckkYYyew9AWfVRbzoJFcQ91w mFh7DMYSsGSBKBYS1I2RiYgbwnm95LASJqfYrsy1oTilBU4iK4KNBdUys69o4GAUF4J2 TD1czwN4Tt6tyynmlj67ydtP92LJoUyAxnIUfDKU6h+iOLigRPs0np+P5KaVDfwhKB7S 42pSy5f7PyKOr03T/W+ZJkOjft8PSwvsq+kOdKSF6qoVlWB4CZqib8Poeg6HY2xKYXFj fvzzbbmCfCgW+t9At0Aurqp2ooAKc/ZGF2F9Uxq8Y3aCSU+z9B7IqHeRvYVHZklewp++ q3aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wREPav/IVtwIgJ9AV4qmBvDE3mXQKGkLO8NDfIU0Ebg=; b=BJcvikPXE0q6KVbv6pIwivt/tTH9z0fhe284+zUyMD5fgupTVkBUxk0r7QrDx2O8Gy R02+Xfc23SoP6mVmEeX2JwZW9AbCQJWU8cA8XUvylXZPN4gWsrNwgswP7Uc7sasKgXYU dk5D3RkeLv4u1+Rhnw832u2eTkIAEuwH7cHf/x71bT5BhE5lC0P59vAvXMjrlzIesER2 qyI/A8iep8KFe97hoydLoxzx9/hun7az9vCWRyV1xBfVlc5yjDzvaSldkl7kUNQNjzzF a2zXRYa6ek0oCN14B3gKy99B8LuYJ57W1w0LJZvqYf7KlCRk8VMOUZhRf+6j0jHN/6e5 +LWw==
X-Gm-Message-State: AOAM530MkcAqjbGD/7MWInUWgj6PTMpN1gc4s1+ZCb9kz5Xc0/904qoE oczfC3bWoXvMC+/SCyjwrNxu/BZd
X-Google-Smtp-Source: ABdhPJyMiJ1hPKomDpW+Zu6QXcULCFkBBgzIYN5E42EwGEQKd94a6f4ySPhWWawG4e3hQwDdr+u8cg==
X-Received: by 2002:a05:6808:218:: with SMTP id l24mr21359529oie.129.1593020268239;  Wed, 24 Jun 2020 10:37:48 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id t22sm4968025oth.53.2020.06.24.10.37.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 10:37:47 -0700 (PDT)
To: Alessandro Vesely , dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it>
From: Dave Crocker 
Message-ID: 
Date: Wed, 24 Jun 2020 10:37:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 17:37:51 -0000

On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
> On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
>> So if Sender: wouldn't be as useful as From:, why not?
>
> I'm a bit skeptic.
>
> The assertion that "DMARC protects the domain name in the address part
> of the From:" would have to be dropped.
Of course. But why is that a 'problem' rather than just a fact?

An obvious challenge in this type of discussion is to distinguish 
surface issues from underlying issues. So for every observation like 
this, about documentation language, we need to ask a version of "so 
what?"  That is, how does it affect actual DMARC efficacy?


> The requirement that From:
> domain be "the identifier used for all message validation operations,
> as it is the single identifier in the message likely to be visible to
> the user" was among the founding intuitions of DMARC.  We used to
> blame MUAs which don't display such datum...  Don't we risk to loose
> design consistency with that move?

Except that DMARC doesn't care about or use the MUA.  Which is why I 
keep claiming that referencing the MUA in DMARC discussions is a 
distraction.


> Sender: has a display name and an address, just like From:.  Don't we
> risk to double phishing opportunities?
>
> If Sender: and From: domains disagree, are both going to get reports?

Why would there be a DMARC report on From:?


> Would that become v=DMARC2, or shall believers of strict From: have no
> chance?  Modifying the protocol for such a minor issue as mailing
> lists sounds a bit of an overkill.

I made a point of not trying to offer the specification details, yet, 
because those choices need to flow from an agreement on the basic 
conceptual change I'm suggesting.

(My personal view is that it won't be necessary to declare a version 
change, but really let's wait on discussing the details, pending 
agreement to consider use of Sender:.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Jun 24 11:35:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFCF3A08A6 for ; Wed, 24 Jun 2020 11:35:17 -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 (1024-bit key) header.d=bluepopcorn.net
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 uNW2y9yEoqDh for ; Wed, 24 Jun 2020 11:35:15 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 99D943A08C9 for ; Wed, 24 Jun 2020 11:35:15 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:e5a2:79be:9620:e0a0]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05OIZA4Q018211 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 24 Jun 2020 11:35:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593023713; bh=hxiQzH7UEqYi469IAX25annny0rW2dY21+cstUufzT0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=uonEigTgvW1cAo11vmpDz6HC2LtRHIVV4+FstX9ZBJZLqCDuFOZZt45UYSfgPNmur eSGzhSA6lmk8wcPsRNF1y6liUom+aOT2Nv62WuTepSDBqOrzfUMMaPUn/uGSwfxjEN yrUWOlcUYgbmzylHBva4X+MjlPpHZEQKWxtYig/c=
To: Dave Crocker 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: 
Date: Wed, 24 Jun 2020 11:35:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>
Content-Type: multipart/alternative; boundary="------------D91C947C0E7C0C1AC3CF2C1E"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 18:35:18 -0000

This is a multi-part message in MIME format.
--------------D91C947C0E7C0C1AC3CF2C1E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/23/20 9:19 PM, Dave Crocker wrote:
> On 6/23/2020 4:14 PM, Jim Fenton wrote:
>> I do have a concern about Sender:. It has existing semantics defined i=
n
>> RFC 5322 Section 3.6.2, and this proposal might conflict with that
>
>
> I don't think it conflicts at all. So it will help for you to explain
> your concern in detail.

Quoting RFC 5322 Section 3.6.2:

> For example, if a secretary were to send a message for
>    another person, the mailbox of the secretary would appear in the
>    "Sender:" field and the mailbox of the actual author would appear in=

>    the "From:" field.
and

> If the from
>    field contains more than one mailbox specification in the mailbox-
>    list, then the sender field, containing the field name "Sender" and =
a
>    single mailbox specification, MUST appear in the message.
In the latter example, the From: header field could contain addresses
from different domains, and the Sender: header field would indicate
which of them actually sent the message.

If either message in question goes to a mediator, the Sender address in
the original message would be lost and replaced by the email address of
the mediator, and the original information would be lost. I'm not sure
if that's a significant problem in practice, but pointing out the
possible conflict with currently specified usage.

Please explain why it is important that specifically the Sender: header
field be used for this.

-Jim



--------------D91C947C0E7C0C1AC3CF2C1E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/23/20 9:19 PM, Dave Crocker wrote:
    
    
    
    
    On
      6/23/2020 4:14 PM, Jim Fenton wrote:
      
    
      
    I do have a concern about Sender:. It has
        existing semantics defined in
        
    
        RFC 5322 Section 3.6.2, and this proposal might conflict with
        that
        
    
      
    
      
    
      
    
      I don't think it conflicts at all. So it will help for you to
      explain your concern in detail.
    
    
    Quoting RFC 5322 Section 3.6.2:
    
    
    
      
    
        
    For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.
    
      
    
      and
    
    
    
      
    
        
    If the from
   field contains more than one mailbox specification in the mailbox-
   list, then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.
    
      
    
      In the latter example, the From: header field could contain
      addresses from different domains, and the Sender: header field
      would indicate which of them actually sent the message.
    
    
    
    
    If either message in question goes to a mediator, the Sender
      address in the original message would be lost and replaced by the
      email address of the mediator, and the original information would
      be lost. I'm not sure if that's a significant problem in practice,
      but pointing out the possible conflict with currently specified
      usage.
    
    
    Please explain why it is important that specifically the Sender:
      header field be used for this.
    
    
    
    
    -Jim
    
    
    
  


--------------D91C947C0E7C0C1AC3CF2C1E--


From nobody Wed Jun 24 11:51:57 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642793A08D6 for ; Wed, 24 Jun 2020 11:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 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, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 JG1cXbHb6m0n for ; Wed, 24 Jun 2020 11:51:53 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1473A08CD for ; Wed, 24 Jun 2020 11:51:53 -0700 (PDT)
X-ASG-Debug-ID: 1593024711-11fa313a102385b0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id s0jcjsf034WW8W8G (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 14:51:51 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=htkwKIqEbNztPOIekTgjbhghsfrXUVsxryyI30m1PuA=; b=EQRHsIubSlVCnY6V19Iv0eUWjWVHdjKLlprdrtvkFnB78UM8GHCU6OvSUOnlPWKr5 PgXinAANBliLIxfTLwEKIMii/awNNICen9NyECHcL5IjXa96D+2LMofvfCmP8pi9K 0hWvIwUEIJXR1VZXG2Yj1A28BC/3rMEK03o90op1c=
Received: by webmail.bayviewphysicians.com via HTTP; Wed, 24 Jun 2020 14:51:42 -0400
To: Dave Crocker 
Cc: IETF DMARC WG 
Date: Wed, 24 Jun 2020 14:51:39 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] What if... Sender:
Message-ID: <34b8ffb4-875a-4c18-bdc4-87415a766521@email.android.com>
MIME-Version: 1.0
Content-Type: multipart/multipart; boundary=ba07e42d6fb4479e8b3cad6e3114f543
X-Android-Message-ID: <34b8ffb4-875a-4c18-bdc4-87415a766521@email.android.com>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
From: "Douglas E. Foster" 
X-Exim-Id: 34b8ffb4-875a-4c18-bdc4-87415a766521
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593024711
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 9435
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82782 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 18:51:55 -0000

This is a multipart message in MIME format.

--ba07e42d6fb4479e8b3cad6e3114f543
Content-Type: multipart/alternative; boundary=2e5480f2b7eb461a89a9cd08fa0b16a2

--2e5480f2b7eb461a89a9cd08fa0b16a2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I doubt that tbe end result is the right one, but you need to articulate 
the transition process.

Your proposal requires that all commercial mail systems be changed so that 
their DMARC-enabled clients can send this missing field.  Simultaneously, 
all mail filters must be rewritten to use the new algorithm.

How does that occur without spam getting through during the switch?

When will MLMs know that it is time to stop header munging?

On Jun 23, 2020 2:49 PM, Dave Crocker  wrote:Folks,

This note is partially triggered by Mike's note this morning, but isn't 
specifically responding to it.  Rather it tries to elaborate on a 
premise I've been implying but haven't been explicating:

      What if the rfc5322.Sender field were typically/always present?

      Or at least, what if it were always present for domains publishing
      DMARC records?


What if messages generally had Sender: fields, even when they are the 
same as the email address of the From: field?  So for such domains the 
From: really would only be the author information and the Sender: would 
be the operational handling/sending information.(*)

The thrust of my reference to making a separate Sender: field prevalent 
is an assumption that the patterns of evaluating email addresses could 
adapt to take advantage of the reliable distinction.  For one thing, it 
could clarify the nature of the information used for filtering. 
Currently we conflate 'handling agent' (or 'transmission agent') 
information with 'authoring agent' information.

This leads to statements about end-user effects that actually are 
fundamentally wrong, even as the use of supposed author address 
information is demonstrating filtering efficacy.  What would happen if 
filtering agents had an explicit distinction between 'author' and 
'sender'?

It might be claimed that they already do, since the DKIM d= field refers 
to a handling agent, rather than author, and is explicitly independent 
of any other message address information.

So, why isn't it reasonable, for example, to have DMARC publish a record 
declaring a requirement for a DKIM or SPF record, independent of From: 
field alignment?  That is, publish a record that says all mail by agents 
of that domain is always authenticated?

It's because the signature needs to be tied to a field that is already 
'interesting' and always present.  Otherwise there is no way to know 
what domain name to look for.  In practical terms, the only available 
choice has been From:.  First, it certainly has an interesting semantic 
-- but really semantic/s/ -- for the address, and second, it's always 
present.

So... what if DMARC's semantic were really for the Sender: field?  If a 
message has no separate Sender: field, then of course the domain in the 
From: field is used.

The would produce obvious possibilities:

    From: someone@goodplace.example
    Sender: someone@goodplace.example

and

    From: somone@goodplace.example
    Sender: someone@mlm.example.com

where there might be a dmarc record for mlm.example.com

The modification to DMARC would be "look for Sender: and if it isn't 
present, look for From:.

Obviously, mlm.example.com might instead be badactor.example.com.

but we already have to deal with cousin domains, and DMARC does nothing 
about them.

So if Sender: wouldn't be as useful as From:, why not?



d/



(*)  Mike took exception to my using "processing" as a term for Sender:. 
  He's probably right and it might be worth some separate discussion to 
make sure there is useful and precise language to cover what the 
semantic of Sender: should/must represent.  There is a continuing 
problem in the industry that the word "sender" is used to cover all 
sorts of agents, from author, to originating MTA, to Mediating MTA. 
Should it be 'any agent that touches the message' or 'any agent the does 
a sending operation of the message' or 'the specific agent the posts the 
message into the mail handling system' or something else?
      Note that for mail going through a mediator, there are at least 
two entities qualifying for the 'posting' definition:  The author's 
originating MSA and the MLM's MSA.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--2e5480f2b7eb461a89a9cd08fa0b16a2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


    I doubt that tbe end result is the right one, but you nee=
d to articulate the transition process.

    Your proposal requires that all commercial mail systems be change=
d so that their DMARC-enabled clients can send this missing field.  Si=
multaneously, all mail filters must be rewritten to use the new algorithm.<=
/div>

    How does that occur with=
out spam getting through during the switch?

    When will MLMs know that it is time to stop header mung=
ing?

    O=
n Jun 23, 2020 2:49 PM, Dave Crocker <dcrocker@gmail.com> wrote:
    Folks,

    This note is partially triggered by Mik=
e's note this morning, but isn't 
    specifically responding to it.  Rather=
 it tries to elaborate on a 
    premise I've been implying but haven't been=
 explicating:

          What if the rfc5322.Sender field were typically/=
always present?

          Or at least, what if it were always present fo=
r domains publishing
          DMARC records?


    What if messages ge=
nerally had Sender: fields, even when they are the 
    same as the email ad=
dress of the From: field?  So for such domains the 
    From: really would o=
nly be the author information and the Sender: would 
    be the operational =
handling/sending information.(*)

    The thrust of my reference to makin=
g a separate Sender: field prevalent 
    is an assumption that the patterns=
 of evaluating email addresses could 
    adapt to take advantage of the rel=
iable distinction.  For one thing, it 
    could clarify the nature of the i=
nformation used for filtering. 
    Currently we conflate 'handling agent' (=
or 'transmission agent') 
    information with 'authoring agent' information=
.

    This leads to statements about end-user effects that actually are =

    fundamentally wrong, even as the use of supposed author address 
    inf=
ormation is demonstrating filtering efficacy.  What would happen if 
    fil=
tering agents had an explicit distinction between 'author' and 
    'sender'=
?

    It might be claimed that they already do, since the DKIM d=3D fiel=
d refers 
    to a handling agent, rather than author, and is explicitly ind=
ependent 
    of any other message address information.

    So, why isn't=
 it reasonable, for example, to have DMARC publish a record 
    declaring a=
 requirement for a DKIM or SPF record, independent of From: 
    field align=
ment?  That is, publish a record that says all mail by agents 
    of that d=
omain is always authenticated?

    It's because the signature needs to b=
e tied to a field that is already 
    'interesting' and always present.  Ot=
herwise there is no way to know 
    what domain name to look for.  In pract=
ical terms, the only available 
    choice has been From:.  First, it certai=
nly has an interesting semantic 
    -- but really semantic/s/ -- for the ad=
dress, and second, it's always 
    present.

    So... what if DMARC's se=
mantic were really for the Sender: field?  If a 
    message has no separate=
 Sender: field, then of course the domain in the 
    From: field is used.
    The would produce obvious possibilities:

        From: someone@goo=
dplace.example
        Sender: someone@goodplace.example

    and

     =
   From: somone@goodplace.example
        Sender: someone@mlm.example.com
    where there might be a dmarc record for mlm.example.com

    The mod=
ification to DMARC would be "look for Sender: and if it isn't 
    present, =
look for From:.

    Obviously, mlm.example.com might instead be badactor=
.example.com.

    but we already have to deal with cousin domains, and D=
MARC does nothing 
    about them.

    So if Sender: wouldn't be as usefu=
l as From:, why not?



    d/



    (*)  Mike took except=
ion to my using "processing" as a term for Sender:. 
      He's probably rig=
ht and it might be worth some separate discussion to 
    make sure there is=
 useful and precise language to cover what the 
    semantic of Sender: shou=
ld/must represent.  There is a continuing 
    problem in the industry that =
the word "sender" is used to cover all 
    sorts of agents, from author, to=
 originating MTA, to Mediating MTA. 
    Should it be 'any agent that touche=
s the message' or 'any agent the does 
    a sending operation of the messag=
e' or 'the specific agent the posts the 
    message into the mail handling =
system' or something else?
          Note that for mail going through a medi=
ator, there are at least 
    two entities qualifying for the 'posting' defi=
nition:  The author's 
    originating MSA and the MLM's MSA.

    -- 
    =
Dave Crocker
    Brandenburg InternetWorking
    bbiw.net

    ____________=
___________________________________
    dmarc mailing list
    dmarc@ietf.org=

    https://www.ietf.org/mailman/listinfo/dmarc

    

--2e5480f2b7eb461a89a9cd08fa0b16a2--

--ba07e42d6fb4479e8b3cad6e3114f543--


From nobody Wed Jun 24 11:52:33 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEA3A10C2 for ; Wed, 24 Jun 2020 11:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, 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=gmail.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 DsjVlg9j0pF0 for ; Wed, 24 Jun 2020 11:52:30 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 6ABAF3A08CD for ; Wed, 24 Jun 2020 11:52:30 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id s13so2917392otd.7 for ; Wed, 24 Jun 2020 11:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FLp5HxoKvHN6jYyKVZWaV/g531i/6hIS5I9OW5zjyAU=; b=t7GGy3QmJvXSsdPynbtGzPM/xkvDwyIFj4cNgPf8IFEqfuno73FqQ9pKqWebXOZXE3 /CGjBpvwE9SYqW7MtM/3VOuXX5g4GsYaIUPSvCFH/VQvo5esl3AvGAzAJn8z6L9pZss7 VNC6t5FeGS/8ABvcyYuY55cqIs0puu33YTOOQN+c2RFcHw5t4tW2vhmQHXDJ747P25jI 1THI3zT11VBuq2Wvd4uUirC94UHnInVz6Iju/jyv5jLFFz4ZBbw0KWFWZHS3GOnvQtAe ys3ZPeivfgKQgE1GmXOQGkQx0gNb6UMJLPv37ZBMCR+NoITqgBIrOeVYM0R6hbyu7VtJ 9xsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FLp5HxoKvHN6jYyKVZWaV/g531i/6hIS5I9OW5zjyAU=; b=PMYm8t5mg7HpLGxGgKEGbTd8vuf/SA45AK/C1Dzl3BZua4XeaHU6c/30+dAwilr0/Q dXZtBRiJ5ZDyXszi/0BzGOL+5pm0WGqbOZVl8ybpJPR4RG1Q/KLV91ZWyltqN0WnGKwl ogIJqhYVcrVKb07hH35sMvAEM4eLBAjbnEXclN42sR2ZDxyV05FlADrldiEB3o3WT6Js A31vcdufqXkppDJ6cnhEO1JWttHd48v3HAlsCoVCtuB89ZodomFuR27uwKCmMqlBkqPF z274DYGaEMp38IZK5/bONyuHkJJAwv2iQ0+4BgvPg/imv6KBJqO6UXcnq4k5d4rUs8dv xAVg==
X-Gm-Message-State: AOAM5318Df/TTKT9hulvf3WsSlug0mJjZa1k+CDV9VEo6a5tb2HhfDtc nOcX9EZ8qv27q5fnN5zjpUvl5FTi
X-Google-Smtp-Source: ABdhPJyHPynzxXmkch1k8st5yESlsHl/47foBPvytTv69UeaM1dN16WVPhPCp3IKxCvJtqcQzZct2g==
X-Received: by 2002:a9d:3bb6:: with SMTP id k51mr22986123otc.168.1593024749420;  Wed, 24 Jun 2020 11:52:29 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id a6sm1108049otb.8.2020.06.24.11.52.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 11:52:28 -0700 (PDT)
To: Jim Fenton 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com> 
From: Dave Crocker 
Message-ID: 
Date: Wed, 24 Jun 2020 11:52:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D078CE84A52706401D96D9AB"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 18:52:32 -0000

This is a multi-part message in MIME format.
--------------D078CE84A52706401D96D9AB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/24/2020 11:35 AM, Jim Fenton wrote:
> On 6/23/20 9:19 PM, Dave Crocker wrote:
>> On 6/23/2020 4:14 PM, Jim Fenton wrote:
>>> I do have a concern about Sender:. It has existing semantics defined in
>>> RFC 5322 Section 3.6.2, and this proposal might conflict with that
>>
>> I don't think it conflicts at all. So it will help for you to explain 
>> your concern in detail.
>
> Quoting RFC 5322 Section 3.6.2:
>
>> For example, if a secretary were to send a message for
>>     another person, the mailbox of the secretary would appear in the
>>     "Sender:" field and the mailbox of the actual author would appear in
>>     the "From:" field.
> and
>
>> If the from
>>     field contains more than one mailbox specification in the mailbox-
>>     list, then the sender field, containing the field name "Sender" and a
>>     single mailbox specification, MUST appear in the message.

> In the latter example, the From: header field could contain addresses 
> from different domains, and the Sender: header field would indicate 
> which of them actually sent the message.

Not 'which of them', but 'who'.  The point of the second quoted text is 
to mandate a separate Sender:, when the From: contains more than one 
address.  But it does not specify a different semantic for Sender:


> If either message in question goes to a mediator, the Sender address 
> in the original message would be lost and replaced by the email 
> address of the mediator, and the original information would be lost. 
> I'm not sure if that's a significant problem in practice, but pointing 
> out the possible conflict with currently specified usage.
>
One can indeed imagine a scenario where it matters, but no, it's not 
likely. In any event, the mediator is posting a new message and has a 
'right' to retain or modify whatever it wishes.

So if this is the 'conflict' you see, I'll disgree.  Rather:

      Replacing Sender: is vastly better than modifying From:.

      That's the entire motivation for my suggesting DMARC switch to 
Sender:.


> Please explain why it is important that specifically the Sender: 
> header field be used for this.
>
From: is demonstrably problematic.  Sender: isn't.

Sender: is a long-standing field, similar to From:, but without it's 
history of interesting MUA-level use that DMARC is well-established as 
creating problems for.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--------------D078CE84A52706401D96D9AB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/24/2020 11:35 AM, Jim Fenton
      wrote:
    
    
    
    
    
      
      
    On 6/23/20 9:19 PM, Dave Crocker
        wrote:
    
      
    
      
    On
        6/23/2020 4:14 PM, Jim Fenton wrote: 
    
        
    I do have a concern about Sender:. It
          has existing semantics defined in 
    
          RFC 5322 Section 3.6.2, and this proposal might conflict with
          that 
    
        
    
        
    
        I don't think it conflicts at all. So it will help for you to
        explain your concern in detail.
    
      
    Quoting RFC 5322 Section 3.6.2:
    
      
     
    
      
    
        
    For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.
    
      
    
      and
      
     
    
      
    
        
    If the from
   field contains more than one mailbox specification in the mailbox-
   list, then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.
    
      
    
    
    
    
    
    
    
      
     
    
      In the latter example, the From: header field could contain
      addresses from different domains, and the Sender: header field
      would indicate which of them actually sent the message.
    
    
    
    
    Not 'which of them', but 'who'.  The point of the second quoted
      text is to mandate a separate Sender:, when the From: contains
      more than one address.  But it does not specify a different
      semantic for Sender:
    
    

    
    
    
    
    
      
    If either message in question goes to a mediator, the Sender
        address in the original message would be lost and replaced by
        the email address of the mediator, and the original information
        would be lost. I'm not sure if that's a significant problem in
        practice, but pointing out the possible conflict with currently
        specified usage.
    
    
    
    
    One can indeed imagine a scenario where it matters, but no, it's
      not likely. In any event, the mediator is posting a new message
      and has a 'right' to retain or modify whatever it wishes.  
    
    
    
    
    So if this is the 'conflict' you see, I'll disgree.  Rather:
    
    
    
    
         Replacing Sender: is vastly better than modifying From:.
    
    
         That's the entire motivation for my suggesting DMARC switch
      to Sender:.
    
    
    
    
    
      
    Please explain why it is important that specifically the
        Sender: header field be used for this.
    
      
    
    
    
    
    From: is demonstrably problematic.  Sender: isn't. 
    
    
    
    
    Sender: is a long-standing field, similar to From:, but without
      it's history of interesting MUA-level use that DMARC is
      well-established as creating problems for.
    
    
    d/
    
    
    
    

    
    
    
    
    -- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  


--------------D078CE84A52706401D96D9AB--


From nobody Wed Jun 24 12:25:09 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9567A3A11C3 for ; Wed, 24 Jun 2020 12:25:01 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 mcdO8ccQ06QZ for ; Wed, 24 Jun 2020 12:25:00 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 ED12F3A11A2 for ; Wed, 24 Jun 2020 12:24:56 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:e5a2:79be:9620:e0a0]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05OJOr6B019071 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 24 Jun 2020 12:24:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593026695; bh=g7BLGNzs5fB+K05a8yfRwQnU3YyMJAwjtQ1NULoamDY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P+c8ETZ4I1XBuNbMQC6STYbMmnDo0iTgQ//r1kM+eEbSF5nhsrjd4la/oHtI1F1M9 qI/mv6JZD6LbQttEkAo3sp+hbQrdye8inxXY3tDTedyLgpOP2Hzhmxvc6xaNXbuYnT 5ZR5osOoHiQJI0KWrB6xoM3zvyuM7xk45KvjEACA=
To: Dave Crocker 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>  
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <75b1e9e8-bda7-3872-349a-08778855a825@bluepopcorn.net>
Date: Wed, 24 Jun 2020 12:24:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 19:25:08 -0000

On 6/24/20 11:52 AM, Dave Crocker wrote:
> On 6/24/2020 11:35 AM, Jim Fenton wrote:
>> On 6/23/20 9:19 PM, Dave Crocker wrote:
>> Please explain why it is important that specifically the Sender:
>> header field be used for this.
>
> From: is demonstrably problematic.  Sender: isn't.
>
> Sender: is a long-standing field, similar to From:, but without it's
> history of interesting MUA-level use that DMARC is well-established as
> creating problems for.
>
You have explained why Sender: is better than From: (which I agree with)
but not why specifically Sender needs to be used. I see the use of a
long-standing header field as being a disadvantage, not an advantage,
because of potential obscure uses we don't know about.

-Jim



From nobody Wed Jun 24 16:12:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602C33A11CA for ; Wed, 24 Jun 2020 16:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 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, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 2yV1JkJegdRM for ; Wed, 24 Jun 2020 16:12:16 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B472B3A11CD for ; Wed, 24 Jun 2020 16:12:16 -0700 (PDT)
X-ASG-Debug-ID: 1593040330-11fa313a102419d0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id WOGCRC1nk7fgZwCd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 19:12:10 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=1xAd9yV2v/ej9zAqdbSmgcg3Pb8HAXByEqlcfyu4oj0=; b=WkqSeIlmt4mzBNr9Q2eo8Tg5Ql9x84iK7eFU9OcmLZt9ZZgsoJDahfAnaaooM+C8t /RchVtm5O8ZgFP/FbVPfG9xFkImDF/j38L4teeCB2YhelLqal3cwa2fjGj/McZyT+ bo/6LtVFkS60g9IZr2gxlIo+FGASQviTlqj2eUBvI=
Received: by webmail.bayviewphysicians.com via HTTP; Wed, 24 Jun 2020 19:12:03 -0400
To: Dave Crocker 
Cc: Jim Fenton , IETF DMARC WG 
Date: Wed, 24 Jun 2020 19:12:00 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] What if... Sender:
Message-ID: <157f874c-122f-4eb4-9a23-d1f2ecacf451@email.android.com>
MIME-Version: 1.0
Content-Type: multipart/multipart; boundary=810ec34a8be541358a72ccdc2b02f22a
X-Android-Message-ID: <157f874c-122f-4eb4-9a23-d1f2ecacf451@email.android.com>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
From: "Douglas E. Foster" 
X-Exim-Id: 157f874c-122f-4eb4-9a23-d1f2ecacf451
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593040330
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 6987
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82784 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 23:12:18 -0000

This is a multipart message in MIME format.

--810ec34a8be541358a72ccdc2b02f22a
Content-Type: multipart/alternative; boundary=e6d518bf08114ebf826b2b99af113fa3

--e6d518bf08114ebf826b2b99af113fa3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If DMARC settles on Sender, what tool will validate the relationship betwee=
n Sende and From?

On Jun 24, 2020 2:53 PM, Dave Crocker  wrote:On 6/24/20=
20 11:35 AM, Jim Fenton wrote:
> On 6/23/20 9:19 PM, Dave Crocker wrote:
>> On 6/23/2020 4:14 PM, Jim Fenton wrote:
>>> I do have a concern about Sender:. It has existing semantics defined in
>>> RFC 5322 Section 3.6.2, and this proposal might conflict with that
>>
>> I don't think it conflicts at all. So it will help for you to explain 
>> your concern in detail.
>
> Quoting RFC 5322 Section 3.6.2:
>
>> For example, if a secretary were to send a message for
>>     another person, the mailbox of the secretary would appear in the
>>     "Sender:" field and the mailbox of the actual author would appear in
>>     the "From:" field.
> and
>
>> If the from
>>     field contains more than one mailbox specification in the mailbox-
>>     list, then the sender field, containing the field name "Sender" and =
a
>>     single mailbox specification, MUST appear in the message.

> In the latter example, the From: header field could contain addresses 
> from different domains, and the Sender: header field would indicate 
> which of them actually sent the message.

Not 'which of them', but 'who'.=A0 The point of the second quoted text is 
to mandate a separate Sender:, when the From: contains more than one 
address.=A0 But it does not specify a different semantic for Sender:


> If either message in question goes to a mediator, the Sender address 
> in the original message would be lost and replaced by the email 
> address of the mediator, and the original information would be lost. 
> I'm not sure if that's a significant problem in practice, but pointing 
> out the possible conflict with currently specified usage.
>
One can indeed imagine a scenario where it matters, but no, it's not 
likely. In any event, the mediator is posting a new message and has a 
'right' to retain or modify whatever it wishes.

So if this is the 'conflict' you see, I'll disgree.=A0 Rather:

 =A0=A0=A0=A0 Replacing Sender: is vastly better than modifying From:.

 =A0=A0=A0=A0 That's the entire motivation for my suggesting DMARC switch t=
o 
Sender:.


> Please explain why it is important that specifically the Sender: 
> header field be used for this.
>
From: is demonstrably problematic.=A0 Sender: isn't.

Sender: is a long-standing field, similar to From:, but without it's 
history of interesting MUA-level use that DMARC is well-established as 
creating problems for.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--e6d518bf08114ebf826b2b99af113fa3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


    If DMARC settles on Sender, what tool will validate the r=
elationship between Sende and From?

    On Jun 24, 2020 2:53 PM, Dave Crocker <dcrocker@=
gmail.com> wrote:
    
  
    
  
  
    
    On 6/24/2020 11:35 AM, Jim Fenton
      wrote:
    
    
    
    
    
      
      
    On 6/23/20 9:19 PM, Dave Crocker
        wrote:
    
      
    
      
    On
        6/23/2020 4:14 PM, Jim Fenton wrote: 
    
        
    I do have a concern about Sender:. It
          has existing semantics defined in 
    
          RFC 5322 Section 3.6.2, and this proposal might conflict with
          that 
    
        
    
        
    
        I don't think it conflicts at all. So it will help for you to
        explain your concern in detail.
    
      
    Quoting RFC 5322 Section 3.6.2:
    
      
     
    
      
    
        
    For example, if a secretary were to send a m=
essage for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.
    
      
    
      and
      
     
    
      
    
        
    If the from
   field contains more than one mailbox specification in the mailbox-
   list, then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.
    
      
    
    
    
    
    
    
    
      
     
    
      In the latter example, the From: header field could contain
      addresses from different domains, and the Sender: header field
      would indicate which of them actually sent the message.
    
    
    
    
    Not 'which of them', but 'who'.=A0 The point of the second quoted
      text is to mandate a separate Sender:, when the From: contains
      more than one address.=A0 But it does not specify a different
      semantic for Sender:
    
    

    
    
    
    
    
      
    If either message in question goes to a mediator, the Sender
        address in the original message would be lost and replaced by
        the email address of the mediator, and the original information
        would be lost. I'm not sure if that's a significant problem in
        practice, but pointing out the possible conflict with currently
        specified usage.
    
    
    
    
    One can indeed imagine a scenario where it matters, but no, it's
      not likely. In any event, the mediator is posting a new message
      and has a 'right' to retain or modify whatever it wishes.=A0 
    
    
    
    
    So if this is the 'conflict' you see, I'll disgree.=A0 Rather:
    
    
    
    
    =A0=A0=A0=A0 Replacing Sender: is vastly better than modifying From:=
.
    
    
    =A0=A0=A0=A0 That's the entire motivation for my suggesting DMARC sw=
itch
      to Sender:.
    
    
    
    
    
      
    Please explain why it is important that specifically the
        Sender: header field be used for this.
    
      
    
    
    
    
    From: is demonstrably problematic.=A0 Sender: isn't. 
    
    
    
    
    Sender: is a long-standing field, similar to From:, but without
      it's history of interesting MUA-level use that DMARC is
      well-established as creating problems for.
    
    
    d/
    
    
    
    

    
    
    
    
    -- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  



--e6d518bf08114ebf826b2b99af113fa3--

--810ec34a8be541358a72ccdc2b02f22a--


From nobody Wed Jun 24 16:13:09 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4B3A11CD for ; Wed, 24 Jun 2020 16:13:07 -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, FREEMAIL_FROM=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=gmail.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 Lv7NURnXl8rO for ; Wed, 24 Jun 2020 16:13:06 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 C158E3A11CA for ; Wed, 24 Jun 2020 16:13:06 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id e13so3632740qkg.5 for ; Wed, 24 Jun 2020 16:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=05l9hivKxtDaUay9RizUHfcogMoUiGBQzw8u6bOh48A=; b=tQiqyyAtvQQGpLlW//sPsNvO5X7S46rGZB2ePC9CW7+fyxE4IxlpgYuBD/H3Om0UIN Plhw3PbVazGqXJl/lOWtT2Nkti1+eU9P3hMg6rUk/cVE0NIxePPq5zAzeWcD0DaAYJs4 8whfYNAoH/7uBZeCxQQ+epbRcp8gpvl2atlY9w+KcwigAbd+3ZB/O8n2px0RbDa3nD2n hNBbveAv3mLzpyBGeepIhERpFLrTStw18Jrfis5F50X7UyqXb+ADIRMtkia50JaSXQ+e yl9y6RTu+DomjDavCmG4KTZIwzKObfoQ1PY12Bvumg6LM0f37bzkOTj6IX89o5RO8xqg Gz5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=05l9hivKxtDaUay9RizUHfcogMoUiGBQzw8u6bOh48A=; b=f9BsvC9074aKfl/YfFDGwdV9ekHh5ZX1Xs9WhfPh6UglT4OOlnhd3+MZZgM2odlt1D q0kymdW5/APsoBGKD3mSN0BSswjgPTixksZl6mwLSQBlUez3eWxkXyPHgMFXseap3djY q9fKgXBSUxsj9YmeBbRqxYSbm/Lumj68/L8y5RsH/QWa4qM+bTPF5IKwSZFLRFU7VBM4 UoMzpm1xidJaBimlzeCPnOBBsgdyeGtHMuhIFbxeKne6UAlCjQGN/hrpygM3wKcJeumX kyz/XAcByi2dNMwxsfukxlTn8Ngc9GbMQaW3FvwZYCBpLXRvKKBG0PUWUk1y56vnnUh6 X6ZA==
X-Gm-Message-State: AOAM532qGKgi1c051VJnxibJnEFbxtnL5BN3XgjjAH+oU00AGLgjepOm hzOKxMM771fDpsNBHKjKCR8tC4zI
X-Google-Smtp-Source: ABdhPJyoFHyGlFMsPvPYqFrwALshRAvLJ3g+myFoCryYOIAkxWJafVur2VGbL+WWEmNL8fk7q4EGDA==
X-Received: by 2002:a37:8f06:: with SMTP id r6mr27317772qkd.184.1593040385619;  Wed, 24 Jun 2020 16:13:05 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:b9ab:6650:388e:6e77? ([2600:1700:a3a0:4c80:b9ab:6650:388e:6e77]) by smtp.gmail.com with ESMTPSA id r125sm4287555qkb.42.2020.06.24.16.13.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 16:13:05 -0700 (PDT)
To: "Douglas E. Foster" 
Cc: Jim Fenton , IETF DMARC WG 
References: <157f874c-122f-4eb4-9a23-d1f2ecacf451@email.android.com>
From: Dave Crocker 
Message-ID: <17b6573d-faf3-3f0f-9b16-1be9f907cb65@gmail.com>
Date: Wed, 24 Jun 2020 16:13:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <157f874c-122f-4eb4-9a23-d1f2ecacf451@email.android.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 23:13:08 -0000

On 6/24/2020 4:12 PM, Douglas E. Foster wrote:
> If DMARC settles on Sender, what tool will validate the relationship 
> between Sende and From?

None.

Please explain why you think it has to. Not in terms of theory but in 
terms of observable practice.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Jun 24 18:56:00 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A63A122A for ; Wed, 24 Jun 2020 18:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level: 
X-Spam-Status: No, score=0.278 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 Ub54VPQz6X3N for ; Wed, 24 Jun 2020 18:55:56 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B773A1229 for ; Wed, 24 Jun 2020 18:55:56 -0700 (PDT)
X-ASG-Debug-ID: 1593050154-11fa313a10242380001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 53TJorZlivu1rU2t (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 21:55:54 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:message-id:subject; bh=B5bTvNQRshvgL7CDUUpzyozc/KHUwxs3jzaoRpwHawI=; b=EavmomXTMzPVrXsQxdpKJs20tcD2xXF+/ZM3vXnlix6VhIIPJtjLVWWFN3cZ1Psky FgzFoHtuFm8y5BfPENs0CLYu70GhvrkpBFA8uBXNLsGIYiN32O1fLSIjNRIV+UdvJ a1at0WNUYhvQfIZtX/eDg0JUbKd4PdICjpRlUYVp4=
Date: Wed, 24 Jun 2020 21:55:45 -0400
Message-ID: 
X-ASG-Orig-Subj: Re: [dmarc-ietf] What if... Sender:
X-Android-Message-ID: 
To: Dave Crocker 
Cc: Jim Fenton , IETF DMARC WG 
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
From: "Douglas E. Foster" 
X-Exim-Id: f168906a-bb1b-4433-b5f7-259072472831
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593050154
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 6962
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MIMEOLE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82788 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 01:55:58 -0000

PGRpdiBkaXI9J2F1dG8nPjxkaXYgZGlyPSJhdXRvIj48ZGl2IGRpcj0iYXV0byI+PGRpdiBkaXI9
ImF1dG8iPjxkaXYgZGlyPSJhdXRvIj48ZGl2IGRpcj0iYXV0byI+VGhlIGNvcmUgaXNzdWUgaXMg
dGhhdCBtb3N0IG9mIHVzIHdhbnQgc2VuZGVycyB0byBwcm92ZSB0aGVpciByaWdodCB0byBzZW5k
IG9uIGJlaGFsZiBvZiBhbnkgYXNzZXJ0ZWQgaWRlbnRpdGllcywgb2Ygd2hpY2ggRnJvbSBpcyB0
aGUgbW9zdCBpbXBvcnRhbnQuPGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0
byI+U1BGIGRpZCBub3Qgc29sdmUgdGhlIHByb2JsZW0gYmVjYXVzZSB2YWxpZGF0aW5nIGFuIGlu
dmlzYmxlIGZpZWxkIHdhcyBpbnN1ZmZpY2llbnQgZm9yIGRldGVjdGluZyB1bmF1dGhvcml6ZWQg
aWRlbnRpdHkgY2xhaW1zLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UdXJuaW5nIERNQVJDIGludG8g
YW5vdGhlciBTUEYgd2lsbCBlbWFzY3VsYXRlIGl0LjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+
PC9kaXY+PGRpdiBkaXI9ImF1dG8iPllvdSBkZW55IGFueW9uZSB0aGUgcmlnaHQgdG8gY2FyZSBh
Ym91dCB2YWxpZGF0aW5nIEZyb20sIGFuZCB0aGVuIGFyZ3VlIHRoYXQgRnJvbSBpcyB1bmltcG9y
dGFudCBiZWNhdXNlIG5vIG9uZSBjYXJlcyBhYm91dCBpdC4mbmJzcDsgVGhpcyBpcyBjbGFpbWVk
IGV2ZW4gdGhvdWdoIHlvdSBjYXJlIHZlcnkgbXVjaCBhYm91dCB3aGljaCBGcm9tIGFkZHJlc3Mg
YXBwZWFycyBvbiB5b3VyIERNQVJDIG1haWxpbmcgbGlzdCBtZXNzYWdlcywgYW5kIGFyZSBkZXRl
cm1pbmVkIHRvIHdlYWtlbiBETUFSQyB0byBnZXQgd2hhdCB5b3Ugd2FudC48L2Rpdj48ZGl2IGRp
cj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGUgdGhlb3JldGljYWwgcHJvYmxl
bSBpcyB0aGF0IG1haWxpbmcgbGlzdHMgY2Fubm90IGRlbW9uc3RyYXRlIHRoZWlyIGF1dGhvcml0
eSB0byBzZW5kIG1vZGlmaWVkIGNvbnRlbnQgb24gYmVoYWxmIG9mIHRoZSBvcmlnaW5hdG9yIGRv
bWFpbi4mbmJzcDsgJm5ic3A7VGhpcyByaWdodCBpcyBleHBsaWNpdGx5IGdyYW50ZWQgb3IgaW1w
bGljaXRseSBhc3N1bWVkIGR1cmluZyB0aGUgc3Vic2NyaXB0aW9uIHByb2Nlc3MsIGJ1dCBubyBl
dmlkZW5jZSBvZiB0aGF0IHRyYW5zYWN0aW9uIGlzIGF2YWlsYWJsZSB0byB0aGUgcmVjaXBpZW50
IHN5c3RlbSB3aGVuIGEgbWVzc2FnZSBpcyByZWNlaXZlZC48L2Rpdj48ZGl2IGRpcj0iYXV0byI+
PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UbyBzb2x2ZSB0aGUgcHJvYmxlbSBjb3JyZWN0bHks
IHdlIGhhdmUgdG8gZmluZCBhIHdheSB0byBncmFudCB0aGF0IGF1dGhvcml0eS4mbmJzcDsgUmln
aHQgbm93LCB0aGF0IGF1dGhvcml0eSBpcyBvbmx5IGdyYW50ZWQgYXQgdGhlIHNlbmRlciBkb21h
aW4gbGV2ZWwgdGhyb3VnaCBETlMsIG9yIGF0IHRoZSByZWNpcGllbnQgZG9tYWluIGxldmVsIHRo
cm91Z2ggZmlsdGVyaW5nIHBvbGljaWVzLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+
PGRpdiBkaXI9ImF1dG8iPkkgZG8gbm90IGtub3cgaG93IHRvIGdpdmUgaW5kaWRpdWFscyB0aGUg
cmlnaHQgdG8gZGVsZWdhdGUgc2lnbmluZyBwZXJtaXNzaW9uIGZvciB0aGVtc2VsdmVzLCBiZWNh
dXNlIGluZGl2aWR1YWxzIGRvIG5vdCBoYXZlIEROUyBjb250cm9sLiZuYnNwOyAmbmJzcDtBIHdo
b2xlIG5ldyB0cnVzdCBjaGFubmVsIHdvdWxkIG5lZWQgdG8gYmUgY3JlYXRlZC48L2Rpdj48ZGl2
IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JZiBkZWxlZ2F0aW9uIHJlbWFp
bnMgYSBkb21haW4tb25seSBhdXRob3JpdHksIHRoZW4gdGhlIGRvbWFpbiBvd25lcnMgbmVlZCB0
byBiZSBpbnZvbHZlZC4mbmJzcDsgVGhhdCBsZWF2ZXMgdXMgdmVyeSBmZXcgcG9zc2libGUmbmJz
cDsgc2NlbmFyaW9zOjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1
dG8iPi0gdGhlIG9yaWdpbmF0aW5nIGRvbWFpbiBvd25lciBwdWJsaXNoZXMgYSByaWdodHMgZGVs
ZWdhdGlvbiBub3RpY2UsIHRoZSBtYWlsaW5nIGxpc3QgZG9lcyBzb21ldGhpbmcgdG8gY2xhaW0g
dGhhdCByaWdodCwgYW5kIHRoZSByZWNpcGllbnQgZG9tYWluIGRvZXMgc29tZXRoaW5nIHRvIGNh
bGlkYXRlIHRoYXQgcmlnaHQuJm5ic3A7IEpvaG4gTGV2aW5lJ3MgZHVhbCBzdWduYXR1cmUgcHJv
cG9zYWwgKHdoaWNoIEkgc3RpbGwgaGF2ZSBub3QgcmVhZCkgYXBwZWFycyB0byBiZSBvZiB0aGlz
IHR5cGUuIERLSU0gc2NvcGVzIGFyZSBhbm90aGVyIGV4YW1wbGUsIGJ1dCBhbHJlYWR5IGF2YWls
YWJsZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj4tIHRo
ZSBvcmlnaW5hdG9uZyBkb21haW4gb3duZXIgZG9lcyBub3RoaW5nLCBidXQgdGhlIHJlY2lwaWVu
dCBkb21haW4gb3duZXIgZG9lcyBzb21ldGhpbmcgaW4gdGhlIGVtYWlsIGZpbHRlciB0byB0cmVh
dCB0aGUgbWFpbGluZyBsaXN0IHByZWZlcmVudGlhbGx5LiZuYnNwOyBUaGlzIHdhcyBteSBwcm9w
c2FsLiZuYnNwOyBPZiBjb3Vyc2UsIGFsbCBkb21haW5zIGFjdCBhcyBib3RoIG9yaWdpbmF0b3Ig
YW5kIHJlY2lwdWVudC48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJh
dXRvIj4tIHRoZSBtYWlsaW5nIGxpc3Qgc3RvcHMgbWFraW5nIGNoYW5nZXMuPC9kaXY+PGRpdiBk
aXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+LSB0aGUgbWFpbGluZyBsaXN0IGRv
ZXMgaGVhZGVyIG11bmdpbmcgZm9yZXZlci48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2
PjxkaXYgZGlyPSJhdXRvIj5BcmUgdGhlcmUgYW55IG90aGVyIG9wdGlvbnM/PC9kaXY+PGRpdiBk
aXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+SSBkbyBub3QgbGlrZSB0aGUgbGFz
dCB0aGlyZCBvciBmb3VydGggb3B0aW9ucyBiZWNhdXNlIG5laXRoZXIgZXZhbHVhdGVzIHRoZSBv
cmlnaW5hdG9yIGFuZCBmb3J3YXJkZXIgam9pbnRseSwgYnV0IHRoZSBvYmplY3Rpb24gaXMgc21h
bGwuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+VGhlIHNl
Y29uZCBvcHRpb24gc2VlbXMgbXVjaCBlYXNpZXIgdG8gaW1wbGVtZW50IHRoYW4gdGhlIGZpcnN0
LCBhbmQgaGFzIGEgc3RhdGVkIHRyYW5zaXRpb24gcHJvY2Vzcy4mbmJzcDsmbmJzcDs8L2Rpdj48
ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JIHRoaW5rIHRoZSBmaXJz
dCBvcHRpb24gd2lsbCBlbmNvdW50ZXIgc2lnbmlmaWNhbnQgcG9saXRpY2FsIG9iamVjdGlvbnMg
ZnJvbSBkb21haW4gb3duZXJzLCBhcyB3ZWxsIGFzIHNpZ25pZmljYW50IHRlY2huaWNhbCBpc3N1
ZXMuJm5ic3A7ICZuYnNwO015IHByb3Bvc2FsIHdhcyBhIHNlcmlvdXMgYXR0ZW1wdCB0byBhZGR0
ZXNzIHlvdXIgb2JqZWN0aW9uLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBk
aXI9ImF1dG8iPkkgd2lsbCBzdXBwb3J0IGFueSBzb2x1dGlvbiB3aGljaCBkZW1vbnN0cmF0ZXMg
dHJ1c3QgaW4gYSBmb3JtIGFjY2VwdGFibGUgdG8gY29vcGVyYXRpbmcgcmVjaXBpZW50IHN5c3Rl
bXMuJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0i
YXV0byI+SSB3aWxsIHJlc2lzdCBzb2x1dGlvbnMgd2hpY2ggYXNzZXJ0IHRoYXQgdHJ1c3QgZG9l
cyBub3QgbWF0dGVyIHdoZW4gdGhlIHNlbmRlciBtaXZodCBiZSBhbiBNTE0uPC9kaXY+PGRpdiBk
aXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+REY8L2Rpdj48L2Rpdj48ZGl2Pjxi
cj48ZGl2IGNsYXNzPSJlbGlkZWQtdGV4dCI+T24gSnVuIDI0LCAyMDIwIDc6MTMgUE0sIERhdmUg
Q3JvY2tlciAmbHQ7ZGNyb2NrZXJAZ21haWwuY29tJmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmli
dXRpb24iPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgMC44ZXg7Ym9yZGVyLWxlZnQ6
MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+T24gNi8yNC8yMDIwIDQ6MTIgUE0sIERv
dWdsYXMgRS4gRm9zdGVyIHdyb3RlOjxicj4mZ3Q7IElmIERNQVJDIHNldHRsZXMgb24gU2VuZGVy
LCB3aGF0IHRvb2wgd2lsbCB2YWxpZGF0ZSB0aGUgcmVsYXRpb25zaGlwIDxicj4mZ3Q7IGJldHdl
ZW4gU2VuZGUgYW5kIEZyb20/PGJyPjxicj5Ob25lLjxicj48YnI+UGxlYXNlIGV4cGxhaW4gd2h5
IHlvdSB0aGluayBpdCBoYXMgdG8uPyBOb3QgaW4gdGVybXMgb2YgdGhlb3J5IGJ1dCBpbiA8YnI+
dGVybXMgb2Ygb2JzZXJ2YWJsZSBwcmFjdGljZS48YnI+PGJyPmQvPGJyPjxicj4tLSA8YnI+RGF2
ZSBDcm9ja2VyPGJyPkJyYW5kZW5idXJnIEludGVybmV0V29ya2luZzxicj5iYml3Lm5ldDxicj48
YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj48YnI+PGRpdiBj
bGFzcz0iZWxpZGVkLXRleHQiPk9uIEp1biAyNCwgMjAyMCA3OjEzIFBNLCBEYXZlIENyb2NrZXIg
Jmx0O2Rjcm9ja2VyQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj48
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj
IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPk9uIDYvMjQvMjAyMCA0OjEyIFBNLCBEb3VnbGFzIEUu
IEZvc3RlciB3cm90ZTo8YnI+Jmd0OyBJZiBETUFSQyBzZXR0bGVzIG9uIFNlbmRlciwgd2hhdCB0
b29sIHdpbGwgdmFsaWRhdGUgdGhlIHJlbGF0aW9uc2hpcCA8YnI+Jmd0OyBiZXR3ZWVuIFNlbmRl
IGFuZCBGcm9tPzxicj48YnI+Tm9uZS48YnI+PGJyPlBsZWFzZSBleHBsYWluIHdoeSB5b3UgdGhp
bmsgaXQgaGFzIHRvLj8gTm90IGluIHRlcm1zIG9mIHRoZW9yeSBidXQgaW4gPGJyPnRlcm1zIG9m
IG9ic2VydmFibGUgcHJhY3RpY2UuPGJyPjxicj5kLzxicj48YnI+LS0gPGJyPkRhdmUgQ3JvY2tl
cjxicj5CcmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmc8YnI+YmJpdy5uZXQ8YnI+PGJyPjxicj48
L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+PGJyPjxkaXYgY2xhc3M9ImVs
aWRlZC10ZXh0Ij5PbiBKdW4gMjQsIDIwMjAgNzoxMyBQTSwgRGF2ZSBDcm9ja2VyICZsdDtkY3Jv
Y2tlckBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbjowIDAgMCAwLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw
YWRkaW5nLWxlZnQ6MWV4Ij5PbiA2LzI0LzIwMjAgNDoxMiBQTSwgRG91Z2xhcyBFLiBGb3N0ZXIg
d3JvdGU6PGJyPiZndDsgSWYgRE1BUkMgc2V0dGxlcyBvbiBTZW5kZXIsIHdoYXQgdG9vbCB3aWxs
IHZhbGlkYXRlIHRoZSByZWxhdGlvbnNoaXAgPGJyPiZndDsgYmV0d2VlbiBTZW5kZSBhbmQgRnJv
bT88YnI+PGJyPk5vbmUuPGJyPjxicj5QbGVhc2UgZXhwbGFpbiB3aHkgeW91IHRoaW5rIGl0IGhh
cyB0by4/IE5vdCBpbiB0ZXJtcyBvZiB0aGVvcnkgYnV0IGluIDxicj50ZXJtcyBvZiBvYnNlcnZh
YmxlIHByYWN0aWNlLjxicj48YnI+ZC88YnI+PGJyPi0tIDxicj5EYXZlIENyb2NrZXI8YnI+QnJh
bmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nPGJyPmJiaXcubmV0PGJyPjxicj48YnI+PC9ibG9ja3F1
b3RlPjwvZGl2PiZuYnNwOzwvZGl2PjwvZGl2PjxkaXY+PGJyPjxkaXYgY2xhc3M9ImVsaWRlZC10
ZXh0Ij5PbiBKdW4gMjQsIDIwMjAgNzoxMyBQTSwgRGF2ZSBDcm9ja2VyICZsdDtkY3JvY2tlckBn
bWFpbC5jb20mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbjowIDAgMCAwLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n
LWxlZnQ6MWV4Ij5PbiA2LzI0LzIwMjAgNDoxMiBQTSwgRG91Z2xhcyBFLiBGb3N0ZXIgd3JvdGU6
PGJyPiZndDsgSWYgRE1BUkMgc2V0dGxlcyBvbiBTZW5kZXIsIHdoYXQgdG9vbCB3aWxsIHZhbGlk
YXRlIHRoZSByZWxhdGlvbnNoaXAgPGJyPiZndDsgYmV0d2VlbiBTZW5kZSBhbmQgRnJvbT88YnI+
PGJyPk5vbmUuPGJyPjxicj5QbGVhc2UgZXhwbGFpbiB3aHkgeW91IHRoaW5rIGl0IGhhcyB0by4/
IE5vdCBpbiB0ZXJtcyBvZiB0aGVvcnkgYnV0IGluIDxicj50ZXJtcyBvZiBvYnNlcnZhYmxlIHBy
YWN0aWNlLjxicj48YnI+ZC88YnI+PGJyPi0tIDxicj5EYXZlIENyb2NrZXI8YnI+QnJhbmRlbmJ1
cmcgSW50ZXJuZXRXb3JraW5nPGJyPmJiaXcubmV0PGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjwv
ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48ZGl2IGNsYXNzPSJlbGlkZWQtdGV4dCI+T24g
SnVuIDI0LCAyMDIwIDc6MTMgUE0sIERhdmUgQ3JvY2tlciAmbHQ7ZGNyb2NrZXJAZ21haWwuY29t
Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRpb24iPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW46MCAwIDAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl
eCI+T24gNi8yNC8yMDIwIDQ6MTIgUE0sIERvdWdsYXMgRS4gRm9zdGVyIHdyb3RlOjxicj4mZ3Q7
IElmIERNQVJDIHNldHRsZXMgb24gU2VuZGVyLCB3aGF0IHRvb2wgd2lsbCB2YWxpZGF0ZSB0aGUg
cmVsYXRpb25zaGlwIDxicj4mZ3Q7IGJldHdlZW4gU2VuZGUgYW5kIEZyb20/PGJyPjxicj5Ob25l
Ljxicj48YnI+UGxlYXNlIGV4cGxhaW4gd2h5IHlvdSB0aGluayBpdCBoYXMgdG8uPyBOb3QgaW4g
dGVybXMgb2YgdGhlb3J5IGJ1dCBpbiA8YnI+dGVybXMgb2Ygb2JzZXJ2YWJsZSBwcmFjdGljZS48
YnI+PGJyPmQvPGJyPjxicj4tLSA8YnI+RGF2ZSBDcm9ja2VyPGJyPkJyYW5kZW5idXJnIEludGVy
bmV0V29ya2luZzxicj5iYml3Lm5ldDxicj48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48L2Rp
dj48L2Rpdj4=


From nobody Wed Jun 24 20:03:58 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4A3A1247 for ; Wed, 24 Jun 2020 20:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lIDnpEXM; dkim=pass (1536-bit key) header.d=taugh.com header.b=Q5IcbPv+
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 XyQWJIMvf5mh for ; Wed, 24 Jun 2020 20:03:54 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2357B3A1246 for ; Wed, 24 Jun 2020 20:03:53 -0700 (PDT)
Received: (qmail 5818 invoked from network); 25 Jun 2020 03:03:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16b6.5ef41418.k2006; bh=qgM7T4/SO2Olw0jyTCQilllwhJkO0iFXUaDPvNx8lmA=; b=lIDnpEXMubp2OGQrICpYEYj0eKzFHDsmdzHmMFiroI0f+aGhEer5U1Rp/zd5VRwaHACVZn4qfu7aRHirXDuvJ4Ttc+3LxVSs0/v704hMiNgUke8qb4W1OTxIpB5/9R9VUSRBOkMkT9D/yHt3TGFk5FS7Wb7obTSgi1o2JLWTbZkvrdDT/82N0BiCXK64A1X11ta0swxi9tPUS+cm3nLl8HTeMctqhNH4H7rGH6w6BO2wri91engEu+6tVf8fXp1E
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16b6.5ef41418.k2006; bh=qgM7T4/SO2Olw0jyTCQilllwhJkO0iFXUaDPvNx8lmA=; b=Q5IcbPv+uCW/GJM5R6NcDiVY1cn14BjNgOcT0qzO8i/pTt5e5rAqhVEjsQOV2xx6wf2TsCOCz1e9quwUGLDTKrtDK4pKVbA1uBTZyzPdrrdIHh62TiV0Qd6vUeJU8dmtYBMa7J2L/Ia7KX3Bptix39ewuwkxGWYGbVeiGksR3txG1qnS88Zv1kbP82J7nLbxHjPJ6Fkr8hAknlPv3tTMeP9H2R+ItmHOj8P8u/C2uLO6YXALCvEpppucBnPPtdvf
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 25 Jun 2020 03:03:52 -0000
Received: by ary.qy (Postfix, from userid 501) id 5EFDA1BAB5E0; Wed, 24 Jun 2020 23:03:52 -0400 (EDT)
Date: 24 Jun 2020 23:03:52 -0400
Message-Id: <20200625030352.5EFDA1BAB5E0@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 03:03:56 -0000

In article  you write:
>The core issue is that most of us want senders to prove their right to send on behalf of any asserted
>identities, of which From is the most important.

Could you be more specific about "us" in "most of us"?

It sure doesn't include me.

R's,
John


From nobody Thu Jun 25 01:54:15 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D303A0880 for ; Thu, 25 Jun 2020 01:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk
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 MXXxq8kda0qY for ; Thu, 25 Jun 2020 01:54:09 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110110.outbound.protection.outlook.com [40.107.11.110]) (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 624C33A087D for ; Thu, 25 Jun 2020 01:54:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R5rbh8PIZCcIF5nKxFT9rBPcWTWRajWlwvH7/DQDkYlZAJbwUjhGwG8TBG1hQBDJulVvb+9XUhICeZ33923fMYQRqDq9mvE/q6SentIrrl5hH+B2IZfEfvq3P8mmdzzRkH5slhLaApySZWEehfC0AVRjMgtthcbXSdqdeF31Cliv4b0NNabA06V5e36sxS6ONhs9n11edK9uDlhRTaxAr/UjKPXX6j6c0eQxBPV46UVNTu9GwRgVLWlG2IP+a8K0lR3R3fbJ8ReI94M7DlC0g3/alGOnC6qXHBXZh5bdrFpSmloCUZGkeHpWE9a0c354ALpHj3CNUalCiT4wotee3A==
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=SsJEj4w0IOhA4ShhcDpxKZE/4KeEI4ebp24E51vQ4wg=; b=l8FaKiKU5dzju6GhqmdcqmBsMw/4AHyHsR+GOHTZ8nDFMbvNRhJXL21xnRQzqQlTx0KkgVmEfx4Ch1c9zfcC6D/2fre26e4f3g82YQP9sb6/Eaf3GQer4RSq/o90A1yvR0EHv1vqfam6ajbJsBQWRqhpljwor/6lDo/i4MEtt7iZpqYOQUI8xpcC2AKAsXOKdVh+FLLjbcR+wIOYwFDJtmCQVwX/wa4uvD5ChtVUvUPehW46TrMb50a3zD6p9ZlL6/JMxT6wqu+tC/g4Lt2bAhG1gCfrpvFzzl5ksH7ya28hzSlxXW1wKWNg0zNJps1JV1MqFqcGiSQfHY56UPPx2g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SsJEj4w0IOhA4ShhcDpxKZE/4KeEI4ebp24E51vQ4wg=; b=viFmnvGlkQ2a1efR42mD2KzlyoieT/ABcqEjIGkVdYyGQxoElyxRyqF1YgGHhFyWLQMgez3BsfK7K65LgXtKyUKGYu8zFIPnGrZlHxs45elCRo2UFGf2kWp8BQptUw30pdyUBZJLpIZUtOJNuafHtUqooH2gHaIV1n9O/UTPA1IODhu+KpLqgwX7SAHx9ErjGjh7nGHVIpixOjbeaorQ0GUOL9pviaGhhV5EGXbIrTyiQr2xlw7VT4dRdxMjFLUQiDjTrn1SJmNEdk1U813ej6a3CDRWKf6ojJOm0ZUTNWSmHLrOBCjnfsfw1KyPja2D7aduyhHLUDxJd615EUXlrg==
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c1::23) by LO2P123MB2160.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Thu, 25 Jun 2020 08:54:07 +0000
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117]) by LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117%7]) with mapi id 15.20.3131.021; Thu, 25 Jun 2020 08:54:06 +0000
From: David I 
To: Dave Crocker , IETF DMARC WG 
Thread-Topic: [dmarc-ietf] What if... Sender:
Thread-Index: AQHWSY8PY6KKw8Z6qkO2oAr/+0mQJajndpXAgABSVICAATGzgA==
Date: Thu, 25 Jun 2020 08:54:06 +0000
Message-ID: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>
In-Reply-To: <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk;
x-originating-ip: [51.140.114.144]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: da3ee2f4-d924-4ec4-b1f7-08d818e551ae
x-ms-traffictypediagnostic: LO2P123MB2160:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 0445A82F82
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c5KryzLQSs1tbLnytI4gdYhD3L3EHBLjzYpGnizZkMo1Sd2wkQ77DiXwc9IMyu67LrpjlgQWjgV3k7/7Mii8nOUegLu+uzdTLxK6urUpNUC62KBkNOk0JpWjvhU1dQi1S4ALIlbXjZiN7zYAM91wxkaJIpfDv/N66aOGIIKo48+tykGLfwz4tn38I+enPylP3aZHg9sUWeQjLFKyqwkWw0D9b/I8zXi1mb8LUyabay9zRR9vBTV7tXtQ6+7hNR4WUdHmUfa1icxgm2L1q15Szx72q0DpGctDdjOJOZRLcu3ySkiR9HlN+iL8iUMtbwVK1JK9ndRA0nt7pEb2/1pSpA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(39850400004)(346002)(366004)(396003)(376002)(53546011)(83380400001)(110136005)(52536014)(316002)(86362001)(66946007)(186003)(64756008)(55016002)(33656002)(26005)(66556008)(76116006)(66476007)(71200400001)(2906002)(5660300002)(9686003)(66446008)(8676002)(478600001)(7696005)(8936002)(6506007)(55236004); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: VSJrlKR6a5i/E0KQt9awl65ZUstd/dyDueo2kKggBCWwG+gXMLhHQrD+dD6WjWMo/Q04HE10MdRK4jMGE0lvAovY9E5pNUoz9bAwzSKNYsjB7vxWvbbCGiM8x/zhEd8c04/N8v/gOv/UtHK2Std6oEGA6zLqcuH6pFM2OFpHoy+C+uLMPhLHyc4V4hU1fQiGudUv69DR9uYcjp+G0WUq91aR+doYQnAVrlNfS/9B6M54DfHAYqLBBitw/YKWXFYNc0B4q01bzDF04hdeC+aXD3Jiun0IbrOlDw+l2YaQ/KsNsH3qsaJQqZXIZvZWkSziOgxyJY1PGrrNeXYMs1npgjJ2/C5mWh8oNoL5+Jwu1QQnw3M+CN8yiXjLsYu5lFIVY0ZMkFTjEhH/fqMkw0kJN/y0DdUuUjqfSenCGPiWd2nkAZJTRNgA3sL1fh2E/T5kJthTkcH4sW0wBRtx5cKH3Eef0540KmIa4Ox+NgnzAruCcNAo3gVARj1hBafWpAAh
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: da3ee2f4-d924-4ec4-b1f7-08d818e551ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2020 08:54:06.9266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SC3mvwW1vsRE7eDF6c+3TgxiYoSk9apb6KMx08+7fI+ijiV2uZGR8a2ojngS1cWLff2AbOn2YxDcXcFK3aE29w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2160
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 08:54:14 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZlIENyb2NrZXIgPGRjcm9j
a2VyQGdtYWlsLmNvbT4NCj4gU2VudDogMjQgSnVuZSAyMDIwIDE0OjQ4DQo+IFRvOiBEYXZpZCBJ
IDxEYXZpZC5JQG5jc2MuZ292LnVrPjsgSUVURiBETUFSQyBXRyA8ZG1hcmNAaWV0Zi5vcmc+DQo+
IFN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gV2hhdCBpZi4uLiBTZW5kZXI6DQo+DQo+IE9uIDYv
MjQvMjAyMCAyOjU2IEFNLCBEYXZpZCBJIHdyb3RlOg0KPiA+IFNwZWNpZmljYWxseSwgYWxpZ25t
ZW50IG9uICdGcm9tJyBhbGxvd3MgYXV0b21hdGVkIGNoZWNrcyBhZ2FpbnN0DQo+ID4gYWRkcmVz
c2VzIG9mIGtub3duLCB0cnVzdGVkIGNvbnRhY3RzIGZyb20gYWRkcmVzc2Jvb2tzDQo+DQo+IFNv
IGRvZXMgYWxpZ25tZW50IG9uIFNlbmRlci4gIFllcywgdGhlIGFkZHJlc3NlcyBpbiBGcm9tOiB2
cy4gU2VuZGVyOg0KPiBtaWdodCBiZSBkaWZmZXJlbnQsIGJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB0
aGUgc2FtZSBhc3Nlc3NtZW50IG1lY2hhbmlzbXMNCj4gdGhhdCBjYW4gYmUgdXNlZCBvbiBhIEZy
b206IGFkZHJlc3MgY2FuJ3QgYWxzbyBiZSB1c2VkIG9uIGEgU2VuZGVyOiBhZGRyZXNzLg0KPg0K
DQpXaXRob3V0IGZvcmNpbmcgYWxpZ25tZW50IHRvICdGcm9tJywgYW4gYXR0YWNrZXIgY2FuIHNl
dCB0aGVpciBvd24gJ1NlbmRlcicsIHNldCBhICdGcm9tJyB0aGV5J3JlIG5vdCBlbnRpdGxlZCB0
byB1c2UgdGhhdCdzIG9mIGEgdHJ1c3RlZCBjb250YWN0LCBhbmQgdGhlIERNQVJDIGFzc29jaWF0
ZWQgd2l0aCB0aGUgYWJ1c2VkIGRvbWFpbiBpbiB0aGUgJ0Zyb20nIGhhcyBubyBlZmZlY3QgYW5k
IGNhbid0IGJlIHVzZWQgZm9yIGZpbHRlcmluZy4gU28gd2hpbGUgeW91IGNvdWxkIHNvIGEgc2lt
aWxhciBmaWx0ZXIgb24gU2VuZGVyLCBpdCB3b3VsZG4ndCBiZSBhcyB1c2VmdWwsIGFuZCB3b3Vs
ZCBwcm92aWRlIGxlc3Mgc2VjdXJpdHkgYmVuZWZpdC4NCg0KPg0KPiA+IElmIHRoZSBhdXRoZW50
aWNhdGlvbiBpcyBvZiBhIHZhbHVlIHdoaWNoIGlzbid0IHJlbGF0ZWQgdG8gdGhlIGVudHJ5IGlu
IHRoZQ0KPiBhZGRyZXNzYm9vaywgSSBkb24ndCBzZWUgaG93IHRoaXMga2luZCBvZiBjaGVja2lu
Zy9maWx0ZXJpbmcgY2FuIGJlIGRvbmUsIGFuZA0KPiBzbyB3b3VsZG4ndCBiZSBhcyB1c2VmdWwu
IFVubGVzcyB0aGVyZSdzIGEgd2F5IEkndmUgbWlzc2VkPw0KPg0KPiBJIHN1c3BlY3QgdGhhdCB2
ZXJ5IGxpdHRsZSAtLSBpZiBhbnkgLS0gb2YgdGhlIGN1cnJlbnQgdXNlIG9mIERNQVJDIHJlbGll
cyBvbiBhbg0KPiBlbmQtdXNlcidzIGFkZHJlc3MgYm9vay4NCg0KSXQncyBkZWZpbml0ZWx5IHRo
ZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHBvcHVsYXIgZW1haWwgc2VydmljZXMgZG9pbmcgZmlsdGVy
aW5nL2FsZXJ0aW5nIGJhc2VkIG9uIGFkZHJlc3Nib29rcy9rbm93biBjb250YWN0cywgYW5kIEkn
bSBjb25maWRlbnQgdGhhdCBETUFSQydzIGFiaWxpdHkgdG8gZm9yY2UgdXNlIG9mIGNvdXNpbi9h
bHRlcm5hdGl2ZSBkb21haW5zIG1ha2VzIHRoaXMgbW9yZSBlZmZlY3RpdmUuDQoNCkRhdmlkDQpU
aGlzIGluZm9ybWF0aW9uIGlzIGV4ZW1wdCB1bmRlciB0aGUgRnJlZWRvbSBvZiBJbmZvcm1hdGlv
biBBY3QgMjAwMCAoRk9JQSkgYW5kIG1heSBiZSBleGVtcHQgdW5kZXIgb3RoZXIgVUsgaW5mb3Jt
YXRpb24gbGVnaXNsYXRpb24uIFJlZmVyIGFueSBGT0lBIHF1ZXJpZXMgdG8gbmNzY2luZm9sZWdA
bmNzYy5nb3YudWsuIEFsbCBtYXRlcmlhbCBpcyBVSyBDcm93biBDb3B5cmlnaHQgwqkNCg==


From nobody Thu Jun 25 03:14:57 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97FA3A08F3 for ; Thu, 25 Jun 2020 03:14:56 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 zPd5sfN9GNds for ; Thu, 25 Jun 2020 03:14:55 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 580DA3A08F0 for ; Thu, 25 Jun 2020 03:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593080090; bh=0soRfOxrbTjab5QScARuExDTtIKQOVmKH4pKoJWYP9I=; l=1437; h=To:References:From:Date:In-Reply-To; b=CIUvIRrDHEBoejZW9Dumi348QFFoMUm5dgJ1pSYik/ovOBaSiAXw4a4eTklt/jhrc jz2yGRYvMiALMDs/WqC7yPpxOVCf7dU1YQBJBua606dtd3AnXEmIHOt3z5wwUmhOvI xPEbXlg+Nc/wdrgZa0irUt3R4x6e8Ioolhj/E4e+XLcltdNv4qjinAv+QyAsC
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.89.134]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005EF4791A.00001A56; Thu, 25 Jun 2020 12:14:50 +0200
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it> 
From: Alessandro Vesely 
Message-ID: <081d18c8-5b35-ed7a-ef6b-e00891d4a1bb@tana.it>
Date: Thu, 25 Jun 2020 12:14:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 10:14:57 -0000

On Wed 24/Jun/2020 19:37:46 +0200 Dave Crocker wrote:
> On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
>> On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
>>> So if Sender: wouldn't be as useful as From:, why not?
>>
>> The assertion that "DMARC protects the domain name in the address part
>> of the From:" would have to be dropped.
> Of course. But why is that a 'problem' rather than just a fact?
> 
> An obvious challenge in this type of discussion is to distinguish
> surface issues from underlying issues. So for every observation like
> this, about documentation language, we need to ask a version of "so
> what?"  That is, how does it affect actual DMARC efficacy?


That position changes DMARC substantially:

Frequently, an inbound message has one or more valid DKIM signatures,
and/or passes SPF, yet it fails DMARC; that is, the authenticated
domain(s) are not aligned with From:.  Now it's obvious that any of
those authenticated domain(s) could as well have set a Sender:
pointing to itself.  Hence, the net effect is equivalent to dropping
the alignment requirement.


>> Sender: has a display name and an address, just like From:.  Don't we
>> risk to double phishing opportunities?
>>
>> If Sender: and From: domains disagree, are both going to get reports?
> 
> Why would there be a DMARC report on From:?


Reports are supposed to be consumed by the originator.


Best
Ale
-- 




























From nobody Thu Jun 25 05:53:56 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FD83A0990 for ; Thu, 25 Jun 2020 05:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.077
X-Spam-Level: **
X-Spam-Status: No, score=2.077 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, MISSING_SUBJECT=1.799, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 1NnHX6DDuHOy for ; Thu, 25 Jun 2020 05:53:53 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFCD3A0982 for ; Thu, 25 Jun 2020 05:53:53 -0700 (PDT)
X-ASG-Debug-ID: 1593089631-11fa313a10245b60001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id JGzLLBlWy48jQRz3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 25 Jun 2020 08:53:51 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:message-id; bh=Vj4wsnK8hMYbR5cli+DBEhOoO7dcZCna4f0+D1dEeME=; b=GVcVMeY3q7BxoxjVpYoMejquDwHLjeajZEX8mdTpXaOvgJRO0oduAE7eqF3KkC0wf Tu9ncJkVwPlFCXdKEIhFAlGXOrTQs/II38hF+Ii3hm3md3qxxWw7XgTNIqIBmS+sO hpIM9mRqDcwoMrXcKf6fOt5ol7aPeA7tyGg9TUoEw=
Date: Thu, 25 Jun 2020 08:53:40 -0400
Message-ID: 
X-Android-Message-ID: 
To: dmarc@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
From: "Douglas E. Foster" 
X-Exim-Id: f928ac48-7ddd-40b7-bc89-6abf1cf01d38
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593089631
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 1495
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 1.30
X-Barracuda-Spam-Status: No, SCORE=1.30 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MIME_HTML_ONLY,  MISSING_MIMEOLE, MISSING_SUBJECT, MISSING_SUBJECT_2
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82798 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE 0.01 MISSING_SUBJECT        Missing Subject: header 1.28 MISSING_SUBJECT_2      Missing Subject: header
Archived-At: 
Subject: [dmarc-ietf] (no subject)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 12:53:54 -0000

PGRpdiBkaXI9J2F1dG8nPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDEyLjhweDsiIGRpcj0iYXV0byI+PGRpdiBzdHlsZT0iaGVpZ2h0Ojg2cHgiPkZpcnN0
IGxlciB1cyBiZSBjbGVhci4mbmJzcDsgRE1BUkMgZG9lcyBub3QgY3JlYXRlIGEgc2lnbmlmaWNh
bnQgZGVsaXZlcnkgcHJvYmxlbSBmb3IgbWFpbGluZyBsaXN0cy4mbmJzcDsgJm5ic3A7VGhleSBr
bm93IGhvdyB0byB1c2UgZnJvbSByZXdyaXRlLCBvciBzaG91bGQuJm5ic3A7IEhlYWRlciBtdW5n
aW5nIGNyZWF0ZXMgYSBNVUEgb2JqZWN0aW9uIGZvciBzb21lIHVzZXJzLCBidXQgdGJlIGRlbGl2
ZXJ5IHByb2JsZW0gaXMgc29sdmFibGUuPGJyPjwvZGl2PjxkaXYgc3R5bGU9IndpZHRoOiAzMjhw
eDsgbWFyZ2luOiAxNnB4IDBweDsiPjxkaXYgZGlyPSJhdXRvIj48ZGl2IGRpcj0iYXV0byI+PGJy
PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGUgTVVBIHByb2JsZW0gY2FuIGJlIGFkZHJlc3NlZCB3
aXRoIHVzZXIgb3B0aW9uczo8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGly
PSJhdXRvIj4tIEZyb21SZXdyaXRlID0gb24gKGFzIG5lZWRlZCksIG9mZiwgb3IgZm9yY2UuPC9k
aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+T24gKGRlZmF1bHQp
IC0gVXNlIEZyb209bGlzdEBsaXN0ZG9tYWluLCwgYnV0IG9ubHkgd2hlbiBES0lNIHNpZ25hdHVy
ZXMgaGF2ZSBiZWVuIGJyb2tlbiBieSBsaXN0IGFsdGVyYXRpb25zLiZuYnNwOyBPdGhlcndpc2Ug
dXNlIEZyb209YXV0aG9yQGF1dGhvcmRvbXNpbi48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwv
ZGl2PjxkaXYgZGlyPSJhdXRvIj5PZmYgLSBVc2UgRnJvbT1hdXRob3JAYXV0aG9vcmRvbWFpbiBh
bHdheXMsIGJlY2F1c2UgRE1BUkMgcG9saWNpZXMgYXJlIG5vdCBlbmZvcmNlZCwgb3IgYXJlIGV4
ZW1wdGVkIGZvciB0aGlzIGxpc3QsIGF0IG15IGluY29taW5nIGZpbHRlci48L2Rpdj48ZGl2IGRp
cj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5Gb3JjZSAtIFVzZSBGcm9tPWxpc3RA
bGlzdGRvbWFpbiBhbHdheXMsIHRvIHByZXZlbnQgbWVzc2FnZXMgZnJvbSBiZWluZyBibG9ja2Vk
IGF0IG15IGluY29taW5nIGZpbHRlciwgYXNlZCBvbiBhdXRob3IgYWRkdGVzcy48L2Rpdj48ZGl2
IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TaW5jZSB0aGlzIGlzc3VlIGlz
IGltcG9ydGFudCB0byBsaXN0IHVzZXJzLCB3aHkgaGFzIHRoaXMgbm90IGFscmVhZHkgYmVlbiBk
b25lPyZuYnNwOyAmbmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGly
PSJhdXRvIj5XaHkgaXMgdGhpcyBNTE0gZGVmaWNpZW5jeSB3b3J0aHkgb2YgSUVURnMgYXR0ZW50
aW9uPzwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImhlaWdodDogMHB4OyI+PC9kaXY+PC9k
aXY+PGJyPjwvZGl2Pg==


From nobody Thu Jun 25 06:36:12 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8859B3A0A39 for ; Thu, 25 Jun 2020 06:36:09 -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, FREEMAIL_FROM=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=gmail.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 XucAxWNRhTX6 for ; Thu, 25 Jun 2020 06:36:07 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 CA6713A0A35 for ; Thu, 25 Jun 2020 06:36:07 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id 5so3245845oty.11 for ; Thu, 25 Jun 2020 06:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=G5ksKiLdcuGbZulPaRRsfgMotKQANdYyMT+qD4FxE/w=; b=UWRMFHfQI8F6EVico9RDZ8iIkWNQHleGF/VJ4IRHixHol/cy5rkr0rBiTYXAwr+F5p DLajxqHRN5pYpoZjOqaWWk3maIb4O/yT2lz1jCOVkka+/bT++D9iIq6qhRUuodaTPxSf B9rDbGoZEczGNAZSyfs8h8l+GPZjQrIkdmNRRYELchf2MmNG2UTjaWyLYgCh0pUL1CKT URZ20suR37YfGR4fJCDdwxI8ANvJ6wGy+XXycYWniLRFsShGQl7Qf4BMLVlWm0Xm+qzg aYHrp9ZfwR4WCTY28E58eIVXIa8pPUFdgfP1AOw+Q5MxD3udXXdk70Gf6yw/f/1To9OG H+Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=G5ksKiLdcuGbZulPaRRsfgMotKQANdYyMT+qD4FxE/w=; b=lC1mLeHmbPY6y9PE1eCB9mtnxVhl9xeY3Cts5OLD+aQQiZ1FpbpoLK7TFDOkLIddCR KqTLR4E+SQau5mtBYU/jiCQUf3tpT4fvrRO2bYT7olbEIhb9f4mzMN3fB59slWhuRBaW NLbpy9W7/ycgQqnc2hD8W07Weg8e18f1vLJPXDKfxZU4lu6MwEUcup4PbkMLr6VXd3Z8 7xqxReI43m5YPszTEwb4gsES6t5k2cjwPHGAH02t7GngAG5aQz8y0PySZCi1nJ5LlsMq ENkqYx28zxxH4pt8DvQtFCs9SNnkbi3iPmG2b1U70FaHbLGxLL25SACoWsPP2B3DyNwP 1zfw==
X-Gm-Message-State: AOAM530E2rWBfk6Jg8RFr2bjDwpZSlM+6bbO+j3i8zHo/vPXb0LG3nz1 bSpYf5LMBsQQDbVrcsA+ZAVkzXPG
X-Google-Smtp-Source: ABdhPJwTlVYn0TABiLKd2EJulgY5Z5DT4mvTCSj8gSc/N5NT+2uxCQVKlr1n/TIBoiWL6uOm6h7ZkQ==
X-Received: by 2002:a05:6830:1657:: with SMTP id h23mr27830802otr.339.1593092166709;  Thu, 25 Jun 2020 06:36:06 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id 62sm1495947ots.47.2020.06.25.06.36.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 06:36:04 -0700 (PDT)
To: David I 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com> 
From: Dave Crocker 
Cc: IETF DMARC WG 
Message-ID: 
Date: Thu, 25 Jun 2020 06:36:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 13:36:10 -0000

On 6/25/2020 1:54 AM, David I wrote:
> Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit.

Why is it useful in the From:?  Seriously.

Since the utility of DMARC has nothing to do with recipient end-user 
decision-making, why is DMARC's use of From: automatically better than 
having DMARC use Sender:?

Attackers do all sorts of bad things.  Some of those bad things don't 
actually matter.  They might be unauthorized, ill-intended, and even 
make you or me uncomfortable. But they don't actually have any effect on 
getting bad mail delivered to recipients nor an effect on those 
recipients.  Bad actors try all sorts of stuff.

So pointing out what an attacker might or will do doesn't end the 
argument.  What matters is the /effect/ of their actions, not the theory 
of their actions.


>> I suspect that very little -- if any -- of the current use of DMARC relies on an
>> end-user's address book.
>>
>> It's definitely the case that there are popular email services doing filtering/alerting based on addressbooks/known contacts, and I'm confident that DMARC's ability to force use of cousin/alternative domains makes this more effective.

I did not say that address books are not used in some filtering work.

I said that I doubted that it is relevant to DMARC use.  Feel free to 
document counter-examples.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 06:42:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A23A0A3A for ; Thu, 25 Jun 2020 06:42:40 -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, FREEMAIL_FROM=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=gmail.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 j_1yx42GfzQy for ; Thu, 25 Jun 2020 06:42:39 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 0B5613A0A39 for ; Thu, 25 Jun 2020 06:42:39 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id n6so5306628otl.0 for ; Thu, 25 Jun 2020 06:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ZmI2SqfmgLHCsV5Wb5csXW+NrEr2d2IM6DC+GkcS6/k=; b=Vn/6mr0eNL6AOuEZdEVgcwFmv/hzmd7LXL7BWOhPPCJxz5AvlRKeU+H0jZ/kUbLrMn 8SQ6/O4ACsexw/b4r4L5nEnaCPxU6+VWfDX5VRi/0qfFfzwKXB6l5ACAV8DNAwAyQqhm DzboVWjZufE+pXP7CGbAEzU5+TjXmH9Hpw81c9OxPbCHvktIKsqHZzmBnUGwJkhZxWSg EJfUQCkUty8FvmA66RYr1a4Fh8yHa2sDlUuA1s9G19cZ6fr9rtLKXUfFBep2IakJRkrf YSP5AKv7g5bnEamCDJ+15oizzdepLuHMZh4+z+xaRmhpqHWKAfZH9UO+Fh1Qrh+oGM0r eMnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ZmI2SqfmgLHCsV5Wb5csXW+NrEr2d2IM6DC+GkcS6/k=; b=BPLyKlFYCre0o+TqxGlahj19fmx0U0VybQQ2lgdMAhG4HFSW+Scuo+uoQ8WH76+XjX d4UWs7ZswkkNQbjYUClxhw2N36wSBz0GrKIJjLksiknEPsh7qRYz5Su9qWfUmG+n4uZ6 Vaa4nvVv9OrpUDTUlOrFvhQnmNpLe1Rr+Pc6xj0qk/l/oV6wXgXvOY8JLmKM+ZgRtY4g 8kuW3RE4EPs3/uwR7rUcrEwk3WXmRQ06ZixiMPfm0jneSV9b1wGdFrn6WccXC5trDRt9 yZBJlFIOW2oVHGKT4/TSGLKUrKTYI9f5RLTyCOY69+D2EecyjBy7USSO6dfqkq2aYf32 SLZQ==
X-Gm-Message-State: AOAM5333eJ+lFVy6GTvGBGPmvlFR8kmF2KmC46jvfuqAXBH3hUgBr5dU 7boJgrTKdqd48thwSfb4aIM3Sa5X
X-Google-Smtp-Source: ABdhPJx+JqKEMJdOqDLRL2UFgfYMjbNBm8+aAHATStJbxU6tL/xPIJz3B8ilYbxHCyjHeSfWBuSBNQ==
X-Received: by 2002:a9d:aaa:: with SMTP id 39mr25455271otq.269.1593092558039;  Thu, 25 Jun 2020 06:42:38 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id s188sm5270758oib.50.2020.06.25.06.42.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 06:42:37 -0700 (PDT)
To: Alessandro Vesely , dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it>  <081d18c8-5b35-ed7a-ef6b-e00891d4a1bb@tana.it>
From: Dave Crocker 
Message-ID: <4dc1ff2b-8936-2652-28a1-b93a6e0c4897@gmail.com>
Date: Thu, 25 Jun 2020 06:42:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <081d18c8-5b35-ed7a-ef6b-e00891d4a1bb@tana.it>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 13:42:40 -0000

On 6/25/2020 3:14 AM, Alessandro Vesely wrote:
> Frequently, an inbound message has one or more valid DKIM signatures,
> and/or passes SPF, yet it fails DMARC; that is, the authenticated
> domain(s) are not aligned with From:.  Now it's obvious that any of
> those authenticated domain(s) could as well have set a Sender:
> pointing to itself.  Hence, the net effect is equivalent to dropping
> the alignment requirement.

It's not.  Remember that the From: field is typically also the Sender: 
field.

Again:  The actual semantics of DMARC have to do with the organization's 
domain, not the author's mailbox.  So, really, DMARC concerns an 
operational identifier, not a content creator.

The suggestion, therefore, is to retain alignment, but move it to a 
field that has to do with operations, not content.


>>> Sender: has a display name and an address, just like From:.  Don't we
>>> risk to double phishing opportunities?
>>>
>>> If Sender: and From: domains disagree, are both going to get reports?
>> Why would there be a DMARC report on From:?
> Reports are supposed to be consumed by the originator.

You didn't actually answer my question.

Let's try a more complete question:

      If DMARC reports refer to the Sender: aligned domain, and reports 
refer to that, why is a report on the From: field also required?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 06:53:22 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0B53A0A73 for ; Thu, 25 Jun 2020 06:53:20 -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, FREEMAIL_FROM=0.001, 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=gmail.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 P-1BxCwoqt41 for ; Thu, 25 Jun 2020 06:53:18 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 791AC3A0A6C for ; Thu, 25 Jun 2020 06:53:18 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id f18so6029213wml.3 for ; Thu, 25 Jun 2020 06:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PvBGa+1XzMKTFGNCPsKVL1xZqCUL4HTB+TzVs7APg1s=; b=FGc6Ux1+ovok3+WAvfjkYLM2NrRmDnXYQdzp3A2t6LCe14kmieK5ChXH2EBVArafhY lGd+ZAgezFKUSgnoUv4HXqQQrG11eiLUf2PIpQ7q4Np9A/sJNCcRhko9TGDRpb5YuK9g nf+WFNPANzS6cTu9r8K+27Br4GLegtjLQB+R7NvZHnKb+hEWrROc1JtiCH4z38wmOOMX lcKeaeBiDW/zPql46NkeWPInynf3nicOhdPgRhBUnT738ShjaIxO6mO0uRssdxcV7qKn jFotPWqAiIIT/0M0PiTDLfFLgxncnsJg9VFm75Wv9kxWHmlNaBlQThkbALtsO7o2/xUd ga4A==
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=PvBGa+1XzMKTFGNCPsKVL1xZqCUL4HTB+TzVs7APg1s=; b=Xso+NOF3dOf3CjjGM+cNqTWdPZ3uHqgKBqifyGWZjfCb4teJTw9zuQKHuNu+/uxOv8 SWaHbWXxSRoIPyZspjsAGYcSBoF5qW9f5lbzZYjfkBWMOku0sNFuhur78DtNd4zk0cPj EOS+FaD1EGXFr5vSNg4pK1J23Y9fUipcroyyFsia8DpwJHbU58GqfE5g4HLX8lIXNawT roU92krlRs/p/x2HLWk3DNbrSGqbJZQPSU/vRY/YHE5XottAmzeMnP1qYr+dMM76LkB0 ukQka1YVdmk4KLPWZEdtJhDXNbb72YBZipFVXGLmvNkCAugoah80iAO9aEJ8Lgzt9Z4y Y0MA==
X-Gm-Message-State: AOAM530KH+8bhL8iockCo5S4XUyF1pgXAU99TWNXyRqZuyb3HaEN2qB2 ivC82QlbRI7X1fYaZNWpZvGdnyP161KcYA+jerg=
X-Google-Smtp-Source: ABdhPJyrwQpX2o/2+MOPuATQ0/z6WnWujoq3Iq4YzylbZp+/fT/3dUPTjJy8TbX81RSsQH3lOCxLhXaliWvf2Nn8iBk=
X-Received: by 2002:a7b:c381:: with SMTP id s1mr3678777wmj.25.1593093196851; Thu, 25 Jun 2020 06:53:16 -0700 (PDT)
MIME-Version: 1.0
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>   <06825918-642e-0a21-2976-55a17ff8854f@gmail.com>
In-Reply-To: <06825918-642e-0a21-2976-55a17ff8854f@gmail.com>
From: Dotzero 
Date: Thu, 25 Jun 2020 09:53:04 -0400
Message-ID: 
To: Dave Crocker 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000017add105a8e8eaa1"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 13:53:21 -0000

--00000000000017add105a8e8eaa1
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker  wrote:

> On 6/24/2020 8:09 AM, Dotzero wrote:
>
> Sender: is completely irrelevant to the use of DMARC now.
>
> Actually, I'm claiming it isn't.
>
> Or rather, I'm claiming there is a failure to appreciate that it is really
> Sender information that is important, not author information.
>

Sender sends on behalf of. It ultimately is still about the From (author).
By your logic, if I walk into your bank and can identify myself as myself I
should be able to withdraw money from your bank account even though I have
shown no relationship between myself and yourself.

> The fact that DMARC only has to do with a domain name tells us that this
> is about an organizational actor and not a person.  My claim is that it is
> sufficient to focus on the operations actor rather than the author actor.
>
Organizations get to decide how individual users may use accounts belonging
to a domain controlled by the organization. This is ultimately why there is
such a pernicious problem with MLMs. IF one user at an organization
subscribes to a list, why would an organization undertake the risk of
allowing that MLM to be listed in it's SPF record or to DKIM sign with the
organizations private key. At the other end of the spectrum, if all or
almost all of the organizations users were subscribers to that MLM, the
organization might consider it.


> Again, note that RFC 733 (on up through RFC 5322) permit Sender: and From:
> to be conflated.  I'm suggesting making sure they are separated, and then
> adjusting the DMARC focus -- and especially discussion -- from author to
> operator. (Well, not so much adjusting the focus as correcting the error of
> thinking that it's the author that matters.)
>
>
> As you have mentioned many times in the past, the burden is on the person
> making the assertion. You have not provided a compelling case that Sender:
> would be a more useful value to validate on than From:. We have substantial
> enough experience on the value of the use of From: and the only experience
> with Sender: (SenderID) was in essence a failure.
>
> We know that the use of From: causes some serious problems.  Using Sender:
> would eliminate them.
>
> I'm not clear why that seems an insufficient justification.  (Unless there
> a demonstration that using Sender: rather than From: alters DMARC's
> observable -- rather than supposed -- efficacy.)
>
>
>
>> Again:  end-user recipient decision-making is irrelevant to meaningful
>> email abuse handling.
>>
>
> While this may in fact be true now, it may be a function of the
> presentation of the information to the end user rather than the content of
> the information itself.
>
> I think I don't understand what that means.
>
> d/
>
> --
>
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
>

--00000000000017add105a8e8eaa1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    =

    On Wed, Jun 24, 2020 at 1:18 PM Dave =
Crocker <dcrocker@gmail.com>=
; wrote:
    
 =20
   =20
 =20
  
    
    
    On 6/24/2020 8:09 AM, Dotzero wrote:
    
    
    
    
    
     =20
      
    
        
    
          
    Sender: is completely irrelevant to the use of DMARC now.
          
    
        
    
      
    
    
    
    
    Actually, I'm claiming it isn't.=C2=A0 
    
    
    
    
    Or rather, I'm claiming there is a failure to appreciate that it
      is really Sender information that is important, not author
      information.

    Sender sends o=
n behalf of. It ultimately is still about the From (author). By your logic,=
 if I walk into your bank and can identify myself as myself I should be abl=
e to withdraw money from your bank account even though I have shown no rela=
tionship between myself and yourself.=C2=A0
    
    
    The fact that DMARC only has to do with a domain name tells us
      that this is about an organizational actor and not a person.=C2=A0 My
      claim is that it is sufficient to focus on the operations actor
      rather than the author actor.
    Organiza=
tions get to decide how individual users may use accounts belonging to a do=
main controlled by the organization. This is ultimately why there is such a=
 pernicious problem with MLMs. IF one user at an organization subscribes to=
 a list, why would an organization undertake the risk of allowing that MLM =
to be listed in it's SPF record or to DKIM sign with the organizations =
private key. At the other end of the spectrum, if all or almost all of the =
organizations users were subscribers to that MLM, the organization might co=
nsider it.=C2=A0
    =C2=A0
    
    
    
    
    Again, note that RFC 733 (on up through RFC 5322) permit Sender:
      and From: to be conflated.=C2=A0 I'm suggesting making sure they =
are
      separated, and then adjusting the DMARC focus -- and especially
      discussion -- from author to operator. (Well, not so much
      adjusting the focus as correcting the error of thinking that it's
      the author that matters.)
    
    
    
    

    
    
    
    
    
      
    
        
    
          
    As you have mentioned many times in the past, the burden
            is on the person making the assertion. You have not provided
            a compelling case that Sender: would be a more useful value
            to validate on than From:. We have substantial enough
            experience on the value of the use of From: and the only
            experience with Sender: (SenderID) was in essence a failure.
        
    
      
    
    
    
    
    We know that the use of From: causes some serious problems.=C2=A0
      Using Sender: would eliminate them.
    
    
    I'm not clear why that seems an insufficient justification.=C2=
=A0
      (Unless there a demonstration that using Sender: rather than From:
      alters DMARC's observable -- rather than supposed -- efficacy.)
    

    
    
    
    
    
      
    
        
    
          

    
            Again:=C2=A0 end-user recipient decision-making is irrelevant t=
o
            meaningful 
    
            email abuse handling.
    
          
    
          

    
          
    
          
    While this may in fact be true now, it may be a function
            of the presentation of the information to the end user
            rather than the content of the information itself.
    
        
    
      
    
    
    
    
    I think I don't understand what that means.
    
    
    
    
    d/
    
    
    -- 
    
    
    Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  
    


    

--00000000000017add105a8e8eaa1--


From nobody Thu Jun 25 07:02:34 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34C23A0B80 for ; Thu, 25 Jun 2020 07:02:32 -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, FREEMAIL_FROM=0.001, 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=gmail.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 W9NEtOCZwINC for ; Thu, 25 Jun 2020 07:02:31 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 F403D3A0B81 for ; Thu, 25 Jun 2020 07:02:30 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id f7so2972229wrw.1 for ; Thu, 25 Jun 2020 07:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BigpCJaZJR/b4tTsL8rgIAV9nF+zokN9rI7wylE5Dt8=; b=YHdvMHilJ95NHStDcTnKvQMmNQ/8xofOFqnis9QVAif8P9PPbqnOYylDGQ2KbGyMIH +cMkiV9ILoVurrjD+7i80DRTwr5BDBxvYT9ckGUcVOuua0F5bVF/jJztVarmjoiDQFez XT0Wcd6dC2cc0u2dPpdDHTUI2w+8DEa3KaxR/ELS4ooB+FOcee8B+lVgi5KlndnJ8ueH Yvz1J1af8GGqAMtc3VnNpKFlQbitV0vGLXGTwtznJITRv+HfT6b+uo05qQlqUcg1vQWP uk/22JZF6F5B1qvd8N49V4znp3lzVA49Sm+I4wyzJWkVFRSyWmWt4QL/SgowTVN7M9Zq 5UOQ==
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=BigpCJaZJR/b4tTsL8rgIAV9nF+zokN9rI7wylE5Dt8=; b=nsvVGzPtVSpJGCWszC+SBOZVg8Ki8IZRB46EiPokvVcUSa1blDchFHAVXLhy+mStQB UwTZ/z8Y7rTSffJx4D0lo7wFkpOPksNzorDGL8GyOy0uzKTYwv0oL5KNVAcYO3nUdJ/O CYC8UcORC3enWSzEd1YoscIPaOF9lVlyRKbO4cA1DhAApXrJF2Y85oqLxkebB5J/Qdyx C3OLjoM2XECJaLzm8ZTU4l8A1QBIFD4i3sH5isDVdvY8n7tQz2Vm3WU7qHZmtRERd3dC 6TglWo7S/myocWm7mRzjADj6DxKg6FLDqeQpWJzp5MJxGxx5L0jIVGqye3cYGyvYDHLD qZVA==
X-Gm-Message-State: AOAM532pe7nXepKV323ZBbuQZvC0sKgePlEQCy/Bbmz7NsB/C+Z/aMUd RviEXqI1Dma6z4XvNlwZr8bl3IlLBhhVuKRCeJk=
X-Google-Smtp-Source: ABdhPJzvBE2pZFKHFAwKqlPK6cC4WsCBsTOPF/+7KjM0ujPPJnvISQqe3njVXRT5hXxaFIz63i+/cWEg0kUQfshDYgc=
X-Received: by 2002:adf:e4d0:: with SMTP id v16mr24106621wrm.193.1593093749419;  Thu, 25 Jun 2020 07:02:29 -0700 (PDT)
MIME-Version: 1.0
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <20e75765-8490-4ce7-dfa6-977641d8d61b@wisc.edu>   <06825918-642e-0a21-2976-55a17ff8854f@gmail.com> 
In-Reply-To: 
From: Dotzero 
Date: Thu, 25 Jun 2020 10:02:17 -0400
Message-ID: 
To: Dave Crocker 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000000733f805a8e90bb4"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 14:02:33 -0000

--0000000000000733f805a8e90bb4
Content-Type: text/plain; charset="UTF-8"

]ARGH! Accidentally hit send. I was going to continue with... It is
unlikely that an organization would do so even if all it's users were
subscribers because now any mail sent through the list is validated for the
organization. We go round and round because of a mismatch in granularity.
Ultimately, who gets to decide how an account may be used. It's clearly the
organization that controls the domain the user account belongs to. So what
is needed is a mechanism that enables a user at a domain (other than
subscribing) to show, through the domain owner, that the domain authorizes
the use of that account at a particular list. This is a different problem
space than DMARC and I don't believe it should be conflated with DMARC. It
would function at a more granular level and have a whole different set of
issues and opportunities. I don't know if it would be appropriate for this
group to take up or another group.

Michael Hammer

On Thu, Jun 25, 2020 at 9:53 AM Dotzero  wrote:

>
>
> On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker  wrote:
>
>> On 6/24/2020 8:09 AM, Dotzero wrote:
>>
>> Sender: is completely irrelevant to the use of DMARC now.
>>
>> Actually, I'm claiming it isn't.
>>
>> Or rather, I'm claiming there is a failure to appreciate that it is
>> really Sender information that is important, not author information.
>>
>
> Sender sends on behalf of. It ultimately is still about the From (author).
> By your logic, if I walk into your bank and can identify myself as myself I
> should be able to withdraw money from your bank account even though I have
> shown no relationship between myself and yourself.
>
>> The fact that DMARC only has to do with a domain name tells us that this
>> is about an organizational actor and not a person.  My claim is that it is
>> sufficient to focus on the operations actor rather than the author actor.
>>
> Organizations get to decide how individual users may use accounts
> belonging to a domain controlled by the organization. This is ultimately
> why there is such a pernicious problem with MLMs. IF one user at an
> organization subscribes to a list, why would an organization undertake the
> risk of allowing that MLM to be listed in it's SPF record or to DKIM sign
> with the organizations private key. At the other end of the spectrum, if
> all or almost all of the organizations users were subscribers to that MLM,
> the organization might consider it.
>
>
>> Again, note that RFC 733 (on up through RFC 5322) permit Sender: and
>> From: to be conflated.  I'm suggesting making sure they are separated, and
>> then adjusting the DMARC focus -- and especially discussion -- from author
>> to operator. (Well, not so much adjusting the focus as correcting the error
>> of thinking that it's the author that matters.)
>>
>>
>> As you have mentioned many times in the past, the burden is on the person
>> making the assertion. You have not provided a compelling case that Sender:
>> would be a more useful value to validate on than From:. We have substantial
>> enough experience on the value of the use of From: and the only experience
>> with Sender: (SenderID) was in essence a failure.
>>
>> We know that the use of From: causes some serious problems.  Using
>> Sender: would eliminate them.
>>
>> I'm not clear why that seems an insufficient justification.  (Unless
>> there a demonstration that using Sender: rather than From: alters DMARC's
>> observable -- rather than supposed -- efficacy.)
>>
>>
>>
>>> Again:  end-user recipient decision-making is irrelevant to meaningful
>>> email abuse handling.
>>>
>>
>> While this may in fact be true now, it may be a function of the
>> presentation of the information to the end user rather than the content of
>> the information itself.
>>
>> I think I don't understand what that means.
>>
>> d/
>>
>> --
>>
>> Dave Crocker
>> Brandenburg InternetWorkingbbiw.net
>>
>>

--0000000000000733f805a8e90bb4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    ]ARGH! Accidentally hit send. I was going=
 to continue with... It is unlikely that an organization would do so even i=
f all it's users were subscribers because now any mail sent through the=
 list is validated for the organization. We go round and round because of a=
 mismatch in granularity. Ultimately, who gets to decide how an account may=
 be used. It's clearly the organization that controls the domain the us=
er account belongs to. So what is needed is a mechanism that enables a user=
 at a domain (other than subscribing) to show, through the domain owner, th=
at the domain authorizes the use of that account at a particular list. This=
 is a different problem space than DMARC and I don't believe it should =
be conflated with DMARC. It would function at a more granular level and hav=
e a whole different set of issues and opportunities. I don't know if it=
 would be appropriate for this group to take up or another group.

    Michael Hammer

    On Thu, Jun 25, 2020 at 9:53 AM D=
otzero <dotzero@gmail.com> w=
rote:


    On We=
d, Jun 24, 2020 at 1:18 PM Dave Crocker <dcrocker@gmail.com> wrote:
    
 =20
   =20
 =20
  
    
    
    On 6/24/2020 8:09 AM, Dotzero wrote:
    
    
    
    
    
     =20
      
    
        
    
          
    Sender: is completely irrelevant to the use of DMARC now.
          
    
        
    
      
    
    
    
    
    Actually, I'm claiming it isn't.=C2=A0 
    
    
    
    
    Or rather, I'm claiming there is a failure to appreciate that it
      is really Sender information that is important, not author
      information.

    Sender sends o=
n behalf of. It ultimately is still about the From (author). By your logic,=
 if I walk into your bank and can identify myself as myself I should be abl=
e to withdraw money from your bank account even though I have shown no rela=
tionship between myself and yourself.=C2=A0
    
    
    The fact that DMARC only has to do with a domain name tells us
      that this is about an organizational actor and not a person.=C2=A0 My
      claim is that it is sufficient to focus on the operations actor
      rather than the author actor.
    Organiza=
tions get to decide how individual users may use accounts belonging to a do=
main controlled by the organization. This is ultimately why there is such a=
 pernicious problem with MLMs. IF one user at an organization subscribes to=
 a list, why would an organization undertake the risk of allowing that MLM =
to be listed in it's SPF record or to DKIM sign with the organizations =
private key. At the other end of the spectrum, if all or almost all of the =
organizations users were subscribers to that MLM, the organization might co=
nsider it.=C2=A0
    =C2=A0
    
    
    
    
    Again, note that RFC 733 (on up through RFC 5322) permit Sender:
      and From: to be conflated.=C2=A0 I'm suggesting making sure they =
are
      separated, and then adjusting the DMARC focus -- and especially
      discussion -- from author to operator. (Well, not so much
      adjusting the focus as correcting the error of thinking that it's
      the author that matters.)
    
    
    
    

    
    
    
    
    
      
    
        
    
          
    As you have mentioned many times in the past, the burden
            is on the person making the assertion. You have not provided
            a compelling case that Sender: would be a more useful value
            to validate on than From:. We have substantial enough
            experience on the value of the use of From: and the only
            experience with Sender: (SenderID) was in essence a failure.
        
    
      
    
    
    
    
    We know that the use of From: causes some serious problems.=C2=A0
      Using Sender: would eliminate them.
    
    
    I'm not clear why that seems an insufficient justification.=C2=
=A0
      (Unless there a demonstration that using Sender: rather than From:
      alters DMARC's observable -- rather than supposed -- efficacy.)
    

    
    
    
    
    
      
    
        
    
          

    
            Again:=C2=A0 end-user recipient decision-making is irrelevant t=
o
            meaningful 
    
            email abuse handling.
    
          
    
          

    
          
    
          
    While this may in fact be true now, it may be a function
            of the presentation of the information to the end user
            rather than the content of the information itself.
    
        
    
      
    
    
    
    
    I think I don't understand what that means.
    
    
    
    
    d/
    
    
    -- 
    
    
    Dave Crocker
Brandenburg InternetWorking
bbiw.net
    
  
    


    

    

--0000000000000733f805a8e90bb4--


From nobody Thu Jun 25 08:11:07 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6DB3A0BB8 for ; Thu, 25 Jun 2020 08:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk
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 1A_z8C0HhoUt for ; Thu, 25 Jun 2020 08:11:02 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100131.outbound.protection.outlook.com [40.107.10.131]) (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 6F5AA3A03EA for ; Thu, 25 Jun 2020 08:11:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NG7+hDYvK4hxhFFN+cthLxmWp4BYQWBtmZtU0QgyRCzk+fxfrz8JKD2Xt6cuugxlWHkArvhO2DsJaNhYv3FOxLrVEs0rmK3U6K7zd6M9rTD344yca14OujE084jeOqPov2m/ho167Zy8t4IcE1+aDkrNKWvW8qMagEAgoX3ETElF1Un0nJJW8wxcCL1zWpIxTrcnixl6FwBH3Z3cs7hRDNPOhveSp66pPPJyVRzewN9xEYOMJnWCkKbLYGX/YmbxyzP4YYHNeTORh7KmiLgLQwY9wF94AeLaLgk/xKAX7EasMRJ66X9nwHfgax9IASK+nf+HSDSRHHB4Wqa713LxnA==
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=WIQlt5cqCDkLw+NLFrG/mG3nSiqVIgNxGTo4lVUrSiE=; b=bQGSr+X0/MPrctHIhUAkqy6wY8aH6DNzU1n6UJy74BFNNUhEuQ5+4SfWkrIsU0nzXl9iGijmg75vwHfiaaGwdllEll7IJvfMNskWx5p3EOFYqaZMTyDaTq2CamPVzheR1YwCGqz7uiQRTUUW5Ms6iG4InuhpFkZNbBEkipxVbGrevEtOStGwGivta2VOtfZIojJW2dzTgQ5RktuFUOYipKUIFCWMiEugEUHCH4z1QNzps8v9x1rpo7p2MLqXrrtdGQ3ri+/6cZMYMofbR+Z5HY+OITdRwS4cw7qet4pr6KT7c/PZTbE+XGsnwtDoCBvmnNKnzzsF2LKvutux7JlPUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WIQlt5cqCDkLw+NLFrG/mG3nSiqVIgNxGTo4lVUrSiE=; b=1B0t+KodSXREA8SuxUbelxCpOwprPztNiX1zemo7UhkdHoudnJCzGjD8KZQwo3tfp/wSNJilGEEehzzwiILRrfAO4lOBXb8tHS+qYg2u99H+G4uXzRdzhR7e9q8PHRC3Dup4Gwn5Zpf4un8ZfBXD0mag9Zd1SUXms5ipX3YWyQSgWDpHH58aSg9k0Uz6ZgsBxEFCH5YoKo7I2YaH6LU3BaUnW5sqNXlXtTbxroNGEilkVcn8NYpVRN2sNp78b+mIlOWhlvQSl3tCbOoydqs8Hgcs5G7Ib7pNbsSUanpWp3N36uSduOW0eH0Eaf0KTVP1h/26MXLARkdO3NDPgwlfzg==
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c1::23) by LO2P123MB2366.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 25 Jun 2020 15:11:00 +0000
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117]) by LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117%7]) with mapi id 15.20.3131.021; Thu, 25 Jun 2020 15:11:00 +0000
From: David I 
To: Dave Crocker 
CC: IETF DMARC WG 
Thread-Topic: [dmarc-ietf] What if... Sender:
Thread-Index: AQHWSY8PY6KKw8Z6qkO2oAr/+0mQJajndpXAgABSVICAATGzgIAAXWgAgAAI2QA=
Date: Thu, 25 Jun 2020 15:10:59 +0000
Message-ID: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk;
x-originating-ip: [51.140.114.144]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 454e81b8-382c-40ed-a0e8-08d81919f818
x-ms-traffictypediagnostic: LO2P123MB2366:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 0445A82F82
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rb9TL6Yqla75IBk6tpnw78dRRXa/h0Omw50RhyH+lKEXXPM097p5/3b2qeDUwMZ0bU5Bh9kC/ZdkOcxTxzZZ+6qKaOOsVapmGW2Cz4kt7/AtOBTHs1c9EXKCIK5UdK9o9hXUSrcBD8P/P843vzgMe05Xe5fZeT93Vy2530abbZiwgwN0OTV9fAD990XKDLslSlqYH7v5oWcUi6BPnG3MZxSSZmMH0YYkTHg08qBmqyTz6lFo+eRAkXe4sWVs1xe1TQkOEfcFM5VRPgPvrhMw/JPH3PoQ3+SvTv3gsNXOzYGua7V8k0OZWeqlrc7AFYb376/yPPpa0VJ6KM696NChSw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39850400004)(396003)(366004)(346002)(376002)(136003)(66946007)(66476007)(66446008)(71200400001)(7696005)(8676002)(4326008)(53546011)(186003)(26005)(2906002)(6506007)(33656002)(8936002)(55236004)(478600001)(6916009)(55016002)(316002)(86362001)(5660300002)(76116006)(52536014)(83380400001)(64756008)(66556008)(9686003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: FMVakOEpKhK87qkg8Jlf31U0hX2JiPgwVruCq7PSEVy9XRKPUD9QmVGmhC1tqtaKs9epvO0aGA0/QwQ4cHk95Xy+uAHsG3fcmBu0q2oVBCrvtqxefH7Qfb0QPaD+I3DbVItPBghD8ZgXZJDr23yxTw7nx7PoqusTRqaVPehCxEytuTlOPepisfPxbejtZZpZYpIUqZ5GcGcgMlWo2eHnehyTRjqYtS2bf42mwiUqHDQf4N7MqGFj9vgEXrukf+LYRg5f80+Isaz92Q9cBI8luygpe+uV/4Rhwn0A5loNQz1wgqdhgo+THbfeS0IihbR8GIK13okdxIlwZmb99PSpO2HhE7acuS0cGl1uFVHjlTcl2QPQmsAlUQ5NhutuffZ4+Dt0+MZaXllxPyfJN0DsnNCbunbNpWfeS1aqHucL6OgyyxkNpyHoujgdKIJ6z/+QXbkcqMWntlCnmETtnyraeBBke20Rd8xdogNcS61VizlnhWbMXi5d6ZB2sjzL9+mY
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 454e81b8-382c-40ed-a0e8-08d81919f818
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2020 15:10:59.9396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z2UavFotIuL8Yo2Ke2MA5Lc0u88T9PxHXnJvDNnzlt0Nau7qsllOKhWq4NptbAKc22V0WScvftgaUEtQ+9mxJw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2366
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 15:11:06 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZlIENyb2NrZXIgPGRjcm9j
a2VyQGdtYWlsLmNvbT4NCj4gU2VudDogMjUgSnVuZSAyMDIwIDE0OjM2DQo+IFRvOiBEYXZpZCBJ
IDxEYXZpZC5JQG5jc2MuZ292LnVrPg0KPiBDYzogSUVURiBETUFSQyBXRyA8ZG1hcmNAaWV0Zi5v
cmc+DQo+IFN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gV2hhdCBpZi4uLiBTZW5kZXI6DQo+DQo+
IE9uIDYvMjUvMjAyMCAxOjU0IEFNLCBEYXZpZCBJIHdyb3RlOg0KPiA+IFdpdGhvdXQgZm9yY2lu
ZyBhbGlnbm1lbnQgdG8gJ0Zyb20nLCBhbiBhdHRhY2tlciBjYW4gc2V0IHRoZWlyIG93biAnU2Vu
ZGVyJywNCj4gc2V0IGEgJ0Zyb20nIHRoZXkncmUgbm90IGVudGl0bGVkIHRvIHVzZSB0aGF0J3Mg
b2YgYSB0cnVzdGVkIGNvbnRhY3QsIGFuZCB0aGUNCj4gRE1BUkMgYXNzb2NpYXRlZCB3aXRoIHRo
ZSBhYnVzZWQgZG9tYWluIGluIHRoZSAnRnJvbScgaGFzIG5vIGVmZmVjdCBhbmQNCj4gY2FuJ3Qg
YmUgdXNlZCBmb3IgZmlsdGVyaW5nLiBTbyB3aGlsZSB5b3UgY291bGQgc28gYSBzaW1pbGFyIGZp
bHRlciBvbiBTZW5kZXIsIGl0DQo+IHdvdWxkbid0IGJlIGFzIHVzZWZ1bCwgYW5kIHdvdWxkIHBy
b3ZpZGUgbGVzcyBzZWN1cml0eSBiZW5lZml0Lg0KPg0KPiBXaHkgaXMgaXQgdXNlZnVsIGluIHRo
ZSBGcm9tOj8gIFNlcmlvdXNseS4NCg0KQmVjYXVzZSB0aGUgY2xhaW1lZCBhdXRob3IgaXMgYW4g
aW1wb3J0YW50IGFzcGVjdCBvZiBhbnkga2luZCBvZiB0cnVzdCBjYWxjdWxhdGlvbiBvbiBhbiBl
bWFpbCwgaHVtYW4gb3IgYXV0b21hdGVkLiBTbyBhbiBhbGlnbmVkLCBhdXRoZW50aWNhdGVkICdG
cm9tJyBpcyBhIHN0cm9uZyBzaWduYWwuDQoNCj4NCj4gU2luY2UgdGhlIHV0aWxpdHkgb2YgRE1B
UkMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCByZWNpcGllbnQgZW5kLXVzZXINCj4gZGVjaXNpb24t
bWFraW5nLA0KDQpJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHRoaXMgYXNzZXJ0aW9uLiBUaGUg
RE1BUkMgc3BlYyBzdWdnZXN0cyBmb3IgcD1xdWFyYW50aW5lIHRoYXQgdW5hdXRoZW50aWNhdGVk
IG1haWwgZW5kcyB1cCBpbiBhIHNwYW0gZm9sZGVyLiBJdCdzIGFzc3VtZWQgdGhhdCB1c2VycyBh
cmUgbGVzcyBsaWtlbHkgdG8gb3BlbiBhbmQgdHJ1c3QgbWFpbCBpbiB0aGVpciBzcGFtIGZvbGRl
ciAodGhvdWdoIGl0J3Mgbm90IDEwMCUgb2YgY291cnNlKS4gU28geWVzLCB0aGUgdXRpbGl0eSBv
ZiBETUFSQyBoYXMgc29tZXRoaW5nIHRvIGRvIHdpdGggZW5kLXVzZXIgZGVjaXNpb24gbWFraW5n
Lg0KDQp3aHkgaXMgRE1BUkMncyB1c2Ugb2YgRnJvbTogYXV0b21hdGljYWxseSBiZXR0ZXIgdGhh
bg0KPiBoYXZpbmcgRE1BUkMgdXNlIFNlbmRlcjo/DQoNCkJlY2F1c2UgdGhlIEZyb20gZmllbGQg
aXMgdXNlZCBieSBzb2Z0d2FyZSB0byB1bmRlcnN0YW5kIHdoZXJlIGFuIGVtYWlsIGNhbWUgZnJv
bSwgYW5kIGFwcGx5IFVJLCBmaWx0ZXJzLCBhbmQgd2FybmluZ3MuIEknZCBiZSBmaW5lIGlmIGJv
dGggaGFkIHRvIGFsaWduIC0gdGhhdCB3b3VsZCBzZWVtIGxpa2VseSB0byB3b3JrIGZvciB0aGUg
c2VjcmV0YXJ5IHVzZWNhc2UgZm9yIFNlbmRlciBpbiBSRkMgNTMyMiwgYW5kIGludHJhLWNvbXBh
bnkgbWFpbGluZyBsaXN0cywgYnV0IG5vdCB0aGUgZ2VuZXJpYyBtYWlsaW5nIGxpc3QgY2FzZS4N
Cg0KPg0KPiBBdHRhY2tlcnMgZG8gYWxsIHNvcnRzIG9mIGJhZCB0aGluZ3MuICBTb21lIG9mIHRo
b3NlIGJhZCB0aGluZ3MgZG9uJ3QgYWN0dWFsbHkNCj4gbWF0dGVyLiAgVGhleSBtaWdodCBiZSB1
bmF1dGhvcml6ZWQsIGlsbC1pbnRlbmRlZCwgYW5kIGV2ZW4gbWFrZSB5b3Ugb3IgbWUNCj4gdW5j
b21mb3J0YWJsZS4gQnV0IHRoZXkgZG9uJ3QgYWN0dWFsbHkgaGF2ZSBhbnkgZWZmZWN0IG9uIGdl
dHRpbmcgYmFkIG1haWwNCj4gZGVsaXZlcmVkIHRvIHJlY2lwaWVudHMgbm9yIGFuIGVmZmVjdCBv
biB0aG9zZSByZWNpcGllbnRzLiAgQmFkIGFjdG9ycyB0cnkgYWxsDQo+IHNvcnRzIG9mIHN0dWZm
Lg0KDQpBZ3JlZWQuIEl0J3MgcG9zc2libGUgZm9yIGJhZCBhY3RvcnMgdG8gY29tcHJvbWlzZSBt
YWlsYm94ZXMgdG8gYnlwYXNzIGN1cnJlbnQgRE1BUkMgYmFzZWQgZmlsdGVyaW5nLiBTbyBpcyBE
TUFSQyBwb2ludGxlc3M/IE5vLCBiZWNhdXNlIGl0IGluY3JlYXNlcyB0aGUgY29zdCBhbmQgY29t
cGxleGl0eSBvZiB0aGUgYXR0YWNrLCB3aGljaCBpcyBhIHBvc2l0aXZlIHRoaW5nLg0KDQo+DQo+
IFNvIHBvaW50aW5nIG91dCB3aGF0IGFuIGF0dGFja2VyIG1pZ2h0IG9yIHdpbGwgZG8gZG9lc24n
dCBlbmQgdGhlIGFyZ3VtZW50Lg0KPiBXaGF0IG1hdHRlcnMgaXMgdGhlIC9lZmZlY3QvIG9mIHRo
ZWlyIGFjdGlvbnMsIG5vdCB0aGUgdGhlb3J5IG9mIHRoZWlyIGFjdGlvbnMuDQoNClRoZSBlZmZl
Y3Qgd291bGQgYmUgdG8gcGhpc2ggcGVvcGxlIG1vcmUgc3VjY2Vzc2Z1bGx5IGJ5IGV2YWRpbmcg
dGhlIGN1cnJlbnQgRE1BUkMgY2hlY2tzIG9uIEZyb20gYWxpZ25tZW50IGFuZCBmaWx0ZXJzL2Rl
dGVjdGlvbnMgYmFzZWQgb24gY291c2luIGRvbWFpbnMuDQoNCj4NCj4NCj4gPj4gSSBzdXNwZWN0
IHRoYXQgdmVyeSBsaXR0bGUgLS0gaWYgYW55IC0tIG9mIHRoZSBjdXJyZW50IHVzZSBvZiBETUFS
Qw0KPiA+PiByZWxpZXMgb24gYW4gZW5kLXVzZXIncyBhZGRyZXNzIGJvb2suDQo+ID4+DQo+ID4+
IEl0J3MgZGVmaW5pdGVseSB0aGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBwb3B1bGFyIGVtYWlsIHNl
cnZpY2VzIGRvaW5nDQo+IGZpbHRlcmluZy9hbGVydGluZyBiYXNlZCBvbiBhZGRyZXNzYm9va3Mv
a25vd24gY29udGFjdHMsIGFuZCBJJ20gY29uZmlkZW50DQo+IHRoYXQgRE1BUkMncyBhYmlsaXR5
IHRvIGZvcmNlIHVzZSBvZiBjb3VzaW4vYWx0ZXJuYXRpdmUgZG9tYWlucyBtYWtlcyB0aGlzDQo+
IG1vcmUgZWZmZWN0aXZlLg0KPg0KPiBJIGRpZCBub3Qgc2F5IHRoYXQgYWRkcmVzcyBib29rcyBh
cmUgbm90IHVzZWQgaW4gc29tZSBmaWx0ZXJpbmcgd29yay4NCj4NCj4gSSBzYWlkIHRoYXQgSSBk
b3VidGVkIHRoYXQgaXQgaXMgcmVsZXZhbnQgdG8gRE1BUkMgdXNlLiAgRmVlbCBmcmVlIHRvIGRv
Y3VtZW50DQo+IGNvdW50ZXItZXhhbXBsZXMuDQoNCk5vdCBzdXJlIGhvdyB0byBkbyB0aGF0IGJl
Y2F1c2UgaXQncyBhbiBpbmRpcmVjdCBlZmZlY3QuIERNQVJDIGZvcmNlcyBiYWQgYWN0b3JzIHRv
IGNvdXNpbiBkb21haW5zLCBhbmQgdGhlIGZpbHRlcmluZyBpcyBvbiB0aGF0LiBXaWxsIGdpdmUg
aXQgc29tZSB0aG91Z2h0Lg0KDQpEYXZpZA0KVGhpcyBpbmZvcm1hdGlvbiBpcyBleGVtcHQgdW5k
ZXIgdGhlIEZyZWVkb20gb2YgSW5mb3JtYXRpb24gQWN0IDIwMDAgKEZPSUEpIGFuZCBtYXkgYmUg
ZXhlbXB0IHVuZGVyIG90aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9uLiBSZWZlciBhbnkg
Rk9JQSBxdWVyaWVzIHRvIG5jc2NpbmZvbGVnQG5jc2MuZ292LnVrLiBBbGwgbWF0ZXJpYWwgaXMg
VUsgQ3Jvd24gQ29weXJpZ2h0IMKpDQo=


From nobody Thu Jun 25 08:17:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC53A0BED for ; Thu, 25 Jun 2020 08:17:30 -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, FREEMAIL_FROM=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=gmail.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 fAugZ1Lw4Cre for ; Thu, 25 Jun 2020 08:17:29 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F413A0BBE for ; Thu, 25 Jun 2020 08:17:29 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id l63so5237967oih.13 for ; Thu, 25 Jun 2020 08:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SN5DvO5QcYN+ceLdc5tVUGhtoU0bxBHYf9ZEJ4/OhRM=; b=A4Mtvd38jpxzbIj4HPf3xCySf9vmxXQfhyimDyJw/IYkNFvX1Igm0ZvZWnSzfQtMR6 7VWuLXsnLwoWBT9uuLuAK80yUdnA3DxVSIs2d09o6KyIKC1pOcr2ByK4Ajae98CiOsj/ /bdVLjgRG+wyv1tMcqoGqiTH5yyCdn/F+CWlm59qLHFdYeyx/Njy5XcguwrRHKGc2dwe brmNDML0iL6tdQ4V/a7EK4ghK+OkSmP26dUmAxfVVUcS+xMU3lYgGf49E8j5JLXLqDK4 xou6F+yrtqmBEPAeg63MZnYbvzJA+mfRRIXqA1hlhqp14Vm5ZHvzKn/0ZVHgsvsnS50R ZSyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SN5DvO5QcYN+ceLdc5tVUGhtoU0bxBHYf9ZEJ4/OhRM=; b=CzEvWx+TXVTdEJi6fMLUYqSR9SrnFrwYfSSlNcFudVB/O1vnjf75hjkKxhiLCYGWbA Y0Wgu0eGPfwpbIm3XeU8PZUNBrtgUs1Q/4kKpECaUXlmXcxmGWopcaHdnUIPnTPbb1+q 1DOrLZZl240R1imeOaIguv9d1cY1N5Cl27KTRPdumRNxucpBjjgCgld0JK4lnb51gi9q h9UQWW3JGSl0e+ODBpquel7ovfTKbkHxtijqn8nnWC0eC7GwjIcWgIcRhv1qbechHYvr ZzLRk8uxPwIJuzmpv8M2nYYpwJGOMFpO0o/jJljsfdOz/9YgoOtsHSgiiBDkFVvi6qps zeTA==
X-Gm-Message-State: AOAM53118mkVhz78T24BVv18nB0kMUwjzxtRDHUSZD/vtG0Zq04cWL8Z LADWJnPdCF2mj7M3Ehdq7ZSTVM5q
X-Google-Smtp-Source: ABdhPJztekXGYKJIz43Kg2G7E8alOrQsQdlzx47OmY24xV9dAxBrcXDwSszLy0KGDK5v9kNB3EjnQg==
X-Received: by 2002:aca:5bc3:: with SMTP id p186mr2637400oib.59.1593098248500;  Thu, 25 Jun 2020 08:17:28 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id y202sm349279oia.17.2020.06.25.08.17.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 08:17:28 -0700 (PDT)
To: Jim Fenton 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>   <75b1e9e8-bda7-3872-349a-08778855a825@bluepopcorn.net>
From: Dave Crocker 
Message-ID: <2aeebe5c-8c47-d6e9-6c8e-9e38b5fe9704@gmail.com>
Date: Thu, 25 Jun 2020 08:17:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <75b1e9e8-bda7-3872-349a-08778855a825@bluepopcorn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 15:17:31 -0000

On 6/24/2020 12:24 PM, Jim Fenton wrote:
> You have explained why Sender: is better than From: (which I agree with)
> but not why specifically Sender needs to be used.

Existing practice is less risky than new practice.  The existence and 
semantics of Sender: has been around for 45 years.  Its semantics match 
what is


> I see the use of a
> long-standing header field as being a disadvantage, not an advantage,
> because of potential obscure uses we don't know about.

That line of logic means we should never modify or add to any existing 
practice.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 08:29:13 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E603A0BC5 for ; Thu, 25 Jun 2020 08:29:11 -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, FREEMAIL_FROM=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=gmail.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 ZsxIsT5BscDv for ; Thu, 25 Jun 2020 08:29:10 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 94FE33A0BBE for ; Thu, 25 Jun 2020 08:29:10 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id k4so2460476otr.7 for ; Thu, 25 Jun 2020 08:29:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=R4tFRJJs8AeWRrMJdKh2Jg6dRtfYOdvNToh9odX0B20=; b=TiWHhVf3Y57XcuPN5SpcK8dLCc7Pl73jr/CBecydZ9yvDYQB5JS6038ktGInlZsyqQ z4rFFUlmGdWHYyra5+O+ENJONVjFZIaxgCXsTCIuqTHRr1SEXnvM1rMkNR1plHBg9OMQ KSaMbyTDBbgc+GcFlMlICNycUhnNt4IP6Fsb9capJTEwCNMesdZLNawBH39vjycJSUMo aaVYSD3WEigxt3vNnAtkcVspF+6AG3WcMb/e5JA/vglCcCLNnY1OSkMzVgCIHS6KWeNe zNZrxKgOGORWUax7d3oP0k6Sw9nYKi48MR/Zxs0y/VYuTzjaYhPhSwMO5QOtcPPEF6Zy QXlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=R4tFRJJs8AeWRrMJdKh2Jg6dRtfYOdvNToh9odX0B20=; b=hFn6FZpreS96ekG8UggUcxg4YC44/WbaekHca1KZNtXCRZO9MoIIf5LDuu0lERgTlz Vb6/9E94ljvm0Uwii/i7TwLEU+zUqHinC0Glz2tXliPq5LvV72UrJ72/yTYqLrMO6Otn e57OFcpFV4ZLFlipVZYWPSVKyzIkjOiG98POaykrP3s3m3/8SiR3pV4OVk66hXLgPuIP oslPlGUhTNe6hTjogFSAr/IXtm5qd4FF+ied0cREu1EKerG6tXUk4n7RMc+H+rMLNQ6m 1dheY5pnBgVDIuaLI7OiGDWIuCREdkT1z7mryG1gkkZ1+2cjZkguTYwJ30g7s7oamOmr MnIQ==
X-Gm-Message-State: AOAM5305V4J1umjcH8+iPMuOhQ8UQVlH0nBR4H7moMLc3sWaCOfEtbIp R+/gJQTiwZw6UwWsiUXeT04R2Qqt
X-Google-Smtp-Source: ABdhPJx4BwFN9M2dMaUrXniGeR2Csd4ek7IamnRL64tgAwrgu2ycG/cU9yUZOte1O6V9ZYJRxkBqPQ==
X-Received: by 2002:a05:6830:1292:: with SMTP id z18mr12938086otp.292.1593098949370;  Thu, 25 Jun 2020 08:29:09 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id 10sm5485853otq.52.2020.06.25.08.29.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 08:29:08 -0700 (PDT)
To: David I 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>   
From: Dave Crocker 
Message-ID: <57d4bf29-aa28-a06d-59d7-52e6c1998ae0@gmail.com>
Date: Thu, 25 Jun 2020 08:29:06 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 15:29:12 -0000

On 6/25/2020 8:10 AM, David I wrote:
>> From: Dave Crocker 
>> set a 'From' they're not entitled to use that's of a trusted contact, and the
>> DMARC associated with the abused domain in the 'From' has no effect and
>> can't be used for filtering. So while you could so a similar filter on Sender, it
>> wouldn't be as useful, and would provide less security benefit.
>>
>> Why is it useful in the From:?  Seriously.
> Because the claimed author is an important aspect of any kind of trust calculation on an email, human or automated. So an aligned, authenticated 'From' is a strong signal.

1. Signal to what and how is it used for filtering?

2. Why isn't an aligned Sender: just as strong?

3. Arguably the actual semantics of an aligned From:, for DMARC, is for 
an aligned Sender:, since the semantics of DMARC concern the 
organization and not the author.  Remember that From: typically 
conflates both author and operator information.


>> Since the utility of DMARC has nothing to do with recipient end-user
>> decision-making,
> I don't really understand this assertion. The DMARC spec suggests for p=quarantine that unauthenticated mail ends up in a spam folder. It's assumed that users are less likely to open and trust mail in their spam folder (though it's not 100% of course). So yes, the utility of DMARC has something to do with end-user decision making.

Users open mail in the spam folder all the time.


>
> why is DMARC's use of From: automatically better than
>> having DMARC use Sender:?
> Because the From field is used by software to understand where an email came from, and apply UI, filters, and warnings.

1. "Warnings" have no reliable utility.

2. UI behavior is what From: field alignment is breaking, given the 
workarounds that MLMs have to do

3. Filtering engines use a wide array of information; there is nothing 
magical about their use of From.  Also note  item #3, from above.


>> Attackers do all sorts of bad things.  Some of those bad things don't actually
>> matter.  They might be unauthorized, ill-intended, and even make you or me
>> uncomfortable. But they don't actually have any effect on getting bad mail
>> delivered to recipients nor an effect on those recipients.  Bad actors try all
>> sorts of stuff.
> Agreed. It's possible for bad actors to compromise mailboxes to bypass current DMARC based filtering. So is DMARC pointless? No, because it increases the cost and complexity of the attack, which is a positive thing.

I think you missed my point.  My point was that some of what attackers 
do doesn't matter.  It upsets us when we hear about their doing it, but 
it doesn't affect discoverability and it doesn't affect recipient 
behavior. We should worry about their actions that actually have a bad 
effect, not worry about actions we just don't like.


>> So pointing out what an attacker might or will do doesn't end the argument.
>> What matters is the /effect/ of their actions, not the theory of their actions.
> The effect would be to phish people more successfully by evading the current DMARC checks on From alignment and filters/detections based on cousin domains.

Your claim of 'successfully' means you have objective data 
substantiating the successes.  Please circulate it to us.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 09:53:33 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B253A0D37 for ; Thu, 25 Jun 2020 09:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk
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 5FLPHo6ZdGr3 for ; Thu, 25 Jun 2020 09:53:29 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110118.outbound.protection.outlook.com [40.107.11.118]) (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 54D863A0D35 for ; Thu, 25 Jun 2020 09:53:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVW5dMCKy2SgCx8B/zYbpeYZw7gBYGaRXy/d1pOMTzl5hpmiHwNjp0V9Fa9r3tf3ftyLWgzcz+v6Q2CEq/WhPSlWWGW4JZRIxpfpxyjnmUnNzdiP8wB6ayZCrWmAfb2gpa7Kk7DXIaXJZRPu6TVWZyFqGqXjzy0Vvb/4/nfRxMgrbk4hjKqEvvzOcodINNxouLz6LZCnG4mVDYB2Jel2DwwWAtbBS5ilbIoatE+QvPzb4mOgrxULKxDieHDaBTRqaM3oU4NXRdZc2gFRZGcDmOjOGHBxSot440iVpCa9w7Z4PfwPaz5N6RE9ebV7lYSLJLfJSEb/ZncLtt5GJC6QUg==
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=SfzfSm8ESfZkit1cQgpCiP9zvh2Tv8bpcfOchfvXL48=; b=hLV4cOCUkz7iEtulgzjrxlHPvTGaQV3ierFgLO29X77qsCGyM8hXBPlM//fOB3NnVkbS86zZQ/A0r+1MPUuLlI3MrXXpDIZNkNqmJUcmwe0jUBPF+biHaBAlx6R7rFWecwLhxV6g3cVu62y5FvkGR0qCml7aQdcq6kMhoRJ7Ebk7Dj8a/4WtnA8lz0edr11bK57iQQ9+hJ+xOezskVy4sMP6mh/UmxiIbqD9Ug4p6TeqUeKdWmTqOKdu6njmviJIun0skJkRY3bINgXOnY4UHY3WSPp2YhApH5MIbIFb+DL9507JlimH+Kee/kJ7afJ1VqUTnX24GbmeUGNDSqcmJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SfzfSm8ESfZkit1cQgpCiP9zvh2Tv8bpcfOchfvXL48=; b=FjvHOD6e25tTAKBgdLLadX5EasifyoIKlyOMoZT0IJCjMKwlU/bffTm9RhbuzxjD8H4yPtBNP/3Pp0ol0Y4moCOZtfTkgIvyWiMuxKEdul68qijSyiUHbqswnjHob8lGozvGG9jXbhXkzo5Y5RRkiqd3/LSXSf6LThP6sQY2oK+a0JO1KADkyYi6Dx73rCEHqFVxdnrX7Q4q6zT9ySBAwd2K5BEv+CnRljsTKJbru3zV0wT91IItDwcJeQWr4kndo0293CsVYVA0pwsni5AWck0TARaZ7ZIe72YwBy7tmFEDb/VOmky01EjyBR0gZGUo/A+Xdm36uIPvOylJe8fM8Q==
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c1::23) by LNXP123MB2187.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:dc::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Thu, 25 Jun 2020 16:53:26 +0000
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117]) by LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117%7]) with mapi id 15.20.3131.021; Thu, 25 Jun 2020 16:53:26 +0000
From: David I 
To: Dave Crocker 
CC: IETF DMARC WG 
Thread-Topic: [dmarc-ietf] What if... Sender:
Thread-Index: AQHWSY8PY6KKw8Z6qkO2oAr/+0mQJajndpXAgABSVICAATGzgIAAXWgAgAAI2QCAABa+AIAABEVw
Date: Thu, 25 Jun 2020 16:53:26 +0000
Message-ID: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>    <57d4bf29-aa28-a06d-59d7-52e6c1998ae0@gmail.com>
In-Reply-To: <57d4bf29-aa28-a06d-59d7-52e6c1998ae0@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk;
x-originating-ip: [51.140.114.144]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6258c842-1e5f-47c1-c2be-08d8192847dd
x-ms-traffictypediagnostic: LNXP123MB2187:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0445A82F82
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kUFFPkvUK7GIQlpTUz5+LCOm+yboPq8pywb5LVHejcDrqlL1RYrcKxrt9k2uTOqNxQk/o9U2uNxw0SV9JpX2ugxRepPeox0q1n5Jwfv1B8UpbJlrNbQlaiK26zLhk6NCRHQCH/AEezxRscAphYhxmV1fiCWjg/JmIFjco5VMB2u/5SrTzlHg9usOkXvnRqMFFXLEkbg8n2qVZTfSXFTbfQRplTbM7DODPW8Tj4NaJB1DD2BWg7Cb5PMkULP/D1bL9V7b7MC2t2k594O/R7QU3TssHmlmg/tpolIgpLsOyA0jPz7ZihO53m0Qk1frKnVBbNkG4PKIGCdHs+eTuLCFkA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39850400004)(346002)(136003)(366004)(396003)(376002)(55236004)(53546011)(71200400001)(26005)(316002)(478600001)(2906002)(7696005)(186003)(4326008)(83380400001)(5660300002)(55016002)(9686003)(86362001)(52536014)(6506007)(33656002)(6916009)(8676002)(8936002)(76116006)(64756008)(66556008)(66446008)(66476007)(66946007); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: 9TF9G17HmBTSPGWDj2vq8xT7pCIuVGPx9UztgwX0votESXjfdqJLxVOqUMDDEon6hBXGIR2ZflmyTaz0qSnh5xCR/3GD506W5N6BozD+scoeYvTI47k4SYgUkwaxVLor3fXmgLmrUIuHJRv5ueEC2/DqJW9GlaDLzejipszXCwiJbvbtp3NCGeINpTbE0uRdDnCfSEdvCLOCQON9gmkTnCOPGBMHpcnIkZCc/PpSUU2RZaSUenxNvliD8SC93HsUmXffaeg97/zX2JNs0IEnUU0ZohTm1gI9+U4Ze+EDWhLo6U7nO9oTdR7m/fAcXhm9pxfW2BWawCn6CuMqnGg2I4q+ERfCjKuk6NJaEdUcE6Kv/CQysBIyaxiPnyczksaZNAkFf/t5RwayiBFQOc3UaQZqflADtrYT/uZmtE/qwxKHWs8cxrofGgR97nyaozteN8apIhUZBj0YgueAifVIsIePWz66OlCLxmrIeVBmVsak6HPNtj1JNAdzHbHvAyTV
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6258c842-1e5f-47c1-c2be-08d8192847dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2020 16:53:26.7237 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6BajPo8x4t7FldNCl7yAeB+DIHPn+nvQFAOokMXok/mCzZZoCKrN25t5uQDEiUMe+7xAVrAR1TzZXcMA0zENuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2187
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 16:53:31 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZlIENyb2NrZXIgPGRjcm9j
a2VyQGdtYWlsLmNvbT4NCj4gU2VudDogMjUgSnVuZSAyMDIwIDE2OjI5DQo+IFRvOiBEYXZpZCBJ
IDxEYXZpZC5JQG5jc2MuZ292LnVrPg0KPiBDYzogSUVURiBETUFSQyBXRyA8ZG1hcmNAaWV0Zi5v
cmc+DQo+IFN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gV2hhdCBpZi4uLiBTZW5kZXI6DQo+DQo+
IE9uIDYvMjUvMjAyMCA4OjEwIEFNLCBEYXZpZCBJIHdyb3RlOg0KPiA+PiBXaHkgaXMgaXQgdXNl
ZnVsIGluIHRoZSBGcm9tOj8gIFNlcmlvdXNseS4NCj4gPiBCZWNhdXNlIHRoZSBjbGFpbWVkIGF1
dGhvciBpcyBhbiBpbXBvcnRhbnQgYXNwZWN0IG9mIGFueSBraW5kIG9mIHRydXN0DQo+IGNhbGN1
bGF0aW9uIG9uIGFuIGVtYWlsLCBodW1hbiBvciBhdXRvbWF0ZWQuIFNvIGFuIGFsaWduZWQsIGF1
dGhlbnRpY2F0ZWQNCj4gJ0Zyb20nIGlzIGEgc3Ryb25nIHNpZ25hbC4NCj4NCj4gMS4gU2lnbmFs
IHRvIHdoYXQgYW5kIGhvdyBpcyBpdCB1c2VkIGZvciBmaWx0ZXJpbmc/DQoNClNvbWUgZm9ybSBv
ZiBhbGdvcml0aG0gdGhhdCBmaWx0ZXJzIG9yIG90aGVyd2lzZSBwcm90ZWN0cyB1c2Vycy4NCg0K
PiAyLiBXaHkgaXNuJ3QgYW4gYWxpZ25lZCBTZW5kZXI6IGp1c3QgYXMgc3Ryb25nPw0KDQpCZWNh
dXNlIGl0IGRvZXNuJ3QgcmVwcmVzZW50IHRoZSBhdXRob3IsIHdoaWNoIGlzIHdobyB0aGUgdXNl
ciB0cnVzdHMgKHRoaXMgbWF5IGJlIGluZmVycmVkIGJ5IHNvZnR3YXJlIGVnIHRocm91Z2ggcHJl
dmlvdXMgY29udmVyc2F0aW9ucywgYWRkcmVzc2Jvb2sgcHJlc2VuY2UgZXRjKQ0KDQo+ID4NCj4g
PiB3aHkgaXMgRE1BUkMncyB1c2Ugb2YgRnJvbTogYXV0b21hdGljYWxseSBiZXR0ZXIgdGhhbg0K
PiA+PiBoYXZpbmcgRE1BUkMgdXNlIFNlbmRlcjo/DQo+ID4gQmVjYXVzZSB0aGUgRnJvbSBmaWVs
ZCBpcyB1c2VkIGJ5IHNvZnR3YXJlIHRvIHVuZGVyc3RhbmQgd2hlcmUgYW4gZW1haWwNCj4gY2Ft
ZSBmcm9tLCBhbmQgYXBwbHkgVUksIGZpbHRlcnMsIGFuZCB3YXJuaW5ncy4NCj4NCj4gMS4gIldh
cm5pbmdzIiBoYXZlIG5vIHJlbGlhYmxlIHV0aWxpdHkuDQoNCkluc29mYXIgYXMgaHVtYW5zIGNh
biBjaXJjdW12ZW50IHRoZW0sIHN1cmUsIHRoZXkncmUgbm90IDEwMCUgcmVsaWFibGUuIEFuZCB0
aGVyZSBhcmUgd2VsbC1kZXNpZ25lZCBvbmVzLCBhbmQgbm90LiBCdXQgdGhleSBhcmUgYSB1c2Vm
dWwgdG9vbCBmb3Igc29mdHdhcmUgZGV2ZWxvcGVycyB0byBoZWxwIHRoZWlyIHVzZXJzIHdoZW4g
dGhleSBkb24ndCBoYXZlIHN1ZmZpY2llbnQgZXZpZGVuY2UgdG8gc2ltcGx5IGRlc3Ryb3kgc3Vz
cGljaW91cyBlbWFpbC4NCg0KPiAyLiBVSSBiZWhhdmlvciBpcyB3aGF0IEZyb206IGZpZWxkIGFs
aWdubWVudCBpcyBicmVha2luZywgZ2l2ZW4gdGhlDQo+IHdvcmthcm91bmRzIHRoYXQgTUxNcyBo
YXZlIHRvIGRvDQoNCk1VQXMgaGF2ZSBsb3RzIG9mIG9wdGlvbnMgZm9yIGhvdyB0aGV5IHdhbnQg
dG8gZGlzcGxheSBhbmQgZGlmZmVyZW50aWF0ZSBtZXNzYWdlcyAoZWcgbWFpbGluZyBsaXN0cykg
YW5kIHN1cHBvcnQgdXNlcnMuIEknZCBsb3ZlIHRvIHNlZSBtb3JlIGNyZWF0aXZpdHkgaW4gdGhh
dCBzcGFjZS4NCg0KPiAzLiBGaWx0ZXJpbmcgZW5naW5lcyB1c2UgYSB3aWRlIGFycmF5IG9mIGlu
Zm9ybWF0aW9uOyB0aGVyZSBpcyBub3RoaW5nIG1hZ2ljYWwNCj4gYWJvdXQgdGhlaXIgdXNlIG9m
IEZyb20uDQoNCk1hZ2ljYWwsIG5vLiBBIHNpZ25hbCB5b3UgY2FuIGhlYXZpbHkgd2VpZ2h0IGFu
ZCByZWx5IG9uLCB5ZXMuDQoNCj4gPiBBZ3JlZWQuIEl0J3MgcG9zc2libGUgZm9yIGJhZCBhY3Rv
cnMgdG8gY29tcHJvbWlzZSBtYWlsYm94ZXMgdG8gYnlwYXNzDQo+IGN1cnJlbnQgRE1BUkMgYmFz
ZWQgZmlsdGVyaW5nLiBTbyBpcyBETUFSQyBwb2ludGxlc3M/IE5vLCBiZWNhdXNlIGl0DQo+IGlu
Y3JlYXNlcyB0aGUgY29zdCBhbmQgY29tcGxleGl0eSBvZiB0aGUgYXR0YWNrLCB3aGljaCBpcyBh
IHBvc2l0aXZlIHRoaW5nLg0KPg0KPiBJIHRoaW5rIHlvdSBtaXNzZWQgbXkgcG9pbnQuICBNeSBw
b2ludCB3YXMgdGhhdCBzb21lIG9mIHdoYXQgYXR0YWNrZXJzIGRvDQo+IGRvZXNuJ3QgbWF0dGVy
LiAgSXQgdXBzZXRzIHVzIHdoZW4gd2UgaGVhciBhYm91dCB0aGVpciBkb2luZyBpdCwgYnV0IGl0
IGRvZXNuJ3QNCj4gYWZmZWN0IGRpc2NvdmVyYWJpbGl0eSBhbmQgaXQgZG9lc24ndCBhZmZlY3Qg
cmVjaXBpZW50IGJlaGF2aW9yLiBXZSBzaG91bGQNCj4gd29ycnkgYWJvdXQgdGhlaXIgYWN0aW9u
cyB0aGF0IGFjdHVhbGx5IGhhdmUgYSBiYWQgZWZmZWN0LCBub3Qgd29ycnkgYWJvdXQNCj4gYWN0
aW9ucyB3ZSBqdXN0IGRvbid0IGxpa2UuDQoNCklmIEkgdW5kZXJzdGFuZCwgdGhlbiB3ZSBhZ3Jl
ZSB0aGF0IHRoZSBnb2FsIGlzIHRvIHN0b3AgYmFkIHRoaW5ncyBoYXBwZW5pbmcsIG5vdCBiZSB0
aGUgcHJvdG9jb2wgcG9saWNlLg0KDQo+ID4+IFNvIHBvaW50aW5nIG91dCB3aGF0IGFuIGF0dGFj
a2VyIG1pZ2h0IG9yIHdpbGwgZG8gZG9lc24ndCBlbmQgdGhlDQo+IGFyZ3VtZW50Lg0KPiA+PiBX
aGF0IG1hdHRlcnMgaXMgdGhlIC9lZmZlY3QvIG9mIHRoZWlyIGFjdGlvbnMsIG5vdCB0aGUgdGhl
b3J5IG9mIHRoZWlyDQo+IGFjdGlvbnMuDQo+ID4gVGhlIGVmZmVjdCB3b3VsZCBiZSB0byBwaGlz
aCBwZW9wbGUgbW9yZSBzdWNjZXNzZnVsbHkgYnkgZXZhZGluZyB0aGUNCj4gY3VycmVudCBETUFS
QyBjaGVja3Mgb24gRnJvbSBhbGlnbm1lbnQgYW5kIGZpbHRlcnMvZGV0ZWN0aW9ucyBiYXNlZCBv
bg0KPiBjb3VzaW4gZG9tYWlucy4NCj4NCj4gWW91ciBjbGFpbSBvZiAnc3VjY2Vzc2Z1bGx5JyBt
ZWFucyB5b3UgaGF2ZSBvYmplY3RpdmUgZGF0YSBzdWJzdGFudGlhdGluZyB0aGUNCj4gc3VjY2Vz
c2VzLiAgUGxlYXNlIGNpcmN1bGF0ZSBpdCB0byB1cy4NCg0KQ2xlYXJseSBJIGNhbid0IGhhdmUg
ZGF0YSBhYm91dCB0aGUgaW1wYWN0IG9mIGltcGxlbWVudGluZyB5b3VyIHByb3Bvc2FsLCBidXQg
SSBiZWxpZXZlIHRoZSBhYm92ZSBpcyBhIHJlYXNvbmFibGUgaW5mZXJlbmNlIGdpdmVuIHdoYXQg
d2Uga25vdyBhYm91dCB0b2RheSdzIHdvcmxkLg0KDQpJIHRoaW5rIHRoZXJlIGlzIGRhdGEgb3V0
IHRoZXJlIHNob3dpbmcgdGhhdCB3aGVuIGN1cnJlbnQgRnJvbS1hbGlnbmVkIERNQVJDIGlzIGFw
cGxpZWQsIHRoYXQgYXR0ZW1wdGVkIHNwb29maW5nIG9mIHRoYXQgZG9tYWluIGRyb3BzICh0aGUg
aW5mZXJlbmNlIGJlaW5nIHRoYXQgaXQncyBiZWNhdXNlIG9mIERNQVJDIEZyb20tYWxpZ25lZCBm
aWx0ZXJpbmcpLiBJZiBub3QsIEkgY2FuIHByb2JhYmx5IGZpbmQgdGhhdCBraW5kIG9mIGRhdGEu
DQpUaGlzIGluZm9ybWF0aW9uIGlzIGV4ZW1wdCB1bmRlciB0aGUgRnJlZWRvbSBvZiBJbmZvcm1h
dGlvbiBBY3QgMjAwMCAoRk9JQSkgYW5kIG1heSBiZSBleGVtcHQgdW5kZXIgb3RoZXIgVUsgaW5m
b3JtYXRpb24gbGVnaXNsYXRpb24uIFJlZmVyIGFueSBGT0lBIHF1ZXJpZXMgdG8gbmNzY2luZm9s
ZWdAbmNzYy5nb3YudWsuIEFsbCBtYXRlcmlhbCBpcyBVSyBDcm93biBDb3B5cmlnaHQgwqkNCg==


From nobody Thu Jun 25 10:14:49 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4E43A0DCF for ; Thu, 25 Jun 2020 10:14:47 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 bjPvgD3Ww7cP for ; Thu, 25 Jun 2020 10:14:46 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 2C6403A0DB4 for ; Thu, 25 Jun 2020 10:14:46 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:c12c:453b:d580:9764]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05PHEgTD006712 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 25 Jun 2020 10:14:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593105284; bh=mWtUDinMiaIp/w9liNpYNr/AMZOtJfj2QHwDSNTb8yU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dj6bnRgT8OS11V/hEa1MwU7oVj7wQyP8NcYO5s5pppQZ3J4aFXwWP83rN+UrTT33w A/bGCEsWv2nqUEBxKSsgvzaz8sDYxT2rBAmgcgNMPZaFKx37ANzyaomGbUEoBfNRmo YZNYCN2os7KZDgEOWCGsCdmrmNfOIWGam9srd5iI=
To: Dave Crocker 
Cc: IETF DMARC WG 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <6d2b6362-b121-2309-5d91-12a285df1cb3@gmail.com>   <75b1e9e8-bda7-3872-349a-08778855a825@bluepopcorn.net> <2aeebe5c-8c47-d6e9-6c8e-9e38b5fe9704@gmail.com>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <200fa8e8-0611-4ba9-2c84-71840f881f2b@bluepopcorn.net>
Date: Thu, 25 Jun 2020 10:14:36 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <2aeebe5c-8c47-d6e9-6c8e-9e38b5fe9704@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 17:14:48 -0000

On 6/25/20 8:17 AM, Dave Crocker wrote:
> On 6/24/2020 12:24 PM, Jim Fenton wrote:
>> You have explained why Sender: is better than From: (which I agree with)
>> but not why specifically Sender needs to be used.
>
> Existing practice is less risky than new practice.  The existence and
> semantics of Sender: has been around for 45 years.  Its semantics
> match what is
>
>
>> I see the use of a
>> long-standing header field as being a disadvantage, not an advantage,
>> because of potential obscure uses we don't know about.
>
> That line of logic means we should never modify or add to any existing
> practice.
>
We disagree. But I suggest we not bikeshed this any further until the WG
reaches rough consensus on whether DMARC binding specifically with the
From: domain is essential. Then we can decide what the "color" of the
header field should be.

-Jim


From nobody Thu Jun 25 12:12:48 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7F3A0FE1 for ; Thu, 25 Jun 2020 12:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.451
X-Spam-Level: 
X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=sQymVYNl; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=cn5Ew8/Q
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 tIpH1GfQXna0 for ; Thu, 25 Jun 2020 12:12:44 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7A8763A0FD4 for ; Thu, 25 Jun 2020 12:12:43 -0700 (PDT)
Received: (qmail 8331 invoked by uid 100); 25 Jun 2020 19:12:42 -0000
Date: 25 Jun 2020 19:12:42 -0000
Message-ID: 
From: "John Levine" 
To: dmarc@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=2084.5ef4f72a.k2006; i=news@user.iecc.com; bh=bC4hQMRYP2GQzfqFOh6vXEsfwZVWbI3EorGShQjjjSQ=; b=sQymVYNlWCE6PKRLyJppdNNwHcrZvazyCTXNKK4pMsMZSSE2bdjhP5cylK9Doeinp/Pd6pn1dGNXb/UlOlE3iW97hAxMmN1FO+Ysd1QE1fFXjJgJ7OJ8G0CW4rmEe8Bzq+Uq7l6W3qSOoqNhD917cGTkAsb/Ar1VJvyMegCTe8GcZLiUZYCLvxJUa/HQRBwztnUGi0/xoyYMr4g86xE7Koo3XJwwp6BW/VhZn0LC/q2Xrr7FSV4zjLhtPDOEvPyt
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=2084.5ef4f72a.k2006; olt=news@user.iecc.com; bh=bC4hQMRYP2GQzfqFOh6vXEsfwZVWbI3EorGShQjjjSQ=; b=cn5Ew8/QgOB403GywOuo2UQ+X2l2QluZnogJL8MIxGAHACzBuOavzsvot/TXfSwqVDSdaVgpNkBYscgVinV59mYj3F5nY0Yr7dcGjgb5p/lvzgEP9kv0I79FvD99xDoPxk+NBmGxL22NTFX+Bw6nymkQw7kEMzxa5NAuxwhSjL3pdxlRQ5WfGzyAcANFJkZf4VlrPG2yki6ZNrNjibc3B29BApcMpsqgJdw4uPK+SSu8Int9m4YV4oS9daSp+kBQ
Organization: Taughannock Networks
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com> 
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com> 
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 19:12:47 -0000

In article ,
David I   wrote:
>Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted
>contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could
>so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit.

It sounds like you're making the common mistake of confusing "DMARC
aligned" with "not phish" or "not spam". What would you do with a
DMARC aligned message with this From header?

  From: Security Alert 

(The correct answer is bury it deep in the phish tank.  Crooks can
do DMARC alignment, too.)

Any sensible mail provider will do its usual reputation checks on the
validated identity, whichever header it is, and decide whether to
deliver the message or not. I believe that Dave's point is if you're
going to do that, validating the sender gives you useful flexibility
without a lot of loss of security.

On the other hand, if you're going to do that, why do you need DMARC
at all? You use the d= in valid DKIM signatures.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Thu Jun 25 12:13:42 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F273A0FE1 for ; Thu, 25 Jun 2020 12:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=KLH81B12; dkim=pass (1536-bit key) header.d=taugh.com header.b=l2yspwcQ
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 zOoFdvjdKAMs for ; Thu, 25 Jun 2020 12:13:39 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0275C3A0FD4 for ; Thu, 25 Jun 2020 12:13:38 -0700 (PDT)
Received: (qmail 8621 invoked from network); 25 Jun 2020 19:13:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=21ab.5ef4f761.k2006; bh=wfmraqCEeR1dfR13uap8JiamSjm2Ay31m6/d4SJYd/M=; b=KLH81B12R+3Y49pfTbtsEBw/aYG/UnoEgrTrinH1agw5VD8h8pUiseDgH727JS+EIgLJ9mj4sPR+JpyLlFzKgFNfew/Ks15eYLOBCnlrVjouluSh+a2QXnHhnhmVj+iRDofsi/UpvPNXTVjzrz0W1QXlzDHBYKJgRwMAOAGfCPlyQz5BQ6AOiAhdqec9cLV46154pPMrNrTd2fEMut4oH6gZvUzFBS2ENEt+1s75+jAM5X7LE4dTi+YBFLluWdIO
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=21ab.5ef4f761.k2006; bh=wfmraqCEeR1dfR13uap8JiamSjm2Ay31m6/d4SJYd/M=; b=l2yspwcQZlQ+bo/jW5RG/CdX5bmciCMxTql1ffcre5SBlvWAuicIntkh+1mqaNoGsATOk2eKKDAoKiUeYRzi0L0uC59soSBrmaIbe2lHoZ1wr6W1F4X8EWPUYy//ilFhibrW2JD3Am7CDw05q8tCxVDjuTuf0tUhshJomh1r+rxJjaH6TFvGZBJsQmYrsqHStbL5QC0/Q3SIWlj73FXhh4uh+lwZs3qR6zUaqPu7ccJPRxE+39t8dkWk1u8ne2nt
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 25 Jun 2020 19:13:37 -0000
Received: by ary.qy (Postfix, from userid 501) id 67B281BB10AD; Thu, 25 Jun 2020 15:13:37 -0400 (EDT)
Date: 25 Jun 2020 15:13:37 -0400
Message-Id: <20200625191337.67B281BB10AD@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] (no subject)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 19:13:41 -0000

In article  you write:
>First ler us be clear.  DMARC does not create a significant delivery problem for mailing lists.

Assertions like this are extremely unhelpful.

Some of us have been running lists for 30 years (yes, really) and are quite aware what the problems are.

R's,
John


From nobody Thu Jun 25 14:11:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697D3A101F for ; Thu, 25 Jun 2020 14:11:01 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=LpOZuec1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=k1t8i7ix
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 AoTy_80DIFmR for ; Thu, 25 Jun 2020 14:10:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9DB3A101C for ; Thu, 25 Jun 2020 14:10:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 328C4F80263 for ; Thu, 25 Jun 2020 17:10:58 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593119458; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=u1zQxv64soTacvorwHbMVsJRS8HZX669W31M+j7GTCM=; b=LpOZuec1A+hYGT8JTnIVjsI8XW4pu2y1gFLcFODnuhTjBPX8Ew7/ShWEzCQKtHPvPc0Mp xcksQ+qvPixFkxpAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593119457; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=u1zQxv64soTacvorwHbMVsJRS8HZX669W31M+j7GTCM=; b=k1t8i7ixymegSB16oa+slnzCWX2AIS5vDGe9dnmObBu+KWGEsLKxPZfRddipj7BsD9cC8 p1wQJ5ao0p1engPMkgd2tFTGdMiu5O4Rtox6tYv3QADLLCQ3WaTXOpZO45z5b9nVyFKeBid r2RIX8bH3tlVDpiVD9/tX+Ckn2pbMgkLhi9s2NAfHlXWa0Gs2pwXqJBBblUX7pVwxB998Ak 5oyIfkstHhovYoRKGXh6VKzqkotRjaSi8py+gpme3a6A4g1HM+IYWJgQHTJqRTV7D5IfLoU ZV/ydtQV8bnjZGzF6qgvlB9vMdgFYiyMIz3w2dSXvwNOCKjDpyny4oEyw8+Q==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E22CBF800DE for ; Thu, 25 Jun 2020 17:10:57 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Thu, 25 Jun 2020 17:10:57 -0400
Message-ID: <3519815.6odjxCbuFl@zini-1880>
In-Reply-To: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 21:11:01 -0000

On Tuesday, June 23, 2020 2:49:11 PM EDT Dave Crocker wrote:
> Folks,
> 
> This note is partially triggered by Mike's note this morning, but isn't
> specifically responding to it.  Rather it tries to elaborate on a
> premise I've been implying but haven't been explicating:
> 
>       What if the rfc5322.Sender field were typically/always present?
> 
>       Or at least, what if it were always present for domains publishing
>       DMARC records?
> 
> 
> What if messages generally had Sender: fields, even when they are the
> same as the email address of the From: field?  So for such domains the
> From: really would only be the author information and the Sender: would
> be the operational handling/sending information.(*)
> 
> The thrust of my reference to making a separate Sender: field prevalent
> is an assumption that the patterns of evaluating email addresses could
> adapt to take advantage of the reliable distinction.  For one thing, it
> could clarify the nature of the information used for filtering.
> Currently we conflate 'handling agent' (or 'transmission agent')
> information with 'authoring agent' information.
> 
> This leads to statements about end-user effects that actually are
> fundamentally wrong, even as the use of supposed author address
> information is demonstrating filtering efficacy.  What would happen if
> filtering agents had an explicit distinction between 'author' and
> 'sender'?
> 
> It might be claimed that they already do, since the DKIM d= field refers
> to a handling agent, rather than author, and is explicitly independent
> of any other message address information.
> 
> So, why isn't it reasonable, for example, to have DMARC publish a record
> declaring a requirement for a DKIM or SPF record, independent of From:
> field alignment?  That is, publish a record that says all mail by agents
> of that domain is always authenticated?
> 
> It's because the signature needs to be tied to a field that is already
> 'interesting' and always present.  Otherwise there is no way to know
> what domain name to look for.  In practical terms, the only available
> choice has been From:.  First, it certainly has an interesting semantic
> -- but really semantic/s/ -- for the address, and second, it's always
> present.
> 
> So... what if DMARC's semantic were really for the Sender: field?  If a
> message has no separate Sender: field, then of course the domain in the
> From: field is used.
> 
> The would produce obvious possibilities:
> 
>     From: someone@goodplace.example
>     Sender: someone@goodplace.example
> 
> and
> 
>     From: somone@goodplace.example
>     Sender: someone@mlm.example.com
> 
> where there might be a dmarc record for mlm.example.com
> 
> The modification to DMARC would be "look for Sender: and if it isn't
> present, look for From:.
> 
> Obviously, mlm.example.com might instead be badactor.example.com.
> 
> but we already have to deal with cousin domains, and DMARC does nothing
> about them.
> 
> So if Sender: wouldn't be as useful as From:, why not?

I've tried to follow this thread.  I've no idea where to start to comment, so 
I went back to the beginning.

I would encourage people to review the working group charter.  I think dumping 
5322.From and aligning to something else is well outside of it.  Not saying we 
couldn't recharter, but I'm skeptical of the value of this entire thread.

I wasn't there at the creation of DMARC, but it seems likely that 5322.From 
alignment wasn't picked at random.  I don't think any amount of post-facto 
sophistry on IETF mailing lists will make that not true.

Before we even think about alternatives, I'd like to hear from someone who was 
involved in the original effort explain the rationale for alignment to 
5322.From and see a discussion on why that original rationale is now wrong 
(imagine I explain Chesterton's Fence here).

Also, why an email address at all (base on my reading of the thread)?  If some 
of the assertions being made are accurate, any random opaque identifier would 
do just as well.

Scott K



From nobody Thu Jun 25 14:16:51 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855B23A1020 for ; Thu, 25 Jun 2020 14:16:49 -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, FREEMAIL_FROM=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=gmail.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 0ciRh0J8wPJ9 for ; Thu, 25 Jun 2020 14:16:48 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 5DC9E3A101D for ; Thu, 25 Jun 2020 14:16:48 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id w17so5553666oie.6 for ; Thu, 25 Jun 2020 14:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=oNAnqpK89ofH7pv8cGw2CE72PQFGSgr+g5i54Q9h2/M=; b=sfC/OG3e376MkrulORTC7px7pVPg0LcCrWrP8eKsW5ADTMKnrzwWnGVTmq3+dkh0M0 GAkqilocIGSLrify9UGe4HNT00ReBXgdvlpb6LI0foWW2YQfVpXeZpTDVvJ6Y5RrrUr1 SgrxmphpYdmOQVIolwMo00275m3FNTp4aERubbzR0NjXwtrnI/szubhEk3UJ6psWG4QI TEPd6acd75Dz3OcEBLrQNg6qfzPjQmwMpfHqkjRWctOBzf+0FjdwChFFL3r7E90+JuCW wSjrIrCXPluTb5bZdBvF5uMXPevjStZrGrQBr+vdUyFr6akdfAyXaoGn7T4cOzgdvcvi hOhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oNAnqpK89ofH7pv8cGw2CE72PQFGSgr+g5i54Q9h2/M=; b=WSepKjxSUwbam95rgmdx+sVRxH//SPFvXVKWgpKLzKx1gsewHHwJdRywb5VmVIxusI aH2lI5hurT8FwRLEsSDd7uJaQBZ2slOv2vR61wVVI9FnCicb/kUGYR4Cu171aL8smI5j Np3Zndmv7s+8sXUlzo5tgxgXPD6/gEG/AZZh6NAvY6qXVm68AibwgDvjAk3Kn/Dsxie/ dNa7HFAk5k0O9P9CFjJvhNcwKoFBoDO/ZWNI2Zvn3AXdNjrL5nAp7sXfk2Ax6dmogSo/ bctQeRcRvdeZfoU7ssUDWoSpfQdqYyn2f3EvkS+cNiaJrRZMsQwNNhBz0KrpVVexXqMe iJUw==
X-Gm-Message-State: AOAM5332iZUQyUcUrkAN/7kAlsyEd/KK6SEs6UlI2lYDfpaAEGgqy8l9 9we8rPhw7gdjiYsrXb6AyCYqD/HW
X-Google-Smtp-Source: ABdhPJzLZoLC5aHZ+sa47GEOd5S8qllAwpXX6p6YNtnGB0l3rjE1FVvDuidlUhYdrzPiWabDoWMvQQ==
X-Received: by 2002:a05:6808:6c9:: with SMTP id m9mr4034557oih.137.1593119807376;  Thu, 25 Jun 2020 14:16:47 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id d13sm5722731otq.46.2020.06.25.14.16.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 14:16:45 -0700 (PDT)
To: Scott Kitterman 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com>
Date: Thu, 25 Jun 2020 14:16:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <3519815.6odjxCbuFl@zini-1880>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 21:16:50 -0000

On 6/25/2020 2:10 PM, Scott Kitterman wrote:
> I would encourage people to review the working group charter.  I think dumping
> 5322.From and aligning to something else is well outside of it.  Not saying we
> couldn't recharter, but I'm skeptical of the value of this entire thread.


What is it about Item 1 in the charter that precludes this work?

What is it about Item 2 in the charter that precludes this work?


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 14:20:45 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62A3A1026 for ; Thu, 25 Jun 2020 14:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ym+bLeez; dkim=pass (2048-bit key) header.d=kitterman.com header.b=sFLby1y3
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 DDC8lKLdVu0U for ; Thu, 25 Jun 2020 14:20:42 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC3C3A1023 for ; Thu, 25 Jun 2020 14:20:42 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 67805F80263 for ; Thu, 25 Jun 2020 17:20:41 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593120041; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=olvTMJLcXmX6cePKVRNUXTrf18aFM7QHa5j8ZqLtxok=; b=ym+bLeezF7g7pfJ30qe5qB2unWUn3Ogy1w/OdAoMRLGK5pHH/oHi9yAwo01pb7RyuxoUw sF2huNv/EtRNn/vBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593120041; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=olvTMJLcXmX6cePKVRNUXTrf18aFM7QHa5j8ZqLtxok=; b=sFLby1y3NMUAVU08hJNL40Liu1VQtmhL/WvxNdluau8dacVE2P9pUBIYOs5ztwZ+R8Ald LvZ/lxKx8w3Z2LFCeRHBHnKOVO0I6U+M1l8ray4Keq189ywTmarEHcqYolbw9a2HZTJjTaA WZRr5+gHeKQ99Z5srN64uZLYcZwkzXm2E6g2+m4/rSX1IeHhL5bpIDY9l8XADonoM9PT2RR 3s6WuI9ntZTknRxvCsnMCFsjmQ10fYKSoH5/GWNqKpwelSobQxbc0a6m0NrSM0BzWH98VVC V2+Qh4badXmN/BhTd+x6EcexoUF1YRRHVB6A2sEZDdtOAhGM40t2dEWc1YDw==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 35865F800DE for ; Thu, 25 Jun 2020 17:20:41 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Thu, 25 Jun 2020 17:20:40 -0400
Message-ID: <1986956.MqcZLKCXeg@zini-1880>
In-Reply-To: <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com>
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 21:20:44 -0000

On Thursday, June 25, 2020 5:16:43 PM EDT Dave Crocker wrote:
> On 6/25/2020 2:10 PM, Scott Kitterman wrote:
> > I would encourage people to review the working group charter.  I think
> > dumping 5322.From and aligning to something else is well outside of it. 
> > Not saying we couldn't recharter, but I'm skeptical of the value of this
> > entire thread.
> What is it about Item 1 in the charter that precludes this work?
> 
> What is it about Item 2 in the charter that precludes this work?

Even before you get to those:

> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and provide detailed justification
> for any non-interoperability.

In fact, the first sentence of the charter includes it in the definition of 
DMARC:

> Domain-based Message Authentication, Reporting & Conformance (DMARC)
> uses existing mail authentication technologies (SPF and DKIM) to
> extend validation to the RFC5322.From field.

This entire thread is about making something that's not DMARC.

Scott K



From nobody Thu Jun 25 15:06:07 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2C3A1047 for ; Thu, 25 Jun 2020 15:06:06 -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 (1024-bit key) header.d=bluepopcorn.net
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 3dKD-OwCVS92 for ; Thu, 25 Jun 2020 15:06:03 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 9D5B63A1045 for ; Thu, 25 Jun 2020 15:06:03 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:c12c:453b:d580:9764]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05PM61qb010562 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 25 Jun 2020 15:06:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593122763; bh=X4IuDOfnLIhm1nR5WMvy7Z92FBF4ZmftKiLoDZdLs3I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d18c4IHH/tgpOjtOYiFlHCS0bgcINcMmSNMWeqN24IRONYjex2jW9RyFEy+92YadR UQ20x5F0/Gn/LJ0tct+EIIueaZzD9i+hNn76yLniEwgVuQCqNSmc04B0JWd54/oFa4 11GyOSywwCKokilw+2tFzkHHpakIJ7SbxF+o54Vk=
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>  
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: 
Date: Thu, 25 Jun 2020 15:05:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4B0051691668F74A2BA2CF77"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:06:06 -0000

This is a multi-part message in MIME format.
--------------4B0051691668F74A2BA2CF77
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/25/20 12:12 PM, John Levine wrote:
> Any sensible mail provider will do its usual reputation checks on the
> validated identity, whichever header it is, and decide whether to
> deliver the message or not. I believe that Dave's point is if you're
> going to do that, validating the sender gives you useful flexibility
> without a lot of loss of security.
I'm not sure what validating the sender (either) accomplishes.
>
> On the other hand, if you're going to do that, why do you need DMARC
> at all? You use the d=3D in valid DKIM signatures.
>
+1, although there's also the reporting piece of DMARC, which can be
used to alert the domain to authentication breakage and perhaps certain
types of abuse.

-Jim


--------------4B0051691668F74A2BA2CF77
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    On 6/25/20 12:12 PM, John Levine wrote:
    
    
    
    
    
      
    Any sensible mail provider will do its usual reputation checks on the

    
      
    validated identity, whichever header it is, and decide whether to
deliver the message or not. I believe that Dave's point is if you're
going to do that, validating the sender gives you useful flexibility
without a lot of loss of security.
    
    
    
    I'm not sure what validating the sender (either) accomplishes.
    
    
    
      
    
On the other hand, if you're going to do that, why do you need DMARC
at all? You use the d= in valid DKIM signatures.


    
    
    
    
    +1, although there's also the reporting piece of DMARC, which can
      be used to alert the domain to authentication breakage and perhaps
      certain types of abuse.
    
    
    -Jim
    
    
    
  


--------------4B0051691668F74A2BA2CF77--


From nobody Thu Jun 25 15:11:07 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473723A100F for ; Thu, 25 Jun 2020 15:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=aUYwWEkR; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=UcBM6tdJ
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 P5ztLC95gQrs for ; Thu, 25 Jun 2020 15:11:03 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [76.245.57.69]) (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 3CD363A1008 for ; Thu, 25 Jun 2020 15:11:02 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=772; t=1593123057; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=IPALvgcZQUETKZApN+dlnUtJhFE=; b=aUYwWEkRFsUk5tlgAYLuKEqcSqsywDC7+r1bXcNTNiLugzjdFZ2nbYUlvL/rkD 6YuG0vwBRPkaoYgaGf8i8lbumczPIJ8rru6rmcwWTjvqfwnJRmzJwlEY/mljF6sb sj++N0lYC3pCnehs28B46I0lR9ibHLqEShtq9kCtakKcA=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 25 Jun 2020 18:10:57 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3850348813.1.3892; Thu, 25 Jun 2020 18:10:55 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=772; t=1593122997; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=31gsUDr VU4TdKHm8djEwXoqLEjvn2/VaGZNxPW7OJjc=; b=UcBM6tdJXz3HrN91h+N449R U48YmCb3fErGIz+pEoFrvY8G83MnpLmD7k43b0x4dqyE52q5xLT9XnObcEFa1u1L yebg3vfm6tzS7Z7MRh3fPaPW7/0x8v4wZ0+73eMqXRg8i/2UEKQaGqFOBcc8gHUy COb2bWPEjkvW4gMU51Mg=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 25 Jun 2020 18:09:57 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 561725407.1.50204; Thu, 25 Jun 2020 18:09:56 -0400
Message-ID: <5EF520F1.2030307@isdg.net>
Date: Thu, 25 Jun 2020 18:10:57 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880>
In-Reply-To: <1986956.MqcZLKCXeg@zini-1880>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:11:05 -0000

On 6/25/2020 5:20 PM, Scott Kitterman wrote:
> On Thursday, June 25, 2020 5:16:43 PM EDT Dave Crocker wrote:
>
> This entire thread is about making something that's not DMARC.

I agree, but I am willing to see an algorithm, not just subjective 
administration considerations.  The Sender is only added by one 
component in my mail framework, the list server, in fact, it adds two 
headers:

Sender:
Errors-To:

Which means, I suppose, "I'm your sender, but if you have any 
complaints, talk to Errors-to:"

Should they align?  and with 5322.From, how?

DMARC needs a 3rd party solution.  SPF has it because it allows you to 
authorize other IPs outside your own network.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Thu Jun 25 15:18:32 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124813A1013 for ; Thu, 25 Jun 2020 15:18:31 -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 (1024-bit key) header.d=bluepopcorn.net
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 nFDo6S71I7bp for ; Thu, 25 Jun 2020 15:18:29 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 9B88A3A100F for ; Thu, 25 Jun 2020 15:18:28 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:c12c:453b:d580:9764]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05PMIQPE010839 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 25 Jun 2020 15:18:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593123508; bh=LYH95JQXHsFmvMmoYpS4MrwhC4VmhiPOzVPANPXGuTc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DCtJ+5Cj3xhRONmaXFsjM0VgiLYNHB5SSpsNSvcIOacFB1HdiHJgKDWef+8y8HS6H dKGqMuPGYv3IJBOL6kxHpDeh9BehOx0V9fLqABeDmHSE8MQMTIMWUr7qR+NUpgjLZe BaGdzb3L7u4SI2JPfpE0PlyMj86Yr/5DWRpssXvE=
To: Scott Kitterman , dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880>
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net>
Date: Thu, 25 Jun 2020 15:18:21 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <1986956.MqcZLKCXeg@zini-1880>
Content-Type: multipart/alternative; boundary="------------50823CEAE7AC3DE480FD151E"
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:18:31 -0000

This is a multi-part message in MIME format.
--------------50823CEAE7AC3DE480FD151E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 6/25/20 2:20 PM, Scott Kitterman wrote:
>
> Even before you get to those:
>
>> The working group will seek to preserve interoperability with the
>> installed base of DMARC systems, and provide detailed justification
>> for any non-interoperability.

The paragraph goes on to say:

> As the working group develops solutions
>    to deal with indirect mail flows, it will seek to maintain the
>    end-to-end nature of existing identifier fields in mail, in
>    particular avoiding solutions that require rewriting of originator
>    fields.
I interpret that "seek to" as of equal importance to the previous one.
But we're spending an awful lot of WG bandwidth discussing rewriting,
while Dave's "what if" proposal doesn't require any.

-Jim



--------------50823CEAE7AC3DE480FD151E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    On 6/25/20 2:20 PM, Scott Kitterman
      wrote:
    
    
    
    

    
      
    Even before you get to those:


    
      
    
        
    The working group will seek to preserve interoperability with the
installed base of DMARC systems, and provide detailed justification
for any non-interoperability.
    
      
    
    
    
    
    The paragraph goes on to say:
    
    
    
      
    
        
    As the working group develops solutions
   to deal with indirect mail flows, it will seek to maintain the
   end-to-end nature of existing identifier fields in mail, in
   particular avoiding solutions that require rewriting of originator
   fields.
    
      
    
      I interpret that "seek to" as of equal importance to the previous
      one. But we're spending an awful lot of WG bandwidth discussing
      rewriting, while Dave's "what if" proposal doesn't require any.
    
    
    
    
    -Jim
    
    
    
  


--------------50823CEAE7AC3DE480FD151E--


From nobody Thu Jun 25 15:34:06 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EF3A104B for ; Thu, 25 Jun 2020 15:34:04 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=KLxY1rfC; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jCrWzJNk
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 gT2RNDol_50e for ; Thu, 25 Jun 2020 15:34:02 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D890B3A101F for ; Thu, 25 Jun 2020 15:34:02 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id E10A7F80263; Thu, 25 Jun 2020 18:34:01 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593124441; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cbp9bCbYXbFGndKw+w5W2ba+mkOOvOq7bj7ecVLEAy8=; b=KLxY1rfC1Grh64J6jpnHjVVadSpm+IOqDqIie0SxAnhF2G1bcPl9M3N7N2I0dXR64ycDU UISBenUMWKsRXcqDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593124441; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cbp9bCbYXbFGndKw+w5W2ba+mkOOvOq7bj7ecVLEAy8=; b=jCrWzJNkc6WDDHm0mXJc/+y56SoyxwpfMMgJsQ03yRZI2rYMZnhETAJGfczf3bKogGGZY SgsucQt22L/hW0AwEQFYQPpgnpWnM4J0lCZJiKCYBwvhhlD2sb1Ai4LvJXtetvk617wDfwm uJCo+9bvwkoi4q3YxpKgapmsYzc8/DVFBJ6Z7P1hmA86KZR6iCKAnPmvbXnzIYMczBbLHJm H80Fk7xiKSr4BUzDSFwePGugM4AjnMCLAVPT1F/w0e9KPP/N1QbVvfanXDboXd7hUKpC7Rm NH8YLclKefHWACgKZk9q6jy/DH/0CnQAzhB7b21PTLg2Imw2MZNvRuJD9O2g==
Received: from [10.149.227.216] (mobile-166-170-32-56.mycingular.net [166.170.32.56]) by interserver.kitterman.com (Postfix) with ESMTPSA id 62951F800DE; Thu, 25 Jun 2020 18:34:01 -0400 (EDT)
Date: Thu, 25 Jun 2020 22:33:58 +0000
In-Reply-To: <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net>
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman 
Message-ID: <0940B242-F49E-4297-868E-9B6598978967@kitterman.com>
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:34:05 -0000

On June 25, 2020 10:18:21 PM UTC, Jim Fenton  wr=
ote:
>On 6/25/20 2:20 PM, Scott Kitterman wrote:
>>
>> Even before you get to those:
>>
>>> The working group will seek to preserve interoperability with the
>>> installed base of DMARC systems, and provide detailed justification
>>> for any non-interoperability=2E
>
>The paragraph goes on to say:
>
>> As the working group develops solutions
>>    to deal with indirect mail flows, it will seek to maintain the
>>    end-to-end nature of existing identifier fields in mail, in
>>    particular avoiding solutions that require rewriting of originator
>>    fields=2E
>I interpret that "seek to" as of equal importance to the previous one=2E
>But we're spending an awful lot of WG bandwidth discussing rewriting,
>while Dave's "what if" proposal doesn't require any=2E

True, but I think it's on topic for a DMARC replacement working group, not=
 this one=2E

Scott K


From nobody Thu Jun 25 15:53:46 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBB43A1055 for ; Thu, 25 Jun 2020 15:53:45 -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, FREEMAIL_FROM=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=gmail.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 C1Il2xVLF0jw for ; Thu, 25 Jun 2020 15:53:44 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 0B08D3A1054 for ; Thu, 25 Jun 2020 15:53:44 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id u23so6870309otq.10 for ; Thu, 25 Jun 2020 15:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MxjWpe6KBUPGsRXH+5UMouWHp0wPWx79kMy9hALiRbc=; b=d0pFZS7E6caSSBVuZikGFyzPIlJS36bTM+jiu+/U68VOfUSXoJaP2GkycprpM5buWc TZKdHD2OOJrRP1Kq4gfi1Kr+/9xAT6ZWig5nfGVxIt8b69xFYIim/QX6Bq3DkK3pbuet BMVXFJqCDexTonbzuTP6lzfWm2xtzroBZHOcjYELIcEM/acfjs76YN4Mo0ETbC2HkgjV d45gU/XZRB7a9Hf6r2AYdjbUZg1Wo2erj538jh7CWaYeeVftTngQmQbB4RuS58v0csT5 5slSZA8+0wVicLgnfQ1nkarq8k9Zo53NWFx7y+jSyKgezrFFeNNyNoBiiS4DM/Z9fB/q oR8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=MxjWpe6KBUPGsRXH+5UMouWHp0wPWx79kMy9hALiRbc=; b=LNEg5c8p41AYNQr2pYGAIewmO36DLXH7OhUkbj9M8TYR0TTH2Flx/8RaBI299YQCXX 5WHLf2LrySso1rej0B6sS3LwPatSDxwC8cluZra/DOTd06LMDYN1TcLHmd6+X7yFoPn9 1pce1oZPN8sjKp36fPPMsAmj/QmDIvDy1RwScHPJUm1s0GcRr4OQUPDUbfb5gz5fmNXm 8mekO+XnPD9Vujm2+4A+gR8z9RJLigswy0nt/wShUvkr4XLN5e+eTsh7z8TdInohhbjL +uyu/IQ7zhe69u8PNDf4VuLRRQPeVCw19LNZFAw+8rvoTmgFwe4zt6PRQOVBEe05iTxP rlDA==
X-Gm-Message-State: AOAM531Tn84iUWB/9+9y3poFPXoG/Wi+JrFgqmKGc+85raXaQ00ib/Ao tALZFK2Cj7bZ077qxtAVjMa57PVc
X-Google-Smtp-Source: ABdhPJy+tAlSSCuS9ab5CiFSR/RXsG2gG4EjkoEFmAPo2S4JWNcCiqZidc4zj2rX957c7OTfKZ9/Kw==
X-Received: by 2002:a05:6830:1d8c:: with SMTP id y12mr53841oti.162.1593125623074;  Thu, 25 Jun 2020 15:53:43 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id 41sm1757239otg.80.2020.06.25.15.53.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 15:53:42 -0700 (PDT)
To: Scott Kitterman 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com>
Date: Thu, 25 Jun 2020 15:53:40 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0940B242-F49E-4297-868E-9B6598978967@kitterman.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:53:45 -0000

On 6/25/2020 3:33 PM, Scott Kitterman wrote:
> True, but I think it's on topic for a DMARC replacement working group, not this one.

You have just crossed over from expressing a personal interpretation of 
the charter, to declaring your interpretation as correct, in spite of 
having a competing interpretation also having been expressed.

Please don't do that.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 15:59:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1143A081D for ; Thu, 25 Jun 2020 15:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nOtSdWa1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=V6Vk1/CJ
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 QGqbwuKIp92O for ; Thu, 25 Jun 2020 15:58:56 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5443A0CCC for ; Thu, 25 Jun 2020 15:58:56 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CA1E9F80263; Thu, 25 Jun 2020 18:58:55 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593125935; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=xg9dZnFtYpcdyKGJoUgyNjvwfZEm4DFnXGWK4j5WkXw=; b=nOtSdWa1v4wKPraeTXNj0nzmMyfu0RB2jlezyamtwjXdQCdJgTq4F/v5gakNGD0t0dmvV PmBdTbvZie4x9NkCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593125935; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=xg9dZnFtYpcdyKGJoUgyNjvwfZEm4DFnXGWK4j5WkXw=; b=V6Vk1/CJr7ZcH24QXYd+viZtPn/qNjO7AbP0yCsWJwXKKaSvxMu/WkoNFMLwbcycV4mbh oX6hDDcsSv7TVLD1M1SfkDXZnz4xJHmJKdHZZzh/fhiNj2lc9jVGtnpHxQjW6RsIInmBtfA DoEZDRljQCICLBD1xe/4Zj5Jt70V+MlHI3cYR+igLzLbapoxD5a+LXVW5upwZYWVcBA+2bT XzVu1EyDU9KsNxtwxmyhbkxjsipaPQwpJx5VpI9+q6902sn9vO4AsFkmh0AWzYOTVpEsQof QQ5eVnmwo5dTbQL13BuAnoRGEVGRjNrRTeO5pJooyLlA7iSWGrHGJCwtNiIA==
Received: from [10.149.227.216] (mobile-166-170-32-56.mycingular.net [166.170.32.56]) by interserver.kitterman.com (Postfix) with ESMTPSA id 70981F800DE; Thu, 25 Jun 2020 18:58:55 -0400 (EDT)
Date: Thu, 25 Jun 2020 22:58:52 +0000
In-Reply-To: <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com>
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman 
Message-ID: <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com>
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 22:59:00 -0000

On June 25, 2020 10:53:40 PM UTC, Dave Crocker  wrot=
e:
>On 6/25/2020 3:33 PM, Scott Kitterman wrote:
>> True, but I think it's on topic for a DMARC replacement working
>group, not this one=2E
>
>You have just crossed over from expressing a personal interpretation of
>
>the charter, to declaring your interpretation as correct, in spite of=20
>having a competing interpretation also having been expressed=2E
>
>Please don't do that=2E
>
>d/

Why would I be expressing an interpretation of the charter that I didn't t=
hink is correct? =20

Absent direction from the chairs, of course I'm going to operate on the ba=
sis of my interpretation (although I think it's less interpretation and mor=
e reading what's explicitly there, I'd imagine you would view it differentl=
y)=2E

Scott K


From nobody Thu Jun 25 16:05:40 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F763A1057 for ; Thu, 25 Jun 2020 16:04:47 -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, FREEMAIL_FROM=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=gmail.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 hmIXYqz278P8 for ; Thu, 25 Jun 2020 16:04:46 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 7D6163A1055 for ; Thu, 25 Jun 2020 16:04:46 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id a21so6468279oic.8 for ; Thu, 25 Jun 2020 16:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=0s4Sdd0bbOG2/WeKEZlSGGggosHfh/wxUw6otTgExQk=; b=HOAJCtd921c+YYF8f3s7ToX2z5evgIcXQGeQxirubRJGf+yL2fpd06plJmgox7pqS/ SC3Op2vm7qpy7KKAnEkxf26M2INLpgXaz2qaQyEb0eY0F3m4WqE7VpaC6cFGz4xhsbKG i6dKJ/7Gl/ECvkRiXe7Zqom05GuE40VrBNfxrFf6VSAshUTNB2Z1Je6NJSedX5/B5oZc 73KchQGtSc6oGu8AyVQpofn3Im0TEDRt4EDoZpacaUcQR0tHNqq96bcNpYqo/6sAPwd+ Eon9jOxpznmfiZmeLRAzy0P4Dw7gNqyvRYjfn+bjyf7ukaBJANr2HmOrFSEY5Brggbm1 /+LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0s4Sdd0bbOG2/WeKEZlSGGggosHfh/wxUw6otTgExQk=; b=LvhaNIb6/3b7uxc4mBNak1lwz0mcRjAobetm9xXf+UOPbH9xm8xWJ7oRBIDpsw/PWv ZjX1CSQsMrM9NUMtVl0z4/0TAe30RqbgVmzq5JXIWrBkeRQ5xifthAlsJ5vPHNZH4A0Q qgpaQckitw353N6iGBBjGfZyXc8965VCfezIdzGsuiWeTvrnhGscb0WNlFJ99jkxIqDr NVXx9xeM5vcKaDiBB73H8osSfYGNB+svfmouvpnG+fKXuPxN9roi5T74+j/4f3ve5Ck4 XEq35DWWoMUJB4X8aoUkvpvnOAl14IbIgRj9QjfLACDeX4J43+cIPHL15l5dieJl5vH2 KxrQ==
X-Gm-Message-State: AOAM532/rNLkxuwSgh3SZLhKmTNZ+FYSVQ/jkcIKzHcF672xK9GhEi1R hGGi1aYDzXQHhG6iOOBwpyaOLyIo
X-Google-Smtp-Source: ABdhPJx5EFFodAFpg8B7pgzBkanzSCy8h3EdYq8EDbCuUtJ/CG40hUrwnF7jz6Jaz4DI8akieQFTmQ==
X-Received: by 2002:aca:b805:: with SMTP id i5mr309437oif.8.1593126285625; Thu, 25 Jun 2020 16:04:45 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:844f:9122:30b3:6503? ([2600:1700:a3a0:4c80:844f:9122:30b3:6503]) by smtp.gmail.com with ESMTPSA id p73sm806226oop.36.2020.06.25.16.04.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 16:04:45 -0700 (PDT)
To: Scott Kitterman 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com> <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com>
Cc: dmarc@ietf.org
From: Dave Crocker 
Message-ID: <604187a6-766d-053c-d1e0-165652e0d396@gmail.com>
Date: Thu, 25 Jun 2020 16:04:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 23:04:48 -0000

On 6/25/2020 3:58 PM, Scott Kitterman wrote:
> Why would I be expressing an interpretation of the charter that I didn't think is correct?

That's not what i said.

I mean that you are asserting a requirement as if it were established, 
based on your interpretation.  the requirement is not established and, 
of course, i believe it won't be.


> Absent direction from the chairs, of course I'm going to operate on the basis of my interpretation (although I think it's less interpretation and more reading what's explicitly there, I'd imagine you would view it differently).

The point is needing to be more tentative.  Opinions are of course 
fine.  The state of being an opinion is transitive.  It flows onto any 
assertions made based on it.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Jun 25 16:22:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD23A1074 for ; Thu, 25 Jun 2020 16:22:39 -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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=xxYdE7kb; dkim=pass (2048-bit key) header.d=kitterman.com header.b=KQEXMcjs
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 OsIiZ71dvHfk for ; Thu, 25 Jun 2020 16:22:38 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871183A1072 for ; Thu, 25 Jun 2020 16:22:38 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 85CC4F80263; Thu, 25 Jun 2020 19:22:37 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593127357; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=dm0oYZkgD4TSCJfqMUm5lsfINyDn1CAUBTsnJJBj0e8=; b=xxYdE7kbeJrW/Ueh0LPQ/sB2oUsZ9f/7a+OdahKB+fe39CiPwIzbJ3lk9AaAgRYD53eLl fAJ9xxik3seo3FvDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593127357; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=dm0oYZkgD4TSCJfqMUm5lsfINyDn1CAUBTsnJJBj0e8=; b=KQEXMcjsZ6eN7zMDl9Jnah19JkkDyOZz28OdbdrRPOam7xcoykXYRbyGGPM+8YNb8sVYY lQrk1elc5zbtt7Tpitj/Lz8MyoHKN1eNi1TLJuRyRzFfX/qP8aa2OAgCPnVbTbrf3XoFeto SB0cSxFwrCwa+JWnWw1Y03u4M+kSVbT01IHEWyy2cmvex3x4tJATUOPxAhpgTnbF8/nxA80 Hzq8Gl4PnNYMRUUM3H9cjOpWw75rzyKO21UKAFfbTeMi1uOXl3vjFxJCv67DFVDkF8WS4tq LLDaT5W2FyKr6HXXNfFKdSCN6nmh1GXweS490Y5aBz26Plqv/BfxtE4Xi7DA==
Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 4CF6EF800DE; Thu, 25 Jun 2020 19:22:37 -0400 (EDT)
Date: Thu, 25 Jun 2020 23:22:35 +0000
In-Reply-To: <604187a6-766d-053c-d1e0-165652e0d396@gmail.com>
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com> <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com> <604187a6-766d-053c-d1e0-165652e0d396@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman 
Message-ID: 
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 23:22:40 -0000

On June 25, 2020 11:04:43 PM UTC, Dave Crocker  wrot=
e:
>On 6/25/2020 3:58 PM, Scott Kitterman wrote:
>> Why would I be expressing an interpretation of the charter that I
>didn't think is correct?
>
>That's not what i said=2E
>
>I mean that you are asserting a requirement as if it were established,=20
>based on your interpretation=2E=C2=A0 the requirement is not established =
and,=20
>of course, i believe it won't be=2E
>
>
>> Absent direction from the chairs, of course I'm going to operate on
>the basis of my interpretation (although I think it's less
>interpretation and more reading what's explicitly there, I'd imagine
>you would view it differently)=2E
>
>The point is needing to be more tentative=2E=C2=A0 Opinions are of course=
=20
>fine=2E=C2=A0 The state of being an opinion is transitive=2E=C2=A0 It flo=
ws onto any=20
>assertions made based on it=2E

I think the bar to convince me that it's okay to throw away aligning to 53=
22=2EFrom is in scope for the working group is really high when the charter=
 defines DMARC as "Domain-based Message Authentication, Reporting & Conform=
ance (DMARC) uses existing mail authentication technologies (SPF and DKIM) =
to extend validation to the RFC5322=2EFrom field"=2E

So far, no one has presented any arguments to suggest an alternative view =
is correct=2E  I think what I think and I don't feel any need to be disinge=
nuous about it=2E

That doesn't mean I won't change my mind later if someone makes a convinci=
ng argument that an alternative view is correct=2E  Don't confuse having a =
firm opinion with being unwilling to consider alternative views=2E

Scott K


From nobody Thu Jun 25 17:06:00 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E293A106E for ; Thu, 25 Jun 2020 17:05:58 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zAsae_K-Zps2 for ; Thu, 25 Jun 2020 17:05:56 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 7A49D3A1078 for ; Thu, 25 Jun 2020 17:05:56 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id q15so7194063wmj.2 for ; Thu, 25 Jun 2020 17:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=f3lt+w39ktcXY9piduUwiDpCxNvoYWU80GslBt/AruQ=; b=RsNRCkwxq9wTeLIu/cqHJK5ykC0UT+CZhWtumrSF+e6fHKwgkCZBfZTc6Evd6pW+Oh f4AI59gcpi6BtNt48MexKui9jVU2ERS81xc483RSz6WRHNjyfIGt6s5NzxbJg862U4gE 9zPOjJjzTbfeahjbhmPYGXfmls7/nuHBcTVny7yTCBe4VEq9mwOwpjGkRjJbI8hS7joA TxAFlRP/XEqxtplyuAsxJtDhSvXglCn4rht9Sviinv6wULXEEw/i1HFkUJPjbKboQEk8 Ij8HKsYvMn8abLn73zTB9ivTMMNOXV76vfLwnhrXJfUrQDu2rFeYiWe4qjtrMP4tn5U+ QyXQ==
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=f3lt+w39ktcXY9piduUwiDpCxNvoYWU80GslBt/AruQ=; b=Cisu4wHOu/ottKNK7mI1ZS82NRD+hHXkdgatJEOw9SeBsBHErrZzFEkIGi8Eo5JwLR zYD41f7TB8Y9lyH74r9BlkKoNyCpo98SJdoP9IgOUdI3SzOcWaHvhTbJpxDvjb6NIYFR hrHQEqChga9TmHX0DLgnDLEro4jnyVzsosL69fZpxu23n2wmg2DQBB7c4M19GyVwo6XA woraDOVGjqqs/TgYTUItlrWxwD9LlgtCLA84mSdoToKokQHJpaV/oLnNdf0yo/ETf6G5 YQNOfaLCWl8IY+7vVI5Omw7MPJLj196YKNsTG9EidyCj2x8W/cpzRCwsU5RvPOu/0IRZ pesA==
X-Gm-Message-State: AOAM531Y5gbFJaroSk5MNtfh6JkzpkC7L0ZGHF6g5MKqab5WtyQ4PTWI oKsB1Hf6Y/H7Juz6HG2zUe6TPj8gA49JefPPEkEXoJNX
X-Google-Smtp-Source: ABdhPJzzyX4xDo4gFUrlMHEnCD8VlXTohKLi8ASAoY5m2Y/27s+MafCjoax8hr6ahLZRnyzhTk1u0h5z9oasXkqAjeg=
X-Received: by 2002:a1c:6408:: with SMTP id y8mr498516wmb.122.1593129954676; Thu, 25 Jun 2020 17:05:54 -0700 (PDT)
MIME-Version: 1.0
From: Dotzero 
Date: Thu, 25 Jun 2020 20:05:43 -0400
Message-ID: 
To: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000007956405a8f17994"
Archived-At: 
Subject: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 00:05:59 -0000

--00000000000007956405a8f17994
Content-Type: text/plain; charset="UTF-8"

After reading Dave Crocker's proposal, which I consider fundamentally
broken, I've given some thought to the issues.

1) Many MLM's do not want to change their current practices yet suffer
consequences from DMARC implementations at their subscribers domains.

2) There is a mismatch between the granularity (domain) which DMARC
operates at and individual subscriptions to mailing lists.

3) It would be useful for domains with individual users to show
authorization for messages by individuals that are likely to flow through
intermediaries such as MLMs.

Without formulating all the details, what I propose for the groups
consideration is a new field which I will call "Intermediary" as a stalking
horse. This field would be DKIM signed separately from the current DKIM
signing. This would ensure more robust survivability in passing through the
intermediary. There would likely need to be some additional elements signed
to mitigate against replay attacks using the second signature.

Variations on this approach might include:

A) Generic signing of "Intermediary". This seems as risky or perhaps more
risky to me as signing using the "*l*=" tag. Presumably generic signing
should not be used in conjunction with reject.

B) Specifying the specific Intermediary in the Intermediary Field. This
would indicate that the users domain recognizes that the user uses the
intermediary and by policy exempts this use even though it breaks both DKIM
and SPF validation. The receiving domain would need to recognize some
potential risk of malicious modifications or additions to the message.

Benefits of this proposal include:

1) This is an addition to DMARC that does not change the underlying
functionality of DMARC for those domains not interested in participating in
this extended functionality.

2) It resolves the mismatch in granularity between the domain level and the
user level as far as authentication/authorization.

3) It would require no effort on the part of known intermediaries other
than not breaking the second signature.

Issues:

1) It increases administrative complexity for the originating domain in
that it requires the domain to either track user:intermediary relationships
or enable users to self approve such relationships ad hoc.

2) A more detailed specification would need to be fleshed out to determine
whether this approach would survive likely modifications by known
intermediaries.

3) This does not address the issue of modifications by intermediaries not
identified in advance and authorized.

Feel free to start pulling this apart. This is a proposal for an approach,
not a complete proposed solution.

Michael Hammer

--00000000000007956405a8f17994
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    After reading Dave =
Crocker's proposal, which I consider fundamentally broken, I've giv=
en some thought to the issues.=C2=A0

    1) Many MLM&#=
39;s do not want to change their current practices yet suffer consequences =
from DMARC implementations at their subscribers domains.

    2) There is a mismatch between the granularity (domain) which DMARC =
operates at and individual subscriptions to mailing lists.

    3) It would be useful for domains with individual users to show au=
thorization for messages by individuals that are likely to flow through int=
ermediaries such as MLMs.

    Without formulating all =
the details, what I propose for the groups consideration is a new field whi=
ch I will call "Intermediary" as a stalking horse. This field wou=
ld be DKIM signed separately from the current DKIM signing. This would ensu=
re more robust survivability in passing through the intermediary. There wou=
ld likely need to be some additional elements signed to mitigate against re=
play attacks using the second signature.

    Variation=
s on this approach might include:

    A) Generic signi=
ng of=C2=A0"Intermediary". This seems as risky or perhaps more ri=
sky to me as signing using=C2=A0the &=
quot;l=3D" tag. Presumably generic signing should not b=
e used in conjunction with reject.

    =
B) Specifying the specific Intermediary in the Intermediary Field. This wou=
ld indicate that the users domain recognizes that the user uses the interme=
diary and by policy exempts this use even though it breaks both DKIM and SP=
F validation. The receiving domain would need to recognize some potential r=
isk of malicious modifications or additions to the message.

    Benefits of this proposal include:
    <=
div>
    1) This is an addition to DMARC that does not ch=
ange the underlying functionality of DMARC for those domains not interested=
 in participating in this extended functionality.=C2=A0

    2) It resolves the mismatch in granularity between the=
 domain level and the user level as far as authentication/authorization.

    =
3) It would require no effort on the =
part of known intermediaries other than not breaking the second signature.<=
/span>

    Issues:

    1) It increases administrative complexity for the originating =
domain in that it requires the domain to either track user:intermediary rel=
ationships or enable users to self approve such relationships ad hoc.

    2) A more detailed specification would n=
eed to be fleshed out to determine whether this approach would survive like=
ly modifications by known intermediaries.

    3) This does not address the issue of modifications by intermediarie=
s not identified in advance and authorized.

    Feel free to start pulling this apart. This is a proposal for an a=
pproach, not a complete proposed solution.

    Michael Hammer


    <=
/div>
    

--00000000000007956405a8f17994--


From nobody Thu Jun 25 19:16:04 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A756F3A1044 for ; Thu, 25 Jun 2020 19:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=D2Jp/a4t; dkim=pass (2048-bit key) header.d=kitterman.com header.b=fOkRbN+4
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 VjgDzXv3yFNo for ; Thu, 25 Jun 2020 19:15:57 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC85A3A090F for ; Thu, 25 Jun 2020 19:15:57 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 63543F80263 for ; Thu, 25 Jun 2020 22:15:56 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1593137756; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/ViyEXCBPg1i6y3MjeI/dIxb6fMDrg7314yGHXyXet0=; b=D2Jp/a4ttTa7h3uP522C3B1fAT45Kn4Zdtin/kcJ71J/dAVwEgbakUYC9wPam05iiLr5W mn4SIuME7eS4YsKAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1593137756; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/ViyEXCBPg1i6y3MjeI/dIxb6fMDrg7314yGHXyXet0=; b=fOkRbN+4G2UwHkvpF+mvB7/FUV+QRNwJxY74M+fDn8O5+5JI4r4G67uOWh37dXIIlPq5T 1yjyyJX22kr3+dJrp78HpCNWe5ma2Ner9NkHReQIS4MmTt64BHkW7BLL6gQDbhn+pzu1jwV hqFSYCGIhdfyraO7viAhIGnylwONAB1L6IUzPheKjeIvlP4K6gnQR8Qm0mQ2FE3WBFlH2Bv zQ3/Rmpcn1yXhZ4yWzIY2fsgA14Wv3KjRdnVt9k114kGFxXEKExPPJy0kKNN9CVjIWoMW3L bHKVuN7BU1aF7H8hewUYphM45bTCXAyLACz8bi/WT3avlMUlpcOvKJggsb2g==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 1CB9AF800DE for ; Thu, 25 Jun 2020 22:15:56 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Thu, 25 Jun 2020 22:15:55 -0400
Message-ID: <2942364.xn3RH8dgyc@zini-1880>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 02:16:00 -0000

On Thursday, June 25, 2020 8:05:43 PM EDT Dotzero wrote:
> After reading Dave Crocker's proposal, which I consider fundamentally
> broken, I've given some thought to the issues.
> 
> 1) Many MLM's do not want to change their current practices yet suffer
> consequences from DMARC implementations at their subscribers domains.
> 
> 2) There is a mismatch between the granularity (domain) which DMARC
> operates at and individual subscriptions to mailing lists.
> 
> 3) It would be useful for domains with individual users to show
> authorization for messages by individuals that are likely to flow through
> intermediaries such as MLMs.
> 
> Without formulating all the details, what I propose for the groups
> consideration is a new field which I will call "Intermediary" as a stalking
> horse. This field would be DKIM signed separately from the current DKIM
> signing. This would ensure more robust survivability in passing through the
> intermediary. There would likely need to be some additional elements signed
> to mitigate against replay attacks using the second signature.
> 
> Variations on this approach might include:
> 
> A) Generic signing of "Intermediary". This seems as risky or perhaps more
> risky to me as signing using the "*l*=" tag. Presumably generic signing
> should not be used in conjunction with reject.
> 
> B) Specifying the specific Intermediary in the Intermediary Field. This
> would indicate that the users domain recognizes that the user uses the
> intermediary and by policy exempts this use even though it breaks both DKIM
> and SPF validation. The receiving domain would need to recognize some
> potential risk of malicious modifications or additions to the message.
> 
> Benefits of this proposal include:
> 
> 1) This is an addition to DMARC that does not change the underlying
> functionality of DMARC for those domains not interested in participating in
> this extended functionality.
> 
> 2) It resolves the mismatch in granularity between the domain level and the
> user level as far as authentication/authorization.
> 
> 3) It would require no effort on the part of known intermediaries other
> than not breaking the second signature.
> 
> Issues:
> 
> 1) It increases administrative complexity for the originating domain in
> that it requires the domain to either track user:intermediary relationships
> or enable users to self approve such relationships ad hoc.
> 
> 2) A more detailed specification would need to be fleshed out to determine
> whether this approach would survive likely modifications by known
> intermediaries.
> 
> 3) This does not address the issue of modifications by intermediaries not
> identified in advance and authorized.
> 
> Feel free to start pulling this apart. This is a proposal for an approach,
> not a complete proposed solution.
> 
> Michael Hammer

I think a good place to start is ATPS (RFC 6541).  At least at this level of 
detail it sounds similar to me.  I think it would be useful to know what you 
would do differently or alternately why you think it might catch on now when it 
didn't when it was developed.

Scott K




From nobody Thu Jun 25 19:37:14 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133163A10F7 for ; Thu, 25 Jun 2020 19:37:12 -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, FREEMAIL_FROM=0.001, 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=gmail.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 3zIjF2diQ4JD for ; Thu, 25 Jun 2020 19:37:10 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 108613A10F6 for ; Thu, 25 Jun 2020 19:37:09 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id q5so7957467wru.6 for ; Thu, 25 Jun 2020 19:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NIfzPgeIfDcOFTwfZ/Q06ZcJI+E+H7B4+LxR0ymNRqI=; b=Zu7O5HJNDgaY8edEY+iOTkbbRAXCbb/a4q4X0FQAYhDQjLjBFsvGS8C6qflDo+MTVN QOI7SCwEfwkGSUf/M1Bu2JT9lbghWif7/AgTdGibjDZM8YLyBtU3TxdgHw14JL1TWkbD 2FwVIkkWC8HNDRMO2xYSNyfOvKvYUyOzxvdxOB8TT+AvBPr8a5KUCLci+O5Pt3y1WlQ5 Bz7rF47cXE4gyETr5ygNmmCeQCv4AkUogrR9p2zt9MDEDSaXRBPEdBvLLdoPoWZHlSEI //V8/EAI09b7iZpl2RHzP6+rANw+EwpT/5tXCAbPdMrNpLvwn25SCelUWW+oA2RsBPef PWAg==
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=NIfzPgeIfDcOFTwfZ/Q06ZcJI+E+H7B4+LxR0ymNRqI=; b=eLGwhLawfab6ervbYrkASl3aBcC1Q/ar0q12BpvT1n4RxSl35Q0ykRogI7XQBMT89A G0hCVcV2onqJeX2DNmUh7e4fbnOnDEz77o7PlFl/vyZf/bkmcpZxdtWfuObgnr6RdTCo PzIORhKTtYLIKC8+ZQ1qWuFXHYmCt1r6uNE1vZ5Iq5RAW+/lGlu4M6cPPka/IlBcWcyD 8DbJnxixcvAWMwJGM0m6RIux0Oky/n7IX6a0WouwlRfXo9/1I/Cw3jCGfQVneQB+gbfD 5rdZcNrrTwyvz2ZtgJyKk5WkmksuyBCCtSQ37O7y4rkZqkqBfg/gOi24W1mcA2CjkQpH JGSQ==
X-Gm-Message-State: AOAM5307Cpn6Jzf6STg+qh27Ovpq7lwu+jZss40Mw/SaWH+1ZN9560u7 VqAuv6VYl2N1k8DbL2g3ZdgSzXIQ/Fy3aJUPvfcJfg==
X-Google-Smtp-Source: ABdhPJxTaxe9VyFl7dCdIhfd6hKJx3tBPGnasNd7DMkr3z/zN+fe0aR1YzOLIAVrgQR/exNLkoxR4Sctx3QAIHriIDc=
X-Received: by 2002:adf:fd8e:: with SMTP id d14mr1272913wrr.202.1593139028193;  Thu, 25 Jun 2020 19:37:08 -0700 (PDT)
MIME-Version: 1.0
References:  <2942364.xn3RH8dgyc@zini-1880>
In-Reply-To: <2942364.xn3RH8dgyc@zini-1880>
From: Dotzero 
Date: Thu, 25 Jun 2020 22:36:56 -0400
Message-ID: 
To: Scott Kitterman 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="000000000000da76e905a8f39585"
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 02:37:12 -0000

--000000000000da76e905a8f39585
Content-Type: text/plain; charset="UTF-8"

ATPS requires signatures by multiple parties. What I'm proposing only
requires a 2nd signature from the originating domain. This significantly
simplifies the requirements for the specification as well as ongoing
operational requirements. MLMS or other known intermediaries would have to
do nothing or very little to make sure they don't break the 2nd signature.

As to why there is likely to be adoption now vs ATPS, ATPS was published in
2012 when there was very little adoption of DMARC, specifically by domains
with end users likely to  send mail through intermediaries. The MLM problem
became significantly greater when domains such as AOL and Yahoo! deployed
DMARC with p=reject wreaking havoc among parts of their user base as well
as with MLMs.

I would suggest that the approach I suggest is simpler to implement and
requires less effort than ATPS or Dave's proposed changes to DMARC.

Michael Hammer


On Thu, Jun 25, 2020 at 10:16 PM Scott Kitterman 
wrote:

> On Thursday, June 25, 2020 8:05:43 PM EDT Dotzero wrote:
> > After reading Dave Crocker's proposal, which I consider fundamentally
> > broken, I've given some thought to the issues.
> >
> > 1) Many MLM's do not want to change their current practices yet suffer
> > consequences from DMARC implementations at their subscribers domains.
> >
> > 2) There is a mismatch between the granularity (domain) which DMARC
> > operates at and individual subscriptions to mailing lists.
> >
> > 3) It would be useful for domains with individual users to show
> > authorization for messages by individuals that are likely to flow through
> > intermediaries such as MLMs.
> >
> > Without formulating all the details, what I propose for the groups
> > consideration is a new field which I will call "Intermediary" as a
> stalking
> > horse. This field would be DKIM signed separately from the current DKIM
> > signing. This would ensure more robust survivability in passing through
> the
> > intermediary. There would likely need to be some additional elements
> signed
> > to mitigate against replay attacks using the second signature.
> >
> > Variations on this approach might include:
> >
> > A) Generic signing of "Intermediary". This seems as risky or perhaps more
> > risky to me as signing using the "*l*=" tag. Presumably generic signing
> > should not be used in conjunction with reject.
> >
> > B) Specifying the specific Intermediary in the Intermediary Field. This
> > would indicate that the users domain recognizes that the user uses the
> > intermediary and by policy exempts this use even though it breaks both
> DKIM
> > and SPF validation. The receiving domain would need to recognize some
> > potential risk of malicious modifications or additions to the message.
> >
> > Benefits of this proposal include:
> >
> > 1) This is an addition to DMARC that does not change the underlying
> > functionality of DMARC for those domains not interested in participating
> in
> > this extended functionality.
> >
> > 2) It resolves the mismatch in granularity between the domain level and
> the
> > user level as far as authentication/authorization.
> >
> > 3) It would require no effort on the part of known intermediaries other
> > than not breaking the second signature.
> >
> > Issues:
> >
> > 1) It increases administrative complexity for the originating domain in
> > that it requires the domain to either track user:intermediary
> relationships
> > or enable users to self approve such relationships ad hoc.
> >
> > 2) A more detailed specification would need to be fleshed out to
> determine
> > whether this approach would survive likely modifications by known
> > intermediaries.
> >
> > 3) This does not address the issue of modifications by intermediaries not
> > identified in advance and authorized.
> >
> > Feel free to start pulling this apart. This is a proposal for an
> approach,
> > not a complete proposed solution.
> >
> > Michael Hammer
>
> I think a good place to start is ATPS (RFC 6541).  At least at this level
> of
> detail it sounds similar to me.  I think it would be useful to know what
> you
> would do differently or alternately why you think it might catch on now
> when it
> didn't when it was developed.
>
> Scott K
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

--000000000000da76e905a8f39585
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    ATPS requires signatures by multiple parties. What I&=
#39;m proposing only requires a 2nd signature from the originating domain. =
This significantly simplifies the requirements for the specification as wel=
l as ongoing operational requirements. MLMS or other known intermediaries w=
ould have to do nothing or very little to make sure they don't break th=
e 2nd signature.

    As to why there is likely to be a=
doption now vs ATPS, ATPS was published in 2012 when there was very little =
adoption of DMARC, specifically by domains with end users likely to=C2=A0 s=
end mail through intermediaries. The MLM problem became significantly great=
er when domains such as AOL and Yahoo! deployed DMARC with p=3Dreject wreak=
ing havoc among parts of their user base as well as with MLMs.
    I would suggest that the approach I suggest is simpler to impl=
ement and requires less effort than ATPS or Dave's proposed changes to =
DMARC.

    Michael Hammer


    On=
 Thu, Jun 25, 2020 at 10:16 PM Scott Kitterman <sklist@kitterman.com> wrote:
    On Thursday, June 25, 2020 8:05:43 PM EDT Dotzero wrote:
    
> After reading Dave Crocker's proposal, which I consider fundamenta=
lly
    
> broken, I've given some thought to the issues.
    
> 
    
> 1) Many MLM's do not want to change their current practices yet su=
ffer
    
> consequences from DMARC implementations at their subscribers domains.<=
br>
> 
    
> 2) There is a mismatch between the granularity (domain) which DMARC
> operates at and individual subscriptions to mailing lists.
    
> 
    
> 3) It would be useful for domains with individual users to show
    
> authorization for messages by individuals that are likely to flow thro=
ugh
    
> intermediaries such as MLMs.
    
> 
    
> Without formulating all the details, what I propose for the groups
    
> consideration is a new field which I will call "Intermediary"=
; as a stalking
    
> horse. This field would be DKIM signed separately from the current DKI=
M
    
> signing. This would ensure more robust survivability in passing throug=
h the
    
> intermediary. There would likely need to be some additional elements s=
igned
    
> to mitigate against replay attacks using the second signature.
    
> 
    
> Variations on this approach might include:
    
> 
    
> A) Generic signing of "Intermediary". This seems as risky or=
 perhaps more
    
> risky to me as signing using the "*l*=3D" tag. Presumably ge=
neric signing
    
> should not be used in conjunction with reject.
    
> 
    
> B) Specifying the specific Intermediary in the Intermediary Field. Thi=
s
    
> would indicate that the users domain recognizes that the user uses the=

    
> intermediary and by policy exempts this use even though it breaks both=
 DKIM
    
> and SPF validation. The receiving domain would need to recognize some<=
br>
> potential risk of malicious modifications or additions to the message.=

    
> 
    
> Benefits of this proposal include:
    
> 
    
> 1) This is an addition to DMARC that does not change the underlying
> functionality of DMARC for those domains not interested in participati=
ng in
    
> this extended functionality.
    
> 
    
> 2) It resolves the mismatch in granularity between the domain level an=
d the
    
> user level as far as authentication/authorization.
    
> 
    
> 3) It would require no effort on the part of known intermediaries othe=
r
    
> than not breaking the second signature.
    
> 
    
> Issues:
    
> 
    
> 1) It increases administrative complexity for the originating domain i=
n
    
> that it requires the domain to either track user:intermediary relation=
ships
    
> or enable users to self approve such relationships ad hoc.
    
> 
    
> 2) A more detailed specification would need to be fleshed out to deter=
mine
    
> whether this approach would survive likely modifications by known
    
> intermediaries.
    
> 
    
> 3) This does not address the issue of modifications by intermediaries =
not
    
> identified in advance and authorized.
    
> 
    
> Feel free to start pulling this apart. This is a proposal for an appro=
ach,
    
> not a complete proposed solution.
    
> 
    
> Michael Hammer
    

    
I think a good place to start is ATPS (RFC 6541).=C2=A0 At least at this le=
vel of 
    
detail it sounds similar to me.=C2=A0 I think it would be useful to know wh=
at you 
    
would do differently or alternately why you think it might catch on now whe=
n it 
    
didn't when it was developed.
    

    
Scott K
    

    

    

    
_______________________________________________
    
dmarc mailing list
    
dmarc@ietf.org
    
https://www.ietf.org/mailman/listinfo/dmarc
    

    

--000000000000da76e905a8f39585--


From nobody Thu Jun 25 20:18:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C003A10F6 for ; Thu, 25 Jun 2020 20:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=KyCbQm1J; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=dJ5QFXAK
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 x3NSJdp9e2oB for ; Thu, 25 Jun 2020 20:18:21 -0700 (PDT)
Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (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 904683A10A0 for ; Thu, 25 Jun 2020 20:18:21 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4381; t=1593141492; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VayJPYC0DPwV6jpY68uRpPjpzdU=; b=KyCbQm1JzS8E3YVWQ5cGxL/4Au4+1gCo9PK/aN4yNHWuGRNfZB5idh7hmxASgA R/fMxOEApu1ZsSSHBL46TIA94tKoFHAFDyGbcS7h4bFSBcJGgE00YaVXMdRnVp2m F9kZN1uO+Dgj6P6a2dozMfbIW0NxmOPCXjkFvK0zB1HFg=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 25 Jun 2020 23:18:12 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3868783951.1.5636; Thu, 25 Jun 2020 23:18:11 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4381; t=1593141432; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=z9TWlpU SGVStREE4jPabPFWzeskoJeVF+pVxq3JNLYo=; b=dJ5QFXAKe6cCWeAKQkPeGj8 QYtiqp7HDz0YSNTgA3eL+TPmfJp/Yw0foUgNibQZXnm1zeS4aDlFwJ8gptrcO7dg CVgoL3LYBQYaYO6GxRc+11n47+IIrmFFMRxH/7YX5wANMgAAY2P3GnqmueVF47/p 9vPuz6fyY7EZt640kCvc=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 25 Jun 2020 23:17:12 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 580160641.1.53068; Thu, 25 Jun 2020 23:17:11 -0400
Message-ID: <5EF568F5.1050200@isdg.net>
Date: Thu, 25 Jun 2020 23:18:13 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com> <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com> <604187a6-766d-053c-d1e0-165652e0d396@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dmarc-ietf] What if... Sender is the "Purported Responsible Address " (PRA)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 03:18:25 -0000

The "Sender" vs "From"  discussion reminds me of SenderID and its 
companion RFC4407 protocol:

	Purported Responsible Address (PRA)
	https://tools.ietf.org/html/rfc4407

"This document defines a new identity associated with an e-mail 
message, called the Purported Responsible Address (PRA), which is 
determined by inspecting the header of the message. The PRA is 
designed to be the entity that (according to the header) most recently 
caused the message to be delivered."

Dave's proposal seems to suggest 5322.Sender would be the PRA of 
interest and serve more useful than 5322.From for the purposes of 
performing DKIM Policy lookups. If the 5322.Sender is missing, then 
for backward compatibility, the fallback is 5322.From.

I can see  engineering power if we can leverage the work already done 
in this regard. Dave's refocus with Sender can be validated with the 
PRA work.  It will also offer a great benefit with another 
SenderID/PRA companion RFC4405 SUBMITTER protocol.

     SMTP Service Extension for Indicating the Responsible
     Submitter of an E-Mail Message
     https://tools.ietf.org/html/rfc4407

Designed for SenderID to be processed at SMTP (without needing the 
payload) by passing the PRA to the SMTP client MAIL FROM command using 
the SUBMITTER keyword:

    C: MAIL FROM: SUBMITTER={PRA}

The good news, there is running code using the PRA/SUBMITTER Protocol 
and with 13+ years of empirical data, it showed:

    PRA is 5322.From for direct mail
    PRA is 5322.Sender for indirect mail.

I think Dave's proposal should get ample review.

However, the DKIM age-old problem still remains; how does the author 
domain authorize all this?  How does the author domain authorize the 
PRA? In addition, what is 5322.Sender's relationship with the DKIM 
signature signer domain?  Is there some alignment questions?

There would now four (4) identities in the DMARC process model;

5321.MAIL FROM: Reverse path domain
5322.From: domain (the first one)
5322.Sender: domain
5322.DKIM-Signature Signer domain (d=)

Actually 5 if we want to throw the client domain name (EHLO/HELO) into 
the pot.

While we can use the PRA for some "lookup," do we still need to tie it 
or bind it with the 5322.From?"

There is the ATPS, TPA, the ingress conditional that can use to make 
the bind which currently binds the signer domain with the author domain.

So those protocols will need to be updated as well.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

On 6/25/2020 7:22 PM, Scott Kitterman wrote:
>
>
> On June 25, 2020 11:04:43 PM UTC, Dave Crocker  wrote:
>> On 6/25/2020 3:58 PM, Scott Kitterman wrote:
>>> Why would I be expressing an interpretation of the charter that I
>> didn't think is correct?
>>
>> That's not what i said.
>>
>> I mean that you are asserting a requirement as if it were established,
>> based on your interpretation.  the requirement is not established and,
>> of course, i believe it won't be.
>>
>>
>>> Absent direction from the chairs, of course I'm going to operate on
>> the basis of my interpretation (although I think it's less
>> interpretation and more reading what's explicitly there, I'd imagine
>> you would view it differently).
>>
>> The point is needing to be more tentative.  Opinions are of course
>> fine.  The state of being an opinion is transitive.  It flows onto any
>> assertions made based on it.
>
> I think the bar to convince me that it's okay to throw away aligning to 5322.From is in scope for the working group is really high when the charter defines DMARC as "Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field".
>
> So far, no one has presented any arguments to suggest an alternative view is correct.  I think what I think and I don't feel any need to be disingenuous about it.
>
> That doesn't mean I won't change my mind later if someone makes a convincing argument that an alternative view is correct.  Don't confuse having a firm opinion with being unwilling to consider alternative views.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>




From nobody Thu Jun 25 20:20:33 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1D3A10D2 for ; Thu, 25 Jun 2020 20:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Pda/0NH7; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZpR31rP+
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 fRQ__Za0ESxE for ; Thu, 25 Jun 2020 20:20:30 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 BD0BE3A10B5 for ; Thu, 25 Jun 2020 20:20:29 -0700 (PDT)
Received: (qmail 33329 invoked from network); 26 Jun 2020 03:20:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=822e.5ef5697c.k2006; bh=9817VG6NuiUMdOzsZAReeHgFmESvjuG+Mn6gY7rcstQ=; b=Pda/0NH7G/ZRjuRvKaeCjCN6iSxHmERYDvzJkI+4nV+crnLGCdQwUGT0+4XCrXidhzD307Mab8nUqFzfTA/K+Q0C6CdcJTD4iFURvjNvIauhBi7PFpecE13ZeWJQ+fLz1aPCP22cwYqkpKz7RnogJBNOol/6llWD8MpowKNqZgcarYQ/EcTo1E1xbVw8bQBtylQmdyr54bwFj+wj09Y2jRO4TnjwHeR1zprQkXZHnwAUKh56ANnYbDl1AogDtfpy
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=822e.5ef5697c.k2006; bh=9817VG6NuiUMdOzsZAReeHgFmESvjuG+Mn6gY7rcstQ=; b=ZpR31rP+NdEGyznqYAumswcU2wpDYbKOtwEh9PAwuKasvfH2gRUtGy7pH9w+a9dH06n0eF2tpcbYEpbCRxIXN4mHGyTbZCy6FQ6oWY4zSpu995UUmbZ09ClO+060tlO3E7Wgqs4xgjduqleBr3yPsIbqt8l/uUvvFCg0b1WlC7DmgZkoiTZA829v4UrgFSO9trfX0tk4uL6K0hVxTKjVG8kAHgUpj2xFYfNsLbITuxuPlXsViEQoZP5Ly3HhwYzr
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 Jun 2020 03:20:27 -0000
Received: by ary.qy (Postfix, from userid 501) id B7EFA1BB563D; Thu, 25 Jun 2020 23:20:27 -0400 (EDT)
Date: 25 Jun 2020 23:20:27 -0400
Message-Id: <20200626032027.B7EFA1BB563D@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: dotzero@gmail.com
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 03:20:32 -0000

In article  you write:
>B) Specifying the specific Intermediary in the Intermediary Field. This
>would indicate that the users domain recognizes that the user uses the
>intermediary and by policy exempts this use even though it breaks both DKIM
>and SPF validation. The receiving domain would need to recognize some
>potential risk of malicious modifications or additions to the message.

Sounds like what I proposed several years ago:

https://tools.ietf.org/html/draft-levine-dkim-conditional-03

R's,
John
-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Fri Jun 26 01:20:19 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86B93A11EA for ; Fri, 26 Jun 2020 01:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk
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 XmybZ4ABBsLB for ; Fri, 26 Jun 2020 01:20:16 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100102.outbound.protection.outlook.com [40.107.10.102]) (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 F081D3A11E5 for ; Fri, 26 Jun 2020 01:20:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CGatO2C6FF6incQVn+14d+XSJzeO4WTFMt3blCC/6qVv4fTOKKT/v0qg7me1Pei2fKi1zmjg47SeAQ0jR1EHGJPtFHDoKCVCpz7sBorxx01NJCf+3rkBbwHYm8FMWSOd0zg/wYQsPrSBbXZVpRmtwuK0upBFlik/9Qf6i+ssz8lLinPsci/pKF8hkaHLm5R/ckQCubd0/VVLXVYnyHf+EdDOxQVtsbhxJvPaKJcV6scgCJ1PEhkRt0ZW65eVecy139tt8Wyx/ga7gcIuWCE/fJdliXMNFTR10amJp13z544AvG1MAl0Ug7ghe7CRvLIFAWfhDLWVzRE8UaC2bT/+WA==
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=lj7D6NsMGZ2Qp7R07emyTG+VVyQ7yjZjqZocZLZUD28=; b=IUdYHoGW8zTcOr/lXkEPO2xYkDTwqhH+IAaWLHOwH6bSsYHAZGOsmeriLQ7EssFaunsMMYs7Nqx3lVLuAgP5Wg/B4CsH+Ai6t5TX+LTmU881hYdyU0dFM6dFIMOpNNrjBWtbUXh06iULti+w0bNV+S0ik5AHRG+HuqNWDWYbC1/JJr438gO+Hmhb4VxOL4Zt6FBm48My1JBeCNMbvt2O2H+fcSQ+gAlzxPL1OzFy1kodelvdOcvMwOV0Qy5veaN+V2HUno8b2AklstmUs0Y/s+4ZatfR+M1ZgNc9lfhszZ5XgZApD84nHthIQbz43erzJHYuIlS9ydtUX4ksvdIYJA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lj7D6NsMGZ2Qp7R07emyTG+VVyQ7yjZjqZocZLZUD28=; b=E0tP/ummHjucpE1FvApKV0pCgfrBkz4oBtOU5L+MmbNcNZgH2BIR51ZJ6/O5unHmjyYbciERkmyMP+K5HbZVModk+qEWrk4uN4cchlLfIPnXfhDKlu4ZIB36iuwONECsd9ckL58izMsX8jhk81p3xOnO0jdlP9vieXFkAJMK0nFMEouD0yO2GMMHm2vYLKR2PaEbflTkrob2y3ao8jnjv+sIY3mBjVKyoBj1kOFgt67dTVBfsN6A+PcWqKKTQySpwGRTC55DHdL4J5HgddV7TrbGQntbBFq0m7dX5mtFslE21e9HSNTdTx1JpGxzyhEOW15TpvcLiWxR9j2+uvdqbw==
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c1::23) by LO3P123MB3290.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:b6::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Fri, 26 Jun 2020 08:20:04 +0000
Received: from LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117]) by LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM ([fe80::347c:1420:93a1:2117%7]) with mapi id 15.20.3131.021; Fri, 26 Jun 2020 08:20:04 +0000
From: David I 
To: John Levine , "dmarc@ietf.org" 
Thread-Topic: [dmarc-ietf] What if... Sender:
Thread-Index: AQHWSY8PY6KKw8Z6qkO2oAr/+0mQJajndpXAgABSVICAATGzgIAAu5yqgADXfMA=
Date: Fri, 26 Jun 2020 08:20:04 +0000
Message-ID: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com>  <7c1c68f8-c394-bea5-4f3d-1fd0e4e31565@gmail.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=none action=none header.from=ncsc.gov.uk;
x-originating-ip: [51.140.78.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5cf5212d-b9d9-4d50-c8ae-08d819a9bad4
x-ms-traffictypediagnostic: LO3P123MB3290:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0446F0FCE1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: W8b5UBAewI8MeKrdYkwUJArKYXV+BLOJ6p6fonKZ2LDivg6HxlG6bPrsBgnwE9gRD+M5QimnObUBZhR8f+t32k7MGT5RQ8xYIYOehGeVds9I9zefJe/x8iMin6uXrD994WGBbsfKkXXtfq+z7qG+ThRlQMicBDzpWZemvDv4hjquIedJ3SYwrnvzsLBVThxKc7QHwv52oerFb2H1UMu/5NSEFODLiQaZLqRaTgfp3dpCvhQatpOrjOBhlUZChtjJJPbFcC8Uq8dVAAhQTU7hzmtI3W/lHtGOtRxlJZaXcrac9SVp/Y9Ww+Fvcb80JMzFY5K9JKDInQA7UZYNx3fYLQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(346002)(366004)(136003)(39850400004)(396003)(9686003)(83380400001)(53546011)(45080400002)(55236004)(55016002)(8936002)(2906002)(316002)(71200400001)(6506007)(110136005)(52536014)(26005)(66556008)(7696005)(64756008)(33656002)(478600001)(66446008)(66476007)(86362001)(186003)(66946007)(76116006)(8676002)(5660300002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: ZpT/mK3ApY6j5AVHp4+IBYZ53QyBN4JQO4weQD8w1YDehQcABNuwgRY3Iv2oCdwf92Y16DS1BdsqQvRUd/oWXLhLZE0+B72PYjPvXjunGYNB7BMC54Gt1yCOOtg9LCfojNLU5WHyx/+6l1HgtxRDrMKrRpzQpbbuhklYil5827ntnpAVgHdspQhJN80P2KTUgTBnRL8cjTNIWa3Iu0YMiv1HVURcmqhQKnJzkfN5OrVPVBnS3YGBa/nJOh6tkDRNuD6osfJMqJux0EVjaLi0EYRUke0nzDVqwOt3T2tuIn6FeUUjIr7EC4oOARKw6r4/yZjnS3hYPuHNrEKpxEgfNptO4WHXWITz8Knn2yfvFJgp5X5KTg6V3kJfI5e/i9m+vp9BZyHwg0yC+/nwkHDIdzhUrLQWaybWFOqlEnePfGupmx15EKyquImhksvPNyHiVLiEvRiskeF4y/RLv2UPpBhBVTJE4eT+T/h71jsoIcs=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB2192.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cf5212d-b9d9-4d50-c8ae-08d819a9bad4
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2020 08:20:04.6970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7oYwQHW19oazbLgXfr0oYZXfa0X9UZaVOhmzUInjCzXc724h3ATON2oaB1ysQDuvXXFTQIYovhVdKXefwqG6lA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO3P123MB3290
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 08:20:18 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNl
c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTGV2aW5lDQo+IFNlbnQ6IDI1IEp1bmUgMjAy
MCAyMDoxMw0KPiBUbzogZG1hcmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkbWFyYy1pZXRm
XSBXaGF0IGlmLi4uIFNlbmRlcjoNCj4NCj4gSW4gYXJ0aWNsZQ0KPiA8TE8yUDEyM01CMjE5Mjcy
RkEwQkQ3RUVBOEQ3RUQ4QjcwQkU5MjBATE8yUDEyM01CMjE5Mi5HQlJQMTIzDQo+IC5QUk9ELk9V
VExPT0suQ09NPiwNCj4gRGF2aWQgSSAgPERhdmlkLklAbmNzYy5nb3YudWs+IHdyb3RlOg0KPiA+
V2l0aG91dCBmb3JjaW5nIGFsaWdubWVudCB0byAnRnJvbScsIGFuIGF0dGFja2VyIGNhbiBzZXQg
dGhlaXIgb3duDQo+ID4nU2VuZGVyJywgc2V0IGEgJ0Zyb20nIHRoZXkncmUgbm90IGVudGl0bGVk
IHRvIHVzZSB0aGF0J3Mgb2YgYSB0cnVzdGVkDQo+ID5jb250YWN0LCBhbmQgdGhlIERNQVJDIGFz
c29jaWF0ZWQgd2l0aCB0aGUgYWJ1c2VkIGRvbWFpbiBpbiB0aGUgJ0Zyb20nDQo+IGhhcyBubyBl
ZmZlY3QgYW5kIGNhbid0IGJlIHVzZWQgZm9yIGZpbHRlcmluZy4gU28gd2hpbGUgeW91IGNvdWxk
IHNvIGEgc2ltaWxhcg0KPiBmaWx0ZXIgb24gU2VuZGVyLCBpdCB3b3VsZG4ndCBiZSBhcyB1c2Vm
dWwsIGFuZCB3b3VsZCBwcm92aWRlIGxlc3Mgc2VjdXJpdHkNCj4gYmVuZWZpdC4NCj4NCj4gSXQg
c291bmRzIGxpa2UgeW91J3JlIG1ha2luZyB0aGUgY29tbW9uIG1pc3Rha2Ugb2YgY29uZnVzaW5n
ICJETUFSQw0KPiBhbGlnbmVkIiB3aXRoICJub3QgcGhpc2giIG9yICJub3Qgc3BhbSIuIFdoYXQg
d291bGQgeW91IGRvIHdpdGggYSBETUFSQw0KPiBhbGlnbmVkIG1lc3NhZ2Ugd2l0aCB0aGlzIEZy
b20gaGVhZGVyPw0KPg0KPiAgIEZyb206IFNlY3VyaXR5IEFsZXJ0IDxhbGVydEBwYXlwYWwtc2Vj
dXJpdHkuY29tPg0KPg0KPiAoVGhlIGNvcnJlY3QgYW5zd2VyIGlzIGJ1cnkgaXQgZGVlcCBpbiB0
aGUgcGhpc2ggdGFuay4gIENyb29rcyBjYW4gZG8gRE1BUkMNCj4gYWxpZ25tZW50LCB0b28uKQ0K
DQpJbmRlZWQsIEkgd291bGQgZG8gdGhhdC4gSSB3b3VsZCBhbHNvIGJlIGdyYXRlZnVsIGZvciB0
aGUgRE1BUkMgcG9saWN5IG9uIHBheXBhbC5jb20gZm9yIGZvcmNpbmcgdGhlIGF0dGFja2VyIHRv
IHVzZSBhIGNvdXNpbiBkb21haW4gdGhhdCBjYW4gYmUgZWFzaWx5IGRldGVjdGVkIGFzIG5vdCBs
ZWdpdGltYXRlLCByYWlzaW5nIHRoZSBjb3N0IHRvIHRoZSBhdHRhY2tlciwgYW5kIG1ha2UgdGhl
IGZpbHRlcmluZyBlYXNpZXIvbW9yZSBhY2N1cmF0ZS4NCg0KRGF2aWQNClRoaXMgaW5mb3JtYXRp
b24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdCAyMDAwIChG
T0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRlciBvdGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xh
dGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmllcyB0byBuY3NjaW5mb2xlZ0BuY3NjLmdvdi51ay4g
QWxsIG1hdGVyaWFsIGlzIFVLIENyb3duIENvcHlyaWdodCDCqQ0K


From nobody Fri Jun 26 01:22:48 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385873A0866 for ; Fri, 26 Jun 2020 01:22:47 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 LRPkSxtTQkZM for ; Fri, 26 Jun 2020 01:22:45 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 6056E3A085C for ; Fri, 26 Jun 2020 01:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593159763; bh=vcrCbPsAQxNrrf4dXpwpD8HsBaYsPJ+y+DLrVskznmY=; l=2410; h=To:References:From:Date:In-Reply-To; b=CKXChmGss+AvXOvgBIosiMeoOEbFGzL8/ABGUnxaE8UdIlf9dtIdPeBKc0YbbAPBL e1pujGqIofa+DXYe/HEwAG4LpVQtUiK5tdBWvOTm0lKc05T39BafTp/riWua1LO0LI lm9kwsBvpIZkxtazKURdrUB6X9mz85W8dUxz/47T9v0jTgxgo7/BFaM3S+7uh
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.89.134]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005EF5B052.00002FD2; Fri, 26 Jun 2020 10:22:42 +0200
To: dmarc@ietf.org
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3328e258-865a-4194-7d1f-bc8156d517b8@tana.it>  <081d18c8-5b35-ed7a-ef6b-e00891d4a1bb@tana.it> <4dc1ff2b-8936-2652-28a1-b93a6e0c4897@gmail.com>
From: Alessandro Vesely 
Message-ID: <104824bb-0bb9-e813-33ed-842387327e60@tana.it>
Date: Fri, 26 Jun 2020 10:22:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <4dc1ff2b-8936-2652-28a1-b93a6e0c4897@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 08:22:47 -0000

On Thu 25/Jun/2020 15:42:35 +0200 Dave Crocker wrote:
> On 6/25/2020 3:14 AM, Alessandro Vesely wrote:
>> Frequently, an inbound message has one or more valid DKIM signatures,
>> and/or passes SPF, yet it fails DMARC; that is, the authenticated
>> domain(s) are not aligned with From:.  Now it's obvious that any of
>> those authenticated domain(s) could as well have set a Sender:
>> pointing to itself.  Hence, the net effect is equivalent to dropping
>> the alignment requirement.
> 
> It's not.  Remember that the From: field is typically also the Sender:
> field.


In a DMARC/sender scenario, From: and Sender: are aligned in direct
mail flows only.  Any intermediate actor, one, say, which adds an ARC
set would also set Sender:.  Indeed, DMARC/sender would likely get the
same level of usability as ARC; that is, require an omniscient mailbox
provider in order to effectively filter based on it.


> Again:  The actual semantics of DMARC have to do with the
> organization's domain, not the author's mailbox.  So, really, DMARC
> concerns an operational identifier, not a content creator.
> 
> The suggestion, therefore, is to retain alignment, but move it to a
> field that has to do with operations, not content.


Exactly.  While From: is linked to the semantic content, Sender: can
be altered scot-free by any intermediate operator.  All the policies,
the aspf and adkim settings that an originator had devised will be
gone.  So will filtering by paramount domains or TLDs.  All those
moments will be lost in time, like tears in rain...


>>>> Sender: has a display name and an address, just like From:.  Don't we
>>>> risk to double phishing opportunities?
>>>>
>>>> If Sender: and From: domains disagree, are both going to get reports?
>>> Why would there be a DMARC report on From:?
>> Reports are supposed to be consumed by the originator.
> 
> You didn't actually answer my question.
> 
> Let's try a more complete question:
> 
>      If DMARC reports refer to the Sender: aligned domain, and reports
> refer to that, why is a report on the From: field also required?


An originator needs to check whether the DKIM signatures they apply
are robust enough to pass through indirect mail flows.

If you consider the originator's mark unimportant, perhaps because the
last hop's signature suffices, you're reinventing ARC.


Best
Ale
-- 


















From nobody Fri Jun 26 02:16:24 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFB23A1210 for ; Fri, 26 Jun 2020 02:16:22 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 X9qJMSqZ_oWK for ; Fri, 26 Jun 2020 02:16:20 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 AEC683A11E7 for ; Fri, 26 Jun 2020 02:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593162977; bh=VkR25dQl7/6RPfAH1jY+v2WJp3aXze1FeKJ6h7bdcw8=; l=1427; h=To:References:From:Date:In-Reply-To; b=C162RwsE10ZeeoMg7NzPdBdXkpJSF1I8UxLR3D0exdgwBFx4DkDpy39/i6DDv7+Bx HiPaFEAjAVpI20wzopRHKz4IBS2RPFLJwU7osS1ddisTHj4Mx0rTQOVhhCOYeVoZYZ +xKkaI0q9BeuiJu6VbA3gKSJF0o+kEB1OqUY5swwCvAcNmfoc8hHbKbQVbn3h
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.171.89.134]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EF5BCE0.0000388C; Fri, 26 Jun 2020 11:16:16 +0200
To: dmarc@ietf.org
References: <20200626032027.B7EFA1BB563D@ary.qy>
From: Alessandro Vesely 
Message-ID: <42d0aae1-1408-504a-810e-a8c6b947e02e@tana.it>
Date: Fri, 26 Jun 2020 11:16:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200626032027.B7EFA1BB563D@ary.qy>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 09:16:22 -0000

On Fri 26/Jun/2020 05:20:27 +0200 John Levine wrote:
> In article  you write:
>> B) Specifying the specific Intermediary in the Intermediary Field. This
>> would indicate that the users domain recognizes that the user uses the
>> intermediary and by policy exempts this use even though it breaks both DKIM
>> and SPF validation. The receiving domain would need to recognize some
>> potential risk of malicious modifications or additions to the message.
> 
> Sounds like what I proposed several years ago:
> 
> https://tools.ietf.org/html/draft-levine-dkim-conditional-03


+1, proper verification requires a DKIM version bump.

However, the first point in the issues is new:

On Fri 26/Jun/2020 02:05:43 +0200 Dotzero wrote:
>> Issues:
>> 
>> 1) It increases administrative complexity for the originating domain
>> in that it requires the domain to either track user:intermediary
>> relationships or enable users to self approve such relationships ad hoc.


The problem of how to build such knowledge on user:intermediary
relationships at each mailbox provider might be worth being discussed.

Note that the same knowledge, at the receiving stage would allow
receivers to just whitelist MLMs.  Even if this simpler arrangement
wouldn't survive further forwarding, it is not antithetic to
conditional signatures.


Best
Ale
-- 

























From nobody Fri Jun 26 04:42:10 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351463A125B for ; Fri, 26 Jun 2020 04:42:09 -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 (1024-bit key) header.d=bayviewphysicians.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 XpD_y-sZXwOW for ; Fri, 26 Jun 2020 04:42:07 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE223A0953 for ; Fri, 26 Jun 2020 04:42:07 -0700 (PDT)
X-ASG-Debug-ID: 1593171725-11fa313a102647f0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id P7SwawqUUA2R6K2q (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 26 Jun 2020 07:42:05 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=6cQA3qjdK/0+ak/5vLTbSTT+96ZoMCrpPpu71rKm8kA=; b=nV8CQdtf7Sd/Xtpp1/SsfxbtH0yGSEKxtYCAt+Ke2aouI8inBTK7au7PpZWAotZZZ jZGtcMjNJrGy9NisoefT7RxlCLwNxaSSkn8FRYrSWPeZs/GlRFlDMqxHK2LADMbZw SttmwOeGfDHLisr8Bu2FsmS43mm+RJZcuZvv3AMYc=
From: "Douglas E. Foster" 
To: 
Date: Fri, 26 Jun 2020 11:41:58 GMT
X-ASG-Orig-Subj: Re: [dmarc-ietf] What if... Sender:
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <1fd4e632a4cf4f32886347da9314d92b@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=4ea46d42a78d42d3946b2765b8c67bb4
In-Reply-To: 
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com> <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com> <604187a6-766d-053c-d1e0-165652e0d396@gmail.com> 
X-Exim-Id: 1fd4e632a4cf4f32886347da9314d92b
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593171725
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 5062
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82818 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 11:42:09 -0000

This is a multipart message in MIME format.

--4ea46d42a78d42d3946b2765b8c67bb4
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Scott, Thank you!
>>I think the bar to convince me that it's okay to throw away aligning to 5=
322.From is in scope for the working group is really
>>high when the charter defines DMARC as "Domain-based Message Authenticati=
on, Reporting & Conformance (DMARC) uses 
>>existing mail authentication technologies (SPF and DKIM) to extend valida=
tion to the RFC5322.From field".

Two weeks ago, John  Levine reminded us that DMARC v1 was already deployed =
and this effort was to perfect the wording.   Suddenly, we have a small but=
 powerful group insisting that we discard DMARC v1 and turn it into DMARC v=
2.   

This discussion has reviewed the success of DMARC v1, how it has limited a =
whole category of attacks and has helped with law enforcement takedowns.   =
 But now John Levine wants me to prove that From alignment is important to =
"most of us", a term I used to include myself in the group that has benefit=
ed from DMARC v1.  Apparently historical results are not relevant.

The supporters of DMARC v2 can certainly navigate the IETF process, but I c=
annot imagine that Google and Paypal, who created DMARC v1, will jump on yo=
ur bandwagon.  Nor can I imagine the US Government, which is requiring DMAR=
C v1 rollout now, will jump on the v2 bandwagon based on the evidence prese=
nted in this discussion so far. 

I live with the knowledge that every day my mail stream is allowing through=
 unwanted and potentially hostile content because the email filtering probl=
em is so difficult.  I know that only one hostile message needs to penetrat=
e to trigger an attack that destroys my organization.   It galls me that so=
me of that criminal content comes from a billion-dollar U.S. company, which=
 acts as  facilitator for the crooks.    "From" is the one identity in thos=
e messages that allows me to filter the utility company mail from the bank =
fraud email.   So, yes, FROM is very important to me.

I have pointed out that the mailing list problem can be largely solved with=
 user-specific delivery options in the MLM, but that has so far been ignore=
d.   However, to support any transition to DMARC v2, MLMs will need user-sp=
ecific delivery options to distinguish those recipients that support the ne=
w design from those who do not.    So MLM readiness is not a small issue. 

DF

 



--4ea46d42a78d42d3946b2765b8c67bb4
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


    Scott, Thank you!<=
/div>
    >>I think the bar to convince me that it's okay to throw aw=
ay aligning to 5322.From is in scope for the working group is really
    <=
div>>>high when the charter defines DMARC as "Domain-based Message Au=
thentication, Reporting & Conformance (DMARC) uses 
    >=
>existing mail authentication technologies (SPF and DKIM) to extend vali=
dation to the RFC5322.From field".

    Two weeks ago, =
John  Levine reminded us that DMARC v1 was already deployed and this e=
ffort was to perfect the wording.   Suddenly, we have a small but powe=
rful group insisting that we discard DMARC v1 and turn it into DMARC v2. &n=
bsp; 

    This discussion has reviewed the succes=
s of DMARC v1, how it has limited a whole category of attacks and has helpe=
d with law enforcement takedowns.    But now John Levine wants me=
 to prove that From alignment is important to "most of us", a term I used t=
o include myself in the group that has benefited from DMARC v1.  Appar=
ently historical results are not relevant.

    The sup=
porters of DMARC v2 can certainly navigate the IETF process, but I cannot i=
magine that Google and Paypal, who created DMARC v1, will jump on your band=
wagon.  Nor can I imagine the US Government, which is requiring DMARC =
v1 rollout now, will jump on the v2 bandwagon based on the evidence present=
ed in this discussion so far. 

    I live with th=
e knowledge that every day my mail stream is allowing through unwanted and =
potentially hostile content because the email filtering problem is so diffi=
cult.  I know that only one hostile message needs to penetrate to trig=
ger an attack that destroys my organization.   It galls me that some o=
f that criminal content comes from a billion-dollar U.S. company, which act=
s as  facilitator for the crooks.    "From" is the one ident=
ity in those messages that allows me to filter the utility company mail fro=
m the bank fraud email.   So, yes, FROM is very important to me.
    =


    I have pointed out that the mailing list problem can be=
 largely solved with user-specific delivery options in the MLM, but that ha=
s so far been ignored.   However, to support any transition to DMARC v=
2, MLMs will need user-specific delivery options to distinguish those recip=
ients that support the new design from those who do not.    So ML=
M readiness is not a small issue. 

    DF



     

    =


    

--4ea46d42a78d42d3946b2765b8c67bb4--


From nobody Fri Jun 26 06:28:09 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDF63A0BC8 for ; Fri, 26 Jun 2020 06:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=HO92Tnos; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=XaeZwdoQ
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 DpvDKuot4uu9 for ; Fri, 26 Jun 2020 06:28:04 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 5CAF63A0997 for ; Fri, 26 Jun 2020 06:28:03 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2681; t=1593178072; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=FDiALzD/xnttwoohByws4nCJnhs=; b=HO92TnosFF6pdiSWXk+RZExZnurKhrMEABCJgYJQmhKRwH35r3nzOatfp7Au8O fRVv9IiXHQGvgvPTTLUvxC83283lHppzYAsTsjL2kNYmR6VOMUDL7hOYogQbUXnY +CclyLGgxkxuZVAHvlGP1ODtfM3u8/ZZaQK/yBolX7MRQ=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 26 Jun 2020 09:27:52 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3905364376.1.1120; Fri, 26 Jun 2020 09:27:52 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2681; t=1593178011; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6PBCuHr OvCRVgCkWhmJKKQdEjMJz9yjQ++m/ArtBGh4=; b=XaeZwdoQtOvlfRdoXKiOWRe EitJG6OU4Cc+F8yjDx8dftrDfss3bVt8oE/A8U58k/W0o3y2jU2rG5RNKib+MOY3 SoUpmXezQOuEg6me87TtEa2L24n/iaFEN3b0okH2d9s84Mtpq1r/PPLlQIbH7L6f XGvY3czkx1omB68Y97O0=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 26 Jun 2020 09:26:51 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 616739000.1.51548; Fri, 26 Jun 2020 09:26:50 -0400
Message-ID: <5EF5F7D9.9050502@isdg.net>
Date: Fri, 26 Jun 2020 09:27:53 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200626032027.B7EFA1BB563D@ary.qy>
In-Reply-To: <20200626032027.B7EFA1BB563D@ary.qy>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 13:28:07 -0000

On 6/25/2020 11:20 PM, John Levine wrote:
> In article  you write:
>> B) Specifying the specific Intermediary in the Intermediary Field. This
>> would indicate that the users domain recognizes that the user uses the
>> intermediary and by policy exempts this use even though it breaks both DKIM
>> and SPF validation. The receiving domain would need to recognize some
>> potential risk of malicious modifications or additions to the message.
>
> Sounds like what I proposed several years ago:
>
> https://tools.ietf.org/html/draft-levine-dkim-conditional-03

Ideally, we should offer support for two methods:

1) The non-DNS conditional method,
2) The simpler ATPS DNS method.

The 1st one is more radical code change for additional "double" DKIM 
signing logic.  You will have a segment of the population where this 
is either not be possibility and/or delayed until it can be done.  It 
also comes with security warning from the author.

The 2nd one is simple and plug and play as a DNS lookup challenge 
method. It does not require DKIM changes. It will require slight 
modifications to the DMARC verifier to look for the optional DMARC 
extension "atps=y" tag for 3rd party signing conditions and 
authorization check.

I can support #1 because there will be IETF folks who will say #2 does 
not scale and the DNS lookup overhead can be high with NXDOMAIN 
results. The latter would certainly be true during the early migration 
period in the same way it was true with SPF, ADSP and now ADSP The 
same was will be true with ATPS with NXDOMAIN results.  Over time, we 
will see the payoff as more domains will support the officially IETF 
sanction protocols described in a protocol complete DMARC-PS.

As to ATPS not being scalable?  That is just a question more related 
to DNS storage and management. But even so, having both will address 
all scales and wider implementations where you will have a migration 
period and the easier one will probably be implemented first to get a 
proof of concept and then perhaps adding conditional support for 
higher scale needs.

But I won't repeat what has happen in the past.  I won't support #1 
unless the author is serious about DKIM Policy and show he is ready to 
champion the protocol rather than use this as a way to poison the 
DKIM/DMARC policy effort with a chaotic and self-admission unsecured 
DKIM add-on with no real intention to complete and support.  The 
security section #1 will need to be review to address its described 
replay potential.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Fri Jun 26 06:48:28 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010F43A0C3B for ; Fri, 26 Jun 2020 06:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=bmEOuK3J; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=pqDVpCbP
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 TTYR3tJEwSRQ for ; Fri, 26 Jun 2020 06:48:24 -0700 (PDT)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (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 D00773A0C21 for ; Fri, 26 Jun 2020 06:48:23 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=494; t=1593179297; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=cJEuWAu0qlqaCHNkuWvKxsbZkqE=; b=bmEOuK3JutjS/GJgP7Qb9Q15EJbRHTUnIuqQj4R2MMxqQ+KaPlng422QvEnGtL g64kynTkrU7aQ7t9IF0e/BjvRQXBhnrjNp9RPYweKOpi3lhs7wD7bLy5CxxsRU/v sK1yeU2YhbeM9b0rCd1d6CiPAG+PVq5XP6wEP/5dzQrH8=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 26 Jun 2020 09:48:17 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3906589420.1.3280; Fri, 26 Jun 2020 09:48:17 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=494; t=1593179236; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=S3O5Eqk CBNGN8dnF5/I40OxuMgWEsCH9+iuqpiOh7n0=; b=pqDVpCbPCxKDM4GfnOchDD8 9TuzpENoaOs9B6CSAHhzlfIWM2vIvE30l0U9IjoaspOdU7X4TJ65JW6+gIRpocp9 L+lJkqekNjhrGdrO51C0VdF3pXPXLLbObkhCq0Y6PKJbfZP8WwHYwju6sp0zvO9i ydGujwdTKcdGszb0IMnA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 26 Jun 2020 09:47:16 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 617964516.1.52208; Fri, 26 Jun 2020 09:47:15 -0400
Message-ID: <5EF5FCA2.4090505@isdg.net>
Date: Fri, 26 Jun 2020 09:48:18 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200626032027.B7EFA1BB563D@ary.qy> <5EF5F7D9.9050502@isdg.net>
In-Reply-To: <5EF5F7D9.9050502@isdg.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jun 2020 13:48:26 -0000

On 6/26/2020 9:27 AM, Hector Santos wrote:

> The latter would certainly be true during the early migration
> period in the same way it was true with SPF, ADSP and now ADSP The
> same was will be true with ATPS with NXDOMAIN results.

Meant to say:

The latter would certainly be true during the early migration
period in the same way it was true with SPF, ADSP and DMARC with
NXDOMAIN result.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Fri Jun 26 18:45:02 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EEE3A08C0 for ; Fri, 26 Jun 2020 18:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ocnHIe6K; dkim=pass (1536-bit key) header.d=taugh.com header.b=N7+xtV/G
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 ONLBAqRtblTY for ; Fri, 26 Jun 2020 18:44:58 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B30473A08BE for ; Fri, 26 Jun 2020 18:44:57 -0700 (PDT)
Received: (qmail 83995 invoked from network); 27 Jun 2020 01:44:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14818.5ef6a498.k2006; bh=fuMHyC7Ad6hSW8GtQ+3XAqyS5Pe6mZd/7Ry2Dqr9OE0=; b=ocnHIe6KAznRuwomVm1TylX2u8KWbI/fpJfnr6M9B1qM4lFNEEXzE6QacppSXDL1LwrGQaf1R7ttJP/xZvNc37HMvj/Txx65WlqleCel+paMq9BewQ1g2gQ5ZJqve6rYPEwMJoiZShZbrdE+zFMKJ3ve4b8NdtSicuu0D8qzTh0rgjjYLODkpdDCorWs+f7IxcsW4rEa4OqCsH8f1+6nyN9ieFbxU1IDGWuKtZs1UwZuhGQNpSElr1k/zWmKnDAW
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14818.5ef6a498.k2006; bh=fuMHyC7Ad6hSW8GtQ+3XAqyS5Pe6mZd/7Ry2Dqr9OE0=; b=N7+xtV/GhEIBOfjeIJMUdfpigRGYPuCYiH25OC6cyBAeCY9rLGJn1OexhYUaYvZDrbcL2B4QhR81hSTy2xyimUQ52IYO+rp7S2NEVo/T71jDuTDYR2XAQeAf8FkWqjYUskaCA6pKKfnZ7xGUU6lgJQ/LGH9pYISCvcp+MPC2rtQgack7lsyc3Mx0PvLLLRiY4nfOt0/vFXjFyNUKm+1mXuA1/96lbEFWJXZwucvk6WV9J/rMjvYCCElUhAWDsLfw
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Jun 2020 01:44:55 -0000
Received: by ary.qy (Postfix, from userid 501) id 95A991BBCBC6; Fri, 26 Jun 2020 21:44:55 -0400 (EDT)
Date: 26 Jun 2020 21:44:55 -0400
Message-Id: <20200627014455.95A991BBCBC6@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: johnl@taugh.com
In-Reply-To: <20200626032027.B7EFA1BB563D@ary.qy>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jun 2020 01:45:00 -0000

In article <20200626032027.B7EFA1BB563D@ary.qy> you write:
>In article  you write:
>>B) Specifying the specific Intermediary in the Intermediary Field. This
>>would indicate that the users domain recognizes that the user uses the
>>intermediary and by policy exempts this use even though it breaks both DKIM
>>and SPF validation. The receiving domain would need to recognize some
>>potential risk of malicious modifications or additions to the message.
>
>Sounds like what I proposed several years ago:
>
>https://tools.ietf.org/html/draft-levine-dkim-conditional-03

Mike clarified that his suggestion is simpler in that the recipient
can recognize that intermediary however it wants, not necessarily with
a DKIM signature.

This makes me wonder how many mailing lists still don't add DKIM
signatures. Unlike the header rewriting hacks, they don't affect the
way recipients see or handle the mail in their inboxes.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Mon Jun 29 02:19:13 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CAD3A0CC7 for ; Mon, 29 Jun 2020 02:19: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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 W4Ln1mDszqHp for ; Mon, 29 Jun 2020 02:19:10 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 A94AD3A0CC5 for ; Mon, 29 Jun 2020 02:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593422346; bh=3joL0/a7fZqYf8mMoIvE+ctENGpplS8hdLK05RNv2HU=; l=973; h=To:From:Date; b=ATcu+VKleY2pbSp/TkxtHaWELbOTlpXXYMkIXiIKdpUgRaoVHFQLIYZlXfXAgfPrr pKKQE0RK70+mhd/WSNAkp+ECHgTtCnXASZrWaHuW9TMjn25/9vpInVIMLC6XuOuGcA 7/wwLBq5pRHX8IqVRBT6B+QJ/3yEdpic1ALP+sQ7aMEcCAeO2X0UN663DCN73
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.101] ([5.170.0.171]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005EF9B20A.00001AB5; Mon, 29 Jun 2020 11:19:06 +0200
To: dmarc-ietf 
From: Alessandro Vesely 
Message-ID: 
Date: Mon, 29 Jun 2020 11:18:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jun 2020 09:19:12 -0000

Hi all,

I mentioned setting To: author instead of From: author-like, near the bottom of a message[*] a week ago, but missed any WG comments on it.  That setting would result if I run a mailing list "by hand", using a normal email client.  I'd hit reply and then add a bunch of Bcc:'s.  Of course, a suitable template would insert a subject tag instead of "Re:", et cetera.

It'd be a cleaner solution than From: rewriting, inasmuch as it saves the association between display names and addresses, for the sake of address books consistency.  The anomaly of seeing authors in To: fields, with some getting used to it, may even become a distinguished characteristic of indirect mail flows.

How unbearable would that be?  And why?  Maybe some comments on this subject can bring out some more details about the rightness or wrongness of the various flavors of From: rewriting.


Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/Mi6jz1SfgOnz7JjPUemkpJvFQ_w






























From nobody Mon Jun 29 06:01:26 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE273A0EA7 for ; Mon, 29 Jun 2020 06:01:25 -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, 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 (1024-bit key) header.d=bayviewphysicians.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 6s0V7xw5Nado for ; Mon, 29 Jun 2020 06:01:24 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E643A0E37 for ; Mon, 29 Jun 2020 06:01:24 -0700 (PDT)
X-ASG-Debug-ID: 1593435676-11fa313a10283800001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 3DoHdlh5s50kNDQT (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 29 Jun 2020 09:01:16 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=0eXiUQwcKUBeGtANTrEAAEce/0VXnC60Sakd3HyHpB4=; b=aMGqBRWng2Tf5Umem+hB0OM5Q6lj9EGMt2adSrQZwTa0OsosFv0uHCsCizrSIOk09 +AH2JyOPhs0iXvKDz4YIm76CUfBIXmLdZ5IR8P0v3/B4KFDctvzKv9iCYlkdHGKyl YliQs9I37zu/Ym/z3CNPxkP13sRbrm6eZQwzQtXWk=
Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 29 Jun 2020 09:01:07 -0400
From: "Doug Foster" 
X-Barracuda-RBL-IP: 192.168.2.108
To: "'dmarc-ietf'" 
References: 
In-Reply-To: 
Date: Mon, 29 Jun 2020 09:01:07 -0400
X-ASG-Orig-Subj: RE: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
Message-ID: <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGMa8Hma/tu7nXkM4xjuH+qsSRkQqmDUfGg
X-Exim-Id: 000001d64e15$5ab947a0$102bd6e0$
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593435676
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 1857
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82888 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: 
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jun 2020 13:01:26 -0000

Very creative suggestion.   We need some new ideas.

However, I just checked my MUAs.   All of them assume that "To" is
unimportant, so it is not displayed in the message list.   "To" only appears
in the message view (including the Preview pane).    Without more
visibility, it probably does not sufficiently solve the user interface need.
Which also suggests why I have not seen spammers try to manipulate that
field.

Doug Foster

-----Original Message-----
From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Alessandro Vesely
Sent: Monday, June 29, 2020 5:19 AM
To: dmarc-ietf
Subject: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

Hi all,

I mentioned setting To: author instead of From: author-like, near the bottom
of a message[*] a week ago, but missed any WG comments on it.  That setting
would result if I run a mailing list "by hand", using a normal email client.
I'd hit reply and then add a bunch of Bcc:'s.  Of course, a suitable
template would insert a subject tag instead of "Re:", et cetera.

It'd be a cleaner solution than From: rewriting, inasmuch as it saves the
association between display names and addresses, for the sake of address
books consistency.  The anomaly of seeing authors in To: fields, with some
getting used to it, may even become a distinguished characteristic of
indirect mail flows.

How unbearable would that be?  And why?  Maybe some comments on this subject
can bring out some more details about the rightness or wrongness of the
various flavors of From: rewriting.


Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/Mi6jz1SfgOnz7JjPUemkpJvFQ_w





























_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




From nobody Mon Jun 29 18:05:55 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7599D3A0F38 for ; Mon, 29 Jun 2020 18:05:46 -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, FREEMAIL_FROM=0.001, 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=gmail.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 LoINbSXEqfm8 for ; Mon, 29 Jun 2020 18:05:44 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 AA4C23A0EEB for ; Mon, 29 Jun 2020 18:05:44 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id z47so5949493uad.5 for ; Mon, 29 Jun 2020 18:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XDticj4tXOlTCHu3AiNDbWwQ1Yu840F8/b6b1HV9KqY=; b=hFAESMsOz5LJ8RZQbzQ6kuLkY32EuR1ctBa6l1AhRft53Ygkf/snWA9h7JO6OKk5WY 2brzyQX27iAaBG1gXC5a8kyHY6J1FZUE3dG/cpiQt5d5q1cSzdjgek4sVWuS0oBsjibz CtmdeFoK4MHOYHFBKJhQHyJ6xRIJB76xf1a0D1FXV7rMU5J/6vT2J+QwdgjR+Lvov16c nSAtLEpVi6cQIekjEepR6z1aAhZgPuChYg/Ai9RNEr+bONgqB49LxMlsCxeyKt70VLoB 5bwXePm7Nebk8byxvl8sbWnO2pbccuwdg65uw2ZR8IpIcmqxkBPXH9+18vxkZp3XzHeA 0yTA==
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=XDticj4tXOlTCHu3AiNDbWwQ1Yu840F8/b6b1HV9KqY=; b=rRHr77Y0m9VDQ4JDZJL9G6r3EJN3zCUKRUIP5N5XIVKGRyEQ/+iL5E9SWjx9cUNBMs xlvPwv/qCNfPr7ihlNjLnFuJrfsD2rX5mcTdzzXL/VBwDfn0mvhKw+04euUYIlr0METW bZkWInnXbLJxx+lPTNCDk6nZ/l9Ch7c8O15rbkYlIk/6WEQjn+tMFWuXrA7fpznfcMcu qZBXi/Wj6Inq7A8Ynq/QK/Enth7cOCW4yrhUfjnk+iEm6b+HQaUiXxA6g/sRdGbUBTc/ RJ4MSjQ7iVpPsYZRurr25l1Gy6UkSrC9UyRzZ72+WpYS+umC+SozmM2Z7dP8nl4Fb22u 11Sg==
X-Gm-Message-State: AOAM531rTpwTfOfO+ziNYRy1XdCrUPOZ4f223uf8fwI9lIUMjBhxYi3A GwxHxvFDhG9fjNHrDV0YlzpunGAlSzRD7cdpLfU=
X-Google-Smtp-Source: ABdhPJyim3x5b0KYyHRMiR7q8dYZa62YD63MgJoc4VL2BcSByMIsq1W1+zT1dsIztVcj0UvjDFmD8uJR11QI1+u7Qac=
X-Received: by 2002:ab0:300c:: with SMTP id f12mr12053067ual.76.1593479143556;  Mon, 29 Jun 2020 18:05:43 -0700 (PDT)
MIME-Version: 1.0
References: <8b3c016f-698c-62e3-3e57-5abea408edbb@gmail.com> <3519815.6odjxCbuFl@zini-1880> <505d035b-4b2b-b6b5-306f-7ff38ff19a1c@gmail.com> <1986956.MqcZLKCXeg@zini-1880> <1c3cc013-8eb0-2d36-da47-057c7b0eeb7c@bluepopcorn.net> <0940B242-F49E-4297-868E-9B6598978967@kitterman.com> <44382cc7-4e7c-a675-25df-e7331e5d8649@gmail.com> <69ED19E1-11C8-431F-9413-8CBE78120B4C@kitterman.com> <604187a6-766d-053c-d1e0-165652e0d396@gmail.com>  <1fd4e632a4cf4f32886347da9314d92b@bayviewphysicians.com>
In-Reply-To: <1fd4e632a4cf4f32886347da9314d92b@bayviewphysicians.com>
From: "Murray S. Kucherawy" 
Date: Mon, 29 Jun 2020 18:05:32 -0700
Message-ID: 
To: fosterd@bayviewphysicians.com
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="0000000000004f0c8005a942c664"
Archived-At: 
Subject: Re: [dmarc-ietf] What if... Sender:
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 01:05:53 -0000

--0000000000004f0c8005a942c664
Content-Type: text/plain; charset="UTF-8"

Emphatically hatless:

On Fri, Jun 26, 2020 at 4:42 AM Douglas E. Foster <
fosterd@bayviewphysicians.com> wrote:

> Two weeks ago, John  Levine reminded us that DMARC v1 was already deployed
> and this effort was to perfect the wording.   Suddenly, we have a small but
> powerful group insisting that we discard DMARC v1 and turn it into DMARC
> v2.
>

"Perfect the wording" rather trivializes what I believe the charter charges
this working group with doing.  If you read it, I suggest you'll see that
this is a heavier lift than that.

This discussion has reviewed the success of DMARC v1, how it has limited a
> whole category of attacks and has helped with law enforcement takedowns.
>  But now John Levine wants me to prove that From alignment is important to
> "most of us", a term I used to include myself in the group that has
> benefited from DMARC v1.  Apparently historical results are not relevant.
>

This seems to me like a myopic synopsis of the discussion so far.  Remember
that while DMARC has lots of people thinking it's a huge step forward in
fighting fraud, there is also an audience that thinks it's been a serious
disruption and has caused more collateral damage than it is worth.  It has,
in particular, disrupted the work of the IETF itself.  It is therefore
reasonable, in my view, to review the premises on which the claimed success
was achieved.  (That's not to say claims of its success are flatly wrong,
but rather that, as with any other scientific endeavor, reviewing our
assumptions should always be on the table.)

The supporters of DMARC v2 can certainly navigate the IETF process, but I
> cannot imagine that Google and Paypal, who created DMARC v1, will jump on
> your bandwagon.  Nor can I imagine the US Government, which is requiring
> DMARC v1 rollout now, will jump on the v2 bandwagon based on the evidence
> presented in this discussion so far.
>

DMARC v1 was not the product of any standards process.  One could argue
that the damage it has caused is a result of the absence of such rigor.  I
don't know why, then, you would discard v2 so easily when it will by
definition be developed with what is probably a higher standard before it's
published.  I, similarly, cannot imagine the likes of Google and Paypal
dismissing out of hand a potentially improved version that actually has
more broad consensus and reduces damage (but, of course, I'm in no position
to speak for them).

I'd like us to take a run at actually doing the work before calling
conclusions like this.

I have pointed out that the mailing list problem can be largely solved with
> user-specific delivery options in the MLM, but that has so far been
> ignored.   However, to support any transition to DMARC v2, MLMs will need
> user-specific delivery options to distinguish those recipients that support
> the new design from those who do not.    So MLM readiness is not a small
> issue.
>

I suggest that specification of user delivery options don't belong in a
protocol document, except perhaps in an informative advisory appendix.  The
working group could choose to pursue an applicability statement alongside
the protocol document that defines DMARC v2, if that's a necessity.  It's
up to the chairs to determine whether consensus has been established to do
so; it's up to you, if you are in favor, to do the work to develop that
consensus.

-MSK

--0000000000004f0c8005a942c664
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Emphatically hatless:

    O=
n Fri, Jun 26, 2020 at 4:42 AM Douglas E. Foster <fosterd@bayviewphysicians.com<=
/a>> wrote:



    =
This seems to me like a myopic synopsis of the discussion so far.=C2=A0 Rem=
ember that while DMARC has lots of people thinking it's a huge step for=
ward in fighting fraud, there is also an audience that thinks it's been=
 a serious disruption and has caused more collateral damage than it is wort=
h.=C2=A0 It has, in particular, disrupted the work of the IETF itself.=C2=
=A0 It is therefore reasonable, in my view, to review the premises on which=
 the claimed success was achieved.=C2=A0 (That's not to say claims of i=
ts success are flatly wrong, but rather that, as with any other scientific =
endeavor, reviewing our assumptions should always be on the table.)
     
    The supporters of DMARC v2 ca=
n certainly navigate the IETF process, but I cannot imagine that Google and=
 Paypal, who created DMARC v1, will jump on your bandwagon.=C2=A0 Nor can I=
 imagine the US Government, which is requiring DMARC v1 rollout now, will j=
ump on the v2 bandwagon based on the evidence presented in this discussion =
so far.=C2=A0

    DMARC v1 was not =
the product of any standards process.=C2=A0 One could argue that the damage=
 it has caused is a result of the absence of such rigor.=C2=A0 I don't =
know why, then, you would discard v2 so easily when it will by definition b=
e developed with what is probably a higher standard before it's publish=
ed.=C2=A0 I, similarly, cannot imagine the likes of Google and Paypal dismi=
ssing out of hand a potentially improved version that actually has more bro=
ad consensus and reduces damage (but, of course, I'm in no position to =
speak for them).

    I'd like us to take a run at =
actually doing the work before calling conclusions like this. 



    -MSK
    

--0000000000004f0c8005a942c664--


From nobody Tue Jun 30 01:52:04 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5CF3A10FE for ; Tue, 30 Jun 2020 01:52:01 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 T5LpZSQFcGcL for ; Tue, 30 Jun 2020 01:52:00 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 32F013A10FB for ; Tue, 30 Jun 2020 01:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593507116; bh=YvWtRYKOiZxzmg9RutgoBSmWWhdmtwUUJm3GS1EnCzY=; l=755; h=To:References:From:Date:In-Reply-To; b=DV/hEKjV6m6hg/YvnUQMcL/MjL/KTSb1O7D5wE4Wbsx8H4g6xX4Zi8Y2uilptNvRg o52ge52LHGhQbSiS9UQ3RKZ/xOOIgRUxUs+paDNAGUQOdchbY+L7rRb/6cgTF5nbFS zcvIT/vGquJCvshcwn3us/wnZwkM5vv3MbkBR4q/sTNOpESNFF8VH5xtGPsYv
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005EFAFD2C.00000E3C; Tue, 30 Jun 2020 10:51:56 +0200
To: dmarc@ietf.org
References:  <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com>
From: Alessandro Vesely 
Message-ID: 
Date: Tue, 30 Jun 2020 10:51:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 08:52:02 -0000

On Mon 29/Jun/2020 15:01:07 +0200 Doug Foster wrote:
> Very creative suggestion.   We need some new ideas.
> 
> However, I just checked my MUAs.   All of them assume that "To" is
> unimportant, so it is not displayed in the message list.   "To" only appears
> in the message view (including the Preview pane).    Without more
> visibility, it probably does not sufficiently solve the user interface need.
> Which also suggests why I have not seen spammers try to manipulate that
> field.


Can't you select what fields to display in the folder view?

The Sent folder must look boring if it only displays From:.

How about catchall folders?  Hm...  I though all email clients featured 
customizable views nowadays.


Thank you for replying
Ale
-- 






















From nobody Tue Jun 30 07:51:20 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D693A09A8 for ; Tue, 30 Jun 2020 07:51:18 -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_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=q/JRQgBl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gTMbGQao
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 NJpBd-Z7atS9 for ; Tue, 30 Jun 2020 07:51:17 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AA83A09A0 for ; Tue, 30 Jun 2020 07:51:16 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 111985C0132 for ; Tue, 30 Jun 2020 10:51:16 -0400 (EDT)
Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Tue, 30 Jun 2020 10:51:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=DXNJpuvN41Gu9E9vXOrNK9pYwR49IHy izPjyVONZsDE=; b=q/JRQgBl/RlyAwOPv1FmynLQ/zmcqavB6QEX+SvdkmjozrT YAUrByY1uAMLTx1MFvgvXdGXVCZ5Sl0c8nMst783i94jNGf8Pc+k5S7jigcBbMCP 4nvMHYheSmcJL0NcjchXSg/zZMBVWMccmQN7uF6Km9HWlCr6MT5PgrEwQjLP052g sqb2fkl8HztW4pT3Rf8fjgVrlhzphqp2WIoUy2gT8KyYovQ+OCkflbWzkKKTZJav seKOPQxdPJOiDgNMaTkDgnb/cV/HeSaZI6RWGa0Hv0sYeL4WvrvBoY3bqR2ifogY VebuIyyUR3ZNRttbHgMrBwYuePkyqBKxAq3XWuQ==
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=fm3; bh=DXNJpu vN41Gu9E9vXOrNK9pYwR49IHyizPjyVONZsDE=; b=gTMbGQaok4p+8RQBQAcXel E/mw4nI14XjxX3mEUZ5V9cBQtaBcN0JCkPdMnowHPwH7GcwaR8mMu29K6VskA3zj fWUf6e34+djoyNAjjuGA6x895FxybvJ0HSq+OY1QZQrN4Hitc2vJU+PlGO7KPI/D TJMmsh07NUAJQAhf3LEkkPRwSJS9ABf7adnX8f8uxXfnFj8q40l+Ln6pEvnIvLQC EwqN5oprMsANHhQKOyBaFxRq42IYqSPJD2MtCzEF0IRn6Xg0B9y6DAVEFpgHBVKp q/smdLR/RANPMiqnnIP6JJnf/oiNbJCbuIw4hS/vTZ2t52/mUeT39jCEe3pUIeZA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddtgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehglhih phhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecuggftrfgrthhtvghrnhepvdegtd effeejgffhueetieeuuddugeetgefhtdffteeulefgveffteelheejffffnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihph hhvghinhdrmhgrihhlfhhorhgtvgdrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7C8681400A1; Tue, 30 Jun 2020 10:51:15 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20200627014455.95A991BBCBC6@ary.qy>
References: <20200627014455.95A991BBCBC6@ary.qy>
Date: Tue, 30 Jun 2020 10:50:55 -0400
From: "Stan Kalisch" 
To: dmarc@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [dmarc-ietf]  =?utf-8?q?An_alternative_proposal_to_the_known_inte?= =?utf-8?q?rmediary_problem?=
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 14:51:18 -0000

On Fri, Jun 26, 2020, at 9:44 PM, John Levine wrote:
> This makes me wonder how many mailing lists still don't add DKIM
> signatures. Unlike the header rewriting hacks, they don't affect the
> way recipients see or handle the mail in their inboxes.

The HTTPbis list and Full Disclosure immediately come to mind. IIRC, Bugtraq didn't use DKIM, either.


Stan


From nobody Tue Jun 30 08:08:51 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2CC3A09DB for ; Tue, 30 Jun 2020 08:08:49 -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, FREEMAIL_FROM=0.001, 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=gmail.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 MuGlWR6zoqu8 for ; Tue, 30 Jun 2020 08:08:48 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 AEF4F3A09D6 for ; Tue, 30 Jun 2020 08:08:47 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id h5so20552824wrc.7 for ; Tue, 30 Jun 2020 08:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+n0WhSQj5hYMiPzB2My2qvPIuKazI5/yxWLU1C7p7Ks=; b=XlQMTntsi2pGyRty+Zhm4XW+ZCkjMD3PMZbwWFsLaW3U2yOIEdJdmCRr1nF4X/pq37 VEN+bHEB7g0RhQVyOn+4wU/LhKoIRNNSYBjjflHdrqPWy/qOsb6cRNZ+Z2ayL2QXjaj4 /pT3bks+qxDPZ82Wrazvhg5LjCPhDj4pZfwJq1YwUmz0iOjd6TYfSmaeUQ0vI9ObeYeW 4yQzGc1pONuB2A5BvmhQ/uI7FKyhxZ5IcJYGYaWzKQWswWnr/Fw5nM63HpHLAYbetlJN NILXsofhqk/avs1QmVFPj/tKDOLC/IZwKEZTl58NjZSW8VvWRjL3/07uxPNOd4FBxE6T tRQg==
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=+n0WhSQj5hYMiPzB2My2qvPIuKazI5/yxWLU1C7p7Ks=; b=U7Sv3g/2kYrmlwN+bz4JHoMxiwymGcuX3J94g3kfZc0AA0Itd+H9kS/5SXsvk4Pwgr MGIzAZJVrJKFX89sJrnCPLEYsmeAyowD1mr9BoTsihbCyfBlhwLd/pMdVa27Cyme4GXi OfDl5kGZUP6fMHQLU/Qq54NtDe+jhaexudRLwEz/HdLFOoy0bKZIaNf4aHZyWc+YnxGf Y2skBnqe9C6C/2EIesEeNx26CxhQKMk4foajbwTxkZ6YOP3PNxciYIOQilWx6f1cDtJr YED2ifZWXTdfRym6MjJQ8TP5rcOFgQ2iSrqKTQMcVd+/yVZbBGGDuF5nJBLhkRCKRLj0 4YNQ==
X-Gm-Message-State: AOAM530NcYNU6cVR8keo448mwyMlrQAeSKUqm50KfwI2PHqklMe12VxX tk3YIoptztX4DgqOxpMfE+VufqJn+qBiWgoJg6e60A==
X-Google-Smtp-Source: ABdhPJxSu1s2gK2DEjaKnFU2ZVJq1jJIARbmIJxO+L/ZN0lZyf+S0QjmBLsrzLD4vJltcyyU/PtKYb5AXTzQWeiYNAw=
X-Received: by 2002:adf:e4d0:: with SMTP id v16mr22305805wrm.193.1593529726117;  Tue, 30 Jun 2020 08:08:46 -0700 (PDT)
MIME-Version: 1.0
References: <20200626032027.B7EFA1BB563D@ary.qy> <20200627014455.95A991BBCBC6@ary.qy>
In-Reply-To: <20200627014455.95A991BBCBC6@ary.qy>
From: Dotzero 
Date: Tue, 30 Jun 2020 11:08:34 -0400
Message-ID: 
To: John Levine 
Cc: IETF DMARC WG 
Content-Type: multipart/alternative; boundary="00000000000043ab6905a94e8d23"
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 15:08:49 -0000

--00000000000043ab6905a94e8d23
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 26, 2020 at 9:45 PM John Levine  wrote:

> In article <20200626032027.B7EFA1BB563D@ary.qy> you write:
> >In article <
> CAJ4XoYeCBh4YCofhZmv+A0336aifX55BLVSdh-u21kKj+GrjAA@mail.gmail.com> you
> write:
> >>B) Specifying the specific Intermediary in the Intermediary Field. This
> >>would indicate that the users domain recognizes that the user uses the
> >>intermediary and by policy exempts this use even though it breaks both
> DKIM
> >>and SPF validation. The receiving domain would need to recognize some
> >>potential risk of malicious modifications or additions to the message.
> >
> >Sounds like what I proposed several years ago:
> >
> >https://tools.ietf.org/html/draft-levine-dkim-conditional-03
>
> Mike clarified that his suggestion is simpler in that the recipient
> can recognize that intermediary however it wants, not necessarily with
> a DKIM signature.
>
> This makes me wonder how many mailing lists still don't add DKIM
> signatures. Unlike the header rewriting hacks, they don't affect the
> way recipients see or handle the mail in their inboxes.
>

DKIM signing would certainly make it easier for receivers but I'm hesitant
to try and mandate it  for intermediaries. The 2nd signature from the
originator is a good indicator and depending on which additional fields are
signed should provide reasonable protection against replay attacks.

Michael Hammer

--00000000000043ab6905a94e8d23
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    =

    On Fri, Jun 26, 2020 at 9:45 PM John =
Levine <johnl@taugh.com> wrote=
:
    In article <20200626032027.B7EFA1BB563D@ary.=
qy> you write:
    
>In article <CAJ4XoYeCBh4YCofhZmv+A0=
336aifX55BLVSdh-u21kKj+GrjAA@mail.gmail.com> you write:
    
>>B) Specifying the specific Intermediary in the Intermediary Field. =
This
    
>>would indicate that the users domain recognizes that the user uses =
the
    
>>intermediary and by policy exempts this use even though it breaks b=
oth DKIM
    
>>and SPF validation. The receiving domain would need to recognize so=
me
    
>>potential risk of malicious modifications or additions to the messa=
ge.
    
>
    
>Sounds like what I proposed several years ago:
    
>
    
>https://tools.ietf.org/html/draft-le=
vine-dkim-conditional-03
    

    
Mike clarified that his suggestion is simpler in that the recipient
    
can recognize that intermediary however it wants, not necessarily with
    
a DKIM signature.
    

    
This makes me wonder how many mailing lists still don't add DKIM
    
signatures. Unlike the header rewriting hacks, they don't affect the
way recipients see or handle the mail in their inboxes.

    DKIM signing would certainly make it easier for receivers =
but I'm hesitant to try and mandate it=C2=A0 for intermediaries. The 2n=
d signature from the originator is a good indicator and depending on which =
additional fields are signed should provide reasonable protection against r=
eplay attacks.

    Michael Hammer
    

--00000000000043ab6905a94e8d23--


From nobody Tue Jun 30 09:17:29 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB663A0C0B for ; Tue, 30 Jun 2020 09:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qiKHJCtm; dkim=pass (1536-bit key) header.d=taugh.com header.b=JiZFfBnq
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 rL2yPIc5EqlX for ; Tue, 30 Jun 2020 09:17:26 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6A7043A0C0A for ; Tue, 30 Jun 2020 09:17:26 -0700 (PDT)
Received: (qmail 57519 invoked from network); 30 Jun 2020 16:17:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e0ad.5efb6594.k2006; i=johnl-iecc.com@submit.iecc.com; bh=NTBEN1Z1+Ypful0iKg2bkQ6F8KB2RTiE8lxCJ8AFGHY=; b=qiKHJCtmjIRfF3b6Qg6PLyt2HJKarOK0JHMPAiifUpeu9ajslQE6Vi18olvDwWAXqA3HlR8+VELEYPf7u60QD9JlSTRakxB/M9Jc1n5nv+iMpRNXjIdHHiOPBA1vTrzD/i//OYq6LzE0TTXsJYXsldd7qUnzo5cg4nsZJa4m6sAfvfEXSotf8pSCk+BCIANBFlfgj2Iozu5qglRA+/xZyXFejuUj8n3dtBpakHsjcH+73vqvkW4ZoJh4hgXu0lMe
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e0ad.5efb6594.k2006; olt=johnl-iecc.com@submit.iecc.com; bh=NTBEN1Z1+Ypful0iKg2bkQ6F8KB2RTiE8lxCJ8AFGHY=; b=JiZFfBnqPua3ceTTHYkaSK9S1cO0JfwHTMmQfvHK8uiXdRG9qaRlXKt6gof2sQhWTdHswarvKco7Ew38SziyHAmgxZcvCs8ipB2/n2Qr6OAp4ofXrSEXSrbxQkV8TQ4LvnGF9Lo8nHaBMemuXF4DensbbAEx2QzAR1EtWIIKq1Lr3L+XkGWoaLLEn9ihpvOoKdYccnRuOgz70V7kqAHtLQfEGKWP/yZbAahcfvQdqYfvt4357LcmGgcjEejtzkba
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 30 Jun 2020 16:17:24 -0000
Date: 30 Jun 2020 12:17:29 -0400
Message-ID: 
From: "John R Levine" 
To: "Dotzero" 
Cc: "IETF DMARC WG" 
In-Reply-To: 
References: <20200626032027.B7EFA1BB563D@ary.qy> <20200627014455.95A991BBCBC6@ary.qy> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 16:17:28 -0000

>> This makes me wonder how many mailing lists still don't add DKIM
>> signatures. Unlike the header rewriting hacks, they don't affect the
>> way recipients see or handle the mail in their inboxes.
>
> DKIM signing would certainly make it easier for receivers but I'm hesitant
> to try and mandate it for intermediaries.

Well, gee, it's easier than ARC signing which is what we're asking now.

I am not opposed to asking list operators to make changes, so long as they 
are not changes that force their users to change the long standing way 
they use the lists.  These days all of the MTAs and list managers I know 
can do DKIM signing, so it's not a lot to ask.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Tue Jun 30 09:43:41 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEDE3A0C10 for ; Tue, 30 Jun 2020 09:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level: 
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ridyvj3L; dkim=pass (1536-bit key) header.d=taugh.com header.b=P5mQkLv2
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 9dNOKiwNVhlJ for ; Tue, 30 Jun 2020 09:43:37 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 ACF1B3A079D for ; Tue, 30 Jun 2020 09:43:37 -0700 (PDT)
Received: (qmail 62889 invoked from network); 30 Jun 2020 16:43:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f5a7.5efb6bb7.k2006; bh=5QSvlfA5fbNYySBEkmpOdFonlh8Bl+aiyFSJz3+wnlM=; b=ridyvj3LM5G2Cl7qVCLEQungIKFOfCqwsiJV3Tvtd0mUronGuFr88mjUBO+f6YrWzlVppowqfnyWjfEeywGbH5v8lM6Nw43N9PPEYQRb8k0afFG+33EinDPwv81miB65j7S4eUN48B3AaYAI9XbYgiP7kDXytue9ZpDMCofzkEswoj2HdvkKL4rWMHZ6Vf9czn/IVWar4LQTPPb9O+Af2N7FdhIpm5GFGFspNKpV6n6r2yGzvBEa/4mocUl2j8L0
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f5a7.5efb6bb7.k2006; bh=5QSvlfA5fbNYySBEkmpOdFonlh8Bl+aiyFSJz3+wnlM=; b=P5mQkLv2ENBX8VhAyibqXZD+enJmmpxuPbOSBP3pK/tTXUBjz8VrjiK8EnN6Wdi9rhzMEjxRPsBNTsThBidjiagb6IjJlvjoUM39cgpcUA8C1XZq6zimFuyZ098gSwNtSJSTuRK/W6vBxo2oz0lSJyoOFtN0xShhomcIYlVhbos9QjyUYsNN811UtLGa+hFcKQn6LY0hLQv7NRhxh6z7GPsqC/JoblO+f3iP5TfrhhXlCtVaQ31GlpTCVQrNRemA
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 Jun 2020 16:43:34 -0000
Received: by ary.qy (Postfix, from userid 501) id 1E8001BDB4F1; Tue, 30 Jun 2020 12:43:40 -0400 (EDT)
Date: 30 Jun 2020 12:43:40 -0400
Message-Id: <20200630164340.1E8001BDB4F1@ary.qy>
From: "John Levine" 
To: dmarc@ietf.org
Cc: stan@glyphein.mailforce.net
In-Reply-To: 
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [dmarc-ietf]  =?utf-8?q?An_alternative_proposal_to_the_known_inte?= =?utf-8?q?rmediary_problem?=
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 16:43:40 -0000

In article  you write:
>On Fri, Jun 26, 2020, at 9:44 PM, John Levine wrote:
>> This makes me wonder how many mailing lists still don't add DKIM
>> signatures. Unlike the header rewriting hacks, they don't affect the
>> way recipients see or handle the mail in their inboxes.
>
>The HTTPbis list and Full Disclosure immediately come to mind. IIRC,
>Bugtraq didn't use DKIM, either.

Bugtraq was started in 1993 and is now dead so I'm not sure how useful
an example it is.  Don't know which httpbis list but the IETF signs all its
mail and if W3C doesn't, they use Exim which is easily adjusted to do so.

The question isn't whether everyone signs, clearly some don't. The
question is how much of an imposition it would be to ask them to do
so. Unless they're using incredibly ancient mail and list software,
not much.

R's,
John


From nobody Tue Jun 30 10:16:21 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342F13A0C9D for ; Tue, 30 Jun 2020 10:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=U+3h/O1s; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QWWoPrSp
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 OFRdBN3w0beu for ; Tue, 30 Jun 2020 10:16:16 -0700 (PDT)
Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (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 8B73D3A0A3A for ; Tue, 30 Jun 2020 10:16:16 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5771; t=1593537369; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=G3xAA7ZCzWFalYeEfUJNmZGxKi8=; b=U+3h/O1s8CqK5YawjTq4W5EF+EPS1NelExL3Xwya1joNS4EU4+Y1Utd4alUehv RdTZ4RmMdTg1h4EUtad2v9K80SFkITYrb7izvJEiJeCkIJvHkcgXT0sqNQl+LGij E8M76+KBeye/vXyMxStDWsCU92wrph+jZ0UeRfGaN8UKI=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 30 Jun 2020 13:16:09 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4264657314.1.2336; Tue, 30 Jun 2020 13:16:09 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5771; t=1593537304; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2sxlSm0 zv5QOj1O6Hwu9n2kSTpFQGLXWB/EYRfJQ2Og=; b=QWWoPrSpR6jXh2R20mu6Ks5 c5gZKGitERi6k0CnK1l2F7smm99wjX3IYZjIWOglaeUvweD+tCxWwN4TmNYE5LuD cS/032nQ8NUtoL3uLQawhjS+XkM/C07YE5Ml4eh91itsG9Y0DEMVCHmH/BNYvg6q gPcmT+PVS1OYTatjAFAA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 30 Jun 2020 13:15:04 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 976032891.1.37036; Tue, 30 Jun 2020 13:15:04 -0400
Message-ID: <5EFB7359.6030309@isdg.net>
Date: Tue, 30 Jun 2020 13:16:09 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References:  <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com>
In-Reply-To: <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 17:16:19 -0000

On 6/29/2020 9:01 AM, Doug Foster wrote:
> Very creative suggestion.   We need some new ideas.
>
> However, I just checked my MUAs.   All of them assume that "To" is
> unimportant, so it is not displayed in the message list.   "To" only appears
> in the message view (including the Preview pane).    Without more
> visibility, it probably does not sufficiently solve the user interface need.
> Which also suggests why I have not seen spammers try to manipulate that
> field.

I have designed all my MUAs and I presumed all the 3rd party MUAs do 
something similar with a "Message List" view (MLV).

Imeo, this would be one part of a "Recommended MUA Guide" to help 
maximize user viewing security.

First, we have a limited space in what columns to show in a MLV.  In 
TUI (Text User Interface) display, you can correctly assume it will at 
least 80 columns and optionally offer extended 132 columns is 
supported by the terminal.  With GUI, there is more flexibility.

Second, it is not that "To: is unimportant, the mail is mostly likely 
targeted directly to you or to All for groupware environments, i.e. a 
mailing list, NNTP newsgroups, local public or private 
conferences/fora. The designer(s) can choose not to include a "To:" 
column, or decide it is off by default. For GUI, the better ones will 
offer a right click of the MLV table header or via some View Option to 
manage the viewable MLV columns.

Third, our MUA, among others, offer this MLV as a quick way to tag 
multiple messages to mark/unmark as read, delete, move, etc, and also 
sort by column field(s).

Forth, our MUA, among others, also shows a Thread view which is 
"Tree-View" display generated as a function of the Message-ID and 
References: fields.

There are other display views for a MLV, for example, our MUA offers a 
TOPIC view which is basically a thread view linked by the subject and 
date fields or a flat table view with sorted subject/date columns.  It 
helps with the problem where a segment of a thread view is broken by a 
"reply" not having a references id.

This illustrate the multiple TUI/GUI design considerations, allow me 
to summaries what I have to deal with:

For a TUI view, the MLV is showing:

{Mail.Number}
{Mail.From}
{Mail.To}
{Mail.Subject}

and just to show you how limitations under 80 columns and 25 rows 
standard terminal display:

Conference 0 - E-Mail (Internet & Local)
[ 1] Msg:63210 Fm:ANTONIO RICO    To:HECTOR SANTOS   Sb:github wcsdk
[ 2] Msg:49893 Fm:security@bbt.no To:HECTOR SANTOS   Sb:BB&T SECURITY 
SERVICES
[ 3] Msg:49894 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:Re: 
[list-wildcat-beta]
[ 4] Msg:49895 Fm:CNNEarningEdito To:HECTOR SANTOS   Sb:Double Your 
Income... I
[ 5] Msg:49896 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:Re: 
[list-wildcat-beta]
[ 6] Msg:49897 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:RE: 
[list-wildcat-beta]
[ 7] Msg:49898 Fm:list-wildcat-be To:HECTOR SANTOS 
Sb:[list-wildcat-beta] RE:
[ 8] Msg:49899 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:RE: 
[list-wildcat-beta]
[ 9] Msg:49900 Fm:ProjectMgmtTrai To:HECTOR SANTOS   Sb:Project 
Management Trai
[10] Msg:49901 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:Re: 
[list-wildcat-beta]
[11] Msg:49902 Fm:Developers@wins To:HECTOR SANTOS   Sb:[Developers] pxw
[12] Msg:49903 Fm:mrsshirlevine20 To:HECTOR SANTOS   Sb:Donation of 
Mrs. Shirle
[13] Msg:49904 Fm:mrsshirlevine20 To:HECTOR SANTOS   Sb:Donation of 
Mrs. Shirle
[14] Msg:49905 Fm:list-wildcat-be To:HECTOR SANTOS   Sb:RE: 
[list-wildcat-beta]
[15] Msg:49906 Fm:morris.cooper@l To:HECTOR SANTOS   Sb:Indebted for 
driving on
[16] Msg:49907 Fm:group.consultin To:HECTOR SANTOS   Sb:MUTUAL OFFER
[17] Msg:49908 Fm:ad428352916@for To:HECTOR SANTOS   Sb:Fwd: For Sale 
by Owner
[18] Msg:49909 Fm:easyhrsoftware@ To:HECTOR SANTOS   Sb:HR Software
[19] Msg:49910 Fm:sarah@toyska.co To:HECTOR SANTOS   Sb:Canada Goose - 
The Ulti
[20] Msg:49911 Fm:ad428352916@gin To:HECTOR SANTOS   Sb:Reply: Plus 
size fashio
[21] Msg:49912 Fm:incoming@interf To:HECTOR SANTOS   Sb:You have new 
fax, docum
[22] Msg:49913 Fm:FreedomGenerato To:HECTOR SANTOS   Sb:Power 
Companies Caught
[R]ead, [M]ark, [C]ontinue, [N]onstop, [Q]uit? [                    ]

yes, mucho spam!

Wit limited screen dimensions, you end up with truncated field 
displays.  That was the original display we had for TUI.  Based on our 
discussions, I will pencil in a change consideration to not show the 
To: which will extend the FM:. I could put the date here too.  But 
again, we are limited.

For a Native GUI View, it borrowed similar to Windows Explorer display 
views. The default columns are:

{mail.subject}
{mail.From}
{mail.to}
{mail.date}

For the HTML GUI view, the backend renders the following default columns:

Msg#
Date:
From:Subject:
To:
Replies (count)

So it is one 1 table row with a message item displayed like so:

+----------------------------------------------------------------+
|{mail.number}| {mail.from} | {mail.to} | {mail.References.count}|
|             | {mail.subject}                                   |
+----------------------------------------------------------------+

We also have dynamic popup box views as you hover over an line item.

Overall, at best, we COULD and probably SHOULD recommend what the 
default columns SHOULD be from a "better" security standpoint but we 
can not design the MUA UI for the MUA developers which may come in 
different flavors, including TUI and today, "WUI" Watch User 
Interface, etc. It is not something that can be mandated and in no way 
should any protocol be depending on concepts that are generally an 
open-ended. It SHOULD discuss it, so that MUA authors get advice, but 
it will be a difficult attempt to mandate it.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



From nobody Tue Jun 30 10:31:18 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D123A0C86 for ; Tue, 30 Jun 2020 10:31:15 -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, 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 (1024-bit key) header.d=bayviewphysicians.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 xu66MPMXP7s7 for ; Tue, 30 Jun 2020 10:31:14 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE963A0CAE for ; Tue, 30 Jun 2020 10:31:14 -0700 (PDT)
X-ASG-Debug-ID: 1593538272-11fa313a102a2ec0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id gDgb5ZifhYis1ygF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 30 Jun 2020 13:31:12 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=rTWvutChPrnHNFYcJM4CCkXilNemQQM6eUgs9mmGOCY=; b=QgZXisq4/BczMOrHRt0zo50MbBvO+KhQGO19XzSutqekz52P/DbliaTqoa//Xb3lp wZrxyD3AwhXqgJ8hN75W/LDcnKHPGnu8up/WkFXZENmYgFZZEY4HVLeyyAjZw68J7 gYO4ZM4jszJM380QF3mr2ww4pAk3jU1qAd+gxDDws=
Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 30 Jun 2020 13:31:04 -0400
From: "Doug Foster" 
X-Barracuda-RBL-IP: 192.168.2.108
To: "'Alessandro Vesely'" , 
References:  <000001d64e15$5ab947a0$102bd6e0$@bayviewphysicians.com> 
In-Reply-To: 
Date: Tue, 30 Jun 2020 13:31:04 -0400
X-ASG-Orig-Subj: RE: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
Message-ID: <005801d64f04$3b365bd0$b1a31370$@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGMa8Hma/tu7nXkM4xjuH+qsSRkQgIZ9beuAdb/sNapZajHEA==
X-Exim-Id: 005801d64f04$3b365bd0$b1a31370$
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1593538272
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 1397
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82915 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: 
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 17:31:16 -0000

You were partially right.   Outlook allows me to pick columns, but I forgot
that the feature was available.  

 I don't see the feature on two web MUAs or two phone MUAs that I checked.

Doug Foster


-----Original Message-----
From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Alessandro Vesely
Sent: Tuesday, June 30, 2020 4:52 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

On Mon 29/Jun/2020 15:01:07 +0200 Doug Foster wrote:
> Very creative suggestion.   We need some new ideas.
> 
> However, I just checked my MUAs.   All of them assume that "To" is
> unimportant, so it is not displayed in the message list.   "To" only
appears
> in the message view (including the Preview pane).    Without more
> visibility, it probably does not sufficiently solve the user interface
need.
> Which also suggests why I have not seen spammers try to manipulate 
> that field.


Can't you select what fields to display in the folder view?

The Sent folder must look boring if it only displays From:.

How about catchall folders?  Hm...  I though all email clients featured
customizable views nowadays.


Thank you for replying
Ale
-- 





















_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




From nobody Tue Jun 30 10:49:59 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0693A09C9 for ; Tue, 30 Jun 2020 10:49:58 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 g1ecsnL88adH for ; Tue, 30 Jun 2020 10:49:57 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E85F53A0CA2 for ; Tue, 30 Jun 2020 10:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1593539391; bh=OViqWykY8NnYFxjrPO+2ZrOw4kCcNZCGezHptiSi7wo=; l=361; h=To:References:From:Date:In-Reply-To; b=BYeVqpyOThl3asS4YCb+wjnPZQD0CSYkXryG78wPNll/Fr8/JudMbOH2HrOW8+S+t bS1l5hn8DLMRLox2rCfPt0x67xk6r59GBINjmLO/U37Z0wKnkTjQk0hrR894Zj3R9H B2h8dEiKSpCLnvyg3bV1J1CSV09lpwKY8JomXGzJBpJNmnk+JctEGfEkd1PoF
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005EFB7B3F.0000532B; Tue, 30 Jun 2020 19:49:51 +0200
To: dmarc@ietf.org
References: <20200627014455.95A991BBCBC6@ary.qy>
From: Alessandro Vesely 
Message-ID: 
Date: Tue, 30 Jun 2020 19:49:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200627014455.95A991BBCBC6@ary.qy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 17:49:58 -0000

On Sat 27/Jun/2020 03:44:55 +0200 John Levine wrote:
> This makes me wonder how many mailing lists still don't add DKIM
> signatures.


Lists at vger.kernel.org and savannah.nongnu.org are not signed.

There are also some which don't seem to have found a way to deliver valid DKIM 
signatures, such as those at lists.sourceforge.net.


Best
Ale
-- 



























From nobody Tue Jun 30 11:01:03 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC94F3A0C96 for ; Tue, 30 Jun 2020 11:01:00 -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, 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 (1024-bit key) header.d=bluepopcorn.net
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 Wwp3lkr3JmD7 for ; Tue, 30 Jun 2020 11:00:59 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 478C33A0D0A for ; Tue, 30 Jun 2020 11:00:47 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:5030:6f83:2d41:ab09]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05UI0jiP019182 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 30 Jun 2020 11:00:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1593540046; bh=MDnH+eTnCYZOVnLwqyH3Z4vUG/Vix2kcI8lc+4AO+74=; h=Subject:To:References:From:Date:In-Reply-To:From; b=muhYAbfdx5fly6pW1JGND0Q+SoCUc1a7DvA5ppjKYVOaOQwlzgWW/7t7KAu/lCgRe Iv8FSQ3CNSdwdS7pGv2AZl81RZO63BCY/r1gsG6rLPIbHWHcpJ3trvL9f7r+heDRet lw5FY7FnAfcFunDmU+zfZ6WmRrXyrAu3876czDQc=
To: dmarc@ietf.org
References: <20200627014455.95A991BBCBC6@ary.qy> 
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
Message-ID: <01bcdeda-4c0c-8b49-ce0b-ae6c2db23884@bluepopcorn.net>
Date: Tue, 30 Jun 2020 11:00:38 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 18:01:01 -0000

On 6/30/20 10:49 AM, Alessandro Vesely wrote:
> There are also some which don't seem to have found a way to deliver
> valid DKIM signatures, such as those at lists.sourceforge.net.

Yes; they seem to be signing with both sf.net and sourceforge.net, but
neither signature verifies successfully. Wonder why.

-Jim



From nobody Tue Jun 30 11:11:52 2020
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27D73A0A3E for ; Tue, 30 Jun 2020 11:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Z+2WZSSM; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=n/Ylkv6O
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 g6u1V0b-5dXs for ; Tue, 30 Jun 2020 11:11:47 -0700 (PDT)
Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (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 3B21F3A08AA for ; Tue, 30 Jun 2020 11:11:47 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1212; t=1593540700; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VZKDnHEwFPlCl1cI4psTrwtmXoQ=; b=Z+2WZSSMAV9nITpr8i7Ajj5k+x+YjG5ODJmJg4wPud7NbNDDHl+pFmDTR0G6Xh rkbPgfCf+KW+2zsT7lvFXEjQM0mvoOCsysYlxcbm7YlLAJXDwCNrix5qUFH3Namo IWHdPmXadXV9J6QUjpfZ9R3rG66YZqq9/gxmRwiVLgdls=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 30 Jun 2020 14:11:40 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); 
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4267987452.1.5000; Tue, 30 Jun 2020 14:11:39 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1212; t=1593540635; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=il0NK8i bW6/UXDLuDOf1PNI8Y5ukMPsy/Uxfk5WsUYI=; b=n/Ylkv6O1/TB7vNS/C0zDbU R/yrUMShOI0z7z1teowKaWmLv5J+v4Bp0JCansXMqCYYp5yLlff0Z7TlH2IMxDAQ vYmq9RBORf6u35iJtFwDjpQZ9yJmSrpA/DbjcCcDBbAlPI1BsRT3HCzXQapSEQ9s IGc5BirHE6NtwWvI+oCg=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 30 Jun 2020 14:10:35 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 979362719.1.54320; Tue, 30 Jun 2020 14:10:33 -0400
Message-ID: <5EFB805B.5000403@isdg.net>
Date: Tue, 30 Jun 2020 14:11:39 -0400
From: Hector Santos 
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <20200627014455.95A991BBCBC6@ary.qy> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 18:11:50 -0000

On 6/30/2020 1:49 PM, Alessandro Vesely wrote:
> On Sat 27/Jun/2020 03:44:55 +0200 John Levine wrote:
>> This makes me wonder how many mailing lists still don't add DKIM
>> signatures.
>
>
> Lists at vger.kernel.org and savannah.nongnu.org are not signed.
>
> There are also some which don't seem to have found a way to deliver
> valid DKIM signatures, such as those at lists.sourceforge.net.


Not all List Systems (MLM, MLS) have a transport system, so it is left 
for the outbound mail processor (mail router) to handle the signing 
for all outbound mail. That is how our MLS behaves. The MLS only needs 
to control the subscription and submissions process by checking the 
DMARC record for restrictive domains.  Really no code change in MLS at 
all related to DKIM.

Abandoned Legacy MLS many be a problem, but any operator who wishes to 
be part of the DKIM/DMARC era, needs to understand it needs some 
controls with subscription and submission checking.  It doesn't need 
to worry about getting support for the abandoned MLS. He just needs to 
control the entry points like subscription and submission.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos