Topic Last Modified: 2011-04-28 This topic provides information about ports, authentication, and encryption for all data paths used by Microsoft Exchange Server 2010. The Notes sections following each table clarify or define non-standard authentication or encryption methods. Transport Servers Exchange 2010 includes two server roles that perform message transport functionality: Hub Transport server and Edge Transport server. The following table provides information about ports, authentication, and encryption for data paths between these transport servers and other Exchange 2010 servers and services. Transport server data paths Data path Required ports Default authentication Supported authentication Encryptio n supported ? Encrypte d by default? Hub Transport server to Hub Transport server 25/TCP (SMTP) Kerberos Kerberos Yes, using Transport Layer Security (TLS) Yes Hub Transport server to Edge Transport server 25/TCP (SMTP) Direct trust Direct trust Yes, using TLS Yes Edge Transport server to Hub Transport server 25/TCP (SMTP) Direct trust Direct trust Yes, using TLS Yes Edge Transport server to Edge Transport server 25/TCP SMTP Anonymous, Certificate Anonymous, Certificate Yes, using TLS Yes Mailbox server to Hub Transport server via the Microsoft Exchan ge Mail Submission Service 135/TCP (RPC) NTLM. If the Hub Transport and the Mailbox server roles are on the same server, Kerberos is NTLM/Kerber os Yes, using RPC encryption Yes used. Hub Transport to Mailbox server via MAPI 135/TCP (RPC) NTLM. If the Hub Transport and the Mailbox server roles are on the same server, Kerberos is used. NTLM/Kerber os Yes, using RPC encryption Yes Unified Messaging server to Hub Transport server 25/TCP (SMTP) Kerberos Kerberos Yes, using TLS Yes Microsoft Exchan ge EdgeSync service from Hub Transport server to Edge Transport server 50636/TCP (SSL) Basic Basic Yes, using LDAP over SSL (LDAPS) Yes Active Directory access from Hub Transport server 389/TCP/UDP (LDAP ), 3268/TCP (LDAP GC) , 88/TCP/UDP (Kerbero s), 53/TCP/UDP (DNS), 135/TCP (RPC netlogo n) Kerberos Kerberos Yes, using Kerberos encryption Yes Active Directory Rights Management Services (AD RMS) access from Hub Transport server 443/TCP (HTTPS) NTLM/Kerber os NTLM/Kerber os Yes, using SSL Yes* SMTP clients to Hub Transport server (for example, end- users using Windows Live Mail) 587 (SMTP) 25/TCP (SMTP) NTLM/Kerber os NTLM/Kerber os Yes, using TLS Yes Notes on Transport Servers All traffic between Hub Transport servers is encrypted by using TLS with self-signed certificates that are installed by Exchange 2010 Setup. Note: In Exchange 2010, TLS can be disabled on Hub Transport servers for internal SMTP communication with other Hub Transport servers in the same Exchange organization. We don't recommend doing this unless absolutely required. For more information, see Disabling TLS Between Active Directory Sites to Support WAN Optimization. All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Mutual TLS is the underlying mechanism for authentication and encryption. Instead of using X.509 validation, Exchange 2010 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) acts as validation for the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority (CA). When you subscribe an Edge Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates AD LDS with the set of Hub Transport server certificates for the Edge Transport server to validate. EdgeSync uses a secure LDAP connection from the Hub Transport server to subscribed Edge Transport servers over TCP 50636. AD LDS also listens on TCP 50389. Connections to this port don't use SSL. You can use LDAP utilities to connect to the port and check AD LDS data. By default, traffic between Edge Transport servers in two different organizations is encrypted. Exchange 2010 Setup creates a self-signed certificate, and TLS is enabled by default. This allows any sending system to encrypt the inbound SMTP session to Exchange. By default, Exchange 2010 also tries TLS for all remote connections. Authentication methods for traffic between Hub Transport servers and Mailbox servers differ when the Hub Transport server roles and Mailbox server roles are installed on the same computer. When mail submission is local, Kerberos authentication is used. When mail submission is remote, NTLM authentication is used. Exchange 2010 also supports Domain Security. Domain Security refers to the functionality in Exchange 2010 and Microsoft Outlook 2010 that provides a low-cost alternative to S/MIME or other message-level over-the-Internet, security solutions. Domain Security provides you with a way to manage secure message paths between domains over the Internet. After these secure message paths are configured, messages that have successfully traveled over the secure path from an authenticated sender are displayed to Outlook and Outlook Web Access users as "Domain Secured". For more information, see Understanding Domain Security. Many agents can run on Hub Transport servers and Edge Transport servers. Generally, anti-spam agents rely on information that's local to the computer on which the agents run. Therefore, little communication with remote computers is required. Recipient filtering is the exception. Recipient filtering requires calls to either AD LDS or Active Directory. As a best practice, run recipient filtering on the Edge Transport server. In this case, the AD LDS directory is on the same computer as the Edge Transport server and no remote communication is required. When recipient filtering has been installed and configured on the Hub Transport server, recipient filtering accesses Active Directory. The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2010. This agent also makes various connections to outside proxy servers to determine inbound message paths for suspect connections. All other anti-spam functionality uses data gathered, stored, and accessed only on the local computer. Frequently, the data, such as safelist aggregation or recipient data for recipient filtering, is pushed to the local AD LDS directory by using the Microsoft Exchange EdgeSync service. Information Rights Management (IRM) agents on Hub Transport servers make connections to Active Directory Rights Management Services (AD RMS) servers in the organization. AD RMS is a Web service that's secured by using SSL as a best practice. Communication with AD RMS servers occurs by using HTTPS, and Kerberos or NTLM is used for authentication, depending on the AD RMS server configuration. Journal rules, transport rules, and message classifications are stored in Active Directory and accessed by the Journaling agent and the Transport Rules agent on Hub Transport servers. Mailbox Servers Whether NTLM or Kerberos authentication is used for Mailbox servers depends on the user or process context that the Exchange Business Logic layer consumer is running under. In this context, the consumer is any application or process that uses the Exchange Business Logic layer. As a result, many entries in the Default Authentication column of the Mailbox server data paths table are listed as NTLM/Kerberos. The Exchange Business Logic layer is used to access and communicate with the Exchange store. The Exchange Business Logic layer is also called from the Exchange store to communicate with external applications and processes. If the Exchange Business Logic layer consumer is running as Local System, the authentication method is always Kerberos from the consumer to the Exchange store. Kerberos is used because the consumer must be authenticated by using the Local System computer account, and a two-way authenticated trust must exist. If the Exchange Business Logic layer consumer isn't running as Local System, the authentication method is NTLM. For example, NTLM is used when you run an Exchange Management Shell cmdlet that uses the Exchange Business Logic layer. The RPC traffic is always encrypted. The following table provides information about ports, authentication, and encryption for data paths to and from Mailbox servers. Mailbox server data paths Data path Required ports Default authentication Supported authentication Encryptio n supported ? Encrypte d by default? Active Directory access 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos) , 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Yes, using Kerberos encryption Yes Admin remote access (Remote Registry) 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using IPsec No Admin remote access (SMB/File) 445/TCP (SMB) NTLM/Kerbero s NTLM/Kerbero s Yes, using IPsec No Availabilit y Web service (Client Access to Mailbox) 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using RPC encryption Yes Clustering 135/TCP (RPC) See Notes on Mailbox Servers after this table. NTLM/Kerbero s NTLM/Kerbero s Yes, using IPsec No Content indexing 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using RPC encryption Yes Log shipping 64327 (customizable) NTLM/Kerbero s NTLM/Kerbero s Yes No Seeding 64327 (customizable) NTLM/Kerbero s NTLM/Kerbero s Yes No Volume shadow copy service (VSS) backup Local Message Block (SMB) NTLM/Kerbero s NTLM/Kerbero s No No Mailbox Assistants 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s No No MAPI access 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using RPC Yes encryption Microsoft Exchange Active Directory Topology service access 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using RPC encryption Yes Microsoft Exchange System Attendant service legacy access (Listen to requests) 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s No No Microsoft Exchange System Attendant service legacy access to Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos) , 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Yes, using Kerberos encryption Yes Microsoft Exchange System Attendant service legacy access (As MAPI client) 135/TCP (RPC) NTLM/Kerbero s NTLM/Kerbero s Yes, using RPC encryption Yes Offline address book (OAB) accessing Active Directory 135/TCP (RPC) Kerberos Kerberos Yes, using RPC encryption Yes Recipient Update Service 135/TCP (RPC) Kerberos Kerberos Yes, using RPC encryption Yes RPC access Recipient update to Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos) , 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Yes, using Kerberos encryption Yes Notes on Mailbox Servers The Clustering data path listed in the preceding table uses dynamic RPC over TCP to communicate cluster status and activity between the different cluster nodes. The Cluster service (ClusSvc.exe) also uses UDP/3343 and randomly allocated high TCP ports to communicate between cluster nodes. For intra-node communications, cluster nodes communicate over User Datagram Protocol (UDP) port 3343. Each node in the cluster periodically exchanges sequenced, unicast UDP datagrams with every other node in the cluster. The purpose of this exchange is to determine whether all nodes are running correctly and to monitor the health of network links. Port 64327/TCP is the default port used for log shipping. Administrators can specify a different port for log shipping. For HTTP authentication where Negotiate is listed, Kerberos is tried first, and then NTLM. Client Access Servers Unless noted, client access technologies, such as Outlook Web App, POP3, or IMAP4, are described by the authentication and encryption from the client application to the Client Access server. The following table provides information about port, authentication, and encryption for data paths between Client Access servers and other servers and clients. Client Access server data paths Data path Required ports Default authentication Supported authentication Encryptio n supported ? Encrypte d by default? Active Directory access 389/TCP/UDP (LDAP) , 3268/TCP (LDAP GC) , 88/TCP/UDP (Kerbero s), 53/TCP/UDP (DNS), 135/TCP (RPC netlogo Kerberos Kerberos Yes, using Kerberos encryption Yes n) Autodiscover service 80/TCP, 443/TCP (SSL) Basic/Integrate d Windows authentication (Negotiate) Basic, Digest, NTLM, Negotiate (Kerberos) Yes, using HTTPS Yes Availability service 80/TCP, 443/TCP (SSL) NTLM/Kerber os NTLM, Kerberos Yes, using HTTPS Yes Outlook accessing OAB 80/TCP, 443/TCP (SSL) NTLM/Kerber os NTLM/Kerber os Yes, using HTTPS No Outlook Web App 80/TCP, 443/TCP (SSL) Forms Based Authentication Basic, Digest, Forms Based Authentication, NTLM (v2 only), Kerberos, Certificate Yes, using HTTPS Yes, using a self- signed certificate POP3 110/TCP (TLS), 995/TCP (SSL) Basic, Kerberos Basic, Kerberos Yes, using SSL, TLS Yes IMAP4 143/TCP (TLS), 993/TCP (SSL) Basic, Kerberos Basic, Kerberos Yes, using SSL, TLS Yes Outlook Anywhe re (formerly known as RPC over HTTP ) 80/TCP, 443/TCP (SSL) Basic Basic or NTLM Yes, using HTTPS Yes Exchange ActiveSync application 80/TCP, 443/TCP (SSL) Basic Basic, Certificate Yes, using HTTPS Yes Client Access server to Unified Messaging server 5060/TCP, 5061/TCP, 5062/TCP, a dynamic port By IP address By IP address Yes, using Session Initiation Protocol (SIP) over TLS Yes Client Access server to a Mailbox server that is running an earlier version of Exchange Server 80/TCP, 443/TCP (SSL) NTLM/Kerber os Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text Yes, using IPsec No Client Access server to Exchange 2010 RPC. See Notes on Client Access Servers. Kerberos NTLM/Kerber os Yes, using RPC encryption Yes Mailbox server Client Access server to Client Access server (Exchange ActiveSync) 80/TCP, 443/TCP (SSL) Kerberos Kerberos, Certificate Yes, using HTTPS Yes, using a self- signed certificate Client Access server to Client Access server (Outlook Web Access) 80/TCP, 443/TCP (HTTPS) Kerberos Kerberos Yes, using SSL Yes Client Access server to Client Access server (Exchange Web Services) 443/TCP (HTTPS) Kerberos Kerberos Yes, using SSL Yes Client Access server to Client Access server (POP3) 995 (SSL) Basic Basic Yes, using SSL Yes Client Access server to Client Access server (IMAP4) 993 (SSL) Basic Basic Yes, using SSL Yes Office Communications Server access to Client Access server (when Office Communications Server and Outlook Web App integration is enabled) 5075-5077/TCP (IN), 5061/TCP (OUT) mTLS (Required) mTLS (Required) Yes, using SSL Yes Note: Integrated Windows authentication (NTLM) isn't supported for POP3 or IMAP4 client connectivity. For more information, see the "Client Access Features" sections in Discontinued Features. Notes on Client Access Servers In Exchange 2010, MAPI clients such as Microsoft Outlook connect to Client Access servers. The Client Access servers use many ports to communicate with Mailbox servers. With some exceptions, those ports are determined by the RPC service and aren't fixed. For HTTP authentication where Negotiate is listed, Kerberos is tried first, and then NTLM. When an Exchange 2010 Client Access server communicates with a Mailbox server running Exchange Server 2003, it's a best practice to use Kerberos and disable NTLM authentication and Basic authentication. Additionally, it's a best practice to configure Outlook Web App to use forms-based authentication with a trusted certificate. For Exchange ActiveSync clients to communicate through the Exchange 2010 Client Access server to the Exchange 2003 back-end server, Windows Integrated Authentication must be enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 back-end server. To use Exchange System Manager on an Exchange 2003 server to manage authentication on an Exchange 2003 virtual directory, download and install the hot fix referenced in Microsoft Knowledge Base article 937031, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server. Note: Although the Knowledge Base article is specific to Exchange 2007, it's also applicable to Exchange 2010. When a Client Access server proxies POP3 requests to another Client Access server, the communication occurs over port 995/TCP, regardless of whether the connecting client uses POP3 and requests TLS (on port 110/TCP) or connects on port 995/TCP using SSL. Similarly, for IMAP4 connections, port 993/TCP is used to proxy requests regardless of whether the connecting client uses IMAP4 and requests TLS (on port 443/TCP) or connects on port 995 using IMAP4 with SSL encryption Windows Firewall with Advanced Security is a stateful, host-based firewall that filters inbound and outbound traffic based on firewall rules. Exchange 2010 Setup creates Windows Firewall rules to open the ports required for server and client communication on each server role. Therefore, you no longer need to use the Security Configuration Wizard (SCW) to configure these settings. To learn more about Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security and IPsec. This table lists the Windows Firewall rules created by Exchange Setup, including the ports opened on each server role. You can view these rules using the Windows Firewall with Advanced Security MMC snap-in. Rule name Server roles Port Program MSExchangeADTopology - RPC (TCP-In) Client Access, Hub Transpo Dynam ic RPC Bin\MSExchangeADTopologyService.exe rt, Mailbox , Unified Messagi ng MSExchangeMonitoring - RPC (TCP-In) Client Access, Hub Transpo rt, Edge Transpo rt, Unified Messagi ng Dynam ic RPC Bin\Microsoft.Exchange.Management.Monitoring. exe MSExchangeServiceHost - RPC (TCP-In) All roles Dynam ic RPC Bin\Microsoft.Exchange.ServiceHost.exe MSExchangeServiceHost - RPCEPMap (TCP-In) All roles RPC- EPMap Bin\Microsoft.Exchange.Service.Host MSExchangeRPCEPMap (GFW) (TCP-In) All roles RPC- EPMap Any MSExchangeRPC (GFW) (TCP-In) Client Access, Hub Transpo rt, Mailbox , Unified Messagi ng Dynam ic RPC Any MSExchange - IMAP4 (GFW) (TCP-In) Client Access 143, 993 (TCP) All MSExchangeIMAP4 (TCP- In) Client Access 143, 993 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Imap4 Service.exe MSExchange - POP3 (FGW) (TCP-In) Client Access 110, 995 (TCP) All MSExchange - POP3 (TCP-In) Client Access 110, 995 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Pop3S ervice.exe MSExchange - OWA (GFW) (TCP-In) Client Access 5075, 5076, 5077 (TCP) All MSExchangeOWAAppPoo l (TCP-In) Client Access 5075, 5076, 5077 (TCP) Inetsrv\w3wp.exe MSExchangeAB-RPC (TCP-In) Client Access Dynam ic RPC Bin\Microsoft.Exchange.AddressBook.Service.exe MSExchangeAB- RPCEPMap (TCP-In) Client Access RPC- EPMap Bin\Microsoft.Exchange.AddressBook.Service.exe MSExchangeAB-RpcHttp (TCP-In) Client Access 6002, 6004 (TCP) Bin\Microsoft.Exchange.AddressBook.Service.exe RpcHttpLBS (TCP-In) Client Access Dynam ic RPC System32\Svchost.exe MSExchangeRPC - RPC (TCP-In) Client Access, Mailbox Dynam ic RPC Bing\Microsoft.Exchange.RpcClientAccess.Servic e.exe MSExchangeRPC - PRCEPMap (TCP-In) Client Access, Mailbox RPC- EPMap Bing\Microsoft.Exchange.RpcClientAccess.Servic e.exe MSExchangeRPC (TCP- In) Client Access, Mailbox 6001 (TCP) Bing\Microsoft.Exchange.RpcClientAccess.Servic e.exe MSExchangeMailboxRepli cation (GFW) (TCP-In) Client Access 808 (TCP) Any MSExchangeMailboxRepli cation (TCP-In) Client Access 808 (TCP) Bin\MSExchangeMailboxReplication.exe MSExchangeIS - RPC (TCP-In) Mailbox Dynam ic RPC Bin\Store.exe MSExchangeIS RPCEPMap (TCP-In) Mailbox RPC- EPMap Bin\Store.exe MSExchangeIS (GFW) (TCP-In) Mailbox 6001, 6002, 6003, 6004 (TCP) Any MSExchangeIS (TCP-In) Mailbox 6001 (TCP) Bin\Store.exe MSExchangeMailboxAssis tants - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSExchangeMailboxAssistants.exe MSExchangeMailboxAssis tants - RPCEPMap (TCP- In) Mailbox RPC- EPMap Bin\MSExchangeMailboxAssistants.exe MSExchangeMailSubmissi on - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSExchangeMailSubmission.exe MSExchangeMailSubmissi on - RPCEPMap (TCP-In) Mailbox RPC- EPMap Bin\MSExchangeMailSubmission.exe MSExchangeMigration - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSExchangeMigration.exe MSExchangeMigration - RPCEPMap (TCP-In) Mailbox RPC- EPMap Bin\MSExchangeMigration.exe MSExchangerepl - Log Copier (TCP-In) Mailbox 64327 (TCP) Bin\MSExchangeRepl.exe MSExchangerepl - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSExchangeRepl.exe MSExchangerepl - RPC- EPMap (TCP-In) Mailbox RPC- EPMap Bin\MSExchangeRepl.exe MSExchangeSearch - RPC (TCP-In) Mailbox Dynam ic RPC Bin\Microsoft.Exchange.Search.ExSearch.exe MSExchangeThrottling - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSExchangeThrottling.exe MSExchangeThrottling - RPCEPMap (TCP-In) Mailbox RPC- EPMap Bin\MSExchangeThrottling.exe MSFTED - RPC (TCP-In) Mailbox Dynam ic RPC Bin\MSFTED.exe MSFTED - RPCEPMap (TCP-In) Mailbox RPC- EPMap Bin\MSFTED.exe MSExchangeEdgeSync - RPC (TCP-In) Hub Transpo rt Dynam ic RPC Bin\Microsoft.Exchange.EdgeSyncSvc.exe MSExchangeEdgeSync - RPCEPMap (TCP-In) Hub Transpo rt RPC- EPMap Bin\Microsoft.Exchange.EdgeSyncSvc.exe MSExchangeTransportWor ker - RPC (TCP-In) Hub Transpo rt Dynam ic RPC Bin\edgetransport.exe MSExchangeTransportWor ker - RPCEPMap (TCP-In) Hub Transpo rt RPC- EPMap Bin\edgetransport.exe MSExchangeTransportWor ker (GFW) (TCP-In) Hub Transpo rt 25, 587 (TCP) Any MSExchangeTransportWor ker (TCP-In) Hub Transpo rt 25, 587 (TCP) Bin\edgetransport.exe MSExchangeTransportLog Search - RPC (TCP-In) Hub Transpo rt, Edge Transpo rt, Mailbox Dynam ic RPC Bin\MSExchangeTransportLogSearch.exe MSExchangeTransportLog Search - RPCEPMap (TCP-In) Hub Transpo rt, Edge Transpo rt, Mailbox RPC- EPMap Bin\MSExchangeTransportLogSearch.exe SESWorker (GFW) (TCP- In) Unified Messagi ng Any Any SESWorker (TCP-In) Unified Messagi ng Any UnifiedMessaging\SESWorker.exe UMService (GFW) (TCP- In) Unified Messagi ng 5060, 5061 Any UMService (TCP-In) Unified Messagi ng 5060, 5061 Bin\UMService.exe UMWorkerProcess (GFW) (TCP-In) Unified Messagi ng 5065, 5066, 5067, 5068 Any UMWorkerProcess (TCP- In) Unified Messagi ng 5065, 5066, 5067, 5068 Bin\UMWorkerProcess.exe UMWorkerProcess - RPC (TCP-In) Unified Messagi ng Dynam ic RPC Bin\UMWorkerProcess.exe Notes on Windows Firewall Rules Created by Exchange 2010 Setup On servers that have Internet Information Services (IIS) installed, Windows opens the HTTP (port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange 2010 Setup doesn't open these ports. Therefore, these ports don't appear in the preceding table. On Windows Server 2008 and Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify the process or service for which a port is opened. This is more secure because it restricts usage of the port to the process or service specified in the rule. Exchange Setup creates firewall rules with the process name specified. In some cases, an additional rule that isn't restricted to the process is also created for compatibility purposes. You can disable or remove the rules that aren't restricted to the processes and keep the corresponding rules restricted to processes if your deployment supports them. The rules not restricted to processes are distinguished by the word (GFW) in the rule name. A number of Exchange services use remote procedure calls (RPCs) for communication. Server processes that use RPCs contact the RPC Endpoint Mapper to receive dynamic endpoints and register those endpoints in the Endpoint Mapper database. RPC clients contact the RPC Endpoint Mapper to determine the endpoints used by the server process. By default, the RPC Endpoint Mapper listens on port 135 (TCP). When configuring the Windows Firewall for a process that uses RPCs, Exchange 2010 Setup creates two firewall rules for the process. One rule allows communication with the RPC Endpoint Mapper, and the other rule allows communication with the dynamically assigned endpoint. To learn more about RPCs, see How RPC Works. For more information about creating Windows Firewall rules for dynamic RPC, see Allowing Inbound Network Traffic that Uses Dynamic RPC.
Evaluation of Some SMTP Testing, SSL Checkers, Email Delivery, Email Forwarding and WP Email Tools: Evaluation of Some SMTP Testing, SSL Checkers, Email Delivery, Email Forwarding and WordPress Email Tools