The CLOSE-WAIT is from your client never closing the connection.
Since you never interact with the connection after the close event, I don't see how this could be handled. The same goes for plain net.Conn / net.TCPConn connections.
If you want to maintain a connection pool, you'd be responsible for ensuring that an application level healthcheck/keepalive can still go through. HTTP/SMTP are very different protocols in that regard.

I don't see anything to do here.

@seankhliao thanks for your reply. Nevertheless I disagree with you. Without bufio it is quite easy to detect that the connection is closed. But with bufio you always need to Peek(1) in advance. I don't know how exactly it could be done, I'm not an expert in OS TCP stack or bufio package, but I'd suggest to introduce some internal channel, which can detect in advance that the TCP connection is closed and an interface that notifies about the closed connection.

The socket API does not provide any mechanism for detecting that a TCP socket is closed without reading from it.

HTTP/SMTP are very different protocols in that regard

@seankhliao generally they are quite similar, they both use textproto wrapped around bufio. And you can see that http transport implementation peeks bufio in a loop (Peek(1)) to detect the closed connection.

@ianlancetaylor, my aim is to avoid reinventing the wheel and have a general implementation to detect a closed connection.

@kayrus If you can find a general mechanism, then, great. I don't know of one.

with my latest change to go-smtp where I'm checking for a connection + buffering what is read + write the buffer down the test looks better: the connection is closed.

the recent test (see https://gist.github.com/kayrus/31023f2a1cc30b1744b3c45cd3557d21) closes the connection properly.

I'm sure that the similar logic can be done in bufio. @ianlancetaylor what do you think?