(ARCH) Basic splitted roles architecture

ELSE: some examples of SMTP architectures

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

---

Top: [SMTP architecture examples] | Previous: [(ARCH) Very basic architecture] | Next: [(ARCH) Load proof architecture with Microsoft Exchange]

---

• Basic splitted roles architecture with 3 servers
  • Context
  • Drawings
    • Basic
    • Detailed
  • Comments
  • Pros & Cons

Basic splitted roles architecture with 3 servers

Context

This architecture is the first starting to be interesting and really allowing to put one feet in the business world, I think.

Compare to the previous one, SMTP roles are splitted according the way of the SMTP traffic. So we find 2 SMTP servers, one dedicated to INCOMING email flow to handle any email received from internet to our messaging domains and mailboxes, and the other one dedicated to OUTGOING email flow to handle any email to be sent from our messaging domains and mailboxes to the world.

This kind of architecture allow management of important mail flows and can be the basic element to build a shared messaging infrastructure. The ELSE really loves architectures where roles are splitted because the emails can be categorized according their way, that this drives the ELSE easily for most of its features: it's easy, for example, to generate graphs and statistics when roles are splitted.

There is of course a third server for the ELSE, to let you investigate Postfix logs without introducing too much changes or perturbations directly on the SMTP servers.

This architecture can be used by small size companies or for small to mid-size needs.

Drawings

Basic

Detailed

Comments

In this architecture again, roles are clearly splitted between the messaging servers and the management server. We go one step beyond by splitting the email flows in two distinct flows: one for incoming emails, and the other one for outgoing emails.

The Incoming Postfix server is acting as MUA and Incoming MTA.
The Outgoing Postfix server is acting as Outgoing MTA.
And the management server is acting as ELSE server.

Incoming and Outgoing Postfix servers have their own dedicated public IPs.

On the Incoming server, an IMAP daemon is installed, allowing the users to handle their mailbox via IMAP4/POP3 protocols using Mozilla Thunderbird for instance. This daemon could be a Dovecot or Cyrus-IMAP one (which I prefer personally). Usually, anti-spam and anti-virus capabilities are also installed on the incoming server, as we consider all the incoming traffic is untrusted (except the one re-injected by the Outgoing Postfix server). Then very often you'll have Spamassassin, Amavisd-new, ClamAV and Postgrey or GreyLSE installed to perform those tasks.

The IMAP daemon and the Postfix SMTP daemons discuss together. Postfix, as the MTA, is in charge of the reception of emails via SMTP protocol from internet. It must be clear the Incoming server cannot receive any incoming email from your internal networks and users.

On the Outgoing server, a Postfix SMTP daemon is installed only. All the traffic coming to the Outgoing server is considered trusted and safe, because generated by your own users. Of course you could decide to not trust them in any way, as it is well known that most of the attacks against a computer system are made by the internal users, and then you could install anti-spam and anti-virus products at this level as well. It must be clear the Outgoing server cannot receive any incoming email from internet.

However in this architecture, the Outgoing Postfix server can re-inject emails to the Incoming Postfix server: those emails are the ones sent by your internal users writting to recipients that are also internal users.

On all Postfix servers the SNMP daemon is configured in Read/Write. It can be qualified as SNMP client. This SNMP client will be queried by the SNMP server running on the ELSE for monitoring purposes, but it can also receive some control commands from the SNMP server.

The Rsyslog daemon is the syslog engine configured in client mode. It is in charge of collecting and sending all the logs from Postfix daemon to the Rsyslog daemon of the ELSE server running as the central Rsyslog server. All logs are sent from the client to the server via TCP, using RELP protocol, and compressed.

The ELSE system is running on its dedicated server and it mainly consists in the SNMP daemon, Rsyslog daemon, PostgreSQL database daemon and the Apache web server serving the ELSE ExtJS based web content.

All Postfix servers, in this architecture, are also able to capture any NDR they might generate, to send them directly to the ELSE server. By the way, they will be available for consultation in the ELSE WUI.

The Rsyslog daemon receive all logs from the PFX servers, and is in charge of sending them directly to the PostgreSQL database upon reception.

Users can then use their Chrome or Firefox web browser to use the ELSE WUI (Web User Interface) in order to search their emails, generate reports and statistics and so on.

In addition to all of that, you might also have other Open Source products installed on the Incoming Postfix server like:

• Horde / IMP for Webmail

And you can have Open Source products below on the ELSE server:

• Cacti, Nagios, Nagvis for monitoring

This solution is completely based on Open Source products.

Pros & Cons

This kind of architecture is interesting for small companies or individual users/engineers wishing to build a good messaging infrastructure for their own needs.

It materialize the basic "brick" to build a good shared messaging infrastructure, able to manage different domains, with dedicated statistics per mail flow and per domain that the ELSE can easily create.

It's also starting to be interesting to implement good security at firewall level, because email flows are clearly identified. And various "barriers" at messaging level can also be implemented. For instance, the MX records of the domains handled by your messaging system will advertise the Incoming Postfix server public IP only, while the SPF records of your domains will advertise the Outgoing Postfix server public IP only.

Also, Greylisting using softwares like Postgrey or the ELSE GreyLSE itself can be installed on the Incoming Postfix server only, where it is relevant, avoiding the analyze of the complete email flows then saving precious ressources.

Finally, the fact the ELSE have a dedicated server introduces only minimal changes to the Postfix servers. The Postfix servers will not be impacted by resource consumption generated by the ELSE server, and the ELSE server can be down for a reason or another without impacting your production Postfix servers. The ELSE particularly loves that your SMTP servers have identified roles, that will allow it to work using the full power of its features.

However, this infrastucture is not robust enough to be able to be qualified as a real state of the art, professional, one. Redundancy is not enough, adaptation to the load is not enough, and some functionnalities requested today would need to be running on other dedicated servers, like mailing lists that cause a lot of issues by blacklisting public IPs of your server due to the nature of their activity, or SMTP routing according to the sender and not to the recipient, allowing your users or your process to send emails on behalf of somebody else.

---

Top: [SMTP architecture examples] | Previous: [(ARCH) Very basic architecture] | Next: [(ARCH) Load proof architecture with Microsoft Exchange]