No, every protocol does not work that way. A whole lot of protocols has no concept of multiplexing a connection or server initiated events. Since we're talking about e-mail, neither SMTP or POP3 has either of these complexities (SMTP allows client-initiated pipelining if the client sends the right greeting), but doesn't allow the server to multiplex responses or initiate anything, POP3 allows none of it at all). It's not new now, but it is moderately more complex if you're implementing a client.
I don't think it's quite as complex as suggested above, though. You just want to provide access to the socket in case the client wants to select() etc., and offer an API to send a request, a queue to read responses from that allows you to filter by request, and maybe a wrapper that sends a request and waits for a reply matching that request (while putting everything else onto the queue). Then the client can decide if it wants to pretend the protocol is mostly request/response or take proper advantage.
I don't think it's quite as complex as suggested above, though. You just want to provide access to the socket in case the client wants to select() etc., and offer an API to send a request, a queue to read responses from that allows you to filter by request, and maybe a wrapper that sends a request and waits for a reply matching that request (while putting everything else onto the queue). Then the client can decide if it wants to pretend the protocol is mostly request/response or take proper advantage.