几天前我访问了一个blog，说System.Net.Mail.SmtpClient已经过时了，开源库MailKit和MimeKit正在取代它。
我可以看到docs，但没有在reference code和库中找到相同的。它是否过时了？
[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
正如Liam指出的那样，由于文档中的错误，这已经过时了。 Is System.Net.Mail.SmtpClient obsolete in 4.7?
它在.NET Framework 4.7中并不过时。由于自动文档生成器中的bug，它在API浏览器中无意中被记录。但是，它在Mono和Xamarin中已经过时了。
微软已正式将.NET类标记为由开源库取代。
SmtpClient的文档现在读到，
已过时（“SmtpClient及其网络类型设计不佳，我们强烈建议您使用https://github.com/jstedfast/MailKit和https://github.com/jstedfast/MimeKit”）
SmtpClient的主要问题是它具有令人困惑的连接生命周期。
连接到SMTP服务器可能非常耗时，尤其是在启用身份验证的情况下，因此每个SmtpClient对象都有一个内部连接池。
这是一个相当奇怪的设计。考虑一下典型的数据库连接。在SqlClient上调用Dispose时，底层连接将返回到池中。创建新的SqlClient时，将检查池是否具有相同连接字符串的活动连接。
使用SmtpClient，调用Dispose将关闭对象连接池的所有连接和漏水。这意味着您不能将其与典型的using块模式一起使用。
像HttpClient这样的共享实例的众所周知的方法不能在SmtpClient中使用。
好吧，不。 ，与HttpClient不同，Send / SendAsync方法不是线程线程安全的。因此，除非您想要引入自己的同步方案，否则也不能以这种方式使用它。事实上，SmtpClient的文档警告说，
相比之下，MailKit中的SMTP客户端表示与单个服务器的简单连接。通过消除内部连接池引起的复杂性，实际上可以更轻松地为MailKit的连接对象创建特定于应用程序的池。