Implementation
“Return Path manages all aspects of our deliverability. We rely on Return Path to protect our email revenue by keeping our reputation intact and our inbox delivery rates high. You can't argue with a 22% increase and that translates directly into sales for us.”
Chris Woodward,
Manager E-commerce Content & Email - Orvis
SpamAssassin is a Habeas partner, and the two organizations have worked together since the 2.6 release of SpamAssassin. Now that Habeas is de-emphasizing the use of the haiku, the most current release of SpamAssassin, version 3.1, no longer checks messages for the presence of the haiku. Instead, by default, SpamAssassin determines whether the originating IP address of each received message appears on the Habeas Safelist. If the IP address is found and is certified at the Confirmed Opt-in level or better, then SpamAssassin gives the message a -8 score. If the IP address is certified at the Single Opt-in level or better, then SpamAssassin gives the message a -4.3 score. If the IP address is simply registered with Habeas but not certified at any permission level, then SpamAssassin gives the message a -0.2 score.
The prior release of SpamAssassin, version 3.0.4, checked inbound messages for the presence of the Habeas copyrighted haiku. If the haiku was found, SpamAssassin checked the Habeas Safelist to determine if the message originated from a Safelisted IP address. If the originating IP address appeared on the Safelist, then SpamAssassin gave the message a -8 score. If the originating IP address did not appear on the Safelist, SpamAssassin then checked the Habeas Infringers List (HIL). If the originating IP address appeared on the HIL, then SpamAssassin gave the message a +12 score.
Habeas strongly recommends that SpamAssassin users upgrade to version 3.1 because this version most accurately reflects how the Habeas Safelist is used currently. SpamAssassin versions prior to 3.1 are based on the copyrighted haiku which is no longer part of the Habeas approach to controlling spam. However, Habeas recognizes that some sites may not be able to upgrade to version 3.1, and therefore the following information is offered for users of version 2.6.3. Users running SpamAssassin 2.6.1 or earlier must upgrade to SpamAssassin 2.6.3 before applying Habeas SA Patch 2.63.
The patch is intended to be applied to a standard SpamAssassin source tree. SpamAssassin should be rebuilt and reinstalled after the patch is applied. Note that while the Habeas SA Patch 2.63 will work with SpamAssassin 2.62, it is recommended that SpamAssassin users upgrade to 2.63 from 2.62 due to known bugs in 2.62.
Apply the patch to the SpamAssassin source as follows:
Please note that this patch only affects Habeas and Habeas-related code. Please also note that these Habeas rules require that the RBL network tests in SpamAssassin be active. After applying the patches, recompile and install SpamAssassin, and if restart spamd if it is being used. In order to check inbound messages for the Habeas SWE mark, but without performing checks of the Habeas Safelist or the HIL, a meta rule can be defined using the _HABEAS_SWE rule. However, even with a meta rule, it may be possible for a spammer to infringe on the mark and avoid detection by SpamAssassin. Using the versions that check the Safelist instead completely eliminates that possibility. Many thanks to Daniel Quinlan and Greg Sutter for their work on the Habeas SA Patch.
SpamBouncer is a spam filter. It analyzes incoming email and separates spam from legitimate messages, adding a header to messages that makes assertions about whether the email appears to be spam or not. Recipients can then choose to use that header to sort incoming email into different folders, or to delete messages identified as spam altogether. SpamBouncer also can block spam at the receiving email server, delete certain types of spam, or send a challenge to senders of blocked email in order to allow them to bypass the filters.
SpamBouncer 2.0 (available for no charge at www.spambouncer.org) is configured by default to check inbound messages for an "Accreditor" header. If the header is present, SpamBouncer then checks the Habeas Safelist to determine whether the message originated from a Safelisted IP address. SpamBouncer's default configuration accepts email streams which are certified by Habeas at the confirmed opt-in, transactional, or one-to-one levels. If single opt-in and personal referral email streams are acceptable, recipients should set HABEASVERIFIED=OI in the variables section at the top of the .procmailrc file. If recipients using SpamBouncer do not wish to use the Habeas Safelist, they should set HABEASVERIFIED=no in the variables section at the top of the .procmailrc file. Please refer to the SpamBouncer web site for additional usage and configuration details.
Habeas makes available a special zone file for Openwave Mx users. In order to use the Safelist, Openwave Mx users must have installed the Edge Gx application.
/*/rblservice/rblServices:
Please note that placing these lines at the beginning of the rules is essential because the Edge Gx DNS RBL Classifier stops processing rules as soon as it finds a match. Please also note that these rules may be customized to accommodate a receiver's policies. For example, if a receiver is willing to allow one-to-one, transactional, and Confirmed Opt-in messages to bypass further filtering, but wishes to have Single Opt-in and personal referral messages pass through the remainder of the classifier rules, then the following rules should be added:
/*/rblservice/rblServices:
It also is possible to give a positive weighting to personal referral and Single Opt-in messages, but please remember that the DNS RBL Classifier ceases processing as soon as it matches a rule. Thus, if Single Opt-in messages were given a higher weighting, and the originating IP address appears on the Habeas Safelist, the classifier collects the assigned score and exits.
Add configure scripts
There are two simple methods for adding Habeas headers using the exim 4 Mail Transfer Agent. The first involves adding them at the transport level, and the second at the router level.
1. Adding headers at the transport level (for all domains on the mail server): The following configuration snippet shows how to add Habeas headers to the remote_smtp transport. If this method is used, Habeas headers will be added to all outbound mail passing through remote_smtp (for simple configs, this means all outbound mail).
2. Adding headers at the router level (for only specific domains on server): Adding Habeas headers at transport level may not be appropriate, for example, for servers with many virtual domains, some of which are licensed for Habeas and some of which are not. The following router instructions will add Habeas headers only for a specific set of sender domains. It should to be used instead of the transport level method. If both are used, then two sets of Habeas headers will be added.
Thanks Richard Welty and Yann Golanski for their assistance in preparing these directions.
