In-Depth
Q&A: Protect Users From Phishing Scams
Just because something "appears" to be from a legitimate sender doesn't make it so.
Q:
We've been getting some spam where the "From" address is either blank or has our own addresses in it. I don't have much budget right now; how do you recommend we deal with these?
—Troy, Austin, Texas
A:
Jim: User education is the first front on which you want to fight the spam battle. This includes educating users on scams, phishing, worms, Trojan horses, and keeping their addresses more private. If you cannot start using Exchange 2003 and the Intelligent Message Filter, I recommend using something such as Cloudmark's anti-spam system for Outlook (see Resources for the URL to find a free download).
Ben: As part of the education, your users must realize that unsolicited e-mail is part of life in the Internet age. They must understand that just because something "appears" to be from a legitimate sender does not necessarily mean that it is legitimate.
Q:
Is it OK to delete files in the Badmail folder on my Exchange server?
—Nigel, Charlotte, N.C.
A:
Ben: Yes, that's fine. Exchange MVPs sometimes recommend creating a batch file to delete those files, then creating a scheduled task to run that batch file on a regular basis.
Jim: In fact, Microsoft includes a script called the Badmail Deletion and Archiving tool on the latest version of the Windows 2003 tools (see Resources to learn where to you can download these tools).
Q:
I get Non-Delivery Receipt messages that read, "You do not have permission to send to this recipient. For assistance, contact your system administrator <myserver.mydomain.com #5.7.1>." Well, I'm the system administrator, and I'm stumped. Can you unstump me?
—Wolfgang, Milwaukee
A:
Jim: I'm not sure that "unstump" is a word, but we'll give it our best shot. If you're getting that Non-Delivery Receipt, you're probably also getting some 1709 and 1710 messages in your event viewer. Those errors are telling you that you're having authentication issues in your SMTP.
Ben: One of the more common reasons for this error is that you don't have the server configured to allow computers that authenticate successfully to relay. You'll find that setting in Exchange System Manager under Servers. Find your server under the Servers container, open Protocols, and open SMTP. Right-click on the SMTP Virtual Server and select Properties. Go to the Access tab, click on Relay, and you'll find an interesting checkbox (see Figure 1). Make sure that you have checked the "Allow all computers which successfully authenticate to relay, regardless of the list above." Never check the "All except the list below" checkbox if the SMTP virtual server is exposed to the Internet; this means you're creating an open SMTP relay.
Jim: That's the first thing to check. It might also be that you're running Internet Security and Acceleration (ISA) Server and you've changed your external (public) IP address recently. If you change the external address, you must be sure to update the SMTP publishing rule and restart the ISACTRL service in order to keep everything running smoothly.
Ben: Another possibility is that you're posting from an e-mail address that doesn't match any of your recipient policies. If you go to the Recipients container in Exchange System Manager, you'll find your recipient policies and you can verify that the domain name you're trying to post from is listed there. If not, add it.
Jim: You should also check to make sure that your Mail Exchanger records point at the correct SMTP virtual server. Having your DNS configured properly is obviously extremely important to proper operation of a Windows 2000 or 2003 network. You might not notice immediately if you have DNS problems because Exchange doesn't use DNS to route internal mail, but resolving server names internally and externally in a Windows 2000 or 2003 network depends heavily upon good DNS servers. Bounce messages on messages going out to the world can be one indicator of DNS problems.
Ben: Wherever possible, I like to configure an internal DNS server (or two, if your network is large enough to support it) with forwarders to outside DNS servers. All of your DNS requests go to your internal DNS servers, and that's the cleanest configuration for most small- and medium-sized networks.
Q:
Some of my users are complaining that they cannot see newly created user accounts in the global address list, but others can. The director of human resources is one of these, and he is getting on my case.
—Rie, Atlanta
A:
Jim: Users complaining? I'm shocked! All kidding aside, we will see if we can get your evil director of HR off your case. The first thing that popped into my mind was that the Recipient Update Service (RUS) is not running. RUS is the component of the System Attendant that stamps e-mail addresses to users' accounts and adds them to address lists. However, some of your users apparently see the new users before others, so we can assume the RUS is running properly.
Ben: The next thing that comes to mind is Active Directory replication. The Exchange 2000 and 2003 global address list (GAL) is actually pulled from global catalog domain controllers, not Exchange servers. If updates to new users have not replicated to all domain controllers, your users might see some delays when a new user is mailbox-enabled.
Jim: Finally, you might not be aware that when people use Outlook in offline mode or Outlook 2003 in Cached Exchange Mode, Outlook uses the GAL from the Offline Address Book (OAB). If the OAB has not been updated or the user has not downloaded it, then this might account for the delay.
Ben: The OAB is regenerated once every 24 hours by the System Attendant on the server that is designated to hold the OAB. OABs are created in the Offline Address Lists container under the Recipients container in Exchange System Manager. Exchange 2000 and 2003 only have a single OAB called Default Offline Address List (see Figure 2). Make sure the server name is correct in the offline address list server, and make sure it is regenerated at least once per day.