It's been a few years since I wrote about Outlook and email
viruses. Frankly, I thought the issue was dead, thanks to the
security built into the last three released versions. Eight
years have passed since Outlook could be used to automatically
send virus infected messages or was less safe than any other
email client. The newer versions of Outlook are safe and no one
really asks about Outlook and virus safety anymore. Then a
forwarded message landed in my Inbox.
It began like this: "What action triggers a virus or its
relatives to do their worst? I'm trying to understand what to
avoid doing when I receive an e-mail. My client is Outlook, and
I have no plans to switch. I have learned how to program it with
VBA to do some neat things. Is even accessing an e-mail and its
parts in VBA dangerous, too? Is the problem with the e-mail, its
attachments, or both? Is the e-mail safe? Is ALL the danger in
the attachments? Am I safe if leave them alone? What? Advice!
Help!"
The user was not satisfied with the answer he received and
forwarded it to me. "Email viruses can be contained in the email
itself in the form of a form; script; attachments; windows
office attachments and url links. All can be triggered just by
opening the email. That's where people who set the preview
option get into trouble because preview auto opens the email.
Suggest a good email virus checker that supports outlook;
Norton, McAfee.. etc. Also a good isp with a robust email system
will help.. Hope it helps.."
Well. No. It does not help. In fact, it's wrong for anyone using
Outlook 2000 or later that has all the Office and Windows
updates installed. Since Outlook 2000 post-SP1, nothing can be
triggered just by opening an email. We called the Outlook 2000
post-SP1 security patch the "Hell patch" because it was a
draconian measure for users but it had the desired effect: it
put an end to Outlook email viruses as we knew them. Yeah,
viruses are still sent by email, but they require user
interaction to trigger, more than just opening a message or
double clicking an attachment.
Potentially dangerous attachment types are blocked - users can't
open or save many file types unless they take specific steps to
unblock them, and even then, the attachment must be saved to the
hard drive before they can be opened. Scripts won't run, not in
an opened message, not in the preview (reading) pane and
certainly not with autopreview (3-line preview).
The reading pane is quite safe. It does not run active content
and hasn't for several versions. Using the reading pane is
actually slightly safer than opening a message.
Should you use a client side email virus checker? No. The
limited increase in safety isn't high enough to outweigh the
problems they cause - from crashing Outlook to disappearing
email bodies to interfering with send and receives. For all but
the few users who really can't be trusted to use common sense
when receiving questionable attachments, scanning incoming email
not worth it - you know it's a virus and will hit Del anyway.
Outlook writes all attachments to the SecureTemp folder before
opening them, so as long as the anti-virus program is up-to-date
and running in autoprotect mode, it will give you the same level
of protection and let you know if you try to open an infected
attachment.
While security is not as draconian as it was back in 2001, it's
still strong and is getting better. Much to the dismay of many
users, Office Saved Searches, shortcuts to folders and other
features were removed in the name of security, while Microsoft
has made it easier to use COM Add-ins in Outlook 2007.
The information in the Feb 2004 Security issue is as true today
as it was four years ago.
http://www.slipstick.com/emo/2004/up040204.htm
PREVIEW PANE SAFETY - ONE MORE TIME (EMO, Jan 2005)
http://www.slipstick.com/emo/2005/up050120.htm#preview
A reader asks: "Is there any way I can set up a warning (or
possibly limit) on the size of file I can email? I'm guilty of
accidentally sending 13mb files."
Sure, you can use VBA to warn you.
A very basic warning uses this simple code:
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As
Boolean)
If Item.Attachments.Count > 0 Then
ans = MsgBox("Is the attachment too big?", vbYesNo)
If ans = vbYes Then Cancel = True
End If
End Sub
This simple procedure checks for the presence of attachments and
asks if the attachments are too large. While this is fine if you
don't send a lot of attachments, it would be even better if you
were alerted only when the message size was too large.
Outlook MVP Michael Bauer offers this procedure that checks for
the presence of attachments and if any are found, it checks the
message size. When the message exceeds the Max_item_size you
configured, a warning dialog pops up.
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As
Boolean)
If TypeOf Item Is Outlook.MailItem Then
Cancel = Not (ConfirmBigAttachments(Item))
End If
End Sub
Private Function ConfirmBigAttachments(oMail As Outlook.MailItem)
As Boolean
' by Michael Bauer http://www.vboffice.net
Dim lSize As Long
Const MAX_ITEM_SIZE As Long = 1048576 ' in Bytes. This is 1 MB
Dim bSend As Boolean
bSend = True
If oMail.Attachments.Count Then
lSize = oMail.Size
If lSize > MAX_ITEM_SIZE Then
bSend = (MsgBox("Item's size: " & lSize & " Byte. Cancel?",
vbYesNo) = vbNo)
End If
End If
ConfirmBigAttachments = bSend
End Function
To use either of these code samples with Outlook, open the VBA
editor (Alt+F11) then copy and paste the code into
ThisOutlookSession. The max_item_size is set for 1 megabyte but
can be changed to any number. Save it and every time you send a
message, the ItemSend procedure will run.
If you need help converting megabytes to bytes, go to google and
type "x megabyte in bytes" into the search field, where x is the
number you need to convert.
Michael Bauer's E-Mail: Check item size before sending
http://www.vboffice.net/sample.html?mnu=2&smp=5&cmd=showitem&lang=en
You can force Exchange 2007 to use a specific Global Catalog
server using PowerShell cmdlets. Use the -StaticConfigDomainController
-StaticDomainController -StaticGlobalCatalog string of the Set-ExchangeServer
cmdlet to set it or set exclusions using: -StaticExcludedDomainControllers
Beginning this issue, EMO is going to be published weekly.
This will allow us to provide a slightly shorter newsletter -
with fewer new and updated utilities and KB articles in each
issue and more "breaking news" when updates or new versions are
released.
We're also going to a new HTML layout, in part because
publishing in HTML just makes sense in this day and age. Many of
the issues over the last 6 months were HTML and not
surprisingly, no one complained. HTML formatting gives us more
formatting options, making it easier for you to read. We'll
continue to publish the entire article in the newsletter except
in the rare cases where the article is really long.
One policy that is not changing: we never sell our mailing list
nor do we spam our subscribers with "special advertising
editions" that are all ads.
RSS
