9.1 Introduction

It is helpful to understand the context of SMTP authentication in the context of an SMG server when configuring a system. It can be confusing to determine what parts of the system are interacting with authenticated privileges compared to email addresses provided in the MAIL FROM and RCPT TO commands of the SMTP protocol.

The following diagrams show the conversation between an SMTP client and server, and what pieces of information are picked up during the conversation by the server process.

When an SMTP client connects, the server knows the IP address of the incoming connection, and nothing more. In the first diagram here, the client has connected to the server, and it has no information about authentication or delivery addresses.

In the second diagram, a typical inbound message transaction is taking place. No authentication is performed, and the sender and recipient email addresses are provided. After these commands, the server has enough information to determine how to deliver the message that will be provided.

Pay attention to the server response to the EHLO command. The response does not advertise AUTH to the client. The client must not try to authenticate when AUTH is not in the initial response, and the server will not accept attempts to try it, reporting an invalid command if it is attempted.

The third diagram shows the state of an authenticating SMTP client. In this case the client issues a LOGIN command along with its credentials. At the end of the addressing process, the server now has two additional pieces of information – a login name and an authenticated state.

There are some very important concepts to understand about this diagram and what it demonstrates.

The login name may or may not match the sender email address, depending on what functionality the SMTP server provides and how it implements authentication. The privileges that are given when successfully authenticated are also not necessarily related to the sender address. They may be linked in some way, but they are not referring to the same internal information. The key point here is that when configuring rules, such as exceptions and allow/deny lists, you need to know which property you are configuring. Allowing a login name is NOT the same as allowing a sender email address, from the SMTP server perspective. Allowing AUTH names acts on the AUTH command, while allowing sender addresses acts on the MAIL FROM command.

In the authenticated state, additional privileges may be afforded to the sender, for example they may now be allowed to send messages from the mail servers internal domain name. These privileges are not automatically assumed by SMG, and must be configured based on the individual system needs.

The next image gives an insight into the state of SMG when an SMTP client fails to authenticate, but subsequently tries to brute force the sending of a message using a spoofed address (pretending to be from company.com in this example).

In this case, because the authentication fails, the internal properties remain undefined and all commands fail from this point on, preventing spoofing of the email address that is provided in the MAIL FROM command.