Policies and permissions

Creating a dead letter office

Employees come and go; their mail subscriptions stay with you for a long time. When you delete a former employee’s mailbox, you’ll find that Non-Delivery Reports (NDRs) for mail messages addressed to their once-valid Internet addresses will arrive in the Postmaster (or Administrator) mailbox (along with all the other non-deliverable messages sent to your domain). Although users eventually stop sending mail once it goes unanswered or they receive an NDR themselves, many listservs and other automated messaging applications will, unfortunately, continue to send mail to invalid addresses, creating an unnecessary number of NDRs in the Postmaster mailbox.

 

As a busy Administrator, you don’t have time to unsubscribe former employees’ addresses from all the mailing lists they subscribed to. Instead, route that mail to a Dead Letter Office and keep the unnecessary NDRs from appearing in your Postmaster mailbox.

 

1.       Create a mailbox named Dead Letter Office and hide it from your Global Address List.

2.       Open the mailbox’s Properties sheet and click the E-mail Addresses tab.

3.       Add the Internet addresses of former employees to the mailbox.

 

Now Exchange will deliver all the mail that your domain receives for the expired addresses to the Dead Letter Office mailbox instead of the Postmaster mailbox. Be sure to clean out the Dead Letter Office fairly frequently using Exchange Administrator’s Clean Mailbox tool.

 

Is the server you love a spam relay?

Many administrators don’t find out that it’s possible for their mail servers to be used to relay spam or other unauthorized messages until someone has already done so. How does this happen? Unfortunately, the default configuration of many types of mail servers, including Microsoft Exchange, allows open SMTP relaying. This feature lets anyone use an SMTP mail client program to send a message to your mail server, which it in turn relays to one or more (or hundreds) of external addresses. In the early days of the Internet, admins left this feature enabled in the spirit of openness and cooperation. However, today it’s too often abused and should be disabled if you want to save you and your company the embarrassment of being an unwitting relay for spam.

 

We’ve published tips on restricting your Exchange server’s SMTP relaying behavior, but you can also learn more by reading Microsoft Knowledge Base article 193922.

 

Editing Public Folder permissions from the command line

Exchange tip reader Mark Turner asks, "Is there a way to append permissions to public folders and all the subfolders like you can with Cacls.exe for NT permissions?"

 

Yes, there is a way to set, modify, and extract permissions for your Exchange Organization’s Public Folder Hierarchy from the command line. For this job, there’s a command-line tool called Pfadmin.exe, which is included in the Microsoft BackOffice Resource Kit, Second Edition. If you’ve used the Windows NT Server 4.0 Resource Kit’s Cacls.exe, you’ll find Pfadmin.exe very familiar. To use Pfadmin.exe, install Outlook on your workstation or server and create a MAPI profile that logs on to a mailbox that uses the Exchange service account as its primary Windows NT account. Pfadmin.exe can also extract public folder permissions to a file and later use the file to reapply the extracted permissions. This can be a lifesaver if permissions have been manually misapplied and propagated through subfolders. For more information on Pfadmin.exe, see the documentation that comes with the BORK or read Microsoft Knowledge Base article 199319 to learn how to use the tool to extract public folder permissions.

Propagating folder permissions with Exchange Administrator

The advantage to setting folder permissions in Exchange Administrator rather than the Exchange client is that you can set your permissions to apply to all subfolders as well. However, there is a drawback to this approach—if a user has added a folder to Favorites, that link to the original folder bypasses all permissions later assigned to that folder.

 

To prevent this potential conflict, enter your Exchange Administrator and execute the following steps:

 

1.       Select from the left pane the folder you want to modify.

2.       Click Properties on the toolbar.

3.       Select Client Permissions and change the appropriate settings, as you would in your Exchange client.

4.       Select Propagate These Properties To All Subfolders.

5.       Click OK.

6.       Within the Subfolders Properties dialog box, select Client Permissions.

 

Checking the private information store

It’s a good idea to clean house before problems develop. Here’s how to check the physical resources being used by every mailbox on a server:

 

1.4. Open Exchange Administrator.

2.5. Select the site you want to work with.

3.6. Select the Configuration container.

4.7. Select the Servers container to display all the Exchange servers.

5.8. Select the server that holds your Private Information Store.

6.9. Highlight Private Information Store.

7.10.          Select Properties from the File menu.

8.11.          Within the resulting dialog box, click the Mailbox Resources tab.

 

Now you can see where your resources are going and either move some mailboxes to another server, clean the overloaded mailboxes, or set up mailbox storage limits.

 

Protecting and optimizing your transaction logs

Every Exchange administrator should understand the importance of Exchange transaction logs. Exchange uses its transaction logs to record database transactions to disk before committing the transactions to its database. Exchange Server uses these logs to perform a soft recovery after a system crash. Exchange writes the logs to disk in contiguous blocks to optimize disk writes and transaction logging performance. The best place to put your transaction logs depends on many factors. However, when configuring Exchange Server, try to use the following rules whenever feasible.

 

1.       Always make sure there is plenty of room on the volume where you place the transaction logs and monitor disk space availability. When Exchange Server runs out of room for transaction logs, it shuts itself down.

2.       Do not put transaction logs in the same volume with the Exchange databases themselves or other files shared by applications. Doing so makes the logs contend with other files for disk space and requires the disk’s head to move to different parts of the disk while performing writes.

3.       Use RAID 1 (mirroring) to protect your files. Small SCSI disk drives are now inexpensive enough that you can justify the benefit of mirroring two of them and using them exclusively for Exchange transaction logs. Remember that even if the array or volume holding your Exchange databases stops functioning, you can recover up to the minute of failure if you have a tape backup of the database and your current transaction logs.

 

Creating pass-through aliases

Often a recipient in your organization will act as a relay point to another recipient outside the organization. Your users have probably already asked you to create mailboxes that they intend to use for this purpose by creating a rule that forwards all of the mail the mailbox receives to the Internet address for someone else. This allows the outside recipient to receive mail as though he or she was actually a recipient in your own organization.

 

Though a mailbox is useful for this purpose, it’s not necessarily the best tool for the job. As an administrator, you should strive to keep the number of mailboxes in your organization to an absolute minimum. If you only need to pass mail sent to one Internet address to another, it would be better to create a pass-through alias. To do so, follow these steps:

 

1.       Create a Custom Recipient entry that points to the outside recipient’s Internet address.

2.       Open the Custom Recipient’s Properties sheet and click the E-mail Addresses tab.

3.       Click the New button and add an Internet address that follows the naming convention at your company (e.g., recipient@mycompany.com).

 

Now, when your Exchange Server receives mail addressed to recipient@mycompany.com, it will send the mail message to the Internet address specified in the Custom Recipient entry.

 

Who’s using that Internet address?

As you probably know, you can assign more than one Internet address to a recipient. This practice is known as creating Internet address aliases and can be very useful when you need to provide an easy way for users outside your organization to contact groups or individuals in your organization. For example, you might create a distribution list that contains your company’s system administrators. This distribution list may have the display name @SysAdmins for use inside your organization, but by creating Internet address aliases you can make this distribution list known as security@mycompany.com, administrator@mycompany.com, sysadmin@mycompany.com, or any dozen or more aliases on the Internet.

 

To add an Internet address alias to a recipient, simply open the Custom Recipient’s Properties sheet and click the E-mail Addresses tab. Then click the New button and add an Internet address.

 

Once you’ve become accustomed to assigning multiple Internet address aliases to a single recipient, you’ll find that you’ve lost track of who’s using which aliases. You’ll usually find this out when you try to assign an alias that’s already assigned to another recipient. Unfortunately, Exchange Administrator doesn’t let you search for recipients by Internet Address alias. The easiest way to find out which recipient is using an alias is to open a New Message window in Outlook. Then type the alias in the To: field and press [Ctrl]K. Outlook will resolve the alias to the display name for the recipient in your organization.

 

Create recipients’ aliases right the first time

Good Exchange administration requires good planning, as Exchange is not nearly as forgiving of our mistakes as we would like it to be. To wit, when you create a recipient, you must make sure that you’ve correctly spelled its alias before you click OK. Why is this so important? When you create a recipient, Exchange uses the alias you’ve entered to create the recipient’s Directory Name. For those of you familiar with databases, the Directory Name field is the Primary Key in the Exchange Directory database. This means that whenever you perform directory imports, you must reference a recipient’s Directory Name to modify its entry (record) in the directory. Even if you change the recipient’s alias after creation, you cannot modify the recipient’s Directory Name. The only effective way to modify the recipient’s Directory Name is to delete and re-create the recipient!

 

Exchange Administrators commonly make the mistake of using a "friendly" alias in the form of first initial plus last name (which is the example often given in Exchange Administration tutorials) for creating mailboxes. Instead, we recommend that when you create employee mailboxes you use an employee number as the alias instead of a friendly alias name. That way, an employee name change will not require you to delete and re-create the employee’s mailbox to keep the Directory Name consistent with his or her actual name.

 

The ups and downs of anonymous LDAP access

An out-of-the-box Exchange Server installation enables anonymous access to your organization’s directory via the Lightweight Directory Access Protocol (LDAP) on TCP port 389. If your Exchange Server’s TCP port 389 is accessible via the Internet or other network, users outside your organization can use LDAP to look up Internet addresses for recipients in your organization.

 

Microsoft intended this feature to be useful, but you should be aware that it is easily misused. If you leave the anonymous LDAP enabled, savvy users can anonymously retrieve the Internet addresses of all of your organization’s recipients and use the addresses to send unsolicited commercial e-mail or inappropriate messages.

 

To disable anonymous LDAP for your entire site, use Exchange Administrator to open your site’s Configuration container and expand the Protocols child container. Then highlight LDAP protocol in the right pane and choose File | Properties. In the resulting LDAP Site Defaults Properties dialog box, click the Anonymous tab and deselect Allow Anonymous Access. Then click OK. Now, any Exchange server in your site that is configured to use the LDAP Site Defaults Properties will no longer allow anonymous access to your organization’s directory.

 

NOTE: Disabling Anonymous LDAP access does have one unpleasant side effect—it renders Outlook Web Access to the server inoperable.

 

Setting up an Exchange 2000 Chat Service Profanity Filter

Suppose you want to use Exchange 2000 Chat Service to set up a Profanity Filter on the Chat server for a particular chat community. First, come up with a list of words you want to filter. Then, using the Profanity Filter extension, apply the list to conversations on the channel.

 


Here’s how to verify that the Profanity Filter (Pfilter) extension is actually installed:

 

  1. Click Start | Programs | Microsoft Exchange | System Manager.
  2. In the chat community you’re connecting the filter to, click the Channels folder.
  3. In the Details pane, right-click the appropriate channel and then click Properties | Extensions.
  4. Make sure the Profanity Filter extension is displayed.

 

On the chat community’s Extensions tab, you’ll see a list of all of the extensions that are installed for the chat community. The order they’re in indicates each extension’s priority. To modify the priority of the

Profanity Filter extension, click Move Up or Move Down.

 

For more detailed information about the Profanity Filter or for step-by-step instructions on how to find out what to do if the Profanity Filter extension isn’t displayed, add words to the filter, or apply the Profanity Filter to the children’s channel, see Microsoft Knowledge Base article 271667.

 

 

Tips on tasks

Reduce your IMS’s dependency on DNS

The mail must go through, and as a good administrator, you’ll take the extra steps needed to make sure it does. But if you administrate for a small organization, your Exchange server probably uses your ISP’s DNS to resolve host names to the IP addresses of the servers that receive mail for a domain. If so, your Exchange Server’s Internet Mail Service (IMS) would be unable to send mail if your ISP’s DNS servers were unavailable. To eliminate this dependency, you could implement your own in-house DNS server. However, since all systems are subject to failure, any DNS outage could render your IMS incapable of sending mail.

 

Fortunately, Exchange Server’s IMS lets you create a table that overrides DNS resolution. You can use this feature to create a permanent host name-to-IP mapping for domains that are critical for your organization. For example, you may want to create mappings for the domains of your business partners or key vendors. To do this, follow these steps:

 

1.       Start Exchange Administrator.

2.       Open IMS Properties and click the Connections tab.

3.       Click E-mail Domain. In the resulting E-mail Domain dialog box, click Add. The Add E-mail Domain button will appear.

4.       Enter the domain in the E-mail Domain field.

5.       Select the Forward All Messages For This Domain To Host option and enter the IP address of the host that receives mail for the domain.

6.       Click OK three times to close the dialog boxes. Stop and restart the server’s IMS.

 

Now your Exchange server will be able to resolve the critical host names even if a DNS outage occurs. Just remember to update the mappings if the IP address of the domain’s mail server changes.

 

Also note: Your Exchange IMS never uses its local HOSTS file to resolve IP addresses for a domain’s mail server. Microsoft purposely designed the IMS to overlook this conventional form of host name resolution to prevent an out-of-date HOSTS entry from affecting mail delivery.

 

Get your post-SP3 hotfixes!

No service pack would be complete without a handful of post-service pack hotfixes! Now that you’ve just gotten around to putting Exchange Server 5.5 Service Pack 3 on all your production servers, you’ll need to read up on the hotfixes. But remember, apply them only if they fix a problem that you’re experiencing. For a comprehensive overview of the available post-SP3 hotfixes, see Microsoft Knowledge Base article 248838.

 

Note that if you reapply an Exchange Service Pack after applying hotfixes, you’ll need to reapply the hotfixes as well. But if you didn’t remove the hotfixes before reapplying the Service Pack, Hotfix.exe may return an error when you try to apply a hotfix. See Microsoft Knowledge Base article 180002 for details on how to reinstall hotfixes after reapplying a Service Pack.

 

Configuring the TURF table without editing the registry

In a previous tip, we explained how to edit your Exchange Server’s registry to configure Exchange’s TURF table—a table of usernames and domain names. As you may know, Exchange Server will reroute messages received from the usernames and domains in the TURF table to its TURF directory instead of delivering them to local recipients or rerouting them. If the TURF directory doesn’t exist, Exchange will simply delete the messages.

 

A tip reader wrote to suggest an easier way to configure the TURF table that doesn’t require tricky registry editing. Simply open Exchange Administrator and view the Properties dialog box for your Internet Mail Connector. Then, click the Connections tab and click the Mail Filtering button. In the resulting Message Filtering dialog box, you will find an interface that allows you to configure all of the options that we showed you how to configure by editing the registry. To keep messages instead of deleting them, deselect the Delete Messages Instead Of Moving Them To The TURF Directory option.

 

Locking down server-to-server Internet connections

When configuring an Internet Mail Service connector, you may want to take some additional security steps to protect your data as it goes flying around the Internet from Exchange server to Exchange server. In particular, you may want to configure Exchange to encrypt all data—including directory and replication messages—and configure connected servers to accept only authenticated, encrypted information.

 

Here are four IMS settings you may want to employ to improve security on servers connected via the Internet. (These settings do interfere with the ability to send general Internet mail, so use them judiciously.)

 

1.       Click Specify By Host and then click Add. Enter the remote server’s subnet mask and IP address. Also specify that the host must use authentication and encryption.

2.       Specify the host name or IP address of the remote server under Message Delivery.

3.       Click the Address Space tab. Delete the default settings, enter a new address space of type SMTP, and use the domain name of the remote server as the address. (This blocks routing of general Internet mail.)

4.       Click the Security tab. Click Add and then enter the remote site’s address. Select the Windows NT Challenge/Response option and then set the Exchange Site Service account as the validator.

 

Read Part #2  TOBE CONTINUED

Advertisements