How to install own chatmail and notification proxy?

Mutual Help
1

Hi there :wave:

So I was planning to upgrade my server which is currently running dovecot+postfix on Arch Linux to chatmail so that iOS devices get instant notifications.

However, after reading docs, FAQs and the forum, I’ve came to the conclusion that I need to deploy the chatmail server. But now I have some doubts regarding this…

  1. Can I try to install chatmail on Arch Linux or will it fail? I would check and execute the code to see what it does but I’m afraid it could break my current setup :grimacing:
  2. If I installed it successfully, would in need to install the notification proxy too or how would I register(?) my own chatmail with the central proxy? I’m not sure I completely understand how it works, TBH…

In any case, I just need some hints from someone with experience to know if what I’m trying to do may be doable or if it is likely doomed, not the precise steps to make it work.

Also, if I get this to work, I may try to contribute a PKGBUILD to Arch Linux AUR so that other people may benefit from it.

Thanks in advance :blush:

2

Currenty chatmail setup expects Debian system as it installs packages using apt, e.g. here: chatmail/cmdeploy/src/cmdeploy/__init__.py at 610637da8009f13a3f2aa5c7a0af1cb51953e1b1 · deltachat/chatmail · GitHub
You can install chatmaild components manually without cmdeploy tool, but integrating this into dovecot+postfix setup manually is not documented. If you really want to do it, probably better setup a VM with Debian first to see how it works and migrate the configs from there.

Instant notifications rely on the metadata server that is integrated into dovecot via config options and Lua script.

There is a central notification proxy running GitHub - deltachat/notifiers: Notify devices on https://notifications.delta.chat/
There is no need to install your own and it is not really possible to do so as it requires tokens from Apple and Google linked to the Delta Chat application. You only need to install your own if you want to fork Delta Chat clients.
There is no need to register your chatmail server anywhere, chatmaild services will talk to notifications.delta.chat to send notifications but this does not need any special token, in the end phone operating system obtains a device token and it is passed back to Apple/Google servers when a new message arrives. How notifications work is described in FAQ - Delta Chat, you may also want to read the blog post Instant Onboarding and Instant Message Delivery - Delta Chat

1 Like
3

Got it. Thx :slight_smile:

That’s a good starting point I think. Depending on the time I have I may try to tweak the scripts to make them work in Arch or start with a VM as you said.

Maybe dockerizing it would be a good idea, there’s another thread about that here → Chatmail server docker deployment

I’ll report what I find.

4

Hi again :wave:

I’ve managed to setup a Debian VM with version 1.0.3 of cmdeploy. Now I will investigate the config and replicate it in my Arch system.

If all goes well I’ll try to document what I did. Maybe it can be added to the FAQ page or something like that…

However, I have one doubt regarding DNS: which of the requested entries are really necessary and for what? I ask this because I’m not sure which entries are needed for autoconfiguration of clients, which for the push service, which for the SSH keys of the web server, and so on…

In my previous setup it was enough with one DNS entry. :thinking:

The cmdeploy script have asked for all these keys at different moments of execution:

mydomain                     A [...]
mydomain                     MX [...]
_submission._tcp.mydomain    SRV [...]
_submissions._tcp.mydomain   SRV [...]
_imap._tcp.mydomain          SRV [...]
_imaps._tcp.mydomain         SRV [...]
mydomain                     CAA 128 issue "letsencrypt.org; [...]
mydomain                     TXT "v=spf1 [...]
_dmarc.mydomain              TXT "v=DMARC1;p=reject;adkim=s;aspf=s"
_mta-sts.mydomain            TXT "v=STSv1; id=202407122012"
mta-sts.mydomain             CNAME mydomain
www.mydomain                 CNAME mydomain
opendkim._domainkey.mydomain TXT "v=DKIM1;k=rsa; [...]
_adsp._domainkey.mydomain    TXT "dkim=discardable"
5

A is for resolution of domain name to IP address.
MX is not really needed but it is a good practice to say that mails sent to your domain should be delivered to the host specified in MX record. This normally defaults to the same domain anyway.

SRV records are not really needed, Delta Chat does not use them as they are not secure.

CAA record prevents someone who gets control over your port 80 but not the keys (e.g. via a vulnerability in nginx after dropping privileges or MITM at your hoster) from issuing a new TLS certificate via Let’s Encrypt or other CA. It is not strictly necessary, but adds some security.

SPF TXT record is for compatibility with receiving hosts that don’t support DKIM. It is a legacy email authentication mechanism.

DMARC is basically useless, but some providers like Google care that it exists, no matter the contents. Could be “v=DMARC1;p=none” and they are still happy, this is what they use themselves, you can check _dmarc.gmail.com. and similar providers. This is just to maybe increase deliverability to such providers.

MTA-STS records are to say that your host uses TLS for message delivery and other hosts should use TLS too. It actually increases security, better have it.

www domain is just for redirect to primary domain in case someone types www in front of domain, not really needed. When we did not have it, we got some reports of people adding www to URL and thinking the server is down.

opendkim record is a “DKIM selector”, chatmail servers use “opendkim” in DKIM signatures to point to this key. DNS record contains the public key that chatmail servers sign messages with. DKIM is absolutely necessary if you want your mails to be accepted by chatmail servers, it is the only authentacation mechanism chatmail cares about.

_adsp is a historic standard RFC 5617: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP), this record says that any mails from us not signed with DKIM should go to trash. Probably nobody looks into this record. Officially this standard was superseded by DMARC. This is likely never resolved by anyone.

1 Like
6

First of all, thanks very much for the explanation :slight_smile: .

So, after reading it, in my case, where I’m only hosting a private server for friends a family I assume I’m OK with just two entries:

  • The A record for my domain.
  • The opendkim record so that delta chat clients use DKIM (which IINM is needed for push notifications at mobile phones).

I’m going to try with those two and the configuration I got from the script and see what happens :crossed_fingers:

Will come back with more news…