Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

Hector Santos <hsantos@isdg.net> Fri, 23 June 2023 18:13 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3666C13AE25 for <dmarc@ietfa.amsl.com>; Fri, 23 Jun 2023 11:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="JeHIrg8P"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="AAhFE/uA"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuV4IfSSlj4x for <dmarc@ietfa.amsl.com>; Fri, 23 Jun 2023 11:13:48 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [3.137.120.140]) (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) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73145C14CE4D for <dmarc@ietf.org>; Fri, 23 Jun 2023 11:13:48 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=16156; t=1687544025; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Message-Id:Subject: Date:To:Organization:List-ID; bh=jQiaywiixPQUsd0ayPNOsFjdbQ5FlBO E7GkvYSqiLnw=; b=JeHIrg8PAYS4ZlBUfr2JO/M7hCKLwMJzOEq6OGsylFSzLJ0 he8qMPZYY0P9r0FQxV0rh6ohVQ+w20z62ODLxk3w3n2WHOMG+WkOJSdIW0E7/E/z 9qycAzuWeXEFOcPLMEsBNBN7QxHsv9fsKjBVAQchavyi3/cJqsvcx2cy573I=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Fri, 23 Jun 2023 14:13:45 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([3.132.92.116]) by winserver.com (Wildcat! SMTP v8.0.454.13) with ESMTP id 3641742286.1.5740; Fri, 23 Jun 2023 14:13:43 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=16156; t=1687544019; h=Received:Received: From:Message-Id:Subject:Date:To:Organization:List-ID; bh=jQiaywi ixPQUsd0ayPNOsFjdbQ5FlBOE7GkvYSqiLnw=; b=AAhFE/uAlt/t1B/r1k4g55U tUrcv0wcEZncMI7MMZvbnwoWl4EF4uRCulAq3Qcj5mHBW+MmLIYI14zus6nB+5SY IQs1Sb7MGRUDGYaz4xOOtj0NK0mz1KWcC5eCueCR659JOvjBhv2gsWF0OxShrurM INHn+YpVIoKbvpAsxjHI=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Fri, 23 Jun 2023 14:13:39 -0400
Received: from smtpclient.apple ([99.122.210.89]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 4087793552.1.17280; Fri, 23 Jun 2023 14:13:38 -0400
From: Hector Santos <hsantos@isdg.net>
Message-Id: <7A47A241-607B-4E93-B5E3-26E78FE3F166@isdg.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_148C9E3E-C74F-4A36-A67F-F7D6735598DB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Fri, 23 Jun 2023 14:13:27 -0400
In-Reply-To: <bfbe77ad-8aba-d803-de06-d734a177066b@taugh.com>
Cc: Emanuel Schorsch <emschorsch@google.com>, IETF DMARC WG <dmarc@ietf.org>, emgu@google.com
To: John R Levine <johnl@taugh.com>
References: <CABZJ8kmg75qo70V-N65b6C4w+g7gX0ehv3CsqG-765BbBGcn=A@mail.gmail.com> <20230623021810.E5F8DF9B3B94@ary.qy> <CAFcYR_WY8MEag7sup_7DnmzRuZJ7zeyJT6TATL45wCKBrsF3UQ@mail.gmail.com> <bfbe77ad-8aba-d803-de06-d734a177066b@taugh.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/i2uycOcdeKb3kWFCwTtxvNYs4uo>
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 23 Jun 2023 18:13:53 -0000


> On Jun 23, 2023, at 12:52 PM, John R Levine <johnl@taugh.com> wrote:
> 
> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>> I agree with John's point that dkim+spf doesn't make sense in the context
>> of strict DMARC enforcement (I think it provides value for p=none domains
> 
> Since the aggregate reports tell you what authentication worked, I don't even see that as a benefit.  There's also the question how many people would even look at a DMARC v2 tag which would be a prerequisite for the auth tag.

DMARC v1 supports extended tags.  See section 3.1.3 in RFC 7489:

https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3



3.1.3 <https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3>.  Alignment and Extension Technologies

   If in the future DMARC is extended to include the use of other
   authentication mechanisms, the extensions will need to allow for
   domain identifier extraction so that alignment with the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From
   domain can be verified.





> 
> The idea is that auth=dkim means you'd publish SPF records but hope people will ignore them, or vice versa for auth=dkim?  I still don't get it.
> 

The immediate benefit would be forwarders. I believe Wei labeled this form of forwarding REM in the PDF analysis posted recently.

With REM forwarders, in SMTP transport terms, it is a passthru message forwarded to a recorded address given by the local domain or locally hosted domain Recipient , untouched data.  MTA inbound to MTA outbound. The MDA, like gmail.com <http://gmail.com/>, would see an SPF failure so the DMARC auth=dkim relaxed option tells GMAIL that the hard fail with SPF is acceptable, ignore it, but expect the DKIM to be valid from the author signer domain.

Who sets this tag?  The initial sender that unbeknownst to this sender, the MX Is not the final MDA.  We will never know that information of where a contact can be reached.  The Hosted Domain market is very big and important.

So it will be a matter of training system admins that domains with any chance of being indirect, it will probably be a good idea to use a relaxed SPF evaluation for DMARC1.

We will not need a version bump. 

—
HLS