Here is a pastebin of the strace -f invocation: https://pastebin.com/qbJRWBrf Please note that I just compiled all skaware myself with s6-networking using BearSSL and this installation does NOT have that problem.
Found it, thanks to the strace. It is indeed a bug... in smtpd-starttls-proxy. The root of the problem is that the UCSPI-TLS protocol, used between s6-ucspitlsd and smtpd-starttls-proxy-io to implement opportunistic TLS, goes against the conventional wisdom that fds should not be shared between programs. (Unfortunately, it has to; there is no other way to proceed that allow a STARTTLS implementation to be as simple.) s6-ucspitlsd and smtpd-starttls-proxy-io run in parallel. The former waits for an instruction from the latter. (On STARTTLS, smtpd-starttls- proxy instructs s6-ucspitlsd to turn into s6-tlsd-io and start deciphering from the network; on a command that proves the client will not attempt STARTTLS, smtpd-starttls-proxy instructs s6-ucspitlsd to forget it and exit.) Crucially, both of these programs have fds to the network socket: smtpd-starttls-proxy uses the socket now, in plaintext, and s6-ucspitlsd may use it later, in ciphertext. smtpd-starttls-proxy-io runs as an asynchronous IO event loop on 4 fds, which it sets non-blocking at start. The socket is among them. And unfortunately, the nonblock flag is not a property of the fd, but of the underlying file, so it applies to s6-ucspitlsd's fds to the network socket as well. And until now, smtpd-starttls-proxy-io failed to clear the nonblock flag before passing the bucket to s6-ucspitlsd. And that is how s6-tlsd-io found itself with a nonblocking stdin+stdout. The bug is unnoticeable when s6-networking is linked against BearSSL, because the BearSSL implementation of s6-tlsd-io does not need the socket to be blocking (it is an asynchronous IO event loop as well, even during the handshake). The libtls implementation, however, expects the socket to be blocking. The latest git of smtpd-starttls-proxy should fix the bug. If you cannot use git, a release of all the skaware packages should happen before next year. Thanks for the report and sorry for the inconvenience. -- Laurent
