PR Summary

This PR will fix the underlying architecture of the Send-MailMessage cmdlet using the actively maintained MailKit SMTP client.
Note: System.Net.Mail.SmtpClient receives no further development and only supports STARTTLS secure connections.

Enhancements

• Fix Send-MailMessage incorrectly handling ValueFromPipelineByPropertyName parameters #7591: Pipelining into the cmdlet is now supported
• SMTPS is now supported

Benefits of MailKit

• Modern actively maintained dependency (would fix HadErrors() returns $true if Send-MailMessage cmdlet is used #10015)
• Secure connection upgrades from insecure connections using STARTTLS is supported implicitly (no parameter has to be specified)
• Secure connections over SSL/TLS is supported (Gmail, Yahoo, ... see smtpServer requires secure connection or client was not authenticated. the server response was: 5.7.0 must issue STARTTLS command first #8987)
• MailKit and MimeKit allow easier implementation of missing functionality (see Send-MailMessage add support for INLINE attachment  #9191)

Backward compatibility and breaking changes
All parameters are left as they are, BUT

• Credential parameter is the only way to provide credentials right now. System.Net.Mail.SmtpClient has the ability to get the default credentials from Windows.
  -> Requires change in documentation; X-plat credential provider solution for PowerShell 7 might be the solution to that.

• DeliverNotificationOption is implemented, but the functionality should be reviewed as all tested platforms either don't support Delivery Status Notfication (DSN) (e.g. Gmail, GMX, Yahoo) or ignore the setting (Outlook.com - btw the only SMTP server I've came accross which reports DSN capability).
  -> Subject to discuss in RFC to deprecate this parameter.

• Encoding parameter no longer has any influence on subject/body encoding as this is handled by MimeKit
  -> Requires further research, but may be subject to deprecate.

• UseSsl is no longer mandatory to allow STARTTLS upgrade from an insecure connection. The parameter is now used to explicitly state the the entire connection should be wrapped in a SSL/TLS connections, also known as SMTPS. -> Using Port 0 (default - automatic port selection will use Port 465 for UseSsl but can of course be overridden with any other port number; If UseSsl is not specified the default port 25 for SMTP is used, although most STARTTLS endpoints use port 587).
  -> Critical breaking change for automated scripts; Subject to discuss
  Possible workaround: Use another parameter for SMTPS functionality and keep UseSsl parameter for STARTTLS (though it wouldn't have any relevance in the code and would be a non-functional parameter like Encoding, though not breaking any scripts)

Test infrastructure
The Pester tests use netDumbster which only supports insecure connections.
STARTTLS and SMTPS functionality have been tested interactively against:

• Outlook.com (STARTTLS 587)
• Gmail.com (SMTPS 465)
• Yahoo.com (SMTPS 465 and STARTTLS 587)

PR Context

As of #9178 is marked as obsolete and an RFC PR PowerShell/PowerShell-RFC#160 was opened to discuess the future of the cmdlet.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).