Is there a better source of information ?

@Valexico said:

Are you speaking of a major release ?

No, the next minor release will include this fix.
Until then, you can either set the port in pocketbase to 587 if incoming fails is enabled on your Cloudron. (not persistent across restarts)
Or you change the mail domain from my to e.g. mail. (persistent across restarts)

This is/was a very complex issue to figure out.

TL;DR - "fix" or workaround

Renaming your mail domain from my to e.g.: mail in /#/email-settings will resolve this issue. (be sure to also update your PTR/rDNS record)

Changing the port from 2587 to 587 also works when incoming mails for your Cloudron server is enabled.
Warning, changing just the port in pocketbase will not be permanent, since every app restart will configure 2587 again.

Detailed report

Pocketbase is a golang application.
If CGO_ENABLED=0 is set for the build it will result in Go uses its own built-in resolver.
While designed to mimic the system, it has known edge cases where it might skip /etc/hosts and rely entirely on DNS.

Certain hosting providers, like DigitalOcean, will set the name for the server in the /etc/hosts file.
So if you name your server my.cloudron.dev DigitalOcean will create a record in the /etc/hosts file with my.cloudron.dev 127.0.0.1, which will result into DNS queries asking for my.cloudron.dev to answer with 127.0.0.1.
If this is not handled by Cloudron certain things would not work.
For example, if you'd use the N8N Cloudron app to run API calls against your own Cloudron server, it would resolve my.cloudron.dev to 127.0.0.1 and fail.

This is why we have a line of code to prevent this issue - https://git.cloudron.io/platform/box/-/blob/v9.1.6/src/docker.js?ref_type=tags#L716

if (manifest.id !== 'com.adguard.home.cloudronapp') containerOptions.HostConfig.ExtraHosts.push(`${dashboardFqdn}:172.18.0.1`);

to always resolve the dashboard FQND to 172.18.0.1 which is the docker proxy / docker bridge inside the docker containers, except for the AdGuard app.

But now, something specific can happen.
The golang mail client requires the mail host to match the mail domain for StartTLS validation.
That is why we have the requiresValidCertificate flag for the sendmail addon for Cloudron apps to handle apps that need valid certificates for mailing.
With requiresValidCertificate set to false (the default), the CLOUDRON_MAIL_SMTP_SERVER variable inside the docker containers will be mail which works for most apps.
With CLOUDRON_MAIL_SMTP_SERVER set truethe CLOUDRON_MAIL_SMTP_SERVER will be the mail domain, by default my.DOMAIN.TLD so for me my.cloudron.dev.

For pocketbase, Go uses its own built-in resolver, it now resolves my.cloudron.dev not to 172.18.0.1 but to the public IPv4/IPv6 139.162.188.66/2a01:7e01::2000:3cff:fe7c:9d41 and tries to connect with port 2587 which fails, because port 2587 is only open internally.
So at some point the failing connection times out and Go's will try to resolve my.cloudron.dev not with its internal resolver but from the system, which then sends the mail.
This explains why the test mail is sent after some time, even tho it reports a timeout and fail.

We are looking deeper into this to find a solution that covers these edge cases to prevent such issues in the future.
The roads of DNS can be a harsh journey to navigate.

Next thing would be to see what the code does

The Cloudron mail server was not throttling, I ensured that.

Many times it fails the send test mail only to send the mail after the failed attempt anyway.
I observed this in the mail service logs and the debug log of pocketbase.

There must be something going in internally that is creating this issue.

From pocketbase point of view, the email request gave timeout
From user point of view the login time is slow (~30 seconds maybe) -> workround : disable login alerts
But emails do get sent at the end ? At least test emails

What am I missing

Thanks in advance!