Cloudron Forum

 ==> Create / Migrate db
Jul 28 21:46:07 ==> Setting up OIDC
Jul 28 21:46:07 => Update site config
Jul 28 21:46:09 2025-07-28T19:46:09Z
Jul 28 21:46:09 2025-07-28T19:46:09Z
Jul 28 21:46:09 2025-07-28T19:46:09Z
Jul 28 21:46:09 2025-07-28T19:46:09Z
Jul 28 21:46:09 \
Jul 28 21:46:09 \Prisma schema loaded from packages/prisma/schema.prisma
Jul 28 21:46:09 Error: P3009
Jul 28 21:46:09 Datasource "db": PostgreSQL database "db831ce9e36aaa4dsab586a1c87917sa89", schema "public" at "postgresql:5432"
Jul 28 21:46:09
Jul 28 21:46:09 migrate found failed migrations in the target database, new migrations will not be applied. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve
Jul 28 21:46:09 132 migrations found in prisma/migrations
Jul 28 21:46:09 The `20250522054050_add_organisations` migration started at 2025-07-28 19:45:58.163673 UTC failed
Jul 28 21:46:11 ==> Create / Migrate db
Jul 28 21:46:11 ==> Setting up OIDC
Jul 28 21:46:11 => Update site config
Jul 28 21:46:13 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.133:3000

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

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)