@staff
This topic's title should be "Invidious - Package Updates"
RoundHouse1924
Posts
-
Invidious - Package Updates -
Cannot login after switch to OIDC@odie
FocusReader contains 9 trackers and 20 permissions, including the invasive GET_ACCOUNTS and READ_PHONE_STATE
https://reports.exodus-privacy.eu.org/en/reports/383074/ -
Calibre Web on Cloudron needs updating to the upstream latest --- V0.6.20 -
can't enable 2FA, now can't log in! --- Redis issues@humptydumpty What happens when you restart Redis?
-
Wallabag - Package Updates -
SimpleX Chat@cortex
simplexchat/smp-server - Docker Image | Docker Hub has moved to:-
https://hub.docker.com/r/simplexchat/smp-server -
IT-Tools is now available@girish
App store link gives "Nothing to be found here" -
IT-Tools is now available@girish
On this topic's title, for "is now available", read "IT-Tools is now available" -
Syncthing - Package updates@girish
Thanks, that just leaves
https://forum.cloudron.io/post/64437
to fix. -
Syncthing - Package updates@nebulon Bump! and Deja Vu!
-
Wireguard VPN4 years down the line and now the top voted-for outstanding item in the App Wishlist.
Although Wireguard is perhaps "not enterprise-ready", as suggested by OPNsense on Twitter, it is surely vastly superior to OpenVPN:-
https://twitter.com/opnsense/status/1654516200896884741?s=20@staff
Please, please keep this app at the top of your new apps queue.Very much looking forwards to the release day!
-
Email healthcheck notification: "Relay error: Connect to smtp.live.com timed out"Strange indeed, but I blocked the VPS Port 25. Whilst blocked, I restarted Kuma and Tiny but to no avail.
All up and running now with 25 unblocked.
-
Email healthcheck notification: "Relay error: Connect to smtp.live.com timed out"@girish
The situation I described was with v7.3.6 when I had only one outgoing domain and it used an external relay.Now with v7.4.1, I have 3 outgoing domains. One via the same external relay; the other 2 using the internal SMTP. Port 25 is open on the VPS and all 3 status lights are green.
So, in order to test your answer, I blocked outgoing Port 25 on the VPS firewall.
As expected, the 2 direct domains go red.
However, the external relay domain's Cloudron status page shows:-
MX record = Current value: [not set]
DMARC record = Current value: [not set]
SMTP Status Outbound SMTP (Relay) = Connection timeoutLooks to me that, with Port 25 closed, the SMTP check is made, but times out.
The puzzler is to know what could be causing the MX and DMARC record checks to fail --- just because Port 25 is closed.
EDIT:
With Port 25 closed, Uptime Kuma and Tiny Tiny RSS cannot do their stuff, so I've now reopened it. -
Email healthcheck notification: "Relay error: Connect to smtp.live.com timed out"I had one domain using an external relay and having port 25 closed on the VPS. The above error was present, but disappeared when port 25 was opened.
So, the port 25 check seems to be unnecessary and confusing for domains that use external relays.
-
Cloudron SPF record does not permit IP@girish
None of my outgoing mail is being rejected, but headers contain the following (first example sending from Thunderbird on Linux; second example sending from FairEmail on Android):-received-SPF: Fail (my.sharona.cloud: domain of groveland.place does not designate 138.199.6.239 as permitted sender) receiver=my.sharona.cloud; identity=mailfrom; client-ip=138.199.6.239 Authentication-Results: my.sharona.cloud; auth=pass (plain); spf=fail smtp.mailfrom=groveland.place
Received-SPF: Fail (my.sharona.cloud: domain of citharas.org does not designate 86.15.69.112 as permitted sender) receiver=my.sharona.cloud; identity=mailfrom; client-ip=86.15.69.112 Authentication-Results: my.sharona.cloud; auth=pass (login); spf=fail smtp.mailfrom=citharas.org
In both cases, the IP addresses belong to the sending mail client, not the server.
One of the 3 domains hosted uses an external relay, the other 2 use the internal SMTP.
Also, each domain's SPF record uses minus all, not tilde all --- so any rejection is not just a softfail:-
TXT v=spf1 a:my.sharona.cloud -all
Although nothing is rejected by the receiving server, receiving clients show:-
FairEmail shows a waving flag, as per its FAQ:-
"...FairEmail can show a small red warning flag when DKIM, SPF or DMARC authentication failed on the receiving server. You can enable/disable authentication verification in the display settings"
https://github.com/M66B/FairEmail/blob/master/FAQ.mdThe DKIM Verifier Thunderbird extension shows "SPF: fail"
https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/So, the bottom line of all this is that the headers incorrectly show that the mail client is the authorised sender. Clearly, as the message passes through the Cloudron mail server (since v7.4.x), something is processed in a manner to cause this.
Hope all this makes sense!
-
Cloudron SPF record does not permit IP@ccfu said in Cloudron SPF record does not permit IP:
SPF details are not injected by Cloudron or Haraka at all
If so, then how come I can trace the origin of this problem to the Cloudron update to v7.4.1 from v7.3.6 ?
-
Cloudron SPF record does not permit IPI have the exact same problem --- only since updating Cloudron to v7.4.1 from v7.3.6.
So, this has clearly been introduced by v7.4.x.SPF is more important than @staff are making out above.
Fundamentally, the point is that the SENDING Haraka/Cloudron is guilty of injecting the wrong header SPF details into OUTGOING emails.
This needs a rapid solution, as domain and server reputation is at stake!
-
Syncthing - Package updates -
Notesnook - A fully open source & end-to-end encrypted note taking alternative to Evernote.@jdaviescoates said in Notesnook - A fully open source & end-to-end encrypted note taking alternative to Evernote.:
@ctrl this looks nice but is it even a web app?
The nearest this gets to being a webapp is:-
Sync server for Notesnook
https://github.com/streetwriters/notesnook-sync-serverbut on that page shows "not yet self-hostable"