What's coming in Cloudron 6.3
-
@girish Weird... I'll wait for a new app update an check again with cache cleared. It seemed to still be an issue with 6.3.3 but again, could be cache
-
@girish said in What's coming in Cloudron 6.3:
spam still cannot be handled by user's sieve filters because the spam filtering is done before user sieve filters are run
Just for clarity... are you saying Spam will never forward from a mailbox either then if marked as Spam by SpamAssassin since it "cannot be handled by users sieve filters"? Or are you saying if the mailbox is set to just redirect all messages that it'll still include spam message forwarding then too?
For what it's worth, until all the spam filtering improvements appear in a future release, it may be better to focus on making that optional for mailing lists until such spam improvements are made. Spam filtering should never be forced on anyone (I've made calls for that too when discussing Spamhaus for example), there should always be a way to bypass spam filtering when needed whether mailbox or mailing list, and that option should exist for any admins.
To be fair, I just re-read my original feature request and don't think I made it obvious at all it should have been an option, so that's on me as I may have unintentionally mislead you to thinking it should be a forced setting for all. It was definitely my intention for it to be optional. Similarly, I had also noted in that very same feature request "the ability to set a threshold number to avoid false-positives" specifically because if it's marked as spam to the mailing list it's then completely lost and can't be seen later unlike a mailbox that still keeps it in the spam folder for viewing, meaning it may be necessary to set a less-rigid spam threshold (from 5 default to say 8 for example) when it comes to rejecting mail to mailing lists.
Just some food for thought anyways.
In the meantime, I've created a mailbox again (moved away from mailing list) for this particular user and hoping that all messages (including spam) are redirected to them.
Sorry again Girish for possibly misleading the feature request and having an issue right away, haha, I admit it's a bit of an edge case because of the sensitivity of this particular recipient's job (a doctor) which means that all spam filtering should be on their side, not mine which is why I needed that option.@d19dotca I think a mailing list not forward spam is correct (same way there is no option to not filter spam for mailboxes). I think what is missing is letting admins define what spam is and have more spam control (through this they can also define nothing is spam too). That said, I will see how much work all this is and decide on a short term checkbox or long term spam control.
-
@d19dotca I think a mailing list not forward spam is correct (same way there is no option to not filter spam for mailboxes). I think what is missing is letting admins define what spam is and have more spam control (through this they can also define nothing is spam too). That said, I will see how much work all this is and decide on a short term checkbox or long term spam control.
@girish I agree that the spam filtering needs to be improved and in most cases it'd be fine to block spam to mailing lists (I basically wrote those feature requests after all haha), but that's part of the issue here too... in order for that new feature of not forwarding spam on to mailing lists to be effective and non-problematic (keyword there), we need those extra controls around identifying spam and setting all the different SpamAssassin options and such.
Until those extra controls arrive (it's understandable that'll take a while), the new feature can cause some unintended consequences for some since it didn't come with the ability to at least disallow spam filtering on a mailing list. There will certainly be cases where the spam filtering should be done on the recipients end, not Cloudron's end because at least if their spam filter catches it they can still see it in their junk box, but if the mailing list on Cloudron catches it then it's gone forever, so there's a bigger risk of Cloudron doing it for some types of accounts.
I would strongly encourage that ability to disallow spam filtering on mailing lists for those who need it at least until the better spam filtering is added to Cloudron along with all the other important mail features we've been clamouring for.
Right now, that feature - while useful in probably 90-95% of cases - is also now a detriment to the remaining percentage without extra controls in place.To be fair, maybe I'm misusing mailing lists though. I used them because it was much easier to manage for accounts which need to simply forward on to a different mailing address. Maybe I always should have been using mailboxes for that use-case? So I'll admit maybe part of the issue here is more the way I'm using it, but I still stand by the fact that the feature is a bit "half baked" without the ability to disallow spam filtering on them for sensitive accounts, and I hope that will be fixed until the time that the spam features are added down the road.
--
Dustin Dauncey
www.d19.ca -
@girish I agree that the spam filtering needs to be improved and in most cases it'd be fine to block spam to mailing lists (I basically wrote those feature requests after all haha), but that's part of the issue here too... in order for that new feature of not forwarding spam on to mailing lists to be effective and non-problematic (keyword there), we need those extra controls around identifying spam and setting all the different SpamAssassin options and such.
Until those extra controls arrive (it's understandable that'll take a while), the new feature can cause some unintended consequences for some since it didn't come with the ability to at least disallow spam filtering on a mailing list. There will certainly be cases where the spam filtering should be done on the recipients end, not Cloudron's end because at least if their spam filter catches it they can still see it in their junk box, but if the mailing list on Cloudron catches it then it's gone forever, so there's a bigger risk of Cloudron doing it for some types of accounts.
I would strongly encourage that ability to disallow spam filtering on mailing lists for those who need it at least until the better spam filtering is added to Cloudron along with all the other important mail features we've been clamouring for.
Right now, that feature - while useful in probably 90-95% of cases - is also now a detriment to the remaining percentage without extra controls in place.To be fair, maybe I'm misusing mailing lists though. I used them because it was much easier to manage for accounts which need to simply forward on to a different mailing address. Maybe I always should have been using mailboxes for that use-case? So I'll admit maybe part of the issue here is more the way I'm using it, but I still stand by the fact that the feature is a bit "half baked" without the ability to disallow spam filtering on them for sensitive accounts, and I hope that will be fixed until the time that the spam features are added down the road.
-
@d19dotca I understand the impact of the change. Let me see if we have a few more hit this before making changes. It requires another full release cycle (a new mail container, new translations, new ui elements etc).
@girish Okay, thanks Girish for understanding.
In the meantime I'm using the mailbox route again for the few addresses where I don't want to be doing spam filtering / preventing the recipient from receiving spam messages.Relevant thread spin-off: https://forum.cloudron.io/topic/5277/spam-messages-forwarding-correctly-via-forwarding-sieve-rule/1
-
FYI it looks like, at least in Firefox, the update button might be inside the <a> tag for the app itself? It always opens the app in a new tab in addition to taking me to the update page.
@atridad said in What's coming in Cloudron 6.3:
FYI it looks like, at least in Firefox, the update button might be inside the <a> tag for the app itself? It always opens the app in a new tab in addition to taking me to the update page.
Actually I am seeing this issue now as well, not sure why it didn't happen when I tested this yesterday. Anyways I've pushed a fix for that now.
-
Something for the stats: 10 minutes for a Cloudron instance with 6 cores, 32 GB RAM, Ubuntu 18.04.2 LTS. 42 apps from Cloudron 6.2.8 to Cloudron 6.3.4
-
Problem for me after updating to v6.3.4 running on Ubuntu 18.04.4 LTS.
Matrix (Synapse server) seems to be running, but sending messages on Android and Windows not working anymore...edit:
i moved this topic to https://forum.cloudron.io/topic/5291/problem-with-sending-and-receiving-message-s-android-windows -
Problem for me after updating to v6.3.4 running on Ubuntu 18.04.4 LTS.
Matrix (Synapse server) seems to be running, but sending messages on Android and Windows not working anymore...edit:
i moved this topic to https://forum.cloudron.io/topic/5291/problem-with-sending-and-receiving-message-s-android-windows@dantheman this maybe be better discussed in the matrix/synapse forum section as most likely this has nothing to do with the Cloudron update. If you have any further logs or error messages, please create a topic at https://forum.cloudron.io/category/50/matrix-synapse-element
-
@girish said in What's coming in Cloudron 6.3:
Make email setup inside apps optional. This will make it possible to configure specific apps to use some external service for mail delivery directly and the Cloudron package won't touch their mail settings.
This one is implemented now in the Email view. The app package has to explicitly say whether it supports this feature or not using the
optionalflag to thesendmailaddon.
This post is deleted! -
Hi,
a small ui glitch (at least it seems so to me) I just noticed in 6.3.4. When there is the update symbol for an app on the dashboard, clicking on it always brought you directly to the update screen in the past. In fact it still does, but additionally it now opens the app in a new tab.
-
Hi,
a small ui glitch (at least it seems so to me) I just noticed in 6.3.4. When there is the update symbol for an app on the dashboard, clicking on it always brought you directly to the update screen in the past. In fact it still does, but additionally it now opens the app in a new tab.
-
Hi,
a small ui glitch (at least it seems so to me) I just noticed in 6.3.4. When there is the update symbol for an app on the dashboard, clicking on it always brought you directly to the update screen in the past. In fact it still does, but additionally it now opens the app in a new tab.
-
G girish unpinned this topic on
-
There will be a 6.3.6. It's going through the CI, it has many minor changes and also an important security fix (the last item)
[6.3.6]
- Fix broken reboot button
- app updated notification shown despite failure
- Update translation for sso login information
- Hide groups/tags/state filter in app listing for normal users
- filemanager: Ensure breadcrumbs and hash are correctly updated on folder navigation
- cloudron-setup: check if nginx/docker is already installed
- Use the addresses of all available interfaces for port 53 binding
- refresh config on appstore login
- password reset: check 2fa when enabled
- Fix crash due to wrong Spanish translation for invitation email
-
There will be a 6.3.6. It's going through the CI, it has many minor changes and also an important security fix (the last item)
[6.3.6]
- Fix broken reboot button
- app updated notification shown despite failure
- Update translation for sso login information
- Hide groups/tags/state filter in app listing for normal users
- filemanager: Ensure breadcrumbs and hash are correctly updated on folder navigation
- cloudron-setup: check if nginx/docker is already installed
- Use the addresses of all available interfaces for port 53 binding
- refresh config on appstore login
- password reset: check 2fa when enabled
- Fix crash due to wrong Spanish translation for invitation email
-
@girish We did all the translation into Spanish. What was the problem and in what sentence?
@mdreira there were just some syntax errors like extra whitespace for example:
<% = invite Link %>a space between
%and=as well asinvite Linkwithout the space
or<%= inviteLink%>and this also, where between
inviteLinkand%a whitespace was missing. Fixed version is now at https://translate.cloudron.io/translate/cloudron/dashboard/es/?offset=1&q=inviteLinkActionText&sort_by=-priority%2Cposition&checksum=Most likely just autocorrect of your browser or copy and paste issue, so easy to fix once I found out. But would be nice if we could make weblate catch this somehow for us.
Ejs, which is the template engine we use here, is quite picky.
-
@mdreira there were just some syntax errors like extra whitespace for example:
<% = invite Link %>a space between
%and=as well asinvite Linkwithout the space
or<%= inviteLink%>and this also, where between
inviteLinkand%a whitespace was missing. Fixed version is now at https://translate.cloudron.io/translate/cloudron/dashboard/es/?offset=1&q=inviteLinkActionText&sort_by=-priority%2Cposition&checksum=Most likely just autocorrect of your browser or copy and paste issue, so easy to fix once I found out. But would be nice if we could make weblate catch this somehow for us.
Ejs, which is the template engine we use here, is quite picky.
