www.freesoftwaremaga magazine.com.


RE а


= | Tew СЕЛ Е FIL | | R 7 ы iM



“К ы лыы e g ый. HOW ТО GE | | "m. B | із Те га ты Т. іш PROC 1 ТТЕ EY







ОСІ, leading supplier of Object Oriented technology training, has been B . educational services for over 12 years.

to oe осоре ("concepts endure, t tools change” is our philosophy).

OCI's extensive curricula of over 50 hands-on workshops is delivered to corporations and individuals throughout the U.S. and internationally.

Curriculum-Based, Comprehensive, Pragmatic *Standards-based/vendor-neutral

*Modular and Progressive sHeal-world examples

Customized Training Programs *Skill/Gap Analysis

Hipp «Training Plans

Re-Skill Existing Developers | sIntro, Intermediate, and Adv. Levels #00-transitional curriculum

Win PIES: TE 1 Р, Enterprise. i | dm Knowledge Transfer Professionals ———— sActive practitioners/mentors sExcellent client ratings

To learn more about OCI's кешш Mentoring einforcement following training Educational Services, »Investment protection

Flexible Delivery Models sOn/Off Site

sDay/Evening sPublic/Private

Product Development - Consulting - Educational Services

visit us at www.ociweb.com

Object Computing, Inc. (OCI) (ei 4 іші

St. Louis, MO Headquarters: --1(314) 579-0066 ы Phoenix, AZ Office: +1(480) 752-0042 A e

www.ociweb.com бекет COMPUTING, INC.

Center of the System Administration www.shbin.org

Open Source Software, which originally developed out of the passion of hackers and geeks, has now become the basis of real

business solutions. Low TCO, high reliability,

security and performance of Open Source software make the shift from "closed" technologies and standards to modern, open solutions inevitable.

+7 8793 365584

CSA offers development, deployment and support services based on Open Source technologies and standards.

Up-to-date solutions for small and medium size businesses are available for you today with guaranteed full 24/7 support and no license fees.

Today. being closed means being left behind

Desigrand by ITA “ire be”


Issue 2, March 2005

EDITORIAL Your part-time job 7

The trials and tribulations of being a “computer person”


The history and future of SMTP 10 by Kirk Strauser

SMTP’s adaptations to a hostile internet

Filtering spam with postfix 13 by Kirk Strauser Effective ways to reduce unwelcome mail

Mail servers: resolving the identity crisis 18 by John Locke

How to get Dspam, Postfix, and Procmail to play well together


Poking at iTunes 27 by Chris J. Karr

A developer’s guide to the iTunes platform

Why free IT management tools are gaining traction 34 by Will Winkelstein

Enterprises are increasingly receptive to free software alternatives for IT management

Case study: Mythic Beasts 37 by Tony Mobily

A small company specialised in Linux servers and amazing support

Interview with Bernhard Reiter at aKademy 40 by Tom Chance

What we can do to promote the future of free software

4 Free Software Magazine n. 2, March 2005

larc 43 by John Locke Creating strong memorable passwords using mnemonic devices and word lists

: а: 49 by Aaron Krowne Dismantling fear, uncertainty, and doubt, aimed at Wikipedia and other free knowledge resources

Ше 57 Бу Тот Сһапсе Part one: promoting community projects іп the marketplace

63 by Maureen O'Sullivan Don’t we have enough laws already? : : e z 36 67 by David М. Berry, Giles Moss A manifesto for free/libre culture 73 by Richard Stallman Selected entries from Бісһага”5 ( ), from November

2004 to December 2004





Losing track of things?

There |


s a better way.

Enterprise-grade issue tracking. Open source customizability.

Commercial support.

Download it now!

Best Practical Solutions offers training, support and custom development services. Check out our website or contact us for details.

| ҚЗ yy BEST www.bestpractical.com PICE oaan sales@bestpractical.com ; " PRACTICAL


== cing a “computer person" these days is a very stressful business. Forget about angry | ) | | customers, missed deadlines, unreasonable bosses and co-workers, shrinking wages, "A etc. Those are just things you get used to after a while. - | For me, the real stress starts when I get out of the office, and I turn on my phone. I get the first call and I think: I wonder who that'll be; maybe Dave (yes, Dave Guard, our editor), maybe he wants to go and have a beer with me (he complained “But I don’t drink beer?" when he edited this editorial...). But no, it’s my cousin: his computer is behaving “oddly”, and his internet connection has slowed down terribly (yes, he's sending spam... and he doesn't know it yet). He begs me to go and have a look at it. I try to explain to him that even though I am a computer person, I don't know anything about viruses on Windows XP. The begging goes on and on, until I give in and say with a sigh: all right, ГЇЇ come and have a look at it. Andrea and I (he's a computer person too) worked out that, even for us, fixing a Windows XP machine takes about 8 hours, because we don't do it as a job and we're not fully equipped for it. To reinstall a system you need to back the previous information up, reinstall the system, install all the drivers (if the driver CDs ever existed), install all the patches and service packs, install the software that was previously installed, answer the question “Why is Office is not part of Windows?!?", discover that they had a crucial, weird device XYZ with no drivers available, and so on. This process is very stressful, and can go very wrong (in fact, I know it never goes smoothly). And after all of this you need to pray that doing, what you've spent hours doing, has solved the problem. Now, I have a big family: 10 aunts and uncles, 25 cousins (including the ones once removed etc.), and roughly another 15 relatives who ГЇЇ put in the “other” category. That's 50 people, and on average, they'll have two “serious problems" with their computers every year. That's 100 “major incidents" (with all the begging and everything) per year. A year is 365 days. 13 of them are public holidays. 104 are Saturdays and Sundays. 10 days for sick leave. So I’m left with 238 working days. This means that if I were to respond to all of the emergency calls I receive, I would spend nearly half of my working life reinstalling Windows XP for my relatives. I obviously don't do that (otherwise, you wouldn't be reading this magazine). But saying “по” to your relatives at least twice a week is awkward. I'm writing this editorial after discovering that Microsoft is planning to buy Sybari Software, and will (probably) make more money off computer viruses. My own mother's computer is infected at the moment, and she is some 14000 Km away - I am powerless, and I can't even fix it by remote because the virus is using all her bandwidth. I feel angry, because I can't stop thinking that if Microsoft makes real money thanks to viruses, they'll never make their systems secure (and you know they could). And that really is a problem. This month's issue is about spam, which is a problem closely related to viruses and Windows security. I'd have loved to publish an article entitled "How to solve the spam problem - forever", but I can't because such a solution doesn't exist yet. I do look forward to the day when I can publish such an article, but until that day comes, ГІ present you with some of the best ways we can defend ourselves against the invasion of spam. Good luck...

Copyright information (c) by Tony Mobily Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved.

Free Software Magazine n. 2, March 2005

EDITOR IN CHIEF Tony Mobily .mobi1ye)


Clare James (c. james)

Pancrazio De Машо (p.demauroe) Gianluca Insolvibile (g.insolvibilee)


(a. dymitrhawkesQ)

Dymitr Hawkes

Dave Guard (a.guarae)


Gianluca Pignalberi (ТАТЕХ class and magazine generation) (g.pignalberié@) Gian Maria Ricci (RTF to XML converter using VBA) (gm.ricci@)


Alan Sprecacenere (Web, cover and advertising design) (a.sprecacenere@) Tony Mobily, Gianluca Pignalberi, Alan design)

Sprecacenere (Magazine


Donald E. Knuth, Leslie Lamport, People at ТЕХ Users Group TUG (http: //www.tug.org)

Every listed person is con-

tactable by email. Please just add freesoftwaremagazine.com tO the

person’s username in parentheses.

For copyright information about the con- tents of Free Software Magazine, please see the section “Copyright information” at the end of each article.


ртт айдай раа гаар

Mil AR | CD Software 20 умі. Java» CIC++ JavaScript + NET |

oO ы; T > = 1 F- = [UU ED ID Me Mies ERN ТЕЬ. РЕНЕА [i AEI DEM UOUOPZAORLCEECS PE DELE TEM) "ТЕРІ... ља - = ғ DIDIT САНАГА ATE SCAR USA; ЕП ЗЫ —— LE шынын еді = La rw] з "-— 1" “/ LE CN = ay ж. ® - = аі , p ——` шир =


“е. 1000 2, ^

j | “ай ҒАММ j foe Seatict uestes "

Powortel Eovircnme = ТАЛЕ 24.1 Dara 6Mireng i dawn

VMPC Меларт Ваа іе Lizi

"аяғы 1 Шалка ith РИНЕ Жарын



Testing Embedded T ctt

Des T Patterns i іп "En

www.shop.software.com.pl = ———— __ ү

| | | (6 Б

MTP is an abbreviation for “Simple Mail Trans-

fer Protocol’, and is the standard internet pro-

tocol for sending email from one system to an-

other. Although the word “simple” belies the in- herent complexity of the protocol, SMTP has proved to be a remarkably robust, useful, and successful standard. The design decisions that made it so useful, though, have given spammers and infectious code an easy way to spread their unwanted messages. Its recent evolution reflects the tug-of- war between those unsavory players and the administrators who want to protect their systems and their users.

Early history

When Jonathan Postel wrote the SMTP definition RFC 821 in 1982, the internet was minuscule in comparison with to- day’s pervasive mix of commercial, governmental, and pri- vate interests. At that time, it mostly comprised a small col- lection of military installations, universities, and corporate research laboratories. Connections were slow and unreli- able, and the number of hosts was small enough that all of the participants could recognize each other. In this early set- ting, SMTP’s emphasis on reliability instead of security was reasonable and contributed to its wide adoption. Most users helped each other by configuring their mail servers as “open relays”. That meant that each cooperative host would accept mail meant for other systems and relay it toward its final destination. This way, email transfer on the fledgling inter- net stood a reasonable chance of eventual delivery. Most

administrators were happy to help their peers and receive their help in return.

Spam has existed since at least 1978, when an eager DEC sales representative sent an announcement of a product demonstration to a couple hundred recipients. The resulting outcry was sufficient to dissuade most users from repeating the experiment. This changed in the late 1990s: millions of individuals discovered the internet and signed up for inex- pensive personal accounts and advertisers found a large and willing audience in this new medium.

Spam becomes a problem

The helpful nature of open relays was among the first vic- tims of the spam influx. In the young commercial internet, high-speed connections were prohibitively expensive for in- dividuals and small businesses. Spammers quickly learned that it was easy to send a small number of messages with recipient lists thousands of entries long to helpful corpo- rate servers, which would happily relay those messages to their targets. Administrators noticed sudden spikes in their metered service bills (and in the number of complaints) and realized that they could no longer help their peers without incurring significant monetary costs and bad will.

First steps to secure the internet

Although the nature of the problem was clear, the solutions were not. The SMTP standard, which was designed with

10 Free Software Magazine n. 2, March 2005


reliability as a key feature, had to be re-implemented to pur- posefully discard certain, recognized messages. This was a foreign idea and no one was sure how to proceed.

The first step was to close the open relays. Administrators argued loudly, and at great length, whether this was a nec- essary move, or even a good one at all. In the end though, it was universally agreed that the trusting nature of the old internet was dead, and in fact harmful in the current setting. Some users took this idea a step farther and decided that they would not only close their own systems, but would no longer accept messages from other open relays. They even- tually began to share their lists of those relays with peers by adding specially formatted entries to their domain name servers and allowing their neighbors to query their servers for this data. This was the beginning of the first “DNS blackhole lists”, and they were highly controversial. For example, administrators debated whether it was acceptable to actively test remote servers to see if they were open re- lays, and discussed which procedures a system administra- tor should follow to remove his or her host from the list after correcting the problem.

The first victims of “collateral damage” were those whose mail servers were blocked through no fault of their own. This often happened when over-zealous blacklist operators added entire blocks of addresses to their lists, rather than just the offending addresses. As one group of operators ar- gued that the lists should err on the side of caution to pre- vent these problems, others believed that this would put ex- tra pressure on the open relay administrators. In one form or another, this debate continues.

New threats

Huge numbers of people with very little computer-security experience came online, often with increasingly cheap, per- manent high-speed connections. As a result, a new epidemic spread across the internet - most visibly as email worms. They infected poorly secured computers which then became the transmitters for new copies of those worms. Many of these propagate through the popular email clients on Mi- crosoft Windows systems and move outward by emailing copies of themselves to people in the infected computer's address book. Many such infections are noticeable because they can overwhelm a machine and its internet connection to the point where both become useless to their end user,

who then typically pay a business, or get a knowledgeable friend, to remove the worm.

There are more insidious infections which spread amongst computers rapidly. They then lie dormant to avoid draw- ing attention to themselves and wait for instructions from another system. A “botnet” is a collection of computers so compromised. Spammers often use botnets as a widely dis- tributed means for sending large amounts of email.

Fighting back

A recent and popular response to these problems is sender authentication. That is, many mail servers now look for proof that a computer attempting to send email to them is actually authorized to do so. For example, Sender Policy Framework (or SPF) is centered around another specialized DNS record that lists the servers authorized to transmit email from a given domain. Тһе adminis- trator of example.com may list “smtp.example.com” and "mail.example.com" as the outbound mail servers for that domain. When an SPF-aware server receives a message from a user with an example.com email address, it com- pares the name of the computer attempting to send that mes- sage with those names. If it isn't on the list, then the mes- sage can reasonably be assumed to be a forgery and may be discarded. Several proposals exist that are similar to SPF, such as Yahoo!'s DomainKeys, but all work in essentially the same way.

Another common measure is simply to enforce the SMTP definition and reject messages that do not adhere to it. This is highly effective because few, if any, worms or spam trans- mitters bother to comply with the standards. They often take shortcuts when generating the email address that a mes- sage claims to originate from, or lie about their own iden- tity. Some seem to completely ignore the standard in hopes that the receiving system will blindly process their load any- way. The methods of enforcing the protocol must be imple- mented incrementally, though, as many old but legitimate mail servers may also fail to meet some of the more pedan- tic requirements. Ап old rule of networking is to “Ве liberal in what you accept". Sadly, spammers seem to be on the brink of making that impossible.

One of the positive side effects of sender authentication and standards enforcement is that email senders are being com- pelled to correctly identify themselves before they are al-

Free Software Magazine n. 2, March 2005 11


lowed to transfer their messages. New DNS blackhole lists, able to narrowly identify specific senders, will be possible once a critical mass of servers have implemented such mea- sures. This solution should neatly avoid the old problem of collateral damage, as well as greatly reducing the scope of the blackhole lists themselves.

Regardless, some spam and worms will always make it through the tightest of filters. To this end, a new class of in- telligent, self-learning filtering software does a good job of identifying the remaining unwanted messages. Good, free antivirus programs also perform well at removing worm- infected messages before they can reach vulnerable email clients.

One of the newer and more exotic approaches is known as greylisting. The idea is simple: receiving mail servers make senders wait for a small amount of time before they are al- lowed to transmit email to a recipient they’ve never sent to before. This serves two purposes. First, very few worms, spam senders, or botnet machines actually have the patience to try again later (or the resources to remember which ad- dresses should be retried). If their first attempt at delivering a message fails, they give up and move on to the next des- tination. Second, by increasing the effective length of time it takes for a spammer to send a message, a mail server also increases the chances that a DNS blackhole list will add that rogue server before it can deliver that message. Few meth- ods can compete with the simple elegance of greylisting, and it offers to many frustrated administrators the hope that the war against unwanted email can be won.

Finally, some administrators have responded to the over- whelming loads which are sometimes sent by botnets by blocking certain operating systems. Almost no one runs a legitimate mail server on Window 98, for example. There- fore, configuring a firewall to block incoming SMTP con- nections from Windows 98 machines (assuming all of your desktop clients use newer version of Windows, or Mac or Unix desktops) can reduce the number of unwanted mes- sages from hijacked computers.

The future

SMTP has a long and illustrious past. It’s one of the “killer applications” that led to the explosive growth of the inter- net. From love letters to stock transactions to family pho- tos, countless users send an endless variety of messages to

each other every day. Email in its current form is going to be around for a long time, but will likely undergo a series of incremental updates. For example, client authentication (which didn’t exist when the SMTP RFC was written) has almost completely replaced open relaying, and some mail servers now use SSL certificates to verify another server’s identity.

However, the future of SMTP depends largely upon those who abuse it. It currently provides a reliable, fault-tolerant system of email delivery. Any changes are likely to work against this reputation, as they would add to the complex- ity of the protocol. Several proposed alternatives have come and gone, and there are no widely accepted proposals that stand a reasonable chance of coming into common use. Only time will tell...


[1] RFC 821 - Simple Mail Transfer Protocol (http://www.faqs.org/rfcs/rfc82 1.html)

[2] Reaction to the БЕС spam of 1978


[3] Wikipedia entry on DNSBLs (http://en. wikipedia.org/wiki/DNSBL)

[4] Sender Policy Framework (http://spf.pobox.com/)

[5] DomainKeys: Proving and Protecting Email Sender Identity (http://antispam. yahoo.com/domainkeys)

Copyright information

© 2005 by Kirk Strauser

This article is made available under the “Attribution- Share-alike" Creative Commons License 2.0 available from http://creativecommons.org/licenses/by-sa/2.0/.

About the author

12 Free Software Magazine n. 2, March 2005

EA f уоп аге responsible for maintaining ап internet- connected mail-server, then you have, no doubt, come to hate spam and the waste of resources which

LL comes with it. When I first decided to lock down

my own mail-server, I found many resources that helped

in dealing with these unwanted messages. Each of them contained a trick or two, however very few of them were presented in the context of running a real server, and none of them demonstrated an entire filtering framework. In the end I created my own set of rules from the bits and pieces

I found, and months of experimentation and fine-tuning re-

sulted in the system detailed in this article.

This article will show you how to configure a Postfix mail- server in order to reject the wide majority of unwanted incoming "junk email", whether they contain unsolicited commercial email (UCE), viruses, or worms. Although my examples are specific to Postfix, the concepts are generic and can be applied to any system that can be configured at this level of detail.

For a real world example, ГИ use my server's configuration details:

Tab. 1: My server's configuration details

Hostname Kanga.honeypot.net Public address Postfix configuration path /usr/local/etc/postfix


This configuration was written with two primary rules in mind:

1. Safety is important above all else. That is, I would much rather incorrectly allow an unwanted message through my system than reject a legitimate message.

2. The system had to scale well. A perfect system that uses all of my server's processing power at moderate workloads is not useful.

To these ends, several checks - that may have reduced the number of "false negatives" (messages that should have been rejected but were not) at the cost of increasing the number of "false positives" (legitimate messages that were incorrectly rejected) - were avoided. The more resource- intensive tests were moved toward the end of the configura- tion. This way, the quick checks at the beginning eliminated the majority of UCE so that the longer tests had a relatively small amount of traffic to examine.

Free Software Magazine n. 2, March 2005 13


HELO restrictions

When aclient system connects to a mail-server, it’s required to identity itself using the SMTP HELO command. Many viruses and spammers skip this step altogether, either by sending impossibly invalid information, or lying and saying that they are one of your own trusted systems - in the hopes that they will be granted undeserved access. The first step in the filtering pipeline, then, is to reject connections from clients that are severely mis-configured or that are deliber- ately attempting to circumvent your security. Given their simplicity, these tests are far more effective than might be imagined, and they were implemented in my main.cf file with this settings block:

1 smtpd_delay_reject = yes

2 smtpd helo required = yes

3 smtpd helo restrictions =

4 permit mynetworks,

5 check helo access hash:/usr/local/etc/postfix/helo access,

6 reject non fqdn hostname,

7 reject_invalid_hostname,

8 permit

Line 1 is a fix for certain broken (but popular) clients, and is required in able to use HELO filtering at all. The second line rejects mail from any system that fails to identify itself. Line 4 tells Postfix to accept connections from any machines on my local network. The next line references an external hash table that contains a set of black- and whitelisted entries; mine looks like this:

woozle. honeypot .net OK

honeypot.net REJECT You are not me. Shoo! REJECT You are not me. Shoo!

The first line in the table explicitly allows connections from my laptop so that I can send mail when connected through an external network. At this point Postfix has already been told to accept connections from all of my local machines and my short list of remote machines, so any other computer in the world that identifies itself as one of my systems is lying. Since I’m not particularly interested in mail from deceptive systems, those connections were flatly rejected. Lines 6 through 8 complete this stage by rejecting con- nections from hosts that identify themselves in bla- tantly incorrect ways, such as “MAILSERVER” and “HOST@ 192. 168!aol.com”.

Some administrators also use the reject_unknown_hostname option to ignore servers whose hostnames can’t be resolved, but in my experience this causes too many false positives from legitimate systems with transient DNS problems or other harmless issues.

You can test the effect of these rules, without activating them on a live system, by using the warn_if_re ject op- tion to cause Postfix to send debugging information to your maillog without actually processing them. For example, line 6 could be replaced with:

warn_if_reject, reject_non_fqdn_hostname,

This way the results can be observed without the risk of inadvertently getting false positives.

Sender restrictions

The next step is to reject invalid senders with these options:

9 smtpd_sender_restrictions =

10 permit_sasl_authenticated,

Li permit_mynetworks,

12 reject_non_fqdn_sender,

13 reject_unknown_sender_domain, 14 permit

Given their simplicity, these tests are far more effective than might be imagined

Lines 10 and 11 allow clients that have authenticated with a username and password or Kerberos ticket, or who are hosts on my local network, to continue onward. Lines 12 and 13 work similarly lines 6 and 7 in the “HELO restric- tions” section; if the sender’s email address is malformed or provably nonexistent, then there’s no reason to accept mail from them. The next line allows every other message to move on to the next phase of filtering.

Recipient restrictions and expensive tests

By this time, it’s clear that the client machine isn’t com- pletely mis-configured and that the sender stands a reason- able chance of being legitimate. The final step is to see that

14 Free Software Magazine n. 2, March 2005


the client has permission to send to the given recipient and to apply the remaining “expensive” tests to the small num- ber of messages that have made it this far. Here’s how I do it:

15 smtpd_recipient_restrictions =

16 reject_unauth_pipelining, 17 reject_non_fqdn_recipient, 18 reject_unknown_recipient_domain,

19 permit_mynetworks,

20 permit_sasl_authenticated,

21 reject_unauth_destination,

22 check_sender_access hash:/usr/local/etc/postfix/sender access,

23 check recipient access hash:/usr/local/etc/postfix/recipient access,

24 check helo access hash:/usr/local/etc/postfix/secondary mx access,

25 reject_rbl_client relays.ordb.org,

26 reject_rbl_client list.dsbl.org,

27 reject rbl client sbl-xbl.spamhaus.org,

28 check policy service unix:private/spfpolicy

29 check policy service inet:

30 permit

Many spammers send a series of commands without wait- ing for authorization, in order to deliver their messages as quickly as possible. Line 16 rejects messages from those attempting to do this.

Options like lines 17 and 18 are probably becoming familiar now, and they work in this case by rejecting mail targeted at domains that don't exist (or can't exist). Just as in the “Sender restrictions" section, lines 19 and 20 allow local or authenticated users to proceed which here means that their messages will not go through any more checks. Line 21 is critically important because it tells Postfix not to accept messages with recipients at domains not hosted locally or that we serve as a backup mail server for; without this line, the server would be an open relay!

The next line defines an access file named sender. access that can be used as a black- or whitelist. I use this to list my con- sulting clients’ mail-servers so that none of the remaining tests can inadvertently drop important requests from them. I added line 23, which creates a similar blacklist called re- cipient access for recipient addresses, as an emergency re- sponse to a “joe job". Once in 2003, a spammer forged an email address from my domain onto several million UCE messages and I was getting deluged with bounce messages to "michelle ? honeypot.net". I was able to reject these by adding an entry like:

michelle@honeypot.net REJECT This is a forged account.

Although the event was annoying, this allowed my server to continue normal operation until the storm had passed.

Line 24 is the last of the "inexpensive" checks. It com- pares the name that the remote system sent earlier via the HELO command to the list of my secondary mail servers and permits mail filtered through those systems to be deliv- ered without further testing. This is the weak link in my filtering system, because if a spammer were clever enough to claim that they were one of my backup servers then my mail server would cheerfully deliver any message sent to it. In practice, though, Гуе never seen a spammer that crafty and this line could be removed without side effects should the need arise.

Lines 25 through 27 are somewhat more controversial than most of my techniques, in that they consult external DNS blackhole lists in order to selectively reject messages based on the IP address of the sender. Each of these lists have been chosen because of their good reputation and very con- servative policies toward adding new entries, but you should evaluate each list for yourself before using their databases to drop messages.

SPF and greylisting

Lines 28 and 29 add Sender Policy Framework (SPF) and greylisting filtering respectively. SPF works by attempt- ing to look up a DNS record, that domains can publish, which gives the list of addresses allowed to send email for that domain. For example, webtv.net's SPF record is currently “v=spf1 ip4: -all”, which means that a message claiming to be from joeuser? webtv.net sent from the IP address is forged and can be safely rejected.

Greylists are pure gold when it comes to rejecting junk email. Whenever a client attempts to send mail to a par- ticular recipient, the greylist server will attempt to find that client's address and the recipient's address in its database. If there is no such entry then one will be created, and Postfix will use a standard SMTP error message to tell the client that the recipient's mailbox is temporarily unavailable and to try again later. It will then continue to reject similar attempts until the timestamp is of a certain age (mine is set to five

Free Software Magazine n. 2, March 2005 15


minutes). The theory behind this is that almost no special- purpose spam sending software will actually attempt to re- send the message, but almost every legitimate mail server in existence will gladly comply and send the queued message a short time later. This simple addition cut my incoming junk email load by over 99% at the small cost of having to wait an extra five minutes to receive email for the first time from a new contact. It has worked flawlessly with the many mailing lists that my clients and I subscribe to and has not caused any collateral problems that I am aware of. If you take nothing else from this article, let it be that greylisting is a Good Thing and your customers will love you for using it.

I use the smtpd-policy.pl script that ships with Postfix to handle SPF, and Postgrey as an add-on greylisting policy server. They're defined in my master.cf file as:

вріро1ісу unix - n n - = spawn

user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/smtpd-policy.pl

greypolicy unix - n n = Е spawn

user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/greylist.pl

Content filtering

The messages remaining at this point are very likely to be legitimate, although all that Postfix has actually done so far is enforce SMTP rules and reject known spammers. Their final hurdle on the way from their senders to my users' mail- boxes is to pass through a spam filter and an antivirus pro- gram. The easiest way to do this with Postfix is to install AMaViS, SpamAssasin, and ClamAV and then configure Postfix to send messages to AMaViS (which acts as a wrap- per around the other two) before delivering them, and line 31 does exactly that:

31 content filter - smtp-amavis:

SpamAssassin is fantastic at identifying spam correctly. Its "hit rate" while used in this system will be much lower than if it were receiving an unfiltered stream, as most of the easy targets have already been removed. I recommend setting АМамі5 to reject only the messages with the highest spam scores; I arbitrarily picked a score of 10.0 on my systems. Then, tag the rest with headers that your users can use to sort mail into junk folders.

ClamAV has proven itself to be an effective and trustwor- thy antivirus filter, and I now discard any message that it identifies as having a viral payload.

Unfortunately, the configuration of these systems is more complicated than I could hope to cover in this article, as it depends heavily on the setup of the rest of your email system. The good news is that literally less than 1% of junk email makes it this far into my system, and I've actually gone for several days without realizing that SpamAssassin or ClamAV hadn't been restarted after an upgrade. Still, these extra filters are very good at catching those last few messages that make it through the cracks.

Other possibilities

If you want more aggressive filtering and can accept the in- creased risk of false positives, consider some of the other less-conservative blackhole lists such as the ones run by SPEWS (http://www.spews.org)or the various lists of blocks of dynamic IP addresses. You may also con- sider using the reject unknown hostname option mentioned in the “НЕГО restrictions" section, but you can expect а small, measurable increase in false positives.

The ruleset described above should be sufficient on its own to eliminate the vast majority of junk email, so your time would probably be better spent implementing and adjusting it before testing other measures.


None of the techniques I use are particularly difficult to im- plement, but I faced quite a challenge in assembling them into a coherent system from the scraps I found laying about in various web pages and mailing lists.

The most important thing I learned from the process was that it's easy to experiment with Postfix, and it can be cus- tomized to your level of comfort. When used in my config- uration, the most effective filters are:

e Greylisting e DNS blackhole lists e HELO enforcement

Greylisting has proven to be an excellent filter and I've deployed it successfully on several networks with nothing

16 Free Software Magazine n. 2, March 2005


but positive feedback from their owners. Even the basic HELO filtering, though, can visibly decrease spam loads and should be completely safe. It can be difficult to find a good compromise between safety and effectiveness, but I believe Гуе found a solid combination that should work in almost any situation. Don’t be afraid to test these ideas on your own and make them a part of your own anti-spam

[6] The //spamassassin.apache.org)

Apache SpamAssassin Project (http:

[7] Clam AntiVirus (http: //www.clamav.net)

Copyright information

tem! © 2005 by Kirk Strauser на This article is made available under the “Attribution- лр Share-alike" Creative Commons License 2.0 available from Bibliography


[1] Postfix Configuration - ОСЕ Controls (http://www. postfix.org/uce.html)

About the author

[2] SPF: Sender Policy Framework (http://spf. pobox.com/)

[3] Greylisting.org - a great weapon against spammers (http://greylisting.org/)

[4] Postgrey - Postfix Greylisting Policy Server (http: / / isg.ee.ethz.ch/tools/postgrey/)

[5] AMaViS - А Mail Virus Scanner (http://www.


Linux Based Solutions www.snowdoniait.com Tel: 01248 355 985 Mob: 07976 632 572 \


By using our services you will gain the many benefits of Linux and free software:

Services available include:

» Installation and configuration of server and desktop systems with appropriate applications

» Training in the use of your Linux system

» Website design with hosting on Linux servers

s Monitoring systems with customised plugins

- Vulnerability scanning and information security programme development

Contact us for a demonstration of Linux and the applications available, or to enquire

about our Linux based solutions for home users and businesses. On-site daytime and evening visits available. Competitive rates, free estimates.

«А secure, stable operating system

«A reduction in licensing costs

- A wide variety of applications for home and office use

„А powerful, customisable system

| spam


com/projects/dspam) filters spam with the best. In my installation, it stops over 98% | of all spam: I’ve only had one false positive

in the last year, and that was a message to the Dspam list that contained a real spam! Administering Dspam is a breeze. No rules to configure, new users can automatically benefit from a global dictionary and quarantine management is simple. But getting a Dspam quarantine set up the first time, without losing any email, can challenge the most seasoned mail administrators. In this article, I’m going to trace email through the various parts of a Postfix mail server running Dspam and Procmail or Maildrop, focusing on getting the CGI quarantine work- ing correctly. ГЇЇ provide the configuration steps for local users. ГІ also explain where the configuration differs for virtual users, and the basic changes or decisions that you need to consider, but I