For about 25 years StreamSec Tools has been the TLS layer inside other vendors' Delphi network stacks - RealThinClient SDK, NexusDB, kbmMW, Indy, Ararat Synapse, RemObjects SDK and DXSock (if you remember it). Release 4.1.2 is the first where the library carries the application protocols itself, and it happened the interesting way around: instead of bolting TLS onto an HTTP library through an "SSL IOHandler", the HTTP server grew out of a TLS server.

HTTPS AS COMPONENTS. An asynchronous TLS server (IOCP on Windows, epoll/kqueue on POSIX) where every connection speaks TLS from byte one and the application protocol is selected by ALPN during the handshake - no connection reaches your code without an established TLS session. HTTP/1.1 and HTTP/2 are two plugin components over one shared router: register a handler once (a static file, a per-path event, or a handler interface) and it answers identically on both wires; HPACK, stream multiplexing and flow control never surface in your code. There is an HTTPS client and JSON REST client/server components (auth seams, idempotency keys, RFC 9457 problem+json) to match. The stack is hardened by default - strict HTTP/1.1 framing (the request-smuggling classes are refused, not guessed at), the published HTTP/2 abuse patterns (rapid-reset, flood, header-bomb) are bounded, and every limit is a published property you can see in the Object Inspector.

If you built on the RTC SDK: this is a complete replacement for that server stack. This forum and the download site have been running on these components for a while - that is where they were proven, against everyday browsers as well as curl, OpenSSL's ALPN client and Node's HTTP/2 module.

A COMPLETE MAIL SUITE. SMTP, POP3 and IMAP, each as both client and server: inbound MX on 25 with STARTTLS, submission on 587, implicit TLS on 465/995/993, IMAP4rev1 with IDLE and UIDPLUS. Storage is Maildir++ on disk - the same format Dovecot and Courier read - with Argon2id password verifiers, a disk spool with retry and RFC 3464 bounces, and delivery to a smarthost or directly to the destination MX with MTA-STS enforcement. Message authentication is included: DKIM signing and verification (including ed25519), SPF, and DMARC with proper alignment checking, over a built-in DNS resolver so none of it depends on platform DNS APIs. Password auth on a cleartext connection is refused unconditionally, and no configuration turns the receiving MTA into an open relay. The release ships a single-form mail-server demo and a worked web-server demo.

SUPPLY CHAIN. 4.1.2 removes the last copyleft code from a build: the old JEDI Winsock header translations (MPL/LGPL) were replaced by our own translation of the SDK headers, and the Gladman AES assembler moved to an opt-in unit, so a normal build carries no third-party attribution obligations at all. Every release now ships a CycloneDX SBOM with five third-party entries - each stating its license, its reachability (whether it can appear in your binary at all), and the compile-time switch that removes it.

Also in the 4.1.x line recently: an ACME client with unattended renewal (it answers tls-alpn-01 on your live server without dropping traffic, honours ARI, and hot-swaps the certificate), and TLS 1.3 hybrid ML-KEM key exchange tracking RFC 10024, interop-tested against OpenSSL in both directions.

The boring facts: pure Object Pascal, Delphi XE3 through 13, compiles straight into your EXE - no OpenSSL, no Schannel, no DLLs. Win32/Win64, with the same code base targeting Linux, macOS and mobile. Commercial, full source, from EUR 895 per seat, and there is a DCU evaluation you can download without talking to anyone: www.streamsec.com

Feature detail pages: HTTPS - Mail - ACME - The SBOM story - Post-quantum readiness

Questions welcome in this thread - particularly about the one-router-two-wires HTTP setup and the mail store, which were the fun parts to get right.