Re: [dmarc-ietf] auth-res vs. dmarc
Todd Herr <todd.herr@valimail.com> Tue, 29 December 2020 17:18 UTC
Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670FC3A148C for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 09:18:19 -0800 (PST)
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 MKJSAACv1Ndj for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 09:18:17 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 4D6D73A148B for <dmarc@ietf.org>; Tue, 29 Dec 2020 09:18:17 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id l7so6621202qvt.4 for <dmarc@ietf.org>; Tue, 29 Dec 2020 09:18:17 -0800 (PST)
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=0cHt5egd57XNr54tEuA6LZovm/cGuOVe4R833qLsu78=; b=gKn24G7TzAeXPnq8kw1rrfRMcCBWaICCkC/PTLTFpY4oXrARmSTswL1AXLOmYaXxNN TLkFZLSVrW8MCEOBC+k+O4RqDFH0kde1GzjbotAm/Z9uRQP3OTlaFsFrME0ryJWtKtv/ vApMqu6z/feJWM/jnzrATsbbFRROFEPLOOALYSGytzSGr5E0/Fkl1n9tZVDzHzlCJz+l KI1//xuCid08pUpGGp4EK71ku465l2AE/KJecD+5XG0p+VfoTSU2U4AGe2mmMHuW7+tE WPRqvdmiFhjKUvZuxBanl4ae+/GZIkd1UwrHRnwniM0+SjJfMacyiV45bRGnaa9gXz0G heIw==
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=0cHt5egd57XNr54tEuA6LZovm/cGuOVe4R833qLsu78=; b=O34Q8i3/rJ1pkRJSHi/6hUOZO2O34Pl90uHGUczejQRDIBBJiohhteP2y5YVBoB60Y dMoJJpNndOxWcBY3nPaJvnwNMM+x9Z+J+vR3OiyUFKwOZnY4j43gG/MqRyHMUoYPtFOe 2On+BiqvWtxrN2Cx17guFoy+wendwfa/MoMI39f288Vu9qTLPvT9vQkYYuB/fYjVVmHP k00VKf0KYZfcNUhXb1ZzoTOup7XIIv3SjayaUeBbzNxrLdG8c5YnyDxITdsB6sf7CTJ4 Q/hVKrxE39yqy4z+qXqxn6/TtZNb0XGyCV2Va7dUQspEQ0h4IO9Xk0ZiTotJ8aT/hQF2 ukdg==
X-Gm-Message-State: AOAM530PBfxArQlD8KAJd/IJo327rBLtjtbt2LVsN5t1Sk37x6IKO111 gpzB+Dc49aEGVgygV2mBwVWIQOcDFqWA4Pn1k0nI9phmMpg=
X-Google-Smtp-Source: ABdhPJweys7V7NglyQX/WJgv0N1Li4EJQMXgHmdOPKPISptE/y4N98ov+M58xnXMZBed2bTmHZkQY6F6nPonsW2cbuo=
X-Received: by 2002:a05:6214:684:: with SMTP id r4mr45747361qvz.54.1609262295843; Tue, 29 Dec 2020 09:18:15 -0800 (PST)
MIME-Version: 1.0
References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <CAHej_8m0OWsTt+tcSgUh+Fxu=HH_57nsb2O1Q_fgA2453ceh4g@mail.gmail.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com>
In-Reply-To: <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 29 Dec 2020 12:18:00 -0500
Message-ID: <CAHej_8mApfoF2ORgL+DoYTanrdhMjvT9H27kORwLKCQc1C9sRw@mail.gmail.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007e969705b79d93c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/JeKbmkVxu55jqmOG-LzKW0GrPKE>
Subject: Re: [dmarc-ietf] auth-res vs. dmarc
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2020 17:18:19 -0000
On Tue, Dec 29, 2020 at 11:38 AM Michael Thomas <mike@mtcc.com> wrote: > Mail from this list is being set to DMARC=fail in the authentication > results even with _DMARC is set to "p=none". My mail provider -- google -- > is the one that is creating that auth-res. I just looked through DMARC and > AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as > "fail". Did I overlook something? > Your use of the phrase "set to DMARC=fail" indicates to me that you are interpreting the Authentication-Results header in ways that are different from my understanding of it. My understanding of the Authentication-Results header is that it captures the results of any authentication checks (SPF, DKIM, DMARC) that were performed on the message. DMARC validation results are independent of the DMARC policy record, in that any validation result (pass, fail, other) is possible for any policy value, even p=none. The intent of the p= value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=none means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check". My feeling is that failure should be reserved only in the case where both > SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI > standpoint is the p= value passed along as well so I can decide to decorate > reject differently from quarantine and none. > A typical domain owner with a non-trivial email infrastructure and an eventual goal of getting to p=reject will start with p=none, and will consume aggregate and failure reports, and will use the data in those reports to address any shortcomings in their authentication practices. Aggregate reports containing DMARC failure verdicts will be quite useful to the domain owner, to ferret out those cases where Mike in Marketing has contracted with a third party to send mail on behalf of the domain, or where Ellen the Engineer has a server running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are properly authenticated before updating the DMARC policy to p=quarantine or p=reject. It's not uncommon for some domains to be at p=none for months, perhaps twelve or more, depending on their mailing practices and cadences before making the switch. Domain owners won't move to p=reject until they're sure that enforcement of such a policy won't have a negative impact on their mail flow. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 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.
- [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Hector Santos
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Laura Atkins
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Douglas Foster
- Re: [dmarc-ietf] auth-res vs. dmarc Kurt Andersen (b)
- Re: [dmarc-ietf] auth-res vs. dmarc Douglas Foster
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Laura Atkins
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Hector Santos
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc John Levine
- Re: [dmarc-ietf] auth-res vs. dmarc Murray S. Kucherawy