Re: ...

Re: ...

Robbert Haarman

2013-01-06

View parent message

Posted by inglorion
at 2006-04-27 08:09:04

Thanks for your comment, and apologies for taking so long to reply. The motherboard in my desktop machine broke down, which disrupted my workflow a bit.

I think you should know that I see emsg more as an interesting idea to explore than as the Final Ultimate Solution to Spam. However, your comment shows that at least some people see something in it, so perhaps it's worth the effort of identifying and solving the issues that come with it.

Addressing the points you made:

> It also causes problems with IPs/domains as everyone would have to go static.

Why would that be the case?

> 1) There's nothing to stop the box #1 'HTTP server' being malicious.

Indeed. No more as there is anything to stop a mail server from being malicious. Keep in mind that the idea behind emsg is to make messages more traceable. By storing them on a server associated with the sender instead of one associated with the receiver, we gain insight in who is approving the sending of these messages. If that server is malicious, we know that _that_ server is malicious, whereas with SMTP, the issue is less clear.

> 2) There's nothing to stop a possible box #3 visiting the same URL.

True. And it should generally be that way; at least I would want to be able to check my mail from any machine I happened to be using. Of course, what you are concerned about is privacy, and there you have a good point. However, there are a couple of things to observe here.

First of all, in some cases you might actually want a message to be publicly accessible. Secondly, there is no prescribed mechanism for generating these URLs. It's probably a good idea to make them hard to guess, and perhaps some information about the intended recipients should be encoded in them.

Thirdly, not a lot of privacy is offered by existing mail protocols; typically, a message travels through multiple hops to get to the recipients mailbox, where it is then accessed through username/password authentication. All of these steps are performed without any encryption, which means any of the intermediate nodes could inspect the message, and it's even possible (and actually pretty easy) to steal passwords and get full access to someone's mailbox.

Fourth, if a message is meant to be private, the sender probably knows the recipient to the extent that public key cryptography (e.g. PGP) can be used.

All in all, I think privacy is an issue which needs to be addressed, but good solutions are easy to obtain.

As for implementing a new prococol for message retrieval, I don't think that would be necessary. Once again, you raise the issue of identification of machines, and I will once again point out that: 1) you don't want to authenticate machines, you want to authenticate users 2) adequate mechanisms for user authentication already exist. In this specific case, HTTPS (HTTP over SSL) can be used to encrypt the transmission and authenticate the server, the client, or both; or plain HTTP could be used, with PGP on the message to authenticate the sender, the recipient, or both. There are plenty of other possibilities, as well.

Anyway, it's fun to think about this stuff once in a while. Thanks for your comments, and if you would like to continue the discussion, I would be glad to.