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
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
As previously mentioned,
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.
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
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
When filtering and SMTP authentication takes place, spammers find it more difficult to send spam out of an organization's network, but not
Viruses can be one of the worst threats to an administrator. This is
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
Number of recipient limits
In addition to built-in capabilities, most MTAs have third-party support for anti-virus
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
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.
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
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
This suggestion can become expensive and very difficult to cost-justify, especially in environments where single vendors'
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
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).
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
Even today, with the very public
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
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
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
For more comprehensive lists of RBLs, you may wish to visit http://www.
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,
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
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
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.
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
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
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
If the sender (or the sender's 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
Option 3 (Turing tests) may also be limited in its
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.
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
MTA IP address (from sender)
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.
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
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
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.
A more recent method used for deterring spam from being sent to or accepted by an organization's MTAs is to slow down or "
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
mail for a given domain. SPF works using "reverse MX" records, whereby the records
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
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.
If the sender's domain
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 "email@example.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.
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