Projects / Active Spam Killer

Active Spam Killer

Active Spam Killer (ASK) protects your email account against spam by confirming the sender's email address before actual delivery takes place. The confirmation happens by means of a "confirmation message" that is automatically sent to all "unknown" users. Once the sender replies to that message (a simple reply will do), future emails from that person will be delivered immediately. You can also specify (regexp) addresses to be immediately accepted, rejected (with a nastygram) or ignored. The package also includes a utility to scan your old mailboxes and generate a list of emails to be accepted automatically.


Recent releases

  •  28 Jun 2003 23:22

    Release Notes: This release adds a new option to validate senders at connection time, using SMTP. This should reduce the number of email messages sent to invalid addresses. Delivery to pipes is now possible, allowing non-procmail users to forward their email messages to other accounts at will.

    •  24 May 2003 20:23

      Release Notes: A bug that caused ASK to fail when using Remote Commands in text mode was fixed. A bug in the exception handling routine was fixed. The upgrade instructions in the documentation were improved. Upgrading is recommended.

      •  21 May 2003 17:58

        Release Notes: Users can manipulate the pending queue as an IMAP folder. Danish and Finnish translations have been added. Lists can span multiple files and match on arbitrary headers. Regular expressions are properly escaped when added to the whitelist. There is improved matching for single email messages on the lists. Bulk/junk messages are now queued instead of saved to separate files. The X-ASK-Info header now contains a timestamp and the reason for delivery. There are many other new features and bugfixes. Upgrading is recommended.

        •  01 Apr 2003 18:27

          Release Notes: Multiple problems with the RPM file have been fixed, the lists can now be used to match any SMTP header in the incoming mail, making integration with other anti-spam tools easier, and lots of other smaller bugfixes have been added.

          •  03 Dec 2002 18:39

            Release Notes: This version contains a large number of new features and bugfixes. The lists (white/black/ignore) can now be spread over multiple files, eliminating possible editing conflicts. Queued messages can now be saved in "Maildir" format (allowing remote access to the queue via IMAP). Replies to a confirmation will now add both the "queued" address and the replying address to the whitelist. Also, the whitelist is now checked before the other lists, allowing entire domains to be ignored while some "trusted" accounts from these domains are allowed.

            Recent comments

            23 Jan 2008 07:48 urlaubswerk

            Re: Very cool concept.


            > % Now, if you could just make it in C++

            > so

            > % that it's

            > % scalable enough for a larger server,

            > % it could

            > % actually become something really

            > % BIG!

            > %



            > i dont think so,

            > python is such a great language,

            > so that the language become so modular

            > :)

            > and dy know, it is faster than Perl


            Yes, I agree. We prefer Pyhton, too. The modularity is much better than in former times.

            18 Jan 2004 20:03 kdog

            Re: Challenge response considered harmful

            > % Response:: reply w/o modifications.
            > %
            > % Faults: Sends challenges to innocent third-parties as a result of
            > % spoofed ehaders.
            > This is not an ASK problem, but rather a weakness in the SMTP
            > protocol.

            A weakness, but not a failure.

            While SMTP _allows_ bounce messages (RFC2822 "MAY generate...", ongoing problems with spam, spoofing, Joe-jobs, etc., means that good practice mandates rejection processing happen at SMTP delivery time. Rather than the receiving MTA
            generate a bounce message, it returns a failed delivery error (permanent or temporary depending on conditions.

            > Take MTAs for example. They send bounces to the envelope
            > address, which is very easy to forge. If a spammer starts sending
            > millions of emails with a forged "envelope-from" containing your
            > email, you will receive zillions of bounces in no time.

            Which illustrates nicely the problem of generating bounce messages.

            The distinction between MTAs and C/R is that _some_ MTAs are broken by implementation or configuration. But _all_ C/R
            systems are broken by design.

            Or: beauty is skin deep. Ugly goes clean to the bone.

            > So, as you can see, programs that "blindly" reply to a forged address
            > are been with us for a long time, including all MTAs, autoresponders,
            > mailing-list managers and everything that talks SMTP. The problem has
            > not been created by challenge-authentication agents.

            It's grossly exacerbated.

            07 Sep 2003 20:16 paganini

            Re: Challenge response considered harmful

            > Response:: reply w/o modifications.
            > Faults: Sends challenges to innocent
            > third-parties as a result of
            > spoofed ehaders.

            This is not an ASK problem, but rather a weakness in the SMTP protocol. Take MTAs for example. They send bounces to the envelope address, which is very easy to forge. If a spammer starts sending millions of emails with a forged "envelope-from" containing your email, you will receive zillions of bounces in no time.

            So, as you can see, programs that "blindly" reply to a forged address are been with us for a long time, including all MTAs, autoresponders, mailing-list managers and everything that talks SMTP. The problem has not been created by challenge-authentication agents.

            26 Aug 2003 01:46 kdog

            Challenge response considered harmful
            Before you use this project, please read the following. You can cause yourself harm by using challenge-response systems. Latest copy at:

            Spam is a growing, heck, exploding problem. No doubt. Regardless, C-R
            is a flawed tactic, for the following reasons.

            0. Weak, and trivially abused, verification basis.

            Even where used, C-R systems are readily bypassed by spammers.

            The 'FROM:' header of email can be, and routinely is, spoofed. It
            offers no degree of authentication or evidence of identity.

            C-R uses the "From:" header (with implementation-specific variations)
            as an authentication key. While a given key is going to have a
            relatively low likelihood of being cleared by a given user, there are
            keys which will have a high likelihood of being cleared. Off the top
            of my head,,,, @*.gov, and other
            major commercial, financial, and governmental institutions, would be
            likely to be cleared by a large number of users. Similar "social
            engineering" tactics are already used by spammers.

            C-R moves you back to square one of the fact that SMTP can't provide
            authentication of email headers. At the very least, contextual
            analysis of headers (as Alan admits) is necessary. If you're already
            taking this step, heuristic and Bayesian methods are a low-overhead
            next step, which have proven to be highly effective and accurate.

            By contrast, systems which utilize multiple metrics -- sender, header
            integrity, content, context, Bayesian analysis -- provide a broader,
            deeper, richer set of metrics on which to gauge spam. While such
            filters may incorporate the 'From:' header, they do so in context of
            additional data for stronger validation.

            1. Mistaken interpretation of anti-spam goals

            The intent of a practical anti-spam system is not to ensure, at all
            costs, that no spam should darken the reader's inbox at any cost. If
            that's the goal, then unplugging your computer is the simplest fix.

            At a practical level, the goal is to minimize the amount of spam
            received, while ensuring no (or the very minimum) of legitimate mail
            is lost. Inconveniencing spammers is a plus. It is currently possible
            to achieve rates of a very small handful of spam messages per week via
            a mix of whitelisting and content-filtering systems, with Bayesian
            filters attaining very high and accurate rates.

            C-R systems in practice achieve an unacceptably high false-positive
            rate (non-spam treated as spam), and may in fact be highly susceptible
            to false-negatives (spam treated as non-spam) via spoofing.

            2. Misplaced burden.

            Effective spam management tools should place the burden either on the
            spammer, or at the very least, on the person receiving the benefits of
            the filtering (the mail recipient). Instead, challenge-response puts
            the burden on, at best, a person not directly benefitting, and quite
            likely (read on) a completely innocent party. The one party who should
            be inconvenienced by spam consequences -- the spammer -- isn't
            affected at all.

            Worse: C-R may place the burden on third parties either inadvertantly
            (via spoofed sender spam or virus mail), or deliberately (see Joe-job
            below). Such intrusions may even result in subversion of the C-R
            system out of annoyance. Many recent email viruses spoof email sender,
            including Klez, Sobig variants, and others.

            3. Privacy violation.

            A record of our correspondence is being maintained by a third party
            who has no business knowing of the transaction. Many people will
            refuse to respond to C-R requests for this reason.

            Virtually all C-R systems must be implemented on the mail server --
            putting them effectively _out_ of the immediate reach of the casual
            home email user, and putting critical information of the email habits
            of both yourself and your correspondents in the hands of a third

            Most of the _general_ discussion (that is, outside this mailing list)
            has concerned service-model enterprise models in which C-R is provided
            and hosted by a third-party, which is then acquiring a rather
            interesting database of communications patterns, which _must_ be
            maintained on a persistent basis. Not the sort of thing I'd like to
            have available to an arbitrary subpoena request.

            4. Less effective at greater burden than receiver-side whitelisting.

            A C-R system is essentially an outsourced whitelist system. The
            difference between a C-R system and a self-maintained whitelist is
            that the latter is:
            * Maintained and controlled by the mail recipient, rather than a
            third party service provider.
            * Is the responsibility of the mail recipient, rather than the
            * Places the burden on the recipient to add new addresses to
            allow/deny lists.

            I might add that I myself use a mix of whitelisting and spam filtering
            (via SpamAssassin) to filter my own mail with a very high level of
            accuracy, in terms of true positives, true negatives, false positives,
            and false negatives. Namely: better than 98% true positive (filtered
            spam), less than 2% false negative (unfiltered spam), 99.98% true
            negative (unfiltered non-spam), and less than 0.02% false positive
            (filtered non-spam). While some C-R proponents claim filtering doesn't
            work, it clearly does.

            5. High type II error (beta).

            Because of numerous issues in sender-compliance with C-R systems, C-R
            tends to a high false positive rate. This is known as type II error,
            in statistical tests, and is denoted by beta.

            The mechanics of C-R systems lead to a fairly high probability that
            users of such systems will find themselves missing an unacceptably
            high rate of non-spam (AKA "ham") mail, possibly with very high
            significance (e.g.: client, commercial prospect, or family

            In a staggering display of transrational behavior, C-R proponents
            frequently and vociferously blame this failure of C-R on the
            unwillingness of bystanders to be drawn into the misguided system.

            C-R systems assume all mail to be spam until proven otherwise. A
            rational system assumes mail to be of _unknown_ quality, until
            determined to be spam or non-spam. If mail processing can't determine
            the mail's quality, it is treated as "grey". Such "greymail" generally
            amounts to a small handful of messages daily, even for heavy mail
            users, and can be readily evaluated, with whitelists and spam filters
            trivially updated.

            For a description of statistical type II errors, see:
            * [1]
            * [2]

            6. Potential "Joe-job" denial of service.

            C-R systems can be used intentionally or otherwise in a
            denial-of-service or "Joe Job" attack on an innocent third party. In
            fact, this is likely to start happening shortly as C-R becomes more

            How? Simply: Spammer spoofs a legitimate sending address (this is
            already commonplace). C-R systems then send out a challenge to this
            address. With only 1% penetration of C-R, the victim of the C-R/Spam
            attack is deluged with 100,000 challenge emails. This could likely
            lead to lawsuits or other legal challenges.

            Even in its less severe form, the number of C-R challenges received by
            users from spoofed mail -- spam, viruses, and the like -- will likely
            cause C-R challenges to be viewed as a major annoyance.

            7. C-R - C-R deadlock

            This is almost funny.

            How do two C-R system users ever start talking to each other?
            * User A sends mail to user B. While user B's address is then known
            to A, user B's C-R server's mail is not.
            * User B's C-R system sends a challenge to A...
            * ...who intercepts the challenge with A's C-R system, which sends a
            challenge to user B's C-R system...
            * Rinse, wash, repeat....

            No, I didn't think this one up myself, see Ed Felton's [3]"A
            Challenging Response to Challenge-Response"

            Bypassing this deadlock then opens an obvious loophole for spammers to

            While _some_ C-R systems may avoid this particular pitfall, current
            experience with vacation responders and spam-notification filters
            provide strong empirical evidence that a significant number of C-R
            systems will in fact _not_ get this right.

            This and several following issues are often countered with "but a
            well-designed C-R system won't do that". Unfortunately, there will be,
            and are, many poorly-designed C-R systems.

            One of the early proponents of C-R, Brad Templeton, has written a
            [4]set of "proper principles" for C-R systems. While one C-R system
            adheres relatively closely to these, there are many which do not. Such
            systems will pollute the public awareness by their bad habits. And
            even so, Templeton fails to consider the issues of Joe Jobs and
            spoofed 'From:' lines resulting in spurious challenges sent to
            innocent users.

            8. Potential integration into spam email harvest systems.

            One commonplace piece of advice for avoiding spam is to not respond to
            opt-out, AKA email validation testing, requests.

            C-R spoofing on the part of spammers would simply hijack a presumption
            that C-R requests were valid to provide spammers with higher-quality
            mailing lists. See the current rash of identity theft / CC theft scams
            based on "updating your account information". This isn't an attack on
            users of C-R systems, per se, but on those who've become habituated to
            responding to C-R requests.

            One likely consequence is that as C-R becomes more commonplace, its
            use as a spam-harvesting system will increase, leading to a reduced
            response rate to C-R mails as people avoid spam harvesters, and find
            that most C-R challenges come from spammers....

            C-R at best promotes bad personal identity protection practices.

            9. Likely consequences: C-R messages and users blacklisted or spamfiltered

            The C-R user is likely to find their own address added to blocklists
            from many users and/or mailing list administrators burned by
            malformed, or simply unwanted, C-R requests. Simply: people who
            receive such requests are very likely to just add the sending address,
            or user corresponding to the request, to their own personal
            blacklists. This is my own current M.O. with C-R requests, and
            anecdotal evidence suggests it's a common practice.

            This factor is entirely outside the bounds of the C-R system; it is a
            reflection of the independent response of individuals and
            organizations to receiving C-R challenges. C-R definitionally cannot
            accommodate this.

            Another possibility is that, due to user consensus, spam filters
            simply tag C-R messages as spam, either with a direct rule or as a
            result of Bayesian weighted scoring.

            Beyond any semiotic arguments of what spam is or isn't, if the
            operational reality is that SpamAssassin reflects the opinion of SA
            users and developers and treats C-R transactions as spam, it is for
            all intents, spam.

            10. Mailing list burden.

            C-R systems typically misfunction on mailing lists in one of two ways,
            neither of which is acceptable:
            1. The C-R sends a challenge to the list for messages received.
            2. The C-R sends a challenge to each individual list member for the
            first post received.

            In both cases, the burden is placed on a party who could care less
            about the benefits of the C-R system. Several lists of my acquaintance
            have taken to permanently banning any users who exhibit use of
            misconfigured C-R systems.

            11. Fails to address techno-economic underpinnings of spam.

            Spam exists for one reason: it's profitable.

            It's profitable because technology allows the costs of sending a large
            number of mail messages to be lower than the revenues available for
            doing so.

            Any effective spam remedy must attack one or the other side (or both)
            of this equation: raise the costs or reduce the technological
            effectiveness, on the one side, or reduce revenues on the other.

            C-R, as with most recipient-side filtering systems, imposes negligible
            incremental overhead on the spammer. A delivery is made, the spam
            server moves on, the cost is a single SMTP connection for a fractional
            second. Collateral costs are high: for legitimate senders, spoofed
            reply addresses, mailing lists, and retaliatory actions on the C-R

            A truly effective spam defense must attack the technical and economic
            aspects, in as unobtrusive a manner as possible.

            The one system which seems to best fit this requirement is the
            Teergrub -- the spam tar-baby, FAQ at:


            A teergrubing mailserver costs a spammer multiple SMTP connections, an
            inherently finite resource, for possibly hours. Workarounds on the
            part of the spammer are possible, but all result in higher costs,
            reduced delivery, or both. The net effect is essentially a delivery
            payment requirement, though the payment is in the form of time and
            configuration on the part of the spammer. Collateral damage is low --
            if a teergrube _does_ unintentionally filter a legitimate sender, the
            only cost is a single (or very small number of) delayed delivery. This
            and other issues are covered at the FAQ above, read it before posing
            hypothetical problems.

            Hall of Shame

            The following are some C-R systems known to behave poorly. Rules for
            matching the challenge messages are included

            [6]Active Spam Killer (ASK)

            Author: [7]Marco Paganini

            Identifier: Contains the header: "X-AskVersion: 2.2
            (". A wildcard match on "X-AskVersion"
            should be sufficient.

            Response:: reply w/o modifications.

            Faults: Sends challenges to innocent third-parties as a result of
            spoofed ehaders.


            7. file://localhost/home/karsten/Projects/Websites/

            19 May 2002 22:24 914

            this is great, and dirt-easy
            nice package. worked super-well with my qmail setup, and was really easy to install/config.

            i'm considering trying this out in a (limited) production environment.

            if you're looking for a challenge-response mailbox protector, this is the best/easiest/most configurable i've found.


            Project Spotlight


            A Fluent OpenStack client API for Java.


            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.