Email receiving issue

CaeruleusAqua

Hello everyone,

I currently have the problem that we cannot receive various emails from exchange servers.

The problem seems to be that exchange cannot find a compatible cipher.

I have already tried to activate more ciphers in Haraka itself, but I still only get the ECDHE from nmap although RSA is definitely activated.

Could this have something to do with the reverse proxy?

nmap --script ssl-enum-ciphers -p 25 mail.byte-robotics.com
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-04-03 11:03 CEST
Nmap scan report for mail.byte-robotics.com (37.221.195.213)
Host is up (0.017s latency).
Other addresses for mail.byte-robotics.com (not scanned): 2a03:4000:8:173:444e:10ff:fec8:1ac5

PORT   STATE SERVICE
25/tcp open  smtp
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|     cipher preference error: Network error
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

nebulon

Do you have any error from exchange which you could share?

The reverse proxy is for http(s) only and not listening on port 25, so at least we can rule that part out here.

CaeruleusAqua

Unfortunately I don't have much:
only the error from the mail itself, in the Cloudron logs was unfortunately nothing to see.

Remote Server at byte-robotics.com (2a03:4000:8:173:444e:10ff:fec8:1ac5) returned '400 4.4.7 Message delayed'
31.03.2025 12:32:06 - Remote Server at byte-robotics.com (2a03:4000:8:173:444e:10ff:fec8:1ac5) returned '451 4.4.0 Primary target IP address responded with: "421 4.4.1 Connection timed out." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was 2a03:4000:8:173:444e:10ff:fec8:1ac5:25'

The other side said:

It caused the problem while negotiating the encryption. Your server did not initially accept any encryption from the cipher suite offered by our mail server. This was easy to see with WireShark and in a packet trace on our firewall.

I then disabled encryption to your mail server on our side, after which there was an unencrypted connection and the mail was delivered to you.

In the next step, I configured an SMTP proxy outgoing on our firewall that replaces the ciphers generated by the Exchange server with more up-to-date ones. This also resulted in an encrypted connection.

His trace from yesterday:

And what now is used (after modifying the firewall)

nebulon

So I am not 100% sure I correctly follow what you did ther with the proxy and why you replaced the generated ciphers from exchange.

Do you know which ciphers you require for this environment? The Cloudron mail service is using the ciphers from nodejs through haraka, so you can check all available ones via SSH on your Cloudron (this is how it should look like on a Cloudron v8.3.1):

$ docker exec -ti mail /bin/bash
root@485ef0cfc06e:/app/code/haraka# node -e "console.log(require('tls').getCiphers())"
[
  'aes128-gcm-sha256',
  'aes128-sha',
  'aes128-sha256',
  'aes256-gcm-sha384',
  'aes256-sha',
  'aes256-sha256',
  'dhe-psk-aes128-cbc-sha',
  'dhe-psk-aes128-cbc-sha256',
  'dhe-psk-aes128-gcm-sha256',
  'dhe-psk-aes256-cbc-sha',
  'dhe-psk-aes256-cbc-sha384',
  'dhe-psk-aes256-gcm-sha384',
  'dhe-psk-chacha20-poly1305',
  'dhe-rsa-aes128-gcm-sha256',
  'dhe-rsa-aes128-sha',
  'dhe-rsa-aes128-sha256',
  'dhe-rsa-aes256-gcm-sha384',
  'dhe-rsa-aes256-sha',
  'dhe-rsa-aes256-sha256',
  'dhe-rsa-chacha20-poly1305',
  'ecdhe-ecdsa-aes128-gcm-sha256',
  'ecdhe-ecdsa-aes128-sha',
  'ecdhe-ecdsa-aes128-sha256',
  'ecdhe-ecdsa-aes256-gcm-sha384',
  'ecdhe-ecdsa-aes256-sha',
  'ecdhe-ecdsa-aes256-sha384',
  'ecdhe-ecdsa-chacha20-poly1305',
  'ecdhe-psk-aes128-cbc-sha',
  'ecdhe-psk-aes128-cbc-sha256',
  'ecdhe-psk-aes256-cbc-sha',
  'ecdhe-psk-aes256-cbc-sha384',
  'ecdhe-psk-chacha20-poly1305',
  'ecdhe-rsa-aes128-gcm-sha256',
  'ecdhe-rsa-aes128-sha',
  'ecdhe-rsa-aes128-sha256',
  'ecdhe-rsa-aes256-gcm-sha384',
  'ecdhe-rsa-aes256-sha',
  'ecdhe-rsa-aes256-sha384',
  'ecdhe-rsa-chacha20-poly1305',
  'psk-aes128-cbc-sha',
  'psk-aes128-cbc-sha256',
  'psk-aes128-gcm-sha256',
  'psk-aes256-cbc-sha',
  'psk-aes256-cbc-sha384',
  'psk-aes256-gcm-sha384',
  'psk-chacha20-poly1305',
  'rsa-psk-aes128-cbc-sha',
  'rsa-psk-aes128-cbc-sha256',
  'rsa-psk-aes128-gcm-sha256',
  'rsa-psk-aes256-cbc-sha',
  'rsa-psk-aes256-cbc-sha384',
  'rsa-psk-aes256-gcm-sha384',
  'rsa-psk-chacha20-poly1305',
  'srp-aes-128-cbc-sha',
  'srp-aes-256-cbc-sha',
  'srp-rsa-aes-128-cbc-sha',
  'srp-rsa-aes-256-cbc-sha',
  'tls_aes_128_ccm_8_sha256',
  'tls_aes_128_ccm_sha256',
  'tls_aes_128_gcm_sha256',
  'tls_aes_256_gcm_sha384',
  'tls_chacha20_poly1305_sha256'
]

CaeruleusAqua

Ok, apparently I didn't express myself correctly:

I didn't replace ciphers, but the other party who wants to send emails to us. Without the adjustment we could not receive the mails.

In any case, I get the following output:

[
'aes128-gcm-sha256',
'aes128-sha',
'aes128-sha256',
'aes256-gcm-sha384',
'aes256-sha',
'aes256-sha256',
'dhe-psk-aes128-cbc-sha',
'dhe-psk-aes128-cbc-sha256',
'dhe-psk-aes128-gcm-sha256',
'dhe-psk-aes256-cbc-sha',
'dhe-psk-aes256-cbc-sha384',
'dhe-psk-aes256-gcm-sha384',
'dhe-psk-chacha20-poly1305',
'dhe-rsa-aes128-gcm-sha256',
'dhe-rsa-aes128-sha',
'dhe-rsa-aes128-sha256',
'dhe-rsa-aes256-gcm-sha384',
'dhe-rsa-aes256-sha',
'dhe-rsa-aes256-sha256',
'dhe-rsa-chacha20-poly1305',
'ecdhe-ecdsa-aes128-gcm-sha256',
'ecdhe-ecdsa-aes128-sha',
'ecdhe-ecdsa-aes128-sha256',
'ecdhe-ecdsa-aes256-gcm-sha384',
'ecdhe-ecdsa-aes256-sha',
'ecdhe-ecdsa-aes256-sha384',
'ecdhe-ecdsa-chacha20-poly1305',
'ecdhe-psk-aes128-cbc-sha',
'ecdhe-psk-aes128-cbc-sha256',
'ecdhe-psk-aes256-cbc-sha',
'ecdhe-psk-aes256-cbc-sha384',
'ecdhe-psk-chacha20-poly1305',
'ecdhe-rsa-aes128-gcm-sha256',
'ecdhe-rsa-aes128-sha',
'ecdhe-rsa-aes128-sha256',
'ecdhe-rsa-aes256-gcm-sha384',
'ecdhe-rsa-aes256-sha',
'ecdhe-rsa-aes256-sha384',
'ecdhe-rsa-chacha20-poly1305',
'psk-aes128-cbc-sha',
'psk-aes128-cbc-sha256',
'psk-aes128-gcm-sha256',
'psk-aes256-cbc-sha',
'psk-aes256-cbc-sha384',
'psk-aes256-gcm-sha384',
'psk-chacha20-poly1305',
'rsa-psk-aes128-cbc-sha',
'rsa-psk-aes128-cbc-sha256',
'rsa-psk-aes128-gcm-sha256',
'rsa-psk-aes256-cbc-sha',
'rsa-psk-aes256-cbc-sha384',
'rsa-psk-aes256-gcm-sha384',
'rsa-psk-chacha20-poly1305',
'srp-aes-128-cbc-sha',
'srp-aes-256-cbc-sha',
'srp-rsa-aes-128-cbc-sha',
'srp-rsa-aes-256-cbc-sha',
'tls_aes_128_ccm_8_sha256',
'tls_aes_128_ccm_sha256',
'tls_aes_128_gcm_sha256',
'tls_aes_256_gcm_sha384',
'tls_chacha20_poly1305_sha256'
]

How can it be that nmap shows me significantly less?

nebulon

I don't quite know how nmap works in listing ciphers, but as far as I can tell the ciphers haraka (through nodejs) offers are not really outdated. Also we can only support those part of nodejs in any case. So not sure how to solve this from our side unfortunately.

nebulon

One idea, to get more insight, you can use the following command to see which ciphers openssl would use, while you can control what it offers:

openssl s_client -starttls smtp -connect my.YOURCLOUDRON.DOMAIN:587 -cipher 'ECDHE:!aNULL' -tls1_2

So ECDHE:!aNULL can be replaced with a cipher you are certain that other server supports.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

Email receiving issue