IETF Logo Mail Archive

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

Todd Herr <todd.herr@valimail.com> Thu, 21 March 2024 14:15 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 AE3CFC1519B7 for <dmarc@ietfa.amsl.com>; Thu, 21 Mar 2024 07:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (2048-bit key) header.d=valimail.com
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 S0uE6OQLyzVC for <dmarc@ietfa.amsl.com>; Thu, 21 Mar 2024 07:15:17 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 A4496C180B57 for <dmarc@ietf.org>; Thu, 21 Mar 2024 07:15:17 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-dcc7cdb3a98so977140276.2 for <dmarc@ietf.org>; Thu, 21 Mar 2024 07:15:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1711030516; x=1711635316; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=XZhwAw0ZUJ4QEHsOxtJaTYef1Q4A8tRGdJl6bq99k2k=; b=GA4rTr0I4y8XJN2VEvux2xPAqe/WCC2m3uTdz24YfwRLDSLovMaawDZhMZ7mm7RxzO SYVWSQPkGfCEWx3q+k1BL6b4H8KovlV6T9M2HvQLj2v62LRmEckQzOzA93D4PRepvZ0a 9JObb9WZ/f6Et+mwp1jJErbZ1DiAmJo1eOygqgpFEqQz7FGNUsNEjngicEUSHQ2qwW1+ MH2KURQGobATbRp2C6w+h7yNJGUo4arsqJ5QEKYusfv7XgQWhUcarGlOB5BFyezTCx8r rIBfuWYPBury6n+K4VqY1kv60XDpH+mNm+7zvg+9ckswpiyon5aDUoKpIk6qNsiaWLIj qQLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711030516; x=1711635316; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XZhwAw0ZUJ4QEHsOxtJaTYef1Q4A8tRGdJl6bq99k2k=; b=vXZTcAFfXrPc2dwHHXP7x1AG6mzcClvL4KU6jUAyFbAG1ogGzV3fT36TQR2XqN1368 1q7014IyT5o6C3Yw3ZsqyhDKiEwMCoJIyZBxJZm46TlTI1WjJf/OQXuMipFY2HO7xQHS gmwWWpUJNX5dx+1dW3Y1FMha0fLaXBiCUFJbRQDeSABr0Sj+KLKp+FZWwy9zGYtuux0M Gw3HBlKfvyjcfQGDC2z29emPIXKzgG6YLu054VPo2daZ6dPVNevimn9Oov4tAKDg+Uzp POrZO87j7Y6g2tVjW3p5nlRMVPdFOWo8nGRtKY2jsXBRkq77Inerh6gdC6vgN4sN8QT9 OEJQ==
X-Gm-Message-State: AOJu0YxeEFaMaSKy7UYvTA0yQSW6qG8TS1VMe2D9fe5tjvdwxAtcjLBl C3o3AOJbrSMoHFY2K8vqv51chBV4XPPe9XhRG0qpBQ8v2X/nzBnF9ECuXZny/mKTV3tEKkzfQWT FhekArhj4jCF/X8/dUVapKHRiJKd9KUtxhvryqMz4hDPSHGhKf9c=
X-Google-Smtp-Source: AGHT+IEL4e+peWXBnN72oF6hTetvzarOZknymMgDzJ8GgwIxaMH3wt54WOlBALjpx6FLxXCLiC5HtOjuOWQKaIpYwfQ=
X-Received: by 2002:a25:aaae:0:b0:dcf:464d:8ec3 with SMTP id t43-20020a25aaae000000b00dcf464d8ec3mr19928912ybi.3.1711030515965; Thu, 21 Mar 2024 07:15:15 -0700 (PDT)
MIME-Version: 1.0
References: <27cf610e-8666-410c-b015-6c33478af9b4@tana.it> <d959df28-efae-41df-a760-95adf48f5d91@wander.science> <8acac3b8-4529-4c21-b7a4-462564199db4@tana.it>
In-Reply-To: <8acac3b8-4529-4c21-b7a4-462564199db4@tana.it>
From: Todd Herr <todd.herr@valimail.com>
Date: Thu, 21 Mar 2024 10:15:00 -0400
Message-ID: <CAHej_8m6MFQ9m5U+=iHeL9MiXno3LF80=rsbKv0c99_24yo2Qw@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001ac04406142c5631"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/x8u0eGBxRnbBgd53KAibGlDYKJc>
Subject: Re: [dmarc-ietf] DMARC result for DKIM testing and policy
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: Thu, 21 Mar 2024 14:15:21 -0000

On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote:
> > Alessandro Vesely wrote on 2024-03-20 15:42:
> >> what is the result of DMARC on having, say
> >>
> >>      dkim=pass (testing key)
> >> or
> >>      dkim=policy (512 byte key)
> >>
> >> is that akin to SPF neutral, i.e. dmarc=fail?
> >
> > dkim=pass results in dmarc=pass (if the domain is aligned). The comment
> in
> > brackets is for human eyes and does not change the DMARC result.
>
>
> For t=y, DKIM says:
>
>        y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
>           from Signers in testing mode differently from unsigned email,
>           even should the signature fail to verify.  Verifiers MAY wish
>           to track testing mode results to assist the Signer.
>
> So reporting dkim=pass for testing keys seems to be a violation.
>
>
> > dkim=policy is like spf=neutral, i.e. dmarc=fail.
>
>
> Agreed.  Should that be mentioned in DMARCbis?
>
>
I don't believe there's any need to discuss this topic in DMARCbis.

DMARCbis, in section 4.1, DMARC Basics, says:

===============================================================

A message satisfies the DMARC checks if at least one of the supported
authentication mechanisms:¶ <#section-4.1-3>

   1.

   produces a "pass" result, and <#section-4.1-4.1.1>
   2.

   produces that result based on an identifier that is in alignment, as
   described in Section 4.4 <#identifier-alignment-explained>.

===============================================================

If there's anything to say about reporting a DKIM pass result for DKIM
signatures where t=y exists and its possible ramifications for DMARC, then
I believe that's something for an update RFC 6376 to address.

-- 

Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.herr@valimail.com
Phone: 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.

v2.23.0 | Report a Bug | By Email