This note follows on from the previous one and outlines some of the issues and solutions to using Powershell to send automated emails via GMail.
First of all, this simple script will send an email via GMail, assuming you have already set GMail up for 'app access'.
#
$secpasswd = ConvertTo-SecureString "plain-txt-gmail-pswd" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ("[email protected]", $secpasswd)
#
Send-MailMessage -SmtpServer 'smtp.gmail.com' -Port '587' -Credential $cred -UseSsl -From '[email protected]' -To '[email protected]' -Subject 'TEST to [email protected]'
Note that GMail only allows encrypted connections, hence the use of the 'UseSsl' flag. Also note that whilst it says 'SSL' it also supports TLS which is what GMail uses.
This ps1 file can then be called via a command script like this:
powershell -ExecutionPolicy ByPass -File "C:ScriptsPowershellGMailworking-test-via-gmail.ps1"
and this in turn can be scheduled using task manager. Works fine... but...but..
- The Powershell Send-MailMessage command is no longer supported by MS and they do not promise an alternative version. So whilst it works today, the next version of PS might break it.
- Google might fully block this method of using GMail.
- Finally, the script is terribly insecure, as the GMail App password is in plain text. So anyone with access to the machine it's running on could find it. [Bear in mind this password can't be used for human interactive logons to GMail, only Apps can use it.]
The only one of these three we can do anything about is the last one - security.
Powershell offers some help here -by way of the 'SecureString' function. So the script shown above could be modified to use an encrypted version of the GMail paassord, which could be created like this:
"plain-txt-gmail-pswd" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:ScriptsPowershellGMailEmailPassword.txt"
This will then produce an encrypted string that can be used without leaving the plain text password visible to prying eyes. But...
First, the encryption can be cracked without too much difficulty, but we can live with that.
Second, and more seriously, by default 'ConvertTo-SecureString' uses the SID of the logged on users PC. So whilst this encryption will work on the PC is was written on, it won't work on any other PC.
However, it is possible to create a user defined AES key and use this, rather than the SID. There is still the issue of needing to leave the key available to the script, but at least security has been increased.
Links for more information
https://adamtheautomator.com/send-mailmessage/
https://www.pdq.com/blog/secure-password-with-powershell-encrypting-credentials-part-1/