In this section we discuss other challenge-based authentications and compare some of their key features to ASK.
Tagged Message Delivery Agent (TMDA) is a spam-reduction solution by Jason R. Mastaler. TMDA is also written in Python and integrates well with most MTAs and MUAs.
One of the key problems in challenge-authentication tools is how to match the confirmation return to the stored message, as very few headers from the original message are kept in the reply. ASK sends the MD5 hash that identifies the message (the cookie) in the ``Subject'' header, knowing that most MUAs quote the original subject in replies.
TMDA takes another approach to this problem. Instead of relying on the contents of the ``Subject'' header, the sender's own email is rewritten to contain the cookie in it. This is possible due to the use of extension addresses, a configurable MTA feature that allows one account to receive emails with differentiated recipient addresses. Under this scheme, emails going to foo@bar and foo-extension@bar will both be delivered to user foo at the host bar. TMDA uses use the ``-extension'' part to include all sorts of control messages and cookies that need to be present in the reply.
A typical message exchange between a TMDA user called tmda@domain and a non-TMDA user called user@domain is something as follows:
TMDA also presents the concept of tagged messages (hence its name): outgoing emails may have the sender's address rewritten to contain special tags that bind that email to that recipient (future emails from that recipient will only be accepted on the special, tagged email), dated addresses (emails that are valid only throughout a date range) and keyword addresses, temporary addresses that work indefinitely until manually revoked (for Web-based services).
The utilization of extension addresses adds robustness to the system and the possibility of tagged messages. However, it requires complete control over the MTA configuration files at the ISP level (or an ISP with extension addresses enabled, a rather uncommon feature). Furthermore, some integration issues exist with Sendmail, which does not provide envelope information to programs invoked from the user's ~./forward file. In these cases, procmail must be configured as the local mailer in order to make all the required information available to TMDA.
Qconfirm is a challenge-authentication system written in the C Language by Gerrit Pape for Qmail users.
Unlike ASK, Qconfirm is not a single program but rather a group of smaller programs with specific tasks (following Qmail's style). Incoming messages are checked by the qconfirm-check program which is also responsible for sending confirmation messages to unknown senders.
Pending messages are held in the qmail queue. qconfirm-check will send confirmation messages with an empty envelope sender and the ``From'' header set to ``user-qconfirm-key@host,'' and create a file named .qmail-qconfirm-key under the user's home directory.
Confirmation returns have the recipient set to user-qconfirm-key@host. This will trigger the .qmail-confirm-key file previously created and invoke qconfirm-accept to deliver the queued message and add the sender's address to the .qconfirm/ok directory (Qconfirm's whitelist).
Common queue and list maintenance tasks are performed by means of a command line utility called qconfirm. This program can also be executed remotely by creating special Qmail control files to invoke qconfirm-control. This provides an interface similar to ASK's remote commands.
Qconfirm is lightweight and fast but relies heavily on the infrastructure offered by Qmail. This leaves Qconfirm as an option for Qmail users only.