Re: [dmarc-ietf] auth-res vs. dmarc

Laura Atkins <laura@wordtothewise.com> Tue, 29 December 2020 18:07 UTC

Return-Path: <laura@wordtothewise.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 6B8B03A03FA for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 10:07:53 -0800 (PST)
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 JFhASYKMlnmp for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 10:07:51 -0800 (PST)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE783A03F8 for <dmarc@ietf.org>; Tue, 29 Dec 2020 10:07:51 -0800 (PST)
Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 418A69F149; Tue, 29 Dec 2020 10:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1609265270; bh=ezMbtrYet42mkpYxiw5+SGroJ596aik4ooFgTpijfN8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=YnTpRIoZw3csm3XfKpOchebL5sKqOKjyp52zeornhQBu7gYTOXc/AZFTwFHPYs6pX 4TvIGZCSbojY+5q3t9ecRUrxX4yNqD13MOLi8f8PbORUKPtdpvT+ZhqvIDZa8VDEKx 67XA1EJlwOhiGqf9NbtK58fqJoLBK8NFbEXgGxEw=
From: Laura Atkins <laura@wordtothewise.com>
Message-Id: <BE4F8EF2-A6F8-4759-B3BF-D7A299FD61A6@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F50B907-B64E-4831-B675-CE32F5275EB5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 29 Dec 2020 18:07:47 +0000
In-Reply-To: <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com>
Cc: dmarc@ietf.org
To: Michael Thomas <mike@mtcc.com>
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> <CAHej_8mApfoF2ORgL+DoYTanrdhMjvT9H27kORwLKCQc1C9sRw@mail.gmail.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/RVCxZRqeK6fYNbhDATMDYKHMz1w>
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 18:07:54 -0000


> On 29 Dec 2020, at 17:48, Michael Thomas <mike@mtcc.com> wrote:
> 
> 
> 
> On 12/29/20 9:18 AM, Todd Herr wrote:
>> 
>> 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".
> Right, but that is not what Google at least is doing  in their Auth-res. It's marking it as DMARC=fail. I think the issue is with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me.
> 
RFC 7489 specifically says that if the domains don’t align then the mail fails DMARC. 

   5.  Conduct Identifier Alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks to see
       if Authenticated Identifiers fall into alignment as described in
       Section 3 <https://tools.ietf.org/html/rfc7489#section-3>.  If one or more of the Authenticated Identifiers align
       with the RFC5322 <https://tools.ietf.org/html/rfc5322>.From domain, the message is considered to pass
       the DMARC mechanism check.  All other conditions (authentication
       failures, identifier mismatches) are considered to be DMARC
       mechanism check failures. 

> Maybe Murray can chime in here.
> 
>> 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.
>> 
> In the mean time, it would be nice for MUA's to be able to do their part with annotating mail. DMARC=fail is really unhelpful with p=none.
> 
But, the mail fails DMARC because the domains don’t align. 

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