(ARCH) ISP-Customer splitted ELSE architecture

ELSE: some examples of SMTP architectures

Edited by Nicolas HAHN < hahnn@x-itools.com > / < hahnn@erios.org >

---

Top: [SMTP architecture examples] | Previous: [(ARCH) Use the ELSE in an infrastructure not designed for that]

---

• Use the ELSE in a splitted ISP/Customer configuration
  • Context
  • Drawings
    • Basic
    • Detailed
  • Comments
  • Pros & Cons

Use the ELSE in a splitted ISP/Customer configuration

Context

Let's say you have your Postfix (or Exchange) messaging servers hosted to your Internet Service Provider.
Unfortunately, this ISP does not provide tool like the ELSE allowing you to investigate all your email flows. Or this ISP is using the ELSE only at his level but doesn't provide it to its customers.

Then you can host an ELSE server at home, in your own infrastructure, and ask your ISP to send to your home-hosted ELSE server all the Postfix and Exchange logs, in real time. This can be done very easily using the Rsyslog encryption features, or by opening a VPN for that purpose between your ISP and you. The bandwidth required for that is small: for a million emails a day, that's an average of 1.5 Mbits/s. of course, that can be even less or a little bit more depending of the number of SMTP layers of servers you have in your email ISP hosted infrastructure.

Drawings

Basic

Detailed

Comments

In this architecture, the customer clearly owns the ELSE server, that's hosted inside his company.
The ELSE server is totaly separated from all the rest of the messaging infrastructure hosted by the ISP, and is managed by the customer only, without possibility for the ISP to interact with it. By this way, logs are not supposed to exist on the individual Postfix servers, because they are sent immediately to the remote ELSE server, via an encrypted tunnel. Messaging logs are not available to the ISP, or to its partners.

Today, such kind of design may be seen as interesting by some customers, at the time we have all discovered the suspicious activity of some US national agencies like the NSA, the PRISM program or else, having for goal to spy as much as data they can all over internet.

The bandwidth usage is small, even for a large amount of email transactions per day.

Of course, it's also possible to get your own ELSE server, managed by the customer himself, but hosted inside the ISP networks.

Pros & Cons

Well, you are supposed to keep the ELSE server inside your own networks, under your total and exclusive control. All communications are secured between the ELSE server and your ISP hosted messaging servers. The response time of the ELSE server to the users is the fastest because it's local to your own company networks. If the ISP have a failure, if your hosted messaging system becomes suddenly unavailable, you can immediately investigate and probably find answers to messaging system issues using your own ELSE server, without waiting that your ISP provide you reports on his investigations. This lead to a contradictory set of reports, that can benefit to you. Of course, you don't depend of the service offerings of your ISP. The fact they offer you an ELSE service or not has no impact on you.

That's your logs, your data, your private company life, and the ISP is supposed to have no way to interact with them in such kind of configuration.

On the other hand, you still need to buy strong ELSE server(s) and to own resources inside your company to host and manage it. The cost can then be higher than having it inside your ISP networks. Your ISP must also accept on your request to establish the communication ways allowing you to receive all the logs of your hosted servers in real time. That also have a cost as a service requested to your ISP.

---

Top: [SMTP architecture examples] | [(ARCH) Use the ELSE in an infrastructure not designed for that]