Cloudron Forum

@mirotalk-57bab571 What @robi is talking about is a conflict when you have a OIDC user with the same username as a user in the .env file. In this case the user in the .env file (same username as the OIDC user but different password) cannot join the room.

@girish Hi Girish, I see the issue you mean (I also reported it a while ago, it was about double forward) but this one is different (although the cause might be same). Before switching to the external SMTP the mailing list was working fine for this use case, it's only after switching that it started happening.

While the other issue was a bit niche, this issue / use case seems more critical as it affects the basic functioning of mailing lists when using an external smtp.

@james sure it's catalystcollective.org

For clarity, sending/receiving emails works fine, it's only when someone with an external email address (i.e. not from this domain) sends an email through a cloudron list that delivery fails for recipients (list members) who also have external addresses.

Addition email server logs:

When sending from @mydomain.coop with successful delivery:

{
  "ts": 1751965332978,
  "type": "delivered",
  "direction": "outbound",
  "uuid": "425FB09B-28B2-4DFD-B19D-24763E77D8A5.1.1",
  "messageId": "<bc8821b5-e1c3-422c-bce0-3be7ae6b974b@mydomain.coop>",
  "mailFrom": "<someone@mydomain.coop>",
  "spamStatus": null,
  "mailbox": null,
  "quotaPercent": null,
  "rcptTo": [
    "<some.person@gmail.com>"
  ],
  "server": {
    "host": "149.28.215.223",
    "ip": "149.28.215.223",
    "port": 587
  },
  "response": "OK: message queued"
}

When sending from an external address to the same list and failing on the same recipient:

{
  "ts": 1751964710037,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "4C06313B-F1B3-460A-AC38-59402F3C3ACE.1.1",
  "messageId": "<76622dc4-1d22-4fe3-a863-e5da6a39a0b8@posteo.net>",
  "mailFrom": "<someone@posteo.net>",
  "spamStatus": null,
  "mailbox": null,
  "quotaPercent": null,
  "rcptTo": [
    "<some.person@gmail.com>"
  ],
  "message": "550 From header must end with @mydomain.coop",
  "mx": {
    "exchange": "149.28.215.223",
    "priority": 0,
    "port": 587,
    "auth_user": "*@mydomain.coop",
    "auth_pass": "c3b478557ae86e1b599aba64",
    "auth_type": "plain",
    "bind_helo": "my.domain.coop",
    "from_dns": "smtp.forwardemail.net"
  }
}

Hello all,

I've recently set-up an external SMTP relay using forwardemail. It works well, emails are going through etc.

However I have encountered a problem using Cloudron mailing lists:

When sending an email from en external email address (e.g. @posteo.net) to a Cloudron list which contains addresses @mydomain.coop (the domain on Cloudron) and some other adresses, e.g. @gmail.com or @posteo.net I am getting bounces for all recipients with those external addresses. Delivery works fine for the recipients @mydomain.coop and all works fine to ALL recipients (no bounces) if the sender is an address @mydomain.coop.

Bounces look like:

Hi. This is the Mailer program at mydomain.coop.

I'm afraid I wasn't able to deliver your message
    "test email"
to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

Intended Recipients: <some.person@gmail.com>
Failure Reason: Error: 550 From header must end with @mydomain.coop

@nebulon wonderful, thank you for the clarification!

@nebulon Thanks for your response. I had read the documentation before. As far as I understand setting up the external SMTP server means that cloudron uses this (in the exemple smtp.forwardemail.net) to send emails instead of the internal SMTP server (my.domain.coop).

Before I setup the external server, my desktop clients were configured to send emails using my.domain.coop + my cloudron credentials for that particular mailbox.

Now it works either using:

• the exact same config as before
• using the settings from the external SMTP server provider, in that case, smtp.forwardemail.net + credentials provided by forward email *@domain.coop + password.

My question is:
If I keep using the same config as before for sending emails from my client, i.e. my.domain.coop + cloudron credentials, does Cloudron still somehow pass that on to the external SMTP server, or is it sent by cloudron internal smtp server?

Or am I missing something?

Sorry for the probably stupid question but I've just set-up an external smtp server on Cloudron and I am puzzled by the SMTP config for email clients.

In my desktop email clients I can now send email using the smtp configs provided by the external service (Forwardemail), but it still also works using the old Cloudron config (i.e. using my.domain.coop + my Cloudron users credentials).

Does this mean that even when configuring Cloudron to use an external SMTP server for outbound email, the internal Cloudron smtp server still works and can still be used? Or is it the case that using the Cloudron smtp config still works but the email is somehow still routed through the external service?

@james said in Host Users not defined in env:

If so, OIDC will always be used even with that configuration.

I'm not sure this is correct.

You can disable IODC in the env config file: OIDC_ENABLED=false

Then "I guess" you can use the host user config.

@d19dotca said in issue with email delivery going through Cloudron mailing lists.:

I think they were using the workaround of creating a mailbox and logging into roundcube to setup mail forwarding, so it kind of acts like the Cloudron mailing list in a way, but seems to be more reliable and doesn’t trigger Gmail’s “mass mail” protections.

That's correct and also started using Lismonk for larger distribution lists.

I can't tell as I stopped using Cloudron mailing list a while ago because of this. But clearly others (e.g. @d19dotca) seem to still have the problem so looks like it hasn't been solved.

@MiroTalk said in reconnecting to the meeting randomly:

If you experience any disconnections, please let me know. It would be helpful if you could provide a screenshot of what you see on the device when it happens, and let me know whether you're reconnected to the room immediately or what exactly occurs.

Hello @mirotalk-57bab571 . So things are different since the updated version. In my first first meeting I had no disconnections so I had great hopes...which sadly got crushed in my second meeting where I had several disconnections. The behavior when the disconnections occur has changed.

• Before, when the connection would drop, this message would appear briefly Lost Connection (Transport Closed), then the page would reload automatically immediately and I would get reconnected to the meeting with both camera and mic off. When turning on my camera back on, the background settings would be lost (say if I have blur before, then on reconnection I would have a clear background).

• Since the new package, when the connection drops I see this (slightly different message):
  

...and that page lasts a bit longer before refreshing and reconnecting (on a couple of occasion I saw a count down appearing on the massage). Then it sometimes takes a couple of refresh before I actually get reconnected properly.

On one occasion I could not reconnect and the app itself became unresponsive. It was show as running on the Cloudron dashboard, when when clicking on it I had the Cloudron error page saying the app was unresponsive. I had to restart the app from the app settings on Cloudron.
On another occasion, right at the start when joining a meeting, I got disconnected right away and on reconnection my external webcam was not recognised anymore and I had to use my laptop one. This had never happened before.

So while clearly something has changed in the way connections are handled, currently the situation/UX has become, I'm afraid, a little worse, but I do not loose hope that this is just a sign of work having started to take place and it'll only get better from here to reach perfection .

Running MiroTalk 1.8.66 btw.

@MiroTalk Thank you, great to hear! I will report if I experience any more disconnections and will provide the info you've requested.

@overholt said in Nextcloud OIDC integration:

LDAP the default authentication protocol used when installing NextCloud on Cloudron and selecting "let application manage users?"

Just emphasis @james's point, when you select "let application manage users", then you're not using LDAP at all, you're using Nextcloud internal user registration which is not affected whatsoever by the migration from LDAP to OIDC.

@overholt said in Nextcloud OIDC integration:

My worry is having to manually reconfigure shares, etc inside NextCloud for users.

Even if you were using LDAP, the transition to OIDC only affects the login process (for NC itself and all external apps) but not anything internal like folder shares, groups, circles, etc.

@MiroTalk said in reconnecting to the meeting randomly:

Work in progress...

Really great to hear. And again thanks for all the work. Keep us updated if you can as for me it has become impossible to keep using it for work but I'm happy to do some testing whenever changes are being implemented.

@mirotalk-57bab571 I've been able to capture connection quality issues as I got disconnections on MiroTalk using https://test.vsee.com/network/index.html. The two drop in connections quality coincided with the disconnections/reconnections events in MiroTalk, which somewhat explain why those events happen randomly and support the idea it has to do with the quality / reliability of my connection (see below).

But there is something about MiroTalk that makes it particularly sensitive to it as does not happen with any other apps.

@MiroTalk said in reconnecting to the meeting randomly:

For testing purposes, could you also try the official mediasoup demo available here: https://v3demo.mediasoup.org ?

@mirotalk-57bab571 So far I haven't been able to reproduce on the mediasoup demo, but I then went to try on the MiroTalk SFU demo (to check it wasn't specific to my own instance), and there I could reproduce within 5min! I got several / repeated disconnection/reconnection event (still with same message: Lost Connection (Transport Closed)). Btw, when this happened I went straight back to using the mediasoup demo to check and there it was stable.

So that seems to confirm that it has to do with something specific to the implementation in MiroTalk itself, not with Cloudron package specifically and not with the mediasoup sfu logic.

I pasted the log of a meeting when I had lost of disconnections when I updated the github bug report earlier this week in case useful.

@james said in Atuin - Making your shell magical:

Hey @Lanhild could you maybe use the pinned template for the wishlist?

Fair, and it's always helpful to get all the info about an app using the the template, though you gotta acknowledge, this is not a wishlist, it's an announcement, "I like this app and I packaged it"

Yeah description is a little confusing but I think what @robi means is that they allowed a user (that is not a Cloudron OIDC user) in the .env file, but that this username has the same username as a OIDC user on Cloudron. As a result the user allowed manually in the .env file cannot login because the app is expecting the OIDC credentials. But yes, @robi please clarify.

@Package-Updates do you actually mean that? Don't you mean name as username?