Cloudron Forum

I am considering switching an existing Exim mailserver for a Cloudron instance.

One feature I need to maintain is a custom mail routing rule which allows mailbox addresses with an arbitrary prefix, designed to implement disposable addresses for use as casual log-ins, inspired by spamgourmet.org.

Is this possible with the default Cloudron mail service? Perhaps using some custom configuration, for instance, can SpamAssassin rules do this?

Thanks!

---

I'll explain the use-case in more detail briefly.

I might have a mailbox alice@example.com, and an alias for this, bob@example.com, which by itself doesn't accept mail, but will forward mail to alice@example.com when prefixed with any arbitrary word (delimited by dot). For example, twitter.bob@example.com, yahoo.bob@example.com and ebay.bob@example.com would all forward to alice@example.com by default, as well as any other prefixed address you could think of.

This allows unique email aliases like this to be invented off-the-cuff when creating a log in for a site requiring an email address to register a user account. These addresses can be disabled if and when they start attracting spam (perhaps because the site has been penetrated by malware, and the user data captured and redistributed in spammer databases).

Because they are unique, the addresses also tends to reveal the source of a breach, because the prefix indicates what it was used for originally.

Disabling an address is done by alice@example.com sending an email to one of her aliases with the subject !off, via an authorised connection to the SMTP server implementing the prefix aliases.

If switching to another implementation, the mechanism for managing these aliases could change, but I'd need the addresses to continue working, obviously.

Ok, it's described here: https://docs.cloudron.io/backups/#restore-app

Kobo Toolbox is a tool for collecting survey data. Fulfills a similar purpose to LimeSurvey, but has a somewhat nicer UI, and supports online or offline completion of surveys. It seems to have a fairly active online community.

Data collection is done via the web with Enketo, or on an Android mobile device via the app Kobo-Collect.

https://www.kobotoolbox.org/

KoBoToolbox is a suite of tools for field data collection for use in challenging environments. Our software is free and open source. Most of our users are people working in humanitarian crises, as well as aid professionals and researchers working in developing countries. Our teams of developers and researchers are based in Cambridge, MA and many other places around the world.

Quickly collecting reliable information in a humanitarian crisis – especially following a natural disaster such as a large earthquake or a typhoon taking place in a poor country – is the critical link to saving the lives of the most vulnerable. Understanding the population’s needs is often neglected for lack of quick means to gather and analyze this crucial information. KoBoToolbox, developed by the Harvard Humanitarian Initiative, is an open source suite of tools for data collection and analysis in humanitarian emergencies and other challenging environments that was built to address this gap. KoBoToolbox is funded entirely through generous grants and donations from our partners.

Ok, that's fair enough.

@girish said in No 'resetToken' for admin password reset:

But as you figured you can just put a json in that ghost file /home/yellowtent/platformdata/cloudron_ghost.json and that's it:
{"username": "sometemporarypassword" }

However, this might be worth adding to the documentation.

I guess what confused me is that the "dashboard visibility" option there does look a bit like you're allowing access to members, especially as there's no mention of that LDAP integration option which could go here but doesn't. You need to have seen that option on another app to know that is missing.

What would probably be clearer would be to mention something like "This application does not integrate with Cloudron's account management" or words to that effect on that panel. (I believe I've seen this somewhere else, thought it was here, and expected to see it as a consequence.)

Stating this on the app store description would also make sense?

Scenario: forwarding email addresses from the Cloudron domain to 3rd party email services such as GMail

Problem: when SRS rewrites the email headers to allow the mail to be classified as legitimately from the forwarding Cloudron host, it can also cause the forwarded spam to appear to be sourced from that host, resulting in it being blacklisted.

Potential solution: implement adequate spam filtering for forwarded mail, for which no manual classification can be used to training a filter as could be for a local mailbox

Another possible solution in the case of GMail might be to implement POP3 and allow GMail to pull mail from that. GMail no longer supports arbitrary IMAP servers since releasing its newer "Gmailify" service.

See the original discussion here:

https://forum.cloudron.io/topic/3323/reading-a-cloudron-mailbox-using-gmail

Hi,

I've just attempted to purchase a Cloudron subscription. I'm doing it on behalf of a co-operative company I am a member of. The company has a bank account but does not have a credit card, so I attempted to use my own for now, however, I only have debit cards, and none of mine seem to work. The subscription form says "Your card does not support this type of purchase" for one, and "Your card cannot be charged" for the other.

Is this really the only way to pay, and if so, are there any plans to allow anything else in the immediate future? As it is this is an unexpected show-stopper for our use of Cloudron.

@nebulon I expected it to indicate the absence of LDAP integration in the app's panel on the app store (and the my-apps list). See my other reply above.

Although there is an account setup screen, I don't think that necessarily makes it clear that the application hasn't also got LDAP integration. It could plausibly need a separate administrator account set up for some unknown technical reason, and yet have access for the Cloudron users.

(My previous Cloudron application installs are so few and long ago I don't remember all the details of what to expect!)

@jdaviescoates - this is close, but not quite a cigar, because although this would work when just starting to use this scheme, there's a whole bunch of existing addresses in use using a different scheme.

I think Cloudron's SMTP server is Haraka, correct? Is it possible to install plugins for it this context? (I might be able to write a plug-in.)

@yusf Oh. Doh. Thanks.

So I've worked around this by telling Firefox to "Forget this host" (right-click on an URL to get this option in the history tab), and thereby got to the web console that way.

However, it could still be handy to know how to trigger the renewal from the terminal, as this might not be the only case when you'd need to do it.

@girish, yes - the implementation rules are logically "like *.bob then route it to a specific mailbox", but there is extra logic to handle things like:

• if the alias is marked disabled, drop it
• if the subject is !off and the connection is authenticated as the user in question, disable the alias and drop it
• ...plus some similar things (implementing !on and !report functions)

State needs to be stored somewhere (the implementation uses a SQLite3 DB). So if the wildcard alias plugin does not store state, that probably won't do it.

Implementing this in Exim filter rules is challenging, both to write and to read, but FWIW it's here

Also just experienced this on Cloudron (v7.2.5, Ubuntu 18.04.6 LTS). I'd report this as a bug via the support panel in the Cloudron dashboard, but the "submit" button seems to be disabled even when the form is apparently filled out correctly. Therefore posting here.

---

Users reported that mail wasn't syncing. This is generally not well reported in the clients - in Thunderbird, it just seems to show a spinning "busy" icon when syncing. Therefore it wasn't obvious what the cause was immediately.

No obviously related errors in the Cloudron dashboard's mail logs, but these all seem to be SMTP related.

Tracked down the IMAP log in the mail container, under /var/run/dovecot.log (This doesn't seem to be accessible in the UI or documented on the Cloudron site? Be great if it was!)

This listed errors like this:

Oct 07 08:29:44 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=REDACTED, lip=172.18.0.9, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session=<pGuonG3qbIhQwAEL>

Validated the SSL certificate using openssl:

openssl s_client -showcerts -connect $host:993 -servername $host > $host.certcheck

This included the line:

Verify return code: 10 (certificate has expired)

I restarted the mail service.

The SSL check then seemed included this line instead:

Verify return code: 0 (ok)

Mail syncing then seemed to work normally.

So problem solved for now, but it might reoccur. I infer something isn't restarting the mail service correctly when the SSL cert is updated?

Thanks!

Rereading, could be worth noting for other readers of this thread: the poll2 plug-in (which seems to be marked as possibly not working with this version of NodeBB) is not the same as the poll plug-in (which seems to be marked as working)/ I'm not sure why I had both installed.

I've been testing out the Cloudron github pages app, using approximately the test case outlined in the earlier post here:

https://forum.cloudron.io/post/1889

Although correctly pushing the repository inside the site, so

• gem install bundler jekyll
• jekyll new my-awesome-site
• cd my-awesome-site
• git init
• git add .
• git commit -m 'initial commit'
• git remote add page https://my.domain/_git/page
• git push page master

After the push succeeds, I visit the app's URL, and I see an error:

Error: ENOENT: no such file or directory, stat '/app/data/website/404.html'

Inspecting the contents of /app/data/website/, it's not the built version of the site. It looks like a copy of the latest master branch commit, which intentionally has no 404.html, nor an index.html file.

Shouldn't the app have built the site, and published the result in /app/data/website/?

At the very least I'd have expected some evidence of a _site folder or log entries showing that Jekyll has been run. The logs simply show:

Jun 27 12:01:17 => First run, create bare repo
Jun 27 12:01:17 Initialized empty Git repository in /app/data/repo.git/
Jun 27 12:01:17 => Install welcome page
Jun 27 12:01:17 => Update welcome page
Jun 27 12:01:17 => Ensure git hook
Jun 27 12:01:17 => Ensure permissions
Jun 27 12:01:17 => Run server
Jun 27 12:01:17 Listening on port 3000
Jun 27 12:01:17 Using git repo at /app/data/repo.git
Jun 27 12:01:17 Serving up directory /app/data/website
Jul 05 11:25:59 git: info {}
Jul 05 11:26:11 git: info {}
Jul 05 12:01:34 git: info {}
Jul 05 12:01:40 git: info {}
Jul 05 12:01:40 git: push {
Jul 05 12:01:40 head: '5c044c8e60311e7bb76c61817d3c3b65eededd46',
Jul 05 12:01:40 last: '0095e37ae41807050bb92ead9279c38dfc84151bb247',
Jul 05 12:01:40 refname: 'refs/heads/master',
Jul 05 12:01:40 ref: 'heads',
Jul 05 12:01:40 name: 'master',
Jul 05 12:01:40 branch: 'master'
Jul 05 12:01:40 }
Jul 05 12:01:52 Error: ENOENT: no such file or directory, stat '/app/data/website/404.html'

I was wondering if the build is failing because of Jekyll version differences.

I attempted to match the version exactly. Unfortunately the latest version of Jekyll mentioned in the updates thread (3.8.7) won't install due to errors (Bundler could not find compatible versions for gem "kramdown"), so I used the next version up which will install, 3.9.2. (I note Jekyll has a 4.0 series now).

I'm not sure how crucial that version for the app to work correctly - but I don't see any errors in the logs, so I can only assume it's okay to have a slight difference? If the Github Pages app is very sensitive to version differences in Jekyll, how would I deal with errors such as the one above, due to changes in compatible versions of other gems?

Since the update rolled out last night, on two Cloudron servers I maintain which use Nextcloud and OnlyOffice, we can now no longer open documents in OnlyOffice.

The usual splash screen appears, the loading animation begins, but no percentage shows, and it eventually times out with an error dialog saying: "Connection to the server has been interrupted"

Inspecting the browser console, I see that the websocket connection is repeatedly attempted, until eventually it fails. This is in Firefox on Linux for me, but it has been reported by users on other OSes (Windows I think) and presumably other browsers.

There appears to be no errors I can see in the OnlyOffice app server logs, or the NextCloud logs. the OnlyOffice web page indicates no problems. I've restarted the apps and the server. It still doesn't work. But as I said, the thing which makes me think it may be a problem with the update is that it is behaving like this on two Cloudron instances, running on different servers for different organisations I'm involved with.

Is there anything else I can try to work out what the problem is?

Thanks