Strategies for Defending Email Infrastructure

Why is email security important?

Email use has replaced the telephone as the predominant business tool for communicating with employees, customers, suppliers, and management. In 2004, IDC estimated that each day there are more than 30 billion email messages crossing the Internet; this estimate does not include email communication within an organization, where the messages never cross the Internet in the first place. The Radicati Group estimated that in 2004 there were nearly 900 million active mailboxes on the Internet with approximately half of these being used for business purposes.

Clearly, email systems and email communication has become extremely pervasive in business environments as a result of the ease with which information can quickly and efficiently be disseminated to one or many people anywhere in the world. The Meta Group estimates that approximately 75 percent of all corporate knowledge is now communicated via email.

74 percent of business people surveyed recently believed that losing email service presents more of a hardship than losing telephone service (Source: META Group survey).

As email systems have evolved and become more pervasive, the types of information that are being moved between users have changed. In early LAN-based mail systems, the typical email contained simple information and fairly innocuous data such as "What are you doing for lunch?" or "Let's meet to discuss the Acme proposal." Today, emails frequently and routinely contain business-critical, personal, and confidential information. As employees and managers rely on this information being available, email administrators have increasingly focused on maintaining higher levels of availability and performance for their users.

In the past, email administrators gave little thought to the possibility of dangerous email content arriving on their users' desktops via email. That all changed on March 26, 1999 when a macro virus called Melissa spread almost overnight to tens of thousands of computers by exploiting the Exchange Global Address List (GAL). Some mail systems were crippled because the message transfer agent (MTA) queues had hundreds of thousands of messages to be delivered to both local and remote mailboxes. In 2000, the second act came in the form of the Love Bug virus (know as such because the subject line contained the words I Love You). Computer Economics estimated that the cost to fight and eradicate the Love Bug virus came close to $9 billion dollars.

Unfortunately, the standard method of email communication over the Internet uses the Simple Mail Transfer Protocol (SMTP); SMTP was designed to transmit 7-bit ASCII character data between two IP hosts using the simplest and most efficient method possible. Security was an afterthought with SMTP, and security systems are almost never implemented by default in an SMTP-based mail system. Further, the threats against an email system and its users have emerged just as quickly as the growth of the number of mailboxes.

Consequently, typical email administrators are spending more and more of their time not only focusing on the availability of their mail systems but also ensuring that both the system and the information are secure. The now invasive nature of spam and phishing attacks requires new mechanisms for ensuring that only valid messages reach the intended recipients.

Evolving Threat Landscape

Email administrators and IT managers now look back to the days of email-based threats such as the I Love You virus or Melissa and feel a little bit nostalgic. Although these threats are just as potentially damaging as today's threats, viruses such as the Love Bug virus were much simpler to defend against than the new threats that email administrators and users face today. The line between a virus, worm, and Trojan horse has been so blurred that they are now lumped into a single category called malware. Spam and phishing scams not only threaten productivity but also have the potential to perform identity theft. Further, as a result of email systems being so easy to use, accidental or malicious disclosure of sensitive or damaging information has become even easier to accomplish.

As if to add insult to injury, spammers are now teaming with virus writers to use viruses and worms to spread spam by building distributed networks of spam bots. Some security experts believe that floods of spam or viruses may be used to do political or economic harm in the future. Although this scenario might seem unlikely, imagine the costs involved in an organization of 1000 employees, each of whom have to spend 30 minutes of their day sorting through the junk in their mailbox in order to find the legitimate messages. For argument's sake, let's say that each of those employees costs the company $20.00 per hour. So, for each employee, it costs the organization $10.00 per day for that person to sort through their spam, or a total of $10,000 per day. And that is 30 minutes of that person's day that they should have spent doing their job.

Malware Comes to Town

The collective term for hostile or malicious email content is now simply malware; malware is any program that is potentially harmful to the user, the user's computer, the email system, or the network. The malware category includes viruses—a virus is a small program that attaches itself to another program running on a computer. Anytime that "infected" program is executed, it attempts to infect other programs.

Worms

This malware category contrasts with its cousin the worm; the worm goes out looking for computers (usually with a specific vulnerability) on which to replicate itself. Once the worm has been executed, the original infected program does not have to continue to run because the program is loaded in memory and begins searching the network for other computers to infect. A worm may also open backdoors on the compromised computer and lower security settings. The infamous SQL Slammer is an example of a worm that exploits a known weakness; the SQL Slammer worm managed to infect computers worldwide within 10 minutes of its initial release. A Yankee Group study found that in 2003, more than 80 percent of businesses that had Internet connections experienced disruption in business due to worms and viruses.

The terms virus and worm are often (and sometimes incorrectly) used interchangeably and often worms are generically categorized as viruses.

Trojan Horse

An off-shoot of viruses and worms is the Trojan horse. A Trojan horse is a program that appears to be harmless or to do one thing, thereby tricking the user into opening the program. Once the program is running, it executes hostile code or attempts to collect information.

Blended Threat

Blended threats are threats that have characteristics of a virus, worm, and/or Trojan horse. These threats use a combination of malicious code and exploitation of vulnerabilities to propagate. Most of the email-based threats and other viruses that are common today are blended threats. Malware such as the Sober virus and its variants can access a user's personal address book, but uses its own SMTP engine to propagate. A client infected with Sober can connect internal email servers (bypassing firewalls and SMTP inspection systems) and deliver infected messages directly to internal mail servers as well as external mail servers. This virus can clog SMTP queues, delay delivery of legitimate email, consume Internet bandwidth, and generate complaints from your ISP.

Phishing

Phishing schemes have emerged as one of the biggest threats to users personally. Phishing comes from the idea that you toss out a line and see who will grab it. The messages usually look reasonably legitimate and may actually appear to come from an organization from which you do business. Figure 1.1 shows an example of a phishing scheme.

Figure 1.1: An example of a phishing scheme.

Often, phishing schemes can be exposed because you are receiving a message from a bank with which you do not do business or there are a lot of typographical errors in the message. The message in Figure 1.1 was received right at a time in which the credit card I used on PayPal was about to expire, so it did make me think twice. However, not even your bank will ever ask you for your ATM PIN, so that request was the final clue that this message was fraudulent.

For the technically adventurous, you can view the HTML source of a message. When I did so for the message that Figure 1.1 shows, the HTML revealed that when the logon button was clicked, it would take you to the link shown in Figure 1.2. In the figure, I have highlighted the actual domain name to which the information is sent. Notice that the author of this message attempted to mask the intent of this message by putting www.paypal.com in the front of the URL, but followed that with many 1s and 0s.

Figure 1.2: The "real" URL exposed.

Email administrators must be concerned that users will be defrauded or have their identities stolen by such a scam, but organizations need to be concerned as well. In the not-too-distant future, a user that has been scammed by a phishing scheme is going to have a creative lawyer that is going to hold their email provider accountable for receiving the email in the first place.

Spyware

Spyware is another form of malware that can be spread via email. Spyware is any program or technology that will gather information about a user's activity when they use their computers. In the early days of spyware, Internet marketing companies would use this software to determine a user's Web surfing habits and generate pop-ups that were targeted to that user's interests; this is also called adware. If those annoying pop-ups were not bad enough, users can just as easily be tricked into loading spyware that performs keystroke logging or that scans the user's hard disk for sensitive information and transmits that information somewhere else. Email masquerading as generic spam or a phishing scheme can trick a user into compromising his or her work computer just as easily as a home computer.

Spam

It used to be the case that receiving one or two spam messages per day was annoying. These days, a primary SMTP address can receive anywhere from 100 to 500 unwanted messages per day. Spam, or unsolicited commercial email (UCE) as it is officially known, is any message that ends up in your mailbox that you neither wanted nor requested. Laws have been passed and lawsuits brought against spammers have been won, but still the amount of spam received by the average email user continues to increase.

Estimates of just how bad the problem is vary widely between analysts. The IDC estimates that as much as 70 percent of all SMTP mail coming into an organization is unwanted or invalid messages. Without some type of filter or blocking mechanism, these messages end up in the user's Inbox. By some estimates, users spend as much as 30 minutes per day weeding through their Inbox to isolate the good mail and delete the spam. This percentage of most people's productive work day is essentially wasted. In addition, there is a cost factor associated with accepting and storing (even temporarily) this onslaught of spam.

Although spam is not necessarily going to crash your mail servers or put your organization out of business, it can still be detrimental. Some spam messages include graphic pictures and offensive words; a user of delicate constitution may well be offended to the point of hiring a lawyer or filing a harassment claim if an organization is not making a concerted effort to detect and eliminate spam.

Denial of Service

Day zero of a virus/worm outbreak is the day the virus is initially identified and protection against that virus is developed. In any given day, antivirus vendors may identify six or more new viruses. Although most of these don't quickly go "global," a select few end up spreading rapidly. Within a few days of being discovered, the Sober.Z variant of the Sober worm was clogging email queues, filling up hard disks, and slowing mail delivery for both commercial organizations and large email providers.

This type of Denial of Service (DoS) is just as effective as a direct attack by a malicious hacker who is intent on delaying mail delivery for an organization. Attackers may target a specific organization by sending significant numbers of large email messages in an attempt to delay messaging services for users.

A fairly new type of "attack" that is now being launched by spammers is called a directory harvesting attack (DHA). A DHA can be run against any SMTP mail server that validates inbound or outbound mail against a valid list of recipients. The Windows 2003 SMTP service, for example, does not perform this type of a validation against a directory service, but once Exchange 2003 Server is installed on Windows 2003, the SMTP service will perform validations of mailboxes against Active Directory (AD).

There are two possible approaches to a DHA. The first involves the sender going through all possible alphabetical characters looking for email that is delivered successfully. For example, a sending SMTP service might start with a@somorita.com, b@somorita.com, and so until it has gone through zzzzzzzz@somorita.com or some other maximum number characters. Each time a successful message is delivered, that address is recorded. A second and possibly more efficient mechanism is when the DHA attacking SMTP server goes through a dictionary of common surnames and given names looking for successes.

DHAs end up using not only a lot of bandwidth but also SMTP server and directory resources. And, in the end, some percentage of your user community's email addresses is compromised.

Information Leaks

Your email system contains your organization's sensitive and private information; unfortunately, this reality makes accidental or intentional disclosure of information easy. Passing along information via email to unauthorized parties (either internally or externally) is as simple as a few mouse clicks. Even accidental disclosure becomes as simple as a few incorrect keystrokes.

Given the volume of email that some users send on a daily basis, they frequently overlook to whom the message is addressed. This may be due to the user incorrectly choosing the Reply All function of the email client or accidentally including an incorrect recipient in the To, Cc, or Bcc lines.

Administrative Concerns

Email administrators often take a very technical approach to improving email security by implementing SMTP gateways, firewalls, appliances, content scanners, and third-party service providers. Throwing all your energies towards a technical solution is all well and good but does not help address some other issues that may plague your organization.

The first of these is administrative-level access to mailboxes. Most users don't realize the level of trust that must be placed in their IT department. As many administrators in the IT department have full administrative access to the network, servers, and data, they have the ability to view email and often an end user's mail. With great power comes great responsibility.

It is not uncommon to read in an IT industry newsletter or magazine about a case in which a network administrator has been fired for accessing information that they should not be reading. This includes recreational "mailbox surfing;" mailbox surfing should always be treated as a serious offense.

The need to have mailbox-level access for users' mailboxes is often necessary in most organizations. This may be because a hostile or sensitive message was sent to everyone and needs to be extracted, information may need to be archived from users' mailboxes, or due to the investigation of a user that requires access to his or her email. Access of a user's mailbox should never be treated as a trivial matter. Procedures should be documented and published for when a mailbox will be accessed by anyone other than the owner of the mailbox. Management oversight and authorization should always be obtained prior to accessing a user's mailbox for any purpose. In some larger organizations, a representative from Human Resources or the Information Security department must be present.

Administrators in small and midsized organizations and organizations that have branch offices frequently overlook physical security of servers. It is not uncommon to find an email server sitting on someone's desk or in a spare cubicle. If an intruder gets physical access to your servers, the information on those servers is easily compromised.

Another area that is often overlooked with respect to administrative procedures is storage of backup media. Although we all know that the backup media has a complete copy of data (at least, you hope it does), often the media is not treated as securely as the servers themselves. In some situations, backup tapes for large companies are stored on a shelf in the hallway outside the data center door. Once an unencrypted tape is in the wrong hands, it is trivial matter to restore the data to an alternative computer and access it.

Backup media should always be stored in locked containers such as a tape backup storage container or a safe. If an intruder acquires your backup tapes, he or she can access the data at their leisure. Backup media should have at least the level of protection that your servers have been afforded, if not more.

Liabilities and Punitive Damages

For most technical staff thinking about vulnerabilities with their systems, lawsuits or government regulations are not the first topic to come to mind. You normally view systems in terms of capacity, availability, performance, and features—not in terms of lawsuits and government oversight.

Regulatory compliance is not a term that most in the technology business were used to hearing until recently. There are now a number of laws that directly or indirectly affect the operation of an email system. These laws were passed with the intent of requiring organizations to provide better protection and accountability of the information they process. The Health Insurance Portability and Accountability Act (HIPAA) is intended to protect protected health information (PHI), including the security of information that is transmitted via email. For example, a doctor can write an email to another doctor containing the word diabetes; diabetes can be mentioned many times and that email message does not have to conform to HIPAA security requirements. However, if that message contains any of, but not limited to, the following, HIPAA guidelines must be followed:

• Uniquely identifying information such as a patient's name, medical record number, or Social Security number
• Phone/fax numbers
• Email address or mailing address
• Photograph or fingerprints

Violation of the HIPAA requirements can bring about lawsuits from the federal government as well as from the patient. However, failure to meet regulatory compliance with your email system is not the only place that may cause your organization to be sued. Misuse of an email system by users, such as sending information that is inappropriate in most work environments may bring about lawsuits. Inappropriate content may include jokes, pictures, or copyright-protected content such as MP3 or MPEG files.

Aspects and Trends in Email Security

The email security process, software, and choices available are evolving rather quickly. The terms that have been known for years for antivirus software, anti-spam software, and content inspection software are now morphing in to a single category of software called message hygiene software. The number of vendors and service providers in this field are rapidly growing and a surprising number of partnerships between companies that formerly competed are now blossoming to form new products with new capabilities. A common theme among these vendors is that you can use a single software package for all your message hygiene needs and with that unified management of antivirus and anti-spam technologies.

Network and email administrators must consider that keeping their messaging systems secure and protecting their information is not a destination to which they arrive after the purchase of a few products and some configuration changes. Messaging security is an ongoing journey that requires adaptation of methods, software, policies, and procedures.

What is a multi-tier messaging security system?

Quite simply, a multi-tier messaging security system provides the back-end messaging system with two or more layers of messaging hygiene, including virus scanning, spam protection, and content inspection. Where the original "threat matrix" contained only simple viruses in attachments, now worms, Trojan horses, and phishing schemes threaten email systems and our user community. Not only can unwanted content arrive on your network via your mail server but users can introduce hostile content by doing something as simple as checking their personal Web mail clients.

As message-based threats and potential security breaches via email have evolved beyond simple, hostile attachments, the need for more levels of protection and more evolved protection has emerged. There are a number of places that messaging security can be implemented; Figure 1.3 shows several approaches to implementing messaging security.

Figure 1.3: Possible components of a multi-tier messaging security system.

As you can see, there are many places where messaging security can be put in place. The whole premise of the multi-tier messaging security system is that you have more than one security mechanism in place.

The sender's mail system is the first place where mail security can be put in place. However, any sort of notion that senders on the Internet are implementing good message hygiene is a poor assumption.

A relatively new component of messaging security is the managed provider. If an organization uses a managed provider, the organization's inbound mail exchanger (MX) records point to the managed provider's mail servers. Inbound mail is then inspected by the provider's software and passed on to a host within your organization. Managed providers can handle all aspects of inbound message hygiene such as real-time block list (RBL—also known as real-time black-hole lists) lookups and spam, virus, inappropriate content, and day-zero threat detection. In addition, they can do so in an environment that is much more scalable and reactive than even larger organizations can do themselves.

For some organizations, an application-layer capable firewall can provide an additional component of messaging security. Some firewalls are capable of performing virus and spam inspection of inbound email as well as performing lookups such as RBL and Sender ID verification of inbound SMTP traffic.

A component that has gained more of the security market is SMTP content inspection systems. One of the reasons these are appealing is that regardless of what type of system hosts your mailboxes (Exchange, Notes, UNIX, and so on) all inbound and outbound mail can be inspected by a single platform. These systems can handle all aspects of message hygiene.

Mailbox server message inspection is probably one of the oldest approaches to mail-based virus protection. This solution requires software that is designed to work with the mail system that hosts the mailboxes, as the inspection software must be able to open the messages stores and detect and clean viruses without damaging the message system's databases.

Client-based virus and content scanning is the oldest method of virus protection—some antivirus scanners have been on the market for nearly 20 years. No messaging security system is complete without protection at each client on the network.

Each of these layers of protection serves as a barrier against unwanted messaging content. Unwanted email content—including spam, viruses, worms, and phishing schemes—serve as a disruption to users and to IT resources, and thus cost a business money.

The tangible and intangible costs of a single virus outbreak within a midsized organization's email system can justify the cost of an additional layer of protection.

Why Have More than One Messaging Security Solution?

When most organizations are presented with the idea that they should have more than one mechanism for protecting against viruses and malicious mail content (and certainly mail-based viruses), their initial reaction is to wonder why it is necessary or to argue that their existing systems are sufficient. However, worms such as SoBig, Sober, and Blackmal may have helped to change people's minds about the necessity of multiple layers of security. These worms (often incorrectly classified as viruses) have multiple mechanisms, including an SMTP engine, with which they can propagate. Even if the message did not arrive via the mail server, a user's computer can become infected; these worms will find email addresses on the user's computer and send messages outbound directly from the user's computer (thus bypassing server-based email security).

The lesson is that hostile content can be brought into an organization not only via email destined for an organization's email server but also through other mechanisms. A number of common mechanisms that viruses and content have used to make their way into an organization's network include:

• Users accessing personal Web-based or POP3 email from their work computers
• Hostile content being downloaded from Web pages
• Laptops that have become infected while being used remotely are then returned to the corporate network
• Home computers and remote computers infect the corporate network via virtual private network (VPN) connections
• Extranet connections from business partners can introduce hostile content

It is important to realize that no single form of protection is 100 percent bulletproof. Although most scanning systems today are far more accurate at detecting virus, worms, and other hostile content, relying on any single mechanism may allow something to squeak by. Implementing multiple layers of protection will also help if you use different scanning engines, signature sets, and detection methods. For some types of scanning, such as behavioral analysis, it is better to offload the overhead of virus detection from the mail server or the client platform.

A reliable multi-tier messaging security system should include client-side scanners as well as some form of perimeter mail protection and mail server scanning.

Finally, for the sake of reducing the overall load of processing on a mailbox server, preventing as much unwanted or dangerous content from arriving on the server itself is valuable. This reduces the resource requirements and the potential for hostile content to actually be accessed by a user.

Early Scanning Systems

The message hygiene industry has seen great convergence over the years. Just 3 or 4 years ago, in order to perform virus scanning, content inspection, and anti-spam activities, you had to purchase two or three separate pieces of software. Figure 1.4 illustrates an example of a healthcare organization's email security system.

Figure 1.4: Going to extremes with message hygiene.

In the example in Figure 1.4, the healthcare organization built additional layers of protection in to their network one component at a time starting with the email scanning system on their Exchange 2000 mailbox server, and, of course, including virus scanning on the client side. Soon they realized the value of an additional layer of virus scanning, and added an SMTP virus scanning system that performs just virus scanning.

Later, as spam became more of a problem for their users, an additional SMTP gateway was installed whose function was exclusively detection of spam. In the case of this organization, not only was the software from different vendors, but it was installed on separate hardware. The antispam system is monitored continually by a Help desk staff member to ensure no false positives are tagged in the spam filter's quarantine. The IT director of this 375-mailbox organization recently noted that monitoring the company's quarantine consumes approximately 4 hours per day of the Help desk's time.

Next came the requirement to perform content inspection in order to meet Health Insurance Portability and Accountability Act (HIPAA) regulations. As neither the spam detection gateway nor the antivirus scanning system were capable of meeting the requirements for scanning inbound and outbound SMTP messages to detect whether messages were meeting HIPAA compliance, a third SMTP gateway was installed. The third scanning system was designed to inspect the content, compare the text of messages against a lexicon of HIPAA terms, and, if necessary, quarantine a message until it could be inspected by an administrator.

All inbound messages that the organization received were sent through three separate SMTP scanning systems prior to the messages being delivered to the organization's Exchange server. This setup introduced complexity, management overhead, and potential single points of failure into the organization's messaging infrastructure.

A current trend is that a product that does a single function (such as just virus detection or only spam prevention) is now the exception rather than the rule. Vendors are now providing products that have multiple capabilities, or vendors are teaming with other vendors in order to provide products that have a single management interface and require a single server platform and perform all necessary message hygiene functions.

Recommendations for Multi-Tier Messaging Security

If you currently have only a single layer of messaging or content security for your organization's email and are looking for a recommendation for how to proceed, you will be relieved to know that implementing multi-tier messaging security is not as complex as it may appear. A solid email protection system really only needs three levels of protection, unlike the organization shown in Figure 1.4 that has three separate SMTP scanning systems or organizations that also implement scanning systems on their firewall.

In the first example, shown in Figure 1.5, the organization has implemented three levels of protection. This organization has chosen to manage their entire mail security system internally. The first layer of defense is an SMTP scanning system located in the perimeter network or DMZ that is capable of not only detecting viruses but also filtering spam. In this case, the organization purchased and manages their own SMTP message hygiene gateway. The organization's MX records should point to this server in the DMZ.

Firewalls should not only restrict inbound SMTP to authorized hosts but also allow outbound SMTP only from authorized mail servers.

The internal firewall should be configured so that inbound and outbound SMTP traffic (TCP port 25) is restricted to only the mailbox server(s) and the SMTP scanning system in the DMZ. This setup will prevent infected clients from sending infected email directly to the Internet, thereby bypassing the SMTP scanning system and the mailbox server.

Figure 1.5: Implementing an internally managed SMTP inspection system in the DMZ.

The second layer of defense is the software on the mailbox server that can scan messages in the users' mailboxes as well as scan incoming mail. In the case of Microsoft Exchange, this software would use the Antivirus Application Programming Interface (AVAPI) to access the mail store and examine messages in the queues. Ideally, the software that is running the SMTP scanning system and the software that handles virus detection on the mail server should be from different vendors or use different scanning engines and signatures.

To improve the possibility of detecting all hostile content, the mailbox server's virus scanning software should be from a different vendor or use a different scanning engine than the one handling the SMTP scanning on the perimeter network.

The final layer of security is once again at the client. If you have properly implemented a multilayer approach to detecting viruses that arrive on your email servers, the chance that a virus will arrive on your clients from your organization's mail servers is very slim. Even if a message containing a virus manages to make it all the way to a user's inbox, the Exchange AVAPI will not allow a client to open a message that has not been scanned. However, in some organizations, users can be exceptionally determined when it comes to finding ways to bring hostile content into an organization; for example, users might configure their mail client to download POP3 or IMAP4 email from external mail servers or open infected email that is on external Web-based mail systems. In either case, the user is bringing content into your organization that has not been scanned by your message hygiene system.

The client computer should have an antivirus client that can not only protect the file system in real-time but also scan mail messages and attachments as they are being accessed by the mail client. Although scanning mail that is being opened from a well-protected Exchange Server is a duplication of functionality, this can serve as an additional layer of protection against viruses or worms that find other ways to enter your organization. Client-side antivirus software should have features such as Symantec Antivirus Corporate Edition's Microsoft Exchange Auto-Protect feature (shown in Figure 1.6). This feature allows the user or administrator to specify how emailbased viruses or threats are treated when they are detected. When an email message is opened, any message attachments are immediately scanned even if the attachment has not yet been accessed. Client-side scanning solutions such as Symantec Antivirus can scan not only messages being opened by a MAPI client but also POP3, IMAP4, and SMTP message data streams.

Figure 1.6: Email client protection.

Software that is intended for desktop client MAPI, POP3, IMAP4, or SMTP virus scanning should never be configured to do this type of scanning on an email server.

When implementing a mail hygiene system in the DMZ network, implement and enforce as much as possible your organization's corporate email policy. The perimeter scanning system should be configured to perform operations to protect the mailbox servers including:

• Performing an initial virus scan and blocking inbound messages that contain worms, viruses, and Trojan horses
• Blocking hostile file content (such as programs and scripts)
• Blocking content types that are not allowed (such as MP3, WAV, or MPG files)
• Detecting and eliminating spam and phishing schemes
• Performing Sender ID filtering and lookups against RBLs and known spammer lists
• Deleting or quarantining messages that are infected rather than passing them through to the mail server

The second example of a multi-tier messaging security system is a little simpler than the first but involves many of the same components. Figure 1.7 shows an example configuration in which the organization is using a managed provider as their first line of defense.

Figure 1.7: Multi-tier security with a managed provider.

The organization's MX records point to the managed provider's SMTP servers, not their own. All inbound mail goes through the managed provider's message hygiene system. The organization can lock down their SMTP ports so that their firewall will only allow inbound SMTP from the managed provider's IP addresses.

This configuration eliminates the need for a perimeter SMTP scanning solution. A managed provider can typically offer much greater reliability and scalability than even a midsized or large business can, and can cost the organization only a few dollars per mailbox. Further, managed providers are staffed and managed to a higher level of availability and can provide immediate reaction and protection against day-zero virus/worm attacks and adapt more quickly to changes in spam and phishing schemes.

When deploying perimeter SMTP scanning solutions, the mail servers should be configured to accept inbound SMTP mail only from the authorized scanning systems.

Although managed providers offer an excellent front-line defense against unwanted mail content, they should by no means be considered an organization's sole line of defense. In Figure 1.7, the organization shown still employs antivirus protection on the mailbox server and the clients are still required to have antivirus software. However, the managed provider will help to reduce the total load on the organization's mail servers.

Managed providers can reduce the unwanted content that makes its way onto your mail servers and reduce resource overhead on the mail servers.

Some analysts attribute 70 percent or more of an organization's email traffic to spam. In addition to placing a tremendous burden on the user community, this amount of spam burdens an organization's messaging system due to extra disk space being consumed, Internet bandwidth being used, and excessive server connections being employed. Excessive server connections due to spam have been exacerbated by the fact that many viruses are simply massive, distributed spam systems. Figure 1.8 shows the inbound SMTP sessions for a small organization (less than 50 mailboxes) that receives a lot of spam daily.

Figure 1.8: Inbound SMTP sessions delivering spam.

Upon first glance, the sessions in Figure 1.8 might appear to be valid sessions. In fact, the only reason the administrator called this into question was that one of the sessions had remained connected for more than an hour. Upon further investigation in the SMTP protocol logs, all these sessions were attempting delivery of random names for that organization. The log showed that there were multiple SMTP conversations from a single IP address. Listing 1.1 shows code that filters out the SMTP conversations from a single IP address.

07:22:22 222.65.236.137 emailhut.net HELO - +emailhut.net 250 
07:22:22 222.65.236.137 peacemail.com HELO - +peacemail.com 250 
07:22:22 222.65.236.137 zalau.ro HELO - +zalau.ro 250 
07:22:22 222.65.236.137 vegemail.com HELO - +vegemail.com 250 
07:22:22 222.65.236.137 emailhut.net MAIL - +FROM:+<oralienmell@emailhut.net> 250 
07:22:22 222.65.236.137 peacemail.com MAIL - +FROM:+<christenmae@peacemail.com> 250 
07:22:22 222.65.236.137 zalau.ro MAIL - +FROM:+<resther@zalau.ro> 250 
07:22:25 222.65.236.137 goowy.com HELO - +goowy.com 250 
07:22:25 222.65.236.137 goowy.com HELO - +goowy.com 250 
07:22:25 222.65.236.137 vegemail.com MAIL - +FROM:+<reighnerz@vegemail.com> 250 
07:22:25 222.65.236.137 chocofan.com HELO - +chocofan.com 250 
07:22:25 222.65.236.137 goowy.com MAIL - +FROM:+<maureenz@goowy.com> 250 
07:22:25 222.65.236.137 goowy.com MAIL - +FROM:+<marlanas@goowy.com> 250 
07:22:26 222.65.236.137 chocofan.com MAIL - +FROM:+<corine@chocofan.com> 250 
07:22:31 222.65.236.137 wildmail.com HELO - +wildmail.com 250 
07:22:31 222.65.236.137 wildmail.com MAIL - +FROM:+<heathlyn@wildmail.com> 250 
07:22:38 222.65.236.137 peacemail.com RCPT - +TO:+<yasso@somorita.com> 550 
07:22:38 222.65.236.137 zalau.ro RCPT - +TO:+<crump@somorita.com> 550 
07:22:40 222.65.236.137 emailhut.net RCPT - +TO:+<roper@somorita.com> 550 
07:22:40 222.65.236.137 vegemail.com RCPT - +TO:+<keen@somorita.com> 550 
07:22:40 222.65.236.137 goowy.com RCPT - +TO:+<sinclair@somorita.com> 550 
07:22:40 222.65.236.137 chocofan.com RCPT - +TO:+<purvis@somorita.com> 550 
07:22:42 222.65.236.137 chocofan.com QUIT - chocofan.com 240 
07:22:47 222.65.236.137 wildmail.com RCPT - +TO:+<hsgrb@somorita.com> 550 
07:22:47 222.65.236.137 goowy.com RCPT - +TO:+<sorensen@somorita.com> 550 
07:22:53 222.65.236.137 peacemail.com RCPT - +TO:+<neff@somorita.com> 550 
07:22:53 222.65.236.137 zalau.ro RCPT - +TO:+<vogel@somorita.com> 550 
07:22:56 222.65.236.137 emailhut.net RCPT - +TO:+<seakmg@somorita.com> 550 
07:22:56 222.65.236.137 vegemail.com RCPT - +TO:+<mpedersen@somorita.com> 550 
07:22:59 222.65.236.137 goowy.com RCPT - +TO:+<fish@somorita.com> 550 
07:23:02 222.65.236.137 wildmail.com RCPT - +TO:+<mims@somorita.com> 550 
07:23:02 222.65.236.137 goowy.com RCPT - +TO:+<swartz@somorita.com> 550 
07:23:09 222.65.236.137 peacemail.com RCPT - +TO:+<worley@somorita.com> 550 
07:23:09 222.65.236.137 zalau.ro RCPT - +TO:+<rusba@somorita.com> 550 

Listing 1.1: Code that filters out the SMTP conversations from a single IP address.

Notice that in each of the RCPT commands, the result was an error code 550 indicating that this address does not exist at this organization (and, in fact, never has). To slow the progress of these "attacks," an SMTP tar pit was put in place to slow the return of the error codes, but at any given time, this server still has between 10 and 50 inbound SMTP sessions consuming bandwidth and resources. The tar pit can help to slow the amount of data that is sent to the organization's SMTP server but does not totally eliminate the bandwidth consumed. Managed providers reduce the risks associated with this type of spamming by eliminating worthless traffic from your network connection.

Should I block file attachments?

Much of the hostile and unwanted message content that enters a messaging system today is hostile because of the attachments that the message carries—including scripts, executables, screen savers, and even compressed files. For this reason, most messaging systems administrators have adopted a strategy of blocking any message that originates outside of their network that might potentially be carrying a virus, worm, or Trojan horse. An antivirus scanning system residing directly on the mail server can handle this task quite easily; this setup merely requires a message scanning system that is capable of scanning the message stores or the message transport directly on your Exchange Server system. A better approach is to keep the unwanted attachments from ever reaching your mail server. Figure 1.9 shows possible solutions that can be quickly implemented by any organization.

Figure 1.9: Implementing attachment-blocking policies.

With the setup that Figure 1.9 shows, this organization can either block the inbound message content using a managed provider or implement a Simple Mail Transfer Protocol (SMTP) scanning system in the DMZ or perimeter of the network. The SMTP scanning system or the managed provider is then configured to block the list of file attachments that the organization wants blocked. The scanning system or managed provider can then take one or more actions on the blocked attachments:

• Quarantine the message and the attachment entirely
• Quarantine just the attachment
• Submit the message to a dynamic quarantine whereby the message is rescanned for some period of time before being released to the user
• Delete the message and attachment entirely
• Do not notify the user or the sender
• Notify the sender of the blocked message attachment
• Notify the intended recipient that an entire message—or just an attachment—was blocked
• Pass the message (without the attachment) to the user's mailbox

The actions taken will depend on the capabilities of the scanning software being used and the organization's policies on attachment blocking. One advantage of using a managed provider is that the hostile content never arrives within the boundaries of any of your servers, therefore minimizing the risk of infecting internal systems and reducing Internet bandwidth usage.

If an organization applies attachment blocking only at the perimeter of the network, however, a virus or worm might still infect internal messaging components. For this reason, organizations should develop two attachment blocking policies. The first policy dictates the types of attachments that are blocked at the perimeter of the network. The second policy defines the attachments that are not allowed to be sent internally.

In Figure 1.9, the external blocked attachment lists includes attachment types that might not be considered acceptable when receiving messages from the Internet, such as multimedia files as well as dangerous attachments. The internal blocked attachments list includes the list of files that are permitted internally. For some organizations, this list will be identical, while distinctly different for others. Further, clients such as Outlook 2000 and later as well as Outlook Web Access (OWA) 2003 allow for certain types of attachments to be blocked so that they cannot be saved and/or opened.

Attachments that Should Be Blocked

The list of attachment types that must be blocked is going to vary widely from one organization to another. This list will end up being based on the politics and needs of an organization's users. One organization might insist on allowing renamed .EXE files, while another may insist on blocking all compressed files.

Absolute Blocking List

The following recommended absolute blocking list consists of the common attachments types that have been used as attack vectors for most of the viruses, worms, and Trojan horses that have appeared in the wild over the past few years. Table 1.1 shows this list including a description of what the attachment is and the typical attachment extension. For the most part, the files defined in this list are generally not files that should be passed via email messages.

Table 1.1: Generic dangerous attachment list.

Microsoft Client Blocking

Microsoft introduced a comprehensive list of potentially harmful attachment types with the Outlook Email Security Update for Outlook 98 and Outlook 2000. Outlook 2002, Outlook 2003, and OWA 2003 include this list of attachments. Collectively, the attachment lists are called the Level-1 and Level-2 attachments. The intention of this update was to categorize potentially harmful attachments into the Level-1 attachment list, which was meant to prevent a user from opening or saving the attachment. The Level-2 attachments can be opened, but only after the user has saved the attachment to the file system.

Level-1 Attachments

Unless a user works in the IT department or is a developer, the user should not be receiving Level-1 attachments; thus, these attachments should be viewed with much suspicion. Table 1.2 shows the Level-1 attachment list as of Outlook 2002 SP2 and later.

Table 1.2: Microsoft Level-1 attachments.

If a user tries to send a message that contains an attachment that is on the Level-1 attachment list, the user will see a warning indicating that he or she is attempting to send an attachment that might potentially be harmful; however, Outlook will allow the user to send the message.

You might have noticed that Table 1.2 is missing an entry for compressed files. Compressed files such as ZIP files are commonly used as an attack vector for email-based worms and viruses. The message carrying the ZIP file tries to trick the user into opening the attached file. ZIP files and other attachments can be added to the Level-1 attachment list via different approaches. The simplest of these is to add the additional attachments to the registry. To do so, locate the HKEY_CURRENT_USER\Software\Microsoft\Office\X\Outlook\Security registry key. Replace the X value with the version of Outlook that you are using. The following are the valid version numbers:

Next, open the Level1Add value and set the attachment types that you want to define as additional Level-1 attachments. If the Level1Add value does not exist, create a new REG_SZ type value called Level1Add. The format for entering additional file types is shown in Figure 1.10.

Figure 1.10: Manually adding Level-1 attachments.

Level-1 and Level-2 attachment types for OWA 2003 clients are defined on a per-server basis and include definitions not only for file extensions but also for MIME types. Figure 1.11 shows the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA registry key, which holds these values.

Figure 1.11 OWA attachment-blocking registry values.

Although these settings can be edited via the registry editor, a simpler way to manipulate the OWA attachment handling rules is to use the OWA Web Administration tool that can be downloaded from the Exchange 2003 tools page at http://tinyurl.com/9cpt6.

Level 2-Attachments

Level-2 attachments are attachment types that are considered possibly unsafe and therefore the user should go through the extra step of saving the attachment to the file system before opening it. By default, the Level-2 attachments list is empty, but a Level-1 attachment can be demoted to a Level-2 attachment via a registry key edit. Figure 1.12 shows two messages that are presented if you open an attachment using Outlook 2003. The warning dialog box on the left is the default message that users see when they open any attachment that is not on the Level-1 or Level-2 attachment list. The warning on the right is the warning that users receive if they try to open a Level-2 attachment.

Figure 1.12: Warning messages when opening attachments in Outlook 2003.

Using the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA registry key, you can define Level-2 attachment types by creating a REG_SZ value called Level1Remove and adding the attachments that you want to remove from the Level-1 attachment list. You can also define attachments that are not on the Level-1 list, for example, defining restrictions for compressed files.

Bypassing or Managing Client Attachment Blocking

Editing the registry of each user that is going to need to have Level-1 file types demoted is not a productive use of time. There are a couple of options that can help you with this management task. Outlook MVP Ken Slovak wrote a very useful COM add-in for Outlook 2000 SP3 and later that allows the user to manage the attachments that are in the Level-1 attachment list through a graphical user interface (GUI). You can download the Attachment Security & Options add-in for Outlook from Ken's Web site at http://www.slovaktech.com/attachmentoptions.htm. Figure 1.13 shows the Attachment Security & Options property page.

Figure 1.13: Attachment Security & Options COM add-in for Outlook.

If you are running Outlook 2003, you can configure the Level-2 attachment list using a Group Policy Object (GPO). The Office 2003 Resource Kit includes administrative templates for all Microsoft Office applications, including Outlook. The Allow access to e-mail attachments policy setting (shown in Figure 1.14) allows the administrator to define attachment types that should be moved from the Level-1 to the Level-2 list as well as attachments that should be added to the Level-2 attachment list.

Figure 1.14: Configuring Level-2 attachments through a GPO.

The administrative templates for the Office Resource Kit can be downloaded from http://www.microsoft.com/office/ork. Once the Outlook 2003 administrative template has been loaded into a policy, this policy setting is found in the policy under Administrative Templates, Microsoft Office Outlook 2003, Tools, Options, Security.

Still another way that an Exchange Server administrator can control the restricted attachments is to use the Outlook Security Settings form (shown in Figure 1.15) to define attachment security as well as other Outlook security components.

Figure 1.15: The Outlook Security Settings form.

The Outlook Security Settings form can be used with all versions of Outlook later than Outlook 2000 SP3. More information about using this form can be found in the Microsoft article "Administrator Information About the Outlook E-mail Security Update: June 7, 2000."

Policy-Blocked Attachments

For some organizations, it might be acceptable to use the email system to pass around multimedia content that is business related; in other organizations, such content is not appropriate. Worse still is that some content such as a user-copied WMA or MP3 file might violate copyright laws if the user is illegally distributing the file. In addition, if the content is offensive, it might be violating an organization's acceptable use policy. Depending on your organization's policies, blocking this type of content might be wise. Table 1.3 shows a list of common multimedia file types that you might consider blocking.

Table 1.3: Multimedia files that might need to be blocked.

Compressed Files

In some organizations, users might not be able to do without compressed files (for example, if they receive ZIP files that compress large documents, spreadsheets, and presentations). This is convenient because it reduces the space that users' mailboxes consume and allows the attachments to be transmitted quicker. Some organizations even use tools such as C2C's MaX Compression, MAPI Lab's Attachments Zip Compressor, or WinZip's Companion For Outlook so that all outbound attachments in files are automatically compressed into ZIP files.

However, several common viruses such as variants of the Beagle and Spester worms have used compressed files such as ZIP files to get past antivirus scanning systems and scanning systems that block scripts or executables. For this reason, the messaging administrator and IT decision makers must balance usability with the potential that a user may open a compressed file that contains hostile content. Table 1.4 shows a list of common compressed file types.

Table 1.4: Compressed attachments that might need to be blocked.

Intelligent Attachment Inspection

Some antivirus systems include a feature that allows the antivirus system to intelligently inspect attachments to determine the attachment type. Quite simply, the attachment is examined to determine what it is. Thus, a user could rename an EXE file to a TXT file, but the intelligent inspection system would still ascertain that the file was really an EXE and block or quarantine it as appropriate. The danger of such systems is that if you really need to receive ZIP files, you will not be able to instruct remote senders to rename the extension for you.

How do you lock down an Exchange Server?

Most modern mail systems are fairly robust and can resist a lightweight attempt at a Denial of Service (DoS) attack. However, a determined individual or group of individuals can still wreak havoc on an unprotected or unprepared mail system if they approach their attack from the right angle. There are a few simple steps that organizations can take to reduce the likelihood that their publicly exposed mail services are compromised.

These steps include applying the appropriate messaging system limits to the server so that it cannot exceed the capacity that you have planned for each user's mailbox. Furthermore, you can lock down the users' ability to automatically forward information outside of the organization.

Reducing the number of services that a server is running or reducing the number of ports that are opened can also help reduce the possibility of DoS attacks by decreasing the server's surface area. If services are exposed to the Internet, place proxy or relay systems between the Internet and the internal mail servers.

Mail servers operate best and most securely when they have only the necessary applications and services to perform the necessary functions. Avoid installing too many services or third-party applications if they are not necessary for the server's designated role.

Disabling Services

One of the first steps to better protection for any Windows server is to reduce the number of services that the server is running and reduce the number of TCP or UDP ports that are open. Although specific services or ports may not currently be employed by attackers to compromise a system, there is no guarantee that weaknesses in those services or ports won't be discovered in the future.

The different services that you chose to remove or disable on any Exchange Server will vary based on your organization's needs. The services you can disable will also vary based on the role that particular server plays in the organization.

Disabling Mailbox Server Services

Exchange Server systems that function as a mailbox or public folder server (a back-end server) have a different set of services that may be disabled than servers that operate as front-end servers. The services that exist on a Windows Server 2003 (WS2K3) machine will vary based on the additional Windows or third-party components that have been installed. Table 1.5 shows a list of the services that may be disabled on a mailbox server and under what conditions.

Table 1.5: Windows and Exchange services that can potentially be disabled on a mail server.

Table 1.5 is not an all-inclusive list of services that you may find running on an Exchange 2003 server, but it includes a list of common services that may be enabled by default or because of an upgrade from a previous version of Exchange.

Prior to disabling any of these services, confirm that the service is not required by your organization or an application running on the server. When making changes in your organization, such as installing new applications or supporting new features, keep in mind that these services may have been disabled but are now required.

Disabling Front-End Server Services

Exchange front-end servers provide different types of remote client access. A front-end server may be dedicated to HTTP client access functionality—such as Outlook Web Access (OWA), Windows Mobile ActiveSync, or HTTP over RPC proxy functions. A front-end server can also function as a Simple Mail Transfer Protocol (SMTP) or X.400 bridgehead server for handling messages in and out of the routing group or to an external organization. Depending on the size of the organization, a single server (or load-balanced cluster) may perform all these functions, or the client access functions may be split off from the messaging bridgehead functions.

The list of services provided in Table 1.5 also applies to front-end servers; however, there are a few more services that may be disabled depending on the server's role and functions. Table 1.6 shows a list of additional services that you may be able to disable if they are unnecessary.

Table 1.6: Windows and Exchange services that can potentially be disabled on a front-end server.

Internet Exposure Protection and Redundancy

A determined hacker or group of hackers can launch a DoS attack against your email servers by doing something as simple as sending many simultaneous inbound requests via an open Internet port. Most organizations open Web services (usually HTTPS using port 443) and, of course, SMTP (port 25).

Sometimes, slightly evil deeds bring unintended consequences, as in the unholy union between hackers and spammers. Hackers have built large, distributed spamming systems using virus and worms. A single SMTP server can have dozens or hundreds of inbound SMTP connections all trying to deliver spam using dictionary message delivery techniques. All these sessions come from different IP addresses, thus, blocking them is difficult.

An important line of defense against DoS attacks and unwanted intrusions is to ensure that your perimeter is correctly sealed and protected, including a properly configured firewall. Audits should be conducted regularly to ensure that no inbound port is left open if it is no longer necessary.

For small and midsized organizations, inbound HTTPS or SMTP might actually be routed directly to mailbox servers. A DoS attack against your organization could cripple not only inbound email or OWA clients but also mail service for the entire organization.

Protecting the mailbox servers from this type of attack becomes an important part of your security defense. The most effective method of stopping a direct attack on your internal mailbox servers is to simply not expose them to the Internet. Instead, use reverse proxy solutions for inbound HTTPS and SMTP relays or third-party inspection systems to protect SMTP.

For scalability and redundancy, additional gateways or proxies can be put in place. Figure 1.16 shows an organization that has implemented this type of defense. They have placed SMTP relays in their DMZ and ISA Servers acting as reverse proxies. In this case, each of these have implemented the network load-balancing service so that, for inbound connections, all the machines appear as one for external clients.

Figure 1.16: Providing protection for internal mail server resources.

Applying Limits

Most mail administrators know that storage limits for mailboxes and message size limits for inbound and outbound mail is a good idea because these limits help in planning expected capacity and knowing how much data you need to backup and restore. However, applying limits also has security implications.

An intruder intent on shutting down an organization's mail servers might start sending many large messages to multiple mailboxes within the organization. With as little as a few hours, a mail server's transaction log disk, database disk, or message queue folder may overflow due to the larger than expected messaging load. For organizations whose management is reluctant to impose limitations on their users, this threat may give you the additional ammunition necessary to convince your boss that you need mailbox or message size limits.

Mailbox Limits

Mailbox limits allow you to impose three size limits to a mailbox. Figure 1.17 shows the Limits property page on an Exchange mailbox store. Messaging limits can be configured directly on the Limits property page of an Exchange mailbox store or on a selected group of mailbox stores using an Exchange Server mailbox store policy. If you have many mailbox stores, using a mailbox store policy is more efficient.

Figure 1.17: Applying storage limits.

The default mailbox limits can be overridden on a user-by-user basis by locating the user in Active Directory Users and Computers, displaying the user's properties, going to the Exchange General property page, and clicking Storage Limits.

I recommend that all three limits be applied; the actual limits used vary wildly from organization to organization based on disk and backup capacity as well as the amount of data that users need to keep in their mailboxes. If you are concerned about a DoS attack that fills up a mailbox, the Prohibit Send and Receive limit will be useful to you. Unfortunately, just setting this limit does not give users any warning that their mailboxes are going to back up. An example scenario for mailbox limits would include publishing a maximum mailbox size limit of 250MB but configuring the size limits as such:

• Warning limit: 240MB
• Prohibit send at: 250MB
• Prohibit send and receive at: 300MB

Users will start seeing a daily warning message when their mailboxes hit 240MB, but at 250MB, they will no longer be able to send messages using MAPI or OWA clients. When the Prohibit Send and Receive limit is reached, the mailbox closes and will not accept any more mail, so you want to make sure that you give your users plenty of warning.

Message Size Limits

Earlier versions of Exchange did not apply a maximum inbound and outbound message size limit. With Exchange 2003, there is a global limit applied that cannot be exceeded by users. This limit is configured under the Global Settings on the Message Delivery properties (the default property page is shown in Figure 1.18).

Figure 1.18: Global message size limits.

For most organizations, the 10MB maximum message size is a reasonable limit, but each organization should evaluate this value to determine whether they typically send and receive larger message sizes or if 10MB is too large.

Maximum Store Size

Exchange 2003 Service Pack 2 (SP2) introduced a feature that generated a lot of excitement for Exchange 2003 Standard Edition customers. SP2 increased the maximum mailbox store size from 16GB to 18GB; but the real excitement about this service pack is that using a registry value, the maximum store size can be increased to 75GB on Standard Edition.

You might wonder what this increased store size has to do with security and DoS. Well, the registry key works with Exchange 2003 Enterprise Edition as well as Standard Edition. It allows you to configure a maximum store size for Exchange 2003 Enterprise Edition. So, for example, suppose that you have five mailbox stores on the F drive and the maximum amount of disk space you have available on the F drive is 300GB. You decide that the maximum store size should be no more than 50GB (you want to leave yourself some headroom here because the maximum store size that is calculated does not include the white space or deleted items). You could configure each mailbox store to be a maximum of 50GB.

When a mailbox store size hits 50GB worth of data, it will be dismounted. Although this approach might not be ideal, it will prevent a single store from growing uncontrollably and forcing all the mailbox stores to be dismounted when the disk drive runs out of disk space.

To enable a maximum store size, you need to edit the registry and create a new registry value for each mailbox store. First, you need to locate the necessary registry key; each store has a private globally unique identifier (GUID) associated with the store name. Figure 1.19 shows an example of these registry keys. Because Figure 1.19 shows a server that is running Exchange 2003 Enterprise Edition, there is more than one mailbox store.

Figure 1.19: Setting the maximum store size.

You can match the GUID in the registry (well, at least part of it) with the mailbox store's objectGUID attribute by examining the mailbox store object in ADSIEdit. Take the last part of the GUID from the registry (in Figure 1.19, this value is B5627D44DC20) and match that up with the last part of the digits in the objectGUID attribute (see Figure 1.20).

Figure 1.20: Examining a mailbox store's objectGUID attribute.

In each registry key that represents a mailbox store for which you would like to restrict the maximum store size, create a REG_DWORD value called Database Size Limit in GB value and set it to the maximum size (don't forget to click the Decimal radio button) that you want to enable the store to grow.

Avoiding Unnecessary Exposure

One of the most common ways that intruders gain access to an organization's resources is through social engineering. An intruder learns via an auto-reply message or an out-of-office message that the IT Manager Paul Agamata is out of the office. He can then use that information to attempt to gain access by posing as Paul or by asking for something on behalf of Paul.

Automatic replies and forwards can also be dangerous if a piece of sensitive data is emailed to a user, but that user has that information automatically forwarded to an external mail system. Once the data is forwarded out of the organization, there is a greater chance that it may be used by someone with less than pure intentions.

A fresh Exchange 2003 installation automatically blocks automatic replies, automatic forwards, and out of office messages, but these are frequently enabled by novice administrators. These are configured under Global Settings, Internet Message Formats. The default Internet Message Format is called Default and it applies to all outbound mail. Figure 1.21 shows the Advanced property page for this message format; you can see that automatic replies, automatic forwards, and out of office messages are not enabled.

Figure 1.21: Defining automatic message handling default settings.

If you have specific business partners or Internet domains to which you want to allow these automatic responses, you can configure additional Internet Message Formats for specific domains.

---