next »

[inp o҉rtb]

So, I have this idea for a distributed communication system (sort of like email) based on HTTP. Let's call this HTMP, or HyperText Mail Protocol. The problem with email is that it's difficult to verify the identity of the sender; only the identity of the recipient is known. Hence, spiced ham.

Well, in HTMP, you get to verify the identity of the sender. Each HTMP address is a URI. So if Alice wants to send a message to Bob, she'd post it off to uri-B. Now, the server managing uri-B has no idea which user sent the message (except that the sender claimed to be Alice), so it does a bit of handshaking with the server managing uri-A. How should this handshaking work?

I have a preliminary idea; please let me know if this makes sense. Here's an analogy with phone calls:

1) Alice calls Bob
2) Bob answers, but doesn't have caller ID and isn't sure of her identity... so he asks Alice for a callback number
3) Alice gives Bob a number where he could reach her
4) Bob recognizes that it is, indeed, Alice's number (if not, the handshake fails)
5) The connection is dropped
6) Bob calls Alice and asks if they were just having a conversation on the other line
7) Alice confirms that they were just having a conversation on the other line (if not, the handshake fails)
x) Alice and Bob pick up the conversation

What do you think? If this works, it could become part of a simple protocol for sendmail-fsockopen-less mailing =p

[islesv]

It is in step 4 (Bob recognizing that the URI given by Alice as Alice' URI) where the protocol will fail:
1.) Where would Bob get the knowledge that the URI is really Alice' URI?
2.) Even if Bob will be able to verify that the URI given by the one who pretended to be Alice is actually Alice URI, there is still a possibility that this information was known from somewhere, hence, again a fail.

In my understanding, the only way that this can be done is through some POST mechanism. So Alice posts something to http://domain/some_index_file?parameters. (The actual message will be part of the URI parameters.) Part of the protocol should be a "return address", where Bob will post his "return address".

Let's continue discussing, I'm also interested in this topic.

--Vincent Isles

[inp o҉rtb]

Hm, good points.

Alice and Bob know each other's phone numbers. Why? Because they met at a party and exchanged contacts
Seriously, though, they need to have exchanged contacts through a more trustable protocol. Even face-to-face meetings could be faked, where one dresses up and wears a mask. We're assuming that face-to-face would be equivalent in reliability to traditional exchange methods.

Let's say that an attacker actually tells Bob Alice's phone number. Well, when Bob calls up Alice, Alice would not know what he's talking about and the handshake would fail here. Unless... Alice is cooperating with the attacker, in which case it would be Alice's responsibility.

That's also like a permanent whitelist mechanism -- Bob _has_ to know Alice's phone number if he is to accept her calls. So Bob can post his number in forums everywhere without fear of getting random calls. What if you want to contact Bob but he hasn't added you? I guess we'll have to work out a mechanism to make your existence known to Bob without letting the spammers win.

Even if you _were_ a spammer, your URI would be a handle where the cops could reach you. You can't spoof that, remember -- Bob has to call you back. ;]

[robleyd]

What about using something along the lines of PGP to identify?

[inp o҉rtb]

Yes! Cryptographic signatures would work very well. Now, if only I could get this done in PHP

[robleyd]

Well, have a look at http://pecl.php.net/package/gnupg - maybe that could be a starting point :-0

[inp o҉rtb]

mmm I guess I'll leave that to the mail clients

Meanwhile, the callback-style handshake is working pretty well. I guess as long as the messages are trackable, people would have to think twice before sending spam. Currently, HTMP places emphasis on the sender -- instead of the sender pushing messages into the recipient's inbox as in SMTP, the recipient has to download the messages from the sender's server.

[islesv]

Currently, HTMP places emphasis on the sender -- instead of the sender pushing messages into the recipient's inbox as in SMTP, the recipient has to download the messages from the sender's server.

I think that sentence should have read "HTMP places emphasis on the receiver". That is, the receiver is just informed that there is a message for him; he has a choice to receive or not that message. The power of spam lies in the fact that even if I don't like to receive the message, I will be forced to see it. In HTMP (if I understood it correctly), the receiver is told "Boss, you have a message from SENDER". If Boss doesn't want SENDER because he doesn't know her, then the message is technically not even delivered.

--Vincent Isles

[inp o҉rtb]

That is indeed the case. It should reduce bandwidth usage somewhat as well as spam. I guess we could be more specific: with HTMP, the recipient pulls messages from the sender; whereas with SMTP, the sender pushes messages to the recipient.

[islesv]

with HTMP, the recipient pulls messages from the sender; whereas with SMTP, the sender pushes messages to the recipient.

It this is a novel idea or have I read this somewhere? Can you start the coding now inp o҉rtb? I'll gladly volunteer my services for alpha testing!

--Vincent Isles

[Slittzle]

the hardest part is finding the correct number for someone you hadn't met but still want to communicate with (eg: initiating contact) and secondly ensuring that the id can't be faked or brute forced.

[inp o҉rtb]

Indeed, that is very difficult to do. But I imagine that making every message trackable would be a good start at making people responsible for their mailings.

Thanks for the interest! I do have some code. Right now it's just me messaging myself, but I'll start making more accounts soon ^.^ (after just a bit more coding...)

[islesv]

the hardest part is finding the correct number for someone you hadn't met but still want to communicate with (eg: initiating contact)

What do you mean? It's just the same as an email address: you won't know my email address if I won't tell you. The difference is, if I tell you, you can send me spam right away, unlike this system inportb had conceptualized where the best that you can is to tell me that you have a message from you--I can choose to download or not your message.

and secondly ensuring that the id can't be faked or brute forced.

I can of course say that I am inportb and can give you (in a forum like this) the public address where you can tell me that there's a message for me. But just the same with an email address; I can come up with a king.of.france@somewhere.com right now.

--Vincent Isles

[inp o҉rtb]

Hmmm looks like we _can_ use RSA/DSA public key cryptography. We've got this installed here: http://www.php.net/openssl

### EDIT ###
Here's a tentative user interface... http://www.inportb.com/mailfeed/

### EDIT ###
Well, it's not so tentative now: http://www.110mb.com/forum/empty-t25514.0.html