Re: hashcash integration on MTA level for postfix

decoder wrote:
> 
> I read the camram installation guide. And I closed the page.

no problems.  I have the same reaction.
> 
> This thing is absolutely unusable,

the installation page is unusable.  No argument about that.  it has 
remnants of two different versions of the system and I quite frankly 
haven't had the energy to go back and fix it.  Right now, installation 
process is a shell script which fetches three packages and installs all 
the components then you need to manually configure the web server, 
postfix, Cron job, and start up.

personally I'm not happy with the installation process because it's a 
bitch to maintain and I would love to find a way to reduce the 
complexity.  if you have some suggestions, let me know and even better 
would be some working code or documentation.

> and I can say that I'm a
> experienced system administrator. The whole installation process is
> longer than setting up spamassassin with all possible plugins that one
> could think of, and is in my opinion, absolutely unusable in a bigger
> environment (for example looking at the step where you need to execute
> stuff for every user..). All this would get me more hassle than use.

yet well, I used to build OS kernels and lived in the file and memory 
management systems for living.  Maybe that's why I'm not very sensitive 
to its complexity.  ;-)

but to the example you give, executing stuff for every user, what else 
are you going to do when you have per user control of their filtering 
environment?  Of course you have to execute something on a per user 
basis.  The bitch comes in when you try to associate an e-mail address 
with a user.  With e-mail forwarding, aliases, and virtual hosts, you 
have no idea where the message is going to end up until it actually 
arrives.  remember that the filtering machine may be entirely separate, 
sharing nothing with the mailbox machine except an ethernet switch.

I was considering putting in a system where if a destination address was 
valid but not recognized by the filter, you would send an additional 
piece of e-mail saying "register this address" with a URL containing all 
of the appropriate encoded information.  Then when the user clicks the 
URL, they are brought to the Web interface, they login and that e-mail 
address is automatically associated with their login ID.  Obviously this 
would have to have exactly 1 semantics etc. but that's the basic idea.

I haven't done it because I don't have the time or energy to implemented 
in its raw form and to figure out a way to keep it from exploitation by 
spammers because I'm worrying about stuff like installation.

> 
> Sorry if that sounds offensive, it surely isn't meant to be like that,
> that is just my opinion.

I take no offense.  The problem is difficult, the solution is moderately 
complex and I have failed on the installation human factors. 
Operationally, it's exceedingly nice.  But installation is still a bitch 
as you pointed out.

my frustration is that I could use help.  Plain and simple, I could use 
some help with this.  I would rather focus on internals than 
installation crap because that's what I know.  it would be wonderful if 
somebody could help me set up a .deb construction process.  But failing 
that, I'm going to start shipping vmware bubbles that are almost 
completely ready to go.  I don't care if it's a whole OS with it and the 
file is 6 GB.  There will be a minor set of changes needed to make it go 
which will make it easier to adopt.

your criticism is valid.  I need to fix those things but other more 
important things come first.

---eric