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.


RSS Recent releases

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 13: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 10: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 10: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.

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.

RSS 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.


3. www.freedom-to-tinker....
7. localhost/home/karsten...

19 May 2002 22:24 914 Thumbs up

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

Aspose.Email for Java

A Java componentomor reading and writing Outlook MSG files.


Project Spotlight

Text Fiction

A Z-Machine for Android.