0

Have a bunch of in-house batch scripts and what-not that utilize sendEmail.exe, which is an old perl auto-emailer application which can be found here:

github for sendEmail.exe

The problem is that with our migration to office365, and our security policies, smtp requires startls. SendEmail does not support startls (or have a startls option)... while there are options for both ssl and tls: yes/auto/no, none of them work.

One option would be to create something new with python and the smtplib library to replace sendEmail.exe, but I'd rather not re-create the wheel here.

Are there any other popular free utilities or programs out there, that I could easily swap out to fill this role?

d34db33f
  • 98
  • 1
  • 8

2 Answers2

1

I would replace this with a more native approach using PowerShell. As Send-MailMessage is now obsolete, that leaves us with System.Net.Mail: MailMessage & SmtpClient. Supposedly your scripts can pass the variables (and you can fill the missing) to:

$mailMessage = New-Object System.Net.Mail.MailMessage($fromAddress, $toAddress, $subject, $body)
$smtpClient = New-Object System.Net.Mail.SmtpClient($smtpServer, $smtpPort) 
$smtpClient.EnableSsl = $true
$smtpClient.Credentials = New-Object System.Net.NetworkCredential($smtpUsername, $smtpPassword)
$smtpClient.Send($mailMessage)
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
1

I've got another solution for you, and it's your old trusted SendMail.exe to be used in conjunction with Stunnel. Stunnel does support STARTTLS, and it runs under Linux/Windows/MacOS/*NIX.

What's Stunnel now about, you might ask? Well, this:

Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code.

So basically it enables your old solution to speak TLS; Stunnel does the encryption part of it and SendMail.exe the rest.

This might be the easiest solution for you; instead of replacing SendMail.exe, you are just adding Stunnel which can be done quite fast.

Marc Stürmer
  • 1,904
  • 13
  • 15