Cloudron Forum

There's really nothing stopping you from doing this presently by using a Cloudflare CNI or (Argo) Tunnel / dedicated ingress proxy to eliminate direct public internet access to the box and provide connections to Cloudflare - bit of setup and maintenance, but realistically getting that level of private access is going to require some networking and sysadmin chops as such anyway.

@girish I’m still around - I can pick this back up in the next week or two

LDAP groups would be huge. Been dying for that a couple years now

Got 7.0.1 loaded up on my testbed machine...going to re-update the packaging as needed and ensure recvmail is integrated properly, then we should be good to go here. Hoping for O(days) on that, may be O(weeks) given schedules the next few weeks.

@hollosch No, work remains "in progress" for the time being to get a reliable package finished before it heads there. You can keep track by the "WIP" tag on the thread right now - it'll go "Solved" and green once completed

@nebulon Also while X-Frame-Options is not as current as CSP, it's still considered best practice to get more complete coverage for that protection across browsers, especially older ones:

https://caniuse.com/contentsecuritypolicy2
https://caniuse.com/x-frame-options

At least, that's still the case for every audit and best practice list in the circles I'm in. It is still required by the latest ASVS 4.0.2 (criteria 14.4.7) as well (source: en / de). So I'd encourage both. While you're touching the session cookie, you can also probably go SameSite=Strict as well.

@chymian said in Quo Vadis Cloudron?:

none of you, who where so quick with the answers and flames did understand, what my point is!

That's sort of exactly my point. You took a pretty condescending tone with comments like "or do you want to deliver a system, which behaves like a real server" that are just vaguely argumentative, and the whole thing led off with slamming the community for not answering certain questions to your satisfaction. You led right into your opinions of "how a server should behave" and how that isn't this product, peppered with value judgements about different technical specialties. Yes, the reaction was collectively a bit defensive, but I don't think it's a stretch to understand why.

Either way, I still struggle to understand your goal/point/complaint. It seems like perhaps you're just advocating for more configurations for ever more behaviors and included features. There are multiple ways to achieve everything you've discussed. I don't know what the hangup about 2FA is, but the feature you're complaining about is this:

Which seems to be exactly what you think it should be - a setting to require 2FA for users.

There's every choice in how someone wants to manage/monitor their servers. Nothing about Cloudron precludes installing agents for any sort of monitoring/management system whatsoever for the underlying host. Want to wrangle your k hosts with ansible? Fine. Rather prefer DataDog or Nagios or PRTG or whatever? Go for it. If the point is that Cloudron should make more decisions about things like this, I disagree. If rather you think it precludes their use somehow, it does not. If you think that it should make some of its activities more apparent for such tools to notice, I think we'd have an interesting conversation to have. If you meant something else, please explain further, because at this point those are the only parts I understand.

As a professional whatever, I read all of that, and may I just say...uh, what?

Footnote: pretty difficult to imagine "more control" than root, but that's mostly because I don't consider straight assembly into ring 0 a daily-driving sort of necessity.

I agree about Moodle, and I'm a fan of having more choices in every category on the platform generally. Canvas is the leading alternative in terms of upvotes so far, and likely to arrive sooner. Worth taking a closer look - bit overwhelming to go in through Tutor itself - I'd advise anyone looking to go underneath that (massive) installer/abstraction and check out Open edX directly as a starting point. Just .02 from a cursory look; this isn't too high on my list yet, but I'll try to make a deeper evaluation of it soon.

You can't use that particular method of editing the code, but you could look into setting a custom CSP via the app configuration (may need some maintenance to keep everything working in the future) - https://docs.cloudron.io/apps/#custom-csp - You'd need to get a copy of the CSP header being sent by your installation presently, then you can adjust the iframe sources allowed manually and put the entire adjusted CSP in place.

@girish So the gzip failure is independent the staged builds. Arguing with tar/gzip and GitHub about file formats presently, but I can replicate the issue you were having and am testing against the same Dockerfile with and without buildit on, so once I get that sorted, we can regroup and go from there.

Also running a moderately large EspoCRM instance here, plus some more hobby-scale ones, and agree with all the points made so far. Generally, I'm a fan. The Advanced pack and VoIP extensions have been good additions and I've not had any issues with the company behind EspoCRM either. Just works, admittedly with a bit of learning curve to administer, perhaps, as has been mentioned, but a lot of that is down to the customizations available. Documentation is only okay for most things, in my opinion. Overall, I'd recommend it

@girish yeah, I don't see why not. It works in an older version. I may be able to pin back the specific dependency as well (it's the node dependency from https://github.com/loomio/loomio_channel_server that seems to be doing it). I'll play around with it a bit while we work on the recvmail thing in the mean time.

@girish Yeah, I tried setting that, but the issue is that one part of the app is sending the two-argument version every time, which 5 and lower just don't know how to handle

@girish All else held equal, I'd probably take this compromise. However, the apps in question where I have run into this issue have the email interface as core features and it can't really be turned off. Installing a somewhat handicapped version of these apps which would require further manual configuration, in some cases through the terminal, is a really poor experience.

I think the case that the mail server is external to the Cloudron should be a well-accounted for exception, but not the expectation of packaged apps. My "perfect" reimagined recvmail would be that by default it works as you've described, but there would be new options on the app configuration page for "Email" that would allow switching the CLOUDRON_MAIL_IMAP_* details over to a manually-entered set of values if desired. That would keep things automatic for the all-in users and allow flexibility for the split-server case, all without requiring complex configuration changes to files and/or the apps' packaging.

These are the log messages when executing a test (which exercises both sending and receiving) through OneDev. Taken from the Cloudron-side email logs, with expanded details, domain name redacted, and chronology flipped (oldest message first):

Queued mail for delivery to onedev.app+test-sub-addressing@example.com from onedev.app@example.com

{
  "ts": 1629216044183,
  "type": "queued",
  "direction": "outbound",
  "uuid": "22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1",
  "remote": {
    "ip": "172.18.16.253",
    "port": 48192,
    "host": "05b821f7-a64e-40c0-8296-451deb089e0c.cloudron",
    "info": "05b821f7-a64e-40c0-8296-451deb089e0c.cloudron",
    "closed": false,
    "is_private": true,
    "is_local": false
  },
  "authUser": "onedev.app@example.com",
  "mailFrom": "<onedev.app@example.com>",
  "rcptTo": [
    "<onedev.app+test-sub-addressing@example.com>"
  ],
  "details": {
    "spamStatus": "",
    "message": "Message Queued (22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1)"
  }
}

Sent bounce to onedev.app@example.com for mail sent to onedev.app+test-sub-addressing@example.com. Some recipients failed: <onedev.app+test-sub-addressing@example.com>

{
  "ts": 1629216044307,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1.1",
  "mailFrom": "<onedev.app@example.com>",
  "rcptTo": [
    "<onedev.app+test-sub-addressing@example.com>"
  ],
  "details": {
    "message": "Some recipients failed: <onedev.app+test-sub-addressing@example.com>",
    "mx": {
      "priority": 0,
      "exchange": "127.0.0.1",
      "port": 2424,
      "using_lmtp": true,
      "family": "A",
      "bind_helo": "mail.example.com"
    },
    "bounced_rcpt": [
      {
        "original": "<onedev.app+test-sub-addressing@example.com>",
        "original_host": "example.com",
        "host": "example.com",
        "user": "onedev.app+test-sub-addressing",
        "reason": "550 5.1.1 <onedev.app+test-sub-addressing@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_action": "failed",
        "dsn_smtp_code": "550",
        "dsn_smtp_extc": "5.1.1",
        "dsn_status": "5.1.1",
        "dsn_smtp_response": "<onedev.app+test-sub-addressing@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_remote_mta": "127.0.0.1"
      }
    ]
  }
}

Sent bounce to <> for mail sent to onedev.app@example.com. Some recipients failed: <onedev.app@example.com>

{
  "ts": 1629216044342,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "D47C41D3-83FB-49F0-A709-5162706B0A72.1",
  "mailFrom": "<>",
  "rcptTo": [
    "<onedev.app@example.com>"
  ],
  "details": {
    "message": "Some recipients failed: <onedev.app@example.com>",
    "mx": {
      "priority": 0,
      "exchange": "127.0.0.1",
      "port": 2424,
      "using_lmtp": true,
      "family": "A",
      "bind_helo": "mail.example.com"
    },
    "bounced_rcpt": [
      {
        "original": "onedev.app@example.com",
        "user": "onedev.app",
        "original_host": "example.com",
        "host": "example.com",
        "reason": "550 5.1.1 <onedev.app@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_action": "failed",
        "dsn_smtp_code": "550",
        "dsn_smtp_extc": "5.1.1",
        "dsn_status": "5.1.1",
        "dsn_smtp_response": "<onedev.app@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_remote_mta": "127.0.0.1"
      }
    ]
  }
}

I first noticed this issue while packaging Loomio and ended up right back here again when I started working on OneDev as well.

So, as first described in January and confirmed as recently as last week and yesterday, this issue is still going on. Let's say we have a cloudron app called example which gets the email address example.app@example.com assigned from the Cloudron for it to use. When both sendmail and recvmail addons are enabled for it, I would expect that the behavior would be:

1. Both SMTP and IMAP credentials populate into the environment
2. The app can connect to both SMTP and IMAP servers
3. Once connected with the app's credentials, it is possible to send mail via SMTP and receive mail via IMAP

However, the observed behavior is:

1. Both SMTP and IMAP credentials populate into the environment
2. The app can connect to both SMTP and IMAP servers
3. Once connected with the app's credentials, it is possible to send mail via SMTP, but all mail sent to example.app@example.com (and any example.app+foo@example.com-style subaddresses) is hard bounced smtp;550 5.1.1

This is a surprising behavior anyway, but particularly tough for the common use case both these apps have, whereby they send email notifications which users can reply to via email as a way to interact with the service. Loomio does this for discussion threads, OneDev does it for issue and PR notifications, and there are many useful cases in which this sort of feature is useful. However, it is not possible to enable it "automatically" at least with a Cloudron app presently, using the managed addons' capabilities. This could all of course be manually wired up, but that's a clunky workaround that's blocking the process of at least these two apps toward general availability, but has also impacted my designs on two other custom apps I've been working on to run on Cloudron.

I've got no solutions or ideas on what is causing this under the hood presently (it's been a pretty busy year), but I wanted to make sure this post gets out there to identify the issue as known, and maybe some greater minds with more time can get it resolved eventually!

I've actually got OneDev nearly packaged locally. However, it is yet another app that has a need to both send and receive mail for certain features, and it is now blocked the same way Loomio is. With both recvmail and sendmail addons running, emails can be sent by the app just fine, but inbound mail bounces.

@girish Any progress on this defect?

@debossnow The password will be the same as the password on the Cloudron for login, but the "username" in this case should be the full email address of the mailbox which you'd like to sign into. This is how multiple mail domains can have mailboxes owned by one account. For example, let's say that I have a Cloudron at example.com which handles mail for example.org as well. Let's further say there is a user with the username admin and a password of secretpassword. That user could be assigned multiple mailboxes; for the sake of the example, let's say this user admin is the owner for admin@example.com, contact@example.com, and also info@example.org mailboxes. In order to sign in to a webmail, such as RoundCube or RainLoop that is attached to the Cloudron mail system, it would be necessary to use the full email address - e.g. contact@example.com or info@example.org - and the same secretpassword as the credentials. The Cloudron knows which user (and therefore which password) goes with a mailbox, but of course the webmail client does not and can only provided the intended mailbox.

If there's anything more unusual going on, the Event Log on the email administration page is likely to have some further details.

@robi said in Blink - Modern, lightweight, planet-scale link shortener:

self-hosted CDN