For this mailing, list, when the Subject line is changed and some
headers added, and footers added, it appears the list service computes a
new DKIM validation sig using its own key. (This makes sense.)
Extracting my complete message (which you just replied to) as a file
(copying from a Maildir store the file for my message that you replied
to) and making no changes to it, running a really simple CLI DKIM
validation script:
$ dkimverify.pl < /tmp/sample_original.txt
originator address: [email protected]
signature identity: @kolabsys.com
verify result: pass
signature identity: @passwall.com
verify result: fail (message has been altered)
sender policy result: neutral
author policy result: neutral
ADSP policy result: neutral
Notice the top DKIM validation by identity "@kolabsys.com" passes DKIM
check, but the later DKIM (lower in the list of headers) completed by my
MTA using identity "@passwall.com" reports "fail (message has been
altered)" : This should not be a problem for most filters and MTA. The
most recent DKIM (top in header) is what should be checked. (Again, that
concept of most recent headers added "should" (by common practice, not
by RFC) be added to the top.)
But, can I alter the file (message) to make it pass DKIM validation for
my MTA DKIM (identity "@passwall.com") sig if I make a few changes, and
if so, what are they?
$ cp /tmp/sample_original.txt /tmp/sample_altered.txt
First, a local milter on my system and an anti-span service are both
configured to alter the Subject line of incoming email. In this case, my
local service reports DMARC fail probably because SPF issue because my
spam filter service provider does not connect to my MTA using the
allowed IP address ranges, so the subject of the message the mailing
list sent back to me:
"Subject: Re: [RCU] [DMARC-Fail] Continuing DKIM problems with RCM
servers?"
Is not the same as the subject shown in my sent-mail:
"Subject: Re: [DMARC-Fail] [RCU] Continuing DKIM problems with RCM
servers?"
(This subject change should NOT be a problem when checking DKIM
validation using the list-provided sig. What I am doing here is just for
illustration purposes to try to reconstruct enough of the message my MTA
signed to get DKIM validation against my MTA DKIM (identity
"@passwall.com") sig show as "pass".)
The message I sent did not include these footer items in the DKIM sig I
made, so I will remove these list-added items. (The list DKIM sig did
include them, which is why that test passed. This is still not a
problem. I'm just trying an exercise to illustrate reconstruction of
enough of the old message to validate dkim.)
"
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users
"
Now I save the file with ONLY those described changes, and check the
ALTERED file:
$ dkimverify.pl < /tmp/sample_altered.txt
originator address: [email protected]
signature identity: @kolabsys.com
verify result: fail (message has been altered)
signature identity: @passwall.com
verify result: pass
sender policy result: neutral
author policy result: accept
ADSP policy result: accept
This makes sense, yes? Now that I altered the message to change the
subject used by the list DKIM (identity @kolabsys.com) sig, and removed
the footer the list added and included in its DKIM sig, the *list* DKIM
sig no longer passes, but now my MTA DKIM (identity "@passwall.com")
passes.
Because the DKIM signing process is closer to a hash, knowing *what*
parts may have changed if you only have the altered copy is difficult.
If you have "what was sent" and "what came from the list" you have a
huge advantage at seeing differences.
To be clear again, I am not asking for a change to be made to this list,
just trying to provide "value added content" to describe what happens
when footers are added and headers (like subject) are changed. Maybe
when it is archived, a search engine will index it, and provide help to
someone else. :-D
Feel free to provide corrections or revisions to the above content with
your own replies. Constructive criticism is welcome. Improve the answers
to help future users. :-)
HTH
On 2021-05-09 19:06, Steve Wilson wrote:
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, [email protected] 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: [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
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users
