[albatross-users] revisiting checkboxes..

[Eric S. Johansson]

Michael C. Neel wrote:

> If you look back at my first posts to this list; you'll see I also had a
> very tight interface issue that I needed help with (a set of filters,
> the number is unlimited and the user just keeps "add filter" or "remove
> filter" and each filter had a set of controld to display and remember
> state on because it was step 6 of 8 in a wizard).  I ended up going the
> albatross_alias/class route and still prefer that method when it's
> needed.

I'll have to read up on that.  One of the things that occurred to me after my 
last message about selling the wrong problem is that I probably need to had a 
new version of "list" which is "listall" which will return a list of all items 
in the group as well as their state.  It's probably only useful for checkbox but 
you never know.


> If you don't mind, do you plan on open souceing this spam tool?  What
> are it's server reqs?  Will it run on qmail?  If so I'd be interested in
> using this when it done ;)

it is open source already (camram.sourceforge.net) the current version is a few 
fries short of a happy meal in a few areas but the filter is fundamentally 
sound.  What I've got on my pack is a version which uses enhancement of the 
python configuration variable class, a bunch of minor bug fixes.  I'm working on 
a reimplementation of the current spamtrap user interface with extraction of a 
bunch of classes for reuse in the dumpster interface.  Then I'll create the user 
configuration editing tool.

camram is the first practical sender pays antispam system.  I described as 
practical because while it does allow for sender pays e-mail, it doesn't dictate 
that all messages must have a stamp.  There is a three filter chain between 
stamps, white list (who you know), and a Bayesian style discriminator.  The 
system also includes a stamping utility designed to work with an SMTP proxy 
called e-mailrelay.  The Bayesian discriminator is crm114 which works pretty 
well but is going through some fairly major changes by itself.

the discriminator phase categorizes messages into good, bad, can't tell.  Good 
is passed on to the inbox, bad and can't tell is spamtrapped.

the system includes the capability of sending notices or postage to notices. 
I've put a great deal of effort into minimizing who gets notices.  For example, 
only can't tell messages get notices.  Additionally, if the message has 
indicators that it might have come from a mailing list, it won't send a message 
either to prevent annoying folks on a mailing list.

server requirements: all needs is the ability to inject itself somewhere in the 
delivery process.  I'm currently using procmail because it's convenient.  If you 
want to make it work with something else all I require it is for message to be 
converted to python e-mail object format and I will return it in the same format.

you can run the system and either global mode or individual mode.  Global mode 
uses one set of discriminator profiles and white list for everyone on the 
system.  individuals have their own profiles.  managing the spamtrap is left up 
to a small number of individuals.  This is typically what you would use for a 
corporate environment.

in individual mode, everyone gets their own spamtrap, white list, discriminator 
profile etc.  Hasn't been heavily tested because my wife doesn't want to be 
bothered with managing her own spamtrap.

Load isn't too horrible.  I have it running at one commercial client on midrange 
Pentium III and it's just running for them without noticeable load.  Unlike Spam 
assassin which regularly hammered the machine and caused major headaches.

the next release is waiting for: the user interface tools (no problem 
advertising albatross if folks want), changes to the SMTP proxy to single thread 
the filter/stamp generator but queue up additional requests, Java applets and 
CGI for the postage due notice and browser based stamp generation.  would be 
nice to have a better authentication system than the traditional htaccess methods.

needs list:

help with user interface implementation (this should come as no surprise)
taking over some of the work so I can concentrate on the ietf protocol proposal
crypto extensions

did I forget to mention the crypto extensions?  In a nutshell, put your public 
key on every single message outbound.  Once you've exchanged stamped messages 
with someone, you can "trust their key" a little bit.  Then you can sign and 
encrypt messages between yourselves automatically with no passphrases.  Yes, it 
has some weaknesses like MITM but on the other hand, it's an order of magnitude 
more secure than postcard mail today and far far easier to use than pgp.

I tend to get a bit passionate about this project and ramble on especially if 
I've been up too late like I have been again.
---eric