So you have been tasked with securing your organization’s email services.

There are quite a few guides available on the Internet and in different computer bookstores that can take you through the basics – and if you are ahead of the game you may have already done your homework.

So you have looked at your email server, or servers, and taken the recommended steps of:

• Installing a commercial email security solution,
• Updating the server’s operating system,
• Patching all required software,
• Turning off all unnecessary services,
• Configuring your email server to sit behind the external firewall,
• Encrypting your email storage,
• Setting a back up schedule,
• Testing the recovery portion of your back up,
• Training your users on your company email policies.

Confident that your email services are now secure, you can roll up your sleeves and attack the next item in the pile of projects that is sitting on your desk, right?

Not just so fast. Unfortunately, there is still quite a bit of work to do.

What am I missing?

Like any other computer service, email requires many different users to share information with the email server or cluster of servers. Each user connects via a desktop computer, a laptop, tablet, or smart phone; as result, there is a two way communication going on between them where data is exchanged. Can you see where we are going with this?

That’s right. Even if the servers that drive your company’s email are secured, there still remains that one variable that is often the root of so many security problems – the user.

If just one of those many users connects to the company’s email servers with an unsecured or infected device, it could mean disaster for your organization’s email. Considering the fact that email is still the preferred method of business communication and you could have some serious problems on your hands.

Securing the endpoint

Your company can buy the top of the line security tools, train users until they can recite policies in their sleep and keep everything under a watchful eye, but all it takes is one zero-day vulnerability to be exploited on a device that a user connects to your network with and you can consider yourself compromised.

You see, attackers know that the weakest point in any organization is the user and his or her computer. Servers are often guarded with firewalls, intrusion detection and prevention devices, and diligent operators. The low hanging fruit is the user so that is where the attackers concentrate.

Training is always considered the best way to enforce security in an organization. The thought is that if people are aware of what the threats are and what they can do to stop them, then most attacks can be mitigated. We know that’s not the case. Training and education works, but only so much. Instead of being looked at as the solution, it should be considered a part of a larger plan to stop threats against your email. Other elements of the overall strategy should include:

Check your computers for malware

No solution is going to stop 100 percent of all malicious software from infecting computers on your network. However, having a solution in place that constantly scans your network devices for malicious software is a crucial part of your overall security because believe me, something is better than nothing. However, this means running anti malware software that will be automatically updated. Even better, make sure you can configure the solution so that users can’t opt to postpone the updates.

Update the OS and all software

After you have tested the updates and patches published for your computers’ operating systems and software, make sure that they are installed. Most patches are released to fix problems and plug up exploits found in the software code. Not updating your machines leaves them open to attack.

Update the browser

As email moves to the cloud, it is essential that the browser used in your organization is updated as regularly as any other software. This includes any plug-ins or extensions used by the browser. Even if you are still hosting mail services yourself, websites continue to grow as a method of delivering malware to computers, using a secured browser is essential to protect users from being infected by seemingly harmless sites that they visit.

Email security is not easy. As with any other portion of your infrastructure’s security, it takes diligence, knowledge and skill. However email security cannot be avoided because it is simply too hard of a task to complete. You can certainly look into solutions that help ease the workload and make up for any deficiencies when it comes to this job.

Secure Your Desktop – Protect Your Email

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Advanced persistent threats make email security a necessity

Most email administrators consider security to be a large part of what they do. With so many laws and regulations governing the storage, discovery and retrieval of email messages, security has become a second job to many.

Unfortunately, many administrators either forget, or simply aren’t aware, that securing email requires much more effort than hardening the email servers against attack. In order to fully protect your organization’s email and their contents the mailbox also needs to be defended. Especially when you consider how popular Advanced Persistent Threats are becoming with large cyber crime syndicates who use email not only as a way to harvest sensitive information, but also as a method of attack through phishing and social engineering.

By implementing the following tips into your security plan you can help protect against these, and the many other threats that your organization may face:

Create email policies to regulate the communication of confidential information

Email communication has become second nature in the workplace. It is quick, easy and it gives us a record of our conversation so we can refer back to any information at a later date. However, if the conversation contains sensitive information like login credentials, financials, personal information, and the like, then it can be extremely valuable to anyone who may harvest those emails.

By simply setting up, and enforcing, policies that restrict certain information from being sent via email you can mitigate the damage done if emails are exposed. At the very least, your policy should state that user logins and passwords (and/or PINs) not be communicated via email.

Teach users to encrypt their messages

One of the best analogies I have seen to describe the need for encrypting emails is one that compares email to a postcard. Basically, anyone who comes across it can read the contents if they want. This can be stopped by encrypting emails to prevent eavesdropping.

Encryption is a hard thing for many people. It requires additional steps, training and, in some cases, third-party software (such as PGP) yet it is really the only way to keep your messages private in transit.

Encryption shouldn’t be limited to sending and receiving messages alone. Any email that is stored on a hard drive (think personal folders), a network drive, backup servers or archive systems should also be protected from any prying eyes.

Get rid of old email

A long time ago, storage space was a precious resource. Nowadays inboxes can be easily scaled to hold enormous amounts of data. Unfortunately that provides a greater possibility that an attacker will find something valuable.

Email should be moved, or deleted, when their life cycle is up. Make sure to check with any regulations regarding discovery and archiving before getting rid of the old stuff, but if you combine this with encryption you will be taking great strides to protect older emails.

Practice good network security habits

Make sure that desktops are continually scanned for malware that could possibly expose email login credentials, filter Internet content to protect against malicious websites, understand how to properly use a firewall and update server and client software as needed.

In addition to the employing technology to help secure your email systems you should also consider human factors as well. One of the ways that people first discover that their systems have been compromised is by noticing an anomaly. Be on the lookout for log-ins that just don’t seem right whether it be the IP address, the time of day or even the length of time.

This can be one of the most tedious tasks to undertake when it comes to security but it is by far the most important.

Put the right solutions in place

In many small and medium-sized enterprises, the email administrator alone cannot be as vigilant as he or she would like. Even in organizations where there is team of professionals dedicated to security use necessary security tools to help them do their jobs. Smaller companies need to understand this as well.

By employing technologies that help manage email, backup and recovery, archiving and security, you are plugging the little holes that provide that chink in the armor most attackers are looking for.

No one said that email security is going to be an easy task, but it is one that cannot be ignored just because it’s too hard or it costs too much.

Tips for Better Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Internet’s Request For Comment system may be one of the world’s best examples of rule by majority consent, as it is the de facto set of ‘laws’ for how the Internet (and all its associated protocols) works, and is essentially a collection of documents that ask the world ‘what do you think about this?’

With literally thousands of documents in the collection, defining standards, recommendations, best practices, and the occasional joke, anytime you want to know the why behind how something is done, you need look no further than the RFCs. While they are replicated on countless websites, the official repository is found at http://www.rfc-editor.org.

RFCs evolve over time, and earlier RFCs can (and often will) be superseded by newer ones. There are several RFCs that address how our email protocols and the associated DNS records should work, and as an email admin, you should be familiar with the lineage of all the major email RFCs. Even those which have been superseded usually contain useful information, as most new ones define enhancements to a protocol, as opposed to completely replacing it. Over 300 of the RFCs have something to do with email; fortunately you won’t need to know them all unless you want to program a new email application. Below you will find a summary of the seventeen RFCs that email admins should have at least a passing familiarity with, and links to the online documents should you wish to read further. All links will open in a new window/tab.

DNS

The DNS records that support email include MX records, PTR records, SPF and Domain Key records. Each record format is defined within these RFCs. Here are the main RFCs concerned with DNS.

rfc 974 Mail routing and the domain system (MX records)

rfc 4406 Sender ID: Authenticating E-Mail

rfc 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

rfc 4871 DomainKeys Identified Mail (DKIM) Signatures

SMTP

The Simple Mail Transfer Protocol has evolved multiple times throughout its history, but each newer RFC ensures backwards compatibility with its predecessor.

rfc 821 Simple Mail Transfer Protocol (SMTP)

rfc 822 Standard for the Format of Internet Messages

rfc 2821 Simple Mail Transfer Protocol (SMTP)

rfc 2822 Internet Message Format

rfc 5321 Simple Mail Transfer Protocol (SMTP)

POP3

The Post Office Protocol has gone through a few iterations. Currently we are up to v3. You can review the RFCs for the earlier versions if you’d like to, but here are the ones relevant to the current version.

rfc 1725 Post Office Protocol Version 3

rfc 1939 Post Office Protocol Version 3

rfc 2449 POP3 Extension Mechanism

rfc 5034 The Post Office Protocol Simple Authentication Mechanmism

IMAP

Like POP, IMAP has gone through several iterations. The current one is IMAPv4.

rfc 3501 Internet Message Access Protocol v4

Security

While there are several RFCs that address various security mechanism within email, here are some of the ones you have probably dealt with or will deal with in your duties.

rfc 1991 PGP Message Exchange Formats

rfc 2246 TLS Protocol

rfc 2595 Using TLS with IMAP, POP3 and ACAP

Being familiar with the RFCs helps you understand what goes on between client and server or between server and server, and also reveals just how products from diverse manufacturers, running on many different operating systems, can still interoperate, making the exchange of messages and files possible.

There are several others related to email; which have you found most useful?

17 RFCs Every Email Admin should Know About

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

As promised, this article will continue highlighting some of the exploits that allow attackers to abuse a mail server running SMTP. In Part 1 we covered how buffer overflows can give an attacker escalated privileges and control of your server as well as how using commands to scan the server can provide a malicious hacker with plenty of useful information from your company’s email accounts.

However if email security were as simple as patching these two vulnerabilities then breaches like the one that effected Epsilon’s servers* may never have happened and the millions of compromised email address may at this time be safe.

Yet mail systems are compromised more often than we would like to think, and some of the following exploits may be the avenue of attack.

Attacking a mail server doesn’t always mean that someone is trying to steal information from your servers, just ask anyone who has been the victim of a Denial of Service attack. While DoS attacks are common against websites, a malicious hacker could easily bring a company or organization to a halt by disrupting their email servers.

When using a DoS attack against a web server a malicious hacker may use something like an ICMP flood or even something like a SYN flood to send an overload of packets to the server to the point of saturation. Since resources needed to run the service are being overused by the attack, the server crashes under the weight of the attack. DoS attacks against SMTP work in a similar way.

Abusing the SMTP command, RCPT TO is one way an attacker can send more messages than the server can handle at one time. The server under attack will eventually see its resources drained causing it to crash. Users will be without mail until this is remedied. Since any modern mail program can send a message to multiple recipients it doesn’t take sophisticated tools to launch such an attack.

• Relays

There was a time when an SMTP server allowed anyone on the Internet to send email through it because of the open mail relay configuration. After spammers realized how easily they could exploit this most relays were either shut down or blacklisted. However this hasn’t completely eliminated the problem.

Spam can still be relayed through a server when a spammer is able to compromise a weak user authentication. Whether they brute force their way into your users’ email accounts or socially engineer their way through, a hacked account can be used to relay junk mail rather easily. This could not only damage your company’s reputation but also result in your addresses being listed on the DNS blacklists.

Now before pointing the finger at the users, keep in mind that a poorly configured SMTP server could just as easily be exploited to relay spam as well. Oftentimes the lowest hanging fruit for a malicious hacker is the admin forgetting to patch a vulnerability or being completely unaware that it exists.

• Aliasing

Some mail admins may read this section and wonder why such an old exploit is listed here. If you are, your boss should congratulate you for keeping your systems up to date and being aware. However there is most likely a large percentage of people who are scratching their heads when they read this and thinking, “are my mail servers protected against this?”

Currently, Sendmail 8.14.4 is available for SMTP authentication. While any release of Sendmail that is more recent than 8.6.4 has seen this vulnerability patched there are still enough systems out there that for one reason or another still allow the decode aliases to be used as a way to compromise the system.

Check your UNIX mail server’s /etc/aliases file to see if the following lines exist:

decode: |/usr/bin/uudecode
uudecode: |/usr/bin/uuencode -d

If they do then not only are you running an old version of Sendmail but you are also allowing mail to be sent to a decode mail address to be piped through the uudecode program and overwrite files on it. If Sendmail is running as root, as it is in many cases, the attacker has complete control over that system.

While it has been years since a patch has been available for this vulnerability, understanding how it works provides you with two things:

1. An understanding of how vital it is to keep your systems up to date and effectively patched.
2. An understanding of how attackers work. Something as simple as this can give an attacker complete control.

Then again, if you find that your system is vulnerable to this exploit then it may be time to start looking at what else gives malicious hackers an open door to your servers.

*Epsilon has not, as of the time this article was written, released any information regarding how their servers were breached. One of the methods outlined in this article may not be the vulnerability that was exploited in this attack.

Common SMTP Exploits – Part 2

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Ever since the inclusion of SMTP-AUTH the Simple Mail Transport Protocol was thought to be on its way to a more secure messaging protocol and with Microsoft’s inclusion of Secure Password Authentication that addressed security issues with Microsoft mail clients mail administrators could easily be lulled into a sense of security that truthfully doesn’t exist.

Email security is much more than simply protecting credentials and authentication. Though most people associate an attack on an email server with private or confidential messages being compromised, the risks of running an email server are much greater than that.

As email is still one of the most widely used methods of business communication, attackers find this to be an attractive target. Not only because they want to see what is in your company’s emails, but because they know that 1) email can open the door to many other resources and 2) people tend to let their guard down when it comes to using email.

Below you will see some of the most commonly used attacks against SMTP servers over time. While some may no longer be an effective means of compromising a system or network, they do show the trends in exploits that attackers use and being aware of them will help keep you on your toes when it comes to securing your servers against vulnerabilities.

Buffer overflows occur when a program is writing date to a buffer (an area that is used to temporarily hold data while it is being moved) and the size limit set for that buffer is maxed out causing an overflow of data. Usually this will crash the system but it can also be used to breach a system’s security.

A common method of exploiting this vulnerability on an SMTP server is to attack with an extremely long email addresses. In the parameter smtp.maxname, the maximum length of the email address is set. If the maximum is reached, the buffer overflow can allow the attacker to gain control through the MAIL FROM or RCPT TO commands.

Another commonly used buffer overflow attack against SMTP servers is against the HELO command where, depending on the server, a command containing more than the threshold of characters can crash the server and allow the attacker to take control using elevated privileges. Piggy back this with the fact that many admins still use the same administrator name and password on multiple systems and you can see where this type of attack can be far more serious than someone simply snooping through the bosses emails. This can lead to a complete network being compromised.

Of course, these only represent a fraction of the different commands that can be susceptible to a buffer overflow attack. Basically any string that overflows a container’s limit can technically be exploited and new vulnerabilities are found on a constant basis.

• Scanning the email server

When debugging mailing lists, the EXPN command can be quite useful as it shows information about the user accounts on a mail system. Of course the information used can also be quite beneficial to an attacker as well. Likewise, the VRFY does the same thing.

If an attacker is able to run these commands on your mail system then they can be used to map valid usernames and even create a hierarchy of user accounts that can be more productive to later attacks since they can also see who belongs to different mailing lists. If they want the IT accounts, they can look for a mailing list associate with this department. Names and accounts for C-level executives, secretaries, the HR department, etc can all be obtained through this vulnerability.

Not only will this give the attacker an employee directory, but it can also provide information about employees that can later be used in social engineering attacks against more lucrative targets within the organization.

With so many server tasks being automated, many admins may go through their careers never having used the EXPN or VRFY commands so they may be completely unaware that they are available. If these are not things that you use in the day to day operations of you or the IT staff then they should be disabled on any SMTP servers.

The second part of this series will look at abuse and relaying as well as how aliasing can be used to compromise your mail systems.

Common SMTP Exploits – Part 1

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my previous post, “Reasons to Virtualize Your Email Servers – Part 1 of 2”, I enumerated three reasons for virtualizing email servers. There are many more reasons why administrators and organizations would want to virtualize their email servers that I will discuss now.

Here are three of those reasons which I discussed in my previous post on why administrators and organizations would want to virtualize their email servers:

1. Understand and learn a new technology.
2. Better use of resources.
3. Lower software licensing costs.Here then are five more reasons for companies and organizations to virtualize their email servers.
4. When your company virtualizes their email servers they are reducing the number of physical boxes that they have to keep and maintain. Email administrators often manage, and administer, other machines besides their email servers. And if your IT department runs as a profit and loss center then administrators should be very interested in reducing the number of boxes they have to administer if they know that they are going to benefit financially. When there are fewer boxes to maintain then your costs are lower. Fewer boxes mean lower cooling costs. Fewer boxes also mean lower power costs as well. Lower power and cooling costs is most likely a part of your company’s goals for a greener environment.
5. Virtual email servers also mean lower hardware costs. Having fewer hardware boxes obviously results in a lot of savings to your company and to your IT department. This can free up money to be used for new software tools or applications for IT administrators and email administrators to deploy within their environment as needed.
6. One of the biggest benefits that you get when you virtualize your email servers is that you – as an email administrator – get more flexibility when it comes to managing the resources that you need to get the best performance out of your email servers. A virtualized server can have resources dynamically added to their operating profile to accommodate unexpected spikes in utilization. Virtual CPUs, memory and even I/O adapters can be added or removed from your virtual email server’s operating profiles as needed. In some virtual environments it is even possible to define different profiles for the same virtual server such that an administrator can switch to whichever profile fits the resource needs of the current utilization rate. Having this flexibility to have a dynamic virtual server can be a great benefit to administrators especially for changing email server loads or when balancing the loads across multiple email servers is not possible. Simply change the amount of resources of the virtual email server to adjust for heavy or light workload requirements as needed.
7. Virtualization of email servers makes it possible to run different versions of Outlook or Exchange in different operating systems. Email administrators can even fine tune those email environments by specifying the different rev levels of the operating systems. Email administrators could test new versions of Outlook or Exchange Server on different virtual servers all within the same physical box. Then, when it is convenient for them, they could roll out the newer versions of Outlook or Exchange into their virtual production environment without needing to reload the OS or the email software onto a different physical box. Simply flip the software switch on their virtual email servers and they are now live in a much shorter amount of time than if they had needed to test, stage and go live on multiple physical boxes.
8. I’ve already discussed the savings in power and cooling that can be realized when going to a virtual email server environment. But there are other infrastructure advantages as well. The number of I/O adapters is reduced which also can reduce the amount of cables and switches that are needed in your data center thus further reducing your overall IT costs. Then there are rack space requirements that can also be reduced. And the assorted peripherals such as video, mouse and keyboards that are needed is also reduced in a virtual email server(s) environment.

In summary, it is very easy to see the advantages for moving your email servers to virtual email servers. The gains that can be realized in maximizing your resource utilization rates, flexible use of resources, operating costs and cost savings in hardware and software should be very easy for email administrators to demonstrate when presenting the virtual email servers advantage to upper management.

5 More Reasons to Virtualize Your Email Servers – Part 2 of 2

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

More and more companies are learning about virtualization technologies. And there are a lot of companies that have already gone from a dedicated server environment to a virtualized server setup in their data center.

Companies, IT directors, their staff and administrators are all considering the advantages and disadvantages of virtual server technology and whether it is the right choice for their company. There are many reasons to go to a virtual environment. And when going to a virtual environment a frequent question is which of our servers would benefit from being virtualized?

Email servers are great candidates for virtualization. If your organization is small then you are probably already running your email server or servers on small boxes with a certain amount of CPU, memory and disk drives. One of the parameters to look at when considering a virtual server is to ask the question: what is the current CPU utilization of my existing email server?

Typically, most data centers are running their email servers at anywhere from 20 to 25 percent of CPU utilization. If that is the case for your company, and you have other servers also running at 20 to 25 percent, or less, then you are a good candidate for an email server virtualization effort.

And what does it mean to virtualize my server? In short, a server virtualization means that we are consolidating one or more existing servers onto one physical frame or box. Each of the virtual servers gets their own allocation of virtual CPUs, memory, disk storage and I/O adapters. A combination of software and firmware performs the distribution and balancing of those resources among the virtual servers that have been defined on the physical frame or box. Usually a hypervisor is involved as a sort of traffic cop for distributing those resources.

Here are some of the many reasons to help you and your company make the decision to virtualize your email server(s):

1. The very reason why an email administrator would be interested in virtualizing their email server is because of the potential benefit to their resume. An administrator might be scratching their head at this point and be thinking “but, now I have to learn about another new technology again. It’s going to take more time away from my existing work, it’ll be time consuming and I may not even like it.” But that’s exactly why an email administrator should be looking forward to virtualizing their email servers – because most email administrators also perform system administration. And if an administrator is a good technologist already then getting to learn a new technology, such as virtualization, can turn them into a great technologist. Understanding new technologies, such as virtualization, can only add to an administrator’s resume and make them more marketable in the workplace.
2. Given that most companies are running their email servers at anywhere from 20 to 25 percent of CPU utilization and have other servers also running at 20 to 25 percent, or less, they can consolidate those physical servers onto one box running virtual servers instead. Server consolidation can result in 3 to 1 or even a 4 to 1 server reduction ratio in some cases. The result is that they can get a better server utilization of between 60 to 80 percent. This means that the physical server is not wasting resources. CPU, memory, disk drives and adapters are getting a higher percentage of usage and are thus earning their money so to speak. Why pay for resources that are only used for a small percentage of the time?
3. One of the added benefits of using fewer resources, for multiple servers, is that your licensing costs go down. Let’s say that you consolidated 4 email servers, each with 2 CPUs for a total of 8 CPUs, down to one physical box with just two CPUs – a 4 to 1 reduction ratio. That means that rather than paying for 8 CPU licenses in the dedicated server days your company is now paying for only 2 CPU licenses for your virtualized environment. This is something that an IT department can appreciate and see the value of. It also means that for an email administrator they are no longer administering four physical boxes but one physical box. This results in not only a savings of money but also time, time that is valuable to all email administrators and system administrators in general.

In my next blog post I will describe five more reasons why it makes sense to virtualize your email servers.

3 Reasons to Virtualize Your Email Servers – Part 1 of 2

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Most companies need an internal SMTP relay at some point. Whether this is for alerting systems, or the scan to email features of their printers, or the “phone home” capabilities many hardware systems offer, the ability for an internal device to send an email to both your internal systems, and out to the world is often needed, and frequently either over, or under engineered. 

Microsoft includes an SMTP service with all versions of the Windows operating system, and the SMTP service is perfect for the job of taking all the non-Exchange based emails in your company and passing them through a single point without having to pass them through your Exchange system unless they are destined for an internal mailbox.

I have seen companies establish dedicated servers, or purchase third party applications, for what is really a very light-weight task that can be added to any available file server or other server with minimal resources. Let’s look at how to add the service, how to configure the service, and some considerations for its use.

Identifying the need

If you have printers with a scan to email feature, SANs or other vendor supported systems that want to email reports and alerts to the vendor, alerting systems that like to send SMTP messages about events, or anything else that needs to send email out to the Internet but that you don’t want to assign an Exchange CAL, then this service is for you.

Choosing which server(s) to use

The SMTP service is available on all versions of the server platform, and requires almost no RAM, CPU, or disk, so it can be installed on essentially any system you have. I like to use file servers, as they tend to have resources to spare (other than free disk space) and are in a central location. This is good, as you want this service to be available to your entire network. I like to deploy two systems, and set up DNS round robin so that the service is highly available. Of course, many older printer/scanners can only be pointed to an ip.addr, so if this is really critical, you need to set up a pair and use NLB.

Getting ready to install

If you are going to let your SMTP relay send mail directly out to the Internet, identify the external address your relay will be NAT’d to on your firewall. Establish an MX record with a weight of 99, and update your SPF record to include this system. If you are going to pass email through your content inspection system, get that internal ip.addr or FQDN, and ensure it is setup to accept mail from your relay.

How to install the service

In Windows 2008, the SMTP service is considered a feature. Here is how you add that. Open an administrative command prompt and run this command as a single line (wrapped to fit the column.)

servermanagercmd.exe -i web-metabase web-lgcy-mgmt-console
 rsat-smtp smtp-server [enter]

How to manage the service

To manage this feature, use the Internet Information Services (IIS) 6.0 Manager, which was added to your Administrative Tools menu when you installed the SMTP Service. In the 2008 SMTP service, the default configuration will NOT relay for any host, which is a good thing. We want to provide a service, but we don’t want to open the floodgates.

1. Right-click your server to access the properties.
2. On the General tab, the defaults should be acceptable for most uses, but you might want to enable logging so that you can see how your relay is being used.
3. Click the Access tab.
4. If you want to require authentication, click the Authentication button. However, since most printers won’t support that, you probably want to leave Authentication alone.
5. Click the Relay button. Notice that by default, no relay is allowed. If you are absolutely certain that this server is will not be abused, and you do not want to restrict relay, you can click the radio button for “All except the list below.” Do not do this on a system in the DMZ, or that has a static NAT assigned to it on the external interface of your firewall. Doing so would create an ‘open relay’ and we all know how bad a thing that is. I recommend that you add the individual addresses of systems you want to permit, or as a compromise, add your internal subnet(s.) This is less work than adding each individual machine, means new systems can start relaying mail without your involvement, and still ensures that your server won’t become an open relay to the world.
6. Click the Messages tab, and review the default limits on number and size of messages. Adjust to taste.
7. Click on the Delivery tab, and then the Advanced button. If you are going to let your SMTP relay send mail directly out to other MTAs on the Internet, fill in the FQDN of your system with a name that will map to the MX record you created in “Getting ready to install” section. If you are going to send email through another system that does anti-malware and content inspection (recommended) then fill in the “Smart host:” field with the ip.addr or FQDN of that system. Smaller business that use an ISP for email will want probably need to fill in the FQDN of their ISP’s relay here. Click OK.
8. If the upstream relay requires authentication, click the Outbound Security button, and set the appropriate credentials. If not, you are done.
9. Test your relay out, using the telnet process we covered in this article.

If all is well, your server should be sending emails like a champ. Remember, whether you assign it a dedicated NAT address on the firewall, or let it use the global, you will want to add that to your SPF records so that external systems will accept your email. And since email is something you should keep an eye on, make sure your egress filtering doesn’t allow all systems to send email directly out; only your SMTP relay and mail infrastructure should have that privilege.

Got relay? Using the Microsoft SMTP service

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Like all servers, email servers are subject to heavy loads and when that happens the servers can slow down to a crawl. And if administrators are not monitoring the performance then they’ll be sure to find out about the slower performance issues from their users.

Email servers can slow down for many reasons such as increased traffic flow or attacks on the server. Sometime it is a result of increased spam messages. Administrators can use the Queue Viewer graphical user interface to view information about messages and various queues such as the delivery queue. Additionally the command line interface for Exchange server can also be used to pull out information. Actions such as modifying the status of queues and messages can be performed individually or in bulk. One or more objects can be selected to perform these actions on.

In Exchange server, queues are used to hold messages before further processing can occur. There are five queues that exist only on Hub Transport servers or Edge Transport servers. Each of these queues is used in the processing of email messages which flow through the server. The processing queues include the following:

• Mailbox delivery queue
• Poison message queue
• Remote delivery queue
• Submission queue
• Unreachable queue

The transport server processes the messages contained in the queues. And access to the message queues is performed by the Exchange Server using the Extensible Storage Engine (ESE) low-level APIs.

Sometimes the queues fill up with many non-delivery reports from the postmaster account. This condition can occur if your computer is the target of a reverse non-delivery report (NDR) attack. This issue can be resolved by creating a recipient filter to prevent Exchange Server 2003 from accepting messages that are sent to recipients who do not exist.

Another problem that can happen is when message flow is slow to the local delivery queue. When this occurs then email messages in the Simple Mail Transfer Protocol (SMTP) queue will get backed up. These email messages that are bound for local delivery end up getting trapped in the SMTP queue. A further undesirable result is that of high disk queue lengths on the Exchange Server’s install drive. This install drive is typically used for the C:\Program Files\Exchsrvr\ directory. These conditions can occur when the information store working folder’s disk drive gets too busy and slows down.

This type of problem can be corrected by pointing the working folder of the information store used for email message conversion to a faster drive. An administrator can follow the steps below:

1. Start – Run – type in “regedit” to start the Registry Editor.
2. Locate the following key in the registry and then select it: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
3. Double-click Working Directory:REG_SZ:Folder_Path in the right hand pane.
4. Type the path of a folder on a faster drive in the String Editor box.
5. Click OK.
6. Close the Registry Editor.

As always, any time you touch the registry you should first make a backup of the registry. This way, if there is a problem for whatever reason; you’ll be able to restore the registry to a known working point.

A similar problem can occur because of a disconnected SMTP mailbox. This can cause messages to be held in the local delivery queue. Administrators might try to dismount and then remount the information store to correct the problem. This action, however, can result in more event error messages being logged in the application log such as the following:

Event Type: Error
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 326
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Service Account failed to logon to the store as
/o=organization/ou=First Administrative Group/
cn=Configuration/cn=Connections/cn=SMTP
(ServerName)/cn={CCCF3BE6-219C-4379-985D-851B766EDDC7}.
Error code : 0x80040148. For more information,
click http://search.support.microsoft.com/search/?adv=1.

Event Type: Error
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 326
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Service Account failed to logon to the store as
/o=organization/ou=First Administrative Group/
cn=Configuration/cn=Connections/cn=SMTP (ServerName)/
cn={CCCF3BE6-219C-4379-985D-851B766EDDC7}.
Error code : 0x80040158. For more information,
click http://search.support.microsoft.com/search/?adv=1.

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1194
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Accept clients on external interface SMTP
failed with error 0x80004005. For more information,
click http://search.support.microsoft.com/search/?adv=1.

This problem can be resolved – assuming the Active Directory object for the SMTP mailbox is missing – by creating a new mailGateway object in Active Directory. This newly created object will have a new GUID. The next time the store is mounted the information store will create a new SMTP mailbox object.

Troubleshooting Message Queues

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The worst possible time to define your uptime and availability requirements for an Exchange environment is when that environment is unavailable.  No email administrator wants to hear “We need this working within 2 hours” when they are looking at a dead server that is going to take all night to recover.

Uptime and availability should be defined within an SLA, or Service Level Agreement.  An Exchange Server SLA should exist in all organizations, even those that provide their own internal IT services.  The SLA is between the IT supplier or IT department and the rest of the business, and clearly defines what is an acceptable downtime or outage of the Exchange environment.

Why Are SLAs So Important?

The existence of an SLA supports many facets of the design and operation of the Exchange Server environment.

Budget – When a business defines their service level requirements they are making a commitment to providing the funds necessary to deliver those service levels.  An SLA is one of the best pieces of leverage the IT department has to secure those funds and implement an appropriate Exchange system.  Without the backing of an SLA the IT department may struggle to get approval for Enterprise server licensing, multiple servers for clustering, and other high availability components.

Server and Network Design – Exchange Server environments are designed to meet defined SLAs.  Certain uptime expectations can only be met with the right server design.  A business that is willing to go a day without email would not need the same infrastructure deployed as a bank that can’t go more than 15 minutes without email.  Clustering, redundancy, site-to-site failover, are all design points that would be included or excluded based on the SLA.

Third Party Warranty – In very resilient environments, such as those with clustered servers, this is less of an issue.  But for an environment with SLAs for single points of failure, the right warranty response times need to be in place for SLAs to be met.  A 4 hour return to service target will not always work if it is paired with a 4 hour vendor response time, because the vendor meets their target simply by showing up on site within 4 hours.  After they then spend time fixing or replacing failed components, the IT team then has to potentially deal with other software and data recovery processes.

Backups – The backup system will be heavily influenced by the SLAs that are in place.  If the backup system cannot restore all of the required data within the SLA timeframe then of course the SLA cannot be guaranteed.

Staffing – The SLA will define the service levels for different times of day, and this will impact staffing levels.  If 8×5 support is all that is required, then that is a different staff level and rostering schedule than 24×7 support would be.

It all starts with the SLA.  Sometimes an organization has trouble defining their requirements before an actual outage occurs.  For those without any SLA at the moment my suggestions would be:

1. Analyze your current infrastructure and make an estimate as to how long a recovery would take under a variety of failure scenarios (e.g. single mailbox, single database, single server)
2. Identify the business processes that email supports and is involved in
3. Survey a sample of staff from various departments and teams, ensuring that each tier of employee is well represented in the survey

From that exercise you will gain an understanding of your business needs, technical capabilities, and the gaps that exist between them, and you can then begin work to formalise them as SLAs and implement changes in the environment to close those gaps.

Exchange Server SLAs, and Why You Need One

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Sending and receiving emails over the network involves the transmission of data to and from common application services such as network services and mail services. At the lower levels in the technology stack, email is sent to services identified by their well known port numbers. Between email clients and email servers the port number used is port 25 for sending emails over TCP/IP networks.

On most email servers, a background process, or daemon, will listen to port 25 for any incoming email. This is the port that clients make socket connections in order to be able to send their emails. Sometimes the port is blocked or unavailable on the email server.

When retrieving email from the server there is another port that can also be blocked and thus prevent emails from being receive. If port 110 is blocked then the client cannot pull down their messages.

Sometimes administrators will block port 25 to stop the flow of spam and/or viruses from their servers. The problem is that you’re effectively throwing the baby out with the bathwater. To be able to send emails and also prevent spam or viruses you need to be able to write some kind of filtering code.

This can get sticky if you’ve outsourced your email servers. Your control is obviously limited in this scenario.

However if you have some control over the email server you can configure your settings such that the ports used for sending and receiving are different than the standard ports of 25 and 110. Spam will still be directed – thru email – to ports that essentially become bit buckets. You decrease your exposure to risk while still maintaining your normal business operations which include communication by email.

How will you know if your ports are blocked?

If you’re using Exchange server clients to send or receive messages you’ll know by the type of error messages you get when you try to send a message to your Simple Mail Transfer Protocol (SMTP) server. One of the error messages you might receive will look like the following:

“The connection to the server has failed. Account: ‘your_account’,
Server:’your_SMTP_server’, Protocol:SMTP, Port: 25, Secure(SSL): NO,
Socket error: 10061, Error Number: 0x800ccc0e”

Note that the specific port number 25 is listed in the error message.

And if you are trying to receive emails from your Post Office Protocol version 3 (POP3) email server, then the error message you might receive will look like this:

“The connection to the server has failed. Account: ‘your_account’,
Server:’your_POP3_server’, Protocol:POP3, Port: 110, Secure(SSL): NO,
Socket error: 10061, Error Number: 0x800ccc0e”

Here you see port 110 listed in the error message.

Both of these messages indicate that ports 25 and 110 are unavailable. While these can prevent email attacks from occurring and prevent viruses from spreading they as already mentioned negatively impact the sending and receiving of emails. Thus, as an administrator you need to know who to investigate the status of these ports and how to turn back on these ports (listeners).

The most common utility to use for investigation is the “netstat” command.

The “netstat” command is often used for displaying the contents of the routing table but can also be used to verify if those services are running on ports 25 and 110. Normally these ports are “up” and running whenever the services for the Exchange Server are started. Port 110 for the Post Office Protocol version 3 (POP3) is automatically started on the Exchange server as soon as the Information Store service is started. And when the Internet mail service is started then port 25 is also started. To verify that they are up and running you can perform the following steps.

• Go down to the Start button and click on it to bring up the menu.
• Pull right on All Programs and then again pull right on Accessories.
• Select Command Prompt to bring up a command prompt window.
• You might want to increase the screen buffer size to make viewing of the command output easier to read. You can do so by right clicking in the upper left corner of the command prompt window. Click Properties and the click on the Layout tab. Increase the screen buffer size to something like 600 or 700 – whatever is your preference. Save the change for the current window or modify the shortcut which started the window if you are comfortable with the change.

Now you’re ready to run the netstat  command. Type in “netstat –an”, hit enter and then watch all that output of services go scrolling by. Because of the change you made above you’ll be able to scroll backward and look for the lines that indicate that your listeners (ports) are up and running.

Proto  Local Address     Foreign Address        State
TCP    0.0.0.0:25             0.0.0.0:0              LISTENING
TCP    0.0.0.0:110           0.0.0.0:0              LISTENING
     
If you cannot find these entries then this means that those services are obviously not running and you will need to troubleshoot further.

Troubleshooting Error Code 0x800ccc0e

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

As an email administrator it is often asked of you to produce statistics showing how your email server is being utilized. This can be very important to IT departments that are run as their own profit and loss centers without the benefit of funding that comes out of the company budget. It is to any administrator’s advantage that they be able to run a set of comprehensive reports that will allow them to charge their customers an appropriate amount for their services.

Some of the reports that an email administrator should be able to run include:  the amount of messages sent and received by any department customer, statistics related to message size or number of receivers, delivery times – what week, day, time and other factors, reports based on distribution lists and reports based on protocols used.

Reports based on the number of messages sent and received by any department should allow the administrator to drill down to various levels of detail starting with a specific email message to including the number of messages transmitted per week, month or quarter. The administrator might be interested in being able to monitor a specific user or department or division within an organization. Perhaps an item of interest might be how many times a specific user went over their email storage threshold during the past month, quarter or year.

Email storage reports are of obvious importance especially if the departments are being charged back for their usage. It is a lot easier to ask for more storage when it can be shown that the sales organizations growth in storage needs is in line with their growth in sales revenue.

Sometimes it is useful to track what protocols are being used by the recipient’s email clients. They will consist of IMAP, POP3 and SMTP email protocols. Code is available on the internet to facilitate this kind of monitoring. Knowing which protocols are being used by email clients can help the senders to tailor their emails for the clients used to display those emails.

These are just a sampling of a few of the many reports email administrators should be able to run in order to successfully categorize and monitor their company’s email usage.

The Importance of Email Server Reporting

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Register reported that popular business ISP ClaraNet was down since early morning on April 3rd and estimated that that email service would be out until sometime late the following day at the earliest. ClaraNet said that service was partially restored – users could send and recieve email but c0uld not access any emails stored in their inboxes. The ISP say no emails have been lost.

          According to ClaraNet’s support site, incoming mail has not been lost, but is queued waiting to be delivered. The firm apologised for the inconvenience and targeted 6pm tomorrow for the restoration of full service.

The company has not publically explained the reason for the outage but some sources speculate that it was related to a failed RAID controller. Outages do happen, and it’s a good reminder to always have some sort of backup system in place just in case so that you can continue business as usual. Like electricity, you never realize just how much you depend on email until you’re suddenly cut off from it!

Another thing to remember in case of an outage is to communicate with your customers and vendors. Placing a notice on your website and/or on your company’s automated phone system is a good idea. A little communication goes a long way in building customer confidence and loyalty!

ClaraNet Suffers Email Outage

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In any large organization there will come a time when the IT department will have to migrate their existing users to a new mail server. Lots of times this migration is a result of two companies merging their IT operations together. Other times the migration is driven by a company’s decision to standardize on one platform so as to simplify administration and reduce maintenance costs.

The migration can be made less painful for users if careful planning is performed during the initial stages. Many tools exist to convert mail folders from one format to another. For example, there are tools to convert from Outlook/Exchange mailbox and personal folders (.pst files) to the Domino server mailbox or local .nsf files

Or in the case of going from an existing IMAP server to Google Apps there are tools that help domain administrators transfer the contents of users mailboxes without risking the loss of existing mail. Of course having a recent backup is most important to insure against the loss of email. In addition, you want to verify that the migration tool you use will keep and/or display a log of each mail message migrated including the sender, receiver and date of the migrated email message.

Folder structures should also be preserved so that users can stay as productive as possible after email migrations. You don’t want users having to spend their time recreating the email folders they use for staying organized nor having to repopulate their email folders from backup. You want to make the transition as smooth as possible.

Email migration efforts should also include the users’ calendars and contacts which are part of an email environment.

Testing your email migration strategy should also be a part of your migration plan. Testing on several small accounts can be performed to verify that your migration tools will work as needed before a larger migration effort is enacted. If you have a very large number of users then consider performing the migration in batches. That way you can track the success of the migration and if needed go back and correct the procedures or scripts as problems arise.

Your migration process is also a good time to scan for viruses and filter out email that doesn’t meet your company’s policies for appropriate email. It is also a good time to notify your users to reduce the size of their email folders and any unnecessary attachments. Set a limit on the size of the mail messages that will be allowed to be transferred and notify your users of these limits. Setting a limit on the number of folders to be transferred per user is another way to minimize the time needed during migration.

Consider this a fresh start and take advantage of this migration effort for the benefit of your users.

Email Migration Management

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

As an IT administrator you have to make sure your servers are up and running at all times, with email being so critical to the business as users communicate via email for almost everything.  You want to make sure you search for a good, easy-to-install monitoring solution.  The first question you have to ask yourself is what you really need in monitoring software.  To begin with you want to check the health of the system and the performance, check the email traffic and see if there are problems.

You do not want a call from the end users alerting you that a problem has occurred.  You want to be a step ahead and by having a system that can alert you of a potential problem would be ideal.  You can be alerted either via email, SMS or a mobile device.  Another aspect is to minimize the downtime of a server.  The software should be able to take corrective action if a potential problem arises.  The corrective action can be set on certain criteria that you set up before hand, such as restarting a service or do a server reboot.

Next is to check if the software requires you to install an agent.  Depending on your bandwidth, installing an agent may not be good.  If that is the case, look for software that does not install agents.  Also you want to be able to customize some functions – create scripts to check specific executables, event logs, disk size, etc.

Each administrator has different requirements but all can concur that having a monitoring solution in place that proactively alerts and addresses problems is better than having nothing at all.  In the end you want to find a solution that works within your needs and budget.

Tips for Managing your Email Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators