[hashcash] Re: mozilla camram/hashcash discussion (Re: [Bug 229686] Request: Support for HashCash type of SPAM protection)
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: Adam Back <adam@xxxxxxxxxxxxxxx>
- Date: Mon, 05 Apr 2004 19:57:59 -0400
Adam Back wrote:
> Re the discussion in mozilla bugzilla about camram and hashcash
> integration approaches.
>
> I think perhaps what the mozilla guys will want to hear is something
> mozilla centric.
that might be true. I personally think that this highlights a need to
create a more extensible e-mail infrastructure. One where external
programs can gain access to different parts of the information flow and
analyze/consume/modify messages passing through. Otherwise we have just
swapped one kingdom for another.
> My thought is the mozilla-centric way to express the full CR camram
> approach is to talk about the netscape spam-filter as the spam-filter,
> the mozilla-mail spam marked messages as the spam-trap. (They are not
> actually in a separate folder (by default -- perhaps you can override
> this to make them be so), but there are folder view options where you
> can hide them. You can edit and so train this by changing the view so
> you can see both spam and non spam marked messages turning on clicking
> on the little spam icon to to undo false positives, and clicking to
> mark as spam for false negatives. (Well actually you can do false
> negatives in spam-free view).
>
> Could this view be used as the spam-trap? Seems maybe could. Getting
> out of the spam trap would just be a subsequent stamp would promote it
> from likely spam to non-spam.
I'm installing camram at a small research lab nearby. My main test case
is a no bullshit administrative assistant. I can just see the raised
eyebrow and swinging foot aimed at my backside if I gave her that kind
of a user interface. She is extremely comfortable with task oriented
interfaces. I.e. if she's doing e-mail, she has an e-mail client. If
she's doing spam processing, she has a spam filter user interface. One
of the things that make the camram interface usable is that it is, for
the most part, single function. You only do what is necessary for
sorting spam. If you can tell everything from the main display, you
just checked a box which declares it spam or not spam.
now if I understand what were proposing correctly, I think it is overly
complicated. In my perspective, the inbox is the place you put messages
that you haven't filtered elsewhere. I still believe there should be a
separate view/task mechanism for sorting the indeterminate messages.
Additionally, the dumpster should be managed separately because it is
expired daily to keep it from getting too big, it is an automatic
destination just like the inbox although not for a good reason and, the
workflow in managing it is different from the spamtrap and the inbox.
One could argue however that if it truly is a mailbox, then it should
have the same sets of operations as the inbox... I need to think about
that one.
remember, our targets audience is the technologically naive user that
has a small amount of trouble finding their butt with both hands. I've
personally consider the current Mozilla model of spamtrap flags on the
inbox a UI disaster. It takes you away from the focus of your main task
(i.e. reading/sorting e-mail). It also mixes in good e-mail with
indeterminant messages and increases the amount of potential spam a user
might see.
Yes, could you make it work, yes but it would be so painful and only
further reinforces the image of anti spam as being difficult to use.
And if anybody says that users have learned how to use the current
interface and seemed happy with it, should be reminded of rather brutal
experiments in which monkeys were trained to new behaviors through
conditioning with painful electric shocks. Our users deserve better.
> The last part would be issuing of DSN or whatever notifications and
> processing of the responses.
>
> I suspect this last one is what would most likely make mozilla as a
> MUA feel this was more than they wanted to go direct into a MUA,
> rather than as 3rd party add on because it results in mixed
> human/machine readable mail messages being sent which are not (at this
> point) RFC compliant. If we could move these notifications towards
> standardization, perhaps.
>
> For standardization the machine processability seems ok.
>
> But human readability seems more challenging -- what goes there (up to
> implementation?) and presumably on the scale of mozilla there can not
> be direct web pointers there due to overload / centralization, so all
> that could go there would be download software pointers, perhaps.
see my comments above about an improved external agent interface. If we
had access to certain parts of the stream from external programs, then
we would be good to create this kind of thing without any problem.
We're going to need it anyway if my hypothesis about dynamically
adjustable postage rates works out.
> Just thinking aloud to think about how one would go towards mozilla
> supporting camram (and bare hashcash).
they are good thoughts. And please do let me discourage you from
working within Mozilla folks if you truly believe that your suggestions
are the right way to go. I must speak out because I have unfortunately
been suffering with bad user interfaces for far too long starting with
Microsoft and ending with almost every cripplingly bad user interface
created by any coding monkey that wielded a GUI creation tool. (but
other than that Mrs. Lincoln, how did you like the play)
---eric
Other related posts:
