Nadav Har'El wrote:
Maybe we shouldn't really discuss all the details on this list (after
all, it's supposed to be a linux list),
From the number of responses, I got the impression that many people who
are subscribed to this list are interested in this subject. Indeed,
spam is a big problem for all E-mail users (I don't think there are any
exceptions, besides spammers themselves). But if you prefer, we can
continue discussing this subject on "The Business of Software" forum,
instead of this mailing list. Just reply to this thread:
http://discuss.joelonsoftware.com/default.asp?biz.5.153447.3
but I (and Eran) already mentioned
why a cryptographic confirmation of who sent the mail isn't always desired.
SPF strikes a delicate balance: you can be quite sure that the mail indeed
comes from the domain it says it does, but you have to trust this domain
owner not to falsify the user's name. Also, you know that the mail comes
from a certain domain, but you can't *prove* it to anyone else (because
the "proof" - the email itself - could be something you simply made up).
This means that as a user, you have "plausible deniability" (your email
can't be taken against you in court). This is a desirable property, for
most people.
Even now, any E-mail you send can be used against you in court.
Although you can deny it, and there is no proof you really sent it. But
personally I think it would be better if we could be more certain who
sent E-mail messages to us. Although, from my experience, impersonating
is very rare (not including spam and phishing, of course). For example,
you would probably assume that it's me (Uri) sending this message and
not someone else. So it wouldn't matter so much for me if there would
be a technical proof for it. If I wouldn't want someone to know that
I'm writing a specific message, I wouldn't use my name and E-mail
address. With my proposed solution you could still be able to create
another identity (another E-mail address) and send E-mail from it. But
you wouldn't be able to send mail from [EMAIL PROTECTED] (for example),
which is desirable. Right now it's technically possible for anybody to
send mail from [EMAIL PROTECTED], although in some sense it's illegal.
But spammers don't care much about laws.
By the way, I think one of the main reasons Yahoo started using
DomainKeys, is because many spammers were spoofing their domain name
(yahoo.com). With DomainKeys they are not able to do it, but it is not
suitable for many small companies or domain owners. Not every company
can control the mail servers where their users send mail from.
Actually, most companies don't.
I'm interested to hear some day how you plan to do this :-)
In particular, I wonder if you are you relying on a central "Trent"
(trusted company that runs this entire email business) to do all the
book-keeping, limitations, and so on, or keeping the decentralized
structure of email?
The implementation still needs to be worked out. It's possible that it
will require a central entity to control it. As I said, there are other
things which rely on a central entity, such as the DNS and SSL
certificates. Actually, almost anything on the Internet will not work
without DNS [to be more specific, the world wide web (HTTP) and E-mail
(SMTP) will not work without it], yet we still rely on the entities who
control it. So E-mail is already dependent on central entities for it
to function.
Good luck. May the source be with you :-)
Thanks!
Have you ever wondered why almost no individual owns a certificate signed
by one of the browser-recognized registrars? Heck, some organizations I
know even don't have them, and sign their own certificates on their
https site. It's because the certification process is too expensive and
complex for ordinary users to go through. It's certainly completely out
of the questions for the hoards of free-email users.
SSL's PKI (public key infrastructure) was supposed to allow a lot of things.
Among these things, you also have "client certificates" - each user would
have a certificate in his browser, and use it to log in, and so on,
instead of passwords. But this initiative never took off. Why? Because
users can't deal with the beurocracy and costs involved. I am afraid that
your solution will face the same problems.
OK, we can do without SSL certificates, but we can't do without domain
names and DNS. Some things have to be centralized. But I agree that my
proposed solution will have to deal with a lot of beurocracy.
Best Regards,
Uri Even-Chen
Speedy Net
Raanana, Israel.
E-mail: [EMAIL PROTECTED]
Phone: +972-9-7715013
Website: www.uri.co.il
--------------------------------------------------------
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
