Rework Send-MailMessage cmdlet with MailKit#10246
Rework Send-MailMessage cmdlet with MailKit#10246ThreeFive-O wants to merge 4 commits intoPowerShell:masterfrom ThreeFive-O:Send-MailMessage_MailKit
Conversation
|
@TravisEz13 Tests for |
|
cc @SteveL-MSFT about if this is the right place for this |
|
We have a list of Assemblies trusted for remoting here https://github.com/PowerShell/PowerShell-Native/blob/534965cb5f5657a019815216a09de419dc6eec91/src/powershell-native/nativemsh/pwrshcommon/pwrshcommon.cpp#L671 Work with @adityapatwardhan on how you can progress. My proposal would be that we publish a pre-release of PowerShell-Native with your changes and you can work off of that.
|
|
@PowerShell/powershell-committee reviewed this, we appreciate this work, but ask that this be a module published to PSGallery. A decision whether this ships in PowerShell will be decided later.
|
|
This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 30 days. It will be closed if no further activity occurs within 10 days of this comment. |
|
I don't agree that existing functionality should be moved to a separate module. It's too bad SMTPClient was deprecated, but this seems like a punishment to the community to remove a builtin feature and put it elsewhere. |
PR Summary
This PR will fix the underlying architecture of the Send-MailMessage cmdlet using the actively maintained
MailKitSMTP client.Note:
System.Net.Mail.SmtpClientreceives no further development and only supports STARTTLS secure connections.Enhancements
Benefits of MailKit
Backward compatibility and breaking changes
All parameters are left as they are, BUT
Credentialparameter is the only way to provide credentials right now.System.Net.Mail.SmtpClienthas 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.
DeliverNotificationOptionis 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.
Encodingparameter no longer has any influence on subject/body encoding as this is handled by MimeKit-> Requires further research, but may be subject to deprecate.
UseSslis 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 forUseSslbut can of course be overridden with any other port number; IfUseSslis 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
UseSslparameter for STARTTLS (though it wouldn't have any relevance in the code and would be a non-functional parameter likeEncoding, 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:
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
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.