Our News

FST Key to Hot FBI Cyber-Terror Issue

Comments by FBI Cyber Crimes Assistant Director Shawn Henry made last October to reporters centered on a noticeable rise in cyber-terrorism and specifically cited "spear phishing" as a rapidly rising threat.

ISR's Forensic Sender Test™ helps UCE control systems combat all types of email identity crimes. Providing FST service in your mail system component or service not only brings tremendous value to your customers, but also affords an opportunity to show initiative on a “hot button” issue.

Contact us to learn more.

Use Cases

There are four basic use cases for the Forensic Sender Test™ in a mail system. Each of these cases focuses on a particular exploitation of the sender identity security hole in the Internet mail system and can be built upon to satisfy various specific needs. We've provided fairly detailed examples of FST integration for each.

Identity Theft Thwart


There are two basic ways to combat the Internet's share of the $9 billion/year identity theft problem. The first is to try to preempt a would-be victim's visit to the identity thief's fake website by connecting their web browser to a central database of known phishing sites. The second is to try to stop the identity thief from presenting their fake website to the would-be victim via email.

Phishing emails are made possible by the criminal's ability to send mail as if they were a known associate, usually a financial institution, of the recipient. With the FST evaluating all of the possible sender addresses in an email against the IP address of the sending computer, this ability goes away. There are five sources of sender addresses: MAIL FROM (RFC 5321), Return-Path (RFC 5321/5322), From (RFC 5322), Sender (RFC 5322), and Reply-To (RFC 5322). According to the RFCs some of these can contain multiple addresses. The FST has the ability to test a virtually unlimited number of alleged sender addresses in a single request. Each of these addresses is compared to a list of known phishing targets. If any address presented fails, a special flag for "identity theft attempt" is returned in the response.

In fact, what has happened goes one step deeper. The criminal has actually tipped his hand because we now know the address of his phishing site. The real implication of this is the ability for the first time to use automated systems to collect the addresses of phishing sites with 100% accuracy. Not only did the FST stop the intended victim from being lured, but the filtering system has the option of publishing the newly discovered phishing URL as part of a global discovery and collection system for use by web browsers as discussed above.

Working Example

In order to protect against phishing attempts, the FST request must contain elements from the header section of the message. We will assume in this example that the entire message was fully received by the SMTP server and saved off to a queue for evaluation by a post-processor of some sort, but this is not the only way to proceed. A mail proxy can call the FST during the receipt of the SMTP DATA to decide whether or not to issue a failure code at the end of the DATA command. If the proxy simply checks the MAIL FROM against the connected IP (the worm protection model), the vast majority of phishing attempts will be rejected even before the DATA has begun.

Our post-processor sees the following header:

Received: from host205.eli.HHHE.fibrewired.on.ca at
    by mail.qostar.com at
    MailVICE MTA ID 05E081DD-AA8C-4902-98CB-C749EBC13CF6; 16 Sep 08 11:25:28 -0500
Return-Path: <manager#0031@bankofamerica.com>
MailFrom: <root@fibrewired.on.ca>
Helo: host205.eli.HHHE.fibrewired.on.ca
Date: Tue, 16 Sep 2008 13:38:13 +0000
Message-ID: <74747.ahmed@cheng>
From: "Bank Of America Tech Support" <manager#0031@bankofamerica.com>
To: <mark@unsuspecting.net>
Subject: Bank of America upgrade warning.
MIME-Version: 1.0
Content-Type: multipart/alternative;

It extracts the IP address as and the alleged sender addresses as root@fibrewired.on.ca and manager#0031@bankofamerica.com and sends them to the FST for investigation via the HTTP API. The FST sees that root@fibrewired.on.ca is perfectly normal for, but it is certainly NOT normal for manager#0031@bankofamerica.com. Furthermore, bankofamerica.com is a known phishing target so the resulting response includes the special "identity theft attempt" flag.

Our theoretical post-processor, then proceeds to scan the message body and finds the following URL (which is not clickable here and hopefully inactive by the time you read this page):


This URL is reported to a centralized database which makes it instantly available to web browsers world-wide. Since the useful life span of the message ends with warning the rest of the world, the post-processor deletes the message rather than pass it along to the end user.

Case Studies

Real examples of identity theft attempts (like the one above) are easy to come by. Two very popular targets are Citibank and Bank of America. You can see samples of the FSTs results in real phishing emails targeting Citibank and real phishing emails targeting Bank of America.

Worm Killer


There are several devastating exploits in current use against SMTP servers that can be stopped or hampered at the very beginning of the SMTP transaction if the MAIL FROM address is checked by the FST. These include but are not limited to:

  • Generic spam worms - infected computers that blindly send spam
  • Their more sophisticated successors "bot nets" - networks of infected computers under the control of a central criminal who rents time on his network to spammers
  • Address harvesters - programs that discover valid email addresses by bulk trial and error
  • "Back-scatter" attacks - the use of a bounce message to relay spam to users who didn't send the original message
  • Distributed denial of service - the use of several computers, usually a bot net, to overload a mail server with some malicious intention other than mail delivery

For about 95% of connections from any of the above, which in many mail systems is 95% of the total mail volume, the MAIL FROM will have nothing to do with the connected IP address and the FST will report it as a failure. The SMTP server can then return an error code in response to the MAIL FROM command in the SMTP transaction. This will often confuse the attacking software but at the very least will avoid wasting resources on the connection.

This method of front-side quality control is VASTLY superior to "greylisting" which disrupts legitimate mail flow as if it were malicious.

An opinion: In modern usage, the blank MAIL FROM specified in the RFCs overwhelmingly represents mail system abuse rather than an actual bounce and should be treated as an automatic denial despite the incessant chatter about the matter among RFC purists. Very few systems, so few that even finding current statistics on the topic has proven impossible, lack the ability to issue RCPT TO errors for bad email addresses during the SMTP transaction leaving the empty MAIL FROM as nothing more than a useless security hole. If you know someone using Microsoft Exchange Server 2000 or any of the antique Unix mail transfers that actually need to send bounce messages, please encourage them to check the year on the nearest calendar.

Working Example

The outermost SMTP server in the local mail system, possibly a proxy appliance, receives a connection from and the following conversation takes place:

220 protectedbythefst.net ESMTP
HELO host205.eli.HHHE.fibrewired.on.ca
250 protectedbythefst.net
MAIL FROM: <manager#0031@bankofamerica.com>
550 You lack the authority. See http://protectedbythefst.net/mailabusepolicies.html
<server forcefully closed connection>

Upon receiving the MAIL FROM command, the server formed and issued an HTTP FST request. The FST found that had no association with bankofamerica.com and responded as such. The SMTP server simply issued a rejection and then closed the connection avoiding all the overhead of whatever was to follow.

It all sounds so simple that one might miss the fact that as much as 95% of the bandwidth, server load, administrative maintenance, and end user disruption was just removed from the mail system.

Email Spam Filter


Spam filtering was an administrator's nightmare in 2004 when we began live testing of the FST and it's done nothing but become a bigger problem since. One-time-use-on-the-fly-generated image and PDF spam are two of the biggest advents since that time and are still very elusive to spam filters (and disturbing if you're trying to receive an actual PDF or image with text on it). There are also new ways of sending spam with "backscatter" - using a bounce message from someone else's server to relay a spam message - topping the list of current public enemies. Bot nets have also come of age so to speak. But spam filters have vast amounts of processing power available now and will always be preferred by some users over identity filters because they require no extra steps to establish an association.

Even considering the incredible processing power of modern hardware, the complexity of the spam filter's algorithm is directly proportional to the vulnerability of the system to swarming attacks or simple volume overload. The logic is very simple: If it takes longer to decide whether a message is spam than it takes to receive a new message, then messages will have to be stored off in queues that will grow steadily until the volume slacks off. For instance, we know of a national provider of wholesale email hosting who suffered a 10 DAY bout of severe email lag because of this very problem.

The FST offers great hope for the designers and users of spam filtering systems in three areas. First, it can DRASTICALLY and safely lower the number of emails that must be evaluated by eliminating several types of malicious traffic without disrupting normal traffic. Second, the FST API's flag system affords the opportunity to tune algorithms based on several conditions to minimize hardware utilization and consequently increase throughput while at the same time increasing the accuracy of each logical branch of the algorithm. Finally, because of the FST’s ability to know the difference between an email from a domain’s real servers and an email from a malicious third party, a reciprocal of the IP reputation system can be created to track domain reputation.

Working Examples

Phishing Email

The first and perhaps most important scenario would be that the spam filter sends out an FST request and discovers that the email is an identity theft attempt. This represents a clear end to the determination process without even considering the content of the message or devoting any further resources.

No Reply Possibility

The FST API reports other useful attributes in making a spam determination in addition to the Forensic Sender Test result. Among these is the absence of a way to reply to the message. If no registered mail exchanger is specified in DNS, the API will try treating the domain as a hostname and checking to see if there is a listening SMTP server on the host. If neither is true, then there would be no way to reply to the message making the likelihood near 100% that it is spam.

Scoring Based on Valid Reverse

Most spam filters use scoring systems, either outwardly obvious or at the very least internally, to keep track of their decision making process. Various conditions will add or subtract points and the final score will be compared to some threshold that may itself be the product of a scoring system.

In addition to the FST result, the API also returns detailed information on the "valid reverse" for the tested IP. The IP may be missing reverse and that might be worth a few points, or it might have reverse but the forward lookup of the reverse result could fail to match the IP and that could be worth considerably more points. Or conversely, perhaps finding completely valid and matching reverse subtracts a few points. It is also possible for any of these conditions to cause branches in the logic of the algorithm as described above based on the observations of the filter's creators. Perhaps a more lax evaluation process is possible for things that have valid reverse or a special shortcut test will always spot spam when reverse is missing.

No matter how it is used, the API has now delivered information to the spam filter to include in its evaluation without creating any additional processing overhead. Since many spam filters already perform these same tests, they can be adjusted to save their resources for their core algorithms rather than creating the various DNS requests, managing the UDP sockets to converse with a DNS server, and then interpreting the resulting response packets while keeping track of and handling UDP timeouts.

FST Reports "Fail"

If the FST result is "fail" but the email is not a phishing target, the chances that the email is a real-person-to-real-person email are still very slim. If front-side measures are being taken to reject invalid MAIL FROM addresses, this means that one of the four other sources of sender information (Return-Path, Sender, From, Reply-To) doesn't match the IP that delivered the mail. Which of the four could be significant to deciding how to proceed with the evaluation. Again, this is another opportunity to create a branch in the algorithm where observations can be tuned to the particular statistical behaviors of spoofs versus non-spoofs.

FST Reports "Valid"

A rather exciting possibility of an FST result of "valid" is the opportunity for domain-based reputation systems. Many industry experts like Arvel Hathcock, founder and CEO of Alt-N Technologies, and Richi Jennings of Ferris Research, believe that domain reputation is the final frontier of spam filtering if they could just solve the sender authentication gap that exists with DKIM, SPF, and the like. (Their opinions where published in the June 2008 Messaging News in an article entitled "Bad Behavior and Today's Reputation Analysis")

If this dream of a global domain reputation system comes true, it ultimately represents another point of simplification for the spam filtering algorithm and another step closer to the perfectly accurate spam filter.

Email Identity Filter


When the Forensic Sender Test was conceived in 2004, it was not the primary objective of the project out of which it emerged. The real goal of that project was the elimination of a death spiral in our sister network's technical support department resulting from customer dissatisfaction with the performance of spam filters. Adjusted too tight and legitimate email was lost; adjusted too loose and spam flooded into inboxes. Perhaps worse, customers never knew what to expect from their email because of the constant oscillation. It seemed that the problem would never end.

The solution proposed to the problem was to stop filtering spam altogether and move to a "buddy list" system similar to instant messaging programs. If you know WHO is sending a message, then WHAT they are sending probably doesn't matter. For instance, if Uncle Paul wants to describe his brand new fake Rolex in great detail, this should not be a problem. Likewise, whether some unknown person is sending three random paragraphs of Moby Dick with an invitation to buy a fake Rolex embedded or a completely original testimony about how great a commercial weight loss package is, it is still just as much an unwanted intrusion by a total stranger. The battle cry in the spam war became "Who not what!"

The obvious problem at the time came primarily from e-greeting sites. These sites would record the email address of a greeting recipient alongside the address of the sender as a pair and then sell the pair at a premium. Some lists even included the names of the sender and recipient. The (correct) theory was that a recipient would be more likely to open an email from someone they knew. The Forensic Sender Test was created to solve this problem.

Ironically, the world didn’t need another spam filtering system and our identity-based project eventually became a high-powered statistical performance data collector for the FST. The various methods we employed are now freely available via white paper upon request.

Working Example

An email is received by the SMTP server and queued up for processing by a mail sorter. The mail sorter picks up the message and sends a request to the FST. If the FST reports that the sender is authentic, the sorter moves on to searching the recipient's "buddy list", otherwise the message is discarded. If the sender is on the list, the velvet rope is lifted and the email is moved into the recipient's inbox. If the sender is not known to the recipient, the message is saved in holding and reported to the user on a digest report that night. If the user sees someone they know on the list, they click a link to add the user to their buddy list and deliver their messages.

This is a VERY simple scenario that was chosen to give an overall idea of how identity filtering works.  Problems like "If both users have buddy lists, then how does either ever find out about the other?" are solved as well, and we welcome further discussion on ways we've leveraged the FST for these purposes.

The point to be made here is that the degree of processing involved is no more than making the FST API request and looking up the recipient in the recipient's buddy list. It doesn't matter if there are embedded images, attached PDFs, three plain text words, or 300k of HTML, getting the message through the system takes the exact same amount of work every time and it is very light. Overrunning an identity filtering system with an intentional mail swarm or random heavy volume period is much more difficult than a complex spam filtering system simply because of the difference in resource requirements between the two.

Beyond Theory

To see beyond the theoretical uses of the Forensic Sender Test, move on the the How It Works page where you can sample live data passing through our FST network.