I’m loving using mail-in-a-box via the Nextcloud portal. One of the things I like the most about Nextcloud is the security options that you can use to prevent unauthorized access to the portal via, e.g., using Rainloop for email.
I am thinking that I might want to force all connections except admin to go via the portal. Is there a way that I can set up (e.g. in the DNS settings) to automatically redirect all connections to the /mail url to the /cloud url. With a straight DNS provider I would know how to do that. But I can’t work out how I might do it with MIAB.
Any thoughts you might have would be much appreciated.
You would probably do this with NGINX, not the DNS settings.
I will try it in the next hours. Hopefully I succeed, and I’ll post how to do step by step
EDIT: But wait. I wasn’t even aware of the box.tld/cloud access. I was believing only a small portion of NextCloud was used for the contacts. How much of NextCloud is in MIAB? All of it?
How do you access your mails once you’ve logged in through box.tld/cloud? Do you need to go to box.tld/mail afterwards? (I’m new to this, I didn’t see any direct access in the nextcloud portal). If yes, the redirection will be a problem. It would be a little more complicated as you would need to redirect to login, and not redirect anymore once logged in, then.
EDIT2: Ok, you’re talking of Rainloop, so I guess this is my answer. It this installed by default or you installed it on top of MIAB base install?
Literally all of Nextcloud! It’s pretty brilliant because now Nextcloud 20 has it all just there set up as default. All you have to do is unlock admin by making your user an admin and you have a fully-functioning nextcloud install and use Rainloop for mail. The only downside is that the Nextcloud Mail App uses php 7.3 and we’re stuck on 7.2 in Ubuntu 18.04. If you could integrate with Nextcloud Mail and block off or redirect the box.tld/cloud url you could create a perfect secure system (Nextcloud has full support for FIDO2, restrict login by IP, etc.) with everything fully integrated (contacts, calendar, files, talk, notes, etc.).
I just have two things to figure out: (1) how to upgrade to php 7.3 without breaking everything; and (2) redirect or block box.tld/mail. The problem is I’m not sure how to work the redirect in nginx and I’m afraid any changes would just get overwritten on update, hence why I was hoping for a DNS-level fix.
On another server, I’m running PHP 7.4 on ubuntu 16 since a while now, so this can’t be correct. As for not breaking everything in MIAB, that has to be tested.
Ok, but I’m willing to try this. Seems nice.
Rainloop isn’t installed by default with the standard MIAB install, or is it? You have to add it. Can you just confirm this?
Yes, this seems to be a risk.
If I’m not mistaken, you can’t redirect to a path directly with the nameservers. To a subdomain, yes. To a path, no. And you also cannot redirect from a path. There might be tricks. One very simple solution would for example be to use another server or another domain (and use a registrar with a redirect service): You can point to another IP (and you redirect again from that IP to the path you want, using NGINX or Apache there) or another domain (and for example configure a redirect with the registrar, many offer this).
For this, you would directly redirect box.tld/ to box.tld/cloud (going through an external server to not do it internally if you don’t want to use the local NGINX). You can also simply use newdomain.tld and use directly the registrar redirect to box.tld/cloud where you would land.
Yes, there is probably a far easier solution: Redirect with PHP in a file you host on your MIAB. It’s silly, I didn’t think about this immediately. You could redirect box.tld/ or any subdomain you create, to anywhere you want, including box.tld/cloud.
If you can redirect box.tld/ or whatever.box.tld/ to box.tld/cloud, that should be good, isn’t it? It wouldn’t prevent people from accessing manually box.tld/mail in any way, though, if you really would want to forbid this (but here, you need quite the local NGINX)
This is a simple and very effective solution! What program runs that? I knew to do this with .htaccess files with Apache but I was believing the same thing to be impossible with NGINX.
By searching about the external solution, there is a service which allows you to do it directly: https://redirect.center . So, with this you could make a redirect to a path on the nameserver level, but it sends the user to the service, which then sends him back. Probably not very good for performance/speed.
You cracked it! Beautiful. I really hoped there was a DNS-level solution to this.
Thanks to you, I have now got my ideal system. I realized I could install an old version of the Mail app that supports php 7.2 (the last good one is 1.4.1). So now I have that installed and have the ability to add attachments from or save them to Nextcloud files directly in the web interface and to directly save calendar ics files into the Nextcloud calendar via the web. I also have the ability to use encryption via the easy Mailvelope plugin. And with the redirect working I can force all users to have a certain password strength, use FIDO2 or FIDO/U2F 2FA and even restrict login by IP address.
This is really quite a major thing. I have searched high and low for an email service that could integrate like this with these security features and a multi-user admin panel of this strength, that was not Gmail or Outlook. If you look hard enough you will find that this actually does not exist. Mailbox, StartMail, Tutanota, Posteo, Kolab, Protonmail, etc, etc, etc. Not one of these can do this. Mail-in-a-Box can!
Thanks very much for your thoughts on all of this. Looks like daveteu have cracked it with the DNS change. But I actually think your ideas would also have worked, albeit a bit fiddly.
Regarding php, it is true you can use later versions on Ubuntu 18.04, but they are not in the default repos. You need to install via a PPA or directly. But either way, it will cause an immediate breakage to the webmail and nextcloud portals and it takes quite a bit of fiddling to get it to work again, after which I wasn’t sure it would survive an update.
However, I just realized I was being stupid and could just install an older version of the Mail app (the last good version being 1.4.1 as 1.4.2 has a bug preventing attachments from working). So I did that and applied daveteu’s solution and now have the perfect system.
I am seriously happy right now. As I mentioned in my reply to daveteu, this makes Mail-in-a-Box the only email solution out there that can do what you can do with G-Suite and O-365 in terms of multi-user management, enforcement of password strength and 2FA using USF/FIDO standards, while also having the integrations that Nextcloud offers, including Talk.
I believe that this takes Mail-in-a-Box to a new level that makes it very suited to a business environment and reckon the developers should do what Mailcow does and have a business offering.
His solution isn’t DNS based. I guess it’s probably run by NGINX. They seem to have actually adapted it to work kind of how Apache works with .htaccess files, which isn’t good for performance, but it isn’t really the goal with MIAB, so…
By looking on Github, one guy had exactly the problem you were fearing: His NGINX config was overwritten by MIAB, so they came up with this solution.
The service mentioned above allows you to do it with DNS, but there is really no use, Daveteu solution is far better IMHO.
Yes, you would need to add a repository to have access to newer versions of PHP. Happy to hear there is an older version working without a PHP update. I will try it. Thank you for making me discover all this!
Ah, OK. In the linked article and the instructions it says " do sudo ./mailinabox/tools/web_update to refresh the dns" so I figured the web_update must have had some impact on the DNS settings. I know when managing DNS settings from my usual DNS providers this kind of redirect is something you can add. So I thought this is what was happening here. Either way, works a charm.
Definitely check all this stuff out. I really think this is Mail-in-a-Box + Nextcloud fully integrated and providing a level of service that you cannot find with any providers but google and microsoft. Very exciting.
Maybe you’re right. I’m unsure what exactly happens in the background with this. I would have to look further. But the fact it works is what’s important! You’ve got a nice solution pretty quickly, and now we all have it. That’s nice. I will definitely check it out. Cheers.
There you go, @MIAB-lover was correct! This is a really great solution. Thank you @daveteu and thank you for the explanation. Wonderful that it won’t get overwritten by updates. But even if it were to it’s such a simple thing it wouldn’t be hard to put back in order.
I wish I was that wise! It did break Roundcube! Also Nextcloud, but could work it out eventually. Thankfully, I keep backups on the VPS and run backups just before fiddling around with things so it was a one-click fix.
I created this file, with this user priviledge and following contents,
ubuntu@box:/home/user-data/www$ ls -lah
-rw-r–r-- 1 user-data root 61 Jan 30 11:18 custom.yaml
ubuntu@box:/home/user-data/www$ cat custom.yaml (ABC is the fake name, I use abc.com, instead of box.abc.com to access email; both ways work to access webmail).
abc.com:
redirects:
^/mail*: $scheme://abc.com/cloud
when I run webupdate, I got the following errors. What’s the reason, you think? Thanks!
buntu@box:~/mailinabox$ sudo ./tools/web_update
500 Internal Server Error
Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.
ubuntu@box:~/mailinabox/conf$ cat nginx-primaryonly.conf
# Control Panel
# Proxy /admin to our Python based control panel daemon. It is
# listening on IPv4 only so use an IP address and not ‘localhost’.
location /admin/assets {
alias /usr/local/lib/mailinabox/vendor/assets;
}
rewrite ^/admin$ /admin/;
rewrite ^/admin/munin$ /admin/munin/ redirect;
location /admin/ {
allow 192.168.0.0/16; (this is what I did)
deny all; (this is what I did)
proxy_pass http://127.0.0.1:10222/;
proxy_set_header X-Forwarded-For $remote_addr;
add_header X-Frame-Options “DENY”;
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy “frame-ancestors ‘none’;”;
}
# ADDITIONAL DIRECTIVES HERE
# MOVED NEXTCLOUD SECTION TO ALLDOMAIN.CONF (**this is what I did)
At each upgrade time, I may have to manually do this as well.
root@box:/home/user-data/owncloud# nano config.php
‘trusted_domains’ =>
array (
0 => ‘abc.com’, (***default is box.abc.com)
If you can help figure out whether we can make these into custom.yaml, that would be great!
Or, we can do those your custom.yaml into these two files, it will work as well.
