Capabilities in Server Hello message

If DC client connects to chatmail server, and server not announce XDELTAPUSH capability - how DC client will behave, comparing to normal?
And same question for XCHATMAIL.

They both are probably means that client can use sam additional functionality.
I’m asking this because I probably going to remove those strings from server hello, but want to still use client and server on 100%.

Paraphrasing, with English polished. I’m not sure if I understand the middle paragraph.

I think you want to camoflage a Chatmail server as a regular e-mail server. Good idea.

Feature request: there should be a setting for that.

You’re thinking right. I don’t like to show those specific capabilities to the whole world. I want it to looks like perfectly usual mail server.

These strings are in server’s config file, it’s trivial to comment them out.

My question is on the consequences of such configuration. What will I miss, using DC clients with server not showing those caps?

Maybe clients can get info on server functionality after they logged in?

I have discovered Delta Chat client connects to port 143 with IMAP unencrypted first by default (self-hosted chatmail relay server). Server responds with plaintext capabilitiles ‘xchatmail’ and ‘xdeltapush’. It looks like the unique fingerprint for chatmail relay server which can be detected by an outside observer. When I have disabled listen to port 143 in dovecot config and have changed IMAP port to 993 in client, Delta Chat client connects to port 993 first with encrypted IMAPS.
Guess, It’s need to fix with disabling listen to port 143 in default chatmail relay configs to hide the chatmail relay fingerprint. Then it will look like a regular mail server.

It’s not the solution.
The same capabilities you can get via IMAPS without logging in. Try curl -v imaps://nine.testrun.org

2 Likes

Does it matter that capabilities are transmitted in the server response while the server’s response is encrypted? Guess, it’s enough if the aim is to hide the chatmail relay fingerprint.

It’s enough to protect against someone listens on your network traffic, which requires some conditions.
But it will not protect from active probing, which is technically much simplier - no conditions needed, everyone can do it with curl or other simple tool.

Maybe. It depends on the probability of such probing of mail servers for chatmail relay fingerprints detection.

AFAIK active probing is implemented and currently used al least by Chinese and Russian ‘great firewalls’. Iran used it in the past, and may return to it in at any time.

Would you like to ask chatmail development team in the github issue about this problem?

Github issue does not guarantee the fix…
As of developers - they know about this problem already. But it takes time.

I still didn’t set up chatmail server, but another forum user did.
He set it with help of chatmail/relay/cmdeploy script.
After the setup was done, he comment out imap_capability = +XDELTAPUSH XCHATMAIL in /etc/dovecot/dovecot.conf
After Dovecot restart, DC-specific capabilities were no more listed in IMAP server responce at least before the succesfull login.
Server and clients are doing ok.
Even mobile notifications seems like working for now (but see this
How to install own chatmail and notification proxy? - #12 by link2xt )
What are we missing here?

If DC-specific capabilities info is actually used by DC core, imho it should be accuired after the login. For IMAP server to change (update) server capabilities answer after succesful client login is perfectly possible by RFC.

But I didn’t find a way for stock Dovecot to sent different capabilities to non-authentificated and authentificated users.

The ‘fastest’ way in network terms is probably to send ‘real’ capabilities with ‘OK’ server answer on successful login (with post-login script probably); but it’s not clear for me yet is it allowed by RFC or not.

Client (core) may also send CAPABILITIES command after the login. Maybe it can be answered by a script, so patching the Dovecot will be not needed. Will look into it later.

Dovecot already does this. It just does not have a way to change capabilities only for logged in users.

What if in dovecot.conf imap_capability = +XDELTAPUSH XCHATMAIL will be disabled, and postlogin script will do something like:
printf "* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN XDELTAPUSH XCHATMAIL]\r\n"
Will current DC core understand it?