On 2023-09-29 at 12:41:42 UTC-0400 (Fri, 29 Sep 2023 12:41:42 -0400)
Mark London <m...@psfc.mit.edu>
is rumored to have said:
Hi - Can anyone tell me why the following email header triggered
DKIM_SIGNED and DKIM_VALID, yet I don't see a DKIM header line?
Unlikely. That would probably require an unmodified copy of the full
message, a copy of your full config, and more detail about the
environment...
SA shouldn't hit DKIM_SIGNED with any message lacking a DKIM signature.
Obviously. A definitive answer to *WHY* it did in this case would
require the ability to replicate the behavior. If you cannot replicate
the error with observability, there is little hope of explaining it.
Strangely, if I run spamassassin from the command line on the message,
DKIM_SIGNED is not triggered. SpamAssassin version 3.4.6
Oh. So you've let a piece of security software go most of year after the
explicitly final update to your version and the release of a new major
version?
That is not robust praxis.
SA 4.0 includes a lot of fixes. No specific bug or change comes to mind
that could have caused this, but it isn't beyond imagination.
(Note, I truncated the X-Spam-Level header, as I have some customized
rules.) Thanks. - MARK
Received: from SRV-EXCHANGE.sdis58.local
(static-css-csd-160189.business.bouyguestelecom.com [176.162.160.1
89])
by simplerelay.pulsation.fr (Postfix) with ESMTPS id
644B1203A3E3;
Fri, 29 Sep 2023 04:56:31 +0200 (CEST)
Received: from simplerelay.pulsation.fr (simplerelay.pulsation.fr
[80.74.64.73])
by psfcmail2.psfc.mit.edu
(8.15.2/8.15.2/Debian-22ubuntu3) with ESMTP id 38T31Prc585381
for <x...@psfc.mit.edu>; Thu, 28 Sep 2023 23:01:25 -0400
Received: from SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0])
by
SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0%5]) with mapi
id
15.01.2507.032; Fri, 29 Sep 2023 04:56:20 +0200
Received: from SRV-EXCHANGE.sdis58.local (192.168.20.11) by
SRV-EXCHANGE.sdis58.local (192.168.20.11) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.32; Fri, 29 Sep 2023 04:56:20 +0200
Received: from psfcmail2.psfc.mit.edu ([unix socket])
by psfcmail2.psfc.mit.edu (Cyrus
3.4.3-dirty-Debian-3.4.3-3build2) with LMTPA;
Thu, 28 Sep 2023 23:01:27 -0400
Reply-To: <mrslerynnewes...@gmail.com>
From: "Louis LASTELLA" <louis.laste...@sdis58.fr>
To: "Louis LASTELLA" <louis.laste...@sdis58.fr>
Subject: RE: GRANT
Date: Thu, 28 Sep 2023 20:56:19 -0600
Message-ID: <c82e0c31791246b580568c693b8ed...@sdis58.fr>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0AB3_01D9F291.A3EE6670"
X-Mailer: Microsoft Outlook 16.0
X-Cyrus-Session-Id: cyrus-1695956487-582568-1-13949929973302507258
X-Sieve: CMU Sieve 3.0
X-Spam-Level: 5.61 (*****) DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU ...
X-Scanned-By: MIMEDefang 2.84
Indicating that this instance of MD is also substantially outdated and
obsolete... However, the updates to MD since 2.84 are unlikely to be
directly related to SA doing weird things.
However, as use of MD suggests the potential for elaborate manipulation,
I would also suggest a close examination of the mimedefang-filter file
to see if maybe it's doing something like stripping DKIM headers out of
forwarded messages. (no *evidence* of that, but MD is capable of such
violence if you compel it.)
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
