Raggedstaff Internet
The friendly ISP

Envelope filters

What is an envelope block?

"Envelope blocks" are tests designed to prevent spam entering our network. They are carried out early in the delivery process, before the message is actually sent in to our servers. In fact, envelope blocks is a bit of a misnomer. Most of the tests we apply are more to do with who the postman is and how he introduces himself, rather than what the envelope looks like! But the main point is that these tests happen before the actual message is received. They are based on the initial exchange between the server delivering a message and our server. A more accurate name would be "protocol level tests".

Envelope blocks are implemented by Raggedstaff as a series of different tests. Each test is allocated a score. The scores for each test that is failed are summed, and if the sum exceeds a set limit the message is rejected. Sets of tests are known as 'policies'

You can apply envelope blocks to each email address individually, or to a whole domain. You can apply different policies to different addresses. Tests are carried out on the basis of the address the mail enters our servers addressed to. If you use mail redirection, tests are carried out on the basis of the address the mail arrived at our servers for, not the address to which it is redirected.

Using envelope blocks we estimate that 92% of spam to Raggedstaff is rejected before it ever enters our network. It's important to understand that this is fairly final and occasionally there will be false positives - legitimate mail that is rejected. We believe the level of false positives is very low, but if it is imperative to you to avoid false positives, don't use envelope blocks.


A policy is a collection of tests. The policy defines the tests that are carried out, the scores assigned to those tests and the score level at which messages are rejected. You associate each address with a policy. You can select from our pre-defined policies or you can define one yourself to meet your particular needs.

Pre-set policies

We provide several pre-set policies that you can use:

No checks are carried out - all mail is passed. This is the default policy and is applied unless you specifically set a different policy for mail to your domain.
This policy requires a relative high score before mail is rejected. It is unlikely to result in legitimate mail being rejected, but it will probably allow quite a lot of spam in.
A basic general purpose policy.
This policy has a relatively low reject threshold. This policy will let little spam in, but it is likely to result in some legitimate mail being rejected
This policy is essentially the same as the 'Normal' policy, but with the addition of scoring against mail servers that are located in countries that are known to be significant sources of spam. Treat this policy with caution - if you expect to receive legitimate mail from any of the countries it scores against you should not use it. Countries currently checked are China, Taiwan, Korea and Brazil.
This is the policy we use for own mail. It is based on the Xenophobic policy, with some additional countries and some tweaked scores. It is likely to change as we tweak things further, so if you want consistent behaviour it is best avoided!

Customising policies

You can not alter the pre-set policies, but you can create your own custom policies. A new policy is based on an existing one, so start by studying the existing policies and selecting the one that most closely meets your needs. You can see a list of existing policies and create a new one from the policy list page.

Once you have created your policy, you can edit it. Before you start on this you should make sure you read our tips on scores. For editing purposes policies are split into three sections:

General settings

General settings include the name and description of the policy, the reject level and a number of pre-configured tests. Many of the pre-configured tests are concerned with how the remote server announces itself (its EHLO argument). Others test whether the remote server has a valid name (a reverse DNS entry) and whether or not the sender's domain authorises the remote sender to send mail (SPF checks - see http://spf.pobox.com/ )

Country blocks

This section allows you to add countries to the list to be tested and to edit the scores assigned to those countries. Country tests are based on a database of which IP addresses are allocated to which country and are not 100% accurate.

DNS block list settings

DNS block lists (DNSBLs) are lists of mail servers that have some connection with spam. The lists can be queried using the Domain Name System (DNS). Simple DNSBLs usually return an IP address, often, if the server in question is listed. There are also 'combined lists' that allow you to send a single DNS query to query several different lists. These return different IP addresses depending on which list the server is found in.

Raggedstaff support both simple and combined DNSBLs. When editing DNSBL entries you must enter the expected result. You can enter the word 'default' as a catchall or for simple lists. For combined lists specify each result you are interested in and allocate it a score. Note that with combined lists if you don't explicitly specify a score for a particular result then the score for 'default' will be used. For this reason it is best to set 'default' to 0 if you do not wish to use all the lists in a combined list.

Reject or tag?

Envelope blocks really come into their own when mail is rejected. This saves on bandwidth, storage, processor cycles and hurts the spammers success figures. But rejecting is pretty final.

We also offer the ability to simply tag the header of mail. This facility is intended for testing only, to allow you to monitor how effective your policies are, to keep an eye out for false positives and to allow tweaking. It is not intended to be used as a long term solution.

We strongly recommend that you initially make use of the 'tag only' option until you are satisfied that your policies are working for you. With this option, mail which failed one or more tests will have an X-wPolicyd: header added, beginning with either ACCEPT or REJECT, and then listing the tests and scores. eg:

X-wPolicyd: ACCEPT: 1.000; L2.SPEWS.DNSBL.SORBS.NET[1]


Tips & tricks

To disable a test

For 'General' tests, set the score to 0. For country tests, delete the country you no longer want to test for. For DNSBLs, delete all the results, including the 'default' result, for that DNSBL.

To reject on a test absolutely

Simply set the score for that test to greater than the reject level for the policy.

What happens to rejected mail?

When we refuse to accept an item of mail we will send a response code advising the sending server of why. That server should then send a message back to the original sender letting them know that delivery failed. This delivery failure notification will normally include the response code sent by our server.

The original sender should therefore see the response code. Of course, if the mail was spam the spammer is unlikely to bother reading it. But if for some reason legitimate mail is rejected, the original sender should see the response from our server.

The response we send includes a web address where the sender can find information on why the message was rejected. If they visit the web page given they will be told which tests were failed. The response has a format like this:

Recipient address rejected: Blocked. See http://raggedstaff.net/mailblock.php?ip=