Re: [dmarc-ietf] auth-res vs. dmarc
Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 30 December 2020 01:30 UTC
Return-Path: <dougfoster.emailstandards@gmail.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 8035D3A0D9B for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 17:30:53 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 4pd1iVXEQVR9 for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 17:30:51 -0800 (PST)
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 719873A0D99 for <dmarc@ietf.org>; Tue, 29 Dec 2020 17:30:51 -0800 (PST)
Received: by mail-vk1-xa2f.google.com with SMTP id m145so3346379vke.7 for <dmarc@ietf.org>; Tue, 29 Dec 2020 17:30:51 -0800 (PST)
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=GzMkzgWpf+iIhWZ91NVF7t6OqfII0poo7yYwisFEqis=; b=ZpP9Y9WQqnbEEvGfBvFkNdoSfa2PmpQ5hXXwmI4aE4cWxt1Uk8pMRVEDKg41VhWtk9 f+S/W7zJ8EZsGhDsb5efqbuzAZDOY0cS1+vnBxEZINaKJajInCwryzsJgeFclp6sU8O0 XLOTHEhxNYfgVRn+3gQK1+EuAQRUScQzh0u2tOmtNiKEXFKcWYFiAa5ReaxOj5TqmiiN 216/e61ukORCQq/PQq1tsN3SrdbeLZHbvvUrEya/EmIodMHYn6s9QRznYN//L/0mW4LW +J8AtpmB8HeAUjaOPuaRWuP0pA1JJ5CpfyQTY4fsRmZs13y6gcsmCjLhLUYykyfooTdf fYng==
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=GzMkzgWpf+iIhWZ91NVF7t6OqfII0poo7yYwisFEqis=; b=srHhECN6o0dxodUv0GUaak+e0YDAgqggEJBaqBaT2byxSvW40LpHxX3FXNfjhYd5hU V2Hf/y2zM7gcI6M0UsRh2wCYWqlbF5xaIVZU8aK0Sxu0xgcyVUlC4n+LnmzsjjzKm2UX XfuwyrKgJRNV1ZJyFHtWd+8MhlwK0AIj2w9/xEGR+P3/0/zXa3OpGxm6e27MKsXkpfAF SXEGtSdMXxar1HzSr4NaiQMZhTiWj1SjucwD+cLZK/5FStYPoGvOL6F0Rj+UbMT60XRV 1hrGu0s+Krd+989dca+oqLawfiQ82gUHO8oVeieOtFevg6nwlJMBIhLtAtRaBQDhliZm RkeQ==
X-Gm-Message-State: AOAM530UMRWKbU4iACxoXCABrxCfhJBaK+rIrTAOfvxeRWbvFyP0FDq/ VM2W7h2KZOKmtUBzXZqqIZgLdPaC+Vvwdf2r5k5cK9aZcbU=
X-Google-Smtp-Source: ABdhPJzadgJeAbOxUzxu2v4kCzKd/CCrQvuSXKmaBmf01MWjVz3YqZ3yplNE+IjM/1cofQCULdWJp5LV3OZLyfCreoM=
X-Received: by 2002:a1f:20d1:: with SMTP id g200mr32696240vkg.25.1609291850221; Tue, 29 Dec 2020 17:30:50 -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> <CAHej_8mApfoF2ORgL+DoYTanrdhMjvT9H27kORwLKCQc1C9sRw@mail.gmail.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <CAHej_8=kW_t_JkOxUud1Uz8+PrbMh5CfwfxZK=mhe0wjW8wQpw@mail.gmail.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <CAHej_8kCi=7oqojDH_rbjn7kRg-PTDJWLgcKTGK9z-baUnKeMw@mail.gmail.com> <ef32de1e-d47e-1d0f-3cec-5994c7fdb7ae@mtcc.com>
In-Reply-To: <ef32de1e-d47e-1d0f-3cec-5994c7fdb7ae@mtcc.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 29 Dec 2020 20:30:40 -0500
Message-ID: <CAH48ZfyxXz-2Wpwmzi+mW_KSS0aS06+yiEOk3YB_UrOKdcsQjA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001293c005b7a47581"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Sle1paFFhaccYUY4n9uTJWo_s2I>
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: Wed, 30 Dec 2020 01:30:54 -0000
I understand that Authentication-Results are intended for use within a single organization, since any assertion by an outsider could be malicious. Since IETF does not apply ARC Sets, we are using A-R as a proxy for what might be possible with ARC, but the two are different. I still see a problem with ARC or A-R. These headers assert, "These attributes had these statuses values when I saw them," but they do not reliably indicate when that look was performed. The typical message header set provides a list of address identifiers which have little connection to servers, and a list of server identifiers which have little connection to the address identifiers. Consider these results from a sample message from this list. They are presented in the order that they appear in the message headers (top might be newest.) The first two are A-R and the bottom one is ARC-A-R: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d= comcast.com ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d= comcast.com; arc=none The bottom one tells me that an authenticator identified as " mx.microsoft.com 1" saw an SPF Pass, but I don't know what IP address it authenticated, and I don't know when this occurred. There are no Microsoft.Com servers in the Received header list, and the Auth-Ident is not intended to convey a server or domain identifier. The bottom entry says that the message passed DKIM, but the second entry tells me that there are no signatures at all, yett the third one assures me that the signatures have suddenly reappeared and are verifiable. DKIM, A-R, and ARC should all have a mandatory attribute indicating the HELO name of the server applying the header, the IP Address of the previous server which supplied the information being evaluated, or both. Without a link between the address identifiers and the server identifiers, I don't see how a viable algorithm can be constructed to use the data. Message forwarding provides so much opportunity to confuse the spam filters that I am surprised that the bad guys do not use it extensively. DF On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas <mike@mtcc.com> wrote: > > On 12/29/20 11:35 AM, Todd Herr wrote: > > None of the validation checks bothered with the p= value in the > mrochek.com DMARC policy record, because the p= value is immaterial to > the validation check. Whether DMARC passes or fails is based on whether SPF > or DKIM passes or fails with an aligned domain, full stop. > > Once the DMARC validation result is determined, then the mailbox provider or entity performing the DMARC validation check can refer to the p= value in determining how to dispose of the message, but it doesn't have to. It's worth noting perhaps that Google does record message disposition in the auth-res header, though: > > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com > > Unless those values in parens are a MUST requirement, the dmarc=fail is > highly misleading. I haven't even seen any specification for the dmarc part > of auth res in rfc 7601, which may be part of the problem. I don't see any > normative language which would update rfc7601 in dmarc with the syntax and > semantics of the dmarc field. > > At the very least this needs to be straightened out because auth-res, to > Ned's earlier point, can have consumers in the form of MUA's. > > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [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