Cloudron Forum

That's great, thanks @girish! It seems to work now. I enabled it and followed the steps in the new documentation you linked to, and then ran doveadm -c /run/dovecot.conf index -A '*' from the mail container which started indexing everything. Just waiting for the indexing to finish to confirm it'll be good.

@LoudLemur You could do that. No problem. You can specify the mail server location to be any SUB and pick any of the domains you have set up in Cloudron. To make things even wackier, you could use multiple subdomains like sub.sub.domain.com as the mail server.

OK, https://support.google.com/a/answer/81126?hl=en has even more information. "ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated." Have to investigate https://github.com/postalsys/haraka-plugin-mailauth . But long story short, @vadim unfortunately the situation is gmail forwarding is probably not going to work until we implement this. I have no ETA to implement this feature.

nice i eventually figure it out thanks

Ok weird, this worked, I backed up apps and updated to Cloudron 8 but it's not working again. that file didn't change. I set it to google's public DNS and it was fine - I reinstalled tailscale and set override DNS to true which I think should fix it and let me keep using TS

Ah yes, you were quicker than me, all green again, so I guess that was just a temporary minor glitch Thanks for checking though!

@brettjhonson that looks like quite a clumsy service advertising. But thank you for the idea.

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade: I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out. DNS=8.8.8.8 1.1.1.1 After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon ! In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

@joseph Thanks for this! I was trying to wrap it up last night so I decided to just reset all the users passwords to a known password, and then send them a password reset link to change it to their old password on their own. I will definitely keep the group approach in mind next time I'm migrating to Cloudron - but my next server likely won't migrate until XMPP gets some love ( https://forum.cloudron.io/topic/10465/xmpp-server-prosody/26?_=1723504540984 )

@nebulon Okay, thank you very much. I think it could be good also keep some options for non-developers that allow users to import and export mailboxes, avoiding REST APIs that require deep knowledge of development. This aligns with part of Cloudron's payoff: 'Self-hosting has never been simpler.' Thank you very much!

Thank you that made me understand the differences quite well. Sadly it seems like the issue is not resolved yet though. The Outlook client seems to stay slow. It was just shortly working a bit better it seems. What I don't understand is the following though: Only the modern Mac Outlook is slow/buggy. If I switch to legacy outlook there are no Problems. Thunderbird is having no Problems as well, same with other clients. I found out though that when I enable Offline Mode in the modern Outlook Mac client, then the search is not slow anymore. Still there is the problem that Attachments are buggy and when you try to open them Outlook says that they have to be redownloaded to open them (which does not work). The modern Outlook for Mac does work with other IMAP clients though. So It's not Purely an Outlook problem and not Purely a Cloudron Mail problem. There just seems to be a problem in the communication between them. I just seem to no be able to debug it. Does anyone have an idea what it could be?

Have you tried to setup the DNS records as suggested by the Cloudron dashboard? Mostly from your screenshot this seems like you have to add the Cloudron in question to the SPF for sending out mails and fixup the PTR pointer. Lastly it appears your IP is on a blocklist, so you should try to get yourself off that by contacting the blocklist provider. Alternately you could of course also setup an outbound mail relay as @joseph earlier suggested.

I enabled Dynamic DNS in Cloudron. Then, I turned off the VPS, deleted its IP's (ipv4 and ipv6) and reassigned new ones. Manually updated DNS record of my. to point to the new domain and it came up in 2 mins. Resynced DNS and it looks like the SMTP issue is fixed.

@samuelandert-eth the way it works is that Haraka (the mail server) parses the HTML and injects HTML signature. Maybe it's failing to parse apple mail content properly. Do you think you can paste the source of a sample apple email at https://paste.cloudron.io ? This will help us debug further and fix the issue.

Is it maybe possible to change the order in which incoming mails are filtered? With sieve you can tell the server to discard mails that match certain criteria, but that only works for mails that have not already been classified as SPAM. i suspect this is not that trivial though because the sieve filters work at the mailbox level.

Yes they are added via the custom spam filtering. I have to check with the client as to whether they are going to inbox or junk folder, they might be expecting them to be blocked outright. Also some spam has the key words as sender name, rather than in the subject... Not sure how to classify that.

@CRBear said in Mail server: IP address verification?: Am I correct in understanding that the email server checks from which IP address a connection is established to send an email and by default, it verifies against the Spamhaus blacklist? The mail server does not make any check for outbound email. The various checks you see in the Email Status tab are purely diagnostic. The idea is if one or more checks are failing there, most likely the email won't be delivered. The Spamhaus is checked for inbound emails though. The DNSBL zone against which it checks is configurable at https://docs.cloudron.io/email/#dnsbl

Interesting. I contacted the provider and told about the problem. They wanted screenshots. After another test all works fine again. Thanks for your help!

That probably works for those apps yes, still a proper relay is recommended.

So i found the error, it is because Hetzner close the port 25 by default on new dedicater server, so you just have to ask them to open it. Bisous les copains