Category list

Relay Security and Blocking Lists

As spamming techniques evolved to become more effective, various techniques have been developed to fight it. One popular technique is called Domain Name Service Blocking Lists (DNSBLs). This technique is sometimes referred to as Real-Time Blackhole Lists or Relay Blocking Lists (RBLs). These lists are used by administrators to report open relays and systems sending spam to a centralized repository holder. Keep in mind; RBLs do not just include e-mail systems as described above. In addition to open relays, there are RBLs for open proxies, Uniform Resource Indicators (URIs), and more.

Open proxies are becoming a larger part of the spammer arsenal; therefore, administrators must account for these RBLs as well (not just open relay lists). Organizations can subscribe to the RBLs and configure MTAs to reject any e-mail from a system listed in the RBLs. For those administrators whose networks end up listed on RBLs, the process to be removed can be difficult and tedious . First, the e-mail server must be secured so that it no longer allows open relaying. Second, the administrator must generally apply to be removed from the RBLs. Today, this is typically automated; however, this wasn't always the case and sometimes delays for removal were inevitable. Being part of an RBL meant subscribers to the RBL would not receive e-mail from your entire organization. As one can see, it is very important to successfully secure e-mail infrastructure to avoid these issues.

Uniform Resource Indicators or Universal Resource Indicators (URIs) are resource addresses generally used to identify resources found on the Internet, also known as Uniform Resource Locators (URLs). URI RBLs differ from other RBLs in the fact that a system is not included in these lists because it was found to relay. Systems (or IP addresses) found in URI RBLs are systems whose IP addresses are found within the message bodies of known spam messages. The goal of URI RBLs is to disassociate your organization with any systems known to participate willingly or inadvertently in the spam community. The systems included here do not necessarily have to send the spam; they just have to be identified somewhere throughout the spam process (that is, in hyperlinks included in the message body).

MTA E-mail Filtering

As previously mentioned, attackers have found e-mail to be one of the most successful mechanisms for successfully exploiting systems for several years . As an example, the Melissa virus was released in 1999. While the virus payload itself was not destructive, the efficiency with which it spread was enough to effectively create a denial-of-service attack on many large e-mail servers. To this day, e-mail remains one of the most effective means of malicious software distribution.

MTA administrators are forced to find ways of protecting e-mail infrastructure from attacks, abuse, and viruses like the example provided above. In order to successfully filter e-mail at the MTA level, various techniques are used. These techniques include SMTP authentication (combined with filtering), anti-virus filtering, and spam filtering.

SMTP Authentication

The explosion of broadband Internet access and the lack of security awareness in the home and small organizations have caused a large number of systems to become targets for compromise. These high-speed hosts have the ability to send enormous amounts of spam, participate in denial-of-service attacks, or attempt to propagate to other hosts with very high efficiency when compromised or infected with viruses.

Some ISPs and even private enterprises have begun filtering SMTP traffic and forcing their users to authenticate to "approved" outgoing e-mail servers in order to send e-mail. ISPs or enterprises may split incoming and outgoing MTA functions to ensure spammers cannot conduct DNS lookups to locate organizations' MTAs and send spam through them (as the MX points to the incoming server which is filtered). In this case, outgoing MTAs are not publicized by DNS MX records and often require SMTP authentication in order to send e-mail. These and similar techniques have been in use by many providers for several years (back to early dial-up providers). In today's IT world with the vast amount of remote work, traveling users, and home offices, most organizations' administrators have run into problems with some subset of their users not being able to send outgoing e-mail through the organization's MTAs remotely because ISPs are filtering SMTP traffic and only allowing it to pass through ISP MTAs requiring authentication. This is not a plan by the ISP to inconvenience administrators but rather part of the security posture to reduce spam from the ISP or enterprise network.

When filtering and SMTP authentication takes place, spammers find it more difficult to send spam out of an organization's network, but not impossible . Within an ISP network, SMTP traffic is customarily filtered as it attempts to egress the network when not sent through the "approved" outgoing MTA. So spammers have found methods (through viruses, worms, Trojans, and so on) to compromise hosts, obtain outgoing mail server settings (to include authentication), and subsequently send e-mail through the outgoing MTA as legitimate e-mail. ISPs and organizations have responded by using various anti-spam mechanisms to determine if messages from authenticated clients are legitimate messages or spam. Therefore, even if the compromised systems send e-mail (and authenticate) through the organization's outgoing MTAs, various early warning detection systems may be in place to identify and block these compromised systems. One example of such detection and blocking mechanisms is known as exponential backoff. This technology is an algorithm used to identify hosts sending higher volumes of e-mail than allowed by the MTA.

Anti-virus and Other MTA Filtering

Viruses can be one of the worst threats to an administrator. This is especially true for e-mail administrators. Not only is e-mail at risk but several (if not all) other technology systems within the local network adjacent to the mail server are at risk as well. For this reason, administrators must take anti-virus very seriously. Since the MTA is the public- facing infrastructure for an organization, it is also the organization's first line of defense against e-mail-born viruses.

Depending on the type of MTA in use, the anti-virus and virus filtering options will vary. Most will have some type of built-in capabilities for virus filtering such as the following:

Subject line filtering
Attachment stripping/filtering
Number of recipient limits
Auto- responder limits (to avoid denial-of-service attacks, including virus outbreaks)

In addition to built-in capabilities, most MTAs have third-party support for anti-virus vendors . This support comes in the form of plug-ins, add-ons, and additionally installed software. Anti-virus software can be configured per vendor instructions. These configuration options may include

Method of scanning (all messages, pre-defined messages, and so on)
Heuristics used during scanning
Instructions for handling infected messages
Notification methods (who should be notified when infected messages are found)
Type and frequency of updates (virus definitions as well as software patching)

These configuration options maximize the chances that infected messages are found at the MTA, or "public" level if you will, before making their way to the internal network.

The administrator must determine which mechanisms should be implemented. These decisions should be based on current MTA technology in use, budget for additional protection and scalability, and growth requirements. Generally , total cost of ownership (TCO) is a major factor if not the driving factor in what type of MTA is implemented (and what options are used) within any organization.

An important aspect when choosing an MTA is to choose a platform and MTA package dissimilar to the internal e-mail system/store. Diversity between the MTA and the internal e-mail store creates a much more difficult e-mail infrastructure to attack. Vulnerabilities on the MTA may not necessarily exist on the internal system and vice versa. This concept compounds attack difficulty when disparate operating systems are used as well. UNIX-type exploits certainly won't do an attacker any good on a Windows server running Microsoft Exchange or Lotus Domino, and Microsoft vulnerabilities are worthless against an MTA that runs on a flavor of UNIX.

Finally, using disparate anti-virus vendors on the MTA and the internal e-mail store greatly increases the chances of discovering and stopping viruses. Anti-virus vendors create virus definitions as they are alerted to the viruses. While the majority of anti-virus vendors have virus definitions within a matter of days, many viruses can spread within hours, or even minutes. By using disparate anti-virus vendors, an organization increases its chances of having virus definitions capable of stopping the most recent viruses. Additionally, if a virus or attacker is directed at a specific anti-virus platform, having disparate anti-virus vendors creates an additional layer of defense in e-mail security.

This suggestion can become expensive and very difficult to cost-justify, especially in environments where single vendors' implementations are encouraged. The intent of this suggestion is to expose the principle "disparity creates complexity" in an environment, also referred to as "security through obscurity." There is an increase in the complexity to manage and maintain an e-mail infrastructure that uses different vendors but that disparity creates a much more secure environment. To battle the increased costs and other disadvantages, solutions such as open source anti-virus use on MTAs (and commercial use on internal mail systems) should be analyzed .

One important factor to mention regarding MTAs and anti-virus is the use of Non-Delivery Notices (NDNs), also called Non-Delivery Receipts (NDRs). Today's miscreants are writing code that spoofs the sender's address on infected systems. Since hundreds (thousands) of messages are sent from these infected/compromised hosts, there are bound to be e-mail addresses that no longer exist. As a result, the legitimate e-mail user who has his or her e-mail address spoofed as the sender address on an infected/compromised host receives all the NDNs when a recipient does not exist. Viruses such as Klez and Sobig gave administrators severe headaches explaining to end users that they didn't actually send the message that caused the NDN.

Anti-virus configurations should never be enabled to send notification to the sender of a message that he or she sent an infected message. The accuracy of this configuration is very low and the NDNs actually become a form of spam as the user receiving the NDNs (often) did not send the message in the first place.

An additional security measure regarding NDNs is to never include the complete message. MTAs should only send enough information to identify the failed delivery message and the reason it failed. Since spoofed addresses are possible, the possibility of NDN attacks (purposefully spoofing addresses to cause multiple NDNs to be sent) increases. Adding complete messages (including attachments) allows less NDNs to be sent to effectively produce a denial-of-service attack. The moral of the story is simple: send NDNs per RFC 821 but do not send any more than required (that is, don't send anti-virus messages to senders of infected messages) and do not include any more in the required NDNs than necessary (to reduce bandwidth and denial-of-service concerns).

Spam Filtering Techniques

Just as viruses can spread through e-mail and clog up e-mail servers, UCE or spam can have the same effects. Users continuously complain about spam and management complains about productivity loss because of spam. On the other hand, if spam filtering becomes too stringent in an organization, both users and management will be sure to inform the administrator(s) that e-mail messages are lost. Organizations also find it difficult to control where "spammed" employees are being taken by links that lead them toward acquiring viruses, popping up web browsers with inappropriate (and potentially legally damaging ) content, and so on and so forth. To combat the spam problem, administrators must find the balance within an organization and determine how aggressive spam filtering techniques should be.

Blocking List Technologies

Even today, with the very public clash between administrators and spammers, many servers on the Internet remain vulnerable to abuse (unauthenticated relaying of e-mail), meaning they errantly "retransmit and distribute" the spam we all receive. One well-known system that was one of the first of its kind was the e-mail Abuse Prevention System (MAPS). MAPS was originally started by Paul Vixie, creator of BIND (DNS server software) and founder of the PAIX. MAPS administers an initiative called the Real-time Blackhole List (RBL) where known spam offenders (actually, the specific e-mail hosts they abuse in order to propagate spam) get added to an IP access control list, which is in turn "subscribed to" by Internet border routers and anti-spam software filters everywhere (enterprises, ISPs, and so on). While MAPS was ground-breaking in its day, several other blocking lists have since been developed, many of which are free of charge to use.

To further explain RBLs, when a spam goes out and early recipients complain to the managers of such RBLs (often an automated process), the perpetrator is almost immediately added to the RBL and many sites (companies, educational institutions, and ISPs that had intentionally subscribed to the RBL) are able to block the abusive host from performing e-mail transactions before the wave of spam is able to reach their MTA and subsequently their users. The vast majority of spammers will try to abuse the same e-mail systems on subsequent occasions (perhaps weeks later) and the RBL will preclude them from being successful in their following attempts. Blocked sites must go through an arduous process to protect themselves and their e-mail hosts from abuse, and prove to the various RBLs that they have taken steps to correct what had gone wrong. Once this is done, they are removed from the RBL and will again be able to ubiquitously send e-mail, assuming the RBL maintainer(s) approve their new operating plans.

As described earlier, there are many more RBLs available today in addition to the MAPS RBL initiative. Many of these blocking lists work very well and significantly reduce spam, while others are implemented with an all-too-aggressive approach to rid the world of spam completely. These latter RBLs are so rigid that administrators utilizing them often find themselves continuously receiving complaints of users not receiving e-mail because the RBL was "too rigid." An administrator's goal should be to find one or more RBLs that fit the organization's spam filtering policies. As previously mentioned, several RBLs are more than just open relay lists. The Composite Blocking List (CBL) known as http://cbl.abuseat.org includes many different systems, such as the detection of open relays, open proxies, infected systems using direct mail transmission, and so on. The CBL does not rely on reports from administrators to populate lists; rather, the lists are populated through data gathered automatically (spam traps, and so on). This type of RBL reduces the need for increased human reports to be more successful. Right Hand Side Blocking Lists (RHSBLs) allow MTAs to filter spam based on the entire domain and not just a system or IP address. Many RBL maintainers also maintain RHSBLs; however, there are organizations that solely provide RHSBLs as a means of combating spam. RBL technology (which includes RBLs, RHSBLs, and URI BLs) is in use by the vast majority of ISPs, educational institutions, and major corporations worldwide and does a good job of significantly reducing the transport of unsolicited e-mail. Also, URI BLs provide administrators with a list of systems or IP addresses that are found within the bodies of spam messages themselves. If a system is associated with spam messages, the system is added to URI BLs and systems subscribing to the URI BLs will not communicate with said systems.

The list below provides some suggestions for various DNSBLs and RBLs. However, an organization must determine the level it deems necessary to fight spam. Some of the examples below are aggressive in blocking and can cause day-to-day issues with e-mail delivery if not carefully maintained . Recommended sites for RBLs include

http://cbl.abuseat.org
http://list.dsbl.org
http://pss.spambusters.org.ar
http://opm.blitzed.org
http://relays.ordb.org
http://relays.visi.com
http://bl.spamcop.net
http://sbl.spamhaus.org
http://blackhole.securitysage.com
http://dsn.rfc-ignorant.org

For more comprehensive lists of RBLs, you may wish to visit http://www. dnsbl . info /dnsbllist.asp or http://www.sdsc.edu/~jeff/spam/cbc.html, both of which contain several more RBL listings than those above. With these lists (and others like them), you can decide which lists make the most sense for your organization.

While it's not necessary to use all of the RBLs listed above, you should use more than one to have a more comprehensive blocking list. The first (http://cbl.abuseat.org) is certainly a recommended option and a choice of one or two others should be sufficient for most organizations attempting to block spam through RBLs. For more information, please review the section "Relay Security and Blocking Lists," earlier in this chapter.

Collaborative Spam Identification Systems

But what happens when spam originates from an organization that is legitimately set up to send unsolicited e-mail? In this case, there is no compromised e-mail server to block (via most RBLs) as an incentive for its owners to secure it. While few of these businesses exist today (and while very little unsolicited e-mail is attributable to their ventures ), every indication suggests they may become a problem in the future. Additionally, MTAs that do not allow unauthenticated relaying but that have been attacked and subsequently compromised for the purpose of sending spam are also legitimate problems. The Spamhaus Blocking List (SBL) is a form of blocking list and includes many of these types of systems, but what if the SBL is not used by your organization? To combat these types of systems, new ideas were needed in the anti-spam fight.

Collaborative spam identification systems such as DCC (the Distributed Checksum Clearinghouse), Razor (Razor2), and Pyzor are all additional methods used for eradicating spam. These systems use statistics gathered from multiple systems available on the Internet to determine whether e-mail messages should be considered spam. For example, the DCC is a system that consists of more than 250 servers. These servers collect and calculate checksums on over 150 million e-mail messages per day. (The checksum used ignores various aspects of messages and is continuously modified to keep up with ever-changing spam messages/techniques.) These messages generally traverse one or more ISPs in their transits where DCC servers reside. DCC servers exchange or "flood" common checksums. The checksums consist of values that are constant even when a spam message is varied slightly (such as customizations to users). These checksum counts gathered by DCC servers are then used to assist in determining if a message is spam by comparing with other DCC servers. If deemed spam, SMTP servers utilizing DCC services reject or filter the message as unsolicited bulk e-mail. E-mail servers or MTAs utilizing DCC simply act as clients soliciting statistics from DCC servers. Therefore, the implementation of such techniques is similar to that of RBLs.

Each organization must decide independently how to handle each spam message. If any checksum exceeds limits set by the organization, the MTA (with the DCC client) can log, discard, or reject the message. Whitelists are used by the MTA similar to other anti-spam techniques to ensure solicited e-mail is delivered properly.

There is an increase in network bandwidth requirements when using the DCC; however, the communication between the DCC client (organization MTA) and the DCC server consists of a single pair of UDP/IP datagrams. The methodology used by the DCC is that the more messages it is exposed to (more DCC servers, more DCC clients), the more accurate the checksum counts and subsequently spam identification will be. While this increases bandwidth requirements, it certainly can be argued that the decrease in spam and UCE counters that increase with a larger decrease in bandwidth requirements (if e-mail is discarded or rejected).

As with other anti-spam methods, spammers have found ways to circumvent the checksum or fuzzy hash anti-spam methods. Spammers now often use "hash busting" information in spam messages. This information may include random words or random lines as a different data set in every spam message. This data is often randomly collected web data used purely as a camouflage technique attempting to hide the messages from these types of spam filtering technologies. Bayesian filtering is an algorithm using many of the same characteristics of checksum and fuzzy hash systems and also falls prey to randomized data included in the spam messages.

Whitelists and CRAM

Beyond RBLs and the DCC, some organizations harden their e-mail systems using whitelists as a means of protection. In a pure whitelist-based system, all e-mail except that which is explicitly flagged as acceptable is blocked. In many organizations, public exposure to the global e-mail system is limited and the extent of most participants ' usage can be summarized by a number of rules that accept e-mail from outside a corporate network. Anything outside of those rules will be turned away.

One method that builds upon the whitelist methodology is a Challenge-Response Authentication Mechanism (CRAM). In this type of system, a received message is queued by the MTA temporarily, often referred to as sidelining. The purpose for this inbound queuing is to check whitelists to determine whether the sender is authorized to send to the recipient. If the sender is authorized per the whitelists, the message is forwarded on to the sender. If not, the MTA holds the message in the queue and contacts the sender for verification. Various checks are performed (which generally are configured per the implementation), but may include

Option 1: Sending E-mail Domain Validation MTA checks for a real domain with DNS-listed MX records identifying mail servers that respond to SMTP. Once the MX lookup is completed for the sender domain, the MTA will connect to the MX to ensure it is a legitimate e-mail server.
Option 2: Validation Request to the Sender Sender must reply to validation request (normally via e-mail, but alternatively by clicking a URL and visiting a web site) to be added to the system whitelist and subsequently allowed to send e-mail to the intended recipient.
Option 3: Turing Test The sender must respond by answering a test that is difficult for a computer system to evaluate or answer correctly. This successful response indicates there is a human presence associated with the sender's "From" address in the original message in question. Turing tests generally use human senses for validation, such as typing a word/phrase that appears in an image or typing a phrase heard in an audio file. The CAPTCHA Project of Carnegie-Mellon is an example of Turing tests in action (http://www.captcha.net).

If the sender (or the sender's MTA) passes the preconfigured tests or responses to challenges, the message is removed from the queue and delivered to the recipient. Of course, once the user has been added to the whitelist (presumably automatically after passing the test(s)), he will not be required to go through the testing process again. If any of the challenges fail, the message is rejected, dropped, logged, and so on (all configurable in the MTA).

Some of the concerns with CRAM systems include the additional load on systems and network infrastructure to support the validations involved with challenging and responding. The additional traffic as well as the productivity loss involved with validating e-mail makes this type of technology less attractive. Instead of users contending with unsolicited e-mail, they are bogged down with validation requests , Turing tests, and other mechanisms for corroborating who they are and that in fact they should be allowed to send e-mail to the intended recipient. This is a similar problem as that caused by anti-virus systems that attempt to respond to the spoofed sender with an NDN-type notification. Because the sender of the original message was spoofed, the NDN notification just spammed the legitimate user (who was spoofed) unknowingly (the justification for turning off NDNs in anti-virus packages was discussed earlier). Option 1 listed above allows a simplistic form of challenge-response without the need for sender involvement creating a scalable option within the anti-spam fight. Options 2 and 3 require sender validation, which may not be viable in most organizations.

Option 3 (Turing tests) may also be limited in its usefulness because of recent efforts by spammers to defeat this type of test. The CAPTCHA-style validation is meant as a test requiring human interaction. As with many other anti-spam techniques, spammers are finding ways around this type of validation. There are software packages that are now able to defeat CAPTCHA-style validations (for some examples available at the time of writing, please see http://sam.zoy.org/projects/pwntcha). Other methods for defeating CAPTCHA-style and other Turing test challenges include posting Turing test response requests to alternative sites under the spammer's control. The unsuspecting user of the alternative site inadvertently inputs the Turing test response and passes the test for the spammer, unknowingly allowing the spammer to then continue on his spamming endeavors.

For example, spammers utilize automated processes to sign up for free e-mail account access, providing a means of gaining access to hundreds (even thousands) of legitimate e-mail accounts. When confronted with a CAPTCHA-style or other Turing test, the spammer simply redirects the test to another sign-up mechanism taking place on some other system within the spammer's control. Pornography web site sign-ups are a popular posting place for redirected CAPTCHAs and other Turing tests. Spammers that control web servers hosting pornography (which require sign-ups) have access to a large number of "in progress" sign-ups that can be used to process the redirected CAPTCHA (or other Turing) tests during the web sign-up process. The user at the pornography web site assumes the CAPTCHA test is part of the sign-up process, but in reality, this is redirected from the other CRAM-enabled system (that is, the free e-mail account sign-up discussed above). (For more information on defeating CAPTCHAs using methods similar to those outlined above, please see http://nilesh.org/weblog/2004/12/defeating-captchas/.)

As mentioned earlier, because of the increased network load, sender validations, and the bypass capabilities, option 3 (Turing tests) in CRAM systems should be analyzed very carefully before implementing to ensure there is legitimate benefit to your organization.

Whitelists, Blacklists , and Greylists

Where using whitelists exclusively provides an organization with a "deny all unless an allow exception is made" posture, blacklists can be used to block or reject only certain e-mail messages. This posture ("allow all by default, deny only those on the list") can be used to block single e-mail users, certain IP addresses or netblocks, or entire domains. If an organization is having spam problems only from certain entities, these entities can be added to blacklists.

Another technique that is growing in popularity is "greylisting." This technique works best when combined with whitelisting and is not suitable for large enterprises or ISPs, but is quite effective for single-user MTAs and for small organizations. Greylisting works by tracking tuples (a pre-set number of characteristics). These characteristics include

MTA IP address (from sender)
Envelope sender
Envelope recipient

If the connecting MTA IP address is on the whitelist or the sender has been seen before within a configured timeframe, the e-mail is allowed for delivery. If these criteria are not met, a "450 temporary failure" message is issued. Since most spammers only attempt to send a message once, this effectively blocks a large amount of spam.

Micropayment and "Stamps"

Another form of whitelisting includes the use of micropayments or stamps. An organization (or single user) could enforce micropayments for all e-mail being received. The general concept is if an e-mail recipient has to contend with unwanted e-mail messages, he or she should be compensated. In theory, the sender would "pay" the recipient to receive e-mail. E-mail that is solicited may be allowed a "free pass" and the sender would not be charged when sending to organizations using this technology. On the other hand, spammers will not find e-mail as efficient (or cheap) to send bulk spam because of the micropayment; therefore, the spam sent to the organization or user would be reduced. Some similar alternatives include various types of "stamps" included when e-mail is sent. If senders' e-mail holds cryptographic stamps, recipients can set rules to accept these messages exclusively. These stamps do not have to cost money; instead, they could have an indirectly associated cost (such as CPU time, as you will see in the example that follows ) giving the sender authenticity. The end goal of this type of technology is to have all legitimate e-mail users holding a stamp and MTAs accepting e-mail exclusively from all stampholders.

An example of this type of anti-spam is a technology called Hashcash. Hashcash runs as a plug-in on mailers or MTAs and for each message being sent, it inserts an additional header. This header stamp includes information about Hashcash and the associated recipient. The example below is displayed in the Hashcash FAQ located at: http://www.hashcash.org/faq/:

X-Hashcash: 0:030626:adam@cypherspace.org:6470e06d773e05a8

In order to produce this Hashcash header stamp, there is an associated CPU cost. For typical e-mail operation, this is generally unnoticeable; however, if a spammer attempts to send e-mail with hosts using Hashcash, the MTA output is significantly reduced (waiting for the CPU to generate cryptographic stamps). The theory is if spammers are slowed down enough, they will not target those systems for sending spam.

Throttling MTAs

A more recent method used for deterring spam from being sent to or accepted by an organization's MTAs is to slow down or " throttle " the MTA incoming message processing. In a day and age where performance is critical, the idea of slowing down the MTA processing seems counterintuitive; however, many spammers will not interact with a slow MTA as it decreases the amount of overall spam that can be sent. Since spammers thrive on volume, any slowdown in the process is subsequently avoided. This methodology affects all incoming messages for an organization, but if incoming spam is significantly reduced, the increase in MTA performance (because of now- unallocated resources previously used by spam) and increase in user productivity (not having to contend with inboxes filled with spam) create legitimate debate over the benefit outweighing the cost. Ecelerity is an MTA product developed and maintained by OmniTI that utilizes MTA throttling as a spam deterrent. While throttling sounds as if it may hurt MTA performance, the Ecelerity product is capable of very efficient message processing and transferring even in a large organization without significant delays.

Authenticated Sender Protocols

There are various technologies available today to provide information about who should be allowed to send e-mail for an entity, organization, or domain. Some of these include

Sender Policy Framework (SPF)
Sender ID (Caller ID for e-mail by Microsoft)
Domain Keys (by Yahoo!)

While each provides various techniques for determining what systems are allowed to send e-mail for an organization, details on SPF will be explained here to provide more information on this type of anti-spam technique.

SPF is a relatively new method to mitigate spam and third-party relaying. As mentioned earlier, MX records are configured in the DNS to advertise the systems that receive mail for a given domain. SPF works using "reverse MX" records, whereby the records indicate the systems (IP addresses) that are permitted to send mail from the domain. These are implemented in DNS as TXT records and are only queried/noticed by systems that support this anti-spam technology. Therefore, publishing them can only help. Given that spammers and relay abusers tend to forge the headers of e-mail to masquerade as another domain, SPF makes spamming much more difficult. If some portion of the SMTP headers is not forged or if a spammer has access to a legitimate account in a domain from which they send, SPF cannot stop the spam. Implementation of SPF consists of the following general steps:

Domain administrators must identify systems permitted to send mail for the domain. Next, DNS TXT records, containing SPF information, must be published for the domain.
Receivers must request the SPF information through standard DNS queries for the domain, and act on that information.
Both senders and receivers must configure MTAs appropriately to handle SPF directives. This is completely MTA dependent. The SPF specification does not dictate how the SPF information should be interpreted and acted on.

The configuration of SPF is quite simple. We'll look at the domain vostrom.com. The following MX records are published for this domain.

*host -t mx vostrom.com
vostrom.com          MX     10 inbound.postal.lax.vostrom.com
vostrom.com          MX     20 inbound.postal.phx.vostrom.com

The MX hosts noted above are also the two systems that deliver all mail from http://vostrom.com; therefore, a simple TXT record is created (below) to specify the systems permitted to send mail from the domain.

vostrom.com. IN TXT "v=spfl mx ptr -all"

The following list defines all available SPF directives, including those used in the above example:

A If the domain has an A record that matches the sender's address, the sender is valid.
MX If the domain has an MX record that resolves to the sender's address, the sender is valid.
PTR If the sender's IP address reverse-resolves to a domain that matches the sender's domain, the sender is valid.
IP4 If the sender's IP address is in the given IPv4 address range, the sender is valid.
IP6 If the sender's IP address is in the given IPv6 address range, the sender is valid.
EXISTS If the sender's domain name resolves (regardless of the IP address it resolves to), the sender is valid. (This attribute is used to perform more complex searches with the SPF macro language.)

Using SPF, an ISP or organization may "self-publish" the DNS TXT records with SPF directives. However, for ISPs and large enterprise organizations, accreditation organizations exist that can validate that senders utilizing SPF are not spammers. There is also a certification process in development to help senders and receivers validate their SPF configurations and MTA interoperability.

SPF can solve some of the problems with spam, but like most anti-spam solutions, it is not an all-encompassing solution. Additionally, in implementing SPF, other items are broken. For example, say you are a bargain shopper when it comes to your ISP. You change ISPs regularly for price and performance reasons, but you do not want to inconvenience your points of contact every time you change ISPs. To solve this problem, you registered a domain and use an e-mail address within that domain as your main e-mail address. You point that e-mail address (or addresses in that domain) at your current ISP e-mail address. Now, when you decide to change ISPs, you simply change the forwarding destination of your main e-mail address to your new ISP e-mail address. So you send and receive e-mail at "you@vanitydomain.com" no matter what your ISP. The problem is the e-mail actually is sent through your ISP e-mail server. This is called message forwarding. Natively, SPF implementations break this and other types of message forwarding. In order to solve this problem, a proposed Sender Rewriting Scheme (SRS) must be implemented, which at the time of writing has not been fully adopted yet. Also, SPF is in use by spammers today. If your organization will not accept messages from a server not included in SPF, spammers simply add relays to SPF, thereby bypassing the system. While authenticated sender protocols exist today, these systems need to be analyzed carefully to determine whether they will bring true value to your organization's anti-spam battle.

Mail Filtering Summary

Using techniques such as those listed above, combined with techniques from the previous section on anti-virus filtering, organizations can produce an MTA filtering policy that significantly reduces the amount of unwanted e-mail that is allowed to pass on to the internal e-mail system. In order to capture these techniques in a simpler, more easy-to-use package, several anti-spam software packages exist today. Again, some are built into MTA packages, while others are installed as stand-alone software. Whatever the choice, administrators must ensure the package in use is capable of thwarting an acceptable amount of unwanted e-mail and able to do so within the budget allotted by the organization. A final factor for consideration is whether or not the anti-spam techniques chosen will limit any legitimate e-mail for the organization. If the answer to this question is yes, administrators must determine what the acceptable amount is and modify techniques used accordingly .