Exchange Server 2003 Troubleshooting: Transport

Microsoft Confidential Overview...3 New Features ...4 Routing Link State Algorithm...4 ArchiveSink Enhancements...5 Lab 1: ArchiveSink ...9 Public Folder Affinity...10 DNS Resolver Enha

Microsoft Confidential

Overview 3

New Features 4

Routing Link State Algorithm 4

ArchiveSink Enhancements 5

Lab 1: ArchiveSink 9

Public Folder Affinity 10

DNS Resolver Enhancement 12

Lab 2: DNS Resolver 17

Domain Address Rewrite 18

Lab 3: Domain Address Rewrite 23

Query Based Distribution Group 24

Lab 4: Query Based Distribution Groups 31

Recipient Filtering 32

Lab 5: Recipient Filtering 37

Distribution Group Restrictions 38

Lab 6: Restricted Distribution Groups 41

Security Principle Based Submit and Relay 42

Lab 7: Security Principle Based Submit and Relay 46

Connection Filtering and RealTime Block List (RBL) 49

Lab 8: Connection Filtering and RBL 64

Fault Analysis 68

Appendix A - Scripts 79

Appendix B – Cube Notes 81

Exchange Server 2003 Troubleshooting: Transport

Information in this document, including URL and other Internet Web site references, is subject to change without notice Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred Complying with all applicable copyright laws is the responsibility of the user Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2003 Microsoft Corporation All rights reserved

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, Exchange 2000 Server, Exchange Server 2003, Outlook, Outlook Express, Outlook Web Access, Windows 2000, and Windows Server 2003 are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries

The names of actual companies and products mentioned herein may be the trademarks of their respective owners

Microsoft Confidential

Overview

This document is intended to provide Microsoft Exchange administrators with the information necessary to successfully configure, deploy and troubleshoot the new features of Microsoft® Exchange Server 2003 SMTP transport The module assumes a good knowledge of Exchange 2000 Server SMTP transport

New Features

Routing Link State Algorithm

The link state algorithm in Exchange 2003 has been changed to address conflicting link states that result when network or other transient hardware problems cause conflicting link state information This change was implemented in two parts:

„ First, the default link state update interval was lengthened to ten minutes versus the five minute interval of Exchange 2000

„ Secondly, each server compares the last link state it received for a given route to the link state that is to be sent to the Routing Group Master

• If the last link state update received does not match the link state the server is prepared to send, the server appends a new update that matches the last one received and does not change the link state message

• If the next update interval expires, a link state update is not received; the server sends a link down status update to the Routing Group Master

When ArchiveSink is enabled, the default behavior is to archive all messages and their recipients, with the exception of bcc: recipients Each message is archived to an eml file that includes message ID, subject, and all recipients on the “To” and “cc:” lines When you enable bcc: archiving, an additional xml file for each message is generated The XML file for bcc: contains the same information produced for other message recipients and includes bcc: recipients All messages are in one of two directories in the archive location the

administrator specifies:

• MAPI Gateway Messages - This directory holds all messages

submitted by MAPI clients, such as Outlook, and messages submitted through foreign gateway servers

• SMTP Messages - This directory contains all messages submitted

through the SMTP service

ArchiveSink uses two transport events, OnMessageSubmission, and

OnPostCategorize

OnMessageSubmission event

All messages submitted through the Information Store and the SMTP transport

triggers the OnMessageSubmission event This event is triggered before any

routing or categorizer events This event is triggered only once per message Messages archived for this event contain the prefix filename: ARCH_<random number>.eml

When the ArchiveSink is installed, messages are archived for this event by default Messages archived for this event contain the prefix filename: ARCH

So an archived message appears as ARCH_<random number>.eml

OnPostCategorize event

The OnPostCategorize event captures a message after it is categorized, that is

after the sender and recipients have been located in the directory and any distribution lists have been expanded Message archival is not the default

behavior of the OnPostCategorize event; archival is enabled via the registry

Messages can trigger this event multiple times Messages archived for this event contain the prefix filename: ARCH_<random number>_POSTCAT.xml The original message is parsed by the categorizer, which generates a new message for each recipient of the original message Hence, each message is a new message destined for a specific domain or server and will trigger the

OnPostCategorize event

Internet Message Format

Messages are parsed or turned into a unique message for each recipient for many reasons; for example, recipients are located in another messaging system

or the recipient is a distribution list The Internet Message Format options available on Exchange Server 2003 require special content handling for recipients in foreign domains or smart hosts Consider the case when all mail sent to one domain is sent as plain text and to another as MIME These new

messages also trigger the OnPostCategorize event

Setup

ArchiveSink is installed via script and configured via script and the registry The sink is installed on a per virtual server basis The sink must be uninstalled using the same script; ArchiveSink_Setup.vbs

• ArchiveSink requires restart of IISAdmin service after installation

• Registry changes require restart of SMTP service

Copy archivesink_setup.vbs and archivesink.dll files from the location where you expanded the Web Release of Exchange Server 2003 tools into the

\exchsrvr\bin directory

The text below demonstrates the command line and usage of the setup script

Cscript archivesink_setup.vbs [install|uninstall|display] [Virtual server ID] [archive location]

Run archivesink_setup.vbs with the appropriate switches for the given SMTP virtual server

When installation is successful, the script automatically creates registry key parameters for advanced archiving controls

Microsoft Confidential

HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\<virtualServer#>\

"Archive System Messages"

"Dump P1"

"Enable MAPI Gateway Messages"

"Enable Message Logging"

The sink archives only OnMessageSubmission messages by default In

addition, system messages are not archived (public folder messages, replication messages, and so on)

ArchiveSink archives all messages to the path specified in the registry If this key is absent, it defaults to the system temp folder For most computers running Microsoft® Windows Server™ 2003 computers, the default location is

„ Dump P1 = 1: ARCH_RandomNumber.P1 binary file is generated for each archived message This binary file contains the property stream of the e-mail message and is helpful only for Exchange debugging purposes

Install the sink on SMTP virtual server 1 and make logs in c:\archivesink directory:

Cscript archivesink_setup.vbs install 1 c:\archivesink

„ BCC recipients = All messages that pass through SMTP virtual server 1 will

be archived However, the BCC recipients will not be logged until the value

of the Enable Message Logging key is changed to 1 in the registry:

a Click Start, click Run and type RegEdit

b Browse to

HKEY LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1 (where 1 represents SMTP virtual server 1)

c Right-click on the Enable Message Logging key Then click Modify

d Change the value data to 1 Then click OK

e Restart the default SMTP virtual server

f Display the bindings on SMTP virtual server 1:

Important

Cscript archivesink_setup.vbs display 1

g Remove the sink from SMTP virtual server 1:

Cscript archivesink_setup.vbs uninstall 1

Run the archivesink_setup.vbs script

Enable the Message Logging registry key that ArchiveSink creates, to turn

on message logging by importing reg file or manual adding key to registry Send messages with Outlook 2003 and Outlook Express to verify that MAPI, BCC and standard messages are archived

Exercise 1:

1 Enable archiving for all message types

2 Send messages with MAPI and SMTP client

3 Verify that P1, bcc: and standard message types are archived

4 Have instructor verify your results

Public Folder Affinity

The default Public Folder (PF) referral is calculated based on the routing cost

Exchange Server 2003 introduces the concept of PF Affinity This new feature

allows the administrator to define which servers will receive client request for

PF content

The new feature is configured on the Public Folder Referrals tab of the “server”

properties in ESM The list has two choices; Use Routing Groups or Use

Custom List When Use Custom List is selected, the administrator may enter

or browse for the servers in the organization and add their cost (preference) Lower cost represents a greater preference This gives the administrator the ability to use costs to prioritize servers in the referral list

Exchange Server 2003 implements this new feature with two new attributes,

msExchFolderAffinityCustom, msExchFolderAffinityList, and supporting

code The value of msExchFolderAffinityCustom determines if PF affinity

will be used for PF referrals

„ If the msExchFolderAffinityCustom attribute is not set or has a value of 0,

PF referral behaves the same as Exchange 2000

„ If the attribute is present and contains a value of 1, the new server attribute

msExchFolderAffinityList list is parsed for the cost of each of the selected

servers; the list is the server GUID Then servers not listed as preferred servers are assigned an infinite cost This ensures that servers in the list with lesser cost will be the target of the referral

„ If the selected server is unavailable, the referral will be passed to the next server in the list until the list is exhausted At this time, the referral will fail and the client will receive an error

Exchange Transport has no knowledge of which servers have a complete PF hierarchy Transport has been engineered to make a calculated assessment of when the PF hierarchy will be present Exchange Server 2003 and Exchange

2000 SP4 transport first selects servers from TLH list, PF servers list, whose history is more than two days Next, server selection proceeds based on topology; local server, then servers in same routing group, then servers in same Adminstrative Groups (AG) and then servers in other administrative groups The rationale is that a server older than two days will most likely have the PF hierarchy in place So if you install a new PF server, it is highly unlikely PF messages will flow to that server until two days have passed If a message reaches a server with the hierarchy in place, and there is no replica of the folder, the store will attempt referral based on routing or affinity in Exchange Server

2003 If there is no hierarchy, the messages will remain in local retry on the server with the incomplete PF hierarchy and the store will not attempt reroute after the PF hierarchy is complete

Replication of PF hierarchy is via normal e-mail messages If transport between PF servers is disrupted for more than two days, PF messages may become stuck in the local retry queue on the new PF server Another possible reason is that the hierarchy is simply too big and two days are not enough Organizations with a large PF hierarchy can mitigate the possibility of the latter

by changing the value of the following registry parameter to increase the time delay before the server is considered as having public folders

"HKLM\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

\IgnorePFTimeLimit"

dWORD: days to exclude new servers from receipt of PF messages

The IIS Admin service will need to be restarted for this registry change to take place; reference knowledge base 328870

Note

DNS Resolver Enhancement

Exchange 2000 SMTP Domain Name Server (DNS) resolver allows for specifying DNS servers that are different from those that are being used by the operating system This functionality allows the operating system to maintain connectivity with the internal DNS infrastructure, while the SMTP DNS resolver can connect to external DNS servers for resource records required for locating hosts outside the internal network While this capability is ideal for configuring Exchange 2000 based Internet mail delivery, using this

functionality has some shortcomings

Issue

To resolve domains on the Internet, the Windows 2000 SMTP server called code in the DNS resolver event The Windows 2000 DNS resolver sink resolved the hosts using the alternate DNS servers, and returned the list of IP addresses for mail exchangers resource records) to the SMTP virtual server The shortcomings were a result of the existing design of the Windows 2000 DNS resolver

„ It was slow because the Windows 2000 DNS resolver event is synchronous This can manifest as outbound mail queue backlog on heavy volume servers

„ The Exchange 2000 DNS resolver sink does not track the DNS server state;

an unresponsive DNS server will cause a delay each time it is queried, unlike Windows Server 2003 SMTP which has code to track which servers are unresponsive

„ The Exchange 2000 DNS resolver sink does not load balance equal priority mail exchanger records

Microsoft Confidential

The sink did not maintain the state of external DNS servers If several external DNS servers are used by Exchange 2000 DNS sink and some of these DNS servers are not responsive, they are not removed from the consideration for subsequent queries and the priority/sequence of DNS server selection does not change This causes unnecessary lookup delays and excessive network traffic

When multiple mail exchanger records with the same cost are

available for a particular domain, an Exchange 2000 SMTP virtual server configured to use the DNS sink tries them in the same order each time the connection is established The order matches the order of the hosts as returned by the response to the DNS query As a result, only the host referenced by the first mail exchanger record is tried, and 100% of mail goes through it Hosts referenced by other mail

exchanger records are used only in the event the first host becomes unresponsive

If several hosts referenced by the first mail exchanger records are not available there is approximately a 23 second time penalty/per host for Transmission Control Protocol (TCP) connection timeout Coupled with the fact that mail exchanger records are tried in the same sequential order for each connection within the SMTP queue, an unnecessary delay occurs when unavailable mail exchangers are tried

There are no performance counters for Exchange DNS resolver sink, and the Exchange DNS resolver sink does not update the DNS query/sec on the SMTP virtual server object in performance monitor

Solution

Exchange Server 2003 running on a computer with Windows Server 2003 will enhance DNS based Internet mail delivery to achieve load balancing, better performance characteristics and better tolerance to network unavailability and external DNS server responsiveness This behavioral change will address the issues described above

Development achieved this goal by unifying the code paths and expanding the Windows Server 2003 DNS event to return the DNS server list from the

Exchange Server 2003 DNS resolver sink in lieu of the default global DNS server list if the SMTP virtual server is configured to use external DNS servers for mail delivery

The new DNS resolver sink in Exchange Server 2003 exposes both the old and the new interface The new interface only checks to see if the domain to be resolved is an external domain, and if so, returns a DNS server list to the Windows Server 2003 DNS event However, it is important to remember that the behavior for Exchange Server 2003 installed on computer running Windows

2000 Server is the same as that of Exchange 2000 installed on a computer running Windows 2000 Server

DNSDiag – a new diagnostic tool

Summary:

This tool is used to troubleshoot problems with DNS resolution for SMTP It simulates SMTPSVC’s internal code path and prints diagnostic messages that indicate how the resolution is proceeding The tool must be run on the machine where the DNS problems are occurring

Program return codes:

These are set as the ERRORLEVEL for usage in batch files:

„ 0 - The name was resolved successfully to one or more IP addresses

„ 1 - The name could not be resolved due to an unspecified error

„ 2 - The name does not exist The error was returned by an authoritative DNS server for the domain

„ 3 - The name could not be located in DNS This is not an error from the authoritative DNS server

„ 4 - A loopback was detected

Usage Notes:

DNSDiag <hostname> [d] [options]

<hostname> - Hostname to query for

This may not be the same as the display name of the queue (in ESM,

if Exchange is installed) It should be the fully qualified domain name of the target for the queue seeing the DNS errors

d - This is a special option to run in debug/verbose mode There is a lot

of output, and the most important messages (the ones that normally appear when this mode is not turned on) are highlighted in a different color

Options are:

„ v <VSID> - If running on a computer with an Exchange DMZ, you can

specify the VSI# of the VSI to simulate DNS for that SMTP VS Then this tool will read the external DNS server list for that VSI and query that server list for <hostname> when <hostname> is an "external" host If <hostname>

is the name of an Exchange computer, the query is generated against the default DNS servers for the local computer

„ s <server list> - DNS servers to use, if you want to specify a specific set of

servers If this option is not specified, the default DNS servers on the local computer are used as specified by v This option is incompatible with v

„ p <protocol> - Transmission Control Protocol (TCP) or User Datagram

Protocol (UDP) TCP generates a TCP only query UDP generates a UDP only query DEF generates a default query that will initially query a server with UDP, and then if that query results in a truncated reply, it will be retried with TCP If this option is not specified, the protocol configured in the metabase for \smtpsvc\UseTcpDns is used This option is incompatible with the v option

„ a All the DNS servers obtained (either through the registry, active directory,

or s option) are tried in sequence and the results of querying each are displayed

Note

Microsoft Confidential

C:\> DNSDiag fe.concsi.lab –d –a –v 1

Running in debug/verbose mode

The DNS flags are not explicitly set in the metabase, assuming default flags 0x00000000

These are the local IP addresses (server bindings)

192.168.1.10

Microsoft Exchange is installed on this machine

Querying domain controller for configuration

The domain controller server which will be used for reading configuration data is DC.concsi.lab

Connecting to DC.concsi.lab over port 389

configurationNamingContext is "CN=Configuration,DC=re,DC=pro" This will be used as the Base DN for all directory searches Checking if the target server fe.concsi.lab is an Exchange server

Searching for an Exchange Server object for fe.concsi.lab on the domain controller

LDAP search returned some results, examining them

Examining next object for attributes we are interested in Successfully read the distinguishedName attribute on the Exchange Server object The value of the attribute is

CN=FE,CN=Servers,CN=First Administrative

Group,CN=Administrative Groups,CN=GLS,CN=Microsoft

Exchange,CN=Services,CN=Configuration,DC=re,DC=pro

The search returned the following 6 values for the

networkName attribute for the Exchange Server object for fe.concsi.lab

Attempting to match the TCP/IP networkName of the Exchange Server object returned from the domain controller against the FQDN we are searching for

0> networkName: ncacn_vns_spp:FE match failed

1> networkName: netbios:FE match failed

2> networkName: ncacn_np:FE match failed

3> networkName: ncacn_spx:FE match failed

4> networkName: ncacn_ip_tcp:FE.concsi.lab match succeeded fe.concsi.lab is an Exchange Server in the Org

fe.concsi.lab is in the Exchange Org Global DNS servers will

DNS Servers: (DNS cache will not be used)192.168.1.2

Connecting to DNS server 192.168.1.2 over UDP/IP

Connected to DNS 192.168.1.2 over UDP/IP

Response received from DNS server

Received DNS Response:

Error: 9501 Description: No records could be located for this name These records were received:

concsi.lab SOA (SOA records are not used by us) Querying via DNSAPI:

QNAME = fe.concsi.lab Type = A (0x1)

Flags = DNS_QUERY_TREAT_AS_FQDN, (0x1000) Protocol = Default UDP, TCP on truncation Servers: (DNS cache will be used)

Default DNS servers on box

Received DNS Response:

Error: 0 Description: Success These records were received:

FE.concsi.lab A 192.168.1.11 FE.concsi.lab A 192.168.1.10

No CNAME records in reply

Checking reply for A record for fe.concsi.lab

2 A record(s) found for fe.concsi.lab Local host's IP is one of the target IPs

Discarding all equally or less preferred IP addresses DNS configuration error (loopback), messages will be NDRed Local host's IP address is the most preferred mail exchanger record

Shutting down ATQ Shutting down IISRTL Exit code: 4

Example: fe.concsi.lab is the SMTP server

DSN logging

Delivery Status Notification (DSN) is the SMTP nomenclature for system transport notifications NDR, or non-deliverable, has become synonymous with DSN in the Exchange world DSN error codes were cryptic in Exchange 2000 Exchange Server 2003 addresses this by adding a new category, "NDR", to the transport diagnostic logging

All NDR related events, their causes and proposed resolutions may be found at http://support.microsoft.com/default.aspx?scid=kb;EN-US;284204 This new logging category, combined with the enhanced transport logging new to Exchange Server 2003, provides message status from start to finish

Note

Students will find the utility fails until they either add

%windir%\system32\inetsrv to the path or copy isatq.dll to the directory with dnsdiag.exe

Exercise 1:

Determine and correct the problem with the execution of dnsdiag.exe by

examining the output of dnsdiag.exe for the concsi.lab domain

Domain Address Rewrite

When companies merge, Exchange is often integrated into a heterogeneous messaging environment Often there is a requirement that all mail destined to external domains reflect the same source domain

Exchange Server 2003 introduces this functionality by rewriting the domain address in both P1 and P2 message envelopes This functionality has existed in sendmail for some years and may have blocked Exchange penetration of this market to some degree

Servers in CompanyB are configured to forward all outbound mail to one of the SMTP bridgehead servers in CompanyA that has been configured for domain address rewrite

MX B.com <-smtp-> domain rewrite enabled MX

MX A.com <-smtp-> INTERNET

UserB has address: userB@B.com

UserB is a contact in OrgA called UserB

UserB has target address userB@B.com, the primary ‘SMTP’ proxy address

is userB@A.com UserB in OrgB sends mail to UserC@c.com and a friend on the Internet

Introduction

Microsoft Confidential

The From has userB@B.com

The mail is forwarded to a domain address rewrite enabled bridgehead in A.com

The bridgehead looks up the recipients in the From:, To: and CC: of the

The friend on the Internet gets the e-mail The From: field will show

userB@A.com; the domain has been rewritten

When the friend at C.com replies, the mail will be directed to one of the mail exchangers for A.com

The mail exchanger for A.com will route the message for userB@A.com to a mail exchanger for B.com because the target address of the contact for

userB@B.com is userB@B.com

userB@B.com will receive the message

Conditions for Address Rewrite

Domain address rewrite requires the following conditions to succeed

„ The SMTP virtual server heuristic value must have been incremented by 1

by using either exarcfg.exe or a manual edit

„ The message must be submitted via a SMTP virtual server meaning another mailer or mail client with the SMTP send function, such as Outlook

Express

„ There must be a contact with a target address matching the sender’s From:, address of the message and a primary SMTP address matching the domain

of the SMTP bridgehead enabled for domain rewrite

„ The message must be destined for a domain external to the directory of the address rewrite enabled SMTP bridgehead There can be no contact in the directory with a primary SMTP address reflecting the domain of the rewrite enabled SMTP bridgehead and a target address of the actual sending domain

Mail originating within the Exchange organization that has enabled domain rewrite does not need to be modified for delivery to the intranet or Internet

The exception is mail submitted via Outlook Express or any other SMTP client Netscape®, will undergo address rewrite on that bridgehead server

Internal process

Address Rewrite happens only for external SMTP mail going out to the

Internet, with the exception of mail submitted via a POP client as noted above Address rewrite operations entail:

Note

„ pushing the message to store

„ invalidating the existing MIME and forcing MIME to MAPI conversion to occur, which then causes the address rewrite

• As a consequence, the message is converted to MAPI and the content format must be rendered to MIME before being sent to the Internet

• Transport does the rendering for the message based on the matching Internet Message Format (IMF) of the receiving domain If the recipient

is a contact and the contact has its own personal content settings, they will be used (personal content settings override IMF settings)

• Transport is not RFC 822 content aware If there is no address rewrite required, the above operations occur So, if there are From: and To: addresses that do not need to be rewritten, the message is still converted even though:

• they do not have equivalent contacts OR mailboxes for them in the rewrite domain

• their addresses already match their PRIMARY SMTP proxies in the rewrite domain

In short, all externally submitted SMTP mail will go through this address rewrite conversion process

Address rewrite happens only once for optimization purposes If the mail passes through other bridgehead servers with address rewrite feature enabled, the process or domain rewrite does not occur

UserX and UserY are contacts in the directory of ServerA ServerA has

address rewrite enabled The P1 and P2 envelope of mail destined for the

Internet is rewritten to match the Primary SMTP Address of the contacts representing userX and userY; userx@mycompany.com and

to build the outbound Internet content

Since the entire body has been rendered again, standard content conversion rules are applied: contact settings, XEXCH50 settings, and domain IMF

settings The resolve P2 setting is set to always resolve the sender's address to

the directory for outbound mail that will be rendered again due to address rewrite This guarantees the sender's address is rewritten and does not depend

on the resolve anonymous email setting on the first SMTP VSI to receive the

Primary addresses used for rewrites are based on existing directory objects in the forest of the VSI doing the rewrite This feature is controlled by

PR_INTERNET_ADDRESSING_OPTIONS in the inbound property row PR_INTERNET_ADDRESSING_OPTIONS was not previously used as an inbound conversion parameter

This option forces the store to resolve addresses in all address headers that IMAIL parses and set MAPI counterparts in store Thus, Internet content rendered from the constructed MAPI message will contain the associated primary addresses

SMTP mail relayed to recipients in remote domains when Address Rewrite is

enabled should receive the correct content type on SMTP submissions with P2 address headers rewritten to contain primary addresses Addresses that are not

in the directory should remain unchanged

OMA push messages that are submitted via a SMTP virtual server with this feature enabled should receive the message without character set corruption or loss of the plain text body part

S/MIME messages should arrive with message body intact and no duplicate headers, but the P2 address headers will be rewritten Some clients may warn that the address on the message does not match the address in the certificate used to sign the message This is expected and will be documented as a known issue

In cases where different Exchange organizations are merged, it is a simple issue

to change the primary SMTP proxy address and retain the old SMTP proxy as a secondary The same holds true for some other mail systems; Lotus® Notes™, for example

Contacts are often used to represent the other organization’s personnel This simplifies routing between the different Exchange organizations and enables Outlook and Outlook Web Access to automatically resolve the recipients in the

To, and cc to the corresponding user in either organization The net result is the alias will be resolved to the correct Display Name in the mail message

Clients like Outlook Express can readily change their “reply to” address There

is no need to do this for internal mail, because mailers can be configured to send mail for specific namespace to the proper internal host

Configuring Domain Address Rewrite

Address Rewrite is disabled by default and currently there is no UI in ESM

EXARCF.exe is the command line tool that enables, disables or displays the status of the domain address rewrite feature for a SMTP virtual server This tool will be part of the Exchange Server 2003 Support Tools Web Release EXARCFG can be run from any domain computer which can access the

directory

The following command line enables address rewrite on the first SMTP virtual server on FQDNrewriteServer:

exafcfg s:FQDNRewriteServer v:1

Help is displayed by typing EXARCFG with no arguments

„ exarcfg [l] [e] [d] [s:] [v:] [/?]

„ [l] - lists the current settings per server/VSI Lists the settings for all the

servers in the domain unless a specific server is specified with the s: option

„ [e] - enables address rewrite Default, no options specified, it enables the

feature for the default VS (#1)

„ [s] - specifies which server in the organization has been selected to enable

address rewrite The server name must be specified as a FQDN This is a required option when using options [e] and [d]

„ [v] - allows specifying which VS needs to be enabled for address rewrite

By default the value is 1 (the default virtual server)

„ [d] - disables address rewrite The option [s] is required, since a server has

to be specified If there is no [v], the tool will disable the address rewrite from all the VSI on the specified server If a VSI number is specified [v], then the feature will only be disabled on the specified VSI number

„ [/?] - Provides the list of options and a short help (prints this message) The

command with no options will default to this option

Manual configuration of domain address rewrite is provided to clarify exactly

what is changed and where in the SMTP virtual server object in the directory

1 Using the directory tool of your choice, connect to the Configuration context in the directory

2 Browse to the Exchange server that will be the domain rewrite bridgehead DC=com,DC=domain,CN=Configuration,CN=Services,CN=Microsoft Exchange, CN=netbios_doman,CN=Administrative Groups,CN=First Administrative Group,CN=Servers,CN=FE,CN=Protocols,CN=SMTP, CN=n; where “n” is the virtual server that will configured to rewrite

domain

3 Increase the value of the "heuristics" attribute of the SMTP virtual server by

1 (one) Note: The default SMTP VSI will have a value of 131072; increase

to 131073 Additional SMTP virtual servers will have a heuristics value of

0 (zero); change to 1 (one)

Microsoft Confidential

Lab 3: Domain Address Rewrite

Objective:

„ At the end of this lab students will be able to set up domain address rewrite

Instructor Notes/ Answer:

Add internal.lab as alias for Student workstation; student-n … Add a record to DNS server or configure SMTP connector to forward to IP address of host machine

Add a SMTP connector for internal.lab to the FE server; mbx-fe

Add a SMTP connector for Microsoft.com to the FE server; mbx-fe Configure the FE server for open relay; clear the box for allow only hosts and clients that successfully authenticate and change the relay restrictions

on IIS to all except the list below

Add a contact to the directory with primary SMTP address of

user@concsi.lab and target address of user@internal.lab

Use Outlook Express to send via mbx-mbx-fe.concsi.lab with reply address

of user@internal.lab , email address of user@internal.lab

Send a message to your alias@microsoft.com Use queue viewer in ESM to inspect the message in the microsoft queue and verify that the from address is user@concsi.lab

4 Configure the FE server for open relay

5 Configure a contact that will provide address rewrite for user@internal.lab

to user@concsi.lab

6 Use Outlook Express to send a message from user@internal.lab to

yourAlias@microsoft.com (this message will queue on the SMTP connector and you may use queue viewer to inspect for address rewrite)

7 Verify address rewrite

Query Based Distribution Group

A Query Based Distribution Group (QDG) is a new type of distribution group introduced in Exchange Server 2003

Query Based Distribution Groups:

„ CAN have restrictions; you may restrict who can send to the QDG

„ CAN expand on a dedicated server (if desired)

„ CAN be used for Exchange 200n users and contact based recipients

„ CAN be used for Universal Distribution Group Message Restrictions

„ CAN be nested – Universal Distribution Group is recommended

„ CANNOT be security principals

„ CANNOT be used in an Exchange mixed mode environment; no 4.0/5.x

servers

„ CANNOT use an external directory service for LDAP query; replicate the

external objects to AD

A Query Based Distribution Group provides the same functionality as a standard distribution group, but uses an LDAP query, based on RFC2254 LDAP filter rules to dynamically build membership in the distribution group in lieu of specifying static user membership

A mailing list for all users with mailboxes on a particular server or particular storage group or database is readily constructed using a QDG Imagine the time savings of this method versus manually adding the users to a standard

distribution group using ESM or even programmatically If the user account resides on the server, they will receive the mail

Microsoft Confidential

QDG allows for a much lower administrative cost given the dynamic nature of the distribution group However, a QDG carries a higher performance cost for queries whose outcome produces a large number of results This cost is in terms

of server resources such as high CPU and increased working set, because each message to the QDG has a corresponding LDAP query executed against Active Directory to determine its membership Naturally you cannot view the

membership of a Query Based Distribution Group in the global address list, because it is dynamically generated each time mail is sent However, you can preview the result of the query in Active Directory Users and

3 The categorizer sends the LDAP query request to the global catalog server

4 The global catalog server executes the query and returns the set of addresses that match the query

5 After receiving the complete set of addresses matching the query, the categorizer generates a recipient list containing all the users Note that the categorizer must have the complete set of recipients before it can submit the e-mail to routing; if an error occurs during the expansion of the Query Based Distribution Group to its individual recipients, the categorizer must start the process over

6 After the categorizer sends the complete, expanded list of recipients to routing, the standard message delivery process continues and e-mail is delivered to the users’ mailboxes

The process is slightly different if a dedicated expansion server, a single server responsible only for expanding distribution groups, is used for Query Based Distribution Groups In this case, rather than sending a query to the global catalog server for expansion in Step 4, the e-mail is first routed to the dedicated expansion server After the message arrives at the expansion server, the

expansion takes place and the delivery follows the same process described above

You must use an Exchange Server 2003 version of Exchange System Manager and Active Directory® Users and Computers to create a Query Based

Distribution Group You cannot create Query Based Distribution Group without upgrading your administration console

ESM simplifies the task of making a Query Based Distribution Group We recommend all administrative consoles be upgraded to Exchange Server 2003 ESM before deploying Query Based Distribution Groups

1 Click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers

2 In Active Directory Users and Computers, click the View menu, and then click Advanced Features

3 In the console pane, navigate to the container where you want to create the Query Based Ddistribution gGroup

4 Right- click the container, point to New, and then click Query Based

7 Under Filter, select one of the following options:

Click Include in this Query Based Distribution Group and click each

item you want to include in the criteria for membership in the Query Based Distribution Group

„ The following criteria are predefined:

• Users with Exchange mailboxes

• Users with external e-mail addresses

• Mail enabled Groups

• Contacts with external e-mail addresses

• Mail enabled Public folders

Click Customize filter and then click Customize to create your own

criterion for the query

8 Click Next to see a summary of the Query Based Distribution Group you are

about to create

9 Click Finish to create the Query Based Distribution Group The new Query

Based Distribution Group displays under the Users container in the details pane

of Active Directory Users and Computers

10 Right-click the Query Based Distribution Group you just created and click

Properties

11 Select Click the Preview tab to view the query results and verify that the

correct recipients are included in the distribution group Active Directory Users and Computers provides an easy way to format the LDAP query using standard attributes, without requiring specific knowledge of LDAP

For example, you can select all mailboxes under the organizational unit or even customize the query to select all mailboxes under the organizational unit that exist on a particular server Additionally, after you construct a query, the Preview feature allows you to ensure your query works the way you intended This feature is useful not only for query validation, but also in determining how long a query takes to execute You can use the Preview feature to learn how long a query takes to execute and based on this time, you can decide whether to break up the query into smaller queries for better performance and faster delivery times

The following guidelines are recommended when creating Query Based

Distribution Groups:

Microsoft Confidential

Index the attributes used in the query Indexing greatly improves the

performance of the query and reduces the time required to expand the

distribution group and deliver the e-mail to the intended recipients; Knowledge Base article Q313992

Use Active Directory Users and Computers If the filter string contains bad

formatting or incorrect LDAP syntax, then the global catalog server will not execute the query Using Active Directory Users and Computers to create your query can help prevent you from constructing an incorrect query Use Preview

to view the result of the query; this will ensure the validity and desired results

of the query If you create a Query Based Distribution Group based on an incorrect LDAP query, then when a user sends to the Query Based Distribution Group, the user receives a non-delivery report with the Code 5.2.4 and, if categorizer logging is enabled, one of two events are logged with event

identifiers of 6024 or 6025

If the filter string is well formatted but no results are produced, then the sender will not get an NDR If you track a message with no results, the last event shows the message submitted to categorizer This is the same behavior that results from sending to an empty distribution group As stated earlier, use Preview in Active Directory Users and Computer to confirm the desired result

of your query

Use Exchange System Manager in a security context that has the same permissions for reading objects in the Active Directory as the Exchange server You should note that Exchange System Manager runs in the security

context of the user that is currently logged in If an administrator is running with higher security privileges than the Exchange server, then it may be

possible that the query is accessing Active Directory attributes that are not accessible to the Exchange server, but are accessible to the administrator The administrator will see the correct set of results in the query preview Because the categorizer will run with the Exchange Server permissions, it will not be able to retrieve the same set of results and e-mail will not be sent to the Query based distribution group as the administrator would expect

Issues exist when a base distinguished name (DN) is deleted Query based distribution expansion relies on its base DN referring to a valid container in the directory If a QDG based DN container is deleted, the categorizer cannot execute the query and the sender receives a non delivery report with the code 5.2.4 If categorizer logging is enabled, an event ID of 6024 or 6025 is logged For example, you create a sales container within the Users container for all sales employees and build a Query Based Distribution Group using the sales container If you delete the sales container, the query will no longer work

Considerations for Groups

The time required to expand a Query Based Distribution Group and execute the query depends on several factors The following factors influence the amount of time it takes to expand and execute a Query Based Distribution Group:

The type of hardware deployed in your organization The categorizer can

require up to 2 kilobytes (KB) of memory for each recipient This is a

conservative metric that you can use as a baseline As a baseline, a QDG that resolves to 6,000 users returns 6,000 records This categorizer will require 12 megabytes (MB) of random access memory (RAM) to expand the QDG The processor speed and amount of available physical memory will affect how long

it will take to deliver the e-mails after the expansion

Global catalog availability affects the expansion and delivery of e-mail sent

to Query Based Distribution Groups If all global catalog servers are

unavailable, the message will be placed in retry mode in the categorizer, which means that the complete expansion will start over after one hour The general recommendation is to break up large Query Based Distribution Groups into combinations of Query Based Distribution Groups and assign different

expansion servers for each large Query Based Distribution Group Consider one

of the following three options for designating and configuring expansion servers and global catalog servers for expanding distribution groups into individual recipients

Option 1

Consider designating an Exchange Server 2003 server with no mailboxes, such

as a public folder replica server or a bridgehead server, as the expansion server for a large Query Based Distribution Group Because this server has more bandwidth and resources to expand the Query Based Distribution Group, expansion and delivery is more efficient To maximize efficiency, configure the expansion server to use one or more global catalog servers that are not used by other Exchange servers in the organization You can configure this setting in

Exchange System Manager on the Directory Access tab of the server

properties

Option 2

Create a Query Based Distribution Group for every Exchange server and limit each Query Based Distribution Group to the mailboxes on that Exchange server Assigning this same server as the expansion server optimizes mail delivery

Option 3

The following example illustrates a third approach for improved handling of large Query Based Distribution Groups: Suppose you want to create a Query Based Distribution Group called “All employees” with 100,000 users Consider dividing the group into the following smaller Query Based Distribution Groups:

„ “All Temps” 10,000 users

„ “All Vendors” 5,000 users

„ “All FullTime” 65,000 users

„ “All Interns” 2,000 users

„ “All Contractors” 18,000 users

The QDG may then be added to a Universal Distribution Group

The difference between a QDG and a normal distribution group is the

mechanism used to select the members Let us explore a QDG using the popular directory tool “ldifde.exe.” We submit a query for the QDG and pipe the output to a log A QDG named “qdg” was added to the Users container in

AD and a custom filter to select users from a given storage group in a specific store

LDIF.LOG, below, is automatically generated by Lifde.exe

Microsoft Confidential

C:\>ldifde v d "cn=qdg,cn=users,DC=server,Dc=concsi,dc=lab" –f

"c:\qdg.log"

Connecting to "fe.concsi.lab"

Logging in as current user using SSPI

Exporting directory to file c:\qdg.log

Searching for entries

Writing out entries

Exporting entry: CN=qdg,CN=Users,DC=server,Dc=concsi,dc=lab

1 entries exported

The command has completed successfully

The text below details the sections of the file that apply to our discussion

CN=Default Global Address List,CN=All Global Address

Lists,CN=Address Lists Container,CN=First

Query Based Distribution works reliably in a NATIVE MODE Exchange 2000/2003 deployment where all Exchange 2000 servers are running Service Pack 3 and the AD uses Windows Server 2003 global catalog servers

If your global catalog servers are running Windows 2000 Server, you can modify a registry key on your Exchange 2000 SP3 servers to achieve greater reliability

Exchange 2000 SP3 server Registry Addition:

1 Start Registry Editor: Click Start, click Run, and then type RegEdit

2 Locate

HKLM\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

3 In the details pane, right-click, point to New, and then click DWORD

Value

4 Type DynamicDLPageSize for the name

5 Right-click DynamicDLPageSize, and then click Modify

6 Under Base, click Decimal, and then click OK

7 In Edit DWORD Value, under Value Data, type 31

Exchange 2003 automatically initializes a DynamicDLPageSize of 31 but the dword value is not exposed by default

Use ADSIedit to obtain the distinguished name of the QDG

Use ldifde to export the QDG and compare the results

Ldifde –v –f qdg.wri –d “cn=qdg,cn=users,dc=concsi,dc=lab Modify the filter to select all users in the organization on your server

Exercise 1:

1 Add a QDG to your organization using ADU&C

2 Configure the QDG to deliver to all users with Exchange mailboxes in your organization

3 Demonstrate a functional QDG by showing your instructor the preview

4 Use ldifde to dump the contents of the QDG

Recipient Filtering

The Exchange 2000 SMTP gateway, a SMTP virtual server, accepts mail for all recipients of domains specified via recipient policies While providing ease of configuration, this open framework can be and often is exploited by entities on the Internet to send unsolicited mail to users within an Exchange 2000

organization This type of mail is not only bothersome, but can disrupt internal process if the payload of the message is malicious or large for the capacity of their hardware Exchange Server 2003 addresses this problem with Recipient Filtering

Recipient Filtering is defined as the ability to block incoming mail by dropping the connection if the “Mail From:” or “RCPT TO:” protocol commands contain

a string that matches an administratively specified addresses Exchange Server

2003 implements recipient validation based on per recipient validation and list

of known recipients to be blocked; “RCPT TO:”

Administrators have the ability to deny anonymous send to specific SMTP addresses and deny anonymous send to any address not found in the directory The Recipient Filter rules apply to mail submitted by anonymous clients: other SMTP mailers

It is important to remember that Authenticated users and other Exchange servers within the organization bypass these validations

This feature is implemented as a standalone transport sink: the Turf List Transport Sink The functionality of this sink is the result of using the SMTP protocol event, “RCPT TO: and recipient validation based on directory query This functionality takes two forms:

1 Specific set of addresses: mail submitted to these addresses by an anonymous, unauthenticated, source is “turfed” despite their existence in the directory

Microsoft Confidential

2 All addresses in the directory: the “RCPT TO:” address must exist in the directory; if the LDAP query to the directory does not return an address match, the message is not delivered; it is “turfed”

When the SMTP interface receives a “RCPT TO:” request and the Turf List Transport Sink is enabled, the “RCPT TO:” data is compared to a list of

addresses based on the existing rule or rules A message sent to multiple recipients will be delivered to recipients based on the rule that applies to their SMTP proxy address

If and when an address in the “RCPT TO:” matches case 1 above, the SMTP protocol will issue error code “550 5.7.1 Requested action not taken: mailbox not available,” but the session is not aborted and mail destined for any

unrestricted recipient addresses will be accepted The RFC822 message headers are not modified and as a result, the recipient display name of a

mailbox subject to a Recipient Filter like case 1 will be displayed as a recipient

to clients that receive the mail

The second aspect, “Filter recipients who are not in the Directory”, addressed

by case 2 above, is the ability to turf mail to any address that does not resolve in the directory The sending client receives the error “550 5.5.1 user unknown”

To filter recipients not in the directory requires a directory lookup for each SMTP “RCPT TO:” command Positive matches are cached in DSaccess Message categorization also resolves each recipient in the directory so this will hit the DSaccess cache The net result is each recipient has always required a directory lookup, and as a result of utilizing the DSAccess cache, filtering recipients not in the directory adds little overhead

Enabling Recipient Filtering is a two step process The first configuration is on

the Recipient Filtering tab of the Message Delivery properties of the

organizations Global Settings menu in Exchange System Manager (ESM)

The location of Connection Filtering in ESM depicts the scope of the Recipient Filter rules

The acceptable inputs for the address of a Recipient Filter are defined below and are the same as those for Sender Filtering:

„ The only required element is a “@” for an SMTP entry

„ Display names can be input with quotes (“”) around the string

„ If adding an SMTP address with quotes, make sure the “@” appears

immediately after the quoted name

The second configuration is on the Identification tab of the Advanced options available through the General properties of the SMTP virtual server The

granularity of this feature mitigates any negative performance characteristics by allowing the administrator to enable this functionality on gateway servers directly adjacent to the internet

As with any feature that refuses the session, this feature has the side benefit of reducing system load and network traffic; the NDR process is the responsibility

of the mail system attempting to deliver the message to the Exchange Server 2003

The Recipient Filter for case 1 above uses msExchRecipTurfListNames

attribute of the Default Message Filter, msExchSMTPTurfList class, of the Message Delivery object (msExchMessageDeliveryConfig class) to determine the SMTP addresses that should be included in the filter settings The

following “ldifde” dump of the Default Message Filter object for domain concsi.lab shows that the filter will block users: auser@concsi.lab and

buser@concsi.lab from anonymous send This means the address will not get mail from clients that do not authenticate with the SMTP virtual server It is very important to remember that users who authenticate with the SMTP service can send to this user, if the server allows authenticated users to submit via the SMTP virtual server; typically POP and IMAP clients Each address is

represented by a unique attribute entry in the Default Message Filter Note that the entries appear with the last entry in ESM listed as the first attribute of the type

dn: CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=First Organization,CN=Microsoft

msExchRecipTurfListNames: buser@concsi.lab

msExchRecipTurfListNames: auser@concsi.lab

The Recipient Filter for case 2 above uses msExchRecipTurfListOptions attribute of the Default Message Filter, msExchSMTPTurfList class, of the Message Delivery object (msExchMessageDeliveryConfig class) to determine

if the address in the “RCPT TO:” should be compared against the directory and the send denied if the address does not exist in the directory

The following “ldifde” dump of the Default Message Filter object for domain

concsi.lab shows a value of 1 in the attribute msExchRecipTurfListOptions

This indicates Recipient Filtering “Filter recipients who are not in the

Directory” is enabled The attribute is an Integer type and is used as a bitmap; a value of “1” signifying “Enable DS Lookups”

dn: CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=First Organization,CN=Microsoft

Exchange,CN=Services,

CN=Configuration,Dc=concsi,dc=lab

objectClass: msExchSMTPTurfList

cn: Default Message Filter

name: Default Message Filter

objectCategory:

CN=msExchSMTPTurfList,CN=Schema,CN=Configuration,Dc=concsi,dc= lab

msExchRecipTurfListNames: auser@concsi.lab

msExchRecipTurfListOptions: 1

Microsoft Confidential

While the above define the attributes that actually contain the filter value set, filtering is enabled on a per SMTP virtual server basis The schema object for SMTP virtual server instance received a new attribute;

msExchServerBindingsFiltering

MsExchServerBindingsFiltering is a Multi-valued string type attribute The

string takes the form of IP:Port:GUID:Mask

IP = IP address of the binding

Port = the port assigned to the binding

GUID = the GUID of the Default Message Filter container MASK = “n”

“n” will correspond to one of the numeric values in the table below

Virtual server Port of 25

GUID of the Message Filter object in this directory 97ba73d49152ba429bbbeac1e4615d93

Bit 1 set to a value of “1” to enable Recipient

Filtering

It is important to remember the following details as they are not

documented in all references

„ The number of bindings is limited to 500 and will be enforced by ESM

Important

„ It is possible that an Exchange 2000 Administrator could be used to change the IP address or port for a binding This would orphan the configuration of the MsExchServerBindingsFiltering attribute, as the IP:Port combination would no longer match a real Server Binding To this end, ESM will delete and rewrite the contents of MsExchServerBindingsFiltering and

MsExchServerBindingsTurflist for any change

„ The Recipient Filter transport sink will be installed and registered on every server, but the functionality must be configured on a per virtual server basis; typically border or Internet facing SMTP servers

Add new user and add to the Recipient Filter List

Use Telnet from the Student workstation to send a message to the same user; do not authenticate

You will receive 550 5.7.1 Requested action not taken: mailbox not available

Solution: Use an authenticated Outlook Express account and send a message to the user

Student should understand the difference between anonymous and authenticated sessions

Exercise 1:

1 Add a new mailbox enabled user to the organization

2 Add the user to a recipient filter

3 Send to the user from Telnet

Record your result here …

4 Send mail from Outlook Express using an authenticated account

Record your result here …

5 Was there a difference between 3 and 4? If so, explain why

Distribution Group Restrictions

Exchange 2000 implemented delivery restrictions for a distribution group by checking that the sender resolved to an address in the directory That methodology is acceptable if there is no external access to the messaging system However, it does not ensure the sender’s authenticity This method of sender validation allows for others to impersonate a valid user by using their e-mail address; they use another address in the “From:” field of their message This is commonly known as “spoofing” and is most often encountered in mail originating from the Internet

Exchange Server 2003 addresses this problem by providing the ability to restrict submission to a distribution group using the standard Windows Discretionary Access Control List (DACL) This feature prevents non-trusted senders, such as anonymous Internet users, from sending mail to an internal only distribution list An example of this would be an “All Employees” distribution list which should not be available to anyone outside the company; especially via spoofing

Distribution group permissions are set through Active Directory Users and Computers

1 Click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers

2 Expand your organizational unit container, and double-click Users

3 Right-click the distribution list for which you want to restrict submissions,

and then click Properties

4 Click the Exchange General tab

Microsoft Confidential

5 Under Message Restrictions, under Accept messages select one of the

following options:

• Click From authenticated users only to allow only authenticated users

to send mail to this distribution list

• Click From everyone to allow anyone to send to this distribution list

This includes anonymous users from the Internet

• Click Only from to specify a select set of users or groups that can send

to this group, and then click Add to specify the users or groups that you

want to permit to send mail to this distribution list

• Click From everyone except to allow everyone but a select set of users

or groups to send to this distribution group, and then click Add to

specify the list of users or groups that you want to restrict from sending

to this distribution list

Query Based Distribution Groups may be used for restrictions on other

Distribution Groups: Global and Universal Detailed instructions concerning the expected behavior and limitations for Domain Local and Global

Distribution Groups can be found in the Exchange 2003 online help

Remember, the contents of Domain Local and Global Groups are not replicated

to Global Catalog servers in other domains

The values for the DACL are stored in the attribute of the distribution group If the attribute does not exist, the authentication behavior and delivery is the same

as Exchange 2000 Alternately in Exchange Server 2003, if the attribute is set, the validation mechanism changes to ensure the sending user has authenticated with the system and meets the criterion of the DACL for sending to the

to a legacy server via SMTP; including Exchange 2000 This feature requires that the border or gateway servers must be Exchange Server 2003 and the communication to the mailbox servers must not pass through a legacy

Exchange SMTP transport

The transport performs a security check to ascertain if the connection was authenticated If the connection was authenticated, the transport retains the modified “Mail From:” “AUTH=” data and sets a new property, a flag, on message which indicates the sender is trusted This flag is retained when the message is passed between servers that advertise XEXPS via the AUTH= on the mail from This new message flag is set from messages originating from the store, as well making all messages that originate from Exchange Server 2003 mailbox servers authenticated

The final evaluation occurs in categorization where one of the following actions takes place as a result of the evaluation of the sender authentication and

distribution group restriction configuration pair

The message will be delivered if the attribute is not set or the user is

authenticated (by the by directory) and authorized (by the DACL on the distribution group)

If the attribute msExchRequireAuthToSendTo is set, the message is turfed

• If the user is NOT authenticated

• If the user is authenticated AND NOT authorized

Delivery restrictions are selected on the Exchange General tab of the

distribution group The default is “From everyone.” There are three other choices available: “From authenticated users, Only from: and From everyone except” Only one of the options may be selected

If the administrator chooses “From authenticated users”, a single attribute is

added to the properties of the distribution group Note the bold italic entry at

the end of the ldifde dump of the distribution group with this filter

dn: CN=Global Distribution

Group,CN=Users,DC=server,Dc=concsi,dc=lab

cn: Global Distribution Group

displayName: Global Distribution Group

mail: GlobalDistributionGroup@concsi.lab

msExchRequireAuthToSendTo: TRUE

If the administrator chooses “Only from:” a single attribute is added to the

properties of the distribution group Note the bold italic entry at the beginning

of the ldifde dump of the distribution group with this filter It will be set to the appropriate value for the given configuration

dn: CN=Global Distribution

Group,CN=Users,DC=server,Dc=concsi,dc=lab

authOrig:

CN=Administrator,CN=Users,DC=server,Dc=concsi,dc=lab

cn: Global Distribution Group

displayName: Global Distribution Group

mail: GlobalDistributionGroup@concsi.lab

msExchRequireAuthToSendTo: FALSE

If the administrator chooses “From everyone except” a single attribute is added

to the properties of the distribution group Note the bold italic entry at the

beginning of the ldifde dump of the distribution group with this filter It is important to note that after an attribute is added to a distribution group or any other directory object, for that matter, it will not be deleted It will be set to the appropriate value for the given configuration

dn: CN=Global Distribution

Group,CN=Users,DC=server,Dc=concsi,dc=lab

unauthOrig:

CN=Administrator,CN=Users,DC=server,Dc=concsi,dc=lab

cn: Global Distribution Group

displayName: Global Distribution Group

mail: GlobalDistributionGroup@concsi.lab

msExchRequireAuthToSendTo: FALSE