Cloudron Forum

@AartJansen You can do this already with Spamassassin rules, for example:

header CASINO_SUBJECT Subject =~ /\bcasino\b/i
score CASINO_SUBJECT 10

These mails will be moved to the Spam folder and could be retrieved if false positives.

Trying to add aliases for emails accounts I wish to move over to Cloudron I am coming up against this error:

mailbox name can only contain alphanumerals and dot

The addresses contain underscores which are valid in email addresses. I think this is a bug as hyphens are accepted as they should be.

Just reviving this thread to see whether anyone is still interested in attempting to package Canvas LMS for Cloudron. Would be great to have it available as an alternative to Moodle.

@subtlecourage

It's very simple. Just spin up a LAMP app with something.mydomain.com as the location. Then, in the file manager create a file .htaccess in the public directory with the following content:

# Permanent URL redirect 
RewriteEngine on
Redirect 301 / https://externaldomain.com/path

Any requests to something.mydomain.com will then be forwarded to externaldomain.com/path

There is plenty of documentaton on this if you do a Google search for 301 redirect .htaccess. there are also generators that will provide you with the correct code for different scenarios, for example redirecting specific pages.

When you send and receive email with an email client you are logging in to the mailserver and there is no 2FA for IMAP or SMTP.

@jdaviescoates This is one of the problems with pre-built apps provided as packages for server platforms, and I have encountered this with other companies as well. If providers are not willing to ensure that these packages are kept up-to-date, then the benefit for the customers is minimal and sooner or later they are going to run into difficulties. It would therefore be interesting to know how easy it is to bring the pre-installed Hetzner versions up to the current versions and also generally what their policy is on keeping these packages updated.

@fproof
Cloudron already has a mail solution which incorporates the same or similar components.

@warg

Haraka is not as widely used as Postfix but it is also hardly a niche product and has been around since 2011. If anything it is down to preference. Cloudron chose it because it is lightweight and efficient and presumably because it best fit their architecture. The IMAP server in Cloudron is Dovecot, which is also used in Plesk.
What are your concerns?

Yes, the best thing to do is just give it a go and see if it fits your needs.

I do exactly what you want to do without any problems. I would suggest deleting the server with the IP that is on a blacklist and creating a new one. You are going to have this issue with other hosters as well as IPs arae allocated randomly. IP reputation is extremely important for the mailserver.

Hetzner allows you to order IPS separately and allocate them to a server. This would be another option.

@DeBossNow

I am glad you got it resolved, but just to clarify:

The MX record is for incoming email. It needs to be set to any domain name that resolves to your server, i.e. has a valid A record. If both my.currentdoain.de and currentdomain.de resolve then you can use either for incoming mail. The mismatch was not with the MX record but between the mailserver domain set in Cloudron and the PTR record of the server. At no point did I or anyone else tell you to change the MX record, and no, the PTR error had nothing to with the MX record. I can therefore only assume that you interpreted MX as being something it is not.

For outgoing mail you need a valid PTR record that matches the mailserver domain. You also need a valid SPF record and a valid DKIM entry.

Because you set up Cloudron via the Linode app you have presumably told Cloudron to use Linode DNS, which is why it is updating / overriding certain settings. If you do not want it to do that you need to set DNS to manual for the resepctive domain(s).

The bottom line is: The PTR record and mailserver domain have to match. Where you make the changes depends solely on the domain you want to use for email, i.e. where the entry needed updating to match.

Btw, I stated every time that you needed to check / update the mail domain in Cloudron, not in the Linode dashboard.

Did you click the link from the apps dashboard or from withon the app settings page? The first time setup dialogue only shows when you click on the link from the dashboard. Not sure if that is intended, but i have noticed this with other apps, too.

@jdaviescoates

I made sure to remove the queued adhoc tasks before updating to prevent that from happening and users receiving notifications of past events. At least you now know that adhoc tasks are working again in your installation

@blaise Not a great start to your membership here in the forum. The response may not have answered your question exactly but that hardly justifies your impolite reaction.

Incidentally, a simple Google search would have found you this:

https://docs.rocket.chat/installation/hardware-requirements

A bit of multiplication and you should have a reasonable idea what you are likely to need.

Edit: I see @fbartels was a bit quicker.

@ianhyzy
Update to 6.2 and that message should go away. Other control panels reported this as well but WP saw no need to act on it as there was no likely risk of it being exploited.

@LoudLemur

I am very sure this clause would be illegal in EU countries under unfair contract terms legislation. At least for contracts with consumers. Not to mention potential conflicts with the GDPR. If this change also affects EU customers it won't be long before they find themselves in very hot water.

What are they trying to achieve here though? No business in its right mind is going to host anything with them if that means consenting to such a license for anything they host.

@jdaviescoates @p44
Many thanks. I'll look at this again later today and report back.

@nebulon Instead of a label, maybe having a coloured dot in the corner of the tile would be a good alternative for immediate recognition of the current state of the app?

@p44 @jdaviescoates Got it working. Thanks for your help!

@robi Only kernel updates should require a reboot, so I had always assumed that the reboot request in the UI appears when there has been a kernel update.

@girish said in Can't discard spam messages on arrival using Sieve filters:

so I think the default behavior is good.

As a default I think so too, but whilst the spam protection in Cloudron is reliable, sometimes the end user wants / needs to be able to filter spam messages directly It would therefore be good to have a simple way of filtering mails to discard spam selectively rather than just having all SPAM go to the SPAM folder. Mails with a SPAMASSASSIN score of over 20, for example, do not need to be saved anywhere, but those with a score of 7 or 8 could in theory be false positives so would warrant 'quarantining' rather than discarding altogether. The same applies to certain sender addresses and subjects.

This does not need to be something defined in webmail clients per domain, but could be a server-wide setting similar to the custom spamassassin rules.