Cloudron Forum

IDrive e2 has been very reliable for me for the cost, however I too ran into that issue a few months back around the “slow down” error where basically they were rate limiting. I suspect it had to do with noisy neighbours ruining it and triggering a rate limiting on the cluster of nodes being backed up to, but that’s just a guess on my part.

What I had to do was delete the region hostname and re-enable it, which created my backup buckets somewhere else and allowed me to proceed without issue. The unfortunate part of this though was that it deletes all the files of course in the prior region, so what I did was first download a few important backups from it to my local disk and reloaded afterwards.

IDrive support team had apologized for the issues and provided me with a couple months free service credit, so that was helpful although the cost is so cheap that it didn’t exactly pay for my time at all, haha.

Just an option for those who may run into that rate limiting issue if it persists for a while. I’d recommend opening a support case and if the issue isn’t resolved quickly enough and you’re able to delete the region, delete it (but first download anything critical from it) and start again and tell support about what you did and they should credit your account for the troubles (you may need to request that though if it isn’t automatic).

@girish Yes, I no longer got the Gmail issues when I created my own system service to implement the iptables rule. So it seemed to do the trick.

The IP tables rule to add is really just this: iptables -t nat -I POSTROUTING -s 172.18.0.0/16 -o enp3s0f0 -j SNAT --to-source {FLOATING_IP}

Where FLOATING_IP is really just replaced with whatever the recognized IP address is that’s used in the DNS records for the MX record. I supposed it could be further improved to only be applicable to the mail container rather than all Docker traffic. And of course the interface would have to be dynamic too.

I guess an alternative is for me to create additional MX records with the other IP addresses but then it’s manually done and prone to mistakes/issues.

In my opinion, I think we really need an option to select the outbound IP interface using Cloudron for the mail component, in order to avoid the Gmail issues (and any other provider who will use FCrDNS for verifying or rejecting emails in the future). I recognize this may not be a common concern as most people probably only have the one IP address of each type and so the DNS records if setup automatically by Cloudron will use both the IPv4 and IPv6 address, but for those of us who use a floating/failover IP addresses that we want to be the one true IP address being used, this becomes an issue without that workaround in place.

@jdaviescoates said in Use floating IP address only for outbound Cloudron Docker container communication:

@d19dotca said in Use floating IP address only for outbound Cloudron Docker container communication:

I had started to use a floating IP address for IPv4

I'm not really following this too closely, but isn't that the root of the problem? I may be missing something obvious, but one not just used a fixed IP? Wouldn't that solve your problem?

That’s basically what I’m trying to do. But instead of using the IP address that comes with the servers I am trying to use the IP address that is floating. The reason for that is it means if I change servers (whether for upgrades or failover) then there is no real interruption in service. While I control most of the domains DNS records for my clients, there are a few outside of my control and it’s a pain to ask them to manually update the DNS records because sometimes it takes them days to complete it which makes data migrations or failovers difficult to do for them.

Basically, I’m paying a buck a month for an additional IP for peace of mind to use when disaster happens, and unfortunately today Cloudron (or perhaps more specifically Docker) is using all available IP addresses to send traffic rather than the only one I set on Cloudron to use.

Hopefully that helps clarify that, I’m rushing a bit so let me know if I confused anything. Haha.

@girish It’s the former, that’s correct.

Basically, Gmail was refusing emails from my server due to a mismatch of FCrDNS (forward-confirmed reverse DNS). This happened after I had migrated to a new dedicated server at OVH with multiple IP addresses as I had started to use a floating IP address for IPv4 l. So the server now had two IPv4 addresses plus the IPv6 address. In Cloudron, I had set it to specifically only use the floating IPv4 address and disable IPv6, but that’s when I learned that doesn’t really do anything beyond what to set the DNS records with.

After a little investigation from seeing the Gmail delivery failures, I realized emails were being sent to Gmail using random IP addresses from my server rather than the IP address that I had manually set on the Cloudron network page to use. This meant that the IP address used in the DNS record for the mail server didn’t always match the outgoing IP from my server which is why Gmail was rejecting the message.

I think the disconnect for me was not realizing that the network tab didn’t control the IP addresses used for any outbound communication (mainly the mail server though).

So I think it’s critical that we have a way to determine the outbound IP to use for the mail container at the very least.

I worked around this by creating a service that runs on boot and basically adds to the firewall rules to for Docker to use only my preferred IP address for outbound traffic. But this seems temporary and almost “wrong” somehow even though it does the trick. I worry that I can’t rely on it long term and would think this logic needs to be added into Cloudron where perhaps on the Network page we get the chance to configure the outbound IP address for traffic, or even if it’s just unique to the mail container because that’s probably the only container where this is an issue.

I hope that helps clarify.

@girish said in What's coming in Cloudron 9:

Since many IPv6/PTR issues have been reported, I revisited the code to double-check.

I found two biggish bugs:

• There was a typo in the IPv4/IPv6 caching code Because of this IPv6 will sometimes be returned as undefined
• On versions less than Ubuntu 24, unbound was configured to use IPv6 . Zen SpamHaus is not replying IPv6 queries for most of the public VPS providers . I made a fix to make unbound use IPv4 to query SpamHaus.

Finally, I also added IPv6 DNSBL checks . Also, double checked that SPF record "a:" includes AAAA .

I am hoping this helps the situation. If not, we can add a flag in 9.1 to make the mail server not use IPv6 at all.

With some much needed Mail improvements, I just wanted to raise this one to your radar in case this can make it in for 9.0 at all. I’m surprised this isn’t making bigger headaches for people, likely just a particular set of circumstances, but I think this is an important fix or improvement to include if we can.

https://forum.cloudron.io/post/109707

Just wanted to follow up on this. Paging @girish , in case this is something you think we can try to include for the next Cloudron version. I think you’re busy working on 9.0 so it’d be good if we can perhaps include this mail / networking improvement. I found the following in case this helps for Haraka where we can supposedly set the specific IP address to use: https://haraka.github.io/core/Outbound#outbound-ip-address

It seems like we can set a hook to determine the IP address to use for outbound mail.

IMO, it should be automatically set to the IP address detected by Cloudron and perhaps more specifically the IP address used on the MX DNS record so that we can be better with the Gmail delivery in particular.

@robi hmm, in that case it may be slightly different. The issue I was having was because the IP address resolving to mail.d19.ca wasn’t the same IP address, and my server has two IPv4 addresses and an IPv6 address. If mail went through one of the IPv4 addresses it worked perfectly, but email to Gmail addresses on any of the other two addresses would fail since the IP didn’t match that on mail.d19.ca.

This fix probably fixes it for anyone who only has one IPv4 and one IPv6 address I suspect, but may not fix it for anyone with an additional floating IPv4 address that is meant to be the main IP.

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

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

I stopped using Cloudron mailing list a while ago because of this

Out of interest, what you using instead?

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.

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

@avatar1024 was this resolved?

No, this hasn’t been resolved. This still needs to be improved in Cloudron mailing lists, please.

I wonder if this would be helpful for this other issue too which I reported back in March but no real progress beyond my workaround yet: https://forum.cloudron.io/topic/13458/use-floating-ip-address-only-for-outbound-cloudron-docker-container-communication?_=1750223095929

Ideally, I want to pick the specific interface / IP address being used for outbound communication. It was mostly because I wanted to prevent the IPv6 address from being used, and apparently disabling IPv6 in Cloudron doesn't achieve that result as I guess it's just for inbound traffic / DNS records, not for outbound traffic. It was the result of needing to avoid blocking in Gmail for traffic when the outbound SMTP IP used isn't the same one in the DNS record / or the one that's set in the Cloudron IPv4 address settings.

Attached is an image, as you can see this is severely impacting the ability for the strata owners to communicate to anyone on the list which goes to a Gmail account. (I originally tried to uploaded a larger screenshot showing more lines but the forum software prevented it, saying it was too large.)

Just wanted to check in on this. It seems I am running into this issue from one particular domain. Same Gmail reply status. Deferred mail according to Gmail, and it’s taking hours to days to ever be accepted by Gmail. Oddly it only affects one domain but I think it’s because it’s also the only domain that forwards via distribution lists in Cloudron to a few Gmail addresses.

Can we please consider this? I see mention of “add this into the next release checklist”, but not sure if that ever got into it or not, or if that was unrelated. Do we have a fix for this Gmail delivery issue when using the Cloudron mailing lists feature?

Upstream error: 421 4.7.28 Gmail has detected an unusual rate of unsolicited mail. To protect 4.7.28 our users from spam, mail has been temporarily rate limited. For 4.7.28 more information, go to 4.7.28  https://support.google.com/mail/?p=UnsolicitedRateLimitError to 4.7.28 review our Bulk Email Senders Guidelines. 6a1803df08f44-6fb09b2f3b8si64915186d6.375 - gsmtp

The mailing list is rarely used and only sends to maybe 18 emails addresses, only 5 or 6 of which are Gmail accounts. It’s for a residential strata mailing lists so it’s a small amount of emails involved and a small group of people, they maybe send a few a day and then weeks can go by with nothing. So it definitely isn’t an unsolicited mass emailing, the response from Google seems a little bit misleading there.

My guess from reading the above is Gmail is detecting the Cloudron mailing lists as bulk email, and deferring it as a result. Seems the workaround is to use a mailbox with mail forwarding instead, which I haven’t tried yet but may try tomorrow given the messages above in this post.

Any insights into how we can really fix this though so that we can use Cloudron mailing lists to Gmail?

Dedicated servers from OVH are well priced too, worth it in my opinion but it likely depends greatly by region. I’m in Canada and there’s only so many local options, with OVH servers being the cheapest by far but still very powerful. I’d only recommend OVH if you’re a pretty decent sysadmin though because their support is not the quickest.

@Shai You would need to edit your local computers /etc/hosts file and add in the old IP address of the previous Cloudron install for the domain name that you’d type in the browser bar. Then you should be able to use the hostname to still access the older Cloudron server.

Forgive my ignorance of this particular app, but is there any ability to monitor Cloudron app containers itself with it? Or maybe related... does Cloudron plan on perhaps building this app into core so that we can get some souped-up monitoring capabilities for each container on the status page?

That has worked for me. I have two domains in which I don't have control over the DNS records, so I have to wait for someone else to make the changes. In general, I've just asked them to make the changes and still migrate the data while keeping the old one in-place for now until the change is made.

Edit: I suppose this also depends on the type of application too. So if it's just a static website or something, probably no worries at all. However if it's an e-commerce store or some storage app like NextCloud, then once they make the changes in their DNS, you may still need to do one final copy from the old server to the new server for just the particular app to avoid any lost information.

It's going well so far in my testing. Updated about 6 domains with the newer DKIM selector today. It'd definitely be nice to have this configurable though in the UI so we can change it in one sweep to a new DKIM selector of our choosing.

What's strange about this to me is I seem to be unaffected (so far at least), and I'm looking in Cloudron mail pages quite frequently. Not sure why but I am throwing this out there in case it has something to do with the region IP of the Cloudron servers? I'm located in Canada, in case that matters at all. I just wonder if there's a pattern for this perhaps with certain countries affected more than others, etc.

Though I guess ultimately if Cloudron isn't properly accounting for blocked connections to Spamhaus and seeing a blocked connection as a listing, then that should still be fixed in the code if that's true.

Sorry, ignore me I think, as I misunderstood the problem. I thought this was around Cloudron detecting that the IP of Cloudron was on the blocklist, but that would have no bearing on rejecting emails so I think I misunderstood. Sorry about that.

@girish , It's a couple years later and I just stumbled across this while doing some DNS record cleanups and remembering that some use the older style DKIM name and others use the newer style. The "OCD" in me wants to format the older ones to use the newer naming scheme. Is this something that ever made it in the product? I see you mentioned that you "will make the dim selector configurable in the coming release" but I don't think I see a way to do that yet. I do see a way from above in this thread though that should do the trick manually in MySQL. https://forum.cloudron.io/post/40250

@james Yes it’s technically a feature request. I only threw it in here since it seemed like Girish was already making adjustments to the filtering in the mail event log viewer. If you’re okay forking it to a feature request, that’s totally fine.