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, 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'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?

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.

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.

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

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?

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

I've successfully connected Thunderbird's Sieve mail-filter plug-in to my Cloudron mail account, and created a range of filters.

The problem is, most of these don't seem to work. I shelved this for a while, but I'm trying to work out why, again.

I recall seeing a post in which it was said that Thunderbird's sieve plugin doesn't work with Cloudron's sieve, but I can't find it again. Is that true, and if so, why is that?

I've tried installing Snappymail and the filters are visible in the UI there, they seem like they ought to work. But they don't.

I don't think the problem is because they're working but not selecting the email I think they should, but that is still a possibility. Is there any means for testing filters against Cloudron mail? Even hacky ones...

Thanks!

@girish Thanks for the sanity check. There does seem to have been something wrong with my jekyll site creation. Trying again, it works as advertised...!? I can see a remote: => jekyll build line in the git-push output.

IIRC I did attempt this more than once earlier, and I'm not sure what was wrong.

Anyway, hopefully this thread may nevertheless be helpful for someone else getting started on this.

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?

@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!)

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?

Thanks @jdaviescoates. In other cases, the Cloudron panel in the app store explains that there is no authentication integration - for n8n, I believe it doesn't. This would be useful! Without it, I'll need to rely on that table - which I hadn't found before.

On starting to use the n8n application, I'm prompted to create an owner user log-in. This allows me access fine.

However, I am under the impression that any Cloudron user should be able to access this application. The log-in requires an email address as the user-name, so I can't simply use my Cloudron user name as it doesn't have the right form. But trying to use the primary email address of my user doesn't seem to work either.

The Cloudron docs for n8n don't mention how to do this, so would someone be able to clarify that for me?

Thanks

(PS I've scanned through the other posts in this category - I don't see an obvious answer here. But maybe I should add that I don't have 2FA enabled on my account!)

@girish I've written non-trivial Sieve filters before, Dovecot supports it (which the server in question uses, and I believe, Cloudron). So far as I know (and scanning through the extensions in those docs) it doesn't really support storing state between filter runs which will allow aliases to be disabled.

So I think the best I could hope for is to use wildcard aliases, and manually block spammy ones using sieve filters. This wouldn't be very user friendly, so this seems to be a potential show-stopper.

(Possibly something external to Haraka could be inserted into the mail delivery process?)

Thanks!

@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