Environment
Secure Messaging Gateway
Situation
Using SMTP Redirection in a multi-tenant Secure Messaging Gateway environment.
Resolution
Note: This page applies to systems updated to SMG after April 2018 update. Prior versions did not have the same architecture.
This page provides details of how the SMG SMTP interface manages connections between sender and recipient servers, with particular attention to how messages are handled when the sender and recipients exist within the same SMG environment.
For most situations, where email comes in, or goes out of an SMG system, the expected behavior of SMG being a middleman process between the relevant SMTP end points will occur. In these core cases messages will be defined as inbound or outbound as expected for the purpose of selecting policies to use for filtering.
The two situations identified in the diagram with red lines indicate unusual or mis-configured situations. In the case of external direction, this implies relay protection is not enabled if email is allowed. In the case of sender/recipient share OU, this should not be a configuration scenario, as it suggests an email server is sending its own mail with a loopback through SMG. Although both are possible and acceptable, having mail delivery in either of these situations should be well understood.
The specific case where multi-tenant logic overrides the regular flow of connectivity is where a message is sent between two domains hosted by an SMG system, where the two domains exist in separate OUs. In this situation, there are two separate sets of policies that need to be considered. For the sender, the outbound policy of their OU must be used. For the recipient, the inbound policy of their OU must be used. The implementation of this is performed through a loopback mechanism with SMTP.
When a loopback message is encountered, on the first hop, SMG treats the recipient as external for the purpose of direction and next-hop connectivity. The next-hop ignores the locally defined addresses and instead looks up the MX record of the target domain. It is useful to understand that when multiple MX records exist, this may cause the message to come back through a different SMG server than the one that has received the original connection. During this connection phase, the SMG server will detect that the next-hop system is an SMG server by the presence of the ESMTP EHLO keyword 'X-SMGFLAGS'. If the loopback server responds as expected, the MAIL command is given the parameter 'X-SMGReentrant=1' to indicate to the next hop that the message being received must be treated as if it were coming from an unknown sender.
When the second hop SMG server receives a connection that indicates hat the sender is external, by way of the 'X-SMGReentrant=1' flag being present on the MAIL line, the sender is treated as unknown and the direction is defined accordingly based on the recipient address. The address should be to a known address within the system and be treated as inbound. If the sender is not internal, which would only occur by either MX misconfiguration or direct attempt to add the parameter, the message will be rejected as an attempted relay (presuming relay prevention is correctly configured).
The net result of this inter-OU handling process is that policies are process independently and in order by each OU. Rejection at either the sender or recipient OU will chain correctly via the SMTP protocol. Isolation of domains and OUs through the SMTP protocol also helps to locate issues where inter-OU mail flow occurs.
This page provides details of how the SMG SMTP interface manages connections between sender and recipient servers, with particular attention to how messages are handled when the sender and recipients exist within the same SMG environment.
For most situations, where email comes in, or goes out of an SMG system, the expected behavior of SMG being a middleman process between the relevant SMTP end points will occur. In these core cases messages will be defined as inbound or outbound as expected for the purpose of selecting policies to use for filtering.
The two situations identified in the diagram with red lines indicate unusual or mis-configured situations. In the case of external direction, this implies relay protection is not enabled if email is allowed. In the case of sender/recipient share OU, this should not be a configuration scenario, as it suggests an email server is sending its own mail with a loopback through SMG. Although both are possible and acceptable, having mail delivery in either of these situations should be well understood.
The specific case where multi-tenant logic overrides the regular flow of connectivity is where a message is sent between two domains hosted by an SMG system, where the two domains exist in separate OUs. In this situation, there are two separate sets of policies that need to be considered. For the sender, the outbound policy of their OU must be used. For the recipient, the inbound policy of their OU must be used. The implementation of this is performed through a loopback mechanism with SMTP.
When a loopback message is encountered, on the first hop, SMG treats the recipient as external for the purpose of direction and next-hop connectivity. The next-hop ignores the locally defined addresses and instead looks up the MX record of the target domain. It is useful to understand that when multiple MX records exist, this may cause the message to come back through a different SMG server than the one that has received the original connection. During this connection phase, the SMG server will detect that the next-hop system is an SMG server by the presence of the ESMTP EHLO keyword 'X-SMGFLAGS'. If the loopback server responds as expected, the MAIL command is given the parameter 'X-SMGReentrant=1' to indicate to the next hop that the message being received must be treated as if it were coming from an unknown sender.
When the second hop SMG server receives a connection that indicates hat the sender is external, by way of the 'X-SMGReentrant=1' flag being present on the MAIL line, the sender is treated as unknown and the direction is defined accordingly based on the recipient address. The address should be to a known address within the system and be treated as inbound. If the sender is not internal, which would only occur by either MX misconfiguration or direct attempt to add the parameter, the message will be rejected as an attempted relay (presuming relay prevention is correctly configured).
The net result of this inter-OU handling process is that policies are process independently and in order by each OU. Rejection at either the sender or recipient OU will chain correctly via the SMTP protocol. Isolation of domains and OUs through the SMTP protocol also helps to locate issues where inter-OU mail flow occurs.