@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.
Reported upstream: https://github.com/alextselegidis/easyappointments/issues/1587
@CptPlastic Not sure if this is the same error message you are getting, but it seems the mails are misinformed. Might be Haraka (cloudron mail system) specific and I don't know where to report this upstream...
Aug 14 14:40:25 [NOTICE] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [core] connect ip=fd00:c107:d509::d port=52584 local_ip=fd00:c107:d509::b local_port=2525
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [helo.checks] helo_host: xxx.xxx.xxx, skip:proto_mismatch(private), bare_ip(private), dynamic(private), valid_hostname(private), rdns_match(private), host_mismatch(private)
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [core] hook=unrecognized_command plugin=cloudron function=hook_unrecognized_command params=AUTH retval=OK msg=""
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [core] hook=unrecognized_command plugin=cloudron function=hook_unrecognized_command params="dGVybWluLmFwcEBzY2h1bHNlcnZlci5vbmxpbmU=" retval=OK msg=""
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [cloudron] Authenticated as xxx@xxx.xxx
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5] [core] hook=unrecognized_command plugin=cloudron function=hook_unrecognized_command params=OGZlNDQ3MzQ5ZDllOTI3ZGM5YmY0NjgwN2IwZjE4YzU2ZGU1NzE3NDEwZjcwZjY5 retval=OK msg=""
Aug 14 14:40:25 [NOTICE] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [core] sender <xxx@xxx.xxx> code=CONT msg=""
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [core] hook=rcpt plugin=rcpt_to.in_host_list function=hook_rcpt params=<xxx@xxx.xxx> retval=OK msg=""
Aug 14 14:40:25 [INFO] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [delay_deny] bypassing all pre-DATA deny: AUTH/RELAY
Aug 14 14:40:25 [NOTICE] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [core] recipient <xxx@xxx.xxx> code=OK msg="" sender=xxx@xxx.xxx
Aug 14 14:40:25 [NOTICE] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [core] Client sent bare line-feed - .\n rather than .\r\n
Aug 14 14:40:25 [NOTICE] [6B68CE5F-A3FB-496B-9DC6-EB3634987FC5.1] [core] disconnect ip=fd00:c107:d509::d rdns=f1a9575d-4e9d-4e08-af9e-64987f686d4a.cloudron helo=xxx.xxx.xxx relay=Y early=N esmtp=Y tls=N pipe=N errors=0 txns=1 rcpts=1/0/0 msgs=0/0/0 bytes=0 lr="451 Bare line-feed; see http://haraka.github.io/barelf/" time=0.028
Updated to Cloudron 8.0 without any issues and then to Ubuntu 24.04.
I was facing DNS lookup errors in the mail logs and had to add
interface 127.0.0.1
to the cloudron unbound config.
Everything working smoothly since then.
At very first glance there seem to be a lot of similarities to Outline. Is this some kind of fork?
@girish said in Community+ also available?:
@NCKNE yes, makes sense. I think the packages should be quite similar. Once we have some more feedback on the existing package, we will get the community+ out.
@girish Did you get enough feedback on the current package? I find it very stable and it has been running without any problems for a long time. I would very much like to see the Community+ version on the app store as it includes important features such as PDF export which I desperately miss in the current version. Packaging should be quick and easy as it is just another installer file as far as I can see.