Email backbone

From Wikipedia, the free encyclopedia
Jump to: navigation, search

An email backbone is typically the middleware of an email infrastructure that manages SMTP-based applications, internal and external email message routing, and policy management and enforcement. The email backbone is normally the portion of the email infrastructure that "sits between" the gateway DMZ layer and the “email groupware system” layer of the messaging infrastructure, such as Microsoft Exchange or Lotus Notes/Domino. The email backbone is sometimes referred to as the messaging fabric or a messaging infrastructure layer[1]

Email backbone infrastructure and cloud computing[edit]

Many businesses are either considering or are actively migrating to cloud-based email because it can offer a number of important benefits. These benefits may include lower cost of ownership, more predictable costs, the shift from a capital expenditure (CAPEX) to an operational cost (OPEX) model, and less demand for internal IT resources.

The typical email infrastructure functions that are moved to the cloud include the email filtering layer for spam and virus protection, message archiving and the "email groupware system" mailboxes. The email backbone layer typically stays on on-premises.

Email backbone infrastructure and on-premises computing[edit]

The benefits of moving email to the cloud are compelling and quantifiable, but there are advantages to keeping the email backbone layer of the messaging infrastructure on-premises while leveraging cloud-based services for common email functions such as spam and virus filtering and the end user mailbox system, such as Microsoft Exchange. For example, an on-premises email backbone can provide policy management to enforce outbound messaging policies, such as encrypting sensitive messages, before the contents of the email leaves the organization.

Other benefits of an on-premises email backbone include the ability to manage a wide variety of mobile platforms at potentially lower cost, the ability to maintain legacy records management systems, and integration with existing voicemail systems.

Further, many organizations have complex routing and SMTP application requirements that require the use of an email backbone even after key parts of the email infrastructure have been migrated to the cloud. For example, routing and control requirements can be quite complex and often cannot be satisfied by cloud-based email systems. Examples of these requirements include:

  • Appending required disclaimers on outbound messages that are specific to particular countries to which emails are sent.
  • Establishing ethical walls between parts of an organization (such as the trading and transmission operations of an energy provider) to remain in compliance with statutory obligations.
  • Management of application-to-human communications, such as transaction alerts or communications from various types of office equipment (printers, scanners, copiers, etc.)
  • Human-to-application messages, such as communications with an automated help desk system, IT support applications with which employees and other communicate, or CRM systems.
  • Management of critical application-to-application communications, such as wire transfers between banks.
  • Email header address re-writing in order to preserve multiple domains.

Hybrid cloud and on-premises email architecture[edit]

At the enterprise level, the choice about how to manage email is not a decision about on-premises or cloud, but rather which services will remain on-premises and which will be managed in the cloud,.[2] Over the next several years, email management will evolve toward a hybrid model using an Email Backbone for virtually all but the smallest organizations.

References[edit]

External links[edit]