Architecture ReviewSystem

(1)

A U T U M N 2 0 0 9 Public Network External Application MTA External

Application MTA System1

System 2

Application

Mailers Exchange

IMAP Store AD / LDAP Administration

GUI Server SMD Master Internal Networks App Mail Backbone Corporate Mail Backbone DMZ

Fallback MTA External

Corporate MTAs

Internal Corporate MTAs

Messaging

(2)

Public Network

External Application MTA

External

System 2

Application

Mailers Exchange

GUI Server SMD Master App Mail Backbone Corporate Mail Backbone DMZ

Corporate MTAs

What do these organizations have in common?

• 7 of the world’s largest top 10 financial services organizations,

• 3 of the largest U.S. government agencies,

• The world’s largest telecom and technology providers, and

• 50% of all Fortune 1000 companies…

All have modernized their email infrastructure backbone as a result of

(3)

Issues and Concerns

<Client Name Removed> is a Fortune 500 Company with over 30,000 employees worldwide. The business receives more than 3 million email connection attempts per day. Prior to conducting the Messaging Archi-tecture Review—and ultimately implementing a new SMTP backbone with Sendmail—the business had:

• A highly complex, multi-layered email architecture

This occurs due to the lack of a strategic master messaging architecture plan. Without such a plan, an IT team constantly has to react to problems caused by the continued growth in email volumes. Such tactical approaches result in high maintenance, support, and administrative costs. It is also difficult to scale such an architecture.

• Ten different point products from multiple vendors for message routing, anti-virus, anti-spam, etc.

This issue presents a clear potential for cost savings through the elimination of redundant products. Replacing point products with a modern platform designed to run applications results in lower support costs and highlights the need for a master messaging architecture plan.

• A costly support structure with too many systems to manage

Many hidden costs can be reduced by moving to a modern messaging infrastructure. Doing so simplifies the management of email and lowers the costs of power, administration, ongoing support, and integration.

• A lack of a redundant architecture putting the email system at risk

Email is a mission-critical business communication system upon which users depend. Downtime and system failures can have catastrophic consequences for the organization.

• Ineffective security and disaster recovery architectures

As the architecture grows more complex, so do the number of potential failure points. Simple administration of updates can result in accidental security leaks—or worse. Modernization improves reliability, lowers the risks, and increases efficiencies for scalability.

• Antiquated message policies preventing users from doing their jobs effectively

Email has evolved into a service function integrated into business processes. A modernized architecture allows for centralized policy management for both incoming and outgoing messages; this enables users to use email as a tool without stress or worry about the efficiency or dependability of message processing.

Executive Summary

The following Messaging Architecture Review is a real architecture review that

Sendmail recently completed for a well-known global business.

The organization’s name and other proprietary information have been removed

from the report for privacy purposes. The company is referred to as <Client Name

Removed> in this report.

In some areas of the report third-party product names were removed for

trademark purposes.

IN T R O D U C T IO N

(4)

Sendmail Recommendations and Proposed Architecture Overview

Sendmail recommended that <Client Name Removed> simplify and strengthen its messaging environment by collapsing its “patched-together” infrastructure and implementing a true SMTP backbone. A Sendmail-based SMTP backbone leverages a core message processing platform, that allows the client to simply “plug in” applications such as reputation services, anti-spam, anti-virus, encryption, message tracking, and much more. All of these best-in-class applications are designed into the Sendmail Sentrion (see Appendix B for information on Sentrion) solution. Using this solution, the organization can manage its entire infrastructure from a single console and graphical user interface. This architecture enables the company to add additional applications at any time as their messaging requirements change.

<Client Name Removed> ROI

<Client Name Removed> achieved a significant Return On Investment by collapsing the complex multi-layered architecture into a more efficient and manageable SMTP backbone infrastructure. The ROI was achieved by:

For additional ROI information see page 12

Reducing the number of servers from 18 to 10, resulting in:

• Lower hardware and software maintenance costs

• Lower hardware and software support costs

• Lower hardware and software licensing fees

• Reduced power consumption

• Reduced rack space usage

• Lower overall heat dissipation

Reducing the number of point products from 8 down to a single platform and reducing the number of messaging vendors down to 2, resulting in:

• Reduced internal IT support costs

• Reduced vendor support and maintenance costs

• Simplified administration

(5)

Sendmail Messaging Architects

One of the biggest reasons customers choose Sendmail to help with their email and messaging infrastruc-tures is our unrivaled experience. Our unique team of experts has implemented solutions for some of the world’s largest enterprises and government organizations. While most IT managers are involved with 1 to 2 complex architectures during their entire career, our experts see 2 to 3 per month.

For a full listing of our Messaging Architects biographies see Appendix C.

Sendmail Sentrion Customers

This is a sampling of Global 2000 Sendmail customers that have modernized their SMTP backbone

infrastructure with Sendmail Sentrion Message Processors after completing a Messaging Architecture Review. Telecom and ISP

• British Telecom

• Disney Worldwide Services

• Sony

• Sprint

• Swisscom

Government and Defense

• BAE Systems

• Computer Sciences Corp.

• JPL/NASA • Raytheon • U.S. Senate Technology • Cablevision • EMC • Oracle • VeriSign Energy

• Florida Power and Light

• Southwestern Energy

• Valero

• Washington Gas

Life Sciences

• Bio-Rad Laboratories

• Blue Cross Blue Shield

• Ontario eHealth

• VWR International

Consumer and Retail

• Miele Corporation

• Ross Stores

• The New York Times

Financial Services

• Allianz Group

• Bank of Nova Scotia

• Charles Schwab • Citigroup • Credit Suisse • Deutsche Bank • Fortis Bank NL • JP Morgan Chase • Putnam Investments • Wells Fargo/Wachovia IN T R O D U C T IO N

(6)

(7)

Messaging Architecture Review for

Public Network

External

System 2

Application

Mailers Exchange

Corporate MTAs

(8)

Architecture Review Overview

Sendmail, Inc. Professional Services team reviewed the messaging architecture for <Client Name Removed> in 2009 with the entire <Client Name Removed> Messaging Team. During the assessment we discovered a complex multi-vendor messaging architecture that is expensive to maintain, difficult to manage and does not address key areas of security, compliance, and disaster recovery. This report outlines the current issues, desired outcomes, and proposes a solution that will reduce operating costs, simplify management, solve complex technical obstacles, and unify the <Client Name Removed> messaging architecture.

Current Architecture and Implementation

Scope of Review

Sendmail was engaged to review the portion of the <Client Name Removed> messaging infrastructure that exists between the Internet and the Exchange message store servers. This document only briefly discusses the Exchange environment as it pertains to message tracking and directory replication.

The Sendmail Messaging Architecture Review is designed to evaluate and provide short and long-term recommendations to optimize the messaging architecture.

To support this, we reviewed and/or developed the following:

• Existing architecture and implementation

• Existing issues and concerns

• Business objectives

• Short term recommendations

• Long term recommendations

• Recommended roadmap Our core methodology is to:

• Review current implementation and discuss architecture with operational team

• Discuss concerns and objectives with team and functional management

• Solicit additional future requirements from stakeholders

• Evaluate technical skill-sets and environmental considerations

• Integrate the above into a working architectural document

• Present findings as required

Discussion of Architecture

There are a total of five different layers in the <Client Name Removed> legacy, multi-vendor messaging envi-ronment. <Client Name Removed> uses Sendmail, <third-party-1>, and <third-party-2> for SMTP backbone services to manage messaging traffic between the Internet and internal Exchange message store servers. Email from the Internet can enter the internal network at two points: <City 1> and <City 2>. The entry point at <City 2> is disabled and does not normally accept email. In each location <Client Name Removed> uses MX records to provide load balancing. Within the primary site this also provides for failover but, at the <City 2> site there is no redundancy above the anti-virus layer. If <City 1> can no longer hit the Internet, several manual changes must be made before email can flow through <City 2> to/from the Internet.

Messaging Layer Overview

During the interview process the complexity of the environment was one of the largest concerns voiced by the entire messaging team. Whenever they had to troubleshoot email and peruse the log files across multiple vendor technologies it was a complex task, took far too long, and left the support staff frustrated. The following is a brief overview of the various layers of the current architecture.

(10)

2

Layer One

In Layer One there are 4 Internet facing DMZ Sendmail servers (3 in <City 1>, 1 in <City 2>). This layer serves as the perimeter defense for DNS blacklists and bounced email. The RBLs at this gateway block the majority of inbound connection attempts, resulting in a vast reduction of message traffic. This server has a large backlog of NDR messages because recipient checks are not done until Layer Two. There is a TLS requirement by <Client Name Removed> vendors and for that reason <Client Name Removed> operates one dedicated TLS server (<servername1>) that faces the Internet. Currently, this email gateway only handles email with those companies where TLS communication is required. This server handles no non-TLS email and no other servers have TLS enabled. During a disaster, all inbound/outbound email depends on a single <City 2> Sendmail gateway.

Layer Two

In Layer Two there are 3 DMZ <third-party-1> appliances (3 in <City 1>, 0 in <City 2>). These servers perform inbound anti-spam and recipient checks against a Lotus Notes Address Book in the DMZ. There is 1 <third-party-1> quarantine server in <City 1>. Of the email that is not blocked by the RBLs, most of the spam is checked at the second layer (the <third-party-1> anti-spam appliances.) Today, <Client Name Removed> quarantines only spam email. There are no rules in place to enforce and/or quarantine any inbound or out-bound compliance policies. These second layer appliances use IP reputation (via received headers), recipient validation, etc. There are a number of bounced NDR messages that occur because recipient checks are not implemented at the perimeter. During a disaster, all inbound email is not subjected to anti-spam, quarantine, or recipient checks.

Layer Three

In Layer Three there are 6 <third-party-2> servers (3 in <City 1>, 3 in <City 2>). These servers perform anti-virus scanning for all inbound and outbound email.

Layer Four

In Layer Four there are 3 Sendmail servers (2 in <City 1>, 1 in <City 2>). These servers perform routing functions between the various application servers, the Exchange network, and the <third-party-1> Layer. The Sendmail MTAs in this layer can be accessed by any internal user or application and no authentication is required. There are no options for managing, reporting, and securing all of the internal applications that are sending bulk/mass email to the Internet at this time.

Layer Five

In Layer Five there are 5 Exchange Bridgehead Servers (3 in <City 1>, 1 in <City 2>). These servers feed all the internal Microsoft Exchange servers world-wide.

Other Related Information

Some locations are required to add outbound disclaimers. This requirement is met by using a third-party tool called <third-party-tool> that runs on the appropriate Exchange servers. Desktop encryption software from <third-party-tool> and <third-party-tool> are being used within <Client Name Removed>.

Email Disposition

<Client Name Removed> receives about 3 million email connection attempts per day. Real-time Block Lists (RBLs) reduce the email volume by approximately 50%, allowing approximately 1.5 million of the remaining emails into the <third-party-2> anti-spam layer.

(11)

3

On average <Client Name Removed> sees the following results from the <third-party-1> anti-spam appliances:

• 46% are non-spam

• 3% are quarantined because they are suspected, but not confirmed, spam

• 20% are dropped because all recipients are invalid

• 31% are dropped because they are confirmed spam

Usage peaks at mid-morning to about 90,000 messages per hour (25 per second). Around 25% of these emails are left at the local filtering host, indicating a bad bounce, or other unwanted anomalies. Email delivery delay is good, at an average of 36 seconds, but there are a sizable number of emails taking exceptionally long for final delivery (more than 1 hour).

These results were calculated by Sendmail running a script called Sumdata against the primary Sendmail MTA logs for 24 hours. The results have been extrapolated from this data. With additional logs and time we can provide much more in-depth results if necessary. The complete results can be view in Appendix A. Current <Client Name Removed> Architecture

Exchange ex3 ex4 Sendmail MT A V-third-party2> Sendmail MT A LDAP Sendmail MT A Encryption Sendmail MT A <third-party-2> <third-party-1> Quarantine mailserver3 mailserver1 mail3 ServerQ LNotes100 mailserver1 mailserver2 b1 b2 b3 c1 c2 c3 mail1 mail2 d1 d2 d3 <thirdparty-1> LDAP N/A N/A N/A Quarantine N/A

Exchange ex4 ex5 ex6

Encryption hosmtp MX10 MX90 <City 1> <City 2> Layer 1 Layer 2 Layer 3 Layer 4 Layer 5 Standby DR Site Production Email Site

DMZ Internal Unix Servers Unix Servers bcsmtp test gateway Internet CLIENT

<Client name removed>

PREPARED

David Maislin

DESCRIPTION

Present Day Architecture: Sendmail MTA/<third-party-2> Reputation, <third-party-1> Antispam, <third-party2> AV, Sendmail Routing Layer

(12)

4

Issues and Concerns

During our review we spoke with several members of the <Client Name Removed> IT team. The primary point made by each individual was that there are too many systems to manage, it is difficult to troubleshoot email across different technologies, and that everything needs to be simplified.

Server Complexity

If you look at the current architecture diagram you will see that inbound/outbound messaging at <Client Name Removed> utilizes 18 servers. Ten of these servers are “point solutions” from multiple vendors. Lack of Redundancy

In the event that Internet connectivity to <City 1>, <City-3>, is interrupted for <Client Name Removed>, no automated failover can occur and, even following manual failover (presuming it can be initiated from <City 1> by the Messaging Team staff ), email will flow in a much degraded state (half the capacity, single point of failure, no TLS communication with partners, no recipient checks, and no anti-spam). All messaging traffic comes through a single data center (and has for the last 4-5 years). Manual failover is required in the event <City 1> becomes unavailable.

Log Searches

When a help desk ticket is opened it is very difficult—and always more time-consuming than desirable—to track email across multiple server logs. The logs exist in different vendor formats across multiple operating systems and the support team and end users get frustrated when searching for email tracking information. Logs are rotated at different intervals and finding older information is nearly impossible.

Recipient Checks

About 33% of all email that passes through the Sendmail gateways is addressed to invalid recipients. All of this bad recipient email bounces back from the <third-party-1> layer to the Sendmail layer, where it remains in the queues for days at a time. Most of this rejected email is sent from email addresses and domains that don’t exist and the Sendmail layer can’t deliver the rejection notices back to original address.

LDAP Directory Services

Directory services perform recipient checks to dramatically reduce the amount of email received by the <Client Name Removed> messaging servers. The Lotus Notes Address Book (NAB) directory responsible for this service is a single point of failure; it resides in the public DMZ, contains sensitive employee information, and all systems query this directory causing unnecessary network traffic. There are no directory services at the <City 2> disaster recovery location. During a disaster all inbound email is not subjected to recipient checks creating a flood of email bounces all the way into the Exchange environment.

Anti-spam

Gateway anti-spam filtering is based on <third-party-2> RBL. While RBLs are undoubtedly doing a great service for <Client Name Removed> at the gateways, message traffic not blocked by the RBLs is accepted by <Client Name Removed>, which is a major concern. By accepting the message, in effect, <Client Name Removed> is informing the spammers that the email addresses are valid.

(13)

5

Anti-virus

Anti-virus is handled by 6 <third-party-2> gateways server at Layer Three, passing through two different vendor technologies that could have dropped these malicious emails at the perimeter.

Message Size

Maximum message size is 7MB. This is likely a policy setting and, in 2009, not a technical requirement. By today’s standards, this is quite restrictive.

Quarantine

<Client Name Removed> is currently quarantining 3% of all inbound email as suspected spam. While this seems to be a small number, a quarantine consisting of 3% of inbound message traffic means that at any given time, roughly 1 million messages are in quarantine based on an assumption that messages stay in quarantine for 30 days.

The quarantine server resides in the public DMZ and access to this server is open to anyone possessing the URL link to an employee’s personal quarantine store. There is no authentication to the quarantine. The quarantine server resides only at the <City 1> location. During a disaster the quarantine is unavailable to all end users. If the quarantine server fails, all stored messages are lost.

Encryption

TLS and non-TLS traffic are currently handled by different server hardware. The <City 2> point of presence does not have TLS capability. In the event that a failover to <City 2> is required, the ability of the company to communicate in a secure manner with business partners is missing. In some instances this most-valuable email traffic could very well be interrupted (depending on recipient domain policies) until email service from <City 1> is re-established.

Recommendations

We recommend that <Client Name Removed> simplify and strengthen their messaging environment by implementing an SMTP backbone. A Sendmail-based SMTP backbone uses the Sendmail Enterprise Anti-spam application which leverages multiple spam fighting technologies, reputation services, and the Sendmail anti-virus application for virus protection. The Sendmail SMTP backbone also uses Voltage for encryption, and RPost for message tracking. All of these best-in-class applications are designed into the Sendmail Sentrion solution, allowing you to manage everything with a unified console across the entire organization. Additional applications are available and can be added to the Sentrion at any time in the future. Redundancy

Email failover should either be configured to happen immediately and in an automated fashion or the email environment should be reconfigured such that even in the event that a datacenter goes down, email continues to flow without interruption. <Client Name Removed> already has email infrastructure located in two data centers; it should be possible to configure both to be on-line full time and be able to manage all messaging traffic to the enterprise in the event that either data center is down. It is further recommended that <Client Name Removed> move from a disaster recovery design to a high availability design. A modern design will split messaging volume across two datacenters and guarantee 100% uptime.

Log Management and Retention

Implementing a centralized log reporting and analysis server will provide a centralized location for all logs from Exchange to the Internet. Modern log analysis systems such as <vendor> can unify all searches and reduce troubleshooting times from hours to seconds. <Client Name Removed> should also adopt a policy of extending log retention to a minimum of 30-60 days.

(14)

6

Recipient Checks

Recipient validation should take place on the perimeter gateway system. This will greatly reduce the amount of queued NDRs that today bounce back from the <third-party-1> systems to the Sendmail MTAs. By check-ing at the perimeter, the systems can immediately reject email and push the responsibility for the rejected email back to the remote sending email gateways.

We also recommend that <Client Name Removed> implement a perimeter outbound LDAP sender email address check policy where no email goes out with invalid return addresses; however, we understand that there are some situations where no return email is wanted—in these cases, we suggest a valid address be cre-ated and a rule established in the Sentrion Policy Engine that only allows NDRs to be delivered (i.e. real replies would be either dropped or returned to the sender with a note indicating that the address is not monitored by a human.) By delivering NDRs the list maintainers can update their lists and help police the environment. Localizing Directory Services

We recommend localizing replica LDAPs on the servers as well as using caching DNS servers to localize services and reduce the amount of servers that reside in the DMZ today. By localizing these servers to the Sendmail platform it will also decrease network load and latency while increasing performance.

Anti-spam

Anti-spam, content filtering, and recipient validation should be moved to the perimeter servers. This change will dramatically reduce email volume, NDR bounces, and allow better management of email at the internal routing layers.

Anti-virus and Zero Hour Threats

This service can and should be consolidated in the perimeter layer as the first layer of virus defense after traffic shaping, reputation, and anti-spam. Today, technologies such as Zero-Hour virus detection can catch new virus outbreaks that occur before traditional signature based solutions receive updates. By combining Zero-Hour with the traditional anti-virus signature based solutions at the perimeter it can further reduce the chance that a new virus will infect internal systems.

Increase Message Size Restrictions

Many messages contain attachments that are quite substantial in size. Large Microsoft Office documents with pictures can easily exceed the <Client Name Removed> limit. It is recommended to increase the limit to a minimum of 15MB. Policies can be put in place to content scan and reject messages that are too large, instructing senders to use an alternative means to deliver their files.

Quarantine

Using multiple-engine anti-spam scanning techniques, it is reasonable to expect that 60-80% of the messages currently being quarantined could be safely identified as spam and dropped resulting in a much smaller and more manageable quarantine.

Access to the quarantine server must be secured and available only to end users possessing the correct authentication credentials, integrated with Active Directory. It is also recommended that the quarantine server solution support the ability for end users to delegate access to their queues. This will allow execu-tives to delegate quarantine access to their support team without giving up their passwords. If messages are quarantined for a specific distribution group, this feature will allow the owner—or all members of the group—access to any quarantined email.

(15)

7

Encryption

It is sometimes desirable to encrypt certain outbound messages (Human Resources information, for example) at <Client Name Removed>. End users may desire to encrypt email for a variety of reasons ranging from confidentiality to personal information security. For reasons stated above, desktop encryption is not a best practice. We recommend that <Client Name Removed> investigate and implement encryption in advance of demand. A good encryption service will work as an integral component of your messaging server.

<Client Name Removed> encryption needs should be handled by an enterprise encryption solution integrated across all email policy gateways. Opportunistic TLS should be enabled across all servers on the perimeter. Where TLS is required, it can be set up per domain server with varying degrees of certificate strength.

We recommend establishing a policy that desktop encryption (i.e. encryption at the client, such as <vendor> for Outlook) be generally disallowed. If at any time in the future the messaging team is tasked with any form of message monitoring or archiving, desktop encryption will cause problems as only the sender will be able to view, monitor, or access the encrypted message. Sendmail Sentrion provides for Voltage, S/MIME, and TLS based encryption.

Bulk Email

All email is not created equal. When a large emailing list is sending email it can quickly load up email gateway queues causing higher-priority business email to back up. We recommend implementing a process to identify high-volume events and redirect the traffic to either low-priority queues or the dedicated bulk-email servers. Sentrion can do this for you.

Sender Policy Framework (SPF)

<Client Name Removed> has no SPF records. SPF validates the message envelope (i.e. the Mail-From portion of the SMTP conversation); allowing recipients to be certain that the message is actually from the domain found in the return address. Please see http://www.openspf.org and Wikipedia for information about Sender Policy Framework. By implementing SPF, the <Client Name Removed> Messaging Team can improve outbound delivery of email and more fully embrace current trends in messaging.

Domain Key Identified Mail (DKIM)

DKIM is a low-cost and potentially high-return email standard that <Client Name Removed> should embrace. We recommend immediately moving to using DKIM on all outbound traffic and simultaneously considering checking and verifying inbound messages for DKIM signatures. Please see http://www.dkim.org for more infor-mation. DKIM (as opposed to SPF) validates the contents (including headers) and is complementary to SPF. Bounce Address Tag Validation (BATV)

Backscatter is a form of spam that appears to the email server to be a “bounced” message (mis-addressed, mailbox full, etc.) that is passed to the person identified as the sender—often with no anti-spam testing at all. This is a growing problem. We recommend that <Client Name Removed> investigate BATV. BATV allows the email server to determine if a given bounce message is actually from the internal sender or if it is a spoof—and spoofed bounces can be dropped.

Email Compliance

We understand that requirements are in place to stop the transmission of private or confidential information; however, it is only a matter of time before a serious violation will occur. In the meantime, perhaps <Client Name Removed> staff that are not working directly for a client user (like the payroll department, IT, etc.) could be limited in their abilities to send potentially embarrassing or legally actionable information out via email…then when the requirement does come along, the <Client Name Removed> Messaging Team will have a solution in-place. The Sendmail Sentrion will do the bulk of this work for you.

(16)

8

Proposed High Availability Architecture

High Availability Mode

High availability designs are an alternative to a disaster recovery mode. If the <City 1> location is offline because of a large network outage or disaster, the <City 2> network is always on and no steps are required to ensure that email continues to flow.

Architecture Diagram

Exchange _server4 _server5 _server6

Exchange

server3 server4

Internet

<City 1> <City 2>

CLIENT

PREPARED

David Maislin

DESCRIPTION

HA Architecture: Sendmail Sentrion MP 351 for mail routing, and Sentrion MP 352 for the console/ldap/quarantine:

PAGE 2 of 3 REVISED Y-Y-2009 DATE X-X-2009 Sentrion MP 351 Sentrion MP 351

·Routing Mail Gateways (2)

·Sentrion MP 351 (1U)

·Policy and Compliance ·Routing ·SMTP Authentication ·LDAP Replica ·Routing Mail Gateways (2)

·Policy and Compliance ·Routing ·SMTP Authentication ·LDAP Replica Sentrion MP 351 Sentrion MP 351 MX10 MX10

·Internet Mail Gateways (2)

·Sendmail MTA with DKIM/BATV ·Traffic Shaping ·IP Reputation ·Antispam & Antivirus ·Policy and Compliance ·LDAP Replica/Recip. Checks ·Integrated Encryption

DMZ

Internal

Sentrion MPV Test Gateway

AD Server Unix Servers Unix Servers AD Server

(17)

9

Recovery Mode Diagram

High Availability Steps

• Both sites are always on, always processing email.

• A monitor script switches the <City 2> Console/Replica to a Master Console/LDAP Master when the production site is down based on any number of tests:

- Heartbeat ping timeout exceeds a certain threshold. - Email round robin test fails after a certain number of tests. - External SNMP monitoring application triggers an event.

• The monitoring script will automatically switch the <City 2> systems into production mode.

• Standby Console/Replica becomes <City 2> Master Console/LDAP Master.

• All available MTA configurations switch the quarantine to <City 2> Quarantine.

• <City 2> LDAP Master replicates data to all available MTA Replicas.

• Dirsync process is enabled and syncs from <City 2> Active Directory server.

• When the <City 1> site is back online, the monitoring scripts will automatically switch everything back.

Exchange _server4 _server5 _server6

Exchange

server3 server4

Internet

<City 1> <City 2>

CLIENT

PREPARED

David Maislin

DESCRIPTION

HA Recovery Mode: Sentrion MP 351 for mail routing, and Sentrion MP 352 for the console/ldap/quarantine

PAGE 3 of 3 REVISED Y-Y-2009 DATE X-X-2009 Sentrion MP 351 Sentrion MP 351 Sentrion MP 352 Console LDAP/Quarantine

·Policy and Compliance ·Routing ·SMTP Authentication ·LDAP Replica

·Policy and Compliance ·Routing ·SMTP Authentication ·LDAP Replica Sentrion MP 351 Sentrion MP 351 MX10 MX10

·Sendmail MTA with DKIM/BATV ·Traffic Shaping ·IP Reputation ·Antispam & Antivirus ·Policy and Compliance ·LDAP Replica/Recip. Checks ·Integrated Encryption secondary dirsync DMZ Internal Sentrion MPV Test Gateway

AD Server Unix Servers Unix Servers AD Server

MX10 MX10

recovery sync recovery sync

(18)

10

Phases of Deployment

To reduce risk exposure, we recommend deploying a new infrastructure in several stages/phases, as defined below:

Phase I: Validation

• Capture a copy of all email, including spam and virus, for one week using a copy milter to a special Lotus Notes server to be used as a validation/test corpus.

• Rack (1) console/quarantine/log, (1) DMZ replica, (1) Internal replica.

• Setup Sendmail directory syncing (dirsync) to console.

• Setup logging-only policies that mirror <Client Name Removed> legacy filters, as well as <Client Name Removed> chosen RBL.

• Configure to pass all processed email to legacy <Client Name Removed> filtering environment.

• Test each component and routing.

• Add appropriate IPs to appropriate MX lists.

• Turn on email flow through validation equipment.

• Enable and test opportunistic TLS encryption.

• Add and test mandatory TLS encryption routes.

• Send the email corpus through the environment.

• Monitor, evaluate, and compare results using the total email corpus.

• Modify components as required and repeat monitoring and evaluation steps until design is validated.

• Convert log-only to action-taking policies, and repeat monitoring and evaluation steps until conversion is validated complete.

Phase II: Implementation

• Setup new cluster architecture side-by-side with <Client Name Removed> legacy architecture. All email continues to process through legacy environment.

• Migrate all required email policy and word lists to new environment.

• Setup directory and quarantine server sync between <City 1>, <City-3> and <City 2>, <City-4>.

• Setup authd on internal quarantine server to allow authentication to internal Active Directory.

• Setup centralized syslog-ng logging facility.

Phase III: Testing

• Test directory and quarantine server sync between <City 1>, <City-3> and <City 2>, <City-4>.

• Test inbound/outbound email delivery on each replica individually and incrementally.

• Test quarantine summary reports and authentication integration on both <City 1>, >City-3> and <City 2>, <City-4> console/quarantine servers.

• Test syslog-ng logging to centralized logging facility.

• Test disaster recovery failover from <City 1>, <City-3> to <City 2>, <City-4>.

• Test end-of-disaster restoration from <City 2>, <City-4> to <City 1>, <City-3>.

Phase IV: Deployment

• Enable logging across all legacy and new systems to new centralized logging facility in addition to <Client Name Removed> legacy logging environment.

• Turn on all required policies, anti-virus, anti-spam, quarantine, and recipient checks.

• Switch MX records to migrate older edge gateways to new Sentrion appliances using a deterministic method of adding or removing one system at a time. This will minimize risk.

• Email is now processing through new environment.

(19)

11

Phase V: Demonstrate Additional SMTP Backbone Functionality (Optional)

• Demonstrate inline DLP and event management capabilities.

• Implement Voltage policy based encryption for a subset of users.

• Show how to create policies based on LDAP directory attributes.

• Demonstrate other Sendmail policies and capabilities.

Phase VI: Training

• Training classes taught on site in <City 1>, <City-3>.

• Knowledge transfer.

• Complete documentation and deliver to <City 1>, <City-3> postmaster team.

Conclusion

Sendmail has spent considerable time ensuring that this document addresses issues the messaging team faces today and provides a total solution designed around the desired outcome of the <Client Name Removed> team for the future. When you modernize the SMTP backbone, the benefits and ROI will be clear. The use of Sendmail Open Architecture Messaging backbone provides cost-saving benefits over the long term. These benefits include:

• The enterprise strength solution will reduce the hardware footprint from 18 servers to 12 servers, or 10 servers with a high availability deployment. Additional costs savings are realized with lower maintenance and reduced energy consumption, while improving overall email SMTP backbone management.

• LDAP servers with sensitive data no longer reside in the DMZ. No separate LDAP servers are required as LDAP is integrated into the Sentrion solution. Integrated directory services are unique to Sendmail whereas all other competitive products require additional directory servers external to a core solution. Email related LDAP information is replicated from the console master in the private network to every local Sendmail Sentrion appliance. Every component in the Sendmail solution is directory enabled, allowing you to construct policies based on any number of directory attributes:

• Piloting new requirements safely: LDAP attributes can be utilized to pilot new initiatives in as granular a method as needed. Such piloting does not affect non-pilot-targeted emails. When ready to advance to the next stage, a simple LDAP attribute change is all that is generally required.

• Location and Language: Add native disclaimers by country or language.

• Compliance: Encrypt or quarantine based on country specific compliance regulations.

• Archive: Route email from legal departments to an archive system.

• All anti-spam, recipient checks, and other vital services work the same across both datacenters on the same hardware. Further, recipient or sender email address checks can be performed locally at every layer without creating additional network traffic or depending on other servers. This new design will ensure that all disaster recovery risks are mitigated while maximizing efficiency and performance.

• The Sendmail quarantine solution supports bi-directional synchronization. If the primary site is down for any reason, end users will not lose any email.

• If you wish to further reduce costs by implementing green initiatives, the Sendmail Sentrion solutions can run on VMware. Virtual deployments can help organizations reduce rack space requirements and energy consumption.

(20)

12

• A reduction in point products from 8 down to a single messaging processing platform and a reduction of vendors from 4 to 2 will simplify the messaging environment, reduce overall support and main tenance costs, and require fewer personnel to manage the total solution.

• Centralized logging is used for all log searches, reporting, and troubleshooting. The entire messaging team will be able to monitor the total system and track messaging from Exchange all the way to the external recei-ving MTA. Additional tracking can be enabled all the way to the desktop of the remote recipient if required.

• The architecture can function as a disaster recovery fail-over or as a highly available environment with no change to the current design. Whether you decide to implement a standby solution now or plan for high availability at a later date, you can be assured that the architecture will not require significant change.

Example Cost Reductions and ROI Analysis

Sample ROI analysis replacing existing servers with Sentrion MP (hard appliances) <Client Name Removed> proprietary data has been removed.

Sample ROI analysis replacing existing servers with Sentrion MPV (virtual) <Client Name Removed> proprietary data has been removed.

<Client Name Removed> can achieve a significant ROI by collapsing the complex multi-layered architecture into a more efficient and manageable SMTP backbone infrastructure. The ROI is achieved by:

Current environment (server types, e.g. Sun)

Proposed environment (Sentrion MP on current environment) Difference (MP vs. current) Number of Servers <> <> -59% Electrical Power (W) <> <> -20% Footprint (U) <> <> -60%

Heat dissipation (BTU/h) <> <> -56%

Current environment (server types, e.g. Sun)

Proposed environment (Sentrion MP on current environment) Difference (MP vs. current) Number of Servers <> <> -92% Electrical Power (W) <> <> -93% Footprint (U) <> <> -92%

Heat dissipation (BTU/h) <> <> -93%

Reducing the number of servers from 18 to 10, resulting in:

• Lower hardware and software maintenance costs

• Lower hardware and software support costs

• Lower hardware and software licensing fees

• Reduced power consumption

• Reduced rack space usage

• Lower overall heat dissipation

Reducing the number of point products from 8 down to a single platform and reducing the number of messaging vendors down to 2, resulting in:

• Reduced internal IT support costs

• Reduced vendor support and maintenance costs

• Simplified administration

(21)

13

Appendix A

Appendix A: Host: <servername1>.<Client Name Removed>.com

<Note: some detailed statistics have been removed from the appendices for simplicity purposes> Summary statistics

---Total messages received: 528406

Total attempts to send: 955478

Total sent messages: 406421

Total unique queue IDs for sent messages: 404935

Total recipients attempted: 1020871

Total recipients sent: 466540

Mean message size (bytes): 79558

Hourly total of sent messages: <data removed>

Delivery location summary of sent messages: <data removed>

Mailer breakdown of sent messages: <data removed>

Mean delay and xdelay times of sent messages: <data removed>

Summary delay time modes of sent messages ( seconds | count ): <data removed>

Summary xdelay time modes of sent messages ( seconds | count ): <data removed>

Stat summary of all attempted messages: <data removed>

Appendix B:

Similar data as above for another server

<data removed>

Appendix C: Host:

Similar data as above for another server <data removed>

(22)

14

Appendix B

About Sendmail

Sendmail provides appliance-based products, applications, and services that enable enterprises and govern-ment agencies to modernize their messaging infrastructures. Since 1982, thousands of commercial and open source customers around the globe have relied on Sendmail for a unified approach to the complex problems of policy-based message handling and routing. The company’s comprehensive suite of applications addresses the challenges of gateway management, inbound threat protection, data leak prevention, email authentica-tion, and intra-company message management. These applications run on the Sendmail family of Sentrion®

Message Processors, which are available in hard appliance, virtual appliance, blade server, and as an SaaS offering. Sendmail is headquartered in Emeryville, CA with sales and support offices throughout the Americas, Europe, and Asia.

Modern messaging systems need to be extremely flexible to meet the ever-changing needs of enterprise-scale implementations. Sendmail has recognized the need for flexibility and has engineered its products with this in mind. The Sendmail Sentrion is not just an “email server”—or “email appliance”—it is a messaging platform designed to facilitate implementing messaging applications to support the varied needs of enterprise customers.

Sendmail products are not stand-alone products. In every case, Sendmail products are required to interoper-ate with third party applications and existing network infrastructures. Because of this, Sendmail depends on industry standards and is a proponent of, and participant in, developing, enforcing, and extending existing standards and pioneering new standards.

About Sentrion Message Processors

Sentrion Message Processors are high-performance message security appliances that provide a unified solution to the complex problems of policy-based message handling and routing. Sentrion is available in a hard appliance (Sentrion MP), virtual appliance (Sentrion MPV), blade server (Sentrion MPQ), and as an SaaS offering (Sentrion Cloud Services).

Sentrion Message Processors are used for external protection and internal policy management, including:

Border Protection and Gateway Management • Secure and reliable message encryption, routing,

and delivery

• Connection controls and rate throttling

Inbound Message Processing and Protection • Spam, virus, and malware protection

• IP reputation services

Internal Policy and Routing

• Sophisticated policy enforcement, message handling, and routing

• Intelligent directory-based message routing

• Managed message flow and routing for email generating applications

Email Authentication

• Authentication of incoming messages to fight phishing and fraud

• Digital signing of outgoing messages

Outbound Data Leak Prevention

• Highly accurate, in-line content monitoring and enforcement

• Policy-based message handling, routing, delivery, and encryption

Message Management for Mixed Groupware Environments

• Enforces internal intra-company/division and outbound message policies

(23)

15

Sentrion Architecture

Sendmail MTA Policy Engine Connection Controls Authentication Directory Quarantine

Sentrion MP

Appliance Sentrion MPQBlade Server Virtual ApplianceSentrion MPV Sentrion CloudServices

Sentrion MPE

A P P LI C A T IO N S M E S S A G E P R O C E S S IN G E N G IN E D E P LO Y M E N T O P T IO N S Anti-Virus Reputation Anti-Spam Authentication Traffic Shaping Authentication Incident Remediation In-Line Encryption Data Leak Prevention

Content Monitoring

Legacy & Future Instant Messaging Risk & Compliance ICAP (HTTP, FTP) Milter Applications

Inbound Outbound Non-sendmail

Red Hat Linux OS

(24)

16

Biographies

Robert Boucneau

As a customer before joining Sendmail in 2008, Bob Boucneau led his team in developing and implementing a fully redundant email transport system for a $1.6 billion dollar company with more than 100 offices in 40 coun-tries. Beginning in 2006, Bob and his team re-engineered, prototyped, deployed, and managed a new Sendmail-based SMTP backbone that served all world-wide employees. For ten years prior, Bob was a third-party consultant, responsible for the design, implementation, and support of more than fifty Sendmail-based email systems in and around Denver, Colorado.

Michael Donnelly

Michael Donnelly has been involved in computing infrastructure and IT since 1991, specializing in integrat-ing messagintegrat-ing infrastructure with directories. Early in his career, Mike worked at Sybase and Pixar Animation Studios where he helped make directory-driven infrastructure a reality. Before becoming an Application Solutions Architect with Sendmail in 2001, Michael ran the Sendmail IT infrastructure, managing email, directory, networking, and security infrastructure. Mike thrives on finding solutions for complex environments and his “wins” include secure deployments for military and government applications, high reliability / high performance solutions for aerospace, as well as successful solutions for large corporate customers.

Kin Fung

With over five years of email backbone solution design experience, Kin Fung is a key member of the EMEA team based in the UK. Kin has been involved with numerous major global customers—including Citi Bank, Deutsche Bank, BT, Orange, PWC, and UTC—helping them re-architecture their systems to improve and modernize their email backbone. With his extensive experience and background in programming, System Analysis, and Business Process Management, Kin is able to effectively understand and solve his customer’s challenges, unique requirements, and goals; ultimately helping to design a backbone architecture which is efficient, resilient, and generates a high ROI with accelerated time to value.

David Gillam

David Gillam has over 20 years experience in both small and large messaging environments. He understands the mission critical nature of email to today’s businesses, and designs security, fault tolerance, and redundancy into each architecture solution. While working with a US defense contractor with a worldwide presence, David and his team implemented a series of changes to increase availability, disaster resistance, and filtering effectiveness—from ~50% to 99.98%—with no notice-able downtime for the email service. Most recently, David and his team replaced the entire email infrastruc-ture of this same defense contractor with the Sentrion messaging platform—across 4 time zones—in a way that was transparent to all customers and resulted in a 35% savings in power/cooling, a 50% savings in rack space, a 60% increase in email capacity, and a filtering cost benefit of approximately $10/user per month.

Boris Kleint

Boris Kleint—a Sendmail messaging solutions architect since 2000—has spent his tenure developing highly customized implementations for mail routing and mes-sage policies throughout Germany, Switzerland, and the UK. He specializes in major, large scale Sentrion deploy-ments. Prior to Sendmail, Boris gained expertise through extensive work in sales engineer network management, systems management, as well as commercial data center experience as a Systems Programmer.

Jeff Kopko

An ultimate Sendmail road warrior, Jeff Kopko spends between 60-70% of his time on the road helping customers get the most utility and ROI from their messaging infrastructures. Jeff’s expertise encompasses everything from SMTP email routing and delivery to AV- and AS-filtering, DLP (Data Leak Prevention), DoS (Denial of Service attacks), TLS encryption, DKIM (Domain Keys Identified Mail) signing, and LDAP (Light-weight Directory Access Protocol) based email address recipient validation services. Large enterprises through-out the United States and Canada have relied on Jeff to fine-tune their systems for maximum performance and immediate payback.

Appendix C

Sendmail Messaging Architects

(25)

17

David Maislin

Twenty years ago, David Maislin worked in UNIX administration when even simple access to the public Internet was severely restricted. Rooted in email from mainframe PROFS, he gradually migrated Motorola’s first SMTP distributed email platform based on TOPS Inbox, ccMail, and open source sendmail as the corporate MTA. Over the next 10 years, David consulted with many large enterprise organizations such as American Express, Charles Schwab, and Motorola, managing their entire UNIX infrastructure, email, LDAP, and DNS. Subsequently, David went to work in sales engineering and consulting for various software start-ups specializing in identity validation, single sign-on, and email encryption for com-panies such as Securant, RSA, Sigaba, and Tumbleweed Communications.

Chris Meidinger

With a long background at the confluence of messaging and network security, Chris Meidinger holds numerous professional certifications, including Microsoft Certified System Engineer and Certified System Administrator and GIAC Certified System and Network Auditor. Prior to joining Sendmail and taking on responsibility for solution design and technical pre-sales in the Nordics, Benelux, and central Europe, Chris advised start-up enterprises, securing both public and private sectors. His expertise includes a strong working knowledge of Internet messaging, network management, penetration testing, security and network auditing, security imple-mentation, and incident response. Traveling extensively throughout Europe to many of the top companies on the continent, Chris is known for making the impossible happen—successfully and on time.

Toni Offermanns

For the past eight years, Toni Offermanns has been a key player on the Sendmail Technical Services team. Based in Germany, he manages the professional services, pre-sales, and technical support team for EMEA and has led sales efforts to secure large enterprise customers includ-ing Credit-Suisse, T-Systems Switzerland, Miele, Vodafone Global, AGIS (Allianz Group Information Service), REWE Germany, and many others. Toni serves on the product steering committee, responsible for the design and ini-tial development of new products such as the Sentrion Open Edition, an open email appliance, and Sendmail Nagios monitoring enhancement.

Ozi Suemasa

Nobuhiro “Ozi” Suemasa helps bring Sendmail expertise to the Land of the Rising Sun. Based in Tokyo, Ozi has more than 15 years of open source sendmail and commercial Sendmail experience, having designed and implemented numerous large email systems for ISPs, xSPs, and large enterprises throughout Japan. An experienced programmer, Ozi is fluent in Windows, Linux, UNIX, and C/C++, and was a key contributing member of the Japan Email Anti-abuse Group (JEAG) which recommended the implementation for Sender Authentication Technology. Ozi has also written numer-ous articles on topics such as email system technology, Anti-Spam, and Sender Authentication (DKIM, SPF, SenderID) for various IT magazines and websites.

Ranell Winchester

With over 24 years of sendmail open source experi-ence, Ranell Winchester helps enterprises starting out as open source users successfully migrate to Sendmail appliances. At the University of Maryland, Ranell man-aged over 1000 UNIX boxes, including email servers in 40 departments. She also worked for an aerospace firm with one of the first deployments of STARTTLS, SMTP-AUTH, and LDAP-based routing. Ranell has been a consultant to several defense contractors and government agencies on email and encryption. She joined Sendmail Professional Services in 2000, and has a strong background in encryption, authentication and authorization, directory services, DNS, large scale system administration, and SMTP.

Christophe Wolfhugel

Christophe Wolfhugel, who is an integral part of the EMEA team and based in London, has been involved with mail systems, particularly Sendmail, since 1990. He has designed and deployed complex messaging infrastructures for major customers in the industry and banking sectors across Europe and the U.S. Prior work experience gained Christophe expertise not only on applications, but also with large enterprise IP networks. During the 1990s, Christophe co-founded the first French professional ISP, Oléane, which was subsequently acquired by France Telecom. There, he designed his first large email platform with opensource sendmail. He has also worked as a Network and Systems Engineer at Insti-tut Pasteur, and as a security consultant for HSC, where he implemented Sendmail-based email filtering.

(26)

18

(27)

Public Network

External

System 2

Application

Mailers Exchange

Corporate MTAs

(28)

Sendmail, Inc.

6475 Christie Avenue, Suite 350, Emeryville, CA 94608 USA Tel: +1-888-594-3150 | Fax: +1-510-594-5429 Email: [email protected] www.sendmail.com Public Network External Application MTA External

System 2

Application

Mailers Exchange

Corporate MTAs

Architecture ReviewSystem

Messaging

What do these organizations have in common?

• 7 of the world’s largest top 10 financial services organizations,

• 3 of the largest U.S. government agencies,

• The world’s largest telecom and technology providers, and

• 50% of all Fortune 1000 companies…

All have modernized their email infrastructure backbone as a result of

Executive Summary

The following Messaging Architecture Review is a real architecture review that

Sendmail recently completed for a well-known global business.

The organization’s name and other proprietary information have been removed

from the report for privacy purposes. The company is referred to as <Client Name

Removed> in this report.

In some areas of the report third-party product names were removed for

trademark purposes.

Sendmail Recommendations and Proposed Architecture Overview

<Client Name Removed> ROI

Sendmail Messaging Architects

Sendmail Sentrion Customers

Messaging Architecture Review for

Table of Contents

Architecture Review Overview

Current Architecture and Implementation

Issues and Concerns

Recommendations

Proposed High Availability Architecture

Phases of Deployment

Conclusion

Example Cost Reductions and ROI Analysis

Appendix A

Appendix B

Sentrion MPE

Red Hat Linux OS

Appendix C

Sendmail, Inc.