[hashcash] pseudo blog 17-May-2004

  • From: "Eric S. Johansson" <esj@xxxxxxxxxx>
  • To: CAMRAM <camram-spam@xxxxxxxxxx>,hashcash <hashcash@xxxxxxxxxxxxx>,Graeme Walker <graeme@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 17 May 2004 14:31:37 -0400

so far this spring, three people that have had a major influence on my 
life have passed away.  I've already spoken about Nick.  The next was 
Janet Mattie, head of the AAVSO (American association of variable Star 
observers).  She and her surviving husband were both very influential in 
my interest in astronomy.  If it hadn't been for the fact that the 
astronomy field was generating 500 Ph.D.'s for every 50 openings, I 
might have stayed there.  Janet did many things for me including 
developing an appreciation of why it is necessary to do good data 
gathering and why it is so very important even  with tools like Hubbell. 
  This appreciation has served me well even in the domain of software 

the next person was my father-in-law.  Like all humans he had feet of 
clay but he did allow me to live in his house for a couple of weeks when 
I left home to start my own life.  He helped me with finding my first 
job and the encouragement to continue in the software development field. 
  Decidedly a mixed blessing.

we have a yearbook from the time when he served on the USS Avery Island. 
  He was part of the bikini nuclear weapons tests and was only 15 miles 
from ground zero.  The plan is to scan the yearbook and publish it on 
the net.  I pity my poor little DSL line.

and that's my excuse for being slow...

camram notes.  Two important developments: multi domain/server front-end 
instance and Windows client side stamper.

The first development is that I now have a version of camram that will 
work as a "lump in the line".  You can install it in front of any 
mailserver, handle any number of domains, and it can handle all traffic 
from the Internet and from your mailserver doing the right thing 
(stamping, filtering etc.).  It's still, as they say, dammed fragile but 
it should be ready for testing relatively soon.  If you are interested, 
please e-mail me directly so we can work out the details.

I must say that the reason it took so long to develop was because I went 
down a rathole of using milter as the filter interface to sendmail. 
fortunately, the process revealed (albeit gradually) some of the 
architectural changes I needed to make in camram.  Some of the more 
painful and there are still some problems that will impede 
multithreading through the filter but that's for another day.

The current system uses two copies of e-mail relay and one copy of 
sendmail.  The first copy of e-mail relay takes traffic in from the 
Internet side of the net and filters it.  The messages then relayed to a 
delivery only instance of sendmail which has all the routing information 
necessary for proper handling of e-mail.  The second e-mail relay 
instance is set up exactly the same way except it is excepting e-mail 
from the "internal" side of the network and only performs stamping 
operations.  Again when it is done, the e-mail is passed to the delivery 
sendmail instance.  If the server is exposed directed for the Internet, 
you can also put two more instances of sendmail in front of the e-mail 
relay proxies.  The reason for this is to allow you to add something 
like smtpauth for the internal interface and to give you greater traffic 
handling capability with queueing for your Internet sourced traffic.

Yes, there is a question about performance but I believe that it 
shouldn't be too horrible and that camram itself will be the limiting 
factor, not the architecture.  In practice with the procmail delivery 
model which is effectively the same thing as what I've described here, 
the dominant overhead is crm114.  When the system has learned who you 
speak with, the overhead is much lower.

another point is that there's nothing special about sendmail in this 
context.  a full MTA for queuing, message handling, deliveries etc., 
anything will work as long as you can fully control source and 
destination interface bindings and port members.

for an intermediary tool for interfacing with camram, E-mail relay has 
been a far more friendly and flexible tool for these purposes.  I cannot 
say enough good things about it.  Only thing that would make it better 
would be if Python was better integrated (hint, hint).  I suspect that 
if anybody wants to help Graham with that, it would be welcome.

The second development is that I now have a version of the stamp or 
working on Windows.  It's only slightly less fragile than the lumper 
version of camram but it does work and, in fact I am using it right now.

it's more of a proof of concept than a real implementation but it gives 
us a foundation for the user experience generating local stamps.

implementation is two email-relay instances.  First for accepting 
traffic and queuing up the messages.  The second is for stamping then 
delivery.  I will admit that it has been a bit of a hair tear.  The 
author of e-mail relay Graeme Walker has been wonderfully supportive.

On the window side of the house, the interface for calling the filter 
only can execute executables or batch files and I had to modify (poorly) 
a JavaScript wrapper to call the Python instance which would run my 
Python code.  I believe this is known the Russian dolls school of code 
development.  the same set of components applied to MacOS X should also 
yield a MacOS X client side Stamper.

theoretically too I also have it set up to autostart.  I will test 
sometime in the near future unless one of you want to beat me to it.

If you want a copy, let me know and I will send you the super secret URL.

I must admit, this combination of bits has some interesting possibilities.

The last thing I'm working on is user interfaces for the training and 
dumpster sections.  I found a bug in the process I was using for 
training CRM114.  I was apparently overtraining and getting distorted 
score patterns.  I'm now doing strictly what is known as "train on 
error" and things seem to be working better.  The discrimination seems 
good enough that you can use a very narrow set of limits and really 
minimize the amount of work necessary for training.

I will start checking things into CVS soon and generate up a release one 
can use with the raging dormouse acquisition package.


Other related posts:

  • » [hashcash] pseudo blog 17-May-2004