Exxhange SQL And IIS- P75 pdf

Confi guring Outbound Message LimitsYou can confi gure how the Hub Transport server should process outbound messages.. Receive Connectors A Receive connector represents an inbound connec

Figure 6.25 Specifying the Source Server

TIP

To create a Send connector via the Exchange Management Shell, you must use the

New-SendConnector cmdlet For example, to create a Send Connector similar to the

one we generated in the previous steps, run the following command:

New-SendConnector –Name ‘To ISP (Smart host)’ –Usage ‘Internet’ –AddressSpaces

‘smtp:*.exchangehosting.dk;1’ –DNSRoutingEnabled $true –UseExternalDNSServersEna bled $false –SourceTransportServers ‘EDFS03’

8 On the Confi guration Summary page, make sure you confi gured the connector as

required, and then click Next.

9 On the Completion page, click Finish.

When you have created a Send connector, you can disable, enable, modify, and remove it by selecting the respective Send connector, and then choosing the required tasks in the Action pane

Confi guring DNS Lookups

You can confi gure a Hub Transport server to use different settings for external and internal DNS

lookups Click the Properties of your Hub Transport server under the Server Confi guration | Hub

Transport work center node On the External DNS Lookups tab shown in Figure 6.26, specify that

DNS server(s) should be used to resolve IP addresses of servers outside your organization As you can see, you have the option of using the DNS settings confi gured for one of the network cards in the server, or by specifying the IP address of the DNS server(s) directly You have the exact same options available under the Internal DNS Lookups tab The only difference is that under this tab you specify the DNS server(s) that should be used to resolve IP addresses of servers inside your organization

Figure 6.26 Confi guring External DNS Lookups

Confi guring Outbound Message Limits

You can confi gure how the Hub Transport server should process outbound messages This is done by opening the Property page of the respective Hub Transport server object in the Result pane Here, you

click the Limits tab As you can see in Figure 6.27, you have the option of setting the retry interval—

in other words, how often the Hub Transport server should try to resend an outbound message to a

destination server, which for some SMTP servers don’t accept the message the fi rst time it’s sent

Figure 6.27 Confi guring Outbound Message Limits

Under Message expiration, we can specify the amount of days a message held locally in a

message queue as undeliverable should expire As you can see, the default setting is 2 days, wherein

the message will be removed from the message queue and a non-delivery report (NDR) will be sent

to the sender of the message

In addition, we can specify after how many hours a non-deliver report (NDR) should be generated and delivered to the sender of the message By default, the sender will be notifi ed every fourth hour Finally, we can confi gure connection restrictions for concurrent outbound connections and concurrent outbound connections per domain Unless you’re dealing with a very large organization, you should leave the connection restrictions at their defaults

Typically, the default settings should be suffi cient for most organizations, but if you’re in a situation where you need to adjust them a little, this is the place to do it

Receive Connectors

A Receive connector represents an inbound connection point for SMTP, and controls how a Hub

Transport server receives messages over SMTP No Receive connector, no inbound mail This means that in order for a Hub Transport server to receive messages from the Internet (from e-mail clients as well as other e-mail servers), at least one Receive connector is required

When you install the Hub Transport server role on a server, two Receive connectors are created

by default A Client <servername> and a Default <servername> receive connector, as shown in Figure 6.28 These two connectors are required in order for internal mail fl ow to work

Figure 6.28 Default Receive Connectors

A Receive connector only listens for connections that match the settings confi gured on the

respective connector That is, connections that are received through a specifi c local IP address and

port, and from a particular IP address range Receive connectors are local to the Hub Transport server

on which they’re created This means that a receive connector created on one Hub Transport server

cannot be used by another Hub Transport server in the organization So, by creating Receive connectors, you can control which server should receive messages from a particular IP address or IP address range

In addition, you can create custom connector properties for messages arriving from a particular IP

address or IP address range You could, for example, allow larger message sizes, more recipients per

message (both of these will be covered later in this chapter) or perhaps more inbound connections

Creating a Receive Connector

To create a Receive connector, you must perform the following steps:

1 Open the Exchange Management Console and select Hub Transport under the

Server Confi guration work center node (shown back in Figure 6.28)

2 In the Result pane, select the Hub Transport server on which you want to create the

Receive connector

3 Now click New Receive Connector in the Action pane

4 The New SMTP Receive Connector wizard will appear Type a descriptive name for the

connector, and select the type of connector you want to create As can be seen in Figure 6.29, you can select between fi ve different Receive connector types:

■ Custom This option is used to create customized Receive connectors, which are

used to connect with systems that are not Exchange servers

NOTE

By default, a Hub Transport server only accepts inbound messages from other

Transport servers (that is, Hub Transport and Edge Transport servers) that are part of the Exchange organization, authenticated Exchange users, and internal legacy

Exchange servers (Exchange 2000 and 2003) This means that e-mail servers that are external to the organization by default cannot deliver messages to a Hub Transport server The reason behind this decision is to make Hub Transport servers secure out of the box by default “But isn’t it a little too aggressive to not allow inbound messages from the Internet?” I hear some of you grumble Well, perhaps it is, but since the

Exchange Product group is convinced that all organizations around the globe will

deploy an Edge Transport server in their perimeter networks, the Exchange Product Group doesn’t see this as an issue at all Luckily, it’s a rather painless process to allow untrusted e-mail servers (that is, e-mail servers not part of the Exchange organization except the Edge Transport server) to deliver messages directly to a Hub Transport

server I’ll show you how in the section titled “Confi guring the Hub Transport Server

as an Internet-Facing SMTP Server” later in this chapter