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.

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/

[Show full history]

To Do

Things still to do:

Any assistance would be appreciated.

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