MDaemon Technologies, Ltd.

Scott

4/11/23, 10:27 AM

DKIM Logfile shows the following: Result: -23 (could not sign)

Does anyone know what this result code represents?

If the error is truely "could not be signed", does anyone have ideas how to troubleshoot this issues? Possibly enabling detailed logging?

Are there any document(s) showing all possible result codes and how to address these issues?

29
Posts

1k
Views

A

Arron Staff

4/11/23, 10:58 AM

Are other messages being signed correctly for the same domain?

Is the domain the message is from a local domain?

Is the message that is not being signed a mailing list message?

In MDaemon under Security / Security Settings / Sender Authentication DKIM signing:

1. is the box checked to sign mailing list message?

2. Is the box checked for All messages from local domains are eligible for signing?

3. If you click define which messages are eligible for signing, what if any information has been specified?

Can you post the entire log snippet that resulted in the (could not sign) message?

S

Scott

4/12/23, 12:27 PM

I found the issue. It appears my ISP didn't accurately update our DNS record. Once that was completed, we retested and DMARC is working correctly.

However, the message line I posted previously indicated "DKIM Logfile shows the following: Result: -23 (could not sign)" was confusing even after DMARC was corrected, becuase there isn't a message anywhere in the log indicating the message was succefuly signed. The only message now are indicating LOCAL message are not be singed; which is correct.

Is there a flag in Mdaemon to allow succefully signed messages to the log?

Also, is there any documentation describing Result Codes (i.e. Result: -23)?

S

Scott

4/14/23, 8:14 AM

Any answers/thoughts regarding the last two questions?

A

Arron Staff

4/14/23, 9:49 AM

An incorrect DNS record should not prevent MDaemon from signing local messages. It would cause the verification of DKIM signatures to fail.

There is no setting that I am aware of to enable/disable the logging of messages being successfully signed.

A successful signing will be in the DKIM log and look like this:

Fri 2023-04-14 09:36:23.912: Performing DKIM signing (thread-ID: 11288)
Fri 2023-04-14 09:36:23.912: * File: E:\mdaemon\queues\local\md3501000154358.msg
Fri 2023-04-14 09:36:23.913: * Work file: E:\MDaemon\CFilter\WORK\1756925808\pd912414823.tmp
Fri 2023-04-14 09:36:23.917: * Message-ID: <WC20230414143615.870293@mdaemon.com>
Fri 2023-04-14 09:36:23.917: * From: arron.caruth@mdaemon.com
Fri 2023-04-14 09:36:23.917: * Selector: mail
Fri 2023-04-14 09:36:23.917: * Domain (d=): mdaemon.com
Fri 2023-04-14 09:36:23.917: * Result: 0 (signed ok)

If there is nothing being logged about a message being successfully signed, then my first thought is that they are not being signed. But I can't tell for sure, because I don't have enough information. If you send a test message to an email address outside of MDaemon, does it contain a DKIM signature?

There is no documentation explaining the result codes.

S

Scott

4/14/23, 10:45 AM

When I send a test message from the server to my GMail account, then using the (...), to open using "Show Original" the status of the DMARC is "PASS".

This and other messgae like this, do not show up in the log (as you showed as an example) as sucessfully signed, nore do they show as an error.

As far as DNS, when we reviewed the DKIM entry before and then after it was corrected, DMARC status changed to PASS.

The proof of a correctly signed email is in the DMARC status (from what I understand). If we pass, then everything from the MDAEMON server to GMAIL is working correctly. Right?

A

Arron Staff

4/15/23, 7:53 AM

A DMARC result of pass does not indicate that a message was successfully signed.

In general DMARC will show a result of pass if the message either passes SPF or if the message contains a valid DKIM signature and the domain that signed the message or the domain that passed SPF matches the organizational domain of the FROM header. For example, if a message passes SPF for mydomain.com and the FROM header contains user1@mydomain.com, the message, in most cases, will pass DMARC without a DKIM signature. Its only in most cases, because you can set your DMARC policy to require a DKIM signature, but most people do not.

To verify the message includes a DKIM signature, when viewing the original message in gmail, scroll down to the actual message headers and look for the DKIM-Signature: header. If you find it, look in the value for the header and find the d= value. Make sure the domain in the d= value is your domain.

S

Scott

4/17/23, 10:49 AM

Per your suggestion I reviewed the outbound queue and found the header (below) with 8 (approx.) lines.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

The Mdaemon DKIM log show both our internal *.local and external *.com mail being signed correctly

Mon 2023-04-17 11:28:27.782: Performing DKIM signing (thread-ID: 48720)
Mon 2023-04-17 11:28:27.782: * File: j:\mdaemon\queues\local\md3501000116322.msg
Mon 2023-04-17 11:28:27.782: * Work file: C:\MDaemon\CFilter\WORK\2116921066\pd313044604.tmp
Mon 2023-04-17 11:28:27.788: * Message-ID: <MDAEMON-F202304171128.AA2825371md5001000100942@mail.***.local>
Mon 2023-04-17 11:28:27.788: * From: ****@**.local
Mon 2023-04-17 11:28:27.788: * Selector: MDaemon
Mon 2023-04-17 11:28:27.788: * Domain (d=): ***.local
Mon 2023-04-17 11:28:27.788: * Result: 0 (signed ok)
Mon 2023-04-17 11:28:27.788: ----------
Mon 2023-04-17 11:29:41.944: Performing DKIM signing (thread-ID: 42764)
Mon 2023-04-17 11:29:41.944: * File: j:\mdaemon\queues\remote\md3501000200109.msg
Mon 2023-04-17 11:29:41.944: * Work file: C:\MDaemon\CFilter\WORK\764021729\pd324802220.tmp
Mon 2023-04-17 11:29:42.023: * Message-ID: <em5f956e15-1003-409e-9771-bc04277581d4@4bac21dd.com>
Mon 2023-04-17 11:29:42.023: * From: ***@***.com
Mon 2023-04-17 11:29:42.023: * Selector: MDaemon
Mon 2023-04-17 11:29:42.023: * Domain (d=): **.com
Mon 2023-04-17 11:29:42.023: * Result: 0 (signed ok)

My next hurtle is receiving mail from other local servers that are Linux/Unix based.

Part of the header for incoming mail contains:

Received: (from **@localhost)
by localhost.localdomain (8.14.7/8.14.7/Submit) id 33HEJGC2002928;

So how should we configure:

(PEM) DKIM selector record for DNS

The entry in dksign.dat to address unix based systems

A

Arron Staff

4/17/23, 11:40 AM

Great, I'm glad that MDaemon is adding DKIM signatures now.

The messages that are using .local in the FROM header, are those being sent to the internet? If they are, I'd suggest changing them from header to use your .com domain. Lots of places won't accept mail from .local, and you won't be able to get the DKIM signature to verify correctly because you can't pubish DNS for .local to the internet. For now, I'll assume they are just local messages, in which case you'll want to publish the DKIM select at mdaemon._domainkey.domain.local in your local DNS.

You'll also want to publish a DKIM selector record at MDaemon._domainkey.domain.com so that other servers on the internet can verify the DKIM signatures in your domain.com messages.

The records should be TXT records.

What is the value of the FROM header for messages from the Unix systems? Are the systems authenticating with MDaemon when sending? MDaemon requires the message be received via an authenticated session in order to be signed. If it cannot be received via an authenticated session then you'll need to setup a content filter rule to force MDaemon to sign the messages.

S

Scott

4/18/23, 12:38 PM

I'm working to address your concerns detailed in your previous email, however there is obviously one issue I should address first; with your help.

The DKIM signing process allows the system to generate a keypair based on our current configuration, and as you know we have a .local internal and a .com externally. However, the documentation doesn't address how to build a keypair that isn't your default local environment. In our case a DKIM key (or .local) will not work for my ISP that hosts our DNS; they will need a external DKIM key (or .com).

Once we’ve built the correct key we can then update the files located in the PEM subdirectory

This file saved as: C:\MDaemon\PEM\MDaemon\dns_readme.txt

DKIM selector record for DNS:

MDaemon._domainkey.***.com. IN TXT

"v=DKIM1; p=********"

"What is the value of the FROM header for messages from the Unix systems? Are the systems authenticating with MDaemon when sending? MDaemon requires the message be received via an authenticated session in order to be signed."

The problem we have with this statement is certainly understandable and may be difficulat to correct. Most mail arrives from several different sources so each IP address has been white listed for security reasons (each site is strictly controlled)

Mail normally arrives as follows:

(not processed: message from trusted or authenticated source)
X-MDRemoteIP: 192.X.X.X

Your thoughts?

A

Arron Staff

4/18/23, 1:46 PM

I'm not sure I'm understanding the question.

Is your ISP sending mail on your behalf and you want to generate a key pair for the ISP to use so the mail they send includes a DKIM signature? Typically if a 3rd party is sending mail on your behalf they will generate the key pair for signing and provide you the information so that you can add it to your DNS.

If your ISP is the one doing the signing, you don't need to update the PEM files in MDaemon. MDaemon only needs to know about the key pairs that it creates. If your ISP is signing mail for your public domian, MDaemon doesn't care about it unless your ISP is sending the mail to your MDaemon. And then MDaemon will treat it like any other verification of a DKIM signature. It will look up the selector in DNS, get the information it needs and attempt to verify the signature. The DNS_readme.txt file is simply to store and make accessible to the admin the information necessary to add the DKIM selector record in DNS.

Just because a message is received from a trusted source, doesn't mean it can't authenticate. If they can be setup to authenticate, that is typically the easiest method.. I'm assuming though the sending server is not capable of authenticating or there is some other restriction that is making it difficult... In this case I would setup a content filter rule and force MDaemon to sign the messages.

Something like:

If the X-MDRemoteIP header contains 192.168.1.1 then add a DKIM signature using the $CF$ selector. Where $CF$ is whatever selector you choose to use. You'll just have to create the selector in MDaemon and then add it to your public DNS. Or you could use the selector that you are already using, but it might be beneficial when troubleshooting in the future to use different ones. Its really up to you.

S

Scott

4/20/23, 11:46 AM

“Is your ISP sending mail on your behalf and you want to generate a key pair for the ISP to use so the mail they send includes a DKIM signature?”

All mail coming into our facility from an outside SMTP relay and additionally mail generated locally is sent out directly to the recipient via our local SMTP or smart host.

NOTE: Our ISP hosts our DNS record, so DKIM information must be update at their location. All mail inbound is stored at our ISP and the local Multipop application reads each mailbox and distributes to internal users.

“... In this case I would setup a content filter rule and force MDaemon to sign the messages.”

We’re in discussions with our vendor to see if authentication can be built, however under the assumption authentication cannot be done, then we must configure signing using Content Filter.

Currently we now understand dkim is working correctly because it signs email going out from within our local domain (see below) when it is sent directly to the recipient via SMTP

Performing DKIM signing (thread-ID: 39812)

* File: j:\mdaemon\queues\local\md3501000117385.msg

* Work file: C:\MDaemon\CFilter\WORK\1657826696\pd2593028654.tmp

* Message-ID: <MDAEMON-* Message-ID: MDAEMON-F202304201206.AA0621738md5001000106909@mail.*****.local

* Selector: MDaemon

* Domain (d=): *******.com

* Result: 0 (signed ok)

Previously we detailed examples when DKIM fails (see below).

DKIM Logfile shows the following: Result: -23 (could not sign)"

So, we’ve tried to sign emails coming in from an outside site that is trusted (as you’ve suggested) using content filtering which appears to work (see below content filtering snippet)

* Message matched rule: 6 "Check and Sign #3 - dkim" (Hits: 4774)

* Condition: X-Authenticated-Sender header exists

* Action: Flagged for DKIM signing

However, reviewing the DKIM log file, it doesn’t show a successful sign request, it doesn’t show an error, as a matter of fact, the DKIM file shows NO entry at all when processing mail from a trusted external site.

So, understanding this we still need detail how to do the following:

Manually build a DKIM key pair for our external ***.com domain name, as well as other external domains that are trusted? Because, as you know, the automated process “Create new public and private keys” only work on our *.local and not our *.com which is necessary to provide to our IPS that published our DNS record.

Taken from the dns_readme.txt file

“The above example uses your primary domain of "*****.local".

You will want to set up similar records using different domain and key values if

you wish to sign mail for other domains.”

We can only assume DKIM key pairs are necessary for each external trust sites for content filtering to work correctly.

A

Arron Staff

4/20/23, 12:45 PM

Manually build a DKIM key pair for our external ***.com domain name, as well as other external domains that are trusted? Because, as you know, the automated process “Create new public and private keys” only work on our *.local and not our *.com which is necessary to provide to our IPS that published our DNS record.

The button to Create new public and private keys works to create a new public and private key for any selector that you enter. Just make sure you select the default selector that you want MDaemon to default to when signing after creating additional selectors.

Additionally, You can then tell MDaemon what selector to use by clicking Define which messages are eligible for signing. For example:

from*@domain.com s=mdaemon

All mail that is received via an autheniticated session that contains @domain.com in the From header will be signed with the mdaemon selector.

So, if you would like to create a selector to be used by a content filter rule, then Type the selector name in the Default Selector field, click Creat new public and private keys. This will generate a unique private and public key pair. For example, if you enter Test as the default selector and click the button for Create public and private keys, you will get a dns_readme.txt file with the following information:

This file saved as: C:\MDaemon\PEM\test\dns_readme.txt

DKIM selector record for DNS:

test._domainkey.domain.com. IN TXT
"v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvJXO5B7hYxjYhiwzDUVWXlytDnHBKjhKW3I40ieui3SiZM4GvHJIEypEN3Xg0/y9LbkD3qJ0kjFBWfvwrQxodIHjzccmBq2wXGi9kuPW75KIiu5w9hYqKw7nY97vfwckg9jxX8BD5yD1KH7mi5NlqSJ6D7p9ZHJ4JRugnrf4GkmyzfWXAD+oNCFKQgo4Pzoj4SsWC32E"
"akOy4Xxak5bwQLusaM0/FXIpqfToBgV+en3FrFCBsxfBxmjwy/RpRty5bjKyl+RVo30hbhBij7D66SHzgPPe03enlQ6LpPhDE4fJAlDhpx9fBGYVVABVDelsEaUY10kE2URuY7a+qGTa8QIDAQAB"

Now, lets say you want to use this in the content filter to DKIM sign messages from externaldomain.com. You'll need to publish the specific selector with the information from the dns_readme.txt file in the DNS for externaldomain.com.

In the example above the only information that would need to be changed in order to do that would be this:

test._domainkey.domain.com. -> test._domainkey.externaldomain.com.

You do not have to update the dns_readme.txt file, this file is only for your information. MDaemon uses the rsa.private file on disk for signing, and it doesn't matter to MDaemon what domain its signing. It just uses the key its told to in order to sign the message. As long as you properly publish the selector in DNS for the correct domain, the signature will verify.

So take the selector you just created, configure the content filter rule to sign messages using that selector and then update the DNS for externaldomain.com to include the selector information.

We can only assume DKIM key pairs are necessary for each external trust sites for content filtering to work correctly.

That is not a correct assumption...

You can choose to generate a unique key pair for each external trusted site (as explained above), but you do not have to. If you want to sign all mail for all external trust sites using the same key pair that you use for yourdomain.com, you can. You just have to publish the selector record in DNS for each external trusted site and tell MDaemon to use the same selector in all of your content filter rules.

I would reccomend using a unique key pair for each domain, but it is not required.

S

Scott

4/21/23, 8:39 AM

Hello Arron,

Your last post was very help to better understand how mdaemon can create keys in DKIM.

This is where I am in this issue

Using content filtering to help with the 'heavy lifting' by replacing 'localhost.localdomain' with the necessary external domain name (**.com).

For some reason I'm still having emails leaving (via SMTP OUT) that are not signed.

Here is the example of one such email (please note the message ID is consistent throughout the example)

SMTP(IN)

Fri 2023-04-21 09:02:59.642: 06: [02180739] ---- End AntiVirus results
Fri 2023-04-21 09:02:59.686: 01: [02180739] Message creation successful: j:\mdaemon\queues\inbound\md5001000239437.msg
Fri 2023-04-21 09:02:59.686: 03: [02180739] --> 250 2.6.0 Ok, message saved <Message-ID: <202304211302.33LD2xhk028822@localhost.localdomain>> <<<< PLESAE NOTE THE INBOUND DOMAIN >>>>>
Fri 2023-04-21 09:02:59.688: 02: [02180739] <-- QUIT
Fri 2023-04-21 09:02:59.688: 03: [02180739] --> 221 2.0.0 See ya in cyberspace
Fri 2023-04-21 09:02:59.689: 01: [02180739] SMTP session successful (Bytes in/out: 2078/2363)

Conent Filter

Fri 2023-04-21 09:03:04.036: Content Filter processing j:\mdaemon\queues\remote\md5001000239437.msg...
Fri 2023-04-21 09:03:04.036: * Message return-path: prvs=147511aa8c=INFO@*****.com
Fri 2023-04-21 09:03:04.036: * Message from: INFO@*****.com
Fri 2023-04-21 09:03:04.036: * Message to: ********@********.gov
Fri 2023-04-21 09:03:04.036: * Message subject: ********************
Fri 2023-04-21 09:03:04.036: * Message ID: <202304211302.33LD2xhk028822@*****.com>
Fri 2023-04-21 09:03:04.036: Start Content Filter results
Fri 2023-04-21 09:03:04.037: * Message matched rule: 1 "Search in Received for 'localhost.localdomain' add DKIM '*****.com'" (Hits: 5667)
Fri 2023-04-21 09:03:04.037: * Condition: Received header contains [localhost.localdomain]
Fri 2023-04-21 09:03:04.039: * Action: Searched for and replaced text in message header (if found)
Fri 2023-04-21 09:03:04.041: * Action: Flagged for DKIM signing
Fri 2023-04-21 09:03:04.042: * Message matched rule: 2 "Search in Received for 'localhost' add DKIM '*****.com" (Hits: 1560)
Fri 2023-04-21 09:03:04.042: * Condition: Received header contains [@localhost]
Fri 2023-04-21 09:03:04.046: * Action: Searched for and replaced text in message header (if found)
Fri 2023-04-21 09:03:04.049: * Action: Flagged for DKIM signing <<<< = please note content filtering is signing >>>>>>
Fri 2023-04-21 09:03:04.063: * Matched 2 of 28 active rules
Fri 2023-04-21 09:03:04.063: End of Content Filter results

DKIM (file)

Does not contain md5001000239437.msg

(EMAIL after being processed with content filter)

NOTE: Content filtering has replaced all references to "localhost.localdomain" with our external domain name ****.com

X-MDAV-Result: clean
X-MDAV-Processed: mail.*****.com, Fri, 21 Apr 2023 09:03:04 -0400
Received: by mail.*****.com with ESMTPS id md5001000239437.msg; Fri, 21 Apr 2023 09:03:03 -0400
X-Spam-Processed: mail.*****.com, Fri, 21 Apr 2023 09:03:03 -0400
(not processed: message from trusted or authenticated source)
X-MDRemoteIP: 192.67.68.80
X-MDHelo: *****.com
X-MDArrival-Date: Fri, 21 Apr 2023 09:03:03 -0400
X-Return-Path: prvs=147511aa8c=INFO@*****.com
X-Envelope-From: INFO@*****.com
Received: from *****.com (localhost [127.0.0.1]) by *****.com (8.14.7/8.14.7) with ESMTP id 33LD2xh1028823; Fri, 21 Apr 2023 09:02:59 -0400
Received: (from root@*****.com) by *****.com (8.14.7/8.14.7/Submit) id 33LD2xhk028822; Fri, 21 Apr 2023 09:02:59 -0400
Date: Fri, 21 Apr 2023 09:02:59 -0400
Message-Id: <202304211302.33LD2xhk028822@*****.com>
Reply-To: "*********************" <DONOTREPLY@*****.com>
From: "*********************" <INFO@*****.com>
To: "*********************" <xxxxx@xxxxx.gov>,
"*********************" <xxxxx@xxxxx.gov>,
"*********************@xxxxx.gov>
Cc:
Subject: ***************************
IMPORTANCE: HIGH
Status: O
X-MDCFSigsAdded: *****.com

So if Content filtering indicates "Flagged for DKIM signing" why isn't the mail showing DKIM being applied to the message?

A

Arron Staff

4/21/23, 11:04 AM

My apologies, the content filter is not working like I thought it was.

You'll need to add another action to your CF rules to add a X-MDDKIMSelector header to the message and this action must be above the action to DKIM sign the message.

Also, I should point out that in the case you provided logs for where the same message matches two rules to have DKIM signature headers added, it will still only be signed one time using the selector from the last rule that ran.