Service pack 2 for Outlook 2003 added two new security features: all mail is displayed in plain text only and hyperlinks are disabled in the Junk email folder, additionally all hyperlinks in messages which are identified as potential phishing attempts are disabled in any folder. While you can change a junk email option and enable hyperlinks globally, HTML rendering in the junk email folder was removed completely and it can't be enabled globally. You either need to move the messages to another folder or click on the Infobar to enable HTML for that message only.

The newest junk mail filter does a very good job and has a low false positive rate so there should be little need to look in the junk mail folder, once you have your Safe lists configured. While viewing junk mail as plain text is less important if you keep the download external content setting on and only download content for individual messages as needed, many users and administrators requested this feature because many users allow all external content.

The reaction to this new security feature surprised me. Many users are upset that they can't turn HTML on in the junk email folder and ask "how dare Microsoft tell me what to do?" and "I can protect myself, I don't need big brother telling me what to do". While Microsoft should have made plain text in the Junk mail folder optional, there should be few false positives in the Junk email folder, and if you can't read the plain text portion, move them to the Inbox. If the message is not junk, mark it Not Junk and add the sender's address or domain to the Safe senders list. If Outlook's junk email filter has a high false positive rate for you, then you need a different anti-spam scanner, one you can train for the types of messages you receive.

To enable hyperlinks on messages in the junk email folder, as well as on messages not classified as junk but which exhibits phishing characteristics, go to Tools, Options, Preferences tab, Junk Email button. Remove the check from 'Don't turn on links in messages than might connect to unsafe sites... ' at the bottom of the dialog. Microsoft recommends you leave this checked, and I agree. It's not about being smart enough to know it's probably a phishing or spam email, it's about accidentally clicking on a link. This feature is added security and it takes just one click in the Infobar to enable hyperlinks on messages that are legitimate.

To learn more about Service Pack 2 and the anti-phishing features, view the

Support WebCast: Overview of Outlook 2003 Service Pack 2
http://support.microsoft.com/?kbid=908366

Outlook 2003's release version included a 'web bug' blocking feature which prevents automatic downloading of external content, usually images, but other content, such as style sheets are also blocked. This feature is good for users in several ways: users can avoid prompts from Windows dialer as they read messages offline, users with slow connections can reduce the bandwidth they use, and everyone can prevent companies or spammers from learning if they viewed their messages.

I purposely choose not to download any external content and enable it per message, as necessary, because I don't want someone to know if, where or from what IP, I read their messages. Unfortunately, too many users do enable external content for all messages because they don't want to be bothered with enabling external content as needed..

An incident from last week illustrates why blocking external content is good for users, bad for newsletters and advertisers and why many people are opposed to 'web bugs'. I received a message which began with the following sentence. "It appears from our records that you are not getting our messages." All I can say is "Oh, really?" I'm most certainly getting their newsletters and I sometimes even read them, when the titles are interesting, but I value my privacy and don't want them to know when I read their messages, so I do what I can to prevent this information from getting back to them, which is to leave external content blocked in Outlook 2003. 

An interesting question about Outlook's autocomplete cache and security came up this week:

"We are experiencing an issue with the autocomplete naming in Outlook 2003. The AutoComplete name displays with the name followed by a UniqueID. The issue is the UniqueID is the user logon name which presents a security issue. After all, we remove the "last logon name" from the logon dialog box for the same security reason. Is there a way to remove the <UniqueID> portion of the AutoComplete name?

While Microsoft allows a way to NOT see a user ID in the logon dialog box, it allows it in the autocomplete section using an .NK2 file? This is a huge security issue so I guess my next question would be is there a way to turn Autocomplete off?"

I'm not sure this problem qualifies as a security issue. What they are seeing in the autocomplete cache is the Exchange mailbox alias, which just happens to be the user logon account at their site. Many sites use the account name as the default SMTP alias, but even if you create a different default SMTP alias, it's visible in the GAL, and anyone with access to the GAL can open the contact record and view it. It can be removed from the GAL, but then users can't log on to OWA using an email address.

When you send a message internally, the display name and exchange alias are stored in the autocomplete cache. This is normal - on my server it's "Diane Poremsky <dianep>". In their case, it looks like Bill Smith <123456>, displaying the same logon id they don't want stored in the logon screen for security reasons. Had they configured the account differently, it could show "Bill Smith <bsmith>" in autocomplete and the user account name would not be seen, even in the GAL.

When many sites create a user account in the AD, they enter the user account logon name and OK their way thru the screens, accepting the defaults for the exchange alias, which by default, just happens to be the same as the user account logon.

If you want to keep the logon separate from the exchange alias, you should create the user account in the AD and enter the user logon name as usual, but once you get to the Create Exchange mailbox screen, enter a different name for the Exchange alias. When the user logs on to Windows using his user account, he'll be logged into the mailbox as usual, even though the user account and mailbox name are different, unless Outlook was configured to require the username and password when accessing the mailbox.

If this is a problem for your company and changing the Exchange mailbox name is not a workable solution, you can disable autocomplete in Tools, Options, Preferences, Email options button, Advanced Email options. Remove the checkmark from Suggest names while completing TO, CC, and BCC fields near the bottom of the dialog.