Scott Galvin, VP, Support Services

Email, for many of us, is a critical component of our day-to-day jobs. As its popularity as a communications and business tool has grown, so has our exposure to the risks inherent to the email process as a whole. Most email users have learned to use popular forms of email such as Microsoft Outlook or Hotmail simply by pointing and clicking their way through sending and receiving electronic mail. Few people have received the “basics” on how email works and how to use the available tools to mitigate exposure. As part of our effort to communicate with you and your staff, Safe Systems, Inc. is running a series about email to demystify the process and help our clients avert problems which may arise through the use of email.

How E-mail Works

Let’s start off with an email leaving your PC and showing up on the recipient’s PC. There are two main types of email client software businesses use. The first and most popular is Microsoft Outlook. After you install this client, you have to configure it with a network path to get to the mail server. You use a user name and password that exists on the mail server in order for it to authenticate or create a connection deemed appropriate for sharing information. Now the client is configured to Send/Receive data to the mail server.

The second type of client is the web-based client such as Outlook Web Access or MDaemon’s World Client. The web-based client is a nice option because it does not require configuration and can often be used remotely. The downside of using a web-based client is that often the functionality is limited when compared to software-based clients such as Microsoft Outlook. Basically, the web-based client can be described as a pathway directly into the mail server. Therefore, none of the data passed has to be transferred between client and server.

Verification of E-mail

Now that we have covered the email clients, we can move on to what happens once the server has the data in the email. The mail server will look at the email and decide whether the domain name matches one that is controlled by the server (i.e., your bank’s domain) or whether it needs to be passed on to the Internet. If the domain matches one controlled by the mail server it will simply distribute the message to the appropriate mailbox and eventually the message will be pushed down to the mail client to be viewed by the end user.

If it has to go out to the Internet, however, things become a little more interesting. Once the mail server determines that a piece of mail is bound for a destination across the Internet, it does a Mail Exchange (MX) record lookup in order to figure out exactly where the email needs to go. A mail exchange record is simply a Domain Name Server (DNS) record that exists on DNS servers on the Internet strictly to route email. If the MX record for your company’s mail server were to disappear, other mail servers would not know where to find you, and your organization would stop receiving email. Once the MX query is run and the foreign domain is resolved down to the public IP address of the remote organization’s mail server, an attempt is made to contact that foreign server. The diagram below graphically depicts the routing of email in sequential order.

Why all the detail?

Once a connection between servers is established, a series of protocol driven handshakes, anti-SPAM checks and data transactions take place. SPAM is the component of this process that is impacting the productivity of many companies, including financial institutions, today. There are numerous technologies to fight SPAM and new ones coming out all the time. It is difficult to comprehensively cover anti-SPAM techniques and ensure that all tools are covered, but I will describe a couple of the most common technologies in use today.

Realtime Blackhole Lists

The first and most common check that email servers will employ is to check the sender’s IP address against a series of databases of known unsecured mail servers called Realtime Blackhole Lists (RBLs). These RBLs are separately owned and maintained entities that exist on the Internet. Each RBL can use a different criteria and each one has a different method of removal from your mail server’s IP address in the case that it is classified as an open relay or unsecured mail server. Some even go as far as to charge you money to get your public IP address removed. These sites are generally not used and should be ignored.

The mail server will examine the source IP of the email and compare it against the lists of IP addresses contained in the RBLs. If it finds that the source IP matches a listed IP, it classifies the mail as SPAM and will take one of the actions described later.

Heuristic Scoring System

The other method I would like to discuss is called the heuristic scoring system. This is a more dynamic anti-SPAM solution that can be controlled more closely by the System Administrator. This system evaluates an email on several criteria such as how many recipients the email was sent to or how much of the email is formatted in HTML (this would indicate that it was a marketing email and not just regular correspondence). As it runs through this checklist, it tallies the point total by the assigned value for every “positive” it finds.

The Administrator then is able to set a point cutoff that states if the email scores higher than “x” points, classify it as SPAM. The Administrator can also reassign the point values of the different criteria. Both of these adjustments can be important in reducing your false positives (regular, valid email classified as SPAM). If the sender’s IP address is listed on an RBL that the server is set to reference or is assigned a high score on the heuristic scoring criteria, one of multiple actions can take place: the mail can be rejected, quarantined, diverted into a SPAM folder, or it can even be delivered into the user’s mailbox with a simple SPAM tag applied.

Once the servers sign off of the connection, assuming the transaction was successful, the email message now resides on the remote mail server. It is then up to the remote mail server to route the message to the appropriate mailbox for the correct domain that it controls. The message should then in turn be pushed down to the designated mail client for the recipient to view.

Conclusion

Our client financial institutions should be utilizing the tools available to them to control their email transmissions in and out of the bank. Implementing the proper controls and monitoring procedures on the bank’s email transmissions will substantially decrease the risk of virulent email entering the financial institution and wreaking havoc on the bank’s network infrastructure.

Write a Comment