I’ve been meaning to post about this for a while as I discovered the bug a few weeks ago, SmtpClient in .Net 1.1 – 3.5 is broken.
By broken, I mean non-standards compliant with the SMTP specification. The SmtpClient object is a fantastic little object that can handle most scenarios you would need for personal apps and sending emails, including multiple encoding formats and SSL handling. However, it has a flaw – it doesn’t close connections to the server correctly.
The SMTP spec calls for the client to issue the “QUIT” command when finishing up communications. The SmtpClient object instead, after sending the mail data, returns control back to the calling app and leaves the connection hanging. Most servers seem to handle this ok but it’s certainly not good practice, and it’s causing me no end of bother now.
I’ve been working on a project called PseudoSmtpServer, which is exactly as it sounds, a fake smtp server designed for Test-Driven Development. It implements the standards-based smtp commands but instead of possessing the usual smtp internals, it stores all information its sent so that it can be queried by test code to ensure sends occurred properly.
It’s been an interesting project, but I’ve had quite a lot of problems, some of which are due to this SmtpClient bug and some due to the TCPListener not performing as expected (in particular, taking a long time to release a socket.) This generally leads to performing erratically, seeming to fail without cause generally because the previous test claims to have cleaned up but in reality hasn’t finished releasing the socket for the next test.
I’m currently rewriting my listener to make direct use of sockets rather than relying on TCPListener’s implementation, and I am led to believe that the bug in SmtpClient may finally have been fixed (about time!) with the release of .Net 4.0. I’m currently trying to upgrade the project to .Net 4.0 but am having difficulty with the Moq libraries. I’m currently investigating this and will post more later on the topic.
Silicon Dreams 