[RCU] [DMARC-Fail] Continuing DKIM problems with RCM servers?

rc at passwall.com rc at passwall.com
Mon May 10 04:52:46 CEST 2021

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: rc at passwall.com
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 

Is not the same as the subject shown in my sent-mail:

"Subject: Re: [DMARC-Fail] [RCU] Continuing DKIM problems with RCM 

(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
users at lists.roundcube.net


Now I save the file with ONLY those described changes, and check the 

$ dkimverify.pl < /tmp/sample_altered.txt
originator address: rc at passwall.com
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") 

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. :-)


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, rc at 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, your signature was fine and it had passed
>>> 2. Something happened on one of these servers ( or
>>> 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 at lists.roundcube.net
>>> Delivered-To: 
>>> users-at-lists-dot-roundcube-dot-net at lists.roundcube.net
>>> Received: from int-mx001.kolabsys.com [5] (unknown [])
>>>   by lists02.kolabsys.com [6] (Postfix) with ESMTP id EDDA7746C1
>>>   for <users at lists.roundcube.net>; Tue,  4 May 2021 21:13:56 +0200
>>> (CEST)
>>> Received: from mx.kolabsys.com [7] (unknown [])
>>>   by int-mx001.kolabsys.com [5] (Postfix) with ESMTPS id 
>>> D9A1713C0376B
>>>   for <users at 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] [])
>>>   by ext-mx-in002.kolabsys.com [2] (Postfix) with ESMTPS id 1D8C3EAE