Up: Back to ASK's homepage
This FAQ is available online at:
http://www.paganini.net/ask/docs/faq/index.html
You can also download the PDF version at:
http://www.paganini.net/ask/docs/faq/faq.pdf
Copyright (c) 2003 Marco Paganini.
ASK is an anti-spam solution written in Python for Unix and Linux systems. Unlike most anti-spam solutions, ASK does not attempt to interpret the content of emails to determine if they're spam or not. Instead, ASK implements a challenge-based authentication method where unknown senders are requested to identify themselves by responding to a confirmation message before their emails are delivered.
The confirmation message is sent to unknown users only. The confirmation process is very simple: all the sender has to do is reply to the message keeping the ``Subject'' header intact. Once ASK receives the reply, the user's address is added to a whitelist and further messages from that user are immediately delivered.
This is unlikely for a number of reasons. Spammers do not use real return addresses as they would have to deal with angry responses and an overwhelming number of email bounces. Besides, most ISPs today are intolerant to spammers, which would cause them all sorts of problems.
There are a few people who refuse to reply to confirmations. These however are very few and in any event their messages will remain in the queue where they can be later inspected.
ASK is a Unix/Linux/OSX program. It will not run on Windows servers or workstations. You may however, switch to an Internet/Mail provider that offers ASK services.
No. ASK can be installed as root or as a regular user.
The best way to report bugs is to subscribe to the ASK-Users mailing-list at
http://lists.sourceforge.net/lists/listinfo/a-s-k-users.
You can also use the Help forums on Sourceforge, but the list will get you a quicker answer. A bug report should always contain:
As usual, we recommend you to check this FAQ and the documentation before you submit a question.
The easiest way is to subscribe to the ASK-Announce mailing-list at
http://lists.sourceforge.net/lists/listinfo/a-s-k-announce.
This is a very low traffic list used to send out new version announcements and bugfixes. We also use this list to have an idea of how many people out there are interested in ASK.
The online documentation contains detailed installation instructions and examples. You can find it at:
http://www.paganini.net/ask/docs/ask_doc.html
Make sure you read the ``Upgrade Instructions'' section if you're upgrading from a previous version of ASK.
Make sure you run ASK from /usr/adm/sm.bin instead of /usr/bin (or whatever). You will need to create this directory, as Apple failed to ship with it. Or you will need to figure out how to configure smrsh (the secure shell sendmail uses to deliver mail (man smrsh)). Make sure you are invoking ASK from the correct location in your .forward file.
Note that all root mail is forwarded to /dev/null on MAC OSX (look at your /var/root/.forward file) - probably because there is no valid root login account. This means that all mail errors get tossed away. You will probably want to change that to a real user so that you can see if anything is going wrong.
This information was contributed by Kurt Werle and applies to OS X 10.1.X.
Note: this is a quick ``how-to'' for experienced MH users using the ``slocal'' auto-sorter. Since MH is a large system on its own, you may wish to consult its documentation and the New MH (NMH) home page at:
http://www.mhost.com/nmh
MH is a suite of mail programs, one program for an action: delete a message, compose a new message, edit a message, list messages, etc. Several MUAs build on to of MH commands to provide easy interfaces: exmh (tcl/tk), MHE (Emacs), and xmh (X11). MH comes with a incoming mail auto-sorter tool called ``slocal.'' Slocal reads a file called ~/.maildelivery with a format such as this:
From "a-s-k-users@" ^ ? "/usr/lib/nmh/rcvstore +ask" To "friend@" ^ ? "/usr/lib/nmh/rcvstore +personal"
The above sample says to file all mail coming from the ASK mailing list in an MH folder called ``ask'' and all mail I send to ``friend'' in my ``personal'' folder. To use slocal, users often place the following line in their .forward file:
"| /usr/lib/nmh/slocal -suppressdup -user USER"
where ``USER'' is your username on the local host that your mail is delivered to. To use ASK with slocal, you have to pipe the incoming message through ask.py, and then pipe it to the slocal program. To make ask.py pipe the proper content to slocal, use the -procmail flag of ask.py, as follows:
"| /usr/bin/ask.py --loglevel=5 --logfile=/home/USER/.ask/ask.log \
--home=/home/USER --procmail | /usr/lib/nmh/slocal \
-suppressdup -user USER"
That's it. You do not have to touch your MH configuration at all. Well, almost...
If you like all of the mail that ASK processes to show up in MH folders, you can do the following:
test -s $HOME/.ask/Junk && inc +junk -truncate -file $HOME/.ask/Junk
The above first test if the Junk file exists and is greater than zero (i.e., it has some data in it), then uses the inc(lude) MH command to break the Junk file into individual MH messages which will be added to your +junk folder (typically found in $HOME/Mail/junk/).
test -s $HOME/.ask/Bulk && inc +bulk -truncate -file $HOME/.ask/Bulk
$ for i in ~/.ask/queue/ask.msg.*; do scan -file $i;done 1 09/30 authorize185@mail Fwd: can you believe it - Make Money just 1 09/30 carolburke@intern Grreat News!!!!<<et="US-ASCII"; charset=" 1 09/30 "Jenny" DirectTV Free Programming Offer Ending So 1 09/28 "E-Business News" Free, 100% Confidential Help. No Loans Re
Finally, you may find it easier to copy those messages into an MH folder (say, named +spam) so you can view/delete them using MH commands:
$ for i in ~/.ask/queue/ask.msg.*; do inc +spam -file $i;done $ scan +spam 1 09/30 authorize185@mail Fwd: can you believe it - Make Money just 2 09/30 carolburke@intern Grreat News!!!!<<et="US-ASCII"; charset=" 3 09/30 "Jenny" DirectTV Free Programming Offer Ending So 4 09/28 "E-Business News" Free, 100% Confidential Help. No Loans Re
Note that in the above case, I used ``inc'' without the -truncate flag. It's important not to truncate files in the the ASK queue directory because some of those messages may yet be delivered to you, when their respective senders reply to an ASK confirmation email.
This section was contributed by Erez Zadok.
This cookbook was provided by ``Gour''.
Let's suppose that the local (system) user ``vadmin'' is the manager of a virtual domain called ``domain.com'' and that each virtual user's home directory is placed under /home/vadmin/users. Also, let's suppose that this system has two two virtual users, named ``vuser1'' and ``vuser2''.
The initial structure below /home/vadmin should be something like:
[dir] /home/vadmin/users/vuser1 [dir] /home/vadmin/users/vuser2
These users receive external emails as ``vuser1@domain.com'' and ``vuser2@domain.com'', respectively.
As far as ASK is concerned, those are indeed two completely independent users, with their own lists, mailkeys, etc. To create the basic configuration, copy the .askrc and the entire .ask directory from the parent user (vadmin) to /home/vadmin/users/vuser1 and /home/vadmin/users/vuser2.
The directory structure should now be something like:
[dir] /home/vadmin/users/vuser1/ [dir] /home/vadmin/users/vuser1/.ask/ [file] /home/vadmin/users/vuser1/.askrc [dir] /home/vadmin/users/vuser2/ [dir] /home/vadmin/users/vuser2/.ask/ [file] /home/vadmin/users/vuser2/.askrc
Configure the .askrc for each user, separately (set the correct email addresses, mailkey, etc). Also, as the files came from the ``parent'' vadmin account, it's a good idea to remove the lists under each virtual user's .ask directory to guarantee a fresh start.
The last step is to create the .qmail files to handle our virtual users, i.e. .qmail-vuser1 and .qmail-vuser2.
Sylpheed, in its default configuration, will read all messages from the pop or imap server directly, making it impossible to externally pre-filter mail messages. It also stores messages in MH format, which is not (yet) supported by ASK.
To make Sylpheed work with ASK, the following tools are required:
Note that most Linux distributions come with most of these installed already. If not, make sure you have the required packages installed before we proceed.
The steps to make integrate Sylpheed with ASK are given below:
poll YOUR_POP_SERVER proto pop3 \
username YOUR_POP_USERNAME \
password YOURPASS fetchall
Substitute the fields in CAPITALS for the real values. If you're using imap4 instead of pop3, substitute ``pop3'' for ``imap4''.
LOGFILE=$HOME/procmailrc.log VERBOSE=on ## ASK :0 fW |path_to_ask/ask.py --procmail --logfile=$HOME/ask.log --loglevel=10 [blank line] :0 e /dev/null [blank line]
Replace ``path_to_ask'' with the directory where the ``ask.py'' executable is installed.
rc_mymailbox = path_to_your_default_mailbox rc_remote_cmd_htmlmail = off
Note that ``path_to_your_default_mailbox'' is normally ``/var/spool/mail/yourusername'' in most Sendmail and Sendmail compatible systems.
From this point on, Sylpheed will not use its internal routines to download pop or imap mail anymore. Instead, it will monitor the system mailbox and incorporate any new mails delivered there. The real task of downloading email is delegated to fetchmail, which in turn calls procmail to pre-filter the messages using ASK.
Run Evolution, click on your account and then select the ``Tools'' menu. Select the desired account and click the ``Edit'' button. Select ``Standard Unix Mbox Spools'' as the server type and enter your mailbox location in the ``Path'' box.
Note that from now on, you will need some auxiliary program to download your email, such as fetchmail. See the ``How do I use ASK with Sylpheed'' question for tips on how to configure fetchmail.
Run KMail, select the ``Settings'' menu, followed by ``Configure KMail''. Click on the ``Network'' icon, then select the ``Receiving'' tab. Click on ``Add'' to add a new account. Choose ``Local Mailbox'' as the account type. Enter the account name and your mail spool directory under ``Location'' (usually something like ``/var/spool/yourlogin''). Also, choose ``FCNTL'' as the locking method (or ``Procmail dotfile'' if you're delivering with procmail. Click on ``OK'' to save the changes. You may need to delete your old incoming account (if any), as it will cause KMail to go directly to the IMAP/POP server, bypassing ASK.
Note that from now on, you will need some auxiliary program to download your email, such as fetchmail. See the ``How do I use ASK with Sylpheed'' question for tips on how to configure fetchmail.
The short answer is ``Yes, you need a mailkey!''.
The mailkey is used to distinguish between emails that really came from you and ``fake'' emails. It's a weak authentication method that works surprisingly well.
Many people don't know, but the ``To'' and ``From'' fields can be easily forged in a SMTP transaction. That means anyone on the net can send out an email as if it came from you. If spammers have your email address, they could (many do) send you an email with your own address in the ``From'' field. If you don't have your mailkey set, we have no alternative but deliver this mail (which in many cases will be spam). With the mailkey set correctly, emails coming from your own address will only be delivered if they contain your mailkey.
The easiest way to deal with this is to set your mailkey to some unusual string in your signature. Do not set the mailkey to be your name! Many spam messages contain your name. This would cause those messages to be immediately delivered.
First, make sure you read (and understand) the question above. If you send yourself mail without your mailkey, ASK has no means of knowing whether it came from you or not. One option is to add a header (let's say, called X-Mailkey) to your outgoing messages. Most mail clients have an option to add a custom header.
This approach has one little problem however: Headers do not survive a reply. This means that using the mailkey in a header nullifies one of its benefits: To allow replies to be delivered directly (most people these days keep the entire message body in a reply, but the headers are discarded by the mail client).
The best option really (at least for now) is to make the mailkey something in your signature. Just add a funny phrase and set the mailkey to it (or even better, part of it to avoid problems with word wrapping).
The Junk mailbox (parameter rc_junKMailbox in your .askrc file) receives all messages that came from one of your addresses (rc_mymails) but did not contain your mail key. See the question above regarding the need of a mailkey.
ASK 2.3 on operates on a different principle: These messages are not sent to the junk folder anymore. Instead, they're queued with the X-ASK-Info header set to ``Junk''.
ASK will never send confirmations to mailing lists. If a mailing-list mail is received, but the mailing-list is not on your whitelist, that mail will be dumped into your ``Bulk'' mailbox (parameter rc_bulKMailbox in your .askrc file). You may comment out this parameter if you don't want to save those messages.
ASK 2.3 on operates on a different principle: These messages are not sent to the bulk folder anymore. Instead, they're queued with the X-ASK-Info header set to ``Bulk''.
Easy enough! Just edit your ~/.askrc and change:
to:
This will instruct ASK to use only English, not any other language.
Edit ~/.ask/templates/confirm_en.txt and ~/.ask/templates/blacklist_en.txt to your liking.
This file is part of ASK's mail-loop prevention mechanism. Every time ASK sends a confirmation message, it appends the original sender's email address to this file. ASK enforces a maximum number of addresses, meaning that after a certain point, new addresses will push old addresses out of the list.
Before sending a confirmation, ASK checks to see if the original sender's email address appears more than ``rc_max_confirmations'' times (default = 5) in the list. If that's the case, ASK assumes some kind of mail-loop is occurring and stops sending confirmation messages to this address.
As new emails arrive (from other senders), the offending addresses are naturally pushed off the list. As soon as less than ``rc_max_confirmations'' occurrences of the offending email address are present in the list, ASK starts sending confirmations to that address again (provided, of course, new emails are received from that address).
Most users should leave this file alone, as it is used internally by ASK.
ASK adds the special SMTP header ``X-ASK-Info'' to all messages it processes. This header contains important information on how the message arrived at your mailbox (confirmed by user, whitelist, etc).
Make sure you set your mail client to display the ``X-ASK-Info'' header. Most clients allow you to do that.
Sendmail is very picky about file permissions. For security purposes, your .forward file will be ignored if it is world readable or if your directory can be written by someone else.
To fix the problem just login as your regular user and type:
Your Sendmail is configured with smrsh support. All you need to do is to add a symlink in smrsh's directory pointing to ask.py. Please check http://www.sendmail.org/faq/section3.html#3.34 for more details on how to fix this problem.
Make sure you have the parameter rc_remote_cmd_enabled set to ``on''. If this variable is set to ``off'', ASK will simply treat your remote commands as any other mail.
Also, make sure your email address is correctly listed in your ``list of mails'' (parameter rc_mymails parameter inside your .askrc file) or ASK will reject your remote commands (you will see lots of ``is_command_help(): Not from ourselves'' messages in your log file).
One possibility is that you're using a delivery agent that does not add the ``From `` line for you. If you're using procmail as your delivery agent, make sure you run procmail with the ``-d'' command line switch.
Some people prefer to configure fetchmail to call procmail instead of opening a connection to their port 25 to perform the mail delivery. If that's your case, make sure your configuration on .fetchmailrc has something like:
poll your_pop_server protocol pop3 username johndoe pass cow mda "procmail -d %T"
This is a known procmail bug! Please upgrade to procmail 3.22.
There is no fail-proof way to tell a real bounce from a confirmation bounce. ASK uses a simple trick: It tries to parse incoming bounces to see if they contains certain parts of the confirmation message. If that is the case, ASK assumes it is a bounce to a confirmation (probably a spammer using an invalid return address) and discards the message. Most MTAs will quote the original message when sending bounces, so this method works reasonably well.
There are cases however, when very little information about the original message is provided. In these cases, ASK's only option is to deliver the message as it may represent an important notification from the mail system.
There's hope however. If you have root access to your system, configure your MTA to make your user ``trusted''. Once you do that, change the ``rc_mta_command'' parameter in your .askrc file to:
rc_mta_command = /usr/sbin/sendmail -f '<>' -t < MAILFILE
This instructs sendmail to use an empty envelope address when sending the confirmations. The receiving MTA will not send bounces to your confirmations anymore.
If you're using qmail, you may want to use the following instead:
rc_mta_command = /usr/bin/qmail-inject -f '' -t < MAILFILE
Quick instructions on how to make your user trusted for a few MTAs:
Sendmail should work right out of the box. It will however, add a ``X-Authentication-Warning'' header to your confirmation messages, which should be pretty harmless anyway.
If you really want to ``do the right thing'', edit your /etc/sendmail.cf file and look for the word ``trusted''. Sendmail can be configured in a number of ways, but once you find the right spot, it should be easy to modify the configuration.
trusted-users: mail:paganini
Always restart your MTA after you perform these changes.
In most systems, you can use ``crontab -e'' to create an entry in your crontab file. Add the line below:
00 08 * * * find /ask_queue_dir -type f -mtime +10 -exec rm '{}' \;
This will remove all queued files that have not been modified in the last 10 days. This procedure will be executed daily, at 8am. Make sure you change ``/ask_queue_dir'' to your real queue directory.
Exercise this option with care. It's always a good idea to check your queue for valid senders who did not reply to the confirmation instead of blindly removing queued messages.
Marco Paganini 2004-06-09