Programming4us
         
 
 
Applications Server

Message Routing in Exchange 2010 (part 4) - Planning and Configuring Your SMTP Namespace

10/24/2010 3:31:05 PM

4. Planning and Configuring Your SMTP Namespace

Another important aspect is to plan and configure an SMTP namespace. The SMTP message protocol is the internal message protocol of Exchange 2010. Thus, you identify an Exchange organization by its primary SMTP namespace.

The SMTP namespace is configured in the Internet using one DNS MX record per SMTP domain that points to your Exchange organization. You need to make sure Exchange understands what to do with the SMTP namespaces that enter your Exchange organization.

4.1. Accepted Domains

The accepted domain property specifies one or more SMTP domain names for which the Exchange server receives mail. If an SMTP Receive connector on the Exchange Server 2010 Hub Transport server receives a message that is addressed to a domain that is not on the accepted domain list, it rejects the message and sends a relaying denied response.

When you create a new accepted domain, you have three options for the domain type you can create:

  • Authoritative Domain Select this option if every e-mail addresses for this domain name exists in Active Directory (as mailbox, contact, and so on). If a message is received that has a recipient e-mail address that is not in the Active Directory, an NDR will be created for that message. The Contoso scenario, where you only use Exchange as the messaging system, is an example where you define all domains as authoritative.

  • Internal Relay Domain This option is to configure a shared address space with one or more messaging systems. If the e-mail address does not exist in your Active Directory, Exchange will forward the message using a Send connector. You need at least one Send connector with the internal relay domain configured as address space so that the Hub Transport servers will send the message that are not found in your Exchange organization to the correct target SMTP server. For example, you would use this option during a migration in which your legacy messaging system and your new messaging system share the same e-mail addresses.

  • External Relay Domain Select this option to relay messages to an SMTP server outside of the Exchange organization or the organization's network. An Edge Transport server is responsible for routing the messages received to the target SMTP server. Your organization is therefore responsible for the DNS MX record of this company and forwards every message received to the target server. It requires a Send connector from the Edge Transport servers to the external relay domain's SMTP server that includes the external relay domain as address space.


Note: To configure accepted domains using the Exchange Management Shell, use the New-AcceptedDomain or Set-AcceptedDomain cmdlets. This allows you to easily create or modify many domains with a single operation.
4.2. Remote Domains

Remote domains define SMTP domains that are external to your Exchange organization. You can create remote domain entries to define the settings for message transfer between the Exchange Server 2010 organization and domains outside your AD DS forest.

When you create a remote domain entry, you control the types of messages that are sent to that domain. You can apply message-format policies and acceptable character sets for the messages that are sent from your organization's users to the remote domain as well as determine out-of-office message settings.

4.2.1. Out-of-Office Message Settings

The out-of-office message settings control the messages that are sent to recipients in the remote domain. The types of out-of-office messages that are available in your organization depend on both the Microsoft Office Outlook client version and the Exchange Server version on which the user's mailbox is located.

An out-of-office message is set on the Outlook client but is sent by the Exchange server. Exchange Server 2010 supports three out-of-office message classifications: external, internal, and legacy, as shown in Figure 7.

Figure 7. Out-of-office settings for remote domains


4.2.2. Message Format Options Including Acceptable Character Sets

You can configure multiple message format options to specify message delivery and formatting policies for the messages that are sent to recipients in the remote domain. The first set of options on the Message Format tab apply restrictions to the types of messages that can be sent to the remote domain, how the sender's name displays to the recipient, and the column width for message text. These options include:

  • Allow automatic replies.

  • Allow automatic forward.

  • Allow delivery reports.

  • Allow non-delivery reports.

  • Display sender's name on messages.

  • Use message text line-wrap at column.

4.2.3. Exchange Rich Text Format Settings

Use the Exchange rich-text format settings to determine whether e-mail messages from your organization to the remote domain are sent by using Exchange Rich Text Format (RTF). Remember that the Microsoft RTF format is not automatically supported by every LINUX or UNIX SMTP server; thus if the recipients of messages from your organization complain about weird attachments or missing attachments, you should try to disable RTF for that domain.

4.2.4. Character Sets

The Characters Sets options let you select a MIME character set and a non-MIME character set to use when you send messages to a remote domain.

5. TargetAddress Routing

Another way to modify message routing is to add a SMTP address to the TargetAddress attribute of a mail-enabled user account object or a contact object. After the attribute is added, the object is available in the Global Address List (GAL) and also can be addressed by using its primary SMTP address. Messages sent to the object will be automatically forwarded to the SMTP address defined in TargetAddress.

The first time I used this technology was back in the old Exchange 5.5 days, with an Exchange migration product called Quest Exchange Migration Wizard. This tool created one contact for every mailbox and used the TargetAddress attribute to forward messages to the target environment.

The TargetAddress attribute is defined on a per-object level; thus you can define which objects are redirected and which are not. You should consider the following if you're planning to use TargetAddress routing in your environment:

  • You need to configure a Send connector that includes the target domain as address space.

  • To share one address space, create an Internal Relay Domain for it. The internal relay domain should be the primary SMTP address of the objects. This is required to have users in both messaging systems (source and target) be able to address the contacts or mailboxes in both system by using their primary SMTP address.

  • You need to create one contact or mail-enabled user account per e-mail address to be capable of forwarding it. The TargetAddress attribute will include a dedicated SMTP address for the target messaging system.


Note: Remember that as soon as you mailbox-enable a user account, the TargetAddress attribute will be removed and any message forwarding will be stopped.
Other -----------------
- Exchange 2010 : Understanding Transport Agents
- Exchange Transport Server Architecture (part 2)
- Exchange Transport Server Architecture (part 1)
- Client Access Server Architecture in Exchange 2010 (part 4)
- Client Access Server Architecture in Exchange 2010 (part 3)
- Client Access Server Architecture in Exchange 2010 (part 2)
- Client Access Server Architecture in Exchange 2010 (part 1) - Client Access Server Architecture
- Exchange Server 2010 Mailbox Services Configuration (part 5) - Configuring Public Folders
- Exchange Server 2010 Mailbox Services Configuration (part 4) - Client Configuration
- Exchange Server 2010 Mailbox Services Configuration (part 3)
- Exchange Server 2010 Mailbox Services Configuration (part 2) - Database Maintenance
- Exchange Server 2010 Mailbox Services Configuration (part 1)
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- Use the Exchange 2007 Toolbox to Troubleshoot
 
 
Most View
- Windows 7 : Adding Folders and Files to the Default Website (part 1) - Setting Permissions on the Default Website Folder
- Working with Search Page Layouts : Modify the Search Results Presentation (part 2)
- Build Mobile Websites and Apps for Smart Devices : Design for Mobile - Build a Better Mouse
- iOS SDK : Debugging (part 3) - NSZombieEnabled
- An OLAP Requirements Example: CompSales International (part 11)
- Windows Server 2012 : Backup and Recovery (part 4) - Backing up and recovering your data - Scheduling backups
- Exchange Server 2010 : Federation Scenarios (part 3) - Federating with Online Services
- Windows Server 2008 : Promote Servers as Domain Controllers
- Performing On-Demand Exchange Server 2003 Monitoring and Maintenance
- SharePoint 2010 : Authoring Pages - Create a New Page (part 2)
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS