Cloudron Forum

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

Yeah, email ids don't go via LDAP. Email ids and aliases are restricted because in other email systems people can use _, - and + as subaddress. Cloudron only supports + right now but might extend it to - and _. @nebulon IIRC, the _ restriction comes when we had 1-1 mapping between username and email. Maybe it's not relevant anymore. I am more open in allowing it in usernames than mailbox names.

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?

@robi said in Roundcube Login: Oh I see, so it's not FF integrated in Hamsket, it's just another instance of FF (portable). Can you run more than one instance? You can on Windows, as many as you want. Don’t know about Mac/Linux.

Members only flag was added in 5.2

@girish Yes, that's what I meant - that would be awesome!

@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.

Gotta give a shoutout to SSDnodes for large systems and low prices and you choose your PTR. Link below in signature.

@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

yes, that tag-input component has several other small bugs and we should really replace it. If anyone knows a good angular1 based component to replace it, ideas welcome

@rfg Agree that Cloudron should not accept emails from spoofed sources. We do have code and configuration in place to block this. Let me investigate.

Also, note that changing the nameserver sometimes takes a bit of time. So, you might have to wait a bit between step 2 and step 3.

@d19dotca Currently, there is no way. The SA settings are set in stone. I can open up our mail addon git repo tomorrow so you can get a better idea of how we have implemented it. But overall, our idea was that customers don't have to deal with implementation details like SA (for example, maybe we use rspamd later) and that spam detection should just work. If you have SA expertise, I am happy to incorporate your suggestions into the default settings.

@girish I just wanted to add another reason why we need better spam control exposed to admins... I just had a client who had their home IP address blacklisted by Spamhaus in their PBL because of the range of IP it was found in, even though they were not spamming at all (since the PBL blocks IP ranges). I have asked for it to be delisted but it'd be awesome if in the future I could just whitelist the IP address or something like that to quickly resolve it for them. Update: Just found https://cloudron.io/documentation/email/#blacklist-domains-and-ips which is for blacklisting but I extrapolated from that and found the related whitelist files too, so used that. This needs to be added to the docs. I will see if I can submit that change in the git for you guys. With that said though, it'd still be nice to see this exposed in the UI so if an admin is on the road / unable to SSH to the server, it can be easily whitelisted still.