Re: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal)

Matthäus Wander <mail@wander.science> Tue, 01 August 2023 18:22 UTC

Return-Path: <mail@wander.science>
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 E02BBC151539 for <dmarc@ietfa.amsl.com>; Tue, 1 Aug 2023 11:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.199
X-Spam-Level:
X-Spam-Status: No, score=-7.199 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, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 (2048-bit key) header.d=wander.science header.b="E35nxpx8"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wander.science header.b="kA8je9Wy"
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 HdiBnCfvNK-o for <dmarc@ietfa.amsl.com>; Tue, 1 Aug 2023 11:22:38 -0700 (PDT)
Received: from mail.swznet.de (cathay.swznet.de [IPv6:2a01:4f8:13b:2048::113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44FFC14CF17 for <dmarc@ietf.org>; Tue, 1 Aug 2023 11:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=2023-05-rsa; h=Subject:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:MIME-Version:Date:Message-ID:Cc: Sender:Reply-To; bh=L7HGpDkdEBVSWRWH4mnb5eynFfM67+LtxNi8XmBhoV4=; b=E35nxpx8K faNlYgnW1B87EJXO3moy3P13mqvyNO3kGZnSMg4s8VbnbfQ9axo3uyPKo08sqbAOJExMaI3TvF6bj SznDZB6UNbK2x+e9zfD9qpbOVzFqH+zlMANxNUfh3HYCeAW0D78MQkaX9UNTxwR5pz+lj7KC9C3+W TtAzZVZz05quOEy3ObLcRo46iVSvAmBTO+FApcGWb/18ZLwaD4awRTAW9zT5M/lIzUjl0eBZOs/MQ jYp+8lss5FTav7TbP0IkqZgsqlIdxPqKSQtM7Deeb6MveXZcvP6ALV5UDm6wuujtQmdYgBWrbQNKv 16f32iDAN7UWWPEoiG2vc0Nlw==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=2023-05-ed25519; h=Subject:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:MIME-Version:Date:Message-ID:Cc: Sender:Reply-To; bh=L7HGpDkdEBVSWRWH4mnb5eynFfM67+LtxNi8XmBhoV4=; b=kA8je9WyA eZqpScskcQxUCmQXN0nnsjSmpiwthZIPfjk4L/VxN9DilGht7Cxqn+cC4tStTf3DB/zQXRcGQKFAw ==;
Received: from dynamic-2a02-3100-3168-f000-1cb0-b9a8-2c3f-04a4.310.pool.telefonica.de ([2a02:3100:3168:f000:1cb0:b9a8:2c3f:4a4]) by mail.swznet.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <mail@wander.science>) id 1qQu0v-003v75-W2 for dmarc@ietf.org; Tue, 01 Aug 2023 20:22:36 +0200
Message-ID: <0ed79c9e-05cd-449d-d208-a02cac5c3511@wander.science>
Date: Tue, 01 Aug 2023 20:22:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
To: dmarc@ietf.org
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <dd0661c0-e476-62b4-fe7a-8ec4d1a62818@wander.science> <1464307464.1412046.1690190449708.JavaMail.zimbra@univ-grenoble-alpes.fr>
Content-Language: en-US
From: Matthäus Wander <mail@wander.science>
In-Reply-To: <1464307464.1412046.1690190449708.JavaMail.zimbra@univ-grenoble-alpes.fr>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a02:3100:3168:f000:1cb0:b9a8:2c3f:4a4
X-SA-Exim-Mail-From: mail@wander.science
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on mail.swznet.de)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/aA5PuTV1OPdY_hhVJkB14UKA_RI>
Subject: Re: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: 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: Tue, 01 Aug 2023 18:22:43 -0000

OLIVIER HUREAU wrote on 2023-07-24 11:20:
>  > c) There is a pattern of similar looking reports, which omit the <dkim>
>> element in the <auth_results> altogether and always report
>> <dkim>fail</dkim> in the policy result. I suspect a product, which makes
>> it a bit too easy to enable DMARC validation without also enabling DKIM
>> verification, but I wasn't able to identify the product yet.
> 
> [...]
> 
> According to XML definitions, the position cannot be swapped and 
> theDKIMAuthResultType (if there is one) must appear before the 
> SPFAuthResultType.
> However, some reporter does not follow this implementation.
> 
> E.g: the no longer maintained Linkedin dmarc-sys :
> https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240 <https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240>where SPFAuthResultType appears before DKIMAuthResultType.
> 
> Are you talking about the same error?

Good catch. These are two different issues, though.

In the issue I mentioned, the mail receiver performs DMARC validation 
and sends an aggregate report, but does not perform DKIM verification 
even though the mail has a DKIM-Signature.

I think the following screenshot offers an explanation of what causes 
the issue:
<https://dmarcian.com/wp-content/uploads/2023/02/Cisco-ESA-Maal-Flow-Policies-update-defaults-1024x611.png>
The admin GUI of a mail gateway offers the option to deactivate DKIM 
verification (next to DKIM signing), thus some people click it by 
accident or by lack of understanding. Not an issue that can be fixed by 
the DMARC spec.

Regards,
Matt