Is this a bug? Underlying OS: debian 12, up-to-date mailcow: latest version docker and docker compose: debian repos, latest version workstation: windows 10 expected behaviour: emails composed in a desktop email client with utf8 encoding should be processed with german umlaute (äöüß) through mailcow. Tests: 1. sogo build-in of mailcow (NOT a desktop client) --> working correct 2. email composed in thunderbird 115.4.1 (64-Bit) --> not working 3. email composed in betterbird --> not working 4. email composed in sylpheed --> not working Using system wide footer is working with sogo, but not working (again umlaute) using a email desktop client. Email sent through a different mail server (nethserver) with same clients are formatted as expected. Please advice where to investigate.

Follow up while digging around: 1. I had to change my fritzbox 6490 cable in bridge mode. Exposed host for the asus router behind was not enough. 2. Now the asus shows a WAN IP, which in (real) bridge mode of the fritzbox is a different one as shown in the fritzbox. The WAN IP shown in the asus is to be set in the DNS settings at the hoster. 3. The laptop is configured as DMZ in the asus. 4. On the laptop I installed nginx as reversed proxy. I took the example config from mailcow and changed it to my domain. 5. I started over with a new mailcow-docker installation. 6. Unbound container was unhealthy. As the asus is running with unbound, I tried to point the forward zone in unbound.conf to the IP of the asus. That didn't work. Unbound container showed healthy, but error during the acme challenge occurred. I changed the IP to 1.1.1.1. That worked. The challenge completed. 7. I created a domain and a test user. 8. I took the dkim key to the DNS (as well as the other settings to make). 9. I tested from sogo an email to email-tester composed in html. So far o.k., dkim passes, not a 10/10 because auf rDNS setting. This was to expect. 10. Changed sogo to plain text, email test also o.k. 11. Tried thunderbird - email tests also o.k. 12. Did a backup. Well - it is was not so easy to track this down. Still some questions open. But maybe it helps someone. I'll keep this running and testing at home for a while. If the mailcow runs smooth, I'll migrate my email servers in business. And will donate for this great work. regards, stefan

> @"stefan21"#p11432 mailcow: latest version Does that mean nightly version? Or latest stable version 2023-10a? What is the receiving side using?

Thank you for taking time to look into. It's the stable version 2023-10a. The clients are configured to use the FQHN in the LAN as mail server. For receiving and sending email. Nothing special, just how any desktop email client would be configured to use an internal email server in the LAN. What do you mean with the receiving side?

Logs from dovecot-mailcow and postfix-mailcow showing nothing special (to me). @"[deleted]"#2109 If it's helpful I'll send you an email to any account you name. @"[deleted]"#2109 If it's helpful I'll send you an email to any account you name. Sorry for double post. The browser requested a refresh...

> @"esackbauer"#p11437 What is the receiving side using? Do you mean where I sent the email to? 1. kabelbw.de 2. mailbox.org

Here's an email from nethserver: dkim=pass (2048-bit key) From: =?utf-8?q?x=2E_y?= Content-Type: text/plain; charset="utf-8" Reply-To: x@y.de X-Forward: 10.0.0.3

More testing: Now from my laptop, OS archlinux, but NOT in a VM. I should had make this clear before: all tests above have been made behind a opnsense in a VM hosted from proxmox, no firewall on proxmox enabled. dkim=pass (2048-bit key; unprotected) header.d=x.de header.i=@x.de header.a=rsa-sha256 header.s=dkim header.b=wO+Fa4dv; dkim-atps=neutral FROM: =?utf-8?q?x=2E_y?= text/plain; charset="utf-8" quoted-printable User-Agent: SOGoMail 5.9.0 German umlaute are o.k. Now from an email client, still my laptop: dkim=pass (2048-bit key; unprotected) header.d=x.de header.i=@x.de header.a=rsa-sha256 header.s=dkim header.b=dGLkfmta; dkim-atps=neutral FROM: "x" text/plain; charset=UTF-8; format=flowed User-Agent: Mozilla Thunderbird German umlaute are o.k.

encoding from different mail clients using mailcow as mail server

stefan21

During several investigations I’m facing another problem with the DKIM key. No matter if composing email form build-in sogo or any desktop email client, any email I send does not pass the DKIM check.

Messages are:

User-Agent: Mozilla Thunderbird:
dkim=fail (2048-bit key) reason=“fail (message has been altered)”

or:
User-Agent: SOGoMail 5.9.0
dkim=fail (2048-bit key) reason=“fail (message has been altered)”

Hmm. Don’t know this from my other mail servers…? What’s wrong?

stefan21

Here’s an email from nethserver:

dkim=pass (2048-bit key)
From: =?utf-8?q?x=2E_y?= <x@y>
Content-Type: text/plain; charset=“utf-8”
Reply-To: x@y.de
X-Forward: 10.0.0.3 <– VPN wireguard / did all tests through VPN
Date: Sat, 11 Nov 2023 00:15:50 +0100
To: x@mailbox.org
MIME-Version: 1.0
Message-ID: <67de-654eb980-3-4e050400@215156844>
Subject: test
User-Agent: SOGoMail 5.9.0
Content-Transfer-Encoding: quoted-printable

Looks clean. I’m pretty sure that I followed the mailcow-dockerized how-to setup. I’m able to send and receive emails. BUT - character encoding does not work, AND DKIM fails.

So?

stefan21

More testing:

Now from my laptop, OS archlinux, but NOT in a VM. I should had make this clear before: all tests above have been made behind a opnsense in a VM hosted from proxmox, no firewall on proxmox enabled.

dkim=pass (2048-bit key; unprotected) header.d=x.de header.i=@x.de header.a=rsa-sha256 header.s=dkim header.b=wO+Fa4dv;
dkim-atps=neutral

FROM: =?utf-8?q?x=2E_y?= <x@y>
text/plain; charset=“utf-8”
quoted-printable
User-Agent: SOGoMail 5.9.0

German umlaute are o.k.

Now from an email client, still my laptop:

dkim=pass (2048-bit key; unprotected) header.d=x.de header.i=@x.de header.a=rsa-sha256 header.s=dkim header.b=dGLkfmta;
dkim-atps=neutral

FROM: “x” x@y.de
text/plain; charset=UTF-8; format=flowed
User-Agent: Mozilla Thunderbird

German umlaute are o.k.

stefan21

Resume:

In a VM, debian 12, hosted on proxmox, no firewall on proxmox, VM in a company LAN behind OPNsense, german umlaute are not processed from mailcow-dockerized, and DKIM is false. Receiving and sending emails is working. On the OPNsense no reverse proxy is configured. Let’s encrypt certs are handled by acme-plugin from the OPNsense and are copied via cron job to the VM. Access to mailcow-dockerized via FQHN in LAN is working flawless. Only open port(s) redirected from LAN to WAN are 80 and 443. The mailcow is not intended to be accessable from WAN. Only via wireguard VPN.

From a laptop at home, on top of archlinux, no issues.

As I intend to substitute a company email server (nethserver 7) with mailcow-dockerized, I need help where to investigate.

Any help would be greatly appreciated.

esackbauer

I have no idea what is happening, but I never had any problems that you have.
My guess is you are at some point not following the prerequisites or installation docs.
Limiting outgoing to only 80 and 443 is bad, because unbound cannot do DNS resolving then.
DKIM is reliant on DNS records, which might need some time to sync across all DNS servers out there. So try it later again.

stefan21

Every DNS (port 53) request from the VM with mailcow (the whole LAN) is redirected to the OPNsense unbound. BTW unbound-mailcow shows healthy status. And port 53 is open.

For email the only open port is 25. All other ports (as in the docs described) are only allowed in the LAN. The mailserver is meant for internal access. No public access at all.

May I ask if you have mailcow-dockerized running in a VM? If so, qemu, virtualbox, proxmox, …? What host OS?

For the prerequisites, what could be wrong? I mean, on my laptop at home I did the same as in the VM. Except that at home the host in archlinux and not a VM based on debian 12.

Well, I can try with another host OS for the VM. Have you got a special recommendation?

esackbauer

I am running a Debian 12 VM on top of Hyper-V. But I have another one running on Virtualbox as well, also with Debian.
No problems. Debian is recommended.
Are you using Opnsense as MTA? Incoming or Outgoing? Maybe transparent?

caylakpenguen

Does the dkim key in dns match mailcow? please check.

stefan21

Thanks to anybody following.

The last 4 days I took time for some tests and investigations. All tests are based on proxmox 7.4.-17. Proxmox is running on a HP Proliant ML30, enough cpu and ram for any test.

First try was to build a VM based on debian 12, minimal net-install as a server. HD 60 GB, RAM 8 GB, rest default hardware, network bridged. No firewall on the proxmox enabled. In front of the network is an OPNsense, the debian VM got a static IP with ARP mapping. The OPNsense nor proxmox is configured as MTA. No reverse proxy is running on the OPNsense. The mailserver is not intended to be accessable from the WAN, only via VPN or LAN. I created the records in the DNS. On the OPNsense itself is running unbound as DNS. All DNS traffic in the LAN is routed through the OPNsense. As pre-requisites on the OPNsense, I opened the port 80 (acme challenge) for the VM in the OPNsense, and created also a rule for all needed ports in the LAN for the VM.

I followed the install instructions, mailcow came up and was running. The acme challenge didn’t work, I assume a reverse proxy would be needed. The workaround was to disable the letsencrypt part in mailcow, get the cert via OPNsense and copy and rename the certs to the given path from the docs to the mailcow.

I configured a domain a few mailboxes, an alias, copied the dkim key to the DNS, and made a backup the the helper script. I started to send a few emails from sogo to kabelbw.de and mailbox.org, and vice versa. That seemed to work with no errors. The test emails had no signature or system wide footer. Emails ALWAYS sent as PLAIN TEXT, NO html email.

I created an account in thunderbird, now with signature and german umlaute äüöß, … Did the same in sogo. This leads to: dkim=fail (2048-bit key) reason=“fail (message has been altered)”

I deleted the signatures and resent a simple test email. Still dkim fails. I double checked with https://dkimvalidator.com/. I restored from the backup and dkim with a simple test email was o.k.

I created a signature in sogo and a system wide footer. DKIM went false.

I started over with a second VM based on Rocky linux DVD. Configuration in proxmox mainly the same, except the CPU. I tried to restore the mailcow backup I made from the debian VM to save some time. That did not work. Emails stayed encrypted. I did a full restore. Nevertheless I started over to configure mailcow in Rocky linux, at this point I cut it down. Same behaviour and results as in the debian VM.

As I already wrote, I installed mailcow-dockerized also on my laptop, based OS archlinux. In my home-network there’s a consumer asus router/firewall. For the test I configured a port forwarding for the acme challenge in the router. I took another domain name, configured the DNS, so far mailcow is working with no errors.

I’ve another email-server in a network. Also running on proxmox in a VM, bridged network. This server (Nethserver 7) is not containerized. Also an OPNsense as FW in front. Email is working for years flawlessly. No dkim errors. This server even completes the acme challenge every 90 days. Same with an koozali (formerly mitel e-smith) server. No errors at all.

Therefore my questions:

is mailcow intended for production use in a company network (LAN, centralized/redirected DNS, ActiveDirectory), NOT intended to be accessable from WAN?
anybody with a similar setup as from me described (signature/domain wide footer with german UMLAUTE, plain text) where dkim passes?
where could I possibly have made a mistake?

I’d like to seperate my email-servers from the file servers, therefore I’m looking for a suitable solution for production use.

esackbauer

I am running my private mailcow in a “company network” behind two Sophos Firewalls, configured as MTAs.
I have tried the domain wide footer (plain text) with Umlaute (composed with MS Outlook via ActiveSync) in my installation, and I had no problems with DKIM.
Maybe something is altering SMTP headers, e.g. because you set up some filtering in OPNsense?

stefan21

Is an already proper installed and running opendkim service a prerequisite before installing mailcow-dockerized?

esackbauer

stefan21 This is not needed at all. Why do you think it is?

stefan21

More or less a guess. What else can I do as to copy’n paste the dkim key from mailcow to my DNS? I think there is no mistake. I’d like to know, what causes the dkim failure in https://dkimvalidator.com.

Validating Signature

result = fail
Details: bad RSA signature

To the question of running filters on the OPNsense. No, not for outgoing email, afaik.

esackbauer

With that little information, we can only guess. Probably you are mixing up DKIM selectors, and/or not waiting until updated DNS records have been published on every DNS server out there.

stefan21

Getting closer. Your guess might lead in the right direction. Thank you for pointing to the records.

I did a dkim check in another tool. mxtoolbox does indeed show a different record as dkimvalidator.com. And here we go - mail-tester.com and mxtoolbox are identical. And correct.

So, for the DKIM it’s a dkimvalidator and cache/update problem. Thank you so far.

Now I will try to find the error with the umlaute problem. I’ll keep investigating.

stefan21

@esackbauer

Could you tell me where exactly are the dkim keys in mailcow stored? Files or database? And I’d like to know how to get there.

More testing with emails to a vodafone account:

mx5.vodafonemail.de/4SV90B37Vyz9ryY;
dkim=fail reason=“signature verification failed” (2048-bit key; unprotected) header.d=x.de header.i=@x.de header.a=rsa-sha256 header.s=dkim header.b=cVJitv3G;
dkim-atps=neutral

I did a diff -s file1 <– dkim from mailcow file2 <– dkim copied to DNS. They are identical.

Could it be, that if restoring a mailcow backup, the keys are messed up? I’d like to check the keys (public and private) before restore and after restore.

esackbauer

stefan21 Could it be, that if restoring a mailcow backup, the keys are messed up?

That could be. Probably they are stored in the Redis DB. I remember a thread in this forum where they discussed problems with the DKIM keys.

stefan21

Well, I’d like to check this. What’s the best approach to access the DB?

BTW here’s the email to the vodafone account:

"
test
–=20
Mit freundlichen Gr=C3=BC=C3=9Fen,

Mit freundlichen Gr=C3=BC=C3=9Fen,

=C3=B6=C3=A4=C3=BC=C3=9F

Umlaute in signature and domain footer… as already seen. Of course with a failed dkim key after a restore. To verify the suspicion I’ll wipe/delete the mailcow install on my laptop and start over with a new, clean install. No restores, no imports, nothing. Means from scratch. Will report.

esackbauer

stefan21
Now I am thinking that the Umlaute conversion is the reason why the DKIM fails. Something is changing the character encoding in transit and changing the “checksum”. Maybe the DKIM keys are fine.

I never tried to access the Redis DB, don’t know.

stefan21

esackbauer Now I am thinking that the Umlaute conversion is the reason why the DKIM fails. Something is changing the character encoding in transit and changing the “checksum”.

Let me start over with a fresh clean install. I’ll create a domain (same I use for tests), a user, will copy the new dkim key to DNS, nothing more. I’ll do a “vanilla” backup. First email will be with no umlaute. Second email will have umlaute. Third email will have signature and Umlaute. Forth one will have the signature and a system wide footer with umlaute.

I’ll report.