Exchange 2007 Edge Server as the Mail Relay of an Exchange 2003 Organization

Introduction

There was a time, a couple of years after the release of Exchange Server 2003 when Microsoft thought, in delivering a product called Exchange Edge Services, that they would have created an intelligent message transfer agent for the edge of a company's network that would offer security, spam and virus protection. The fact is that Edge Services never saw the light of day as a standalone SKU. Instead, Microsoft released the Edge Transport Server role as part of Exchange Server 2007.

The Exchange Server 2007 Edge role is a very special role. It can not be collocated with any other Exchange Server 2007 role, it does not require Active Directory (it uses its own directory: Active Directory Application Mode - ADAM) and it is very, very secure. In fact, it is such an "independent" role, that it can be used as a smart host and the internet mail relay of an Exchange 2003 organization without requiring any of the migration steps necessary for an Exchange 2007 transition.

Although placing an Exchange 2007 Edge server as the mail relay of a messaging infrastructure does not require an upgrade of the Exchange organization to Exchange 2007, there are still some configuration tasks that need to be done. This article will describe all these tasks and all the required procedures.

Solution Topology

For the purpose this article, I installed the following environment on my test lab:

Figure 1: Solution Topology

All servers are virtualized with Windows Server 2008 Hyper-V.

Name	Role	Software
VM1	Domain Controller Exchange Server 2003	Windows Server 2003 R2 SP2 Exchange Server 2003 SP2
E2K7EDGE	Edge Server	Windows Server 2003 R2 SP2 x64 Exchange Server 2007 SP1 + UR7 Forefront Server Security for Exchange 10 SP1

Table 1: List of servers

Configuration Tasks

The deployment of an Exchange 2007 Edge Transport server (also referred as Edge server or just Edge) to support an existing Exchange 2003 organization starts with the installation of the Exchange 2007 Edge server role and, optionally (but recommended), Forefront Security for Exchange Server. After that, the rest of the process can be broken down into the following tasks:

1. Configure accepted domains on the Edge server
2. Create a Send Connector from the Edge server to the Internet
3. Create a Send Connector from the Edge server to the Exchange 2003 organization
   
   3.1. Configure the SMTP Virtual Server on Exchange Server 2003
4. Create a Receive Connector on the Edge server that accepts connections from the Exchange 2003 organization
   
   4.1. Create an SMTP Send Connector from the Exchange 2003 organization to the Edge server
5. Redirect the DNS mail exchange (MX) record(s) for the internal SMTP domain(s)

Figure 2: Summary of configuration tasks (image courtesy of Microsoft)

1. Configure Accepted Domains

The first step is to configure accepted domains for which the Edge server will accept e-mail.

1. On the Exchange Edge Server, open the Exchange Management Console (EMC), select Edge Transport, select the Accepted Domains tab and then on the Actions pane, select New Accepted Domain. Choose an appropriate Name and then fill in the Accepted Domain (Figure 3). An accepted domain can be configured as Authoritative, Internal Relay or External Relay. In this case we'll configure it as an Authoritative Domain. Click New to create the entry.

To execute the very same task, but using a PowerShell cmdlet:
new-AcceptedDomain -Name 'virtual.com' -DomainName 'virtual.com' -DomainType 'Authoritative'

Figure 3: New Accepted Domain

2. Repeat this task for each SMTP domain that will be routed through the Edge server.

2. Create the Internet Send Connector

Send Connector is necessary to route e-mail messages to the Internet. Several Send Connectors can be configured (differentiated by the SMTP domain) or one universal connector with the address space defined as asterisk ( * ). E-mail messages can be routed directly to other SMTP servers, using DNS name resolution, or they can be routed through a smart host (such as a server hosted by an ISP).

1. Back to the EMC, click the Send Connectors tab. In the Actions pane, click New Send Connector. In the Name field, type a name to identify the connector. In the Select the intended use for this connector field, select Internet (Figure 4). Click Next.

Figure 4: New SMTP Send Connector

2. On the Address space page (Figure 5), click Add. In the Add Address Space dialog box, enter "*" as the Address, 10 as the Cost (is a best practice not using the default 1) and then click OK. Click Next.

Figure 5: Address space

3. On the Network settings page (Figure 6), the option Use domain name system (DNS) "MX" records to route mail automatically is selected. If this is the correct setting, click Next (if you must route mail through a smart host, I will explain how to do it later on this article, since the Send Connector that will be created to route mail to the Exchange 2003 Organization will have a smart host).

Figure 6: Network settings

4. On the New Connector page (Figure 7), review the configuration summary and click New.

Figure 7: New Connector

5. On the Completion page, click Finish.

3. Create Internal Send Connector for Exchange 2003

In order to handle the received messages, the Edge server has to route them internally. It does this by using a Send Connector configured to route the messages destined to the internal SMTP domains through one or more Exchange 2003 bridgehead servers configured as a smart host.

1. On the Edge server, open the EMC. Select Edge Transport, click the Send Connectors tab and then, in the Actions pane, click New Send Connector. In the New SMTP Send Connector wizard (Figure 8), type a Name for this connector. In the Select the intended use for this connector field, choose Internal, and then click Next.

Figure 8: New SMTP Send Connector

2. On the Address space page, click Add. Several SMTP domains can be added as separate entries, or, in the Add Address Space dialog box, the -- placeholder can be entered (Figure 9). The -- placeholder represents all authoritative and internal relay domains configured as Accepted Domains. Click OK to close the dialog box, and then click Next.

Figure 9: SMTP Address Space

3. On the Network settings page (Figure 10), select Route mail through the following smart hosts, and then click Add. In the Add smart host dialog box, enter the IP Address or the FQDN of the Exchange 2003 bridgehead server that will receive the incoming messages. Click OK. More than one smart host can be configured, meaning Edge server will load-balance the connections between servers. Click Next.

Figure 10: Adding a smart host

From this point on, you must choose which type of security to implement:

• [Error! Reference source not found.] Basic Authentication over TLS - Requires the creation of a domain account, member of the Exchange Domain Servers. Both servers must have a certificate. The Exchange 2003 SMTP Virtual Server must be configured to accept Basic Authentication over TLS.
• [Error! Reference source not found.] Anonymous Access - Requires modification of the discretionary access control list (DACL) on this Send connector to grant the NT Authority\ANONYMOUS LOGON account the ms-Exch-SMTP-Send-Exch50 permission. On the Exchange 2003 bridgehead server, the Relay Restrictions of the SMTP Virtual Server should be configured and you must modify the registry to enable it to receive anonymous submission of Exch50 data (to preserve some information, such as the spam confidence level (SCL) for a message, when messages are relayed from the Edge Transport server).

The recommended setting is Basic Authentication with TLS to authenticate to the legacy Exchange server.

Leave the New SMTP Send Connector wizard open and proceed to appropriate paragraph: Error! Reference source not found. or Error! Reference source not found..

Basic Authentication with TLS

4. Create a user account (used by the Edge server to authenticate to Exchange 2003) in the Active Directory that services the Exchange organization (Figure 11). Add the account to the Exchange Domain Servers security group (Figure 12).

Figure 11: New AD user

Figure 12: User Properties

5. On the Exchange 2003 server or servers that will receive messages from the Edge Transport server, open Exchange System Manager. Expand Servers, expand the desired server, expand Protocols and finally expand SMTP. Right-click Default SMTP Virtual Server and select Properties. Click the Access tab and then click Authentication. In the Authentication dialog box (Figure 13), select Basic authentication (password is sent in clear text) and Requires TLS encryption. Click OK.

Figure 13: SMTP Virtual Server Authentication

6. Since TLS will be used, there should be a certificate configured for Exchange 2003 bridgehead server to use. On the Access tab click Certificate. On the Web Server Certificate Wizard, click Next. Follow the instructions on the remaining pages of the wizard to create a new certificate or to assign an existing certificate. Close Default SMTP Virtual Server Properties. Regarding the Edge server, the self-signed certificate will be accepted. In case you replaced the self-signed certificate, make sure the enabled certificate is signed by an authority both servers trust.
7. Back to the Edge Server, on the Configure smart host authentication settings page (Figure 14), select Basic Authentication and Basic Authentication over TLS. In the User name and Password fields, enter the credentials for the previously created user account (use the domain\user format or user principal name (UPN) format). Click Next.

Figure 14: Smart host authentication settings

8. On the New Connector page (Figure 15), review the configuration summary and click New to create the connector.

Figure 15: New Connector summary

9. On the Completion page, click Finish.

Internal Send Connector with Anonymous Access

On the Exchange 2003 bridgehead server, configure the relay restrictions to enable only the Edge server to relay through this virtual server:

1. Open Exchange System Manager. Expand Servers, expand the desired server, expand Protocols and finally expand SMTP. Right-click Default SMTP Virtual Server and select Properties. On the Access tab of Default SMTP Virtual Server Properties click Relay. On the Relay Restrictions dialog box (Figure 16) select Only the list below, click Add and then on the Computer dialog box, enter the IP address of the Edge server. Click OK twice to close the Default SMTP Virtual Server Properties.

Figure 16: SMTP Virtual Relay Restrictions

2. To modify the registry settings on the Exchange 2003 bridgehead server, open Registry Editor. Locate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\XEXCH50. Right-click XEXCH50, click New and select DWORD Value. Type SuppressExternal for the value name and leave it with the default value of 0 (Figure 17). The XEXCH50 properties are now allowed to be transmitted anonymously.

Figure 17: SupressExternal Registry key

3. Next, we must allow XEXCH50 properties to be transmitted when e-mail is sent anonymously. Right-click XEXCH50 and create a new key. Type the number of the SMTP virtual server instance as the key value (the default virtual server instance is 1). Right-click the key that you've just created, point to New and select DWORD Value. Type Exch50AuthCheckEnabled as the name and leave the default value of 0 (Figure 18).

Figure 18: Exch50AuthCheckEnabled Registry key

4. Back to the Edge server, on the Configure smart host authentication settings page (Figure 19), select Externally Secured (for example with IPsec). Click Next.

Figure 19: Smart host authentication settings

5. On the New Connector page (Figure 20), review the configuration summary and click New to create the connector.

Figure 20: New connector summary

6. On the Completion page, click Finish.
7. Run the following command in the Exchange Management Shell to grant the permissions that are required to enable transmission of XExch50 data to the Exchange 2003 server:
   Add-AdPermission -Identity <"Send Connector Name"> -User "NT Authority\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Send-Exch50

Internal Receive Connector from Exchange 2003

Although the default Receive connector on an Edge Transport server can be used to accept e-mail submissions from both the Internet and from the Exchange organization, as a best practice, it is recommended to configure a second Receive connector to separate SMTP traffic and to configure different authentication.

1. Open the EMC, click Edge Transport, and then in the work pane, click the Receive Connectors tab. In the action pane, click New Receive Connector. On the New SMTP Receive Connector page (Figure 21), type a unique Name for the connector. From the Select the intended use for this connector drop-down list, select Internal, and then click Next.

Figure 21: New SMTP Receive Connector

2. On the Remote Network settings page (Figure 22), delete the all network ranges entry and click Add. In the Add IP Address(es) of Remote Servers dialog box, type the IP address(es) of the Exchange 2003 bridgehead server(s) that will relay messages to the Edge server. Click OK, and then click Next.

Figure 22: Remote Network settings

3. On the New Connector page (Figure 23) click New and then, on the Completion page, click Finish.

Figure 23: New Connector summary

1. Create SMTP Connectors on the Exchange 2003 Bridgehead

On the Exchange 2003 server, follow these steps to create an SMTP connector that is configured to relay e-mail through the Edge server:

1. Open Exchange 2003 System Manager. Expand Administrative Groups and then expand the administrative group that you want to configure. Expand Routing Groups, right-click the Connectors, select New, and then select SMTP Connector. On the General tab (Figure 24), type a unique Name, select Forward all mail through this connector to the following smart hosts, and type the IP address or FQDN of the Edge Transport server. Click Add and in the Add Bridgehead dialog box, select one or more Exchange 2003 servers that will act as bridgeheads for this connector.

Figure 24: Exchange 2003 SMTP Connector General tab

2. Select the Address Space tab (Figure 25), click Add and in the Add Address Space dialog box, select SMTP and click OK. On the Internet Address Space Properties page, enter ¡°*¡± for the Address and a Cost of 10. Click OK twice to close the SMTP connector properties page.

Figure 25: Exchange 2003 SMTP Connector Address Space tab

Now that the Internal Receive Connector on the Edge server and the SMTP Connector on the Exchange 2003 bridgehead are created, we can choose what the authentication method will be:

• Basic Authentication over TLS ¨C requires the creation of a local account on the Edge server and then granting that account permissions on the Internal Receive connector.
• Anonymous Access ¨C requires the removal of the authentication methods on the Internal receive connector.

2. Internal Receive Connector with Basic Authentication over TLS

1. The Edge Transport server, create the credentials that are used by the Exchange 2003 server to authenticate when sending e-mail. Create a user account in the Users folder in the Local Users and Groups container on the Edge Transport server (Figure 26).

Figure 26:New local user

2. Modify the authentication method that is used for this Receive connector. Open the Exchange Management Console (EMC). Locate the Receive connector that you want to modify, and then in the Actions pane, click Properties. Click the Authentication tab. Select Basic Authentication and Offer Basic authentication only after starting TLS (Figure 27). Click OK.

Figure 27: Receive Connector Authentication settings

3. Run the following command in the Exchange Management Shell to grant permissions on the new Receive connector to the local user account previously created:
   
   Add-AdPermission -Identity "Internal Receive Connector [from Exchange 2003]" -User E2K7EDGE\E2K3Auth -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-Accept-Headers-Routing,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Figure 28: Add-AdPermission

4. Next, go back to the Exchange 2003 bridgehead server. On the Exchange 2003 SMTP Connector Properties, select the Advanced tab, and click Outbound Security. In the Outbound Security dialog box (Figure 29), select Basic Authentication, and then click Modify. In the Outbound Connection Credentials dialog box, enter the user name and password for the Edge Transport server local user account and then click OK. On the Outbound Security dialog box, select TLS encryption. Click OK twice.

Figure 29: SMTP Connector Outbound Security

3. Internal Receive Connector with Anonymous Access

To use Anonymous access, we have to modify the authentication method that is used for the Receive connector.

1. Open the EMC on the Edge server. Locate the Receive connector that you want to modify, and then in the Actions pane, click Properties. Click the Authentication tab (Figure 30). Make sure the only authentication method selected is Externally Secured (for example with IPsec) and then click OK.

Figure 30: Receive Connector Authentication settings

4. Configure MX Record

The final configuration step is to configure the Edge Transport server to accept the incoming SMTP connections to the organization. This can be accomplished by modifying the DNS MX records to direct mail for your SMTP domains to the Edge server. If there is a firewall or some other security equipment between the Edge server and the Internet, maybe all that is necessary is to edit firewall rules or make any other configuration change so that e-mail to your accepted domains is correctly routed.

But first, you may consider doing some tests...

Testing

Before putting the newly configured Edge server in production and changing the MX record, it might be a good idea to test it first. By now, there should be 4 connectors configured (Figure 31):

• Default Receive Connector: used to receive mail from the Internet
• Internal Receive Connector: used to receive mail from the Exchange 2003 Organization
• Internet Send Connector: used to send mail to the Internet
• Internal Send Connector: used to relay the incoming Internet mail to the Exchange 2003 Organization

Figure 31: Edge Connectors

Tip:
During the tests, you should disable the anti-spam features of both the Edge server (Content Filtering) and the Exchange 2003 bridgehead (IMF).

Mail flow from the Internet to Exchange 2003

Since probably at this time, the MX record is not yet redirected to the new Edge server, in order to simulate incoming mail we will have to do it the hard way: using SMTP command verbs!

1. Telnet to the port 25 of the external IP address of the Edge server (where the Default receive connector is listening). Using SMTP command verbs, send a message to an internal user (Figure 32).

Figure 32: Testing using SMTP verbs

2. To check that the message was successfully delivered, either check the user's Inbox or find that specific message using the Exchange 2003 Tracking Center (Figure 33).

Figure 33: Message received on the Exchange 2003

Mail flow from Exchange 2003 to the Internet

1. To check mail flow to the Internet, using an internal mailbox send an e-mail to some outside user (you can do this test, even if your Edge server is not yet connected to the Internet).
2. Using Exchange 2003 Tracking Center, verify that the message was successfully delivered to the Edge Server (Figure 34).

Figure 34: Message sent to Exchange Edge server

3. If the Edge server is already connected to the Internet and is capable of delivering mail, check the recipient's mailbox to see if the message arrived. If the Edge server is not yet capable of sending outside mail, from the Exchange Management Console open the Queue Viewer and find the destination domain where you sent the test message to. Figure 35 depicts 1 pending message for live.com.

Figure 35: Exchange Edge Server Queue

Additional Configuration

There are some additional configuration tasks that you can do, such as configuring anti-spam, anti-virus, transport rules (adding disclaimers, for example) or even allowing application servers to relay off the Exchange 2007 Edge server.

If you have anti-spam settings defined on Exchange 2003 (IMF, sender filtering, block lists, etc.), you can use the Exchange 2007 Anti-Spam Migration Tool to migrate these settings to the Edge Transport server. For further information regarding the utilization of this tool, please read Exchange 2007 Anti Spam Migration Tool.

Troubleshooting

While configuring the Edge server, I got the first error when I was trying to create the Internet Send connector (Figure 36):

You must specify at least one source server.

Exchange Management Shell command attempted:
new-SendConnector -Name 'Internet Send Connector' -Usage 'Internet' -AddressSpaces 'SMTP:*;10' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false

Figure 36: Error: You must specify at least one source server

The problem occurred because the Exchange Transport service was stopped. Starting the service solved the issue.

Anti-spam

While sending test messages (and maybe afterwards), you can get some messages blocked by the anti-spam features of Exchange Server. You can try do temporarily disable these features to troubleshoot the problem.

For the Edge Server, selectively disable the anti-spam agent filtering.

For the Exchange 2003 bridgehead, unbind the anti-spam features from the SMTP Virtual Server (Figure 37).

Figure 37: Exchange 2003 anti-spam bindings

Message Tracking Center

The Message Tracking Center (Figure 38) is a great tool you can use to find any message in the Exchange 2003 organization.

Figure 38: Message Tracking Center

Protocol Logs

Exchange Servers (2003 and 2007) have lots and lots of logs with useful information. I will not describe all the available options, I will just say that for the purpose of the subject of this article the Protocol Logs can really make a difference. For instance, let us look at the Exchange 2003 logs, available by default in the folder C:\WINDOWS\system32\LogFiles\SMTPSVC1 (some fields were truncated for better reading).

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2009-04-25 12:40:36
#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent)
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 EHLO - +E2K7EDGE.mycorp.org 250 0 283 24 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 STARTTLS - - 220 0 0 8 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 STARTTLS - - 220 0 29 8 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 EHLO - +E2K7EDGE.mycorp.org 250 0 327 24 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 MAIL - +FROM: 250 0 65 48 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 RCPT - +TO: 250 0 59 35 0 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 BDAT - +<5e575a1c-b03c-4978-9a9e-a73d3c33fea8@e2k7edge.mycorp.org> 250 0 117 587 157 SMTP - -
2009-04-25 E2K7EDGE SMTPSVC1 VM1 10.10.1.111 0 QUIT - E2K7EDGE.mycorp.org 240 2219 85 4 0 SMTP - -

Can you identify what this portion of the log means? It's Exchange 2003 receiving that very test message I sent using Telnet and SMTP commands.

But Exchange 2007 also have nice protocol logs, but do not forget to enable the Verbose logging level, in the Properties of the desired connector (Figure 39).

Figure 39: Protocol logging level

These logs are located in C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\ by default. Let's look at a portion of the send logs for the same message in the previous log (some fields were truncated):

#Software: Microsoft Exchange Server
#Version: 8.0.0.0
#Log-type: SMTP Send Protocol Log
#Date: 2009-04-25T13:00:47.231Z
#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context
2009-04-25T13:00:47.231Z,0,*,,attempting to connect
2009-04-25T13:00:47.231Z,1,+,,
2009-04-25T13:00:47.247Z,2,<,"220 vm1.virtual.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Sat, 25 Apr 2009 14:00:47 +0100 ",
2009-04-25T13:00:47.247Z,3,>,EHLO E2K7EDGE.mycorp.org,
2009-04-25T13:00:47.262Z,4,<,250-vm1.virtual.com Hello [10.10.1.100],
2009-04-25T13:00:47.262Z,5,<,250-TURN,
2009-04-25T13:00:47.262Z,6,<,250-SIZE,
2009-04-25T13:00:47.262Z,7,<,250-ETRN,
2009-04-25T13:00:47.262Z,8,<,250-PIPELINING,
2009-04-25T13:00:47.262Z,9,<,250-DSN,
2009-04-25T13:00:47.262Z,10,<,250-ENHANCEDSTATUSCODES,
2009-04-25T13:00:47.262Z,11,<,250-8bitmime,
2009-04-25T13:00:47.262Z,12,<,250-BINARYMIME,
2009-04-25T13:00:47.262Z,13,<,250-CHUNKING,
2009-04-25T13:00:47.262Z,14,<,250-VRFY,
2009-04-25T13:00:47.262Z,15,<,250-TLS,
2009-04-25T13:00:47.262Z,16,<,250-STARTTLS,
2009-04-25T13:00:47.262Z,17,<,250-X-EXPS GSSAPI NTLM,
2009-04-25T13:00:47.262Z,18,<,250-AUTH GSSAPI NTLM,
2009-04-25T13:00:47.262Z,19,<,250-X-LINK2STATE,
2009-04-25T13:00:47.262Z,20,<,250-XEXCH50,
2009-04-25T13:00:47.262Z,21,<,250 OK,
2009-04-25T13:00:47.262Z,22,>,STARTTLS,
2009-04-25T13:00:47.262Z,23,<,220 2.0.0 SMTP server ready,
2009-04-25T13:00:47.262Z,24,*,,Sending certificate
2009-04-25T13:00:47.262Z,25,*,CN=E2K7EDGE,Certificate subject
2009-04-25T13:00:47.262Z,26,*,CN=E2K7EDGE,Certificate issuer name
2009-04-25T13:00:47.262Z,27,*,E60C8B2919103D984D2AEAD282D85C3E,Certificate serial number
2009-04-25T13:00:47.262Z,28,*,8F7D14A3ED220AAD5344E1B591FC9941D8D57522,Certificate thumbprint
2009-04-25T13:00:47.262Z,29,*,E2K7EDGE;E2K7EDGE.mycorp.org,Certificate alternate names
2009-04-25T13:00:47.262Z,30,*,,Received certificate
2009-04-25T13:00:47.262Z,31,*,D16428229959D997CF448CE94CFEEB964BBE9578,Certificate thumbprint
2009-04-25T13:00:47.309Z,32,*,Valid,Chain validation status
2009-04-25T13:00:47.309Z,33,*,,SmartHost certificate
2009-04-25T13:00:47.309Z,34,*,CN=vm1.virtual.com,Certificate subject
2009-04-25T13:00:47.325Z,35,*,"CN=My Internal CA, DC=virtual, DC=com",Certificate issuer name
2009-04-25T13:00:47.325Z,36,*,61107EC0000000000007,Certificate serial number
2009-04-25T13:00:47.325Z,37,*,D16428229959D997CF448CE94CFEEB964BBE9578,Certificate thumbprint
2009-04-25T13:00:47.325Z,38,*,vm1.virtual.com,Certificate alternate names
2009-04-25T13:00:47.325Z,39,>,EHLO E2K7EDGE.mycorp.org,
2009-04-25T13:00:47.466Z,40,<,250-vm1.virtual.com Hello [10.10.1.100],
2009-04-25T13:00:47.466Z,41,<,250-TURN,
2009-04-25T13:00:47.466Z,42,<,250-SIZE,
2009-04-25T13:00:47.466Z,43,<,250-ETRN,
2009-04-25T13:00:47.466Z,44,<,250-PIPELINING,
2009-04-25T13:00:47.466Z,45,<,250-DSN,
2009-04-25T13:00:47.466Z,46,<,250-ENHANCEDSTATUSCODES,
2009-04-25T13:00:47.466Z,47,<,250-8bitmime,
2009-04-25T13:00:47.466Z,48,<,250-BINARYMIME,
2009-04-25T13:00:47.466Z,49,<,250-CHUNKING,
2009-04-25T13:00:47.466Z,50,<,250-VRFY,
2009-04-25T13:00:47.466Z,51,<,250-X-EXPS GSSAPI NTLM LOGIN,
2009-04-25T13:00:47.466Z,52,<,250-X-EXPS=LOGIN,
2009-04-25T13:00:47.466Z,53,<,250-AUTH GSSAPI NTLM LOGIN,
2009-04-25T13:00:47.466Z,54,<,250-AUTH=LOGIN,
2009-04-25T13:00:47.466Z,55,<,250-X-LINK2STATE,
2009-04-25T13:00:47.466Z,56,<,250-XEXCH50,
2009-04-25T13:00:47.466Z,57,<,250 OK,
2009-04-25T13:00:47.481Z,58,>,AUTH LOGIN,
2009-04-25T13:00:47.497Z,59,<,334 ,
2009-04-25T13:00:47.497Z,60,>,,
2009-04-25T13:00:47.497Z,61,<,334 ,
2009-04-25T13:00:47.497Z,62,>,,
2009-04-25T13:00:47.512Z,63,<,235 2.7.0 Authentication successful.,
2009-04-25T13:00:47.528Z,64,*,6,sending message
2009-04-25T13:00:48.794Z,93,>,MAIL FROM:someone@company.com> SIZE=969 AUTH=<,
2009-04-25T13:00:48.794Z,94,>,RCPT TO:administrator@virtual.com,
2009-04-25T13:00:48.794Z,95,<,250 2.1.0 someone@company.com....Sender OK,
2009-04-25T13:00:48.966Z,96,<,250 2.1.5 administrator@virtual.com ,
2009-04-25T13:00:48.966Z,97,>,BDAT 574 LAST,
2009-04-25T13:00:49.122Z,98,<,250 2.6.0 <5e575a1c-b03c-4978-9a9e-a73d3c33fea8@e2k7edge.mycorp.org> Queued mail for delivery,
2009-04-25T13:00:49.450Z,106,>,QUIT,
2009-04-25T13:00:49.450Z,107,<,221 2.0.0 vm1.virtual.com Service closing transmission channel,
2009-04-25T13:00:49.450Z,108,-,,Local

Here we can see all the processes involved, such as the certificate exchange, the TLS handshake and then all the necessary SMTP verbs.