Cloudron Forum

@jdaviescoates I am interesting to figure out the workaround if I could just define the new SMRP port in the server configuration.

Alternatively, Is it possible to implement some kind of port forwarding rule that can circumvent the port 25 block?

Ah the Cloudron is on version 7.5.2 which had a bug here. This is fixed with v8.0 already

Yes, you’re correct! If you’ve configured Mailgun as a relay on Cloudron, you should use port 587 with STARTTLS for secure email sending. If you're looking for alternatives, I recommend SMTPget and iDealSMTP. Both offer reliable services and can also be easily configured for your email needs.

@darsh_parsana

/home/yellowtent/box/setup/start/cloudron-firewall.sh is on the root system, not inside any container.
You can just edit the file directly via ssh.

@Lanhild I sent a reply to them again. They've finally opened the port.

I have the solution, VPS is blocked SMTP , now is open now is working

@JUVOJustin said in Send email with brevo relay:

I have a sender configured for my-domain.com, while the server has cloudron01.my-domain.com . How can i solve this?

Just to double check - on Cloudron, the relay system requires "domain" level relaying . Meaning, it requires a relay that can send with FROM address like <anything>@domain.com , as opposed to specific-address@domain.com . Can you confirm this?

I think the easiest would be to allow changing the "From" domain in case a relay is used, since the sending domain will most likely be handled by the relay provider.

You can change the From Email address of an app in the Email section of the app - https://docs.cloudron.io/apps/#mail-from-address . If you want my-domain.com , then add this in the Domains view. It will then appear in the dropdown of the Email domain selector as well. Then, Email -> my-domain.com -> Configure Outbound as brevo.

@q__nt_n The VPS blocks port outbound 25. You have to reach out to contabo again and tell them that you can't connect with the above command.

@jdaviescoates totally confusing for sure. Not cloudron's fault completely as TLS is just an update to SSL. The problem comes from old software I think where SSL (the verb) is still being used where TLS should be. Both are technically the same, one is just newer.

Or at least that is what google would suggest lol. Either way, you can never have too many docs so an update to specifically call this out when working with SMTP ports would be useful.

@girish with help from vps and hosting it is been solved.
thank you for replying here

What @d19dotca mentioned is correct, the next release will solve this issue and the current warning can be safely ignored for now.

@girish Thanks for a quick fix, It's now working

@girish Wow that worked perfectly, thank you so much! 😊

@tomw thanks for the update! I will make the default value higher in the next release.

The root cause for this was the Cloudron server had the hostname as "box.domain.com" (same as the relay). Debian/Ubuntu has a quirk that it will put the hostname in /etc/hosts to resolve as 127.0.1.1. This meant that when we try to set it as relay, it resolves to 127.0.1.1 instead of the actual IP.

To add to the confusion, I suggested using the host command which does not use /etc/hosts (i.e the nsswitch mechanisms) and uses only the DNS. If I had suggested using ping then we would have narrowed down the issue more quickly...

Anyway, the fix is simply to hostnamectl set-hostname somethingelse.domain.com and also edit /etc/hosts (for some reason, hostnamectl doesn't change hosts file even after reboot, 🤷 ).

@girish
Thanks - it is green now and everything is okay 🙂

@vladimir I can also recommend sending a test mail to https://mail-tester.com to check if you have setup the DNS records required for the external email server correctly.

@saikarthik said in IMAP port and server settings for LAMP app mail client:

What I blurred out in the picture is actually a valid cloudron mailbox ID.

Yes, but it seems there is some extra text before it like Test User: "Test User". Can you remove that and try?

Woah;

Now I understand why so much user end by not using KMail (if you are curious look at KDE forum and Reddit for KMail issue)

Basically @girish you were on the right track simply I had to go a little bit deeper
instead of looking under identities (because, of course, my Identity was well configured)
the issue is located under the sending configuration where you have to declare the mail email (not the alias even if my test is not with the alias.)

9b78073a-ff99-4158-acb0-011f3f510209-image.png

Anyway thanks for your help! 🙂