SmtpClient docs recommend a third-party library that is not FIPS-compliant

[AnthonyMastrean]

Issue description

.NET manages FIPS compliance by passing "cryptographic primitives calls through to the standard modules the underlying operating system provides". This is the case for the entire standard library on Linux and Windows.

https://docs.microsoft.com/en-us/dotnet/standard/security/fips-compliance

However, on the SmtpClient docs, you recommend MailKit (and other libraries) that do not make the same choices or guarantees.

https://docs.microsoft.com/en-us/dotnet/api/system.net.mail.smtpclient?view=net-5.0#remarks

MailKit depends on MimeKit which depends on Bouncy Castle, which reimplements cryptographic primitives instead of targeting the "standard modules the underlying operating system provides". Bouncy Castle is FIPS-validated on a 5-year-old version of their library targeting .NET 4.5.2.

https://www.bouncycastle.org/fips-csharp

Target framework

• [x] .NET Core
• [x] .NET Framework
• [ ] .NET Standard

dotnet --info output or About VS info

```console ```

[adegeo]

This user has feedback related to the system.net.mail.smtpclient API.

[adegeo]

@AnthonyMastrean I transferred your issue to the SDK repo as they would be better suited to help you. From the docs perspective there isn't much we can do. If the SMTPClient API hasn't been keepig up with modern protocols, there are two alternatives:

1. Request the SDK team to reimplement this API in a new way to support modern protocols.
2. Find a different alternative to MailKit.

Hopefully they can help with either of those two solutions.

[AnthonyMastrean]

Thank you. It doesn't seem like no. 1 would be a priority, but the SDK team would know best and we're definitely approaching no. 2 on our end. I filed the issue in the docs repository because it seemed like the recommendation/endorsement worked against the linked FIPS documentation and the approach of the .NET framework in general.