Cloudron Forum

Thanks!

Resolved.

Pages don't render due.

New update was pushed an hour ago - https://github.com/invoiceninja/invoiceninja/releases/tag/v5.7.36

Thanks

@girish I have a great idea.

Directly under "Check for Updates" in the app settings page, there could be a "Notify" button. And perhaps a field for allowing any optional comments to be sent to the team with the notification.

Search engines have been broken for weeks and the app remains without updates despite fixes pushed weeks ago.
App install page reports "This app packages SearXNG 81b729161" which is 3 weeks ago in September.

Any particular reason these aren't being updated? These types of apps (searxng, yt-dlp, meta/alternate interfaces etc) rely on ever dynamically changing interoperability and they just break if not maintained.

Thanks for the response and input. Albeit one side note is that this post is more of a specific implementation that I'm considering based on my objectives, and initially less about a general 'feature suggestion'. Although it seems my idea does certainly invoke the feature suggestion aspect too. And now I'm glad I posted.

As it stands currently, I think you're probably right about the best way to implement this concept. The downside, however, is I'd likely need to hire a dev to conjure up an API based registration page to feed Cloudron. It's just not my skill set. The WordPress component would have negated that and as such was a primary benefit of using it, in addition to the full subscription management and fiat/crypto payment capabilities that come along with its extensibility.

Appreciate the insight

@girish said in Further Locking Down Email:

@xarp note that all newly registered domains and new cert issuances are basically available online. For example, https://crt.sh/ and https://certstream.calidog.io/ . https://dnpedia.com/tlds/daily.php shows newly registered domains... It's easy to get lists from those sites and feed them into some bot code.

That's it, that'll do it. Thanks for the reminder.

I feel like this idea has probably been discussed or presented. But perhaps I'm thinking of it in a way that's making me foggy on locating the clearest answer.

Scenario:

• WordPress is the front facing website
• The WordPress is running on Cloudron, which is also running a bunch of other apps
• You want users to be able to register an account via your front facing WordPress and in turn have a Cloudron account provisioned to provide 'membership authenticated' access to xyz apps via LDAP/SSO/etc.

IE a membership walled garden (with Cloudron acting as identity provider) for your installed apps that can be handled/automated/interfaced with via WordPress public front end and subsequent subscription management/payment plugins. Kind of like two-way synchronised LDAP.

What would be the best practice and direction to go in this instance? I'm pondering over possibilities in the directory server section of docs page.

The most 'traditional' method of doing this, in my mind, involves a CRM with n8n type automation to achieve what's desired.. But I'm thinking if this can all be drastically simplified by all being in the same Cloudron ecosystem.

(I'm aware not all apps support centralised account management, instead managed individually at app level, and this would be another hurdle.)

Drop me your thoughts and help set my mind straight. Thanks!

Another thing that's interesting is it's hitting all my domains activated for email. Despite some of them basically never ever being used or given out. It's like a bot has harvested all the domains associated to my Cloudron instance somehow. Could this be something akin to the domain TLS cert info harvesting method (think solved now)? Some method to centrally obtain all in-use domains operating on the server

Has anyone else been getting hit a lot recently with spam connections?
What I find peculiar is the consistency in type of random connection attempts. What do you think one is trying to achieve by trying random aliases/accounts in this fashion? It's not even remotely close to real world accounts, just random strings of letters and numbers of similar length.

These are coming from IP addresses in all sorts of countries - Hong Kong, Bangladesh, Russia, United States, Netherlands, South Korea, etc. Makes me think it's from some type of botnet.

@girish any input possible? Doesn't seem it would be too difficult to implement.
In addition to server rejecting "To" domains (e.g. me+taggedwebsite@mycloudron.com), same with "From" (e.g. spammerphisher@fakedomain.com)

That's right. I had expected in 7.4.0 to be able to open settings for an App Proxy and tick a box (or similar) enabling authentication. But glad to know it's on the road map somewhere.

It seems the new proxyAuth feature has to be configured in the setup of custom manifest add-on. Why can this not be added to the settings page of an App Proxy so it can be configured on the fly?

@d19dotca Since this hasn't received any traction, would you mind assisting with your SpamAssassin discard rule in context that would be acceptable via Cloudron? It seems the syntax isn't allowed.

Is there any way discard can be achieved using the single line approach that cloudron docs/examples illustrate? Thank you!

The workable examples given are:

header SUBJECT_HAS_DISCOUNT  Subject =~ /\bdiscount\b/i
score SUBJECT_HAS_DISCOUNT   100
describe SUBJECT_HAS_DISCOUNT    I hate email discounts

If not, I can try going in and editing the config file directly, if it even exists. Thought I'd try here first given editing stuff directly isn't always the best idea with Cloudron. If it even manages to persist.

@d19dotca To make it really simple:

I blacklist me+website@myemail.com
All email arriving that matches receiver address me+website@myemail.com is SMTP rejected.

This is great for when websites or mailing lists get compromised and there is just an endless spam campaign on that address. I can ban the address at server level and now that address is forever blackholed.

I can go to the website in question, if I choose, and simply update my email address with a new tag, thus effectively generating a new non-spammed contact for which they hopefully won't get compromised again. If so, rinse repeat.

On Mail-in-a-Box, you'd just run a command on console with the block address parameter and address to block. Very easy. Forever SMTP rejected until removed again.

@d19dotca said in Reject mail at SMTP level, address blocklist:

To reject email at the SMTP level, you need to use a DNSBL which is documented here (it essentially runs before SpamAssassin even sees the message but doesn't allow you to control which addresses are involved, only if it's a "true" then reject and if it's "false" then continue processing): https://docs.cloudron.io/email/#dnsbl

Thanks for the reminder. I've added two extra blacklists to the default.
The primary feature request still stands though.

Surely it can't be difficult to implement SMTP reject when the devs are able to get around to it.

@privsec Is SpamAssassin able to issue SMTP reject?

I use email tagging (myemail+xyzfuturehackedwebsite@mydomain.com) and would like to be able to use the address blocklist feature to completely reject (all emails) to designated addresses at SMTP level, as opposed to having Cloudron flag them as spam and put them in the respective folder.

Years ago I used Mail-in-a-Box and this feature was built in and configurable via the command line. Used to make abandoning tagged addresses a breeze. They would be permanently banished from my mind.

I can't help but be honest that it triggers me when spam constantly shows up in my spam folder without my ability to nuke their attempts at even hitting my email server.

What do ya'll say? Can this be implemented easily in a future update please?

The only reference I found to the same was in this thread.

@scooke Applies to most things. But it is not recommended to install anything alongside Cloudron. Keep it clean or things could go wrong and then you've acted against best practices advisory.

@girish Damn. I wasn't expecting resolution that rapidly!

Thanks! Updated. Solved.

A nudge regarding app package Trilium which has new versions available 0.54.2

To note - Trilium is more burdensome re update adherence due to sync inability that occurs if server/client versions are mismatched.