Current version: 0.5.5 (6 Feb 2006)
[src]
Downloads |
|
|
Information & Links |
|
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 software is OSI Certified Open Source Software.
OSI Certified is a certification mark of the
Open Source Initiative.
|
![[OSI Certification Mark]](../images/osi-certified-60x50.png) |
|