Part 4 — Communication

What’s in a chat program?

If your org using any chat system right now, it’s almost certiantly Slack. There’s plenty of open-source alternatives to Slack, and it’s important to understand what you want out of a chat program, as you have more than one good option to choose from.

The top four open-source alternatives I would recommend to Slack are Matrix, Rocket Chat, and Zulip. Each have their own strengths and weaknesses. Here’s some questions you can ask yourself, or your chapter leadership, and what option that might be best for you:

• If privacy and security is your utmost concern, Matrix is the right option. Rocket Chat also offers encryption but isn’t designed with the security primitives Matrix is. Zulip and Mattermost do not offer end-to-end encryption (your admin can read all messages).
• Matrix is a very community-oriented project. Large enterprises like Firefox or European government agencies have started using Matrix apps becuase of their high security, but the protocol is driven as a community process rather than controlled entirely a single corporate entity.
• If you want the most Slack-style experience, Rocket Chat fits the fill best. Even on the free plan, it offers more compelling features than Slack (with the exceptoin of a limit on mobile push notifications)
• There’s one additional option that’s a bit different – Zulip. Zulip doesn’t have the advanced security features of Matrix or the boatload of features Rocket Chat or Mattermost have. It does have a very unique way or organizing conversations, which many technical teams love. It’s also dead simple to setup (it doesn’t use Cloudron, however), and cheap to run. They also offer preposterously low pricing for their cloud hosted project for volunteer organizations.

Having said all that, I’ll be continuing with Matrix here. I think it has the most potential long-term, and it’s rock solid security is a great benefit to provide as a default. That doesn’t mean however, that you should overlook the other options.

Matrix

Matrix is a secure communications protocol, meaning that it requires a server  and a client to function the way you expect chat programs, like Slack, to work. Matrix will look familiar to users of Slack, Discord, or Mattermost, but unlike those options, it’s fully open-source and all messages are encrypted by default. It’s a perfect fit for chapters.

There’s multiple servers and clients for the Matrix protocol, but we’re going to focus on the biggest two – Synapse, the server, and Element, the client.

Matrix is designed with decentralization in mind, meaning it is designed to function as a network of servers, of which your installation is just one node. This is great for a lot of purposes but can be confusing for people who are less tech-savvy, but it’s simple in practice. Basically, you can allow your sever or channels on your server to allow users from other servers. So users at Albuquerque DSA can use their Matrix accounts to login to Chicago DSA’s chat server (if they allow it) – there’s no need to make a new account on the Chicago DSA matrix server. Unlike Slack, this isn’t limited to one pair – you can have as many people from as many servers as you like in one room.

Matrix doesn’t yet have the polish that competitors do, but it does have a huge amount of energy behind it (several European government agencies have bought into it) and it’s improving constantly.

As it’s a bit too long to fit in here, check out our Matrix guide for a step-by-step guide on getting it set up.

Email

Email is more complicated than anything else here, so we’re going to return to it here for another look. Email can be critical for sending chapter communications, and conversations not appropriate for a chat app. Before we go in-depth on Cloudron’s email services and how they interact with your apps, I want to take a moment to familiarize you with the main concepts of email routing.

Earlier, we enabled the SMTP server in Cloudron. SMTP stands for Simple Mail Transfer Protocol, and it is anything but simple in practice. Luckily, Cloudron handles the hard parts for us, but there is one thing it cannot help with – your IP reputation.

IP reputation

As you recall, when you created your VPS you first accessed it with its IP address. Nearly all mail systems, including Cloudron itself, compare incoming emails’ source IP against IP denylists. There are public IP denylists and private ones, but all email servers use IP denylists in one way or another to gauge how trustworthy your IP is.

To illustrate how they work, I’m going to use a Gmail user on your server as an example. Let’s say Alex sets up his Rocket Chat account with his email, alex@gmail.com. Rocket Chat will send his two-factor login code from Cloudron to Gmail. Gmail will analyze the message – using a huge variety of factors like sending IP, message content, and Alex’s preferences, to determine 1) if it reaches their inbox at all and 2) where it will go if it does.

Let’s start with sending IP. There are a limited number of IPv4 addresses, so big hosting providers, such as Digital Ocean and AWS, are forced to re-use them. It is also possible to detect what “block” an IP comes from – so Gmail knows your message is coming from Digital Ocean, for example.

Unfortunately, spammers use virtually all VPS services to send spam, so these companies usually do not have very reputable IPs to begin with. This usually isn’t enough to prevent your message from being received by Alex’s Gmail account, but it may send it to their spam folder.

If you want to avoid this problem, a much more reliable way to send mail is via a “transactional email service” such as Mailgun. These companies go to great lengths to protect their IP reputation, and so your messages have a better chance of being delivered. They also cost money, but not too much (roughly a dollar per thousand emails for Mailgun, a bit more or less with other providers). To keep costs low and this guide short, we’re going to stick with the built-in SMTP server to send mail and hope for the best, but if you choose to use a service like Mailgun the process is fairly straightforward.

How to use Cloudron’s Email services

By default, Cloudron will only be configured to send mail. This is all you need for your apps to send things like password reset emails or two-factor codes. After a few changes, you can turn Cloudron into a full-service email provider, with email inboxes, delegation, powerful search, and many more features.

Setup

Setup is easy. Open the Cloudron menu (your name, in the top right) and click Email. Then click Enable.

Cloudron should automatically configure all your email DNS records for you! It may take a few minutes (and sometimes a few hours) to fully take effect. You can click the Status screen to ensure everything is configured correctly.

Troubleshooting tip: If, after a day, you still aren’t seeing these records in Gandi, click the record and Cloudron will show you exactly what it’s expecting to see – then enter that information into Gandi in LiveDNS or ask in the Cloudron forums.

That’s it! You can view the post from Cloudron on troubleshooting emails for more help if you need it.

Using your new email account

After your email is ready to go, you can create a mailbox. Mailboxes are tied to Cloudron accounts and permanently fixed to a domain. Remember – your emails live in the Cloudron service itself, not with any single app.

To begin, click “Email” in the Cloudron menu. Click the pencil icon next to the domain to add things like mailboxes, mailing lists, and catch-alls.

You can create new user accounts under the Users tab, but we’ll go over that more next – let’s start with you as the admin. Click “Add” in the mailboxes menu. You choose an owner (including a group) and the name of the email. That’s all you need to do.

logging in with Cloudron email boxes

To login, enter the connection details on this screen into your email app or use one of the apps listed that have connection information ready to go. You will likely need to enter the connection settings manually in your email app, unless you’re using a Cloudron email app like Roundcube or SoGo.

Use the mailbox name as your authentication username and your personal Cloudron password to login to the mailbox. I strongly reccomend sending a test email to another email account and replying via the other email account to make sure everyting is setup correctly.

security

For Cloudrons with multiple domains, there is always still only one mail server location — this is a limitation of email. Technical users can find the mail server location. For example, if you run redrockdsa.com and bobsblog.com, and use bobsblog.com as your mail domain, all users who get an email from redrockdsa.com can find out that the same server also runs bobsblog.com.

While Cloudron offers 2FA (which you should go turn on right now if you haven’t already), IMAP doesn’t. This means if someone gets your Cloudron password, they can see all of your emails. Cloudron is looking into implenenting 2FA for apps but as of 6.3 it’s not here yet. This is one of the few major downsides to using an open and standards-based email service – 2FA is not in the standard for email and puts your emails at risk compared to a closed provider like Gmail or Outlook. It’s imperative that anyone with a mail-enabled Cloudron account uses a unqiue password — a password manager (like Bitwarden) is the best option here. This should be a hard requirement. Cloudron logs don’t provide any context for login events that can help you determine if a user is malicious or not, so someone can be surrepitously snooping on emails with a stolen password forever without being detected.

What’s next?

There’s more security questions to consider now that you have a solid base of applications installed and ready to go. You could start editing documents, sharing files, chatting with your comrades,  and setup an email service for updates and help. Before you move on to install more apps, let’s ensure that you know the basics on how to use a computer safely.