If you missed the previous article in this series please read Managing Receive Connectors (Part 1).
If you would like to be notified when Anderson Patricio releases the next article in this series please sign up to the MSExchange.org Real Time Article Update Newsletter.
In the last article we created a Receive Connector to receive mail coming from the Internet, and we also tested it using the telnet utility.
In order to test a receive connector we have to be aware of the basic SMTP verbs to send a message using a telnet session. These following commands will enable you to send a test message using the telnet utility. All the basic SMTP verbs required to send a message are below:
- The receive connectors that we have just created is listening on port 25 and on a specific IP address. Let’s use the telnet utility to connect in our server:
telnet <IP> 25
Expected result: 220 <FQDN name> Banner information - Start the SMTP communication.
EHLO example.org
Expected result: a list of all SMTP verbs that are accepted by the receive connector. In the first line a hello answer with the IP Address used by the sender will be shown. -
Define the sender of the test message.
Mail from:[email protected]
Expected result: 250 2.1.0 Sender OK
-
Define the recipient of this test message. The SMTP domain used by the recipient must exist in the current organization.
Rcpt to:user@<your-domain>
Expected result: 250 2.1.5 Recipient OK
-
Start the test message.
Data <enter>
Expected result: 354 Start mail input; end with <CRLF>.<CRLF>
-
Hit the<enter> key twice and type in the content that will appear in the body of the test message. To finish type a period “.” in a blank line and hit <Enter>.
This is a test message. <enter>
. <enter>
Expected result: 250 2.6.0 <Message [email protected]> Queued mail for delivery
-
Closing the session.
Quit
Expected result: 221 2.0.0 Service closing transmission channel
We can log on to OWA to check if the message was received. The entire process can be seen in Figure 01.
Figure 01
Knowing this process is important to troubleshooting mail flow and to validate a Receive Connector as well.
Playing with Receive Connector security features…
Now that we have just configured a Receive Connector using both the Exchange Management Console and Exchange Management Shell we can start playing with some security configurations for our Receive Connectors. All the security that we are going to see here is modified by the Receive Connector and they must be configured using the Exchange Management Shell. Let’s configure some features in our new Internet Receive Connector, as follows:
Changing Banner information…
Some companies do not like the idea of displaying the server name in SMTP connections. We can change the banner information used by a Receive Connector using the cmdlet below and the result will be shown in Figure 02.
Set-ReceiveConnector <connector-name> -Banner “220 Mail Server”
Figure 02
If you still have Exchange Server 2003/2000 and you want to change this behavior you can use the following Microsoft KB Article: How to change the default connection response that you receive after you connect to the SMTP port in Exchange 2003.
Specifying a number of errors during a session…
We can control the number of protocol errors in a single session. The default value is 5, to configure it to 2 we can use the following cmdlet:
Set-ReceiveConnector <Connector Name> -MaxProtocolErrors 2
Now if an SMTP Server/user connects and reaches the maximum number of errors defined in the receive connector the following message will be shown (Figure 03):
Figure 03
Throttling a Receive Connector…
Receive connectors allow us to restrict inbound traffic to prevent high usage from a determined source, preventing an unnecessary overload of the system. Here are the three options that we have:
- MaxInboundConnectionsperSource: Defines the maximum number of connections made in the receive connector at the same time by the same source. This default value of this setting is 100.
- MaxInboundConnection: Defines how many connections the receive connector will accept at the same time. The default value of this setting is 5000.
- MaxInboundConnectionPercentagePersource: Based on the MaxInboundConnection value it indicates how many connections the same source can establish with the receive connector. The default value is 2%.
To configure the Receive Connector using the new settings that we have just seen, we can run the following cmdlet:
Set-ReceiveConnector <Connector-Name> -MaxInboundConnection <Number> -MaxInboundConnectionsperSource <Number> -MaxInboundConnectionPercentagePerSource <Number>
We can also configure time-out in a receive connector in certain aspects, such as: during SMTP communication and also during an inactive connection .To configure the ConnectionTimeout we can run this following cmdlet:
Set-ReceiveConnector <Connector-Name> -ConnectionTimeout <days.hours:minutes:seconds>
To disconnect due to Inactive time, we can use the cmdlet below:
Set-ReceiveConnector <Connector-Name> -ConnectionInactiveTimeout <days.hours:minutes:seconds>
We can also restrict the number of recipients, Rate Limit and Max message size at connector level, to configure these settings we can use the following parameters:
- MaxRecipientsPerMessage: The maximum number of recipients in a single message, the default value is 200.
- MaxMessageSize: The maximum size of a message; the default value is 10MB.
- MaxRateLimit: This specifies the maximum number of messages that can be sent by the same client per minute.
Let’s change our Internet Receive connector to accept 100 users maximum, the message size should be more than 2MB and the rate limit is 200, as follows:
Set-ReceiveConnector<Connector Name> –MaxRecipientsPerMessage:100 –MaxMessageSize:5MB –MaxRateLimit:200
The last feature we will cover in this article is the TarpitIntervall. In Exchange Server 2003 we have to configure it through the Registry Editor (http://support.microsoft.com/kb/842851). In Exchange Server 2007 we can do that using the Exchange Management Shell. The tarpit feature inserts a pre-defined delay in each SMTP response that contains the 5.x.x error code during the SMTP communication between servers. The tarpit feature is only applied to anonymous connections and it should be used with the Recipient Filter Agent and Recipient Lookup features enabled.
In this article we are using a single Exchange Server 2007 box with all three main roles installed (Mailbox, CAS and Hub Transport) and it is receiving messages from the Internet, we also configured the Anti-spam agents on that box (we can validate how to configure a single Exchange Server to receive internet messages and anti-spam features in this article: Configuring Mail Flow in a Single Exchange Server 2007). Let’s look at the Recipient Filtering agent and enable the Recipient Lookup feature:
- Open the Exchange Management Console.
- Expand Organization Configuration.
- Click on Hub Transport.
- Click the Anti-Spam Tab.
- Double click Recipient Filtering.
- Click the Blocked Recipients tab.
- Check the first option “Block messages sent to recipients not listed in the Global Address list” (Figure 04).
Figure 04
Okay, from now on all messages addressed to unknown address in our organization will be refused by the Exchange Server, as shown in the first rcpt to: SMTP verb in Figure 05. However we might encounter a problem where a spammer can try a harvest attack against our Exchange Server using a dictionary attack to find out which e-mails are valid in your organization. So, how can we stop it? There is no way to stop it but for each wrong address tried in the SMTP communication a “5.1.1 User unknown” error is displayed and for each of these errors we can configure tarpit to delay the server response.
Figure 05
The default value is 5 seconds, to change this configuration we can run the following cmdlet:
Set-ReceiveConnector “<Connector-Name>” –TarPitInterval:<Number of seconds>
Conclusion
In this article we have gone over how to configure some security settings and limits in a Receive Connector. We also saw that the some configuration must be done using the Exchange Management Shell. In the next article we are going to play with logging information and start playing with authentication methods and how to configure permissions using AdsiEdit.msc and the Exchange Management Shell.
If you missed the previous article in this series please read Managing Receive Connectors (Part 1).
If you would like to be notified when Anderson Patricio releases the next article in this series please sign up to the MSExchange.org Real Time Article Update Newsletter.
