Re: PR Problem?

I apologize if my writing is a little more rough than usual.  I'm into 
the 27th hour of a migraine.

Todd A. Jacobs wrote:
> On Sat, Nov 11, 2006 at 10:56:34PM -0500, Eric S. Johansson wrote:
> 
>> then there is no "objection" to that system.  What appears to be the
>> most contentious is generating stamps.  Any stamps.  Without
>> addressing that objection, we won't get off of T0.
> 
> I'm not sure what the objection is there, unless it's from the mail
> systems admins. See, I think the downside to sender-pays
> stamp-generation at the MTA level is that, if you're a busy ISP and no
> one else is using sender-pays, you basically reduce your available CPU
> cycles for no discernable benefit.

that is one of the two arguments against naïve sender-pays as well as 
the source of the resistance by mail administrators.  They cannot 
comprehend that one can apply a predicate to the stamp generation 
process and reduce unnecessary stamps.  There is also an emotional 
reaction which is "why should I spend cycles so you can read my e-mail?" 
  there is a bit of arrogance in that "why should I do anything for 
anybody else.  I can just filter the spam out" while not recognizing 
that the filtering process actually contributes to the increase in spam.

The important aspect of deploying proof of work stamps is doing it in 
such a way that early adopters are not hurt but then it turns on 
automatically as adoption climbs hence my DNS-based predicate.

> 
> *I* would run sender-pays from postfix if there were an easy way to do
> it, but I don't push nearly the volume that a major ISP would. That's
> why I think that *validating* at the MTA might be useful, but that the
> stamps really should generally be minted by the MUA.

As soon as I publish my twopenny blue bzr repository, you will have all 
of the components you need to do that.  I have postfix pre-and 
post-queuing capability, message queuing and even a message format which 
will record important data elements about the message as it comes in.

You're more than welcome to slice and dice them any way you see fit. 
although I think you'll mostly need postfix_stamper.py and all of its 
associated bits of code.  one suggestion however, all of the traps and 
error checking are necessary because spammers write really crummy mail 
messages as a way of bypassing filters.

> 
> Think about it this way: a spammer isn't going to install sender-pays,
> and an ISP that is being used by a spammer essentially gets punished
> twice if they have sender-pays on the server side. Just my $0.02, but
> minting stamps really belongs in the MUA *unless* you have a dedicated
> MTA for things like mailing lists or legitimate e-commerce.

I agree.  But unless somebody's going to pull their thumb out and build 
a client-side proxy or plug-in, the best we've got right now is the 
various bits of work done by various people on this list.  The really 
sad thing is we are very close to multiple good solutions for different 
people but for some reason, we're not able to step over the line to 
something finished.

But I would also suggest considering this when looking at the end user 
versus centralized service model.  What is more work for a corporation 
or enterprise?  Changing everybody's desktop or running a server 
performing the desired operation?  Anyone who operates in enterprise 
environments will tell you, if they can do on a central server, they 
will do so because users are idiots and they don't want to have to deal 
with them any more than they have to.

ISPs on the other hand know their users are idiots and deal with them 
anyway.  So if they are going to run a stamping service how do they 
convince the user base to upgrade their software to be able to run 
client-side stamping?  The answer is they don't.  They will just shrug 
and say the solution is unacceptable.

Now a middle ground might be the Zombie idea developed by Jonathan 
Morton.  The Zombie is a stand-alone process that runs on a client 
machine and generates stamps.  We can make it more secure than the 
classic zombie so they can't be taken over.  The idea would be that the 
MTA meeting stamps would ask a zombie for a stamp.  It really doesn't 
matter which zombie as long as the zombie is free.  The stamp is 
generated at a leaf node and there is no excess load placed on the MTA.

The question is how do you secure the zombie engine and does this make 
the mail server a more valuable target of attack?  Would it make sense 
to limit stamps generated?  It's an interesting idea that is worth 
examining.  It's also easy to deploy in the sense that the user is 
running a new piece of software and not changing what they know. 
Enterprise deployment is also easier because you make it part of your 
centralized startup script for your Windows boxes or on your under 
loaded servers.  although I would suggest for enterprise deployment that 
the sales department funds their own mail server and spam generation 
capability.

But coming back to the load and hybrid issue.  What I am seeing today in 
relatively small enterprises is roughly and under 5% of total message 
volume stamp generation rate.  so you're looking at a relatively small 
number of stamps with the first generation of hybrid sender-pays.

>> Since hybrid sender-pays can reduce the cost of generating stamps to
>> almost nothing and the DNS info propagation method proposed can reduce
> 
> Lots of people implemented SPF records, but I don't know a lot of people
> who actually *use* them for filtering. There might be some, but I don't
> know any of them personally.
> 
> But it *is* a good example of how to increase uptake: the SPF folks
> created a web interface that made it trivial to create the appropriate
> SPF records, which people could then plug into their DNS. I still think
> that's beyond most end-users, but would be useful for a busy sysadmin
> who was willing to implement such a feature but didn't have enough time
> or interest to wrestle with the details.

Fair enough.  That makes a lot of sense.  SPF is not a useful antispam 
technique, it's a useful anti-forgery technique which merely limits one 
of the types of spam disguises.  But I think your point of giving them 
the tools and let them just cut and paste the text record makes a lot of 
sense.

> 
>> one way to prove the lack of damage is to run an e-mail service.
> 
> Creating a hashcash plugin for squirrelmail might be a quick way to
> generate some interest in that. Just a thought.

Okay, who knows Java and is willing to make a fast (only three X slower) 
stamp generator?  I've often thought the same thing about a generic 
"contact us" mailto.  can a mail-to include random headers in a message?
> 
>> if you want to have something like open PGP clear text signing, we
>> could create the equivalent of a multipart mime document in which one
> 
> Well, MIME attachments will increase the complexity and CPU cost of
> inbound filtering. I think the correct thing to do is create filtering
> mechanisms that can attach visible headers or mime attachments when a
> stamp is authenticated. For example, bogofilter creates the X-Bogosity
> headers that let you know what bogofilter thinks of the email, and MUAs
> like mutt display the validity of PGP attachments or inlines in the
> message body.
> I'd leave the X-Hashcash header alone, but suggest having hashcash
> itself create something like an X-Hashcash-Validated or
> X-Hashcash-Result field, instead of requiring the end user to shell out
> to something like procmail+hashcash+formail to generate one, because
> that creates some instant complexity.

do not let the thoughts of procmail, pine or mutt even enter your head. 
  Think Outlook first Thunderbird second.  There is no third.

I'm still not getting this however.  It may be the migraine and I'm 
being dim.  It seems like what you're saying is that the filter should 
attach some sort of a mime trailer indicating success or failure of 
stamp analysis.

Is this even close?

>> (maybe).  another advantage to multipart mime document form is
>> multi-parts stamps.  That instead of having a single 24-bit stamp, you
>> would use 16 20 bit stamps to reduce the variability of stamp search
>> time from message to message.
> 
> I'm not sure I follow that. How would that reduce CPU time?

It reduces time variability.  A search for a hash cash stamp is a linear 
process. 2^(n-1) average search time but the distribution of search 
terms is pretty much random as far as I understand it.  So sometimes 
they happen fast, sometimes they go very long.  But if you do a series 
of much smaller searches adding up to the same number of bits as the 
larger search, that variability averages out.  Not always but it's 
better than a single search variability.

others can probably explain this better than I can.
> 
>> One question would be what happens if you stand a gpg signed document?
> 
> I'm not sure I follow that either. What do you mean?

sorry about the speech recognition error.  If you had a mime attachment 
for holding stamps, and you also signed the document with gpg, would gpg 
be able to cope with a document that had the stamps attached post-signing?

---eric