'qmail'에 해당되는 글 21건

  1. 2013.02.05 check qmail & dovecot version.
  2. 2012.07.12 [qmail] mysql 연동을 위한 링크 keep..
  3. 2012.06.11 [qmail] qmail 실행 오류 또는 설치 오류
  4. 2012.05.22 [Qmail] Spamhaus FAQ
  5. 2012.05.22 [Qmail] Spamhaus Rsync 설치 가이드
  6. 2012.05.21 [qmail] rblsmtpd...
  7. 2012.05.14 [qmail] antispam 관련.
  8. 2012.05.14 [qmail] clamav overview
  9. 2012.05.14 [qmail] knetqmail 패키지 파일.
  10. 2012.05.14 [qmail] control 파일 설명

check qmail & dovecot version.

ITWeb/개발일반 2013. 2. 5. 18:44

You can check qmail version.


cat /var/qmail/man/man7/qmail.7

It exist below the string. ("This documentation describes netqmail version")


....

This documentation describes netqmail version

1.05

....


Check dovecot version


# It's very simple.

dovecot --version


:

[qmail] mysql 연동을 위한 링크 keep..

ITWeb/서버관리 2012. 7. 12. 18:53

[vpopmail+mysql 연동]

http://coffeenix.net/board_view.php?bd_code=1476


[mysql 소스설치]

http://blog.beany.co.kr/archives/26

:

[qmail] qmail 실행 오류 또는 설치 오류

ITWeb/서버관리 2012. 6. 11. 18:11

sudo rpm –Uvh /usr/src/redhat/RPMS/x86_64/knetqmail-0.0.1-5.x86_64.rpm


knetqmail 을 rpm 설치 시 아래와 같은 오류가 날때가 있습니다.

/var/tmp/rpm-tmp.80051: line 31: /etc/inittab: 허가 거부됨

보통은 이런 오류가 안날텐데요.
회사마다 보안정책과 권한정책이 다를 수 있으니 이런 오류가 발생 할때는 아래 내용 참고 하셔서 해결을 하시면 됩니다.


[원본링크]

http://system.neulwon.com/xe/3498

[원본내용]

[오류]

[root@mail service]# /etc/init.d/qmail stop
Stopping qmail...
  qmail-smtpd
svc: warning: unable to control /service/qmail-smtpd: supervise not running
svc: warning: unable to control /service/qmail-smtpd/log: supervise not running
  qmail-send
svc: warning: unable to control /service/qmail-send: supervise not running
svc: warning: unable to control /service/qmail-send/log: supervise not running
  qmail pop3
svc: warning: unable to control /service/vpop: supervise not running
svc: warning: unable to control /service/vpop/log: supervise not running
[root@mail service]# /etc/init.d/qmail start
Starting qmail

> stop 은 위와 같은 에러가 출력되고,

   start 는 에러가 발생하지 않으나 포트가 오픈되지 않을때.

 

[해결]

# /command/svscanboot &

# /etc/init.d/qmail start

 

/etc/inittab 에도 아래 행을 삽입하여 부팅시 정상 작동되도록 합니다.

 

SV:123456:respawn:/command/svscanboot


:

[Qmail] Spamhaus FAQ

ITWeb/서버관리 2012. 5. 22. 11:10

Spamhaus FAQ Lists.

Is the new Spamhaus DBL included in my Datafeed?
Yes. All DNSBLs Spamhaus produces are always included in the Datafeed. There is no additional cost to use new additions in the Datafeed. You will find an announcement and usage instructions in your Datafeed Account Area. You can then begin using the DBL straight away.

Are the new Spamhaus whitelists SWL and DWL included in my Datafeed ?
Yes, also the whitelists are included in the Datafeed, at no additional cost.

Query Service or Rsync Service, which should I choose?

The choice of which service to apply for, Datafeed Query Service or Datafeed Rsync Service, depends on how big your network is and how high your email traffic is.

If you have 1,000's of users and very high email traffic or you want to serve our DNSBL data locally to multiple mail servers on your network, we recommend you use the Rsync Service. The Rsync Service requires some setup on your end (requires you also set up Rbldnsd) and usually a dedicated server (although you can also run Rbldnsd on the same machine as your DNS server). So only take the Rsync Service if you understand why you want Rsync/Rbldnsd.

If your network is medium-sized, small, or you want a non-complicated solution with no software to install, the best choice is the Datafeed Query Service. With this service the Datafeed Service Group assigns you a unique account ID and access to a set of private Datafeed Query Service servers. The Query Service is very simple to install (it should take you literally one minute to set up on most moderns mail servers). It requires no extra software or servers.

Instructions for using the Datafeed Query Service with Microsoft Exchange 2007 (PDF. 166 KB) have been published by MXTools.

Both services perform the same. You can switch from Query Service to Rsync Service later on if you find reason to need Rsync Service.


Datafeed Rsync Service: How do I set this service up?
The Datafeed Rsync Service can be installed on nearly any Unix-based machine (Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X, Solaris, Tru64, HPUX, AIX, Irix, etc.). The memory and CPU requirements are usually modest, so that old PCs are typically up to the task. An Internet bandwidth of at least 512 kbps is required. 

Datafeed Rsync Service utilizes 2 free programs, Rsync and Rbldnsd. Both of them are usually also available as packages for the various operating systems. Nowadays, rsync is often part of the base distribution. 

SERVICE INSTALLATION MANUAL 

Spamhaus supplies an Installation Manual with the Datafeed Rsync service, giving instructions for how to install and set the Datafeed up. The manual covers: 

1. installing rsync
2. installing rbldnsd and prepare it for running
3. configuring your local DNS resolver
4. configuring your mail servers

The manual is supplied only after you apply for the Datafeed service, or a free trial of the datafeed service, and it is linked from the account page on the SpamTeq.com web site.

Datafeed Rsync Service: With what domain should I connect the zones locally?
While it is technically possible (by using forwarding in your DNS resolver) to run the sbl, pbl, xbl, zen, dbl local zones under the spamhaus.org domain, we recommend to use a different domain for your local zones. By doing so, you will be sure that queries really stay local rather than being sent to the Spamhaus public servers as a consequence of a configuration error. 

The preferred solution is that of running the Spamhaus zones under a local domain unreachable from the rest of the Internet. For instance, you can use a local domain called "dnsbl", referring to the zones as "sbl.dnsbl", "pbl.dnsbl", "xbl.dnsbl", "zen.dnsbl", "dbl.dnsbl" in your mail servers. With a Bind DNS resolver, this can be done be defining in named.conf
zone "dnsbl" {
        type forward;
        forward only;
        forwarders {
                1.2.3.4;
        };
};
where 1.2.3.4 is the IP address of the rbldnsd server (on the same or on another host). 


Datafeed Rsync Service: How can I use Rbldnsd and BIND together?
You can run rbldnsd on the same system/IP as an existing BIND 9.x DNS server acting as resolver in your network. For instance, the rbldnsd option "-b 127.0.0.1/54" tells rbldnsd to listen on the IP address 127.0.0.1, UDP port 54.

You then configure the BIND server your mail server(s) use, to forward queries for the Spamhaus DNSBLs to rbldnsd by adding the following to named.conf: 
zone "dnsbl" {
        type forward;
        forward only;
        forwarders {
                127.0.0.1 port 54;
        };
};
This port forwarding option is not supported in BIND 8.x. (For BIND 8.x, you need to dedicate an IP address to rbldnsd and configure BIND to not listen on that IP - by telling it which IPs to listen on).

Datafeed Rsync Service: What kind of rbldnsd dataset types should I use?
Rbldnsd defines a few different dataset types. To optimize performance and memory usage, we recommend Datafeed users to choose ip4set for SBL and SWL, ip4trie for PBL, andip4tset for XBL. 

However, using ip4tset will result in a return code 127.0.0.4 for all XBL listings. In the majority of cases this is acceptable, but if you need to distinguish between the different XBL return codes you should use ip4set also for XBL. 

DBL and DWL must always use the dnset dataset type. 

Public mirrors are required to use ip4set for all the IP zones, and dnset for DBL and DWL.

Datafeed Rsync Service: On the rsync server I don't see a combined zen zone file...
The combined 'zen' zone (which we publish to reduce the global DNS traffic on our public nameservers) does not exist as a file. The sbl, pbl and xbl files can be combined into a single "zen" zone by running rbldnsd in this way:
rbldnsd (options) \
        zen.dnsbl:ip4set:sbl \
        zen.dnsbl:ip4trie:pbl \
        zen.dnsbl:ip4tset:xbl \
        ...
That is, the combined zone is built 'on the fly' by rbldnsd from the three files. Datafeed users may choose to run the individual zones, the combined zone, or both. Since all queries are local, the performance advantage of the combined zone is usually negligible unless your mail traffic is really massive.

dbl must not be included in zen: it is a domain zone, not an IP zone, and should never receive queries relative to IP addresses. The two whitelists swl and dwl must also, of course, be individual zones.


How do I test to see if my setup is working?
Once you have set up/configured your mail server (or tools such as SpamAssassin) to use the Datafeed service, you can test to see if the Spamhaus blocking is working by sending an email (any email) to: nelson-sbl-test@crynwr.com (you must send the email from the mail server which you wish to test). The Crynwr system robot will answer you to tell you if your server is correctly blocking SBL-listed IPs or not. 

Similar tests are available for PBL and XBL.

I need to test the Datafeed service first, before ordering it
If you're not sure how well the Spamhaus DNSBLs will perform to reduce incoming spam on your network, and your email traffic is too high to test using our free public DNS mirrors, you can test the Datafeed service offered by Spamhaus Technology for 30 days, free of charge and with no obligations.

Details are available on the Spamhaus Technology web site.


What is the application process?
The application process is designed to allow organizations to initiate an application without committing to taking the service or making a payment until they are first satisfied with the service and have agreed to the service terms. The process is:

1) Use the Price Calculator on the Spamhaus Technology web site to find the correct price for your organization, based on the total number of Email Users you provide service for.

2) Fill out the Datafeed Application Form.

Your application is then submitted to Spamhaus for approval (Spamhaus wants to ensure it does not grant access to its data to organizations involved in spamming). This can take a few hours. Once approved, your Application is handled by an Authorized Datafeed Vendor who will create a Datafeed account for you and email the account information to you. In your Datafeed account area you will then find installation instructions, a Service Agreement (for you to agree), payment options, and technical support contacts.

(Note that you contract the Datafeed Service directly with the Authorized Datafeed Vendor, not with Spamhaus Project, as Spamhaus Project does not have any commercial activities.)

I need to see the Service Agreement contract text before applying for the service
Spamhaus wants to ensure that its data is only given to reputable qualified organizations, we therefore need to know who you are before offering you access to Spamhaus data.

The Datafeed Service Agreement is between you and a 3rd party contractor (Authorized Datafeed Vendor) authorized by Spamhaus to sell and manage the Datafeed service. The Authorized Datafeed Vendor's Agreement therefore is only made available to you once you first complete the Datafeed Application Form which is first vetted by Spamhaus to ensure the application for access to its data is acceptable to Spamhaus.

Completing the Datafeed Application Form does not commit you to anything.

Who do I contract the Datafeed service from?
The Datafeed service is sold, supplied and managed by Authorized Datafeed Vendors, independent resellers of SpamTEQ (UK), licensed by The Spamhaus Project to include realtime Spamhaus data in a Datafeed service format.

You therefore contract the Datafeed Service directly with an Authorized Datafeed Vendor and not with Spamhaus Project (as Spamhaus Project does not have any commercial activities). The Authorized Datafeed Vendor is also responsible for first-line technical support.

The Spamhaus Project retains responsibility for initial vetting of your Datafeed application (to weed out any suspect applications by spam firms attempting to gain access to the data and to disallow supply of the service to networks engaged in spam service or support activities).

Why is there a charge for this service?
In 2004 Spamhaus introduced the Datafeed service to replace the former free but simple Rsync service. The change from free to subscription-based became necessary in 2004 in order to handle the exponential growth of the service. Thousands of networks take synchronized transfers of Spamhaus DNSBL data, it is therefore a resource-intensive service that demanded its own separate and independent management, servers and support infrastructure.

To guarantee the availability of the service, provide support and maintain the equipment and redundency behind it, Spamhaus decided in 2004 to move the provision of the service to authorized Datafeed contractors who manage, sell and support the Datafeed service.

The announcement of the service change, and reasons for moving it to a charged annual subscription, was made in Spamhaus's 2004 "A Blueprint for the future" document outlining the future of Spamhaus: Futureproofing Spamhaus.

Does the pricing change?
Yes, approximately every two years the service price may be adjusted in line with inflation and market value. Current pricing can be calculated by using the Datafeed Price calculatoron the Spamhaus Technology web site.

Service Restrictions
Spamhaus evaluates every Datafeed service application to ensure the applicant is bona fide and is not involved in the provision or support of spam services.

Service Refusal

The Datafeed service is refused to any ISP with excessive SBL listings, bad enough to be listed in the Spamhaus 'TOP 10 Worst Spam ISPs' chart. Spamhaus considers an ISP whose spam control practices are so bad that the ISP is listed in our "TOP 10" to be "knowingly facilitating spam operations (for profit)". The consensus is that such ISPs should be putting far greater efforts into reducing the spam problems they cause and that it is hypocritical to attempt to reduce incoming spam to their own customers much of which is caused by them in the first place.

I don't need this service, I got a Barracuda instead!
The major part of spam filtering done by appliances such as the Barracuda is in fact DNSBL filtering using among other things the Spamhaus DNSBLs and other data from Spamhaus. If you are using any Spamhaus lookup in any part of a Barracuda or similar spam filter appliance you must ensure you have a current Spamhaus Datafeed subscription from a Spamhaus Authorized Datafeed Vendor.

If you do not have a current Spamhaus Datafeed subscription, then you are abusing Spamhaus's public DNSBL servers. If your email volume is big enough that you need a Barracuda or similar spam filter appliance, then you certainly CAN NOT use Spamhaus's free public DNSBL servers.

Contrary to what you may have been told by the nice Barracuda salesman, Spamhaus does not have any agreement with Barracuda for the use of any Spamhaus DNSBLs with Barracuda appliances. Nor does Barracuda contribute in any way to Spamhaus (the sales claim on the Barracuda website that they support Spamhaus with donations is an untruth).

Because Spamhaus's public DNSBL servers get heavily abused by companies with spam filter appliances, mostly Barracuda appliances, Spamhaus has implemented a control system on the public DNSBL servers to flag and firewall such users and Barracuda appliances in particular.

Please ensure that if you are using Spamhaus DNSBLs in any part of your corporate spam filtering setup, you have a Spamhaus Datafeed subscription in place first.

:

[Qmail] Spamhaus Rsync 설치 가이드

ITWeb/서버관리 2012. 5. 22. 11:09

Datafeed Installation Guide

1.0 Introduction

1.1 Using The Service

This document describes how to use the Datafeed Rsync Service to block spam using the Spamhaus Project blocking lists (BL). The Datafeed Rsync Service has these advantages over the traditional scheme based on DNS queries over the public DNS infrastructure of the Spamhaus Project:
  1. it is still based on DNS queries, so changes to do in the mail servers configuration are minimal (in most cases a simple editing of the BL domain);
  2. all DNS queries are local, so the turnaround time is short and entirely under your control. This means shorter transit times for messages;
  3. as far as BL checks are concerned, any problem on the outside network or at the Spamhaus servers will not slow down your mail flow. At most, the copy of the BL in use will not be the most current and a bit more spam may be allowed in.

Besides the four BL (SBL, PBL, XBL and DBL), the Datafeed Rsync Service also includes access to two whitelists (WL), SWL and DWL, introduced in September 2010 and currently in the process of being populated.

The Datafeed Rsync Service requires availability of a machine running Linux, FreeBSD, OpenBSD, NetBSD or some other variety of Unix (such as Mac OS/X, Solaris, Tru64, HPUX, AIX, Irix, etc.) The memory and CPU requirements are usually modest, so that old PCs are typically up to the task. For instance, a 400 MHz Pentium with 512 MB of memory is usually sufficient for small organizations. A virtual machine with 512 MB would also be fine.

For customers running Microsoft operating systems, we recommend using the Datafeed Query Service instead. This service is based on DNS queries sent to the Internet rather than local, but answered by an infrastructure entirely separate from the public infrastructure.

1.2 The Plan

You will need to do the following:
  1. some preparation work (section 1);
  2. install rsync (section 2);
  3. install rbldnsd and set it up to run (section 3);
  4. configure your local DNS resolver (section 4);
  5. configure your mail servers or antispam appliances (section 5).
Note that this type of setup for using a local copy of blocking lists is quite standard. You may find that most of the setup work described in this document can be used to incorporate other blocking lists in your system.

2.0 Preparation

2.1 Requirements

You need a server with a Linux or Unix-like operating system to be able to run rsync and rbldnsd.

rsync is a program to maintain a mirror copy of one or more files, and is nowadays available in the base distribution or as a package on all the major platforms.

rbldnsd is a DNS server specialized to serve blocking list data, and can also run on several Unix-like operating system. It is known to be working on Linux, FreeBSD, NetBSD, OpenBSD, Mac OS X, Solaris, HP-UX, AIX.

Unless your traffic volumes are high (on the scale of millions of messages per day), the hardware requirements for your server are moderate. Normally a server with, say, a 400 MHz CPU and 512MB of RAM is adequate. In particular, the rbldnsd process with all the lists loaded takes usually between 100MB and 150MB of RAM. Disk space usage should remain within 500 MB (also considering the increased storage requirements during the rsync updates).

It is not necessary to assign a dedicated server for this task; most organizations install the software on an existing server, or on a virtual machine.

At the time of this manual version, synchronizing the zones usually implies about 50 MB of incoming data per hour. This quite large amount is mostly caused by the highly dynamic nature of ``zombie'' (trojaned) PCs: hundreds of thousands of IP addresses can enter and leave our XBL database in a single day. For this reason, a bandwidth of at least 512 kbps is recommended to run a Data Feed, and 2 Mbps is desirable. It is possible to confine a Datafeed to use a lesser amount of bandwidth using techniques discussed in the rsync configuration section, but we do not recommend to assign less than 256 kbps. We recommend that users with limited bandwidth use the Rsync Query service instead.

You need to be in control of the DNS server(s) handling general DNS resolutions on your network. If you are currently using DNS resolvers provided by your ISP, prepare to install and use your own (using the DNS server software of your choice). This has nothing to do with the authoritative DNS service for your domain(s), which may well remain hosted by an ISP.

2.2 Directory organization

You need to define a directory where Spamhaus files are imported by the rsync process, and another where they are used by the rbldnsd process. In the remainder of this document it will be assumed that these two directories are respectively /usr/local/dnsbl/spamhaus and /usr/local/dnsbl/rbldnsd, although you can relocate these directories in any place on your system. You will not need to define any subdirectory within those directories.

2.3 Users and groups

You will need to create a user named rbldns and a group also named rbldns (note that, for historical reasons, there is no "d" at the end of the name). This user will have no shell and no home directory. The most common choice for UID and GID is perhaps 153, but you may choose any unused number. rbldnsdwill run under this user and group. If you install rbldnsd as a package prepared for your operating system (if available), this step will likely be done automatically during the installation process, with UID and GID assigned automatically.

Note that rbldnsd does not need write access to the dataset files. For security reasons, all datasets used by rbldnsd must not be owned by the user rbldns.

rsync can run under any existing user in the system.

2.4 Clock

Make sure that your machine is running with the correct clock, so that your server will synchronize the zone files at the times indicated in the instructions.

It is a good idea to keep the time synchronized with an external source using the ntpd daemon. Please check your system documentation for details.

2.5 Firewall settings

You need to allow outgoing traffic to port 873/tcp in order to reach the Spamhaus rsync servers. Note that Spamhaus has several servers at different IPs scattered throughout the world, that may change because of maintenance, hardware failures, network malfunctions, IP relocations, DDOS attacks, supplier changes, etc. While the service is stable, IPs of specific servers are not. We therefore discourage people from allowing only rsync traffic going to specific IPs. Since the rsync connections are initiated by you and you will not be running a rsync server (just a client), opening outbound rsync traffic to any destination does not constitute a significant security risk. A large fraction of support tickets opened by our customers is related with useless firewalling of outbound rsync traffic at the customer site.

If your server is running ntpd, traffic from 123/udp and directed to 123/udp should also be allowed in both directions to allow your server to talk with the time servers on the Internet.

Of course, to and from DNS traffic between the rbldnsd server and its clients must also be allowed.rbldnsd only uses 53/udp -- it does not use 53/tcp. Access to the rbldnsd server should be limited to your local DNS resolvers and to any other IP that needs to be able to send queries directly to therbldnsd server. In all cases, do not allow access to the rbldnsd server from unknown clients outside your network.

3.0 Installing and running rsync

3.1 Why rsync ?

The rsync program is one of the best options for data transfer in all cases where a previous version of the file is already available. Since rsync transmits only file differences across the communication channel, this allows for high efficiency when changes between the current and the previous version constitute a small fraction of the whole file.

This is the typical scenario for blocking lists, which are usually rather large files with a limited number of modifications between one version and the next. Keeping a copy updated using rsync is therefore much more efficient than using ftp or http even when compression schemes are used. While compression can still be used, it brings limited advantages and some important disadvantages (for instance increased CPU load), so we do not use it.

Rather, we have tried to organize data within the XBL zone (which is by far larger than SBL, PBL and DBL) so that file changes between updates tend to cluster in specific areas of the file. Due to the way the rsync algorithm works, such measure decreases the number of bytes transferred in each update and makes the whole synchronization process more efficient.

3.2 Installation

Nowadays rsync can usually be found within the regular operating system distributions. Otherwise, it can be downloaded from the rsync home site and installed ("make install"). Note that you will need only the client component, so you do not need to run the server daemon. Also, there is no need to edit any configuration file.

To verify that your client is working, try the command

        rsync na.dr.spamhaus.net::
You should see a 'Welcome' message and a directory list from our server.

Note: If you see a message like

  Please contact Spamhaus Technology if you are interested in using this service.
  See http://www.spamhaus.org/datafeed/ for further informations.
it means that you are connecting from an IP address not authorized to connect to our Datafeed servers. If the machine has multiple interfaces, try again making sure that the source IP of the connection is the one that you sent to Spamhaus. This can be done using the --address option of rsync, like in
   rsync --address=1.2.3.4 na.dr.spamhaus.net::
(replace "1.2.3.4" with the IP address on your machine supposed to be authorized to use the Datafeed Rsync service). If this does not solve the problem, contact support.

Note: If you get a "Connection refused" message or can not connect for other reasons, it is likely that some firewall at your side is blocking outbound rsync traffic. Please see the subsection on Firewall settings about the firewalling policies for rsync outbound traffic.

3.3 Syntax

In general, calling rsync with one argument results in a directory listing, while calling it with two arguments results in a file synchronization. The second argument must be the name of the local file.

The spamhaus-sync.sh script takes care of details, so you do not really need to worry about the command syntax if you are not using rsync for other purposes.

In case you need to access the directory directly, rather than through spamhaus-sync.sh, keep in mind that there are two different but equivalent syntaxes to specify the location of a remote file. One is the traditional rsync syntax

   rsync na.dr.spamhaus.net::rbldnsd/remotefile localfile
while the other is the more recent URL syntax
   rsync rsync://na.dr.spamhaus.net/rbldnsd/remotefile localfile
Choose the syntax style that you prefer.

3.4 Running via cron

You will use a cron job to call a script named spamhaus-sync.sh every minute. This does not mean that all the zone files will be synchronized every minute. SpamTeq controls the zones update policies through some parameters contained in the zone files, and tuned to optimize the service and avoid congestions when there are major updates. On the basis of these parameters and of the current time, every minute the script will decide what BL and WL files will be updated.

The service now requires version 3.1.2 of spamhaus-sync.sh, distributed since October 27, 2010. If you are a Datafeed customer from before that date, please replace your script with the current one. If you were still running a version 2.x.x script, you also need to change the crontab entry to call the script every minute rather than every 30 minutes.

The line to be defined in /etc/crontab will be like

  * * * * * service /usr/local/bin/spamhaus-sync.sh
The shell script spamhaus-sync.sh can be downloaded using the command
rsync na.dr.spamhaus.net::tools/spamhaus-sync.sh spamhaus-sync.sh
In this example the script will be run as user service (of course this can be any valid username in your system, but please do not use root!). The reason we execute a script rather than the rsync program itself is the script allows us to do some additional bookkeeping, get some better diagnostics in case of errors, and to make the system more robust against possible network troubles.

Note: We are not supporting usage of scripts different from spamhaus-sync.sh (which is designed to minimize the risk of congestions). If you have particular needs that spamhaus-sync.sh can not address, please contact us.

Note: In all cases, never use the IP address of a specific Spamhaus rsync server in scripts. IPs can change at any time and without notice in advance. This is essential to achieve continuity of service in presence of adverse network conditions (such as DDoS attacks, etc), or we can simply decide to distribute traffic between different servers, change IPs for server maintenance purposes, add new servers, etc. Note that the time-to-live of DNS records for our rsync servers is very short exactly for these reasons. In practice, a DNS lookup to discover the rsync server IPs should be made before any synchronization.

Note: For the same reasons given above, we do not recommend you block outbound rsync traffic by default, "punching holes" for the Spamhaus servers IPs. These IPs can change at any time, resulting in troubles until you reconfigure the firewall rules. If security is a concern, we recommend you define a rule acting on the source IP, allowing outbound rsync connections to any destination but only if coming from the specific IP of your machine initiating the rsync connections. Remember that we are talking about outbound connections only: you will not have any rsync server running, just a client. Risks are minimal and not larger than the risks associated with running a web browser in your network (which you probably do without having to punch a hole in the firewall for any web site you want to visit).

Note: If your bandwidth availability is limited (of the order of 1 Mbps or less) and the synchronization causes a congestion of your link affecting other activites, you may consider to use the --bwlimit=KBPSoption of rsync, that can decrease the bandwidth at the expense of a longer synchronization time, as discussed in a subsection below.

3.5 Configuring spamhaus-sync.sh

Before using it, you need to edit spamhaus-sync.sh to tailor it to your environment. The configuration variables are confined in the initial section of the script, and you are not supposed to need making changes outside of this section.

These notes refer to version 3.1.2 or later of spamhaus-sync.sh, available since October 27, 2010. If you have a version 2.x.x or 3.0.x script from a previous installation, please download the most recent version from our rsync server before proceeding.

We now review the configuration variables. In the most common situations, only TROUBLES, WORKDIR and RSYNCPOOL need to be changed.

  • TROUBLES. This variable contains an email address (or a list of addresses separated by commas, without spaces in between) that will receive trouble notifications. If you leave it empty, troubles will not be notified (but some information will still be available in diagnostic files left in the OUTDIR directory).
  • WORKDIR. This is the name of the directory where synchronizations are performed, assumed to be /usr/local/dnsbl/spamhaus throughout this manual.
  • BLFILES. This variable contains a list of the Spamhaus files to be synchronized. It is usually set to "sbl pbl dbl xbl swl dwl". Edit this variable if you need only some of these datasets.
  • SBLPOLICY. Spamhaus makes available a more aggressive "policy" version of the SBL zone. The policy version may contain usually short-lived "escalation" listings that could block some non-spam mail. This option should be chosen only by organizations willing to accept some false positives to the end of getting cooperation from networks with serious spam problems. The "policy" version is the one served by the public DNS infrastructure. To use the policy version set SBLPOLICY to 1, otherwise leave this variable empty.
  • RSYNCPOOL. This variable contains the name of the rsync server pool to use. At present we support two pools of servers: na.dr.spamhaus.net referring to servers in North America, andeu.dr.spamhaus.net referring to servers in Europe. Choose the server pool that you believe to be closer (in terms of traveling times of Internet packets) to your geographical location. You mustedit this variable.
  • RSYNCHOST_IP_PREFER. If you have reasons to prefer one particular server in our pool (for instance because it is very close to you), you can place its IP in this variable. If we remove that IP from the pool, your preference will become ineffective. At most one IP can be specified. Most users do not specify anything here.
  • RSYNCHOST_IP_AVOID. If you have reasons to avoid at all costs one particular server in our pool (for instance because connectivity between that IP and yours is poor), you can place its IP in this variable. At most one IP can be specified. Most users do not specify anything here.
  • RSYNCOPTS. rsync options. The current recommended setting is "-L -t --timeout=50". See thersync man page for details. Please handle with care, and do not use the -B/-block-size=SIZEoption and the -z/--compress option.
  • VERIFY. This is a flag indicating whether we want cksum verification of data integrity or not. A value of 1 means that verification will be done (recommended). Leave it empty if you do not want cksum verification.
  • RSYNC. Name or full pathname of the rsync command. On some platforms rsync sits in a directory which is not part of the default path name for cron jobs, and the full pathname is required. For instance, FreeBSD users may have to prepend /usr/local/bin/.
  • CKSUM. Name of the program used for verification, usually cksum but a full pathname can be specified if the command does not sit in a directory included in the default path name for cron jobs (unlikely). It is not used if VERIFY is empty.
  • MAILER. This variable contains the name of the program used to mail the trouble notices. The standard Unix program generally called mailx or Mail is the usual choice (on some platform this program is not part of the basic install and must be installed from a package). The variable may contain just the program name or the full pathname. It is not used if TROUBLES is empty.
  • HOST and DIG. The script needs to be able to access either one of these two similar programs to perform DNS queries. A full pathname can be specified if the command does not sit in a directory included in the default path name for cron jobs. For instance, Solaris users may have to prepend/usr/sbin/.
  • GZIP. Access to the gzip compression/decompression program is needed for updating zones as compressed zone files. A full pathname can be specified if the command does not sit in a directory included in the default path name for cron jobs. If gzip is not available, normal uncompressed zone files will be transferred. This is an experimental feature we are currently investigating: at this time no zone file is compressed yet.
  • LOGFILE. Location of a log file, containing one line for each rsync transaction. Lines in the log file contain in the order date, time (UTC), file name, IP address of rsync server, total file size, elapsed time in seconds, rsync exit status.
  • OUTDIR. Name of the directory where the output file (and other auxiliary files) generated by this script will be written. This file can be useful when things go wrong, as it contains error messages from all the commands called during the script execution. The default choice is "/tmp" but any choice is fine, as long as the UID running the process can write into it.
  • TIMEFILE, SKIPFILE, PSTMPFILE: location of temporary files needed by the script. They may be changed if you wish.
After you have configured all variables, it may be useful to run the script from an interactive shell before creating the new crontab line. If you do that, keep however in mind that the program should be run under the same UID in the crontab (otherwise files can not be overwritten later), and that the path seen by cron tasks is often more restricted than the one seen by commands run interactively (so the script run under cron may fail even if it runs successfully from an interactive shell). Also keep in mind that the script may take a long time to execute the first time you run it, because an amount of the order of 100 MB of data has to be transferred from the net. Subsequent runs are much lighter, because rsync only transmits differences.

Finally note there should be no output sent to stdout or stderr, as output will go to spamhaus-sync.out in the OUTDIR directory independently on how the script is run. This file is costantly overwritten by different executions, and it is generated only for diagnostic purposes.

3.6 Verifying data integrity

The data integrity verification is incorporated in the spamhaus-sync.sh script. We describe it here briefly, mainly for the benefit of users setting up their own scripts.

If you look at the bottom of a Spamhaus zone file, you will see a line like

                # CKSUM: 2767122920 379852
This line, generated by Spamhaus at the end of the zone file construction process, contains the output of the cksum program (available in nearly all the most common Unix/Linux distributions). The two numbers are in the order a checksum CRC and the total number of bytes in the file, computed by considering the whole zone file except the last line (the one we are talking about). Therefore, this line can be used to verify the integrity of the file at the end of the synchronization procedure. Files that do not pass the verification should not be put into production. Likewise, files that do not contain the CKSUM line at the end are corrupted and should not be put into production. Verification failures are rather uncommon, and if they occur repeatedly they may indicate the presence of serious network or hardware malfunctions.

The Bourne shell code accomplishing the verification is usually the following:

   CRC0=`tail -1 xbl | awk '{print $3}'`
   CRC1=`sed '$d' xbl | cksum | awk '{print $1}'`
   if [ "$CRC0" = "$CRC1" ]
   then
       (ok)
   else
       (fail)
   fi
where (ok) and (fail) should be expanded to the appropriate commands to handle success or failure respectively. $CRC0 is the checksum as extracted from the file, while $CRC1 is the checksum as computed from the file.

3.7 Limiting bandwidth usage

If it is found that the Datafeed Rsync service is using up too much bandwidth during updates, saturating your line and slowing down other activities, bandwidth usage can limited using the --bwlimit=KBPS option of rsync. This option can be added in the RSYNCOPTS variable in the spamhaus-sync.sh script. For instance:
             RSYNCOPTS="-L -t --timeout=120 --bwlimit=64"
Note: the bandwidth is expressed in kilobytes per second, while line speeds are usually given in bits per second (bps). Therefore, the KBPS parameter must be multipled by 8K to give the actual bandwidth limit in bps. In the example given above, the limit would be 512 kbps.

Since large updates currently may require transferring about 15 MB (with occasional peaks up to 20 MB or possibly more), the updating time with a limit of KBPS kilobytes per second would result in a transfer time of the order of 250/KBPS minutes: or about 2 minutes for KBPS=128, 4 minutes for KBPS=64, etc. Given that updates should complete within at most a few minutes, going below KBPS=64 (512 kbps) should be regarded as risky in terms of performance. A value as low as KBPS=16 (128 kbps) is almost guaranteed to give problems, and we recommend not to go below 32 ever.

Also note that this mechanism is only effective to decrease the intensity of bandwidth peaks by increasing their duration. It will not decrease the average bandwidth, which is determined by the amount of data to be transferred.

For the same reason, changing the updating interval can not improve the situation much. Updating less often would result in a larger amount of data transferred for each synchronization, and viceversa. In other words, if you can not dedicate enough bandwidth you will simply not be able to keep up with the astounding rate of creation of new spam emitters and spam domains on the Internet. Considering that having fresh copies of XBL and DBL is important to block spam from new emitters and advertising new domains, we do not recommend to increase the updating intervals, as this would mean more spam with limited bandwidth savings. Users with bandwidth problems should consider the Datafeed Query service instead.

4.0 Installing and running rbldnsd

rbldnsd is a specialized DNS server, written by Michael J. Tokarev, designed and optimized to answer blocking list queries. Among its advantages:
  1. rational format for input datasets (in particular, networks can be specified using the CIDR notation);
  2. ability to merge multiple files in a single blocking list;
  3. easy way to include exceptions (unlisted addresses located within a listed range);
  4. extremely small memory footprint;
  5. extremely limited CPU requirements (very fast);
  6. high stability and reliability.
For this reason, Spamhaus has chosen rbldnsd as the DNS server of choice for the Data Feed option, as well as the production software for all the public nameservers. rbldnsd is capable of sustaining many thousands of DNS queries per second using ordinary PC hardware.

It is important to note that rbldnsd is not a complete nameserver (such as, for instance, Bind) and, in particular, it does not have a caching facility: it can only answer (authoritatively) queries about the blocking list zones it has loaded, and nothing else. Therefore, it will not replace the DNS resolver(s) you are using in your network. The thing to do is to inform the resolver(s) that the local BL/WL queries (and only those!) are answered by the rbldnsd server, and this point is discussed in section 5.

4.1 Installation

As already indicated, rbldnsd can run on all the major Unix-like operating systems. Check if a rbldnsdpackage is available for your platform. If not, download the source code, compile it (usually this means giving the commands ./configure and make), and install the resulting executable file in an appropriate directory, such as for instance /usr/local/sbin. This can be done simply by copying the rbldnsdexecutable file. You may also wish to install the man page, and check the existence of user and grouprbldns as indicated in a previous section. That is all: there are no configuration files, all the relevant informations are passed via command line when starting the program as described below.

In case of installation troubles please refer to the program documentation or to the rbldnsd mailing list. We suggest that you subscribe to the mailing list anyway (mail volumes are moderate).

4.1.1 Installation on Linux Debian and Ubuntu

Users of the Debian and Ubuntu Linux distributions can install rbldnsd as a package using
    apt-get install rbldnsd

4.2 Running

We recommend that you create a local domain -- one which does not exist on the Internet -- to host your local blocking lists. This has several advantages:
  1. you will be sure that no query is going outside your network due to a configuration mistake;
  2. you will be more confident that no one from outside will ask BL/WL resolutions to your servers (although restricting access with a firewall is always a good idea!);
  3. you retain access to the public BL/WL of Spamhaus (for debugging, testing or other needs).

In this document it will be assumed that your BL and WL domain will be dnsbl. Therefore, for instance, you will send queries to sbl.dnsbl rather than to sbl.spamhaus.org. Note that this local domain name is totally arbitrary and can be changed at will.

rbldnsd can combine one or more datasets into a DNS zone, and can simultaneously serve different DNS zones. A dataset is, basically, a file containing IP addresses and ranges; a DNS zone is the domain queried via DNS to obtain informations about an IP address. As far as we are concerned, you will deal with six datasets (sbl, pbl, xbl, dbl, swl and dwl) that will be mapped onto six zones (sbl.dnsbl,pbl.dnsbl, xbl.dnsbl, dbl.dnsbl, swl.dnsbl and dwl.dnsbl). It is also possible to combine the first three datasets (all containing IP addresses) into a single zone zen.dnsbl, with a slight gain in efficiency and a slight loss in flexibility. Furthermore, it is possible to define the individual zones and the combined zone. The kind of mapping to use is entirely up to you. Mappings are defined in the command line arguments used to launch rbldnsd, as discussed in the next section.

rbldnsd reloads itself when it notices that a dataset file changed. So there is no need to give any "reload" command during normal operation.

4.3 Options and arguments

In this section we discuss the options of the rbldnsd command which we considered relevant for the operation of your Datafeed Rsync service. A complete list of options can be found on the rbldnsd man page.

4.3.1 Select an IP (-b option)

Specifying this option is required: there is no default. You will give this option multiple times if yourrbldnsd needs to listen to several IP addresses.

If you are going to run rbldnsd on a machine with no regular DNS server (the simplest situation), you will specify the option -b IP.ad.dre.ss, where IP.ad.dre.ss is the primary IP address of your system. This must be an address visible by all the DNS resolver(s) in your network that need to be able to send BL queries -- the resolver(s) used by your mail servers.

If, on the other hand, you are going to run rbldnsd on the same machine hosting your local DNS resolver, or any other DNS server, you need to assign different IPs to the two servers to avoid a conflict on port 53 (if your resolver is Bind 9, it is also possible to bind rbldnsd to a different port, as detailed in section 5.2.1, however this is often problematic and we do not recommend it). If you wish, you can bindrbldnsd to the localhost interface 127.0.0.1 and Bind (or whatever your DNS server is) on the main Ethernet interface. This is valid if rbldnsd needs to be accessed only from the DNS resolver on the same machine. If your DNS server is already occupying port 53 of 127.0.0.1, you can also create a second localhost address (such as 127.0.0.2) and bind rbldnsd to this address (this is often preferable to using a non-standard port number).

If you need to access rbldnsd from other machines in your network, you will have to create an IP alias for the Ethernet interface and bind rbldnsd to that alias.

rbldnsd can be simultaneously bound to several IP addresses on the machine. According to the program documentation, using more than one address implies a small performance penalty. We will assume that you will use just one address; let this address be, for sake of simplicity, 1.2.3.4. Once you have selected the address, make sure that Bind (or whatever your DNS server is) will not bind to this address when starting. By default Bind binds all the available addresses, so to obtain this result you have to editnamed.conf specifying the addresses you want Bind to use. For instance, if your machine has 1.2.3.3 and 1.2.3.4 as IP addresses of the main Ethernet interface,

        options {
                ...
                listen-on {
                        127.0.0.1;
                        1.2.3.3;
                };
                ...
        };
in named.conf would leave 1.2.3.4 available for rbldnsd. The rbldnsd command line option -b 1.2.3.4 will then instruct rbldnsd to use that IP.

4.3.2 Select the root directory (-r option)

rbldnsd will do a "chroot" within the directory you indicate with the -r directory option. This means that this directory will play the role of the root directory / as far as the program is concerned, and so the program will be unable to access anything outside it, with an obvious security advantage.

Using the organization discussed in section 2.2, we will use

        -r /usr/local/dnsbl

As far as rbldnsd is concerned, the directory that you specify with this option becomes the root directory. Therefore, the program will map an absolute path name like /path/na/me into a filename/usr/local/dnsbl/path/na/me in your filesystem. Moreover, there is no way to refer to files outside the root directory: do not attempt to use symbolic links to escape the root jail.

Moreover, you should use relative pathnames in symbolic links, as in

        % cd /usr/local/dnsbl/rbldnsd
        % ln -s ../spamhaus/sbl sbl
        % ln -s ../spamhaus/pbl pbl
        % ln -s ../spamhaus/xbl xbl
        % ln -s ../spamhaus/dbl dbl
        % ln -s ../spamhaus/swl swl
        % ln -s ../spamhaus/dwl dwl
Symbolic links defined using full pathnames would not work correctly when using the chroot option, and would cause rbldnsd to be unable to find the zone files.

Note: sbl, pbl, xbl, dbl, swl, dwl above are files, not subdirectories.

4.3.3 Select the working directory (-w option)

Within the root directory defined by the -r option, and again referring to the structure discussed in section 2.2, we will use
        -w rbldnsd
to specify the directory where rbldnsd expects to find its files. This will be /usr/local/dnsbl/rbldnsd in your filesystem. In our case these files are symbolic links. rbldnsd will be able to follow them, because the files themselves are still within the rbldnsd root directory.

4.3.4 Fork a child during reloads (-f option)

rbldnsd can continue to process requests even during data reloads using the -f option. This is done by forking a child process to handle requests while the parent reloads the data. The price to pay is extra memory usage since two copies of the data are kept in memory during reloads.

Unless you are very tight on memory, we recommend to select this option. If you do not select it, your mail servers may have to wait a few seconds (or queries may time out and cause some spam to flow through) when rbldnsd reloads.

4.3.5 Arguments: mapping datasets to zones

We recommend, for maximum flexibility, to define independent zones for SBL, PBL, XBL, DBL, SWL, DWL, as well as the combined zone ZEN including SBL, PBL and XBL. This is done by calling rbldnsd with the following argument list:
             sbl.dnsbl:ip4set:sbl  \
             pbl.dnsbl:ip4trie:pbl \
             xbl.dnsbl:ip4tset:xbl \
             zen.dnsbl:ip4set:sbl  \
             zen.dnsbl:ip4trie:pbl \
             zen.dnsbl:ip4tset:xbl \
             dbl.dnsbl:dnset:dbl \
             swl.dnsbl:ip4set:swl \
             dwl.dnsbl:dnset:dwl
These arguments indicate how the XXX.dnsbl zones are composed out of the available datasets. Note how the zen combined zone is obtained simply by associating three different datasets to the same zone name.

The string after the first colon specifies the method internally used by rbldnsd to map the file into a data structure:

  • ip4set is a flexible general method that we recommend for SBL and SWL.
  • ip4trie defines a mapping method efficient for datasets like PBL containing networks in the CIDR notation.
  • ip4tset is efficient for a dataset like XBL containing only single IPs.
  • dnset is a data structure designed to contain domains, rather than IP addresses, and is therefore the structure needed by DBL and DWL.

Note: the \ characters are required to break the command into several lines, and they must be the last character in each line (in other words, make sure that you do not have any space after the \ !). Of course you can also define a single, long command line without any \ character.

Note: the datasets must not be owned by user rbldns. The daemon only needs read access to the datasets.

4.3.6 Restricting access

If you have bound rbldnsd to an IP address reachable from the external Internet, you may wish to restrict access to make it impossible for unauthorized third parties to use your server for BL lookups. While this can certainly be accomplished by using a firewall, it may be useful to know that rbldnsd has the possibility to define an ACL (Access Control List).

To this end, create a file named acl into /usr/local/dnsbl/rbldnsd containing

    0.0.0.0/1 :ignore
    128.0.0.0/1 :ignore
    1.2.3.0/24 :pass
The first two lines indicate "block access to the whole Internet" (rbldnsd does not accept 0.0.0.0/0 as a valid entry), while the last line will contain the network range with allowed access to the service. To specify multiple networks just enter multiple pass lines. The ignore keyword means that all DNS queries received by source IPs not included in the pass lines will simply be absorbed and ignored, without returning any response.

To use the acl file, add :acl:acl to the argument list in the command line (the first acl is a fixed keyword while the second acl is the file name). Do not forget the colon at the beginning; for more details see the rbldnsd man page under acl Dataset.

Note: to implement access restrictions, you must be running rbldnsd release 0.996 or later. Since 0.996 was released in 2006, this condition should now be satisfied unless your O/S is really old.

4.4 Launching at boot

rbldnsd is a daemon that is typically launched at boot time and left running permanently. You will therefore invoke rbldnsd at startup time, following the conventions of your operating system and giving all the options and arguments presented above. Remember to launch it in the final stage of the boot process, and particularly after the network interface has been brought up.

If you installed rbldnsd as a package prepared for your operating system, there will be a script to start and stop the program, and a place where options and arguments have to be indicated. If you compiled and installed rbldnsd by yourself, you can use a simple startup script like the following:

    #!/bin/sh
    #  Start the rbldnsd daemon
    /usr/local/sbin/rbldnsd -b 1.2.3.4 -f \
            -r /usr/local/dnsbl -w rbldnsd \
            sbl.dnsbl:ip4set:sbl  \
            pbl.dnsbl:ip4trie:pbl \
            xbl.dnsbl:ip4tset:xbl \
            zen.dnsbl:ip4set:sbl  \
            zen.dnsbl:ip4trie:pbl \
            zen.dnsbl:ip4tset:xbl \
            dbl.dnsbl:dnset:dbl \
            swl.dnsbl:ip4tset:swl \
            dwl.dnsbl:dnset:dwl \
            :acl:acl
(the last argument is required only if access control is used, as described in section 4.3.6).

The termination script can be as simple as

    #!/bin/sh
    #  Stop the rbldnsd daemon
    killall rbldnsd

Note that -- since it binds to a privileged port -- rbldnsd must be started as root. The program drops the root privilege as soon as it binds to the DNS port. From that point on, it runs under the rbldns user.

Verify that the program is started and stopped correctly using these scripts, or the similar scripts supplied by the rbldnsd package for your operating system.

Note: Make sure that no space follows the \ continuation character at the end of each line, otherwise the command will be truncated and some zones will not be loaded!

4.4.1 Launching at boot using Linux Debian and Ubuntu

Linux Debian and Ubuntu users that have installed rbldnsd as a package (as described in section 4.1.1) should define the following variable in /etc/default/rbldnsd:
    RBLDNSD="dnsbl -b 1.2.3.4 -f -r /usr/local/dnsbl -w rbldnsd \
            sbl.dnsbl:ip4set:sbl  \
            pbl.dnsbl:ip4trie:pbl \
            xbl.dnsbl:ip4tset:xbl \
            zen.dnsbl:ip4set:sbl  \
            zen.dnsbl:ip4trie:pbl \
            zen.dnsbl:ip4tset:xbl \
            dbl.dnsbl:dnset:dbl \
            swl.dnsbl:ip4tset:swl \
            dwl.dnsbl:dnset:dwl \
            :acl:acl"
(the last argument is required only if access control is used, as described in section 4.3.6).

rbldnsd will be launched at boot, and

    /etc/init.d/rbldnsd {start|stop|restart|reload}
will start/stop/restart/reload the daemon.

4.5 Security and access limitation

We recommend implementing an access control list (ACL) as described in section 4.3.6. Access to it can also be restricted by using a firewall to limit the transit of 53/UDP packets to and from the client systems. rbldnsd does not use TCP.

4.6 Testing rbldnsd

To verify that the daemon is properly running, send A or TXT queries to the zone using the dig command or the host command. For instance,
        % dig A 2.0.0.127.sbl.dnsbl @1.2.3.4
should show an answer
        2.0.0.127.sbl.dnsbl.  300 IN A  127.0.0.2

Equivalently,

        host -t A 2.0.0.127.sbl.dnsbl 1.2.3.4
should give
        2.0.0.127.sbl.dnsbl has address 127.0.0.2

Note that these commands generate queries that are specifically directed to the rbldnsd server at the address 1.2.3.4. It is crucial to verify that these tests work as expected before proceeding to the next sections.

5.0 Configuring your DNS resolver

You now have a rbldnsd server capable of resolving queries in domains like sbl.dnsbl. However, dnsbl is not a top-level domain like com or org, and therefore your DNS resolver will not be capable of handling the queries until you inform it that those queries have to be sent to the local rbldnsd server. This is actually very simple, and this section explains how to do it. In the examples in this section it is assumed, like in the previous sections, that the rbldnsd server has IP address 1.2.3.4.

There are two methods that can be used to achieve the desired goal: the NS delegation method and the forwarding method.

The NS delegation method can be used regardless of the particular DNS server software that you are using. When using this method, your DNS resolver will learn, through the usual DNS delegation mechanisms, that BL/WL queries have to be sent to the rbldnsd server.

The forwarding method can be used for some common DNS server software such as Bind (however, it can not be used with the Microsoft DNS Server). When using this method, your DNS resolver will forward the query to the rbldnsd server, get the answer and pass it back in a way completely transparent to the client. This method is slightly faster to implement, but it is somewhat less clean and finding errors is more tricky. We recommend to organizations with a complex infrastructure and several mail servers to choose the delegation method if they can.

5.1 Delegation method

In the delegation method you create a local DNS zone named dnsbl, and explicitly define delegation records that indicate that the blocking list subzones are handled by your rbldnsd server. If you are using the Microsoft DNS Server, use the DNS Manager for this purpose. Otherwise, use the tool you commonly use to create or change information about your local domains.

Create a new primary (master) zone called dnsbl, insert into it an A record pointing to your rbldnsdserver, and the NS record(s) for the list(s), like:

        rbldnsd    IN  A     1.2.3.4
        sbl        IN  NS    rbldnsd
        pbl        IN  NS    rbldnsd
        xbl        IN  NS    rbldnsd
        zen        IN  NS    rbldnsd
        dbl        IN  NS    rbldnsd
        swl        IN  NS    rbldnsd
        dwl        IN  NS    rbldnsd
This means that your rbldnsd server will be known with the name rbldnsd.dnsbl within your network. DNS queries like 2.0.0.127.sbl.dnsbl directed to the resolver will be diverted to the rbldnsd server for resolution. In this setup, the rbldnsd server receives query traffic directly from the machines originating the queries. Restart your DNS resolver after the changes.

Note: sbl, pbl, xbl, zen, dbl, swl, dwl are DNS subdomains, not hosts. Any entry like

        zen        IN  A     1.2.3.4   ; *WRONG*
will not produce any useful result.

5.2 Forwarding method

This method does not require the creation of a new local zone. It is implemented by editing the DNS server configuration. The details depend on the DNS server you are using.

Reports from the field indicates problems associated with the forwarding method used with DNSSEC. If your DNS infrastructure uses DNSSEC, we recommend using the delegation method instead.

5.2.1 Forwarding method using Bind 8 and 9

If you are running Bind version 8 or version 9, edit the configuration file named.conf and insert
    zone "dnsbl" {
            type forward;
            forward only;
            forwarders {
                    1.2.3.4;
            };
    };
where the IP address of the rbldnsd server has been put in the forwarders list (if you have more than one rbldnsd server, include all of them in the list).

Reload Bind, and it will now forward all queries ending with .dnsbl (that is, all blocking list queries, including non-Spamhaus zones that you might also have) to the rbldnsd server, wait for the answer, and return the answer to the client. In this setup, the rbldnsd server receives all query traffic from the Bind resolver.

Note that Bind 9 also allow to specify a port different from port 53 for each forwarder. This allows you to put rbldnsd on the same IP as Bind, using a different port. This is done using a syntax like

    zone "dnsbl" {
            type forward;
            forward only;
            forwarders {
                    1.2.3.4 port 54;
            };
    };
In this way you can have Bind and rbldnsd on the same IP. This is not possible using Bind 8. This method sometimes leads to unexpected problems, and our recommendation is to use the standard port (creating new IP aliases if necessary) unless it is absolutely necessary to run on an alternate port.

5.2.2 Forwarding method using dnscache

If you use the dnscache program within the djbdns suite, you should be able to define a forwarder by giving these commands:
        cd /service/dnscache
        echo 1.2.3.4 > root/servers/dnsbl
        chmod 644 root/servers/dnsbl
        svc -t .
For further details please check the djbdns documentation.

5.2.3 Forwarding method using Microsoft DNS Server

You can not use the forwarding method with the Microsoft DNS Server.

5.3 Security and access limitation

By contractual terms you should not redistribute Spamhaus data outside your organization, even if unintentionally. In practice this means that your DNS servers should not answer dnsbl queries coming from unauthorized parties outside your network. Blocking direct access to rbldnsd has been already discussed in section 4.3.6, however you should also make sure that dnsbl queries sent to your DNS resolver from outside are not answered. This is particularly important if you chose the forwarding method.

In fact, as a general rule it is recommended, for security reasons, to ignore all DNS traffic coming from external unauthorized parties -- with the only exception of requests relative to Internet domains for which your server has been designated as an authoritative server.

Under Bind, access can be generally restricted by configuring ACLs in named.conf as follows:

    ...
    acl trusted {
       192.168.0.0/24;
       1.2.3.0/24;
    };
    options {
       ... other options ...
       allow-query {
           trusted;
       };
       allow-recursion {
           trusted;
       };
    };
    ...
In this example, 192.168.0.0/24 is an internal network (RFC1918 addresses) used by your organization, and 1.2.3.0/24 are your external Internet addresses (they may not be present if your Internet gateway is using NAT and you only use internal addresses in your LAN). If your DNS server is also giving authoritative nameservice to specific domains, the general query access restrictions indicated in theoptions section can be overridden within the zone sections for those domains.

For a more detailed discussion of these points, Bind users can consult this document prepared by Team Cymru, while users of the Microsoft DNS server can consult this and this Microsoft technical note.

NOTE: if you chose the forwarding method and your DNS resolver is open to the world, you are likely redistributing Spamhaus data in violation of contractual terms.

5.4 Testing dnsbl resolution

After your DNS resolver has been reconfigured as indicated above and reloaded, the tests described in section 4.6 should also work without explicitly directing queries to the rbldnsd server, but simply using your local resolver. For instance,
        % dig A 2.0.0.127.sbl.dnsbl
should produce
        2.0.0.127.sbl.dnsbl.  300 IN A  127.0.0.2

We recommend that you perform this test from your mail servers, which will be the main "users". We also recommend to verify that the mail servers do not use any fallback resolver that does not know about the blocking lists. On Unix-like systems the list of resolvers is usually found in the file/etc/resolv.conf. All the nameserver directives in this file should point to DNS resolvers that know how to handle dnsbl resolutions.

Do not proceed to the next section until these tests work as expected.

6.0 Configuring your mail servers

The last step to do is to configure your mail servers so that they send DNS queries to check if the client IPs are listed on the Spamhaus blocking lists, and reject all mails that satisfy this condition. This can be done using the generic BL lookup facility that you find in virtually all the mail server or antispam appliance products in use today. Please consult your mail server or appliance documentation for details. Moreover, the Spamhaus web site contains some useful instructions and pointers.

In this section we start with some general indications, valid for all mail servers, and describe more in detail what to do for some common servers and appliances.

The whitelists SWL and DWL are not covered in this section yet, firstly because several mail server products are not yet supporting their usage, but also because these lists are currently being constructed slowly and carefully and the number of entries they contain is still rather limited. We expect this situation to improve drastically during 2011. In the meanwhile, we recommend that you start serving them in your local DNS infrastructure as described in the previous sections.

6.1 General indications

In general, this is what you have to do:
  1. make sure that the server/appliance resolves DNS names using your DNS resolver(s), configured as described in section 5;
  2. configure your mail server or antispam appliance to use the external blocking list for IP addresses zen.dnsbl (or sbl.dnsbl, pbl.dnsbl, xbl.dnsbl if you have chosen to go with separate zones). If the configuration includes references to spamhaus.org, replace them with corresponding references to dnsbl.
  3. configure your mail server or antispam appliance to use the external blocking list for domainsdbl.dnsbl. Again, if the configuration includes references to spamhaus.org, replace them with corresponding references to dnsbl.

Below are instructions on how to accomplish this for some specific cases.

Note: if your setup makes use of a content analyzer separate from the mail server -- such as for instance SpamAssassin -- which also queries the Spamhaus databases to compute the spam scores assigned to messages, make sure to replace all references to spamhaus.org in its configuration with corresponding references to dnsbl.

Note: do not use zen.dnsbl for content analyzers, URL verification, etc.: it contains the PBL database which is not designed for this purpose. Content analysis should be done with sbl-xbl.dnsbl or sbl.dnsbl. The former blocks more spam but may generate occasional false positives.

6.1.1 Configuring sendmail

Locate the sendmail.mc file and edit it. Insert the following line (as a single line with no linefeeds):
FEATURE(dnsbl, `zen.dnsbl', `"550 Mail from " $&{client_addr} " rejected 
    using zen.spamhaus.org. Please see http://www.spamhaus.org/query/bl?ip=" 
    $&{client_addr}')dnl
The location of the line of the file is not important. Produce a sendmail configuration file using the m4command:
        m4 sendmail.mc > sendmail.cf
then place sendmail.cf into the appropriate directory (usually /etc or /etc/mail) and restart sendmail.

6.1.2 Configuring postfix

Edit main.cf (usually located in /etc/postfix), and add
        reject_rbl_client zen.dnsbl
in the list of recipient restrictions, as in
        smtpd_recipient_restrictions =
            permit_mynetworks,
            reject_unauth_destination,
            reject_rbl_client zen.dnsbl,
            permit
Then create a file named for instance dnsbl-reply-map containing the line
zen.dnsbl  554 $client blocked using zen.spamhaus.org. Please see $rbl_txt
Create a hash map of it with
        postmap hash:dnsbl-reply-map
then insert
        rbl_reply_maps = hash:dnsbl-reply-map
in main.cf. Reload postfix.

6.1.3 Configuring qmail

First of all, you must have ucspi-tcp installed to enable you to run rblsmtpd, the qmail module that does DNS lookups to blocking lists and uses the results to allow or disallow SMTP connections.

Edit the run file (usually located in /var/qmail/supervise/qmail-smtpd) and locate the line invokingtcpserver at the bottom of the file. It will be something like

        /usr/local/bin/tcpserver (...options...) \
        0 smtp \
        qmail-smtpd
(the details can differ in your installation, and you may see 25 in place of smtp). Insert the invocation ofrblsmtpd just before the qmail-smtpd argument as follows:
        /usr/local/bin/tcpserver (...options...) \
        0 smtp \
        /usr/local/bin/rblsmtpd -b -r zen.dnsbl \
        qmail-smtpd
With this setting, an incoming SMTP connection will launch rblsmtpd, which will check if the client IP is listed in our databases. If it is listed rblsmtpd handles the rejection dialogue, while if it is not listedrblsmtpd launches qmail-smtpd for normal mail delivery.

Note: Some qmail users have reported that the BL checks are made also for outgoing mail submitted by legitimate users of the mail server using authenticated SMTP. In these cases, the client IP is not a mail server and is likely to be listed in the PBL database. Therefore, users would not be able to send mail. The standard way to solve this problem is to run a separate qmail instance that listens on port 587, accepts only authenticated mail submissions and does not use rblsmtpd. See this example and this discussion.

6.1.4 Configuring SpamAssassin

In this section we describe how to configure SpamAssassin so that it sends query to your local server rather than to the public servers of the Spamhaus Project.

Note that to take advantage of the DBL component, you need SpamAssassin 3.3.1 or later. These instructions assume that your SpamAssassin version is at least 3.3.1. If you are running an earlier release, you should omit all the lines including "DBL".

Go to the SpamAssassin configuration directory, which is usually /etc/mail/spamassassin or/etc/spamassassin. Insert the following definitions (overriding SpamAssassin's own definitions, referring to the Spamhaus Project public service) in the file local.cf:

 header __RCVD_IN_ZEN eval:check_rbl('zen','zen.dnsbl.')
 header RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.','127.0.0.[45678]')
 header RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.', '127.0.0.1[01]')

 uridnssub URIBL_SBL       zen.dnsbl. A 127.0.0.2
 urirhssub URIBL_DBL_SPAM  dbl.dnsbl. A 127.0.1.2
 urirhssub URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255

Restart SpamAssassin.

For further information we recommend to consult the SpamAssassin documentation.

6.1.5 Configuring a Barracuda Spam Firewall appliance

This subsection applies only to owners of Barracuda Spam Firewall appliances.

A Barracuda can be configured to query your local servers in place of the public Spamhaus infrastructure. To achieve this goal from the web interface of the appliance:

  1. select BASIC, then IP Configuration. Look at the IP addresses selected as Primary and Secondary DNS Server. Are these resolvers configured to recognize the dnsbl domain as described in Section 5 ? If yes, proceed to the next point. Otherwise, change these fields so that the Barracuda appliance only uses resolvers that know how to deal with dnsbl requests. If you have just one resolver, leave empty the Secondary DNS Server field. Do not specify nameservers that are not under your control (such as your ISP's nameservers).
  2. select BLOCK/ACCEPT, then External Blacklists. Set to 'Off' all the spamhaus.org zones that might be configured. Insert zen.dnsbl as a Custom External Blacklist. Hit Save Changes.

6.1.6 Configuring a SonicWALL Email Security appliance

This subsection applies only to owners of SonicWALL appliances with Email Security, version 6.x.

A SonicWALL Email Security appliance can be configured to query your local servers in place of the public Spamhaus infrastructure. To achieve this goal from the control interface of the appliance:

  1. follow System > Host Configuration and look at the DNS server IP addresses (Primary DNS server IP address and, if configured, Fallback DNS server IP address). Are these your DNS resolvers configured to recognize the dnsbl domain as described in Section 5 ? If yes, proceed to the next point. Otherwise, change these fields so that the SonicWALL appliance only uses resolvers that know how to deal with dnsbl requests. If you have a single resolver, indicate just that one. Do not specify nameservers that are not under your control (such as your ISP's nameservers).
  2. follow Anti-Spam Anti-Phishing > Black List Services (BLS), add a new entry zen.dnsbl. The entry should be automatically enabled after you add it. Disable all the currently configured services referring to spamhaus.org, if any.

6.1.7 Configuring a Symantec Mail Security appliance

This subsection applies only to owners of Symantec Mail Security appliances, 8200 Series.

A Symantec Mail Security appliance can be configured to query your local servers in place of the public Spamhaus infrastructure. To achieve this goal from the web interface of the appliance:

  1. from the Control Center, follow Settings > Hosts > Edit > DNS and look at the DNS server IP addresses. Are these your DNS resolvers configured to recognize the dnsbl domain as described in Section 5 ? If yes, proceed to the next point. Otherwise, change these fields so that the Symantec appliance only uses resolvers that know how to deal with dnsbl requests. If you have a single resolver, indicate just that one. Do not specify nameservers that are not under your control (such as your ISP's nameservers).
  2. from the Control Center, follow Policies > Sender Groups > Blocked Senders (Third Party Services). Disable all the currently configured services referring to spamhaus.org, if any, then clickAdd and insert zen.dnsbl.

6.1.8 Configuring Clearswift MIMEsweeper

This subsection applies only to owners of Clearswift MIMEsweeper software for Microsoft Windows. We assume here a version of MIMEsweeper 5.x equipped with the SpamLogic feature.

MIMEsweeper can be configured to query your local servers in place of the public Spamhaus infrastructure. To achieve this goal:

  1. make sure that the DNS resolver(s) configured on this machine are your DNS resolvers, configured to recognize the dnsbl domain as described in Section 5. If this is the case, proceed to the next point. Otherwise, configure this machine to only use resolvers that know how to deal withdnsbl requests. Do not specify nameservers that are not under your control (such as your ISP's nameservers).
  2. from the Manager program, follow SMTP Relay > Receiver > Anti-spam > Properties. Replace all the currently configured blocking lists in the spamhaus.org domain with the equivalent ones in thednsbl domain.



:

[qmail] rblsmtpd...

ITWeb/서버관리 2012. 5. 21. 12:34

[원본링크]

http://cr.yp.to/ucspi-tcp/rblsmtpd.html

[원본글]

D. J. Bernstein 

TCP/IP 
ucspi-tcp

The rblsmtpd program

rblsmtpd blocks mail from RBL-listed sites. It works with any SMTP server that can run under tcpserver.

Interface

     rblsmtpd opts prog
opts is a series of getopt-style options. prog consists of one or more arguments.

Normally rblsmtpd runs prog. prog is expected to carry out an SMTP conversation to receive incoming mail messages.

However, rblsmtpd does not invoke prog if it is told to block mail from this client. Instead it carries out its own limited SMTP conversation, temporarily rejecting all attempts to send a message. Meanwhile it prints one line on descriptor 2 to log its activity.

rblsmtpd drops the limited SMTP conversation after 60 seconds, even if the client has not quit by then.

Options:

  • -t n: Change the 60-second timeout to n seconds.

Blocked clients

If the $RBLSMTPD environment variable is set and is nonempty, rblsmtpd blocks mail. It uses $RBLSMTPD as an error message for the client. Normally rblsmtpd runs under tcpserver; you can use tcprules to set $RBLSMTPD for selected clients.

If $RBLSMTPD is set and is empty, rblsmtpd does not block mail.

If $RBLSMTPD is not set, rblsmtpd looks up $TCPREMOTEIP in the RBL, and blocks mail if $TCPREMOTEIP is listed. tcpserver sets up $TCPREMOTEIP as the IP address of the remote host.

Options:

  • -r base: Use base as an RBL source. An IP address a.b.c.d is listed by that source if d.c.b.a.base has a TXT record. rblsmtpd uses the contents of the TXT record as an error message for the client.
  • -a base: Use base as an anti-RBL source. An IP address a.b.c.d is anti-listed by that source if d.c.b.a.base has an A record. In this case rblsmtpd does not block mail.

You may supply any number of -r and -a options. rblsmtpd tries each source in turn until it finds one that lists or anti-lists $TCPREMOTEIP.

If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions.

RBL sources

If you want to run your own RBL source or anti-RBL source for rblsmtpd, you can use rbldns from the djbdns package.

I've heard about the following public RBL sources:

  • dev.null.dk
  • list.dsbl.org, using rbldns as of 2002-03
  • multihop.dsbl.org, using rbldns as of 2002-03
  • orbs.dorkslayers.com
  • orbz.gst-group.co.uk
  • relays.osirusoft.com
  • unconfirmed.dsbl.org, using rbldns as of 2002-03
  • dnsbl.sorbs.net
  • cbl.abuseat.org
I've given up on the following RBL sources for various reasons:
  • blackholes.mail-abuse.org, demanding money for access as of 2001-07
  • dialups.mail-abuse.org, demanding money for access as of 2001-07
  • dul.maps.vix.com, renamed dialups.mail-abuse.org
  • inputs.orbz.org, disabled as of 2002-03
  • outputs.orbs.org, disabled in 2001-06
  • outputs.orbz.org, disabled as of 2002-03
  • rbl.maps.vix.com, renamed blackholes.mail-abuse.org
  • relays.mail-abuse.org, TXT records eliminated in 2000-08, demanding money for access as of 2001-07
  • relays.msci.memphis.edu, a copy of relays.mail-abuse.org with TXT records, disabled in 2001-01 because mail-abuse.org started demanding money
  • rss.maps.vix.com, renamed relays.mail-abuse.org
  • or.orbl.org, down as of 2001-10
  • relays.ordb.org, no longer in operation
  • bl.spamcop.net, fails to interoperate with deferred-delivery ISPs
relays.mail-abuse.org stopped working with rblsmtpd in August 2000, because all the TXT records were removed. ``They were eliminated because the zone file is growing rather large,'' the maintainers said. This problem wouldn't occur with rbldns, because rbldnsdatabases are much smaller than zone files. However, the people who run MAPS also have financial interests in BIND, and they refuse to use rbldns.

Temporary errors

Normally, if $RBLSMTPD is set, rblsmtpd uses a 451 error code in its limited SMTP conversation. This tells legitimate clients to try again later. It gives innocent relay operators a chance to see the problem, prohibit relaying, get off the RBL, and get the mail delivered.

However, if $RBLSMTPD begins with a hyphen, rblsmtpd removes the hyphen and uses a 553 error code. This tells legitimate clients to bounce the message immediately.

There are several error-handling options for RBL lookups:

  • -B: (Default.) Use a 451 error code for IP addresses listed in the RBL.
  • -b: Use a 553 error code for IP addresses listed in the RBL.
  • -C: (Default.) Handle RBL lookups in a ``fail-open'' mode. If an RBL lookup fails temporarily, assume that the address is not listed; if an anti-RBL lookup fails temporarily, assume that the address is anti-listed. Unfortunately, a knowledgeable attacker can force an RBL lookup or an anti-RBL lookup to fail temporarily, so that his mail is not blocked.
  • -c: Handle RBL lookups in a ``fail-closed'' mode. If an RBL lookup fails temporarily, assume that the address is listed (but use a 451 error code even with -b). If an anti-RBL lookup fails temporarily, assume that the address is not anti-listed (but use a 451 error code even if a subsequent RBL lookup succeeds with -b). Unfortunately, this sometimes delays legitimate mail.

Acknowledgments

Thanks to Andrew Richards for his comments on this documentation.


:

[qmail] antispam 관련.

ITWeb/서버관리 2012. 5. 14. 23:38

[원본링크]

http://qmail.kldp.net/wiki/wiki.php/qmail_antispam

[원본글]

Anti spam 시스템 구축하기 

  • 이글은 qmail을 이용한 메일서버를 운영중인 시스템 관리자를 위한 문서이며 본문의 내용중에 다소 틀린 내용이 있을 수 있습니다.
  • 글에 문제가 있다면 언제라도 고쳐서 업데이트를 해주시길 바라겠습니다.^^;
  • 좋은 의견은 stone@linuxstudy.pe.kr 로 주시면 감사하겠습니다.
  • 존칭은 생략하도록 하겠습니다. 널리 이해해 주시기 바랍니다.

머릿말 

2 어디서 부터 막을 것인가? 

qmail 시스템에서 스팸 필터링 하는 과정은 크게 세 가지 정도로 구분지어 본다.(이건 어디까지나 필자의 의견이다..^^)
이번 장 에서는 전체적으로 스팸 필터링하는 과정에 대한 설명을 하고 실제 스팸필터링 도구를 이용하는것은 3장을 참고하도록 한다.

2.1 메일 시스템에 접근하는 단계에서의 필터링 

이 단계에서는 불 필요한 메일에 대한 처리 과정이 없이 smtp 서버에 접속을 막기 때문에 서버의 불필요한 자원의 낭비를 막아주는 효과가 있다.
TCP/IP 프로토콜 중에서 주로 IP 기반의 필터링을 하는 과정이다.

2.1.1 rblsmtpd 를 이용 

rblsmtpd 프로그램은 [http]ucspi-tcp 패키지에 포함되어 있는 프로그램으로 rbldns서버에 쿼리를 던져서 그 결과에 따라 접속 허가를 해주는 프로그램이다.

rblsmtpd 설정 예(qmail-smtpd/run 파일의 내용이다.) 
주의.) 필자의 셋업을 그대로 복사해서 사용하지는 말라.테스트용 run파일이다.^^;
rblsmtpd가 들어가는 라인만 참조하자.

#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
QMAILQUEUE="/var/qmail/bin/qmail-dk"
DKQUEUE="/var/qmail/bin/qmail-scanner-queue.pl"
DKSIGN="/etc/domainkeys/linuxstudy.pe.kr/mail"
export QMAILQUEUE DKQUEUE DKSIGN

rbldns="-r bl.spamcop.net -r rbl.linuxstudy.pe.kr"

exec /usr/local/bin/softlimit -m 100000000 \
/usr/local/bin/tcpserver -vRHl0 -x/etc/tcp.smtp.cdb \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -t 30 -b $rbldns \
/var/qmail/bin/qmail-smtpd mail.linuxstudy.pe.kr \
/bin/checkpassword /bin/true 2>&1

2.1.2 tcp.smtp(cdb) 이용 

qmail.kldp.net 에서 열심히 활동해주시고 계시는 ironiris 님이 업데이트 하셨던 [http] 스팸서버 발송지 주소리스트 를 참조해보자.
tcp.smtp 파일(파일을 변경하였다면 tcprules 명령으로 cdb 파일을 업데이트 하도록 한다.)

1.2.3.4(스팸발송지ip):deny
5.6.7.8(스팸발송지ip):deny
tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp

2.1.3 시스템의 방화벽을 이용(리눅스의 경우에는 iptables) 


Shell>iptables -A INPUT -p tcp -s 스팸아이피주소 -j DROP

2.1.4 qmail control파일 이용 

badmailfrom 이나 기타 스팸필터관련 패치 이후 환경 설정 파일을 이용하는 방법.(실제로는 qmail-smtpd 단에서 호출해서 사용하지만 일단 tcpserver 와 qmail-smtpd 중간의 과정이라 이곳에 기록한다.)

2.2 qmail 의 Queue 에 저장되는 단계에서의 필터링 

2.2.1 qmail-queue 단에서의 필터링(ex. qmail-queue-scanner,qfilter,etc) 

먼저 큐메일의 전체적인 구조를 살펴보도록 하자.
참고. [http]큐메일시스템 메시지 전달과정
외부에서 우리의 메일서버로 메시지가 전송되는 과정은 다음과 같다.

 tcpserver->qmail-smtpd->qmail-queue->qmail-send->qmail-lspawn->qmail-local->메일박스
큐메일 서버의 전달 과정을 보면 알겠지만 모든 메시지는 qmail-queue에 의해서 메시지가 처리된다.
물론 qmail-smtpd 소스를 고쳐서 qmail-queue 이전에 스팸 메일들을 처리할수도 있겠지만 이미 큐메일의 queue patch 도 있고 금방 적용하기 쉬운 편이라 필자는 개인적으로 queue 단에서 스팸처리를 하는것을 선호하는 편이다.
  • [http]Queue patch를 적용한 이후에 원래 qmail-queue 대신에 다른 프로그램을 호출하여 스팸처리를 하는것이다.
    queue_patch 이후에 메시지 전달 과정은 아래처럼 변경이 되는 것이다.

     tcpserver->qmail-smtpd->임의의 필터링 프로그램(or qmail-queue)->qmail-send->qmail-lspawn->qmail-local->메일박스

    • 2.2.2 qmail-smtpd 단에서의 필터링(ex. domainkey,spf,spamcontrol,etc) 

    변형된 qmail-smtpd 를 이용한 스팸메일 필터링

    2.3 MDA 단계(사용자의 메일박스에 메시지가 도달하기전)에서의 필터링 

    .qmail 을 이용한 메시지 처리(ex. procmail,maildrop,etc)

    아래는 procmail을 이용한 메시지 처리의 예.

    [root@db stone]# cat .qmail 
|/var/qmail/bin/qmail-quota
|/var/qmail/bin/preline /usr/bin/procmail -p -m /home/webmail/linuxstudy.pe.kr/stone/.procmailrc
[root@db stone]# 


    [root@db tttt]# cat .procmailrc 
PATH=/bin:/usr/bin:/usr/local/bin
DEFAULT=/home/webmail/linuxstudy.pe.kr/tttt/Maildir/
MAILDIR=/home/webmail/linuxstudy.pe.kr/tttt/Maildir/
LOGFILE=/var/log/qmail/procmail
VERBOSE=no
SHELL=/bin/sh

:0 Efhw
*^(Subject|From|Cc):.*=\?EUC-KR\?(B|Q)\?
|formail -c | hcode -dk -m

:0 Efhw
*^(Subject|From|Cc):.*=\?ks_c_5601-1987\?(B|Q)\?
|formail -c | hcode -dk -m

    3 Spam filtering 도구 소개 

    여기서 소개하는 스팸 필터링 도구는 일반적으로 많이 사용된다고 생각되는 것으로 각각의 취향에 맞게 구축해볼것을 권유한다.

    3.1 메일 서버 접근 단계의 필터링 도구 

    3.1.1 rblsmtpd 

    - 메일서버에 접속하는 클라이언트 아이피가 rbldns 서버에 등록되어 있는 IP 인지 여부를 판단하여 등록되어 있을 경우에는 rbldns서버에 기록되어진 반송 메시지와 함께 반송을 한다.
    rblsmtpd에 대한 자세한 내용은 [http]rblsmtpd한글 메뉴얼을 살펴보도록 하자.

    rblsmtpd 를 설정했을때의 qmail-smtp로그 파일의 내용이다.(필자는 현재 spamcop.net 과 필자가 직접 구축한 rbldns 를 이용하고 있다. 

    @4000000046c8b4dc2e44d74c rblsmtpd: 61.183.0.8 pid 1601: 553 Blocked - see http://www.spamcop.net/bl.shtml?61.183.0.8
@4000000046ca90a91a7ab984 rblsmtpd: 72.237.208.57 pid 23522: 553 Your IP is Blocked, see http://spamlist.linuxstudy.pe.kr/lookup?72.237.208.57

    rblsmtp 설정하기
    /var/qmail/bin/qmail-smtpd/run 파일에 아래와 같이 rbldns 서버의 주소를 추가해 준다.
    -r 은 블럭리스트 -a white 리스트임.

    안타깝게도 rbldns서버들이 예전에는 많았지만 많이 유료화 되었다.(우리나라에서는 [http]kisa에서 무료로 rbldns서버를 운영하는것으로 알고 있다.)

    exec /usr/bin/softlimit -m 66000000 \
/usr/bin/tcpserver -vRHl0 -x/etc/tcp.smtp.cdb \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/bin/rblsmtpd \
-t 30 -b -a white.linuxstudy.pe.kr \
-r bl.spamcop.net \
-r rbl.linuxstudy.pe.kr \
/var/qmail/bin/qmail-smtpd linuxstudy.pe.kr  /bin/true 2>&1

    Q) 반드시 다른 rbldns 서버를 사용해서 ip필터링을 해야 하나요??
    A) 아니다. Local 베이스의 rbldns 서버를 구축할 수 있다.(참고. 이운억님께서 작성하신[http]rbldns구축하기)

    3.1.2 spamdyke 

    - rblsmtp 처럼 tcpserver 와 qmail-smtp 사이에서 IP레벨의 다양한 필터 설정을 할 수 있는 통합(?)툴이다. 또한 패키지에 들어있는 몇몇 유틸리티들은 다양한 기능들을 제공해주고 있다.
    - 먼저 소스를 [http]spamdyke다운로드 한다.
    - 받은 소스를 압축을 해제하고 소스디렉토리에서 make 명령을 실행하여 spamdyke 실행파일 생성
    - 적당한 위치에 파일을 복사(/var/qmail/bin/spamdyke)
    - qmail-smtpd/run 파일 수정

    Shell>wget http://www.spamdyke.org/releases/spamdyke-2.6.3.tgz
Shell> tar xvfz spamdyke-2.6.3.tgz
Shell> cd spamdyke-2.6.3/spamdyke
Shell> make
Shell> cp spamdyke /var/qmail/bin/
Shell> vi /var/qmail/supervise/qmail-smtpd/run

    예제)spamdyke 를 포한한 smtpd run파일 내용

    exec /usr/bin/softlimit -m 66000000 \
/usr/bin/tcpserver -vRHl0 -x/etc/tcp.smtp.cdb \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp  \
/var/qmail/bin/spamdyke -a 30 /var/qmail/bin/qmail-smtpd linuxstudy.pe.kr  /bin/true 2>&1

    위의 예제는 spamdyke 의 많은 옵션중에서 한번 접속당 recipients 수를 지정한 경우 입니다.
    이외에도 아주 많은 옵션을 제공합니다만 일일히 설명드리기에는 너무 많네요. [http]www.spamdyke.org에 가셔서 도움말 참고하시면 되실겁니다.

    3.2 qmail-smtpd or qmail-queue 단계에서의 필터링 도구 

    qmail 의 queue 단계에서의 필터링은 반드시 qmail의 queue 패치를 해주는게 좋다. 물론 queue 패치없이도 필터링이 불가능 한것은 아니다.
    약간의 꼼수겠지만 qmail-queue 바이너리 파일의 이름을 변경하고 다른 프로그램으로 대체하는것이다.
    먼저 [http]netqmail-1.05를 사용중이라면 별도의 패치가 필요없을 것이다. 이미 queue 패치가 이루어진 버전이기 때문이다.
    qmail-1.03 버전을 사용한다면 반드시 패치를 해주도록 하자.

    Qmail-queue 단계에서의 필터링을 위한 기본 구성.
    - 먼저 qmail-smtpd 에 QMAILQUEUE라는 환경변수를 통해서 기본 큐 프로그램인 qmail-queue 를 다른 프로그램으로 전환한다.
    둘중에 편한 방법을 선택하도록 한다.

    run 파일로 변경하는 방법.

    QMAILQUEUE="qmail-queue 를 ��~@신�~U� 다른 ��~D��~\그�~^�(ex. /var/qmail/bin/qmail-scanner-queue)"
export QMAILQUEUE
exec /usr/bin/softlimit -m 66000000 \
/usr/bin/tcpserver -vRHl0 -x/etc/tcp.smtp.cdb \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/bin/rblsmtpd -t 30 \
-b $rbl /var/qmail/bin/qmail-smtpd linuxstudy.pe.kr  /bin/true 2>&1

    tcp.smtp파일을 변경하는 방법.

    linuxstudy qmail # cat /etc/tcp.smtp
127.0.0.1:allow,RELAYCLIENT="",QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue"
:allow,QMAILQUEUE="/var/qmail/bin/simscan" 
linuxstudy qmail #

    3.2.1 [http]qmail-scanner 

    perl 로 제작된 대표적인 content 필터링 도구임. 다양한 다른 필터링 모듈(ex. clamav,spamassassin,etc)들을 추가할 수 있는 장점과 perl 로 제작되어 있기 때문에 시스템 관리자의 입맛대로 고쳐서 사용할수 있는 장점이 있다.

    -참고.) qmail-scanner-1.x 버전과 2.x 버전에서는 기본 설치 디렉토리가 /var/spool/qmailscan 에서 /var/spool/qscan 으로 변경이 되었다. 그리고 필터링 정의 파일의 이름도 변경이 되었으니 참고 하기 바란다.

  • 설치 및 사용 방법
    - 소스 다운로드 후 압축해제
    - qmail-scanner 를 위한 사용자 추가
    - 컴파일 및 설치
    - 환경 설정

    사용자 추가
Shell>groupadd qscand 
Shell>useradd -c "Qmail-Scanner Account" -g qscand  -s /bin/false qscand
qmail-scanner 설치를 위한 패키지들 설치(maildrop, 각종 Perl module)- qmail-scanner홈페이지를 참고할 것
Shell> ./configure --install yes
    설치가 마무리 되었다면 /var/qmail/bin/qmail-scanner-queue.pl -g 명령으로 DB를 생성해 주면 된다.
    * qmail-scanner 환경 파일 설정하기 및 적용
    앞에서도 이야기 했지만 qmail-scanner 1.x 버전과 qmail-scanner 2.x 버전은 스팸 필터링 정의 파일도 변화가 생겼으니 참고하기 바란다.(quarantine-attachments.txt -> quarantine-events.txt)
    필자는 2.x 버전을 기준으로 설명하겠다. 중간 중간에 1.x 버전의 차이나는 부분은 가급적 많이 언급해 보겠다.

    • 필터링 정의 파일 만들기
    이제 우리는 qmail-scanner 만을 가지고 바이러스 메일과 스팸 메일을 필터링 해 볼 것이다.
    qmail-scanner 는 quarantine-events.txt 에 스팸에 대한 규정을 적고 DB 형태로 만든 다음 메일서버에 들어오는 메시지와 비교를 해서 룰에 맞으면 걸러주는 형태로 동작을 한다.
    따라서 스팸 필터링 정의에 대한 규칙을 이해하는 것이 중요하다. quarantine-events.txt 을 열어보면 예제에 대한 상세한 내용들이 있으니 좀 더 살펴보도록 하자.

    기본적으로 Qmail-scanner의 스팸 필터링 정의 파일은 탭으로 구분된 3개의 필드로 이루어져 있다.
    파일명(또는 문자열)<TAB>파일사이즈(또는 메일헤더)<TAB>설명

    예제)quarantine-event.txt
    # 첨부 파일에 mp3가 첨부되어 있다면 필터링 하겠다는 룰이다. SIZE에 -1 되어 있다면 사이즈에 관계없이 필터링 하라는 룰이 된다.
.mp3 SIZE=-1 mp3 disallowed

# 첨부파일에 .doc 가 첨부되어 있고 사이즈가 0 인 경우에 필터링 하라는 룰이다.
.doc  SIZE=0   Zero-length corrupt viruses - ignore

# 첨부파일에 Happy99.exe 가 첨부되어 있고 첨부파일 사이즈가 10Kbyte 라면 필터링 하라는 룰이다.
Happy99.exe             SIZE=10000      Happy99 Trojan virus

# 메일헤더의 제목에 viagra 라는 문자열이 있을 경우에 필터링 하라는 룰이다.
.*viagra.*              Policy-Subject:       Spam Viagra

# 메일 헤더의 from  주소가 duma.gov.ru 가 포함된 경우에는 필터링 하라는 룰이다.
.*duma.gov.ru   Policy-MAILFROM:      Virus Dumaru

# 메일 보낸 주소가 127.0.0.5 일 경우에 필터링 하라는 룰이다.
127.0.0.5      Policy-REMOTEIPADDR:   Blocked IP from 127.0.0.5 blocked

# 스팸 메일 발송기 중에서 Bat이 들어가 있는 경우에 필터링 하라는 룰이다. 스팸 메일 발송기가 업그레이드가 늦다면 꽤 유용하게도 쓸수 있을듯 하다.
.*Bat.*            Policy-X-Mailer:             Spammailer sender
    이런 형대로 정책 파일을 만든 다음에는 /var/qmail/bin/qmail-scanner.pl -g 명령으로 반드시 DB를 갱신해 줘야 적용이 된다.
    그리고 메일 헤더를 가지고 필터링을 할때는 반드시 Policy- 으로 시작해야 되며 1.x 버전을 사용중이라면 반드시 Virus- 으로 시작해야 된다.

    3.2.2 [http]simscan 

    Simscan은 C로 작성된 스팸 필터링 도구로 qmail-scanner 와 마찬가지로 다른 스팸/바이러스 필터링 프로그램(ex. spamassassin,Clamav,etc)과 결합이 가능하다.
    C로 작성된 만큼 빠른 속도를 자랑한다. simscan과 qmail-scanner 의 장단점은 개인적으로 simscan 에 기록을 남겨두었으니 참고하기 바란다.

    • simscan 설치
    [root@db qmail]#adduser -c "simscan user" -s /dev/null simscan(simscan user ��~]성)
[root@db qmail]# wget  http://www.inter7.com/simscan/simscan-1.1.tar.gz
[root@db qmail]# tar xvfz simscan-1.1.tar.gz
[root@db qmail]# cd simscan-1.1
[root@db simscan-1.1]# ./configure && make && make install

    • simscan configure 옵션 설명
    --enable-user=유저명 
	simscan을 유저를 셋팅한다. 기본값으로 simscan
--enable-clamav=y|n
	clamav 를 이용한 스캐닝. 기본값으로 y 이다.
--enable-clamdscan=clamdscan의 PTAH
--enable-custom-smtp-reject=y|n
	바이러스 이름을 포함하여 리턴 메시지를 보내도록한다
	주의. 위의 옵션을 사용하기 위해서는 소스디렉토리/contrib/qmail-queue-custom-error.patch 의 패치를 Qmail에 해주어야 한다.
	      또한 나중에 설명되는 옵션중에 하나인 enable-dropmsg 의 값이 y이면 안된다.
--enable-per-domain=y|n
	많은 도메인에 대해서 메일서비스를 하고 있으며 각각에 대한 simscan 의 설정을 하고자 한다면 y를 택하도록 한다.
--enable-attach=y|n
	첨부파일에 대해서 체크를 할 것인지의 여부를 정한다. /var/qmail/control/ssattach 파일안에 필터링할 파일명이나 확장자를 넣어주면 된다.
--enable-spam=y|n
	스팸메일에 대한 필터링을 할 것인지에 대한 옵션이다. 스팸어세신에 의해서 status 가 YES인 메일에 대해서는 반송을 하게 될것이다.
--enable-spam-passthru=y|n
	스팸 어세신에서 붙은 status값을 무시하고 그냥 통과시키고자 할 경우에 사용한다. 이는 나중에 procmail 이나 maildrop으로
	스팸 편지함이나 별도의 디렉토리에 스팸 메일을 저장하고자 한다면 유용하게 사용될 수 있을 것이다.
--enable-spam-hits=점수
	기본값으로 10 이 셋팅되며 스팸 어세신에서 정한 값을 넣으면 될 것이다.
--enable-spamc=PTAH
	spamc 바이너리파일의 위치를 잡아준다. 자동으로 잡을것이다…^^
--enable-spamc-args
	spamc 에 필요한 옵션을 지정할 수 있다. 필자의 경우에 퍼포먼스를 위해 spamd 를 소켓을 사용하게 하였으며 소켓의 위치는 /tmp/spamd 였다.
	쌍따옴표로 지정한다는 점에 주의 하라

Ex) --enable-spamc-args=”-U /tmp/spamd” 
--enable-dropmsg=y|n (스팸 메일에 대한 메시지를 sender 에게 보내지 않겠다는 옵션이다.)
--enable-quarantinedir=디렉토리위치( 스팸,바이러스 메일을 따로 저장해둘 디렉토리를 지정한다)
--enable-received=y|n ( 메일헤더에 received를 추가할 것인지에 대한 옵션이다. 버전정보 및 처리시간이 기록되어진다.)

  • simscan 설정
    • 먼저 QMAILQUEUE 환경 변수에 simscan을 사용하도록 변경을 한다.(물론 qmail에 queue 패치가 되어 있어야 한다.)

    둘 중에 한가지를 선택해서 사용하면 되겠다.
    qmail-smtpd/run 파일에서 설정하는 방법
    vi /var/qmail/supervise/qmail-smtpd/run
#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
QMAILQUEUE="/var/qmail/bin/simscan"
export QMAILQUEUE
rbl="-r bl.spamcop.net -r rbl.linuxstudy.pe.kr"
exec /usr/local/bin/softlimit -m 100000000 \
/usr/local/bin/tcpserver -vRHl0 -x/etc/tcp.smtp.cdb \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -t 30 -b $rbl \
/var/qmail/bin/qmail-smtpd mail.linuxstudy.pe.kr \
/bin/checkpassword /bin/true 2>&1

    tcp.smtp 를 이용하는 방법
    vi  /etc/tcp.smtp
127.0.0.1:allow,RELAYCLIENT="",QMAILQUEUE="/var/qmail/bin/simscan"
:allow,QMAILQUEUE="/var/qmail/bin/simscan"

    simscan에서 첨부파일 필터링 방법( --enable-attach 옵션을 주고 설치했을 경우이다.)
    [user@mailserver user]$ cat /var/qmail/control/ssattach
    .jpg
    .mp3
    .scr
    .bat

    simscan 에서 각 도메인별로 필터링룰 설정하는 방법( --enable-per-domain 옵션을 주고 설치했을 경우이다.)
     [user@mailserver user]$ cat /var/qmail/control/simcontrol
  postmaster@example.com:clam=yes,spam=no,attach=.txt:.com
  example.com:clam=no,spam=yes,attach=.mp3
  :clam=yes,spam=yes,trophie=yes,spam_hits=20.1
    각 룰의 의미는 다음과 같다.
    - postmaster@example.com 으로 오는 메일에 대해서는 clamav로 바이러스 메일을 필터링하고 첨부파일이 .txt 또는.com에 대해 필터링 한다
    - example.com 으로 오는 메일은 spamassassin로 스팸 필터링을 하고 mp3 확장자가 있는 첨부파일에 대해서 호출한다.
    - 기본값으로 clamav 로 바이러스 메일을 필터링 하고 spamassassin 과 trophie로 스팸 필터링을 하며 spamassassin에서 부여한 점수가 20.1이 넘는 경우에는 reject한다.

    3.2.3 Qmail 패치를 통한 스팸 방지 기능 추가 

    qmail 패치를 통한 스팸방지 기능의 추가는 거의 대부분 소스 패치를 통해서 이루어지고 있어서 상세한 과정은 생략하고 주로 패치들에 대한 소개로 진행할까 한다.
    주로 qmail 의 control 파일이 추가 되거나 qmail-smtpd 에 환경변수가 추가되어 동작하는 경우가 많다.
    자세한 내용은 아래 사이트를 참고하기 바랍니다.
    [http]http://qmail.psshee.com/top.html#spam

    몇몇 쓸만한 패치들을 소개를 해본다.
    이 패치는 Qmail에 패턴 매칭을 통해서 다양한 필터링을 제공한다.
    /var/qmail/control 하위에 아래와 같은 control 파일들을 이용해서 접근을 막는다.
    badhalo,badmailfrom,mailmailfromnorelay,badmailto,badmailtonorelay

    이 패치는 RCPT TO 명령어에 대한 카운트를 제한을 하고 그 제한이 걸리면 일정 시간동안 delay를 줘서 한꺼번에 다량의 메일 전송하는것을 방지한다.
    /var/qmail/control 하위에 tarpitdelay,tarpitcount 로 제어를 할 수 있게된다.

    3.3 MDA 단에서의 필터링 

    보통 메일 박스 이전에 .qmail 또는 .qmail-default를 이용해서 다른 프로그램을 호출하여 사용한다.
    다른 방법으로는 qmail 의 run 파일을 이용해서도 가능하다.
    먼저 간단한 .qmail 의 예제를 보도록 하자.
    필자는 개인적으로 procmail 보다는 maildrop을 선호하는 편이다.

    cat>.qmail
|spamc -U /tmp/spamd | maildrop .mailfilter
    위의 내용은 메시지를 먼저 spamassassin 에 전달하여 메시지에 스팸 점수를 체크한 다음에 maildrop 으로 원하는 메일박스로 전달을 하는 형태이다.
    cat> .mailfilter

DEFAULT=/home/webmail/linuxstudy.pe.kr/tttt/Maildir/
SPAMDIR=/home/webmail/linuxstudy.pe.kr/tttt/SPAMDIR/
if (/^X-Spam-Flag: *YES/)
{
to "$SPAMDIR"
}
    위는 maildrop 에서 호출하는 .mailfilter 의 내용이다. 메일 메시지에서 X-Spam-Flag 가 YES인 경우에는 스팸 디렉토리로 메일을 저장하라는 내용이다.
    필자가 maildrop을 선호하는 이유는 아주 다양한 설정을 편하게 설정할수 있기 때문이다.
    [http]maildrop홈페이지에서 다양한 예제를 볼 수 있다. 참고하기 바란다.

    4 스팸 필터링의 새로운 패러다임 

    4.1 SPF (Sender Policy Framework) 

    SPF 는 DNS 기반의 스팸 필터링 기술이다. 메일 발송의 도메인에 대하여 실제로 정상적인 도메인에서 발송이 되었는지 query를 통해서 처리를 하는것이다.
    즉 메일 발송지의 DNS 서버에 특정레코드(TXT)에 대한 쿼리를 해서 그 결과에 따라서 정상적인 메일인지 아닌지를 구분하는 것이다.
    아래는 간단한 spf를 이용한 메일 필터링의 구조이다.
    메일 송신->메일 수신->발송지(도메인,IP,e-mail address)에 대한 Query->Query 값 리턴받음->메일서버 정책에 따라 처리

    자세한 정보는 [http]http://www.openspf.org/에서 확인해 보도록 하자.

    만약 우리의 메일 서버에서 외부로 메일을 발송을 한다면 그리고 메일을 수신하는 메일서버가 SPF 체크를 해서 필터링을 한다면 먼저 우리는 발송 서버에 대한 SPF 설정을 해줘야만
    필터링을 무사히 통과할 수 있을 것이다.

    spf설정은 네임서버에서 설정을 해주는 것으로 일단 아래의 예제를 보도록 하자
    linuxstudy.pe.kr.  IN   TXT   "v=spf1 ip4:211.189.119.187 ip4:211.189.119.186 -all"
    위의 설정은 다음과 같은 의미를 가지고 있다.
    메일을 보내는 서버의 도메인이 linuxstudy.pe.kr 이면 발송지 주소는 211.189.119.187,211.189.119.186 이며 이외의 ip에 대해서는 fail 결과를 리턴하라는 이야기이다.

    Zone파일 설명
    도메인 IN TXT "v=spf1 조건(a,mx,prt,ip4,ip6) 조건 외 정책(-all(fail),~all(softfail),+all(pass),?all(neutral))

    몇 가지 Zone 파일의 예제를 보면서 이해를 해보도록 하자.( 조건외 정책은 최소한 -all 또는 ~all 정도 셋업해주는게 좋다.)
    linuxstudy.pe.kr.               IN      A       211.189.119.186
                IN      MX 0    mail0.linuxstudy.pe.kr.
                IN      MX 1    mail1.linuxstudy.pe.kr.
                IN      MX 2    mail2.linuxstudy.pe.kr.

mail0            IN      A       211.189.119.187
mail1            IN      A       211.189.119.188
mail2            IN      A       211.189.119.189

# 메일을 보낸쪽 도메인이 linuxstudy.pe.kr 이고 ip address 가 211.189.119.187 이라면  pass 하고 그 나머지에 대해서는 fail 값을 리턴한다.
linuxstudy.pe.kr.  IN   TXT   "v=spf1 ip4:211.189.119.187-all" 

# 메일 수신서버에서 spf레코드에 대한 query 를 했을때 mx값에 설정되어 있는 Host의 IP(아래 예제를 보자면 211.189.119.187~189)에 대한 인증을 하고
# 그 이외의 ip에 대해서는 softfail 값을 리턴하라는 이야기다. 마지막이 -all 이라면 fail값을 리턴한다)
linuxstudy.pe.kr.  IN   TXT   "v=spf1 mx ~all"

# a레코드 값에 설정되어 있는 Host의 IP(즉 211.189.119.186) 일 경우에는 pass 값을 보내주고 그 이외의 값은 fail값을 리턴 하라는 이야기 이다.
linuxstudy.pe.kr.  IN   TXT   "v=spf1 a:linuxstudy.pe.kr -all"
    쉽게 설명하자면 네임서버에 우리가 메일을 발송할때는 아래와 같은 서버(or IP)를 사용하니 혹시 우리 도메인을 사용하면서 다른 IP라면 그건 가짜 입니다 라는 정보를 다른 메일서버에 알려주는 형태이다.

    지금까지는 메일을 송신했을때 spf 체크를 하는 메일서버에 메일이 잘 들어갈 수 있도록 하는 설정이었으며 
    이제는 우리가 메일을 받을 경우에 spf 를 가지고 체크를 해서 필터링을 해보는 방법을 알아보도록 하자.

    참고로 아래는 필자가 확인해 본 몇몇 포탈 사이트의 spf 설정 상황이다.
    dig TXT 도메인
nownuri.net.            21476   IN      TXT     "v=spf1 ip4:203.238.128.90 ip4:203.238.128.56 ip4:203.238.128.57 ~all"
hanmail.net.            20568   IN      TXT     "v=spf1 ip4:211.43.197.0/24 ptr ~all"
naver.com.              600     IN      TXT     "v=spf1 ip4:220.95.234.208 ip4:61.74.70.0/23 ip4:222.122.16.0/24 ip4:220.73.156.0/24 ip4:211.218.150.0/24 ~all"
chol.com.               3600    IN      TXT     "v=spf1 ip4:203.252.1.0/24 ip4:203.252.3.0/24 ip4:164.124.191.0/24 ip4:210.120.128.23 ~all"
empas.com.              3600    IN      TXT     "v=spf1 ip4:61.97.66.0/24 ip4:61.97.67.0/24 ip4:61.97.70.0/24 ip4:61.97.72.0/24 ptr -all"

    먼저 spf 레코드 체크를 위한 몇가지 방법을 알아보도록 하자.
    편하게 할 수 있는 방법 몇가지를 소개해 본다.

    4.1.1 qmail 에 spf 패치를 하여 필터링를 하는 방법 

    [http]http://www.saout.de/misc/spf/에서 qmail-spf 패치를 받아서 spf 패치 이후 Qmail을 재설치 한다.
    tar xvfz qmail-1.03.tar.gz
cd qmail-1.03
patch -p1<qmail-spf-rc5.patch
make && make setup check
    참고로 spf패치를 하게 되면 spfquery 라는 바이너리 파일이 생성이 되고 간단하게 테스트 spf 테스트를 해볼 수 있다.
    기본 사용법: spfquery 메일쪽IP 메일도메인 메일주소
    [root@db qmail-1.03_spf]# ./spfquery 211.189.119.186 linuxstudy.pe.kr root@linuxstudy.pe.kr
result=pass
Received-SPF: pass (localhost: SPF record at linuxstudy.pe.kr designates 211.189.119.186 as permitted sender)
[root@db qmail-1.03_spf]# 
필자는 네임서버에 spf설정을 해두었기 때문에 return 값이 pass 로 나온다.

[root@db qmail-1.03_spf]# ./spfquery 211.189.119.190 linuxstudy.pe.kr root@linuxstudy.pe.kr                 
result=fail: See http://spf.pobox.com/why.html?sender=root%40linuxstudy.pe.kr&ip=211.189.119.190&receiver=localhost
Received-SPF: fail (localhost: SPF record at linuxstudy.pe.kr does not designate 211.189.119.190 as permitted sender)
[root@db qmail-1.03_spf]# 
메일 보낸쪽 IP address를 약간 변조를 해서 query 를 날려보았다.
결과를 보면 알겠지만 fail 값이 리턴이 되었다. 왜냐면 필자의 네임서버에서는 186,187번 IP에 대해서만 spf 설정을 해두었기 때문이다.
    위의 원리로 변조되어 들어오는 메일을 필터링 할수 있는 것이다.

    이제 spf 패치가 된 qmail의 설정을 살펴보도록 하자.
    다른 패치와 비슷하게 control 파일을 이용하도록 되어 있다.
    cat>/var/qmail/control/spfbehavior<<EOF
3
EOF
    값은 0~6까지 줄수 있으며 아래와 같은 레벨로 필터링을 할 수 있다.
    0: spf 설정에 대한 쿼리를 하지 않으며 spf 결과에 대한 헤더를 생성하지 않는다. 
    1: 단지 spf 쿼리에 대한 헤더만 생성하되 블럭은 하지 않는다.
    2: spf쿼리에 문제가 있을경우 dns 에러와 함게 reject한다.
    3: spf 쿼리 결과가 fail 일 경우에 deny한다.
    4: spf 쿼리 결과가 softfail 일 경우에 deny한다.
    5: spf 쿼리 결과가 neutral 일 경우에 deny한다.
    6: spf 쿼리 결과가 pass가 아닐 경우에 deny한다.

    나머지 몇개의 control파일이 더 있는데 생략한다.

    4.1.2 spamassassin 을 이용하여 필터링을 하는 방법. 

    spamassassin 을 이용하는 방법은 아주 쉽다.
    spamassassin3.x 버전 부터는 기본적으로 spfquery 를 사용할 수 있도록 되어 있다.
    spamassassin에서 spf를 이용하기 위해서는 spf perl 라이브러리가 필요하다.
    [http]http://www.openspf.org/Implementations 에서 Mail::SPF 모듈을 다운로드 하여 설치하도록 하자.
    Mail::SPF 을 설치하기 위해서는 아래와 같은 다른 perl 모듈도 설치를 해줘야 한다.
    Module-Build 0.2805
    Test-More
    Net-DNS-Resolver-Programmable 0.002.1
    위의 모듈을 모두 설치한 다음에 Mail::SPF 모듈을 설치하면 된다.
    설치하는 방법은 다소 내용이 길어질 수 있어서 생략하도록 하겠다.
    Mail::SPF 모듈이 설치가 되었다면 spamassassin 설정 파일을 열어서 SPF 체크를 하도록 하면 된다.
    vi /etc/mail/spamassassin/init.pre
loadplugin Mail::SpamAssassin::Plugin::SPF
    아마 3.x 버전을 설치했다면 아마 기본적으로 설정이 되어 있을 것이다.
    spamassassin은 실제 메일 메시지에 대한 reject를 하는 시스템은 아니고 score를 부여하는 역할만 하므로
    만약 smtpd 단에서 필터링을 하기를 원한다면 위에서 말한 qmail에 패치를 하여 사용을 하는것이 좋을 것이다.

    4.2 DKIM(Domain keys identified mail) 

    Domain key 는 현재 대표적으로 Yahoo에서 사용하는 메일 인증 시스템으로 
    기본 원리는 SPF처럼 네임서버에 등록된 정보를 확인하는 구조를 가지고 있다.
    그러나 SPF가 IP기반의 인증을 하는 반면에 Domain key는 digital sign을 하는 형태라서 메일의 변조 여부까지 확인할 수 있다.

    기본 구조는 다음과 같다
    메일 발송서버->메일 수신 서버->메일헤더에 sign 되어진 값을가지고 다시 메일을 발송한 도메인 네임서버에 query->리턴된 public key를 이용하여 메일 메시지 검증

    *private key 및 public key, signature 이해하기
    Domain key가 어떻게 동작하는지 원리를 잠깐 살펴보도록 하자.
    [root@db ~]# cat test.txt 
ajdfasdf
[root@db ~]# openssl dgst -sign /etc/domainkeys/linuxstudy.pe.kr/default -sha1<test.txt >sign.file
[root@db ~]# openssl dgst -verify /etc/domainkeys/linuxstudy.pe.kr/rsa.public -sha1 -signature sign.file <test.txt 
Verified OK

test.txt 파일을 약간 변경해서 검증할 때
[root@db ~]# openssl dgst -verify /etc/domainkeys/linuxstudy.pe.kr/rsa.public -sha1 -signature sign.file <test.txt 
Verification Failure
    설명) 먼저 메일 발신 서버에서는 test.txt(메일메시지)에 private key를 이용해서 sign을 하고 메일 메시지에 sign.file을 더 덧붙여서 메일을 전송한다.
    그리고 메일 수신서버에서는 메일 메시지에 첨부되어 있는 sign 과 네임 서버에 query를 하여 돌아온 public key 를 이용해서 그 메일의 변조 유무를 체크하는것이다.
    만약 test.txt파일이 sign 되는 당시와 변경 사항이 있다면 검증 결과는 Failure 를 리턴한다.

    • Qmail에 Domain key 패치하여 설치하기
    [http]티니님이 작성한 Domain key 설정법을 참고하기 바란다.

    • SPF 와 Domain key 비교(어디까지나 필자의 생각다 :-) )
    SPFDomain key
    인증방식IP기반RSA 이중키로부터 만들어진Digital Signature
    구현방식DNS에 등록된 IP와 실제 메일 발신 IP대조발신자의 서명을 검사
    장점적용하기 편리함(네임서버에 등록만 해주면 됨안전하고 신뢰성이 높음
    단점위/변조 가능성이 있다(IP spoofing)적용하기가 좀 어려움

    5 맺으며 

    스팸 메일 필터링에 대한 전반적인 이해를 위해 글을 시작했으나 생각보다 설명하고 싶은게 너무 많아
    전부 쓰기에는 너무 내용이 방대해질 듯 하여 많은 부분을 생략 했습니다.(설치과정이나 실제 운영하는 방법? 등등)
    따라서 좀 내용이 어려울 수도 있다는 생각이 드는군요..^^;
    이 문서가 지속적으로 업데이트 될수 있도록 많은 의견들을 바라며...
    2007년 9월4일

    By stone92


    :

    [qmail] clamav overview

    ITWeb/서버관리 2012. 5. 14. 21:14

    [원본링크]

    http://wiki.clamav.net/bin/view/Main/ClamOverview

    [원본글]

    Overview

    ClamAV is an anti-malware application that scans files for viruses, worms, spyware, and other forms of malware. Optimized for automated e-mail scanning on mail gateways, you can use ClamAV with SMTP, POP3, and IMAP mail servers. ClamAV also includes provisions for on-demand scans as well as test files for verifying the installation. Its major components include:
    * libclamav
    * clamd
    * clamdscan
    * clamscan
    * freshclam
    * sigtool
    * clamav-milter
    * clamuko
    * clamconf

    libclamav

    Libclamav is the shared library for clamav and is the virus-scanning engine.

    The library is thread-safe, and automatically recognizes and scans archives. Scanning is very fast. Libclamav can add virus protection to software other than ClamAV.

    clamd

    Clamd is a scalable, multi-threaded daemon.

    Clamd uses sockets, streams, and file pointers so that it can be used thousands of times an hour and perform file and mail attachment scans as needed. Clamd uses the clamd.conf configuration file.

    clamdscan

    Clamdscan is a command line scanner that uses clamd.

    When you need an on-demand scan and clamd is running, use clamdscan for the best performance. Clamdscan uses the running daemon and does not have to wait for ClamAV to start.

    clamscan

    Clamscan is the command line scanner that uses the ClamAV database.

    Use clamscan to scan files on an infrequent basis or when when the clamd daemon is not running. Clamscan starts clam and the clam startup (loading database, etc.) slows overall detection time. For routine scans, use clamdscan.

    freshclam

    Freshclam is the ClamAV virus database-updating tool that runs either as a daemon or on the command line to update the ClamAV signature database.

    Freshclam uses the freshclam.conf configuration file. It relies on an Internet connection to update the signature database, but runs in a variety of ways to compensate for intermittent connections. For installations with no connection, many distributions provide a clamav-data file and the package is not automatically updated, once installed.

    sigtool

    Sigtool is the ClamAV antivirus database manipulation tool.

    It is for advanced users who intend to write their own signatures. Refer to the signatures portion of the documentation for more information about sigtool.

    clamav-milter

    Nigel Horne's clamav-milter is a very efficient email scanner.

    It is a plugin for Sendmail and Postfix that enables those programs to scan email.

    clamuko

    Clamuko is a special thread in clamd that performs on-access scans on Linux and FreeBSD. Clamuko shares the virus database with the clamd daemon.

    clamconf

    Clamconf is a program that runs from a command line.

    It displays information about your configuration. It is useful during ClamAV debugging. When you file a bug report, the ClamAV engineering team will often ask for clamconf output.


    :

    [qmail] knetqmail 패키지 파일.

    ITWeb/서버관리 2012. 5. 14. 21:00

    패키지 파일 공유 합니다.

    원본은 아래 링크에서 받으실 수 있습니다.

    http://mail.linuxstudy.pe.kr/download/knetqmail-0.0.1-5.src.rpm


    knetqmail-0.0.1-5.src.rpm


    :

    [qmail] control 파일 설명

    ITWeb/서버관리 2012. 5. 14. 19:59

    [원본링크]

    http://qmail.kldp.net/wiki/wiki.php/QmailControl%ED%8C%8C%EC%9D%BC%EC%84%A4%EB%AA%85

    [원본글]

    qmail은 하나의 전체 설정 파일을 사용하지 않고 /var/qmail/control/ 안에 다음과 같이 분리되고 각각의 기능을 하는 설정파일들을 사용합니다. 각 설정 파일들의 목적은 매우 뚜렷하고 이해와 수정이 용이합니다. 다음 콘트롤 파일들이 모두 존재하고 있어야 하는 것은 아니며, 필요에 따라 만들어 줍니다. -- 임은재 2004-04-15 21:25:37


    정의
    • bounce : 어떤 이유로든 메일이 되돌려 질때 (from: 헤더가 있는 경우)
    • double bounce : bounce 한 메일이 다시 되돌아 오는 경우
    • me 는 FQDN으로 명기한 도메인 명이 적혀있는 me 라는 파일을 의미합니다.
    Control 파일Default사용설명
    rcpthosts없음qmail-smtpd메일을 받아들일 도메인(들)
    badmailfrom없음qmail-smtpd이 메일주소로 부터 오는 메일은 553 sorry, your envelope sender is in my badmailfrom list 라는 메세지와 함께 무조건 User unknown으로 bounce 한다.
    bouncefromMAILER-DAEMONqmail-sendbounce 할때 메일의 from: 헤더에 들어갈 유저 이름.
    bouncehostmeqmail-sendbounce 할때 메일의 from: 헤더에 들어갈 호스트 이름.
    concurrencylocal10qmail-send로컬 메일 배달시 qmail-send의 동시 최대 프로세스의 수를 조절
    concurrencyremote20qmail-send리모트 메일 배달시의 qmail-send 동시 최대 프로세스 수를 조절
    databytes0qmail-smtpd메일의 최대 크기(byte, 0 = 무제한)
    doublebouncehostmeqmail-senddouble bounce 된 메일을 수신할 호스트
    doublebouncetopostmasterqmail-senddouble bounce 된 메일을 받을 유저
    envnoathostmeqmail-send메일주소에 @ 가 명시되지 않았을 경우의 디폴트 도메인 이름
    helohostmeqmail-remoteSMTP HELO 명령에 표시될 호스트 이름
    localiphostmeqmail-smtpd로컬 IP 주소가 대체될 이름
    localsmeqmail-send로컬로 인식하며 배달할 도메인(들)
    me시스템의 FQDN.다른 콘트롤 파일을 위해 쓰임
    morercpthosts없음qmail-smtpd두번째 rcpthosts 파일
    percenthack없음qmail-send"%"-형식의 릴레이를 사용 할 수 있는 도메인
    plusdomainmeqmail-injectdomain substituted for trailing "+"
    qmqpservers없음qmail-qmqpcQMQP 서버의 IP 주소
    queuelifetime604800qmail-send메세지가 메일 큐안에 머물 수 있는 시간 (초단위)
    smtpgreetingmeqmail-smtpdSMTP greeting message
    smtproutes없음qmail-remoteartificial SMTP routes
    timeoutconnect60qmail-remoteSMTP 연결 대기 시간 (초)
    timeoutremote1200qmail-remote리모트 서버 연결 대기 시간 (초)
    timeoutsmtpd1200qmail-smtpdSMTP client 대기 시간 (초)
    virtualdomains없음qmail-send가상 도메인들과 유저들
    defaultdomainmeqmail-inject기본 도메인 이름
    defaulthostmeqmail-inject기본 호스트 이름
    idhostmeqmail-injectMessage-ID 에 사용될 호스트 이름


    :
    ◀ PREV : [1] : [2] : [3] : NEXT ▶

    티스토리툴바