The Microsoft articles "XCON: Connector Delivery Restrictions Do Not Work Correctly" (Q277872, http://support.microsoft.com) and "XCON: Restriction Settings Are Not Applied After Configuring the Delivery Restrictions Option" (Q279813, http://support.microsoft.com) explain that restrictions you place on SMTP-based connectors (i.e., the Routing Group connector and the SMTP connector) don't take effect until you also add a registry value. Let's look at how to use the Exchange 2000 Server UI to create restrictions and how to fully implement the restrictions.
Applying Restrictions
As Figure 1 shows, the Delivery Restrictions tab on an Exchange 2000 connector defines the users from whom the connector will accept or reject messages. To access the Delivery Restrictions tab, open Exchange System Manager (ESM), select a connector, and view the connector's properties. For the default set of Exchange 2000 connectors, the Message Transfer Agent (MTA) controls the restrictions placed on the X.400 connector, and a combination of the routing engine and the SMTP service controls the restrictions on routing-group and SMTP connectors. As you can see in Figure 1, you can use individual mailbox names or distribution groups to define who can use a connector.
Unfortunately, Microsoft decided that applying restrictions through ESM wasn't sufficient. To complete the job and make the restrictions effective, you also must change the registry to instruct the SMTP service that restrictions are in force and tell the routing engine that it should validate submitters and recipients. The logic behind the registry-change requirement is probably that turning on restrictions causes additional overhead for the routing engine as it checks names against the restricted list. So, Microsoft added a safeguard to prevent unnecessary performance hits incurred through administrator error.
The routing engine performs the checks against Active Directory (AD), so turning on restrictions on a bridgehead server that's already under load or has an extended connection to the nearest Global Catalog (GC) is a bad idea. Remember that Exchange 2000 uses the GC to validate names when the routing engine processes messages because the GC holds a copy of all mail-enabled objects in a forest. However, in production situations, you typically locate bridgehead servers close to GCs, and many of the names that the routing engine needs to check will be in the local directory cache. Thus, in many environments, turning on restrictions on a bridgehead server won't incur a large overhead.
Two REG_DWORD registry values, which Table 1 shows, control how the routing engine performs checking. Place these values in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters registry subkey, as Figure 2 shows.
After you insert the two values, stop and restart the SMTP service and the Exchange Routing Engine service to make the blocks effective. The restart is necessary to let the two services recognize that restrictions are in place and read the information about users who should be permitted to send or barred from sending through the connector. The restrictions you set are active for all SMTP-based connectors on a server.
To test the restrictions, attempt to send a message from a blocked account. If the block is effective, you'll receive a nondelivery notification similar to the one that Figure 3 shows.
Of course, any change you make to the system registry can affect only components that are active on that server. If you have only one server that hosts connectors and you restrict that server, the block is effective for the entire organization. However, if a message can take multiple routes through your organization to get to a destination, you need to implement the restriction at every bridgehead server along these routes. (You can create an AD Group Policy Object—GPO—to distribute the needed settings.)
"XCON: Connector Delivery Restrictions Do Not Work Correctly" states that you might see event ID 957 from MSExchangeTransport if you set restrictions on a connector and don't make the registry changes. On an Exchange 2000 Service Pack 3 (SP3) system, I placed restrictions on an SMTP connector, then on a routing group connector—both without changing the registry—then sent test messages. The tests stubbornly refused to generate any evidence of event ID 957, so don't depend on this event as a warning that restrictions aren't working properly.
Exchange 2000 implements delivery restrictions on SMTP connectors through a combination of UI and registry settings. Remember to change both sets of settings if you want to stop specific people from using a connector.
