Transport Underlying Permission Model

Introduction

Transport is the process responsible for moving messages from one server to the other. SMTP is used for all message transfer among Hub servers. The security model between Mailbox and Hub is rather straightforward, as Hub servers in the same organization are trusted by Mailbox to submit and deliver messages. For SMTP it is not as clear cut. For starters, messages received from the Internet are anonymous and those need to be differentiated from authenticated messages submitted within your organization. That differentiation is what the Exchange2007 Transport permission model is all about. This document provides a detailed explanation of the permission model, probably more than most people want to know.

Example

An example works best for me to explain how permissions are being used. Suppose a user submits a message using Outlook Express. Outlook Express will use SMTP to submit the message to an Exchange2007 Hub server. When Outlook Express connects to the SMTP server, the session will initially assign those permissions to the session that have been granted to the Anonymous User as the session is anonymous initially.

The next step is for Outlook Express to authenticate. As part of the authentication procedure, the SMTP server checks whether the session has the permission to submit messages. By default Authenticated Users will have this permission, so there should not be a problem. Now the SMTP server will grant permissions to the session that have been configured for this user, or any groups to which this user belongs.

To submit the message, Outlook Express will execute the “MAIL FROM:” command. The SMTP server will check whether the session has the permission to send as any user (spoof). End users should only be allowed to send as themselves, thus not have that permission, so the server will execute a spoofing check. That will pass if the user has configured the correct email address. Outlook Express will continue the mail transaction issuing the “RCPT TO:” command. The SMTP server now checks whether the session has the permission to send messages to any domain (relay). It should as by default Exchange users are allowed to send messages to any domain.

Finally the “DATA” or “BDAT” command submits the actual message content. Once the message has been received by the SMTP server, it checks several permissions. One of those is the permission to send routing (Received:) headers. End users should not be allowed to send those, and the Header Firewall within the SMTP server will strip those headers from the message content. Another permission determines whether sender spoofing checks (send-as and send-on-behalf-of) should be bypassed or not. The SMTP server will finally report back whether the message got accepted, and Transport will try to send the message to the next hop.

This example illustrates how the SMTP server uses permissions with an SMTP server session. It also shows you that an SMTP session gets an initial set of permissions (anonymous) and another set once authenticated, corresponding to the authenticated user or computer. The next section explains the permissions, and the section after that explains the authentication mechanisms.

Permissions

Authentication

Permission Groups and the Usage Property

SMTP Server Responses (and what’s wrong)

Appendix A: Using the Add-AdPermission Task

Appendix B: Security Identifiers

Appendix C: Using ADSIEDIT to manage Transport Permissions