Wednesday, November 24, 2010

Sending SSL Emails using Powershell

We had recently experienced problems with our backup emails getting spammed or just having general difficulty getting out through the disparate array of local SMTP servers across our clientbase, and the security issued raised by allowing specific machines relay rights.

Also, our previous method of using blat meant our scripts were reliant on the existence of a 3rd party executable. Our way around this was to use SSL SMTP back to our own email server, and luckily, through the .NET Framework, Powershell can do this natively. Here's an example of an email function similar to one I use (it is very basic and doesn't really check what it is passed so be careful):

Function EmailSimple
{
Param($esRecipients, $esSubject, $esBody, $esFrom, $esAttachments, $esSmtpUser, $esSmtpPassword, $esSmtpServer)

#Create the credentials for the smtpauth connection
$credentials = New-Object System.Net.NetworkCredential($esSmtpUser, $esSmtpPassword);
#Create the message
$message = New-Object System.Net.Mail.MailMessage $esFrom, $esRecipients, $esSubject, $esBody
#Add attachment to $message if one exists
if ($esAttachments)
{
foreach ($esAttachment in $esAttachments)
{
$attachment = new-object System.Net.Mail.Attachment $esAttachment
$message.Attachments.Add($attachment)
}
}
# Set up server connection
$smtpClient = New-Object System.Net.Mail.SmtpClient $esSmtpServer, 587
$smtpClient.EnableSsl = $true
$smtpClient.Timeout = 100000
$smtpClient.UseDefaultCredentials = $false;
$smtpClient.Credentials = $credentials
#Send the message
$smtpClient.Send($message)
Write-Host "Message sent."
}
}

One of the most important things is the line

$credentials = New-Object System.Net.NetworkCredential($esSmtpUser, $esSmtpPassword);

This is where you create a credential that you can set in your System.Net.Mail.SmtpClient object that will allow you to connect to authenticate with an SSL server. I suggest keeping your script or configuration file in a location that is locked down to administrators so that you can minimise exposure of the username/password of the account you're using to send email with.

I found that our email server wasn't liking getting a lot of smtp connections at exactly the same time, so I added a random pause of up to 2 minutes just before doing a send to try an distribute the load:

#Add random sleep to stop smtp server overload
$randNum = New-Object System.Random
Start-Sleep -Seconds $randNum.next(0,120)

Powershell has some excellent capabilities, I'll post some more on scripting soon.

Symantec Premium Antispam Optimisation

Settings for Symantec Premium Antispam are fairly customisable, and should be tweaked according to client wishes. That said, there is a default level you should start tweaking from, and that is not how Symantec is configured out of the box.

Any changes should be discussed with clients beforehand, so staff can be on the lookout for false positives.

Key Concepts

There are some key concepts:

  • SCL values - Exchange scans messages received and those that are determined to be spam are assigned a SCL value of 1 (extremely low likelihood that the message is spam) to 9 (extremely high likelihood that the message is spam).
  • Store Action Threshold - The Store Action Threshold (SAT) in Microsoft Exchange 2003 works with the SCL value that is stamped on an email message to determine the destination of the message. When the SAT value is not set, Exchange sends all messages with a SCL value to the user's Junk E-mail folder. If the SAT value is set and a message has a SCL value that is higher than the SAT threshold, Exchange sends the message to the user's Junk E-mail folder. If the SCL value is lower than or equal to the SAT value, the message goes into the user's Inbox.
  • Symantec Spam Rating - Symantec calculates a spam score from 1 to 100 for each message. If a message scores from 90 to 100, it is defined as spam. You can define a suspected spam threshold between 25 and 89 (default is 72) in the Spam Scoring section of Premium AntiSpam Settings.
You are best off setting the Store Action Threshold to something like 7, and then reassignning an SCL rating of 8 or higher to messages that are classified as Suspected Spam using the Symantec Spam Rating, otherwise it's hard to tell which program is catching a message.

The SAT can be set via the \Program Files\Symantec\SMSMSE\6.0\Server\SMSMSESAT.exe executable. Just run SMSMSESAT.exe from a command prompt with no arguments to see the current threshhold:

C:\Program Files\Symantec\SMSMSE\6.0\Server>SMSMSESAT.exe
SMSMSESAT.exe -- Symantec Mail Security for Microsoft Exchange Store Action Thre
shold Utility

Usage:
SMSMSESAT [sat] [/H hostname]
Gets and sets Store Action Threshold.
sat Store Action Threshold value to be set.
/H hostname Domain name, host name or IP address to connect.

Current value of Store Action Threshold = 7

You can set it via SMSMSESAT.exe [sat], where [sat] is the threshold value (eg 7).

Handling Spam

There are three main sections for handling spam under the Symantec Premium AntiSpam Actions configuration page:

Spam Messages
  • These are the messages that have been given a Symantec Spam Rating of between 90 - 100. These messages will almost always be spam, I would recommend rejecting these, but turning on logging so that we can check if a client reports a rejection.
Suspected Spam and SCL
  • This allows you to deal with messages that are Suspected Spam using the Symantec Spam Rating (default is 72), and also have a SCL rating above a certain level. At this stage I think a good default setting is to reject messages that are Suspected Spam using the Symantec Spam Rating, and have an SCL rating of >6, and logging the action. Microsoft recommend rejecting messages with an SCL rating of 7 or above (http://technet.microsoft.com/en-us/library/bb738130.aspx).
  • If this turns out to be rejecting too many legitimate messages, you could either turn down the SCL rating level to >7 or >8, or alternatively accept the message but tick the "Assign SCL value to message" option and set it above the Store Action Threshold (this guide recommends 8). This will ensure that the message is delivered to the user's Junk Email folder, rather than their Inbox.
Suspected Spam
  • This allows you to deal with messages that are Suspected Spam using the Symantec Spam Rating (default is 72), but don't have an SCL rating, or have an SCL rating lower than the threshold set in the ** Suspected Spam and SCL ** section.
  • I would recommend accepting this message, but ticking the "Assign SCL value to message" option and set it above the Store Action Threshold (this guide recommends 8). This will ensure that the message is delivered to the user's Junk Email folder, rather than their Inbox.
Whitelisting

If there are domains/senders that the client usually receives legitimate mail from, you can whitelist domains or individual addresses so that no antispam action is taken against messages received from those domains/senders.

Conclusion

Again, all clients will be different, but I think this allows a good starting point to tweak from. Most spam will either be rejected or send directly to Junk Email. If there are reports of rejections or incorrectly classified mail, the actions can be tweaked, or the sender/domain being rejected/marked as spam can be whitelisted.

Deploying Firefox in an Enterprise Setting

Who would have thought that getting Firefox up and running in a manage environment would be so easy?

Previously I've encountered all sorts of problems getting Firefox up in an enterprise setting. Typically the situation arises because of a new or existing application that will only work or works better in a browser other than IE (which has terrible javascript performance in IE8 and below). Since IE9 wont be available for Windows versions prior to Vista/Server 2008, the only real alternative at the moment is Firefox.

Mozilla doesn't distribute msi's for Firefox if you need to deply en masse using group policy, but you can roll your own fairly easily - 404 Tech Support has an excellent article:


I would suggest ignoring the suggested default settings modifications by adding files - there is a better way! There's an open source project called FirefoxADM which allows you to set all the preferences you need through group policy using ADM templates. You can download the latest version from here:


And there's some great instructions here:

http://homepages.ed.ac.uk/mcs/FirefoxADM/ADM_Deploy.pdf

The most important thing to note is that you need to get the scripts running for the GPO settings you specify to apply. Simply copy the relevant scripts to your GPO's scripts location, and add the relevant one to your GPO settings and you're good to go. You can even tell Firefox to use IE's settings if you like!

I'm happy to do a more detailed post if people want one.