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.

In reference to this post, it would be good if emails from specific senders and hosts could be rejected or discarded before they reach users' mailboxes. Currently, unless the IPs are on a blocklist the only way to achieve this is by blocking the IP via the network settings (but this is only effective if the spam comes from the same IP or range). Mails from specific senders or hosts that are not classified as spam can be discarded with filters, but as soon as they are classified as spam the filter is ignored. This doesn't seem logical.

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.

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.

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

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

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

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

@sixguns said in SendGrid is over, what to use instead?:

But I think Coudrons built in email will provide transactional emails and therefore may be worth subscribing to, "if" I'm correct, need that verified.

Cloudron's mailserver is absolutely fine for transactional emails but only if your server provider does not block port 25.

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