From the DKIM header assumed added by your MTA:
"
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;
d=pricom.com.au; s=phr1; x=1620760128; h=MIME-Version:
Content-Type:Content-Transfer-Encoding:Date:From:To:Cc:Subject:
Reply-To:In-Reply-To:References:User-Agent:Message-ID; bh=FmYpFg
8n5qzZwGVS9g1ntm5elRA=; b=oRoLjUkhqBD4I7O17UaQEiwoku0KRuVy5/Ghjb
2HhS4HIQMoPOK7JsinkxKUuK4Ux0XJlJAukaD7uSG61aCadR6kRXurcAtSv8kY79
w6q2PAf/JPofvR1xVpvN4E1MGqM80s9G6fpvHCdzV0fJKRseoFpZZhkSlctcXPFh
95i5E=
"
This implies that your MTA DKIM signing includes all of these in the
computer DKIM value for your messages:
MIME-Version
Content-Type
Content-Transfer-Encoding
Date
From
To
Cc
Subject
Reply-To
In-Reply-To
References
User-Agent
Message-ID
If only this list is showing DKIM validation failure while sending to
you test email say gmail show DKIM validation as working, you should
have all the information you need in order to find the cause.
1) The case where it always breaks.
2) The case where it always succeeds.
3) The same test which can exercise both.
4) Access to compare the results to look for differences
Email a message to the list from the troubled DKIM signing service, and
CC your gmail account which shows DKIM signing works.
To be the most kind to list members, make your test be something that is
on-topic to the list, so it isn't a junk message sent to all list
members, distributing a cost of reading and deleted or just deleting a
test message among many people. (You could imagine the kind of wasted
time if everyone on the list tested DKIM with test messages of no value
to any other members.)
Complete a character-by-character comparison of each of the items your
MTA uses to compute your DKIM sig between the message to the list, and
the copy of the same message you CC-ed to your gmail account. (Subject
is a common place for a message to get marked-up like with adding [RCU]
to a subject. This is often resolved by adding another DKIM sig which
includes those changes, and get used instead of later DKIM.
If every single character (including whitespace tabs vs space, \r vs \n,
etc), extra whitespaces, especially in between strings without previous
spaces and alphabetic characters match for headers specified in DKIM
header for sigs are exactly the same, then 2 sore-spots for you to
investigate which are common sources of problems:
1) The separation between "headers" and "body" : some services will
violate an *implied* process for adding headers to e-mail messages and
"add them at the bottom" between the headers / body separation, which
can sometimes cause problems with dkim validation. (IIRC, the mail RFC
only says header ^Received.* lines must be added at top top in order
they are added, but I don't recall comment for other headers mentioned
in email RFC being required to always be added only to the top. (Other
RFC for other e-mail headers can indicate only adding to top in
chronological order.) Most of the time, MTA and milters will do the
commonly accepted thing and add only to the top, but some do not, and
can break the method used to separate headers from body and break DKIM
eval. It can happen with the last header adding an extra '\n' or adding
a '\r' or other causes.
2) Footers added by lists (and extra characters including whitespaces)
can also break DKIM evaluation of the body, consider copying the broken
message to a text file and run your favorite DKIM validation tool
against the message with the bad DKIM check, removing items or revising
items not included in the gmail received message or change on
list-message compared to gmail message.
The above can usually help a mail admin identify the causes email from
for *their* failing DKIM checks on lists with DKIM checks from other
users are fine. There are other cases for causing problems, but the
above is usually enough to identify most causes. If the above is not
enough, consider possible multibyte charset homograph replacement, and
check for those.
Other tests can be done if you can control the attributes that DKIM uses
to generate a sig, but that "trial and error" approach to diagnosing
problems is usually considered very bad for mailing lists members.
Next, if you are using a 4k key for DKIM signing, that can cause
problems with some older dkim validation tools. 2k seems well supported.
Last, consider changing your dkim hashing ALG from sha1 to one of the
sha2 class of hashing (sha2 or sha256 (a=rsa-sha256;), etc.) (As of the
writing of this message, sha1 has been phased out of many crypto systems
for hashing. In the future, sha2 classes will probably be phased out and
not be suggested.)
HTH you or someone else,
Good luck!
On 2021-05-09 03:34, Philip Rhoades wrote:
People,
My mail server guru sent me the response below when I asked him about
getting error messages when I post to the RCM list - can someone tell
me if his analysis is correct?:
Thanks,
Phil.
-------- Original Message --------
Subject: Re: FW: Re: [RCU] How to Host Multiple Mail Domains (Email
Hosting) in iRedMail Full Featured Linux Mail Server
Your mail got altered at the mail server that received kolabsys.com
[1]?
Authentication-Results: ext-mx-in002.kolabsys.com [2] (amavisd-new);
dkim=pass (1024-bit key) header.d=pricom.com.au [3]
1. When it was received by ext-mx-in002.kolabsys.com [4] from pricom
server 14.202.193.218, your signature was fine and it had passed
2. Something happened on one of these servers (10.5.9.1 or 10.5.3.2)
which altered the message body, after which your signature no longer
verifies.
3. There is no issue with your DKIM-Signature as it verifies on
ext-mx-in002.kolabsys.com [4]
I have cut-pasted the headers from the original mail below
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from int-mx001.kolabsys.com [5] (unknown [10.5.9.1])
by lists02.kolabsys.com [6] (Postfix) with ESMTP id EDDA7746C1
for <[email protected]>; Tue, 4 May 2021 21:13:56 +0200
(CEST)
Received: from mx.kolabsys.com [7] (unknown [10.5.3.2])
by int-mx001.kolabsys.com [5] (Postfix) with ESMTPS id D9A1713C0376B
for <[email protected]>; Tue, 4 May 2021 21:13:56 +0200
(CEST)
X-Orig-Spam-Flag: NO
X-Orig-Spam-Score: 0.001
X-Orig-Spam-Level:
X-Orig-Spam-Status: No, score=0.001 tagged_above=-999 required=4.5
tests=[TIME_LIMIT_EXCEEDED=0] autolearn=unavailable
Authentication-Results: ext-mx-in002.kolabsys.com [2] (amavisd-new);
dkim=pass (1024-bit key) header.d=pricom.com.au [3]
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DMARC-Filter: OpenDMARC Filter v1.3.2 ext-mx-in002.kolabsys.com [2]
1D8C3EAE
Received: from pricom.com.au [3] (pricom.com.au [3] [14.202.193.218])
by ext-mx-in002.kolabsys.com [2] (Postfix) with ESMTPS id 1D8C3EAE
for <[email protected]>; Tue, 4 May 2021 21:08:53 +0200
(CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;
d=pricom.com.au [3]; s=phr1; x=1620760128; h=MIME-Version:
Content-Type:Content-Transfer-Encoding:Date:From:To:Cc:Subject:
Reply-To:In-Reply-To:References:User-Agent:Message-ID; bh=FmYpFg
8n5qzZwGVS9g1ntm5elRA=; b=oRoLjUkhqBD4I7O17UaQEiwoku0KRuVy5/Ghjb
2HhS4HIQMoPOK7JsinkxKUuK4Ux0XJlJAukaD7uSG61aCadR6kRXurcAtSv8kY79
w6q2PAf/JPofvR1xVpvN4E1MGqM80s9G6fpvHCdzV0fJKRseoFpZZhkSlctcXPFh
95i5E=
MIME-Version: 1.0
Links:
------
[1] http://kolabsys.com
[2] http://ext-mx-in002.kolabsys.com/
[3] http://pricom.com.au/
[4] http://ext-mx-in002.kolabsys.com
[5] http://int-mx001.kolabsys.com/
[6] http://lists02.kolabsys.com/
[7] http://mx.kolabsys.com/
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users
