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.

@archos I think you are maybe misunderstanding something here. Users and customers are not the same thing. Users are support staff who log in to Freescout and can reply to tickets. Customers should not have accounts / be able to log in at all as otherwise they will indeed see - and be able to reply to - all conversations in mailboxes they are allocated to.

Customers can access their own tickets if you have the module End User Portal: https://freescout.net/module/end-user-portal/. What they see there is linked to their email address(es) and the respective mailbox in Freescout.

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.

I can also recommend the Custom Fields and Workflows modules.

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

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.

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.

Thanks, @girish
FYI, in the notification it says "Email Status is checked every 30 minutes. See the troubleshooting docs for more information." This appears to be incorrect then. The notification does indeed only come once every 24 hours.

I couldn't resolve this but discovered that it isn't in fact as complicated as I thought it would be to migrate to the Freescout App. Just in case anyone else comes up against this challenge:

1. Install and setup Freescout app
2. Drop all the tables in the database and import database from previous installation
3. If you have any modules: upload module folders to storage/modules
4. Upload attachments folder to storage
   Done

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

I have heard positive feedback from people who use Postmark. Azure blocks port 25 (unless you have an enterprise subscription), so it is not even technically possible to send mail directly from Cloudron.

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.

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

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

The correct syntax for the php.ini file is Name = Value:

post_max_size = 6000M
upload_max_filesize = 6000M
memory_limit = 1024M
max_execution_time = 6000
max_input_time = 6000
session.gc_maxlifetime = 1200

The syntax you used is for .htaccess files.