From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] spam rejection after reception does have limits Message-ID: <20030928101050.J27821@cackle.proxima.alt.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from ron minnich on Sat, Sep 27, 2003 at 04:46:50PM -0600 Date: Sun, 28 Sep 2003 10:10:50 +0200 Topicbox-Message-UUID: 51e499c4-eacc-11e9-9e20-41e7f4b1d025 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 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).