From nobody Tue Aug 18 14:53: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 86B243A0DD6 for ; Tue, 18 Aug 2020 14:53: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 (2048-bit key) header.d=iecc.com header.b=QLeWpYAs; dkim=pass (2048-bit key) header.d=taugh.com header.b=kqwFp7ne Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OChbFUcuZLuc for ; Tue, 18 Aug 2020 14:53:55 -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 9D17B3A0DD7 for ; Tue, 18 Aug 2020 14:53:28 -0700 (PDT) Received: (qmail 85724 invoked from network); 18 Aug 2020 21:53: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=14eda.5f3c4dd6.k2008; bh=hgzgR/qYQ90vgY2LwmbZ6N0Kaz7IO+B+Y5RwSJSWBGg=; b=QLeWpYAs6k2vq2tYKx60ptf4J33ltRsfJslQdNuKZZkarkwmkrgBJkYVNXSDfyZQevX0lftrv6km96dIP8a+gi5wwHhw2F3wrj93mfzAeTxuo72STCuEVlXHsuggjzGP0wi6NO8w1nQLzjW+4kuMNDv1R+lYfXFtKDOxr9AR/iT3ZJIx00NVNbLAdCwjS/V+dZmri3WkZ56fxaxHuyrTT5or5B8yq9nphlP/wS+GdZd1BMnpB16yOZMZmAUKavEGIgkOie7Xcw2GpcasMyWm3SvIRlExDGfpp9sM8w4r9jbQRrL+FD8NPe44I1fAzbegvdIWKkpMi293/Z6kPpk+7A== 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=14eda.5f3c4dd6.k2008; bh=hgzgR/qYQ90vgY2LwmbZ6N0Kaz7IO+B+Y5RwSJSWBGg=; b=kqwFp7ne/nqn8sqtvrnLfvONxgECrG9XO7OxwT1NOQjnedGcAV9SIRaBEFd4ihJouBnIoOQs7VJSo8tJn6q8MpDZos4eXGf8eN5KpknwqL0+TnkRIdYM8YGeIYo5RctlWsMNURWCgxtZeFC8X6ebMWDCqDhjX/AGhjlPykq6vhk6/OgIFNZZlvWdJ9rUr3dn63MbgUJerz3hM93bY+KulFRtOicOkUjvbjSjitBpnMZwgfdQMSIQvYYmCRI8N4vy8UBetNgzmg21kywV+HqidD0NonyLQrj9deFyNaH9g/YLxU3znPby3MS0cQIge4u0T+X4fXkOD8DhnXo6aHhVKg== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 18 Aug 2020 21:53:26 -0000 Received: by ary.local (Postfix, from userid 501) id 0CCFE1EEC88D; Tue, 18 Aug 2020 17:53:26 -0400 (EDT) Date: 18 Aug 2020 17:53:26 -0400 Message-Id: <20200818215326.0CCFE1EEC88D@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@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] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Aug 2020 21:53:57 -0000 In article you write: >[What to do when From and Sender DMARC have different results ?] > >When I first posed this, the answers I got were along the lines of >"Receivers will do what they want, like they've always done", and that's >certainly true if the behavior isn't mandated in the RFC (and maybe even if >it is). That's cool and all, but doesn't "Receiver's Choice" risk >continued, or perhaps even worse, breakage of the primary problem that this >document is trying to fix? You're right, the sender tweak only makes sense if the sender result is preferred. Otherwise a sender result can only make it less likely that a message is delivered, and that wouldn't be very useful. As always, a successful result doesn't mean not spam, it just means it didn't fail DMARC. I expect some non-normative advice would be helpful, pointing out that this is useful for third party senders, and recipient systems will have to come up with their own idea about which third parties are credible. It occurs to me it's likely to be the same list of third parties whose ARC seals are credible. R's, John