Junk Mail Buffering Agent

Current version: 0.5.5 (6 Feb 2006) [src]

Junk Mail Buffering Agent is a tool for preventing delivery of email until the sender has confirmed their address. It can be used in conjunction with a spam filter to prevent delivery of spammy-looking email unless the sender is confirmed as valid.

jmba is designed to be used in conjunction with a spam filter such as QSF and the mail processor procmail. When the spam filter says it thinks an email is spam, it can be passed to jmba. jmba will queue it and send an email to the sender containing a key; if the sender replies, the original email is "unfrozen" from the queue and delivered.

Note that some people consider verification emails such as those that jmba generates to themselves be spam, so use with caution.

This software is distributed under the terms of the Artistic License.

Comments, bug reports, and patches gratefully received - please use the Contact Form.

If you liked jmba, please consider a donation: [Donate]

Questions

What is "challenge-response"?
A challenge-response system is one that will issue a challenge when asked to do something, and requires the correct response before it will go ahead and do it.
 
In terms of email, a challenge-response system will react to a computer sending it an email with a challenge consisting of an email back to the sender saying "please verify that you meant to send this". When the sender sends back the correct response, their original message is then delivered.
Won't spammers reply to jmba's challenge?
Currently, the vast majority of spam is sent with a forged (invalid) envelope sender, so replying direct to the sender won't work and therefore jmba will never receive a response to its "please verify" challenge. In fact, a lot of the time the challenge just bounces.
Why not use challenge-response on its own?
While you could use jmba on its own, without a spam filter, it does not employ "whitelisting", so every message sent to you would be challenged. Other programs such as TMDA exist to do this and handle whitelisting themselves.
 
In general, challenge-response systems are very annoying for the sender. They require the sender to jump through hoops just to talk to you, which increases the effort required to send a simple email. Limiting the number of messages that are challenged to only those that trip the spam filter keeps the annoyance down to a minimum.
Why not just use a spam filter on its own?
No spam filter is perfect; sometimes a spam will be allowed through, and more importantly, sometimes a non-spam will be flagged as spam. This means that either you delete everything the spam filter thinks is spam, and potentially lose important messages, or you put all possible-spam into a separate folder and check that now and again.
 
Putting all possible-spam into a folder for periodic checking is fine at first, but if you're getting hundreds of spams a day, it becomes almost as time-consuming as not bothering to filter at all.
 
If, instead, all possible-spam is queued and the original sender is asked to verify they sent the message before it is delivered, the "checking" is effectively done for you - by the sender. Although spam filters are not perfect, they are still quite accurate, and so only the occasional sender will have to perform this verification step.
How is jmba different from another-package?
The design of jmba is centred around doing one thing and one thing only. Unlike TMDA, for instance, jmba does not implement whitelists, blacklists, or tagged addresses; it simply handles challenge-response and relies on a spam filter and the procmail and formail tools to decide which messages to queue up for the challenge-response treatment.
 
What this means is that jmba can be small, fast, and light on dependencies. Unlike many other packages it is not written in Python or Perl, so it starts up quickly and requires very little memory. It can also be much less complicated, which means it is less likely to contain bugs.

News

0.5.5 - 6 February 2006
  • ignore files starting with "." in the queue directory
  • include slightly more of the original message in replies
  • added new {SENDER} tag in template
  • added new {RECIPIENT} tag in template (sponsored by SpamDefy, http://www.spamdefy.com/)
0.5.1 - 8 July 2005
  • bugfix to make flood protection actually work
0.5.0 - 11 June 2005
  • minor bugfix in subject line decoding
  • log sender address on creation of queue entry
  • cleaner wording in logs
  • minor code cleanups
  • added -T, -f, -F options (-f = flood protection)
  • enabled flood protection (-f) by default
  • enabled no-to-self (-t) by default
  • flood protection was sponsored by SpamDefy, http://www.spamdefy.com/
0.4.5 - 25 September 2004
  • new option "-x" to run a command on each discarded email; this feature was sponsored by SpamDefy, http://www.spamdefy.com/
0.4.4 - 23 September 2004
  • new option "-S" to output decoded subject line
0.4.3 - 8 September 2004
  • accept message codes in the subject line, in case of blank replies
0.4.2 - 15 June 2004
  • corrected procmail recipe bug when used with "-t"
0.4.1 - 14 June 2004
  • new option "-t" to ignore emails with "from" and "to" addresses the same
0.4.0 - 5 May 2004
  • use the full path when calling procmail and formail
  • added new {MESSAGECODE} tag in template
  • added new {USER} tag in template
  • added new {ORIGINAL} tag in template
  • optionally keep a copy of spam, with the new "-D" (--discard-dir) option
  • optional logging of queueing, bouncing, reply receipts, etc
0.3.0 - 15 February 2004
  • added decoding of subject lines from other character sets
  • fixed bug in "make deb" for making Debian package
  • some translation fixes in the procmail recipe
  • portability fixes in the build process
0.2.8 - 3 February 2004
  • added Czech translation courtesy of Ondrej Suchy
0.2.7 - 12 January 2004
  • compatibility improvements to procmail recipe; now works with postfix
  • bugfix in "make index" (only of interest to developers)
  • run formail with "-I XX:XX" instead of "-IXX:XX"
0.2.4 - 15 December 2003
  • default subject now "Email queued by JMBA" - "JMBA:" causes problems
  • improved bounce detection in procmail recipe
  • procmail recipe reordered to match messages more quickly
  • notice added to example about putting it AFTER mailing list rules
0.2.0 - 13 December 2003
  • added -p / --procmail option, to output example procmailrc
  • added -b / --bounce option, to process bounced messages
  • tested example procmail recipe
0.1.0 - 22 November 2003
  • delivery into the queue implemented
  • replying implemented
  • recognition of replies to our replies implemented
  • redelivery (-q) implemented
  • minor tidyups of option parsing
0.0.1 - 21 November 2003
  • package created
  • first draft of man page written

To Do

Things still to do:

Any assistance would be appreciated.

This project is Free Software. Support the Free Software Foundation.