One of the coolest things about Outlook 2000, was the ease at which we could create rules and manage Out of Office replies. This feature has become even easier still with support not only for Outlook, but for the Outlook Web Access product as well. In fact, most corporate mail platforms allow some level of automated replies for OOF we well as functions that request delivery and read receipts. So the real question is whether your company should allow, support and troubleshoot these functions. While the internal value of these features is clear, the implications of these messages being sent out to Internet hosts are not always understood. Let me give you an example:
Subject: Out of Office AutoReply: Need V1agra? Ch3ck 0ur l0w price$$
I will be out of the office until June 5 and will have limited access to email as I am away on vacation with my family. We are out of the country and not watching the house, but have left the back door open in case you need anything.
For those of you from work, please contact Kendall as she is in charge of everything except for really important things that should be sent to Haley (when she gets back from her trip to Japan.)
Talk to you when I get back!
OK, so what are we saying in this message? Our house is empty and likely our office is as well. I am out of the country with my family and I do not fully trust Kendall with the office functions. We have also disclosed the travel plans of a co-worker. Now I know my example is a little extreme, but you have to admit it is not too far from the truth. A quick Google search on a phone number will return your home 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 if Internet Out of Office and other auto-replies. Here are a couple of references I found while doing a quick search on the subject:
- Out of Office used to target home burglary:
“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.”
- Corporate Risk to Out of Office replies
“According to Chris Poulos, Trend Micro Australia and New Zealand managing director, recent research has shown that criminal organizations use mass emails to search for auto-reply messages generated by key personnel such as senior management and financial staff.
He warns this can result in substantial financial loss, damaged credit ratings and is an invasion of personal privacy, as an auto-reply can open the door to hackers and spammers and provide opportunity for identity theft and telephone fraud.”
- Out of Office replies increases SPAM
” 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 (see “What should not be done about ‘spam’?”, below). This makes it more likely that your address will be sold/swapped by spammers.”
Out of Office replies are not the only automated chink in the armor. Within Exchange and Outlook, there are six types of automated responses that are available:
1) Non-Delivery Reports (NDRs)
2) Delivery Report (Delivery Receipt)
3) Out of Office Responses (Configurable through Outlook)
4) Auto forward Rules (Configurable through Outlook)
5) Auto-reply rules (Configurable through Outlook)
6) Read Receipts (Managed by the Outlook client)
I took an informal poll to other Exchange MVPs and large system operators and was told that most disable all automated replies, especially those that verify a successful delivery. This would include Delivery Reports, Out Of Office replies and any auto-reply rule from Outlook. What I found (by sending test messages to people in large Fortune 500 companies) is that most block nothing. This really surprised me considering the fact that most analysts including Gartner report that unsolicited mail (SPAM) accounts for over 60% of the total messages being delivered over the Internet. Can you imagine the message volume created by large companies just to reply to all the SPAM? The biggest risk could actually be the phisher’s 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 probably don’t want identity thieves knowing all that information as it could help them to learn more about me.
Best Practices for Businesses
So now that we know the problem, what do we do? To begin, we should as a general rule disable any automatic replies that would indicate a success. Let’s start with the server level settings. Using the Exchange System Manager console, we can open and modify the behavior for the Default “*” domains. Within this setting, we can define the default settings.
Using the Exchange System Manager, we can add specific format rules for specific domains. This ability allows us to adjust the auto reply settings different for our business partners.
Is it from this settings screen that we are able to define all of the server reply settings for the organization. This is an important distinction as there is no granular way to apply settings like this for individuals or servers. Instead, we have one set of choices for the entire Exchange organization as a whole.
From a security standpoint, blocking automatic replies, Out of Office replies and Outlook auto forward from being sent out to the Internet is a good starting point.
Out of Office, Auto Replies and Auto Forwards
These three settings are actually controlled by the Outlook client. Exchange 2003 (and Outlook 2003) allows these rules to be fired from the server itself and no longer require the Outlook client to be running. The first thing we want to do is use the ESM to restrict OOF replies from being sent out to the Internet. This is the key point of this article for reasons I have already mentioned. What these settings also do is restrict any Outlook mailbox rules from sending any type of auto reply or auto forward. Auto forwards are dangerous to your organization because of the ease at which corporate intelligence could be sent out to unknown and uncontrolled accounts. Auto-replies likewise provide the same type of risks that Out of Office rules apply in that they can send out corporate intelligence as well as sensitive user information such as message signatures or custom reply text. Another reason for turning these off is mail volume. When you receive an unsolicited message, an auto reply message would be sent back to the sender. Most of the time, the return address is false to an NDR is returned to your sender. In short, one SPAM message becomes three your server has to process and two the client must read which wastes productivity.
Another best practice is to allow non-delivery reports to be sent. While some who are more security-conscious that I (imagine that) may say that this helps SPAMers, I think of NDRs are a basic troubleshooting tool required by both system administrators and users. If a partner fat-fingered your email address, wouldn’t you want that person to know? If you have any question on this subject ask someone in your sales department and they will be able to present better arguments than I ever could. For most companies, the benefit to NDRs outweighs the risks and so NDRs are allows to be sent to Internet hosts.
Technically, delivery reports (delivery receipts) also disclose information that could potentially be used by SPAMers to confirm email addresses. I have yet to see this exploited and it too can be used as 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.
You may have noticed that there is no setting in the ESM to block responses to read receipts. This is another client-controlled setting and one that is difficult to block without buying third-party tools or creating a custom Event Sink in Exchange. What you can do, however is block (or allow) read receipts directly from the Outlook 2003 client itself. From the Tools, Options menu, you can click the E-Mail Options button to access the Tracking Options page. From here you can configure the client to process read receipt request automatically or even to ignore the requests altogether.
Outlook 2003 (and Outlook XP) comes with a tracking options page that allows you to control, how requests and processed including read receipt requests. Don’t be misled by the indication that the read receipt option “Only applies to Internet Mail accounts” as this setting applies for clients connected to an Exchange server as well.
WARNING: If your Outlook 2003 client connects to a POP/IMAP/SMTP server then you could be exposing much more by issuing mailbox rules as the client’s IP address is put into the message header when the reply is generated. For some reason, Microsoft has even published a how-to article that shows you how to “Determine a recipient’s IP address by using read receipts.” Here is the link in case you are interested. http://office.microsoft.com/en-us/assistance/HA011195511033.aspx
Lastly, I mentioned earlier that there is no ESM option for blocking read receipts from Internet delivery. For most companies the inability to easily remove these types of notifications does not pose a serious problem. If your company has identified that read receipts should be blocked, then you are not out of luck as there are third-party tools available as well as some simple scripts you can write to block the request before it ever gets to the Outlook client.
Contrary to popular opinion, Microsoft and Exchange server does conform to the SMTP RFCs for message delivery and format. When a sender requests a read receipt, two header fields are added to the message: Read-Receipt-To and Disposition-Notification-To. Instead of programmatically blocking read receipts from leaving the system, we can write an Event Sink for the SMTP stack that strips these two header fields from incoming messages. The IIS 5 and 6 both support the use of “OnArrival transport events” which is what we would want to use for this. A really good example of such a script can be found at http://www.vamsoft.com/orf/howto-readreceipt.asp. Péter’s example provides the syntax for a VBScript that does just the trick with only a few lines of code:
Const cdoRunNextSink = 0
Sub ISMTPOnArrival_OnArrival(ByVal Msg, EventStatus)
‘ remove read receipt request fields
Set Flds = Msg.Fields
‘ update the mail header
‘ save changes to the mail
‘ continue execution with the next sink
EventStatus = cdoRunNextSink
Simply register the .VBS file you create with this code on all the servers that directly receive the mail from the Internet (any “gateway” server running Windows 2000 or Windows Server 2003 machine running SMTP and you are in business!
Auto-generated responses are an excellent way to trouble-shoot the delivery of mail. It is good practice, however to disable responses that can compromise your business intelligence or provide personal information to others on the Internet. Automatic notifications that have the ability to auto-forward information to outside resources is definitely a no-no. Moreover, Out of Office responses are helpful for internal notifications but can seriously compromise corporate and personal safety when sent to Internet addresses. Use common sense when establishing your acceptable-use policies and ultimately in configuring your Exchange environment.