Is System.Net.Mail.SmtpClient obsolete in 4.7?

Question

Few days back I visited a blog that said System.Net.Mail.SmtpClient is obsolete and an open source library MailKit and MimeKit is replacing it.

I can see docs for that but not finding the same in reference code and in library. Is it obsolete or not?

[System.Obsolete("SmtpClient and its network of types are poorly designed, we strongly recommend you use https://github.com/jstedfast/MailKit and https://github.com/jstedfast/MimeKit instead")]
public class SmtpClient : IDisposable

Answer 1

As Liam pointed out, this is obsolete due to a bug in documentation. Is System.Net.Mail.SmtpClient obsolete in 4.7?

Answer 2

It is not obsolete in .NET Framework 4.7. It was inadvertently documented as such in the API Browser due to a bug in the automated documentation generator. However, it is obsolete in Mono and Xamarin.

Answer 3

... Microsoft has officially marked a .NET class as being replaced by an open source library. The documentation for SmtpClient now reads,

Obsolete("SmtpClient and its network of types are poorly designed, we strongly recommend you use https://github.com/jstedfast/MailKit and https://github.com/jstedfast/MimeKit instead")

The main problem with SmtpClient is that it has a confusing connection lifecycle. Connecting to a SMTP server can be time-consuming, especially if authentication is enabled, so each SmtpClient object has an internal connection pool.

This is a rather strange design. Consider for a moment a typical database connection. When you call Dispose on a SqlClient, the underlying connection is returned to the pool. When you create a new SqlClient, the pool is checked for an active connection with the same connection string.

With SmtpClient, calling Dispose closes all of the connections and drains that object's connection pool. This means you can't use it with the typical using block pattern.

A well-known approach of the shared instance like HttpClient cannot be used in SmtpClient.

Unlike HttpClient, the Send/SendAsync methods are not thread thread-safe. So unless you want to introduce your own synchronization scheme, you can't use it that way either. In fact, the documentation for SmtpClient warns,

There is no way to determine when an application is finished using the SmtpClient object and it should be cleaned up.

By contrast, the SMTP client in MailKit represents a simple connection to a single server. By eliminating the complexity caused by internal connection pools, it actually makes it easier to create an application-specific pool for MailKit's connection object.

Ref: MailKit Officially Replaces .NET's SmtpClient