Powershell: Should Send-MailMessage be marked obsolete

[FireInWinter]

Version: PowerShell 7.0rc3
OS: AWS Linux

Currently Send-MailMessage is marked obsolete, but I don't think it should be. The API behind it should be replaced eventually, but the site that gives the reasons why it should be used, also include a reason what it would still be useful for.

https://github.com/dotnet/platform-compat/blob/master/docs/DE0005.md

It's great for one off emails from tools, but doesn't scale to modern requirements of the protocol.

My reasoning is that the majority of use of Send-MailMessage is exactly the "one off emails from tools" they mention. If someone has some statistics, that would be great, but my guess is that 95% of use of Send-MailMessage would fall under that category. It would be obsolete if someone is using it for sending millions of emails, but I doubt if there are many people doing that.

I would suggest having it marked in some way in the source code, but let's not bug users about a problem that isn't a real problem.

[doctordns]

For simple administrative things, like emailing the results of a PowerShell script run via the Task Scheduler, this is an excellent cmdlet. It does what it needs to - and sends mail. I accept the argument that it may not support the latest and greatest protocols nor is it scalable. But for simple one-off tasks, it works.

If it is to be removed, then there should be a replacement that enables a PowerShell script to send an email.

[vexx32]

Agreed. I think the deprecation notice should be prominently displayed in the help summary and a brief comment about it including a link to the .NET Core deprecation notice for the related API should be included in the full help description and/or related links/notes.

Having it always emit a warning is primarily an annoyance to most folks who're going to be using it regardless, and doesn't add a significant degree of value here.

[doctordns]

If any cmdlet has to issue warning message then it should be actionable. What action can the user take? Just saying this is 'old' is not at all helpful.

What is the alternative to this cmdlet? If an IT pro wants to send a simple email how can they do so?

[user8446]

The replacement is MailKit. If you want this wrapped up in a cmdlet, use Mailozaurr module available in the PS Gallery

[martin9700]

Why would you obsolete the cmdlet? It just seems like an odd approach to the problem. Instead of obsoleting one of the most used cmdlet's in PowerShell I have a weird suggestion: Why not just fix it?

Start a branch, re-write it from the ground up. Wouldn't the fixes mostly be in the background? On the surface at least, seems like you might not even blow up every script that uses it 🤷‍♂️

[user8446]

I agree. Apparently the PS committee hasn't completely decided to not upgrade it, just wants to see it in in a separate module first and will decide later. See: https://github.com/PowerShell/PowerShell/pull/10246

[EchoApeiron]

There is another alternative native to Powershell, but requires using .NET objects. Credit to these writers I used this to store my credentials securely, but this is a better method and I provide a code snippet as well to help:

Powershell: How to encrypt and store credentials securely for use with automation scripts

$userName = "[email protected]"
$password = Get-Content .\encrypted_password.txt | ConvertTo-SecureString
$credentials = New-Object System.Management.Automation.PsCredential($userName, $password)
# SMTP Variables 
$emailFrom = "[email protected]"
$emailTo = "[email protected]"
$subject = "Test"
$body = "Some test message." 
$SMTPServer = "smtp.domain.com"
$SMTPClient = New-Object Net.Mail.SmtpClient($SMTPServer, 587)
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = $credentials
$SMTPClient.Send($emailFrom, $emailTo, $subject, $body)

[MWRobertson]

@EchoApeiron , I had the same thought but just confirmed with someone on the PowerShell team that the Net.Mail.SmtpClient object is what's running behind the scenes of Send-MailMessage, and _that_ is what is actually marked for deprecation, so this workaround will also be obsolete.