Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for 4 août 2018

Business Email Reflections

Posted by Teruin laurent sur août 4, 2018

When we centralize Email with Exchange Online and remove local SMTP servers in subsidiaries or remote locations, the question arises as to which model we want to propose so that the business applications of the different agencies will continue to be able to send emails.

Some of them, sometime, send a large number of electronic messages for business needs. The question is therefore to determine which model should be adopted, to allow its agencies to legally send messages to the Internet.

Communicating applications.

The applications that have the need to send messages can be diverse and varied. These can be printers, scanners whose configuration must be done locally, but also business applications directly in relation to customers and therefore can be particularly sensitive.

In most cases, changing the parameters of its applications, scanners, printers, monitors are very time consuming for the Agencies. In addition, some applications can be complex to update. To complicate matters, some of them do not know how to use encryption layers or simply cannot authenticate themselves on a mail server.

The question is therefore which model should be proposed to take all these constraints into account and ensure that agencies can continue to use electronic messaging, without calling into question a level of control and security that could be described as satisfactory.

Two models can be proposed.

Centralized model

The first consists in specifying to each agency that they must change all of its business applications to use a simple and unique centralized SMTP service (UCSS) located in a unique datacenter

In this case the services of this UCSS for security reasons will have to set up access controls for each application that does not know how to authenticate itself. For applications that can authenticate themselves, UCSS will have to create application accounts for each remote application.

For each new application, agencies will have to apply for an authorization

This model certainly works but does not take into account the risks linked to the breakage of interconnection lines which could generate the need to reassign smtp service, quickly if the case arises the messaging flow to another SMTP relay. (Changing SMTP settings on each application can indeed generate several days of work).

it will also imply a heavier workload for the teams in charge of this UCSS

This model also implies that each Subs station sending SMTP streams to UCSS is identifiable by its IP address, which can be complicated in the case where address translation is used.

The following picture illustrates a possible centralized SMTP service organization


Distribution model

The distribution model consists in keeping a smtp relay in each Subs that can be used by local applications. This SMTP server will be from a UCSS, easily identifiable by its unique IP address but also by the fact that it will use authentication mode.

Thus, in the event of a problem with the Subs, the UCSS site can easily « turn off the tap » by simply deactivating the connector account.

In addition, firewalls could be set to leave only the SMTP stream from that IP address precisely, eliminating the risk of attack from different remote internal workstations.

In case the company would like to move the SMTP service point, only the Subs SMTP server would be concerned, unlike the centralized model, where the change would have to take place on all applications of the entire company environment.

This model would allow a better reactivity, and a load distribution towards the agencies which would not have any more the need to have to declare centrally each business application having to send messages.

It is also compatible with the possible presence of address translation provided that an IP address translation (1 For 1) for the Local SMTP server can be established between the company network and the agency network.

This model is also much more tolerant to possible MPLS or VPN link breaks that could occur between the Subs networks and the UCSS network.

Safety issues

In terms of security, I think it is important that the company, which will bear the main burden of forwarding the messages of each Subs, should at least

  • be able to quickly identify the emission source
  • close the communication tunnel in the event of « mail flooding » for example.

In both cases you should be making recommendations to the Subs to establish a clear and documented service agreement with them.

Laurent TERUIN


Posted in Non classé | Leave a Comment »