As you are probably aware, Sendmail is heavily involved with DKIM (DomainKeys Identified Mail), one of the leading methods of Sender Authentication.  Under DKIM, mail messages are signed using the company’s private key as they are sent.  The receiving party looks up the company’s public key in DNS and verifies the signature.  This not only prevents forgery but also prevents message tampering.

However, simply verifying a signature is not enough as nothing prevents an evil person from signing all of their mail for a domain they control.  Users can’t use a successful signature verification as an indication of message quality.  The next step is to tie that verified sender domain to a reputation to determine how to treat that message.  While it is true that you don’t need reputation to prevent forgery, reputation does help the receiver not mistake mail from send-mail.com as being from the reputable Sendmail, Inc.

You may be asking why DKIM verification plus IP reputation isn’t enough.  Given the mail industry consolidation, the sending host’s IP is becoming less and less useful for reputation.  If it weren’t already registered, I could have send-mail.com registered in about 20 minutes.  Next, I sign up for Google’s free service, Google Apps for Your Domain.  Then I send my mail through Google’s SMTP server.  The mail message will come from a Google IP address.  How does the IP reputation for Google’s mail server relate to mail from send-mail.com?  Clearly it does not.  Even completely outside of DKIM, IP reputation is going to become less and less useful for anything but bot blocking.  You can’t judge a sender based on the machine that sent the mail.  You need to judge based on the quality of the sender’s organization which is only related to their domain.

With DKIM preventing forgeries, domain-based reputation can provide an accurate representation of the quality of the sender and therefore the quality of the content (outside of ISP domains).  IP reputation still has a place but it will transition more and more into an IP blacklist (e.g., IP addresses that shouldn’t be originating mail).  It is my belief that we won’t see widespread DKIM adoption until there is an open and collaborative domain-based sender reputation system.  The first step has been taken with domain-based accreditation (”good” sender list).  Hopefully, in time, that will evolve into a full reputation system.

It should come as no surprise that I hate spam as much as the next guy. I run my own FreeBSD-based mail server for my personal mail and despite my best attempts, more and more unwanted mail gets by my filters (SpamAssassin, GreetPause, personal block lists, etc). It has been tempting as of late to start using DNS based block lists such as SORBS, Spamhaus, SpamCop, etc. but I keep falling back to not wanting to let others decide who can send me mail and who can’t.

This fear is not based solely on paranoia. The Sendmail, Inc. mail servers have been blocked multiple times by SpamCop (ironically, SpamCop is owned by a competitor). Obviously Sendmail is not a spammer. Both times, they had blocked Sendmail due to auto-responders which sent a single message to one of their traps. Clearly, someone forged mail to our `jobs’ address from one of these traps. Auto-responders that let a job applicant know their resume has been received are not the problem, spam is, yet we were penalized. It is this type of draconian thinking (and the amazingly difficult process of getting off a block list) that has me shying away from using them. In my mind, this is throwing the baby away with the bath water, it is not solving the spam problem.

I do applaud some of the other block list sources which have started to categorize the listings as that provides me with an opportunity to decide which lists I want to participate in. For example, SORBS provides a variety of different lists for different purposes. This was tempting until I read how to get delisted. Once again, too many innocent organizations can be caught up in their nets simply for having IP addresses “near” bad sites or using a colocation facility that has had bad customers in the past. These innocent bystanders have no real recourse (except in some cases to pay to be delisted). Once again, how does punishing the innocent solve the spam problem?

All in all, whether by quality or practices, I haven’t found a block list that I could trust to control who can contact me. Feel free to add a comment to this post if I am overlooking the perfect DNS block list.

Instead, I look forward to a day when domain-based sender authentication (e.g., DKIM) is widely deployed and there is an open and collaborative domain-based sender reputation system which can be used by each individual site to decide who to accept mail from. Unfortunately, neither is in place yet. DKIM is only starting to get deployed and most of the industry is still stuck on IP address reputation. I’ll discuss why domain-based reputation is needed in my next post.

For the two decades that I have worked in email security as an IT analyst, System Administrator, Solutions Consultant, and Sales Engineer I always felt like I was fighting a losing battle. Email security issues were only addressed after they negatively impacted an organization. Why wouldn’t an organization want to spend money proactively on a solution instead of wasting money fighting fires after the problems have already occurred? It’s always been a problem of action and reaction rather than plan ahead and implement. I really shouldn’t be complaining because all these security issues have kept me gainfully employed for many years, but complain I must. I wanted to rant because there are so many common sense things that can be done to improve email deployments that are simply not being implemented into best practices.

If a company were to deploy reputation filtering it could eliminate 80-90% of all inbound traffic at the connection level with no false positives. Why would any gateway accept email from known spamming networks in the first place? Most gateways could deny all email from DHCP addresses if they had the IP ranges available. ISPs could block all outbound port 25 traffic from dynamic clients if they chose to do so. Many ISPs have already done this to prevent botnet attacks from being initiated from their networks. Rather than putting the responsibility on the receiving gateways we should push outbound spam blocking back to the ISPs and to the countries that are responsible for sending the spam in the first place.

If the spam networks could be disabled, then ISPs would be held accountable. Assuming only 10-20% of the email volume remains after reputation filtering, why then do email gateways scan email from people that don’t exist. It’s because no directory integration has ever been installed to drop email to illegitimate recipients. Some of the largest companies in the world are getting hundreds of millions of inbound email daily. They complain about spam and performance, but do nothing about it. The problem is simple enough to solve yet companies dare not integrate with a directory service because they may lack the directory expertise to unify their email addresses and aliases under a common meta-directory. Some employees use twenty different email nicknames (aliases) and their employers don’t want to mandate only 1-2 primary email addresses for fear of a missed email. I have seen many companies unify their email address schemes before and all it took was a top down executive decision to simplify their email addresses. Within a few months every employee was using their new email address with only a few legacy addresses left for backwards compatibility with email applications that may already be in place.

Data Leak Prevention (DLP) is the latest issue getting all the attention. Companies are setting aside tremendous amounts of money to setup entirely new infrastructures. This also requires training and a dedicated staff for the sole purpose of preventing sensitive data from leaking out of an organization. If I have learned one thing over the years it is to realize that DLP technology is just another application that will become part of the core messaging infrastructure. All the money in the world doesn’t stop someone from maliciously taking data, losing a laptop, sending data from their home networks, and infecting their PCs with malicious spyware and key loggers.

I remember a time when computer viruses were one of the top reasons for downtime and data loss. One simple email with a tiny executable attachment and entire networks were brought down in the blink of an eye. Companies responded to these virus threats by deploying antivirus software on their servers and desktops. This response created a new issue; email administrators realized that virus scanning software was putting a heavy burden on their servers. As the email volume continued to rise, servers became slower and slower. Soon thereafter the first standalone antivirus email gateway appliance was born. Gateway based appliances solved many different problems as viruses, spam, phishing and other malicious attacks were removed at the network edge. In parallel, outbound appliances that offered solutions for archiving, encryption, and web filtering were added to the mix. Over time most of these independent solutions merged into multi-purpose bi-directional appliances used for everything from inbound threats to outbound compliance. With all these apparent solutions, why then are there still problems? Answer the following questions about your messaging architecture:

1. Are inbound connections managed with reputation services? If not, why are you allowing spammers to continually saturate your email gateways with absurd amounts of spam?
2. Can recipient checks be performed against directories? If so, what vulnerabilities or limitations were created when this feature was implemented?
3. Was inbound/outbound scalability and geographical redundancy part of the initial design? If not, are you prepared for long term growth and network failures?
4. Has an email assessment been performed? If so, were the recommendations followed?

Even when the correct solutions are deployed, many times important features are not being leveraged or properly configured. Answer the following questions about your existing solution(s):

1. Are you meeting regulatory compliance guidelines with regard to logging, auditing, reporting, encryption, signing, and archival requirements? Are you liable or personally responsible if sensitive data is leaked through email?
2. Is your organization doing any mass mailing? If so, is outbound email signed using DomainKeys Identified Mail (DKIM)? How do you manage legitimate NDRs and backscatter?
3. Can you verify that an external recipient has received their email? Are there any legal requirements that mandate message tracking?
4. Since most information enters and exits via email, is data leakage prevention (DLP) technology integrated into your email solution? If so, does this require a completely separate infrastructure and what is the plan for long term maintenance?
5. How do your instant messaging, web proxy, and email solutions work in unison to stop data leakage? Do your appliances support the
   Internet Content Adaptation Protocol (ICAP)? How much extra manpower is required to maintain separate products?

Have you ever called technical support and found out that your maintenance has expired? Don’t forget that the technology needs to be kept up to date to be able to combat threats. When maintenance expires, chances are the updates stop too. Keep your software up to date with the latest release and certainly don’t blame the vendor if your software is several versions out of date and you experience problems. The power of a solution is only as good as the people and practices that are put into the deployment. Don’t deploy something halfway because it’s good enough for now; take the time to engage the experts in email security and do it right the first time.

I used to think that people who talked about “spending money to save money” were just joking about justifying their latest shopping spree on items acquired as part of an impulse buy. But as I have traveled around the world visiting our customers, it’s become very clear that the higher up in the organization a person sits, the more attention is paid to how money is being spent to gain a pay-back. C-level executives want to know how the money is being spent from their budgets to gain return-on-investment (ROI) and to maximize and prioritize their IT/Security budgets. Executives are not afraid to spend money now to save money in the long run. In fact, if there is going to be a strong or high payback, they want to spend the money as fast as possible to realize the economic returns ASAP.

I’ve noticed that during difficult economic times, too often the lower- level positions in an organization translate corporate belt tightening initiatives from the top as times of “no spending” or “no budget.” This is often an incorrect interpretation and it can be misleading. The directive from above may instead be about asking the organization to review how existing budget money is being spent today compared to other ways it may be allocated to gain a greater ROI. It’s not the time to stop spending, it’s the time to reassess where and how the money is being spent!

At Sendmail, we’ve witnessed larger sales transactions during these times because it appears the customer’s organization is on “high alert” on all levels to look for ways to save money over time. Often there is a direct link between the long term strategic business objectives of an organization and the savings resulting from a 3-year lower total-cost-of-ownership from major infrastructure investments made today. For example, if a messaging infrastructure can be modernized by moving from software maintained on multiple layers of aging hardware servers to “virtual” appliances based upon VMWare, not only may machine processing layers be reduced, but the entire upgraded architecture would pay for itself from the dramatic reduction of maintenance/support costs of software, hardware, and administrative overhead. Instead of saying “there is no money available,” the organization should be aware they may be already incurring the software, hardware, and administrative costs in its support budget. The existing budget could be simply reallocated to cover the upfront costs of modernizing the messaging infrastructure today, moving from outdated hardware to high performance appliances which increase productivity immediately. By doing so, the department could gain alignment with the long term strategic business plan calling for greater security or compliance flexibility, while paying for itself through savings over the three-year period.

I’ve yet to find a large enterprise where substantial savings like this could not be found after Sendmail is able to conduct a messaging assessment and architectural review at the customer site by one of our email security architects. The bottom line is a customer can spend money to save money, and the money can usually be easily found by looking closely at existing budgets! Messaging volumes will continue to rise exponentially in the future. Infrastructures will be stretched and stressed if not refreshed with the latest technology advances. Modernization not only makes good business sense, there is also a high payback on something all customers cannot live without. I am interested to learn more from others on how such infrastructure investments yield these savings.