| Downloads |
|---|
| 46947.zip |
Most companies allow some types of automated replies (e.g., out-of-office replies) as well as functions that request delivery and read receipts. Should your company allow, support, and troubleshoot these replies and functions? Although the internal value of these features is clear, the implications of the messages being sent to Internet hosts aren't always understood. Take, for example, the out-of-office reply that Figure 1 shows. This message is telling everyone that my house and my office are empty. This message is also telling everyone that I don't fully trust Kendall with all the office operations. I have even disclosed the travel plans of a coworker. Now I know this example is a little extreme, but you have to admit it isn't too far from the truth. A quick Google search on a phone number can return an address and with one more click, you can get directions to almost anyone's home or office. Pretty scary, huh?
When I first began researching this problem, I found that security experts have been warning people for years about the risk of Internet out-of-office replies and other types of automated responses. Here are some interesting articles I found while researching the subject:
- The online riskVue newsletter (http://www.riskvue.com/subscribe/wt0407.htm) reports that out-of-office replies can be used to target homes for burglary. It states, "In December 2002, a British hi-tech group released a warning that thieves could use e-mail lists to send mass-mailings in order to retrieve vacation auto-replies. The auto-replies could be cross-referenced with publicly available personal information, and used to target the home of a vacationer. At the time of the warning, an FBI public affairs officer told ABC News that it 'has some indication that there might be some of this activity.'"
- New Zealand Reseller News (http://www.reseller.co.nz/reseller/reseller.nsf/0/fcb529c1ed25bdd0cc256f6900026fe4?opendocument) reports that out-of-office replies can lead to corporate financial loss. In "Announcing your absence sends invite to crims," Louis van Wyk states, "According to Chris Poulos, Trend Micro Australia and New Zealand managing director, recent research has shown that criminal organisations use mass emails to search for auto-reply messages generated by key personnel such as senior management and financial staff.... Research has shown tapping into auto-reply messages is one of the easiest ways for spammers to collect sensitive information including company names, addresses, titles and phone numbers, says Poulos. With this information, identity theft becomes simple. This can put corporate finances at risk, as criminals can pretend to be from a company and contact customers offering assistance while their usual contact is away."
- On the Penn Computing Web site (http://www.upenn.edu/computing/security/advisories/spam.html), the University of Pennsylvania's Information Systems and Computing department reports that out-of-office replies increase spam. It notes, "If you use 'vacation/out of office' replies on your e-mail account when you're away, you automatically generate a reply to each incoming spam message that confirms that your address is valid, and that someone is reading it.... This makes it more likely that your address will be sold/swapped by spammers."
Out-of-office replies aren't the only automated chink in the armor. Within Exchange Server and Outlook, there are six types of automated responses available. The server-based automated responses are nondelivery reports (NDRs) and delivery reports (aka delivery receipts). The client-based automated responses are out-of-office replies, automatic replies based on autoreply rules, automatic forwarding based on autoforward rules, and read receipts.
I took an informal poll of Exchange Most Valuable Professionals (MVPs) and administrators of large Exchange systems to find out whether they disable any of the six types of automated responses. Most of the MVPs and administrators disable the automated responses that verify a successful delivery. This would include delivery reports, out-of-office replies, and automatic replies.
In another fact-finding mission, I sent test messages to people in large Fortune 500 companies to see whether the companies blocked any mail messages. My message was a generic "How are you" to common names such as jsmith@ and postmaster@. What I found was that most companies allow delivery reports, NDRs, and read receipts. I also received several out-of-office replies. The test-message results really surprised me considering that most analysts, including Gartner, report that spam accounts for more than 60 percent of the total messages being delivered over the Internet. Can you imagine the message volume created by these large companies for every automatic reply, delivery report, read receipt, and out-of-office reply? The biggest risk might actually be from the phishers who are writing code to extract personal information from messages whose subject lines read Out of Office or OOF. My signature includes my full name, company name, and phone numbers. I don't want identity thieves knowing all that information because it could help them learn more about me.
Out-of-Office Replies, Automatic Replies, and Automatic Forwarding
So now that you know the problem, what should you do? From a security standpoint, blocking out-of-office replies, automatic replies, and automatic forwarding to the Internet is a good starting point. Let's start with the server-level settings. You can modify the behavior of the default domains through Exchange System Manager (ESM). In the top-level node of your Exchange organization, navigate to Global Settings, Internet Message Formats. In the right pane, double-click Default * to bring up the Default Properties dialog box that Figure 2 shows. This dialog box lets you define all the server reply settings for the Exchange organization as a whole. In ESM, there's no granular way to apply settings like this for individual users or servers.
Although the Outlook client controls out-of-office replies, automatic replies, and automatic forwarding, Exchange Server 2003 (and Microsoft Office Outlook 2003) allow these rules to be fired from the server and no longer require the Outlook client to be running. (Although this functionality was introduced in earlier Exchange versions, Exchange 2003 with Outlook 2003 provides greater server-rule support.) Thus, you can use ESM settings to stop any Outlook client's mailbox rule from sending any type of out-of-office reply, automatic reply, or automatic forwarding. Automatic forwarding is dangerous to your organization because of the ease with which corporate intelligence can be sent out to unknown and uncontrolled accounts. Similarly, out-of-office replies and automatic replies can reveal corporate intelligence as well as sensitive user information.
Another reason for not allowing out-of-office replies, automatic replies, and automatic forwarding is mail volume. When you receive an unsolicited message, an automatic reply message is sent back to the sender. Most of the time, the return address is false, so an NDR is returned to your sender. In short, one spam message becomes three messages that your server must process and two messages that the client must read, which hurts productivity.
Read Receipts
Read receipts are useful in that a sender can request one and can use the automated response to verify that the recipient has received and opened the message in question. However, I personally don't like to use read receipts, nor do I permit my Outlook client to respond to them. For me, I prefer email to remain asynchronous because I often work at home and sometimes I open messages and wait for hours or even a day to respond while I gather my thoughts. Plus, read receipts add to a company's mail volume. For these or other reasons, you, too, might want to disable read receipts.
In Figure 2, you might have noticed that ESM has no check box to allow read-receipt responses. This client-controlled setting is difficult to block from the Exchange server without buying third-party tools or writing a script. What you can do, however, is block read receipts from the Outlook 2003 or Outlook XP client. From the Tools, Options menu, select E-Mail Options to access the Tracking Options dialog box, which Figure 3 shows. In this dialog box, you can configure the client to process read-receipt requests automatically or even to ignore the requests altogether. Before configuring the Tracking Options dialog box, though, you need to be aware of two caveats:
- Don't be misled by the statement Only applies to Internet Mail accounts that appears near the bottom of the Tracking Options dialog box. The setting you select will also apply to clients connected to the Exchange server.
- If your Outlook 2003 client connects to a POP, IMAP, or SMTP server, the client's IP address is put into the message header when the reply is generated. In general, exposing your IP address is a bad idea considering the ease with which hacking tools can be acquired and used. It's much easier to break into a system if you know the OS and the IP address of the machine you want to target. However, network administrators sometimes use read receipts if they want to track the computer used to open mail messages. The Microsoft article "Determine a recipient's IP address by using read receipts" (http://office.microsoft.com/en-us/assistance/ha011195511033.aspx) discusses how to use read receipts for that purpose.
As I mentioned previously, there's no ESM option for blocking read receipts from Internet delivery. For most companies, the inability to easily remove these types of notifications from the Exchange server doesn't pose a serious problem. But if your company needs to block receipts, you're not out of luck. There are third-party spam and content filters available as well as some simple scripts you can use to block the request before it ever gets to the Outlook client.
Contrary to popular opinion, Exchange conforms to the SMTP Requests for Comments (RFCs) for message delivery and format. Thus, when a sender requests a read receipt, two header fields are added to the message: Read-Receipt-To and Disposition-Notification-To. Instead of blocking read receipts from leaving the system, you can write an event sink that strips these two header fields from incoming messages. Peter Karsai's ReadReceiptRequestRemoval.vbs is a good example of this type of script and, as Listing 1 shows, does the trick with relatively few lines of code.
To use ReadReceiptRequestRemoval.vbs, you need to download the readreceiptremoval.zip file at http://www.vamsoft.com/orf/howto-readreceipt.asp. (This .zip file also includes a JScript version of the script.) Then register ReadReceiptRequestRemoval.vbs on all the servers that directly receive mail from the Internet—that is, any Microsoft IIS 6.0 or IIS 5.0 gateway server running Windows Server 2003 or Windows 2000 Server, the SMTP Service, and Windows Script Host (WSH) 5.6. The commands to register and launch the script are in the readme file in readreceiptremoval.zip. As with any script or executable, test this script first before modifying your production server. Note that there will be a slight performance drop on SMTP delivery because you're adding an additional process. Fortunately, Exchange routes and processes mail very efficiently, so unless your SMTP server is already taxed, you probably won't notice a difference.
NDRs and Delivery Reports
Although some people who are very security conscious think allowing NDRs to be sent to Internet hosts is a bad idea because it helps spammers confirm email addresses, I believe NDRs are a basic troubleshooting tool that both system administrators and users need. If a partner fat-fingers your email address, wouldn't you want to know? If you have any reservations about allowing NDRs, ask the members of your sales department—they'll be able to present better arguments than I ever could. For most companies, the benefits from allowing NDRs outweigh the risks. So, I recommend that you allow NDRs to be sent to Internet hosts.
Like NDRs, delivery reports disclose information that spammers might potentially use to confirm email addresses. However, I've yet to see delivery reports be exploited. Delivery reports can be a valuable tool that vendors and partners can use to verify message delivery. Most companies (even financial institutions and government facilities) I work with have left this setting on, and most experts agree that the ability to provide delivery reports is mostly benign.
Use Common Sense
NDRs and delivery reports are an excellent way to troubleshoot the delivery of mail. However, you need to disable the other types of automated responses that can put your business at risk. Out-of-office replies are helpful for internal notifications but can seriously compromise corporate and personal safety when sent to Internet addresses. Similarly, automatic replies can compromise corporate intelligence and provide personal information to people on the Internet. Even read receipts can expose a client's IP address in some situations as well as increase mail volume. And allowing automatic forwarding outside resources is definitely a no-no. If you use common sense when establishing your acceptable-use policies and configuring your Exchange environment, your business will be in a much safer state.
