I read a tip just recently that advocated the use of fake MX records as a spam deterrent.  The solution was apparently devised after struggling with the server load that was being generated by spam emails.

As we all know, spam makes up as much as 90% of global email traffic, so it is not unusual for spam load to be a serious issue for email server performance.  The natural instinct is to prevent that load from being applied to the server in the first place.  Fake MX records are not the best way to do this.

MX records are the DNS records that tell email servers where to send email that is addressed to a particular domain.  For example, if I send an email to john@company.com my email server will look up the MX record for company.com, determine the associated IP address, and transmit the message over SMTP to that IP address.

To maintain redundancy most organizations will use multiple MX records that point to multiple email servers, so that if one is unavailable the others can still receive incoming email.  MX records are given a priority, an arbitrary number that is only relative to the priority of other MX records for that domain.  The lower the number, the higher the priority.

So for the same example as above, my email server looks up the MX record for company.com and gets the following response.

company.com MX preference = 10, mail exchanger =
 maila.company.com

company.com MX preference = 20, mail exchanger =
 mailb.company.com

It knows then to send to maila.company.com first, and then try mailb.company.com if the first try is not successful.

The idea of fake MX records is to create multiple MX records (usually at least 3) of varying priority, and have the highest and lowest priority MX records be pointing to non-existent servers.  The theory is that spammer’s botnets will only try to send to the highest or lowest priority MX, and then when they get no response will give up and move on to the next victim.  Some email administrators use as many as 10 MX records with only one real one among them.

The theory has some merit.  Spammers want to send out as much email as possible so usually won’t waste time and resources by having their bots try multiple MX records for a targeted domain.  However the technique impacts legitimate senders as well. Continue reading Fake MX Records More Harm Than Good

When you are transitioning from a legacy Exchange version to either Exchange 2007 or Exchange 2010 you will come to a stage in the project at which you need to plan for the migration of mailboxes to the new servers.

In small to medium size businesses the considerations are fewer than for larger enterprises, but they do share several in common.  Generally speaking you should plan for the following items.

End user interruption – when a mailbox is moved the end user will be disconnected from it.  Older versions of Outlook do not handle this very well, but even newer versions will need the end user to restart the application to connect to their new mailbox.

This means that it is often best to schedule migrations to occur outside of normal business hours.  Evenings and weekends are very common for this.  If a business operates 24 hours a day using rotating shifts then you can schedule migrations to occur so that a given user is moved when they are not rostered on duty.

Transaction Logging – a mailbox migration means that on the target server (the new server) a whole bunch of new data is being written into the databases.  This creates a very large amount of transaction logging, often much larger than what a normal day’s email traffic would generate.

There are a few ways to manage this.  Moving mailboxes in smaller batches keeps logging to a minimum but means migrations will take longer.  Provisioning large amounts of disk space on the logging volume means bigger batches can be migrated, but after the migration is finished it can mean wasted disk space that is not needed for day to day logging levels. Continue reading Planning Considerations for Exchange Mailbox Migrations

In most businesses the topic of shared email and other mailbox features will come up at some stage.  A business will have certain requirements that the Exchange administrator needs to configure the system to meet.  Depending on what those requirements are the actual configuration used will vary.

One of the most common situations is the sharing of email addresses.  A group of uses need to receive email sent to a certain email address other than their own personal email address.

Sometimes it is appropriate for this to be achieved simply by using a secondary email address on the user’s mailbox.  John Smith can have john.smith@company.com as his primary email address, but also receive email sent to his predecessor’s email address of greg.jones@company.com.

In other cases this does not work so well.  A reception desk staffed by more than one person throughout the week makes it impossible to assign reception@company.com as a secondary email address to each individual person’s mailbox, because an email address can only exist on one mail-enabled object in the organization at any one time.

The solution here could be to use a distribution group, or to use a shared mailbox.  Each has its pros and cons.  A distribution group delivers each mail item sent to the address to each member of the group.  This works fine for newsletters, memos, and other broadcast type information, but not so well for items where only one person needs to take action.

In those cases a shared mailbox is better suited, because it means a single instance of each actionable item and everyone who shares the mailbox can tell when something has already been actioned.  Shared mailboxes are commonly used for Help Desks and sales teams so that a single email address can be publicized and a team of people can access the mailbox to action new items. Continue reading Shared Email Address Scenarios

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing. Continue reading The Importance of SSL for Exchange Servers

The release of Google Buzz adds another new step in the ongoing evolution of online communication.  And I hope you’ve been paying attention to the evolution so far.

Buzz, along with Google’s other recent release Google Wave, add real-time communication to traditional email inboxes in ways that, quite frankly, most people will fail to grasp for some time yet.

These new Google releases are part of a long running change in the consumer side of online communications.  Looking back 10 years the average web user had email, newsgroups, and basic instant messaging, all performed on their computers.

Today we have blended platforms such as Facebook that include email-style messaging, real time chat, and broadcast communications such as status updates.  In addition to this more and more content is shared in non-text formats.  Photos and videos are exchanged between friends as often as written messages are.  Business deals are done on Twitter.  And no one ever complained that a sales pitch was too short.

Business communications are charting a similar, but slower evolution.  Email quickly replaced much of our phone and fax communications and became a collaborative workspace, albeit a highly inefficient one.

In recent years collaboration has moved out of the inbox and into document management systems and intranet workspaces.  Faxes go directly to electronic records management systems instead of being dropped on our desk.  And telephony systems are integrating with our real-time communications servers to make voicemail and presence data available to us at our desks or on our mobile devices. Continue reading What Will Email Be In 10 Years?

Backups are one of those things in IT that most people know are very important, but not everyone treats them that way.

More times than I care to remember I have entered a disaster recovery situation for an email system in which the recovery options are limited because either:

• The backups hadn’t been running and no one realised
• The backups hadn’t been running and people knew but didn’t do anything about it
• The backups had been running but had never been tested

I can tell you that the worst possible time to put your backups to the test is during a real disaster situation.

Take a look at your current email backups and ask yourself these questions.

Are the Backups Running?

Even if you know that the backups have been set up and scheduled you still need to know whether they are actually running.  It is not a nice feeling when you open up the backup history of a server and see that every backup job has actually failed.

Good backup software includes alerting options for the outcome of a job.  Set these options to send email reports to the people responsible for checking the backups.  It is also advisable to have a weekly or monthly summary report sent to other people such as managers so that they can verify that the backups are being done.

Are the Backups Successful?

Not only do you need to know whether the jobs are running, you also need to know what the outcome of the backup job was.  Obviously the goal is a successful backup job, but in the real world backups will fail from time to time.

Have a response and escalation process in place for any failed backup jobs so that they are investigated immediately that day.  If the problem can’t be resolved, or a consecutive day’s backup also fails, escalate the problem to a senior administrator or seek vendor support.  Some environments can tolerate a single failed backup but the risks grow exponentially with every subsequent failure.

Are the Backups Protecting the Data You Think They Are?

It might not occur to everyone to check not only the successful outcome of the backup job, but also verify that the job is backing up everything you intend it to.  No backup software will report that it failed to backup something it isn’t configured to backup in the first place. Continue reading Are You Sure Your Backups Are Working?

Some Exchange Server 2007 and Exchange Server 2010 roles require Internet Information Services (IIS) to function.   On these servers Exchange will install a series of IIS virtual directories.  In this post I will describe the Exchange Server virtual directories and their purpose.

/owa – This is the directory for OWA (Outlook Web Access on Exchange 2007, and now called Outlook Web App on Exchange 2010), which is the web browser version of Outlook that is usually accessed by remote workers.  The /owa directory is for access to Exchange 2007 or 2010 mailboxes.

/Public – This is the directory used by OWA users when accessing any Public Folders in the organization.

/Exchweb – This directory is used for OWA access for Exchange 2003 or 2000 users but is not usually accessed directly by the end user.  The OWA session will automatically refer the connect to this virtual directory when necessary.

/Exchange – This directory is again used for OWA access.  When an Exchange 2003 or 2000 mailbox user access the /Exchange virtual directory they are proxied to their mailbox.  For Exchange 2007 or 2010 mailbox users they are redirected to the /owa directory for their mailbox access.

This is useful during the transition from legacy Exchange versions to 2007 or 2010, because users can continue to connect to the /Exchange directory and the result will always be that they connect to their mailbox, as long as the server does not run the Mailbox Server role.  In other words, the /Exchange directory only works for legacy mailbox users if the server is a dedicated Client Access Server (though it can also contain the Hub Transport Server role without a problem). Continue reading Overview of Exchange Server Virtual Directories

Microsoft Exchange Server has used Connectors in various ways for many different product versions to date.  Exchange Server 2007 and Exchange Server 2010 both use the same types of Connectors in their organizations.

Even in simple organizations some people become confused by the variety of Connectors and their purposes.  Here is an explanation of each type of Connector for Exchange Server 2007 and 2010.

Send Connectors

Send Connectors are responsible for sending email to servers outside of the organization.  This might also include Edge Transport Servers, which are non-domain member servers usually located in a secure DMZ for sending and receiving internet email.

Send Connectors can be configured in a number of different ways.  The typical Send Connector for an organization sends all outbound email to a smart host or uses DNS to route the mail directly to the receiving party.

More specific Send Connectors can be used to send email destined for particular domains to different servers.  One example would be a Send Connector that routes email across a secure VPN to a partner domain rather than go via the internet.  Another example would be a Send Connector that has a larger message size limit than the default one, permitting very large files to be sent to partners or customers.

Send Connectors can be configured with authentication requirements when sending to a smart host, but when sending via DNS lookup have no authentication options to configure.  However, Exchange Server will honour the receiving server’s security or authentication requirements (such as TLS encryption) where possible.

Continue reading Understanding Exchange Server Connectors

Exchange Server 2010 has similar capabilities to Exchange Server 2007 when it comes to adding disclaimers to emails sent by end users.

However two improvements have been made in Exchange Server 2010 – the ability to use HTML to format the text, and the ability to insert Active Directory attributes into the text.

These new capabilities make it very easy to add a standardised email signature and disclaimer to all emails sent in the organization.

For this to work the desired Active Directory attributes need to be populated on the user account objects.  Attributes that would commonly be used in email signatures include the person’s name, job title, phone number, and street address.

You can view and edit these attributes in the properties of the mailbox or user account.

When the user accounts are populated with the necessary attributes you can proceed with the creation of the Transport Rule that will add the signature and disclaimer. Continue reading How to Add Automatic Email Signatures and Disclaimers with Exchange 2010

Microsoft Exchange Server 2010 is now available but some businesses will be wondering whether the upgrade is worth it.  Many of the new features of Exchange 2010 can only be used with Outlook 2010, which is several months away from being released.

So if the new features can’t be used, should businesses wait to deploy Exchange 2010?  The new features of Exchange 2010 can be broken down into two categories.

Back-End Exchange 2010 Features

A lot of the attractive new features of Exchange 2010 are in the back-end.  This means that the features or improvements are server-side as opposed to client-side, and can be taken advantage of immediately.

These features include better high availability features to improve the reliability and resilience of the Exchange environment, and database performance improvements that lower the storage costs of deploying Exchange 2010.

A business can immediately take advantage of these features by deploying Exchange 2010 in their organization.  However they should also consider any reasons not to deploy Exchange 2010, and instead may consider deploying Exchange 2007 instead, or staying on Exchange 2007 if they are already there.

The reason for not moving to Exchange 2010 will mostly come down to the compatibility of third party integrated products, such as enterprise mobile messaging, backup, archiving, and email security.  Not all vendors for these products have updated their software to be compatible, and so if those systems are critical to the business then an Exchange 2010 deployment may not be appropriate.

Exchange 2010 also removed some legacy application programming interfaces in favour of the new Exchange Web Services that was introduced with Exchange 2007.  Again if a business has legacy Exchange-integrated applications that rely on those interfaces then an upgrade would be unwise until the legacy apps are themselves upgraded or replaced.

Client-Side Exchange 2010 Features

For all the back-end improvements it is the front-end, or the Outlook client by wich most people will judge Exchange server.

Although Exchange 2010 has many new client-side features such as Mail Tips, archiving, and the Exchange Control Panel for self-service administration, these are mostly only available when the end user has Outlook 2010.

Not being able to take immediate advantage of new client-side features may undermine the business case to move to Exchange 2010.   However if an Exchange upgrade must be performed (eg, the version the business is currently on is 2003 or earlier, which are either already unsupported or about to become unsupported) then it makes sense to consider the latest available version. Continue reading Exchange 2010 Worth It Without Office?