Could provide a set of non-standard ports on nine.testrun.org

Feature Proposal
21

EDIT: the problem was resolved, it is a bug with native-tls. Fixed by explicitly setting certificate checks to “strict”. It was set to legacy “automatic2” which was used for old accounts created in old DC versions.

The bug is fixed in core 1.156.2 and should not affect most users, only those who created accounts in old DC versions.

1 Like
22

I would like to raise a concern regarding the implementation of ALPN (Application-Layer Protocol Negotiation) for imap and smtp on port 443 (as seen in recent chatmail/relay changes, e.g., PR #357).

While this multiplexing allows bypassing simple port-based firewalls, it creates a significant “protocol fingerprint” (anomaly) that makes chatmail servers easily detectable by DPI (Deep Packet Inspection) systems.

The Problem:

  1. DPI Signature: Standard HTTPS traffic on port 443 exclusively uses h2 or http/1.1. Sending ALPN imap or smtp on port 443 is an immediate “red flag” for network censors. It identifies the server not as a web server, but as a specialized proxy/mail bridge.

  2. Fingerprinting: Active scanners (like Censys or Shodan) can easily index all Chatmail instances by simply probing port 443 for these specific ALPN tokens. This leads to bulk IP blocking.

  3. Broken Stealth: The goal of using port 443 is usually to blend in with web traffic. Explicitly labeling the traffic as IMAP/SMTP via ALPN defeats the purpose of using port 443 for obfuscation.

Suggested Alternative:
Instead of multiplexing via ALPN on a single port, it is safer to:

  • Use subdomains (e.g., mail.example.org) with standard ports (993/465).

  • If port 443 must be used for mail, it should be done through a proper stealth tunnel (like VLESS+Reality or WebSockets) where the ALPN remains h2 to mimic a real web server.

Conclusion:
By forcing ALPN imap on port 443, we are making the Delta Chat infrastructure more vulnerable to automated blocking and protocol-based filtering. I suggest making this behavior optional or removing it in favor of more standard-compliant configurations.

23

@cewama2955 JMAP would provide an obvious forward-looking alternative for blending in with web traffic that could solve further use cases: