Re: mozilla camram/hashcash discussion (Re: [Bug 229686] Request : Support for HashCash type of SPAM protection)

Adam Back wrote:
> Re the discussion in mozilla bugzilla about camram and hashcash
> integration approaches.
>=20
> 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=20
create a more extensible e-mail infrastructure.  One where external=20
programs can gain access to different parts of the information flow and=20
analyze/consume/modify messages passing through.  Otherwise we have just=20
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).
>=20
> 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=20
is a no bullshit administrative assistant.  I can just see the raised=20
eyebrow and swinging foot aimed at my backside if I gave her that kind=20
of a user interface.  She is extremely comfortable with task oriented=20
interfaces.  I.e. if she's doing e-mail, she has an e-mail client.  If=20
she's doing spam processing, she has a spam filter user interface.  One=20
of the things that make the camram interface usable is that it is, for=20
the most part, single function.  You only do what is necessary for=20
sorting spam.  If you can tell everything from the main display, you=20
just checked a box which declares it spam or not spam.

now if I understand what were proposing correctly, I think it is overly=20
complicated.  In my perspective, the inbox is the place you put messages=20
that you haven't filtered elsewhere.  I still believe there should be a=20
separate view/task mechanism for sorting the indeterminate messages.=20
Additionally, the dumpster should be managed separately because it is=20
expired daily to keep it from getting too big, it is an automatic=20
destination just like the inbox although not for a good reason and, the=20
workflow in managing it is different from the spamtrap and the inbox.=20
One could argue however that if it truly is a mailbox, then it should=20
have the same sets of operations as the inbox... I need to think about=20
that one.

remember, our targets audience is the technologically naive user that=20
has a small amount of trouble finding their butt with both hands.  I've=20
personally consider the current Mozilla model of spamtrap flags on the=20
inbox a UI disaster.  It takes you away from the focus of your main task=20
(i.e. reading/sorting e-mail).  It also mixes in good e-mail with=20
indeterminant messages and increases the amount of potential spam a user=20
might see.

Yes, could you make it work, yes but it would be so painful and only=20
further reinforces the image of anti spam as being difficult to use.=20
And if anybody says that users have learned how to use the current=20
interface and seemed happy with it, should be reminded of rather brutal=20
experiments in which monkeys were trained to new behaviors through=20
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.
>=20
> 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.
>=20
> For standardization the machine processability seems ok.
>=20
> 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=20
had access to certain parts of the stream from external programs, then=20
we would be good to create this kind of thing without any problem.=20
We're going to need it anyway if my hypothesis about dynamically=20
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=20
working within Mozilla folks if you truly believe that your suggestions=20
are the right way to go.  I must speak out because I have unfortunately=20
been suffering with bad user interfaces for far too long starting with=20
Microsoft and ending with almost every cripplingly bad user interface=20
created by any coding monkey that wielded a GUI creation tool. (but=20
other than that Mrs. Lincoln, how did you like the play)

---eric