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

rc at passwall.com rc at passwall.com
Mon May 10 02:47:32 CEST 2021


 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 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 [10.5.9.1])
>   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 [10.5.3.2])
>   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] [14.202.193.218])
>   by ext-mx-in002.kolabsys.com [2] (Postfix) with ESMTPS id 1D8C3EAE
>   for <users at 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/


More information about the users mailing list