Cloudron Forum

@p44 Just a quick update: I moved the backups to Exoscale a week ago and so far no issues at all. The backups also complete faster. Due to Hetzner's minimum price per month for object storage it won't actually be more expensive either.

@p44 I have looked at Exoscale and will probably give it a try. I am happy to pay a bit more for reliability.

Hetzner are now reporting a problem with S3 that has yet to be resolved.

@p44 I moved from Storage Boxes because it was also unreliable. I am aware of other posts relating to Hetzner but none seemed to refer to S3 timeouts.

I will test with another provider. Need the DC to be in Germany. Had thought about trying Ionos but it looks like there are issues there, too.

Perhaps somebody here has had good experience with Cloudron backups to another EU provider with DC in Germany. Ideally not horrendously expensive.

Is anyone else experiencing instability with backups to Hetzner object storage? Over the past few weeks backups have been taking much longer than usual and regularly fail altogether due to timeouts while copying. This is with locations Nuremberg and Falkenstein.

This is not really a Cloudron problem as far as I can see, but as Hetzner status is not reporting any issues generally with object storage and it does work some of the time, it would be good to know whether other users are experiencing similar issues.

@webliska Is this resolved now?

Maybe reboot the server for good measure as well.

The log entry shows that the email originated from an IP in Indonesia which does not have the best reputation (the ISP is PT Centrin Online Prima) and was sent whilst logged in as dikshant@... Does this information help you to identify the connections?

If you do not recognise the connections, check some of the other log entries. Are the mails all being sent from the same IP? If so, you could block it in the network settings. If not, do you see a pattern?

@matix131997 Direction outbound just means mail leaving the server but the origin can still be the server itself. This is why we also need to see the second log entry. In either case the sender has access to the account and there is a good chance your app password theory is correct.

@webliska Not the mail queue, the queued for delivery log entry for the mail you already posted. Each successfully sent email should have two log entries: queued and delivered. You might need to change the display filters if you only see delivered.

Also check whether an app password is set for the mail user in question and delete it if it is.

Please also post the log entry for queued for delivery for this email, remembering to also obfuscate any sensitive information such as hostnames.

Is there maybe an app running which is configured to send email via that user's account? If so, maybe the app has been compromised and is sending out emails.

You might want to consider temporarily disable outbound email for this domain until the the issue has been resolved. This may not be an option of course as it would impact other addresses on the same domain.

The email headers would be interesting here as @matix131997 already mentioned.

Definitely change the password on the compromised account if you have not already done so. That should stop these emails. If you allow this to continue you risk having your server's IP blacklisted, which will then affect the deliverability of legitimate emails.

This is not email spoofing but emails being sent from the respective account on your server.

@lewisl Nobody here is likely to be hurt by your comments. Of course things can be improved, and nobody is denying that, but maybe a subject line with something like "suggestions for improvement" would have been more appropriate. Some of the "so many problems" you mention are just your opinion and refer to issues you yourself had (and can probably fix with the suggestions) or ideas. Perhaps something to think about when giving feedback in future. You might then get a different reaction from other users.

@lewisl

I also feel this is very much an unwarranted, extremely subjective opinion, and the statement "Cloudron is a clever idea, failing extensively in implementation" an inappropriate generalisation. If it really were failing to this extent, I am very sure we would see a lot more threads here with similar issues.

Of course Cloudron isn't perfect. If somebody feels Cloudron isn't suitable for a person's needs or it doesn't fit their expectations, that is of course perfectly fine. There are other options available. However (and this is of course just my opinion), don't register with a forum and then post as a first topic with the subject "so many problems" a list things which you personally don't like about a product or service and package them as a list of issues that need to be fixed as a matter of urgency.

Credit to @james and @girish for replying so professionally. Let's hope @lewisl has the decency to acknowledge this.

I think the mail is clear (technical support -> forum) but just to avoid any misunderstandings maybe consider specifiying what is meant by senstive issues (licensing, billing, legal, issues requiring the sharing of data).

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.