As well it should! I intentionally stipulated that these things were not a part of the initial DNS check script. The server software won’t refuse to install if you don’t have a DKIM key, but it will refuse to install if you don’t have a PTR record, even though the absence of both could adversely affect mail delivery. Yes, check. Yes, recommend. Yes, warn. …but ultimately, my refrain is that an “install anyway” option should be provided.
Yes, you’re correct, SPF/DKIM records don’t have explicit issues with residential IP ranges in the same way that such issues exist with PTR records. However, it’s possible to exchange e-mails without a PTR record, as it is possible to exchange e-mails without DKIM keys. We’re talking about a script designed in a way that lacks an override under circumstances that are ultimately optional.
We agree here.
I like RSpamD. I administer one as a part of a Mailcow server I maintain. The reason I bring up Miracast and Barracuda isn’t because I believe RSpamD is incapable, it was a readily-understandable example of a scenario where a requested DNS record would fail a check, but that traffic would flow properly. Perhaps a better example is putting the A records and CNAME records behind Cloudflare, but the point ultimately remains that all I’m asking for is an “proceed anyway” option.
From the original post I made in this thread:
It’s entirely possible I could be wrong, but let’s go down the hypothetical road of what would happen if I did option 4: create my own DNS server and point the /e/Cloud instance to it, in order to feed it whatever answers it wants to proceed with the install. We’ll assume that the listed A records and CNAME records are also correct for the mail, autoconfig, and autodiscover CNAME entries the script says it needs on the domain registrar.
What would happen? E-mail would be inconsistent-at-best, I grant you…but all of the other functions of the /e/Cloud server would function properly, right? Contacts, calendars, notes, tasks, passwords, decks, activity logs, and the system config all replicate normally, right? None of these things hinge on a valid PTR record or the ability to receive inbound e-mail, correct?
That’s what I’m looking for. Now, you addressed this in option #2, and I will get to that in a minute, but my point is that I’m not proposing anything absurd, I’m proposing an approximation of the following code be added at the end of a DNS check (sorry, my shell script syntax may be a bit off):
echo “DNS check failed. We recommend resolving these DNS issues prior to install. Retry DNS check, Abort Install, or Proceed Anyway (R/A/P)?”
if var01 == “R”
then GOTO dnscheck
else if var01 == “P”
then GOTO install
else exit 0
That’s literally all I’m looking for; I’m not looking to fundamentally change the install process.
Your recommendation for the alternative is a Nextcloud instance I build from the ground up and tie to /e/OS. This is certainly possible, and it’s not entirely off the table. However, my logic is that, while I’m at least fairly competent in this sort of set up, I’d have greater trust in the people smarter than me, who wrote the install script, to not only be more effective at integrating all the components, but also to ensure that updates and additional integrations don’t break things in a way that is more likely to happen if I’m running my own separate Nextcloud instance.
You’re fully on point in this section. We agree completely, and again, I’ll concede that my example was questionable in terms of complete consistency. I appreciate the link that seems like a viable means of keeping my data local while the code runs on a VPS (Hetzner seems really cool)…but forgive me sounding like a broken record…the reason this solution is being proposed is because of a break condition in the installer that doesn’t account for valid configurations that won’t pass it.
Your post is a font of information; I appreciate the provided links and Crowdsec is likely to be implemented in my instance, regardless of where it lives.
I do sincerely appreciate your time and thoughtful responses here.