Sustainable email sending programs in an inherently hostile environment now require great care and planning. Before considering the technical complexities and the marketing tactics, email senders must adopt a basic paradigm shift.
The five guidelines included in this series should become watchwords for ezine emailers as they incur the risk and responsibility of sending newsletters or any other repetitive type of email.
Part 1 of 5: Treat Email as a True Risk and Cost Center
Part 2 of 5: Avoid Collateral Damage
Part 3 of 5: Use the Available (Legitimate) Tools and Tactics (M2M)
Part 4 of 5: Build Strong Relationships (H2H)
Part 5 of 5: Continuously Evaluate
Part 2 of 5
Avoid Collateral Damage
by separating and isolating sending streams
"Collateral Damage" is a term that originally meant the blacklisting of non-Spamming IP addresses. Now it is widely used to generally refer to the losses caused by incorrect blocking or filtering of legitimate email (e. g. False Positives), either accidentally or intentionally, as well as the access and operational damage caused by complaints.
Here is the root of the problem:
Email senders can no longer simply rely on “the system" to take care of their continuing critical interests. Anti-Spam programs are imprecise, and abuse administrators and blacklist operators can be recalcitrant. Some organizations actively block non-Spamming email senders as a pressure tactic, while others are quite simply inept; running misconfigured filters or unreviewed blacklists.
Complaints against your mailings, whatever the source, are automatically taken as serious grounds for action by your own ISP, not to mention the recipient ISP, despite the fact that you may send only confirmed permission-based email. Minor or even accidental actions by a very small percentage of your recipient population from one type of email send can cause a general shut down of all your email or even Internet access. And the diversity of barriers and potential blow-back points where this can be generated along the transmission chains for lists having thousands of addresses, is simply mind-boggling. Even the most careful organization with exposure to the email sending space can end up being blocked by a major ISP or by a diffuse population of networks using a blacklist. What can you do in this situation?
Segmentation and isolation
One basic response to this new risk is to segment and distribute email sending channels as much as possible, so that a catastrophic failure in one element does not cause a problem with others. This basic business approach has long been used in fields as diverse as brand management and administrative controls. Now it needs to be applied to your email sending programs.
There are at least four layers of segmentation should be included in this strategy, based upon the major information points anti-Spam systems use to identify email:
1) Source ISP and sending IP address:
The oldest and most widely practiced form of transmission blocking is by IP address. It simply means that no traffic will accepted from that address (your are just unplugged). There are significant technical reasons why this is the easiest and therefore the most commonly used blocking method, and it is the core method of the vast majority of Blacklist and community blocking schemes.
A distributed population of IP addresses for sending different types of email can help assure that blocking in one area (for example a marketing channel) does not shut down another (for example confirmations of purchases). Likewise, problems with one product line or brand can be kept from spilling over into others. Because of the potential impact of intentional collateral damage techniques, having IP addresses in different class-C bocks, and even at different service providers for each channel is the safest approach.
Moving even further into risk management planning, it is advisable to have back-up or reserve IP addresses for each segmented sending channel, similarly distributed, that can be rolled into operation in case a substantial block appears. Additionally, it makes a lot of sense to consider using multiple IP addresses simultaneously for single large channels to allow for load balancing and sending signature reduction.
While extremely effective in mitigating the risks of email blocking, the natural difficulty with this approach is that it quickly becomes burdensome to implement and manage. Several newer MTA packages offer at least some support for implementing this type of segmented or distributed architecture.
See the Email PhD “Top MTAs " section for more information on this topic.
2) Domain Names – URL blocking:
One of the primary blocking tactics at some major ISPs right now is the URL-based rejection. This system works by recognizing a particular domain name as having an unacceptable level of complaints, and any message containing that URL is rejected. The URL may be in the “From", “Respond To”, or other header field, or it may be a click though URL within the body of the message. The target URL can even be the hosting address for images contained in the message.
Server name level variations of the domain name (for example, info. emailphd.com instead of www.emailphd.com) typically do not affect the URL block. However, variations of a domain name (for example, emailphd.com, emailphd1.com, or emailphd-info.com) are usually seen as completely different by these systems. Thus, it is quite possible to set different domains for each sending channel, each of which may be clearly recognizable by recipients as belonging to your company, and which will not be automatically shut out in case of a problem with a different channel.
Controlling the domain names for centralized or frequently used functions, such as click tracking and image calling, can be treated in the same way, but the administration problems can be tricky unless the architecture for reintegrating the data generated is designed into the system architecture.
3) Trans-channel and repetitive content markers:
A less obvious (but important) risk for blocking or filtering (even across properly segmented channels) is the accidental use of common message elements. After going to all the trouble of assigning specific IP addresses to particular channels, and giving different URLs to different products and message types, and managing their click through and hosting environments, some companies then place a common element or text right back across their entire message space that may incorrectly be used to block all email that contains it.
Examples of this oversight might include using a single “approved” logo or image, or a compliance element such as a text or image version of the required physical postal address with a single file name and location on all company email. It might include a standard header or footer that by policy appears on all company email, or a common disclaimer used throughout your company.
If an element is associated with a blocked or filtered email, and it is also found on other types of email, the door has been left open for this type of collateral damage. If the ISP decides to block any message containing that element, or to class all email that has that element as the same, your segmentation strategy may be abrogated.
4) Bad content filtering is another cause of collateral damage:
Although less prevalent today at the major ISPs, large stretches of the recipient world still rely on basic word or phrase filtering. These programs search for words and phrases that are typical of Spam and assign each incoming e-mail a “score. " If your e-mail has too many of these words and phrases, you receive a high score, and your message may be blocked.
Many boxed software packages for client-side use, and smaller or custom systems for local and corporate networks, have a wide installed base. They will likely be with us into the foreseeable future. Many administrators and users of these systems are certainly smart enough to understand that every email containing the word “free” is not likely to be Spam; but they are willing to accept the False Positives they know they are generating as collateral damage.
If addresses at smaller networks are an important component of your list, it is advisable to begin a filter testing program to guide your choices of message text and format. The easiest first step in this process is to download and set up SpamAssassin the well known open source anti-Spam filter. You can use this as an experimental platform for testing your content. It is surprising how many commercial products (both boxed and service) are really just reworked versions of this program.
You can also add several of the “name” packages to your experiments (such as Norton/Symantec or McAfee to broaden your view of how these types of filters view your messages. There are also a number of “Words that Kill” lists available online, although this is an area where the information appears to be somewhat dated and largely antidotal. For example, see:
- 20 Words That Kill - At Least When It Comes to Spam Filters
- Words and Phrases that Trigger Some Spam Filters
See the Email PhD “Sending Obstacles " section for more information on this topic.
While these steps are essentially defensive, and cannot in themselves assure total sending continuity to all recipients, they do remove one of the biggest, and frankly scariest threats to companies sending diverse types of email. Catastrophic shut downs can be prevented using this approach, and different email streams can operate without inheriting delivery problems from each other. The larger the number of different sending streams within a company the more important these basic protections are.
Copyright © by Email Ph.D. All Right Reserved.
Tim Starzl is the chief editor of Email Ph. D. , an informational Web site dedicated to improving email delivery for all permission-based senders. With years of experience in email sending system design, high volume sending, and high precision tracking systems Mr. Starzl provides practical working advice for a difficult and rapidly changing environment.