Indeed, currently catch-all has to have the feature to set mailboxes across domains (like aliases).

@d19dotca Thanks for your suggestions! I will try and work on it and report back in case of progress or success....

Much appreciated!

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.) Anyway thanks for your help!

BTW, for the "dot" thing, the mailbox separator in Cloudron is ".". This is why folders with dot don't work. If you create a folder named "foo.bar.baz", it is like subfolder bar under foo and subfolder baz under bar. While using "." as a seperator is not a bug as such, using "/" as a separator instead of "." would have been a better choice for Cloudron but we didn't know this when we started (sadly, "." is the dovecot default too). And also using "/" as separator is required for mailbox sharing to work. We are slowly working towards moving the separator to be "/", step by step.

@d19dotca Maybe you can try something like this: docker exec -ti mail /bin/bash Edit /run/haraka/config/tls.ini Add the secureProtocol line like below (be careful not to add it to the end since it has to be outside any section): ; default tls version and ciphers come from node (better to upgade node than set them here) secureProtocol = TLSv1_method [no_tls_hosts] 172.18.0.0/16 127.0.0.1 supervisorctl restart haraka Does it work after that? Unfortunately, the above changes are not persisted. So, you have to make the changes on server restart and sometimes on cloudron update (if we updated the mail container).

OK, with @NCKNE 's help we got this figured out. Cloudron has a anti-spoof check where we don't allow external servers to send email with FROM address set to any incoming domain. In this case, a backup MX is relaying email to Cloudron and it is correctly detected as spoof-ed email. The workaround is to simply whitelist the MX's IP in the SPF record. With this Cloudron has the "authorization" that the server is allowed to relay such email and accepts the mail. I have added a section in our doc here - https://cloudron.io/documentation/email/#alternate-mx

Upgrade went well - all good on v5.1.3 now

OK, I will try to reproduce it locally and reach out if required. Thanks!

@girish this all sounds great - looking forward to the next release! It would also be really nice if there was a simple way to limit the visibility of apps by domain (perhaps using groups?). I realise that at present it's possible to create groups and then limit access to specific apps to specific groups, and that could be used now to achieve this, but I'd like a quicker and easier way to say to Cloudron: "this group has access to all apps on this domain" (but none of the other domains) than having to do it app by app. Make sense?

Yes, you can install other plugins as well - https://cloudron.io/documentation/apps/roundcube/#plugins

@girish Thanks for the info Girish! Actually 1 matters most for their use case so that's great to know. 2 would be nice but not essential to them for now. You are doing an amazing work, and all the lately stuff on conferencing apps has been greatly appreciated!

@necrevistonnezr I actually wrote a post about migrating email hosts using the imapsync tool that girish recommended, you can check it out here. Note that my post is a bit more extensive as I also migrated registrars and had other active emails there that weren't mine, so yours should hopefully be a bit easier than the whole tutorial!

@iamthefij Well the you can make it so you're not discoverable unless you message the person. Thats pretty anonymous

Is just DKIM and SPF not required or generally that domain not for sending out emails? If the latter is the case, the checks can be disabled by setting the Email Relay to "Disable" in the Outbound tab of the Email settings for this domain.

@nebulon said in Do the Cloudron MailServer have a TRACKER_ID ?: thunderbird plugins installed? you got me, I forgot my mailhop plugin ;s

I have pushed out 1.4.2. Note that the package is a "major" version upgrade since the UI is kinda different (so you have to click update manually in the Cloudron dashboard, it won't auto update).

My point of the 443 port issue was so ya'll could fix the docs. I have manually setup SRV records, that's why I thought it'd be nice to automatically set them up. Also, I meant to put this under discussion, not sure how it ended up in support. Thanks.

@subven I use sendgrid with great success

@d19dotca Indeed, there was a typo in the eventlog code. I have fixed it for the next release - https://git.cloudron.io/cloudron/box/commit/ae5722a7d4865a1924737a7e7d1697c6c9b94d6e