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%.
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.
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.
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.
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.
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?