While you were out: Scheduling meetings and OOFs

Although it's been an accepted (and expected) practice to setup OOF auto-responses while you are out of office, I haven't been a big fan of OOFs in the past. My reasons:

1. I often forget to turn off OOFs once I'm back in the office, or forget to set these up in the first place— setting up OOFs isn't exactly a priority for many when leaving for a business trip or a vacation.
2. At times I don't want to provide the same information to external senders that I provide to internal ones.
3. I don't want to broadcast to the whole world about being out of office.
4. I hate to respond to spammers (or phishers and identity thieves) and confirm my email address with a nice little OOF response that may also have more personal details about me, including contact information.

Exchange Server 2007 and Outlook 2007/OWA have help for folks like me.

Schedule OOFs: You can beat the last minute OOF blues by scheduling OOF start and stop times using the Out Of Office Assistant in Outlook 2007 [Tools -> Out of Office Assistant] or OWA [Options -> Out of Office Assistant].
Different internal and external OOF responses: You can also setup different OOF messages for internal and external recipients.
Restrict external OOFs: You can restrict OOFs to internal senders or your Contacts only.


Figure 1: The Out of Office Assistant allows you to schedule OOFs, create different OOF messages for internal and external senders, and restrict external OOFs to your Contacts

However, OOF auto-responses are sent out exactly once per sender - the very first time the sender sends you a message.

When planning to be out of office, it's a great idea to setup a Calendar appointment for yourself and mark the status as out of office instead of busy.


Figure 2: When planning to be out of office, create an appointment on your Calendar and set the status to out of office

When another user tries to schedule a meeting with you during the period you're out of office, your Free/Busy information does not show your OOF status. Setting up the OOF appointment in your Calendar allows meeting organizers to instantly identify whether you're just busy or actually out of the office during the period.


Figure 3: Meeting organizers can instantly determine your out of office status

Related posts:
- The hilarious lingo of Exchange folks
- Why is OOF an OOF and not an OOO?
- Legacy client and Out of Office (OOF) interoperability
- OOF integration with Exchange Server 2007 Unified Messaging (UM)

Removing internal host names and IP addresses from message headers

Another frequently asked question about SMTP mail - how can I remove internal host names and IP addresses from outbound internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization's internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it's a part of a checklist written by a security expert at some law firm somewhere, and given the viral nature of checklists it's all over the place!

Let's take a look at what we're talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).

Here are headers from a message received from Dell. (Unnecessary headers removed).

Received: from smtp.easydns.com (205.210.42.52) by exchange.somedomain.com
(192.168.2.171) with Microsoft SMTP Server id 8.1.240.5; Mon, 19 May 2008
03:12:46 -0700
Received: from mh.dell.m0.net (mh.dell.m0.net [209.11.164.66]) by
smtp.easydns.com (Postfix) with ESMTP id 647C222914 for ;
Mon, 19 May 2008 06:14:46 -0400 (EDT)
Received: from [192.168.138.130] ([192.168.138.130:57330]
helo=fc13a1.dc1.prod) by oms1.dc1.prod (ecelerity 2.1.1.24 r(19486)) with
ESMTP id 3B/AF-18306-11351384 for ; Mon, 19 May 2008
03:14:41 -0700
Message-ID: <[email protected]>
Date: Mon, 19 May 2008 03:14:41 -0700
From: Dell Small Business
Reply-To:
To:
Subject: $429 desktop, plus new laptops. Hurry and shop now.
Errors-To: [email protected]
Return-Path: [email protected]

These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.

What the standards say
Let's take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):

4.4 Trace Information

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4.

This line MUST be structured as follows:

- The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

and prohibits removing received headers (repeatedly). One example:

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.

More secure?
Should you remove these headers, and "hide" internal hosts and IP addresses? Is it really a security risk?

There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.

Steve Riley, Senior Security Strategist at Microsoft, says:

In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.

Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.

In many ways, the issues faced are similar to changing fqdn on SMTP Virtual Server/Receive Connector. Even if you make these changes, at least one internal hostname is likely to be revealed by the Message-ID (read "Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain").

Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don't want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor's checklist).

How to remove Received headers in Exchange Server 2007
Exchange Server 2007 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon— a well-known security principal that refers to anonymous users, as shown below:

Get-SendConnector "Connector Name" | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

What's your take?
Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.

Released: Update Rollup 2 for Exchange Server 2007 SP1

Exchange Server 2007 SP1 Update Rollup 2 has been released.

Description of the roll-up can be found in KB 948016. Besides all the fixes from Update Rollup 1 (for SP1), this rollup includes fixes for the following issues:

• - 940462 The public folder store may take several minutes to mount on an Exchange 2007 server
• - 944153 Exchange Server 2007 does not have Transport Neutral Encapsulation Format (TNEF) capabilities for POP and IMAP protocols
• - 945917 You receive an error message when you try to access the Outlook Web Access global address list in an Exchange Server 2007 environment
• - 947346 Exchange Server 2007 mailbox users cannot retrieve the free/busy information for Exchange Server 2003 mailbox users in a large Exchange Server organization that has more than 100 administrative groups
• - 947360 Error message occurs, and users cannot access the free/busy information after you use the Import-Mailbox cmdlet to import data to a mailbox in Exchange Server 2007 Service Pack 1
• - 947391 The contents of .pst files are not imported into Exchange Server 2007 mailboxes when you use the Import-Mailbox cmdlet
• - 947451 A recipient sees unexpected text in the top of an e-mail message that you send in Exchange Server 2007
• - 947458 The Edgetransport.exe process may crash on an Edge server that is running Exchange Server 2007 Service Pack 1
• - 947551 The Edgetransport.exe process may crash intermittently on an Exchange Server 2007 Service Pack 1 Edge server
• - 947577 If you try to connect a mobile device to a mailbox server through a server that is running Exchange Server 2007, the mobile device may be unable to connect
• - 947646 Event ID 12011 is logged every time that the MSExchangeTransport service starts after you install Exchange Server 2007 Service Pack 1 on a computer that is running the German version of Windows Server 2003
• - 948047 An event ID 1080 message is logged in the System log every three seconds after you run the Set-ExchangeServer command to set the static domain controllers on an Exchange 2007 cluster node
• - 948297 The OOF template may be delivered as an attachment in an Exchange 2007 environment when you use the "Reply with Template" option in Microsoft Outlook
• - 948332 Failover takes a long time to finish in an Exchange Server 2007 cluster continuous replication environment
• - 948374 The EdgeTransport.exe process crashes intermittently, and event ID 1033 is logged in Exchange Server 2007
• - 948666 When you try to migrate a mailbox from Exchange Server 2003 to Exchange Server 2007, the Exchange Management Shell may stop responding
• - 948830 The MSExchangeSyncAppPool application pool crashes on a server that hosts an Exchange Server 2007 Client Access Server role
• - 948831 A user may be unable to synchronize with an Exchange Server mailbox from a mobile device when a Client Access server has been upgraded to Exchange Server 2007 Service Pack 1
• - 948844 An exception occurs, and event IDs 4999 and 5000 are logged when you modify the Outlook Web Access user interface
• - 949186 When you try to run the Restore-mailbox cmdlet on a server that is running Exchange Server 2007, you receive an error message
• - 949193 The address rewrite agent does not rewrite the address for Out of Office (OOF) messages in Exchange Server 2007
• - 949463 An exception error is generated after you run a Set-AttachmentfilterListConfig command together with the ExceptionConnectors option on an Exchange 2007 SP1-based server
• - 949541 You cannot log on to Outlook Web Access Light, and an error message occurs in Exchange Server 2007
• - 949703 Error message in Outlook when you click the signature icon of a signed e-mail message that an Exchange Server 2007-based Edge server receives: "The digital signature is invalid"
• - 949726 After you install Exchange Server 2007 Service Pack 1, the Set-ExcecutionPolicy task causes an error message, and event ID 103 is logged
• - 949772 If you run the "isinteg -dump" command against a dismounted store on a server that is running Exchange Server 2007, the Store.exe process stops unexpectedly
• - 950123 Error message after you apply Update Rollup 1 for Exchange Server 2007 Service Pack 1 in a Japanese environment: "Public Folder Management Console is not an allowed Snap-in"

HOW TO: Remove the Public Folder Store

This is a fairly common question - you're trying to remove the Public Folder store on an Exchange 2007 server and get an error that some Public Folder replicas still exist. You're certain you've removed all Public Folder replicas from that server. What next?

Here's a little procedure documented in How to Delete Multiple Public Folders from Your Organization that takes care of this.

Note: This procedure should be performed only if you're removing the last (or only) Public Folder Store from an Exchange Organization. If there are other servers in the Organization that also host Public Folders, using this procedure removes the folders from the Public Folder hierarchy.

Remove all Public Folder replicas from the server using the following command:

Get-PublicFolder -Server "SERVER NAME" "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

Next, remove all System Folders using the following command:

Get-PublicFolder -Server "SERVER NAME" "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

To verify all Public Folders have been deleted:

Get-PublicFolderStatistics -Server "SERVER NAME" | fl

At times the replica clean-up may take a little while. If you still see replicas after running this command, run it again in 10-15 minutes.

Removing Public Folder replicas using MoveAllReplicas.ps1

If Public Folders are hosted on more than one server, use the MoveAllReplicas.ps1 script to remove replicas from a server, as illustrated in KB 927464: How to remove Exchange 2007 from a computer.

The MoveAllReplicas.ps1 script resides in the Scripts folder in the path where Exchange Server 2007 is installed. It's an easy-to-use script that takes 2 parameters— the source and target server names. The source server is the server you're trying to remove the Public Folder replicas from. The target server can be any other server in the Organization that hosts Public Folders— presumably a server that's in the same location to avoid replicating PFs over WAN links.

MoveAllReplicas.ps1 -Server "SOURCE SERVER NAME" –NewServer "TARGET SERVER NAME"

Once this is done, it may take some time for Public Folders to replicate to the target server, and for these to be removed from the source server. To verify there are no replicas on the source server, you can use the Get-PublicFolderStatistics command.