As this list adds/ensures "[RCU]" is in the subject, that's at least one
component that's changing. It also appends the mailing list signature as
a footer to the body which changes that too.
I should have dkim on my mails, so I'm curious now how mine's configured
too as I don't see failures with various lists.
Steve.
On 10/05/2021 01:47, r...@passwall.com wrote:
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: users@lists.roundcube.net
Delivered-To: users-at-lists-dot-roundcube-dot-...@lists.roundcube.net
Received: from int-mx001.kolabsys.com [5] (unknown [10.5.9.1])
by lists02.kolabsys.com [6] (Postfix) with ESMTP id EDDA7746C1
for <users@lists.roundcube.net>; 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 <users@lists.roundcube.net>; 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 <users@lists.roundcube.net>; 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
users@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
users@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/users
