Joseph that looks like a promising start for an RFC but you need more detail, you mention a permission granting transaction that needs to be expanded upon with attention to what happens to legacy smtp clients in the transaction. You also mention some form of cryptographic authentication being used to validate the transaction and verify identification of the participants, this needs to be expanded upon, what are are the properties needed by the underlying crypto transaction, what preexisting protocols have those properties, and how would this work with extant TLS protocols.
Also a search of already accepted RFC's needs to be done so that conflicts and supersedure can be acknowledged. Looks good though. On Fri, 21 Feb 2003, Joseph Carter wrote: > No, the solution to the problem of spam exists, and it is indeed quite > simple in theory. It does, however, depend on a divergence from the > established SMTP mail protocol quite sharply, which means that the > simplicity of the solution is quite deceptive in the real world which > likes compatibility. > > you want > to send me any instant message, you must first have my permission to do > so. If you don't have permission, your message won't even be accepted by > some of the IM protocols out there. Asking for permission is seen as a > relatively low-bandwidth thing. > > What is needed then is a modern email protocol in which mail is never even > sent unless permission is granted to send it. If permission is not there, > the sender's server may instead send a VCard and ask you for authorisation > to send you mail. If you grant it, the mail gets sent to you. If not, it > rots on the sender's server until it expires. > > Obviously, tying the sender to a particular VCard you accepted is needed > and can be established through an ID mechanism and whatever allowed the > mail to be sent to you should be indicated in the delivered message (just > in case you decide that you want to move someone from your whitelist to > your blacklist..) > > > Three problems I see with my own thinking: > > - Anonymous email would be very difficult. The address from which the > message is sent really must actually belong to you in order for the > thing to get delivered. It'd still be possible to set up an anon mail > server along the lines of anon.penet.fi (which I assume most here are > old enough to remember), however remember that anon.penet.fi went away > as soon as someone decided to get a court order to compell the people > running the server to produce non-anonymous contact information. A > reasonably RFC-versed user can still produce mail that cannot be traced > back to them relatively easily. Spammers have been abusing this for > years, but there are certain valid uses of it that would be lost. > > - An email ID and the authentication used with it need to be reasonably > secure against cryptographic attacks. At some point there needs to be > a token that a person has which allows them to email you, and that > token must be unique to you and to them. If this token can be found by > a third party, spammers can send you mail claiming to be someone else. > On the other hand, direct mail would not need to be taboo as it is with > many ISPs today since you must actually own the address which sends the > message in order for it to verify. Obviously using an open relay would > be a bad idea, and if you have the option, it's better to deliver the > message yourself. > > - Mailing lists would become somewhat interesting.. I would require an > auth to be able to send mail to the list. My messages whould then be > sent out to the group, using the list's authentication to send the > message. Obviously any permission denied means unsub the person, and > the list server would be responsible for holding the message for a > period of time or not if auth is pending. This is a very big change to > how lists work today, obviously. > > > I've also been considering how you would gate traditional email clients > and traffic into this sort of system as a transition mechanism. I've got > ideas for how to do that with the clients, but it seems to boil down to an > address at your ISP which serves as a mail bot to handle the directory for > authentications.. (Noteworthy is that a directory service is necessary in > order to make the list of users and auths not just terribly suck!) > > Gating all of this into traditional ISP-to-ISP SMTP would kinda defeat the > purpose to some extent, but it's clear that this will need to be done for > at least a time. Unfortunately I fear that it might lead to the problem I > have with Jabber - I have it and it's great and everything, but most of > the people I communicate with through it use ICQ and have little interest > in using something else, tying me to the bugs and limitations found within > the ICQ/AIM protocol. _______________________________________________ Eug-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
