Cloudron Forum

If SRS is not an option (or not obeyed by Gmail) you can look into some advanced sieve stuff:

https://doc.dovecot.org/2.3/configuration_manual/sieve/configuring_auto_forward_sender_address/

@marcusquinn You‘re welcome. We are using openwebui with RAG (our own documents aka knowledge) for the IT support team. We are using it on cloudron together with the private IONOS AI Hub. Great service if you are serving EU customers.

I am pretty happy with this in openwebui:

But I will take a look at librechat, just had no desire to look for something else so far.

I am also confused about how this is different from openwebui where you can create a custom model that is enriched with your own knowledge (aka you own documents) and share that model with other to chat with. I am no expert here though and have just used openwebui so far. Works great.

@avatar1024 said in Email delivery issues with double forwarding to external addresses:

Does it work fine with your set-up?

Yes, using an external SMTP relay it works for me. And Google finally accepts incoming mails right away instead of delaying them for hours or even days...

Not sure if this might be due to some SRS (https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) misinterpretation? I have set up similar scenarios on Cloudron, but switched to an external SMTP relay server - so not comparable per se. If not using SRS, you would run into SPF problems when forwarding the mails aka using a distribution group.

The "Error: bare <LF> received" message might hint at some other cause though, maybe the Haraka mail server used by Cloudron formatted something in a non-conforming way.

I am pretty happy with the MS-01 „workstation“ from MinisForum. It has options for more than one NVME so you can run a software RAID and has solid hardware specs. Pricing is much higher than used mini PC systems off eBay, but if you are looking for powerful, silent, and small hardware this might be an option to consider (if it fits the budget).
https://store.minisforum.com/products/minisforum-ms-01

Thanks guys, thant‘s exactly the use case I was thinking about. The Hakara MTA used by cloudron seems to be very flexible in regards to the outbound configuration (https://haraka.github.io/core/Outbound). While I am no expert on this subject, it might not be too difficult to implement a failback using an SMTP relay.

We had some good experiences with self hosted mail servers and using SMTP relays (CSA listed). I just don’t want to send all mail messages through an SMTP relay (costs, logs not on Cloudron, etc.), just the ones that stay in the queue for too long. Shouldn’t be too difficult to implement, but I don’t know if there is a need for it for others. We‘ve had all messages delivered so far (even to Gmail, etc.), but I am annoyed by the delays because of 4xx rejections from the large providers.

Sometimes, mail providers such als Gmail/Yahoo/AOL can be picky when accepting incoming mails from self-hosted mail servers, even if they come from a reputable IP address of a cloud hosting provider. Mails are being temporarily rejected with a 4xx error code and it can take a long time for them to be accepted, if at all.
Would it be possible to have a configuration in Cloudron to use an external SMTP relay service for mails only in case a mail stays in the queue for a (configurable) time, e.g. 30 minutes?
Cloudron could continuously monitor the outgoing mail queue and if a mail is in the main queue for a certain amount of time without being delivered, it could move it to a secondary queue, configured with an external SMTP relay (mailgun, rapidmail, etc.) to ensure delivery of the mail.
Any thoughts on this? Would this be possible?

Most likely related to https://forum.cloudron.io/post/91353. Reported upstream: https://github.com/alextselegidis/easyappointments/issues/1587#issue-2465769537

You may also check this post if you are technically skilled with wireguard and a public VPS.

Thanks, I can confirm this. The mails just did not show up in the queue on the web frontend which I find a bit confusing.

From what I can tell the Harakari mail queue is not persistent. Mails do not remain in the queue when the server is restarted. If problems - DNS, etc. - come up and outgoing mails queue up and the server is restarted, the mail queue is emptied (deleted). Would there be a way to make the mail queue persistent?

@girish Yes, I did. A while ago. The problem just came up after upgrading to 8.0.5 a few days ago. 8.0.4 was running fine.

Same happened to one of my installations as well. Also causing problems with email delivery:

Die Zustellung von E-Mail ist fehlgeschlagen. Wird in Sekunden erneut versucht.. DNS lookup failure: Error: queryMx ESERVFAIL xyz.de

After fixing the problem and a reboot, the outgoing mail queue is empty. Will there still be attempts to resend the outgoing mails that were not yet send because of the unbound-anchor problem?

@infogulch If you want to deploy your Cloudron instance on a home internet connection, you might consider running it through a Wireguard tunnel to a VPS with a public IP.

Thanks for this write-up. You can easily adjust this to use a wireguard tunnel (apt install wireguard-tools) and port forwarding instead of Tailscale and a reverse proxy. Just use destination NAT and source NAT to route all outbound traffic through a VPS (I use a cheap 1€/month VPS) with a public ip and forward inbound ports to your private server behind a NAT (eg. at home, etc). This works, even for email.

The concept is the same as with Tailscale above, but without a reverse proxy and port forwarding instead (making email etc. work). Just use the following Wireguard configs (adjust to your specific needs):

---

Wireguard config (/etc/wireguard/wg0.conf) on your public VPS (IP: 1.2.3.4)

[Interface]
PrivateKey = AAAAAAAAABBBBBBBBBCCCCCC=   # (<- server privte key)
Address = 10.10.10.2/32
ListenPort = 51822

PreUp = sysctl -w net.ipv4.ip_forward=1

# (replace ens6 with your server network interface)
PreUp = iptables -t nat -A POSTROUTING -o ens6 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ens6 -j MASQUERADE

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.1:80 
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.1:80

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.1:443
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.1:443

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 25 -j DNAT --to-destination 10.10.10.1:25
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 25 -j DNAT --to-destination 10.10.10.1:25

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 465 -j DNAT --to-destination 10.10.10.1:465
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 465 -j DNAT --to-destination 10.10.10.1:465

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 587 -j DNAT --to-destination 10.10.10.1:587
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 587 -j DNAT --to-destination 10.10.10.1:587

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 993 -j DNAT --to-destination 10.10.10.1:993
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 993 -j DNAT --to-destination 10.10.10.1:993

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 3478 -j DNAT --to-destination 10.10.10.1:3478
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 3478 -j DNAT --to-destination 10.10.10.1:3478

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 4190 -j DNAT --to-destination 10.10.10.1:4190
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 4190 -j DNAT --to-destination 10.10.10.1:4190

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 5349 -j DNAT --to-destination 10.10.10.1:5349
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 5349 -j DNAT --to-destination 10.10.10.1:5349

PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 222 -j DNAT --to-destination 10.10.10.1:222
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 222 -j DNAT --to-destination 10.10.10.1:222

[Peer]
PublicKey = AAAAAABBBBBBCCCCC= (<- private servers public key)
AllowedIPs = 10.10.10.1
PersistentKeepalive = 25

(If you use the TURN server, you might want to forward additional port ranges)

---

Wireguard config (/etc/wireguard/wg0.conf) on your private server:

[Interface]
PrivateKey = AAAAAABBBBBBCCCCC= (<- private servers private key)
Address = 10.10.10.1
ListenPort = 51821

[Peer]
PublicKey = AAAAAABBBBBBCCCCC= (<- public VPSpublic key)
Endpoint = 1.2.3.4:51822
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

---

During install (or after setting up the Wireguard tunnel), make sure you set your Cloudrons public IP manually to "Static IP" and enter your public VPS ip address.

Don't forget to set Wireguard to start as a service and enjoy your Cloudron instance on a home server.

systemctl enable wg-quick@wg0.service
systemctl daemon-reload
systemctl start wg-quick@wg0

This is nothing I would recommend for an enterprise grade deployment, but might be suitable for a testing/development instance.

@CptPlastic Cal.com is great and I am using both for different scenarios, but for some use cases I prefer Easy!Appointments in regards of the ease of use and simple handing for non-tech users.

@joseph

Reported upstream: https://github.com/alextselegidis/easyappointments/issues/1587