Cloudron Forum

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.

@james Should I create a feature request for this?

@james We abandoned the idea of using a separate gateway, but the underlying issue did not get resolved, but I see that I overlooked the question asked by @girish.

The issue is not spam slipping through the SA filters, but that it is not possible to reject / discard mail from certain senders or with certain subjects or coming from certain hostnames. The global SA rules can only set a score based on sender or keywords but there is no way to reject the mails altogether.

Example: Sender spammer@badactor.com regularly sends emails from different IPs. These emails are 100% junk and can / should be discarded and not even forwarded to user's mailboxes. If the host were on a blocklist the mails would be rejected, and if the IP was always the same we could network block the IP, but otherwsie SA rules are necessary. And this is where the treatment of mails is illogical:

If the mail has a SPAM core below 5.0 (the hardcoded SPAM level), it is possible to set up a (albeit mailbox-level) filter to silently discard the mail. If the score is 5.0 or above, the mail will always go to the SPAM folder bypassing the filter settings. In other words, I can discard an email that is not classified by SA as SPAM, but not one that is.

Hope this makes sense.

@bazinga Is there a reason you want to stick with Azure for your VPS hosting? Seems very expensive. Maybe look for an alternative that enables you to host email yourself rather than looking for an email provider you would also have to pay for.

@sixguns The webmail apps Roundcube, SnappyMail and SoGo are simply frontends for the IMAP server, just like mail clients such as Outlook or Thunderbird. Mail accounts you intend to host on the Cloudron mailserver are created in Cloudron under "Email", which I would suggest is also intuitive

I don't want to influence your choice of hoster, but I have used Hetzner for many years without any problems.

@neki The misconfiguration warning is for your IP and has no relevance for incoming mails. That warning is being shown because Spamhaus is not reponding correctly to the request from Cloudron and Cloudron is incorrectly interpreting that as your IP being blocklisted. It is nothing more than a display error though and should be fixed in the next release.

If you are seeing incoming mails rejected due to Spamhaus listing then this is due to the DNSBL checking. The error may well be with Cloudron and how Spamhaus reports are interpreted, but that will be resolved if you deactivate the checks.

@SansGuidon Had you removed Spamhaus from the DNSBL checks? I think the issue is (at least partly) to do with changes in the way Spamhaus processes queries (I noticed a lot of errors in the logs before deactivating Spamhaus altogether) and the way Cloudron interprets the results when errors are thrown.

I have two Cloudron servers, both running version 8.3.2, but one on Ubuntu 22.04, the other on Ubuntu 24.04. Interestingly, the server running on 24.04 does not show the (false) email configuration error, but the one on 22.04. regularly does. As already mentioned, however, that is just an icorrect message and has no affect at all on deliverability as that will depend only on the receiving mailserver.

@neki If you are experiencing problems with inbound mail being rejected, have you tried just removing Spamhaus from the list of DNSBL checks?

@sixguns How do you intend to try out email without an email account?

The documentation has the answers to many of your questions.

@sixguns said in seeking server set up advice:

And if I subscribe the email Cloudron provides can act as a transactional provider for Discourse right?

Cloudron can be used to send emails for the apps installed on it and also from externally hosted apps if you connect via SMTP. You just have to make sure that the everything is set up correctly for the domain(s), in particular SPF and PTR records. And obviously make sure that your server provider does not block port 25. The biggest "issues" with self-hosted email is establishing reputation and ensuring deliverability, but both of those can be easily overcome with Cloudron if you set things up properly.

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

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.

@sixguns I don't think that James wanted to say that Cloudron is the same as Ubuntu or Debian, what he is trying to say is that Cloudron provides a UI for the underlying operating system in that it manages the entire server, including updates for Ubuntu. There are very few situations in which you should need to SSH into the server. In this respect it is actually similar to Plesk or Cpanel, whereas most other panels are focused purely on hosting.

@sixguns said in seeking server set up advice:

I just reinstalled as it's been awhile and I wasn't sure, I can't log-in, just loops "Wrong username or password."

You need to log in with the email credentials which are the email address of the email account you are trying to log in to and the password of the cloudron user the email account belongs to.

@sixguns said in seeking server set up advice:

So can cloudron be used on VM's created by virtualizor?

Try it and see. As long as you use hardware virtualisation (KVM) and Ubuntu 22.04 or 24.04 it should work.

Cloudron really should be able to do everything you are trying to do (apart from AVideo which is not currently available. Whilst it is a PHP application and could run in the LAMP app, it also requires root access to install additional libraries that could potentially interfere with the operation of Cloudron).

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

@joseph Will see what else I can find. It is odd though as no errors are being thrown or logged anywhere and everything actually seems to be working as it should (i.e. the queue is being processed).

@joseph

Thanks for that. A small step closer maybe as putting those two in the cron section gives me the same result as including

/app/data/public/artisan queue:restart

Mail fetching is OK, however, I still get the red text

queue:work Last run: ? Last successful run: ? Try to clear cache to force command to start.

and not 'running' on the status page. Clearning the cache doesn't help.

@joseph

I have discovered the apparent sticking point in the LAMP app, but cannot work out why it is happening:

If I run

sudo -u www-data php8.3 /app/data/public/artisan schedule:run > /dev/null 2>&1

in the terminal I can see all the commands that are executed, the last one being

'/usr/bin/php8.3' 'artisan' queue:work --queue='emails,default' --sleep=5 --tries=1 --timeout=1800 sudo -u www-data php8.3 /app/data/public/artisan schedule:run > /dev/null 2>&1

This executes the queue and it shows as running, but the job freezes until it times out at which point the queue shows as no longer running.

If I run the command via cron the same thing happens, but for some reason the queue is not executed (or at least that is what it shows on the status page). Subsequent cronjobs do not work so mail fetching stops until the hardcoded timeout is reached.

I tried adding a cronjob for

sudo -u www-data php8.3 /app/data/public/artisan queue:restart > /dev/null 2>&1

This works insofar as mail fetching works, but the queue is not shown as running.

Long story short, I think the questions I need answering are why is the job freezing and what is different about executing it via cron and directly via the terminal? The logs show nothing unusual, so I honestly don't know where else to look.

Thank you @james, that is great news.

@joseph Thanks. I had a look but can't find anything that would explain what is happening. I think everything is actually running OK, even though the status page is still saying that queue:work is not being executed.

@luckow Thanks for the link. That is basically what I did, then cleared the caches manually as the server was throwing a 500 error due to incorrect paths in the cache configuration. There are several threads dealing with problems with the queue:work (a common issue with lavarel by all accounts) but none of them quite resolve the problem.

I just found one thread that suggests addditional cronjobs to execute queue:work manually and resart it every hour in case it gets stuck. This seems to have resolved the problem with fetching which is now working every minute, and sending seems to be working as well, although the status page suggests queue:work is not being executed. I'll observe further.

Has anyone successfully used FreeScout in the LAMP app? I need to move an instance from a non-Cloudron server and this seemed to be the best solution considering that there is unfortunately no easy method of copying over conversations from an old install to a new one.

I have everything copied over, set up and working, but the queue seems to freeze when the cronjob runs also causing the fetching of mails to stop. Clearing the cache gets things going again - but only until the next cronjob runs a minute later. I have been unable to find anything in the logs or in the Freescout issue reports that would identify the problem. Any suggestions would be much appreciated.

I would also really like to use Pretix for a project which would be live in a few weeks, but cannot do so if this is not resolved very soon. I appreciate that this app is listed as unstable, but the inability to send emails unfortunately makes it unusable. I do hope this can be fixed as I know a lot of people have been waiting for Pretix to be added to the AppStore for a long time.