Cloudron Forum

LibreTranslate
Free and Open Source Machine Translation API, entirely self-hosted. Unlike other APIs, it doesn't rely on proprietary providers such as Google or Azure to perform translations. Instead, its translation engine is powered by the open source Argos Translate library.

https://libretranslate.com
https://github.com/LibreTranslate/LibreTranslate

Seems like a nice addition to the app collection. Appears it would be a relatively simple integration. I'd love to see this as somebody who heavily uses translation services.

This is easily achieved with standard postfix system packages, but Cloudron obviously uses 25 so a built-in Cloudron feature for security and observation, auditing, would be great.

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!

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.

Setting "script-torrent-done-enabled": false fixes it.

Absolutely 100%
Came to the forum to see if there was yet a request for this.

Better yet, would be ideal starting with this since Invidious still (unfortunately ... ) hasn't made its way in to the app store.

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?

Unsure if related to this, but as soon as my file is complete, it disappears from the Transmission UI.

If I upload the exact same .torrent again, it will re-download the file in full (yes redownload, not just verify files already on disk), and once complete, will remain in the UI.
Seems like bug behavior. The file is available on disk after it is completed and disappears from the UI.
Here is a GIF of the behavior.

I see references to purge actions in the torrentDone.js file. Could it be a bad script? Assuming it has been modified for Cloudron.

@girish Belated marking as resolved for anybody looking in future. girish did some remote ssh support magic and solved the problem.

Pages don't render due.

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

Thanks

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

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.

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

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

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.

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

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 Damn. I wasn't expecting resolution that rapidly!

Thanks! Updated. Solved.