Re: [9fans] spam rejection after reception does have limits

[Lucio De Re <lucio@proxima.alt.za>]

On Sat, Sep 27, 2003 at 04:46:50PM -0600, ron minnich wrote:
>
> We have a half-working solution now on 9grid. I agree with everything
> everyone has said about the limitations of import /mail/box but I don't
> see the current SMTP-based systems lasting a whole lot longer if you can't
> even say
>
> Subject: Thank you
>
> in a mail message.
>
Choate is quite correct <default disclaimer> that the solution is
not a technological one, but a social one.  It has always been: in
NetNews, the recommended response to unacceptable behaviour was to
ignore it, which still applies, in spades.

Not reject it, not get angry about it, simply ignore it, as early
as possible.

Choate suggests legal recourse, within the existing system.  Again,
harrassment could be used, I think it would work if one could target
the perpetrator rather than some innocent, unwitting victim.

Our job is to provide the tools that make prosecution possible,
together with the features that diminish unprosecuted/unprosecutable
harrassment to a level where communication is not worse than lack
of communication.  But the objective will be to get rid of SPAM
and e-mail viruses altogether, whether attainable or not.

9grid proposes a distributed mailbox.  We have that already, just
a different model, the difference is that the new model is still
under development and does not carry the legacy baggage of RFC821/2
with it.  I don't think it's such a big deal to admit that RFC821/2
are obsolete (I do mean RFC2822 and any other successor as well)
and that a new approach is required.  The difficulties can be
listed:

	- Legacy: can't be helped, that's where the problem lies
	in the first place.

	- Acceptance: critical mass problem, will probably sort
	itself out, possibly making somebody very, very rich.

	- Design: Once the actual issues are properly identified,
	there is really very little left other than redefine the
	concepts of RFC821/2 for a new world order.  One can even
	safely discard all the legacy stuff that RFC822 addressed
	as it no longer exists.  Of course, one can jump into the
	breach and provide a totally new solution (distributed
	fileservices for mailboxes), but that's a technicality.
	I'm sure even Collyer will agree.

So what are the issues?

	- Unsolicited mail: I want to be able to send some, receive
	some, but most of it is unwanted.  Maybe the "Don't speak
	to strangers" rule applies and one ought to get an
	introduction.  Historically, it seems to me this has happened
	before (the Renaissance?).  It puts certain introduction
	agents in an enviable position, but then they probably are
	there because they can be trusted (notaries, that type of
	thing, perhaps?).

	  I think it boils down to identity and I think the PEM
	people and the ITU-T tried to provide a mechanical solution
	to a political problem and we may have to undo this.  As
	long as a technical solution is sought or believed to be
	valid, there will be an option for social enginnering to
	subvert it.

	- Theft of Identity: somebody has hijacked a trusted
	identity.  We've lived with this for a long time, one makes
	it as difficult as possible for the identity to be stolen,
	then makes is as easy as possible to recover from the
	damage.  A Choate solution would report it to the "authorities",
	in my understanding of Choate's opinion more to deter future
	perpetrators than to punish the current one.  It's a
	judgement call, my opinion is more neutral, but doesn't
	conflict with Choate's and certainly requires an "authority"
	capable of prosecuting a perpetrator.

	  How one persuades a sensitive organisation to disclose
	such attacks when it may damage its reputation?  By
	threatening with much more damaging sanctions if it doesn't.
	Yet another social rather than technical solution.  But
	the tools are technological ones and need careful design
	not to become a form of oppression.

I'm sure I ought to list more issues and problems, but this is
boring enough, let someone else add to this list.  Keep in mind
that I believe Ron is right: we don't have a lot of time left.

++L

PS: I don't have a problem with each mail recipient acting as its
own CA and issuing certificates left, right and centre that can be
used to further certify agents on behalf of the sender.  X.509's
certification hierarchy allows for this and it may be best employed
as a certification audit trail.  I'm not (yet) competent enough to
code the tools to create and inspect such a certification audit
trail, but I believe there is ample competence on this list to do
it, and do it timeously.

PPS: Choate, I hope I haven't ruined your reputation irreparably
by agreeing with you.  I certainly could have miscronstrued your
opinions and I apologise in advance if I did.  Please do not hesitate
to correct me (in private would be preferable, I won't hesitate to
issue public corrections if required).