I'm not referring to POP or IMAP. I can keep my mail offline in any format I choose, anywhere I want. It's just text records. I can keep it in a .pst file, in a Maildir, in an mbox, behind an MUA or any mail retrieval protocol/service. My point was that using a repository like Git, you can simply store your mails (after you receive them, using any mechanism you choose) and then replicate them anywhere, and use any method you choose to interface with the repository later. Think of Git as your mbox or Maildir, and IMAP5 as the protocol+service to interface with it.
The reputation system is a relic of domain-hosted mail. We don't need to rely on it, it's just necessary for the current mail paradigm.
Crypto signatures from/to recipients could help this. You could register your personal signature with a notary, and the network could validate it before sending or receiving. You can then extend the cryptographically-secure identity into any other system you want to determine whether you want to accept the mail.
--
Example 1:
User A wants to send mail to User B. User A and User B both have crypto signatures distributed through notary services on the network. User A connects to a New-SMTP (NSMTP) service called "ZomboCom" and initiates sending a mail. The ZomboCom service checks the signature on the mail, and it's valid on the network. It also checks the recipient signature, and it's also valid on the network. It then accepts the mail. Then, ZomboCom can route the mail, or advertise it for delivery.
User B uses three different NSMTP services - "Flooz", "Webvan", and "eToys". User B has registered their signature with them all, and each validated the signature, and all of them agree to receive mail on behalf of User B.
An additional service can exist on the network which routes users to registered services - a Message Routing service. Flooz, Webvan and eToys can all register themselves with the Message Routing network as valid recipients for User B. When ZomboCom wants to deliver a message to User B, it can simply query which providers are listed as recipients for User B. It can verify they are real providers by cryptographically verifying the records against User B's public crypto key, which is in a different network service, the Public Key service.
So, ZomboCom connects to each of Flooz, Webvan, and eToys, and sends them a notification that there is a message waiting to be delivered for User B. Each one determines they do indeed receive mail for User B, and each then connects to ZomboCom and initiates receiving the mail. They each check User A's signature against a list of revoked signatures, and a separate list of "bad senders". If there is no bad flag, they receive the mail and store it.
Flooz, Webvan and eToys all store the mail in a Git repository for the user. The user can then retrieve their mail by merging each service's repository into their own. They can purge their repositories, edit history to remove old mail, whatever. Since every message is cryptographically signed/hashed, duplicates are easy to identify and ignore. If any one provider stops working, the other will have received the message already.
Example 2:
Spammer wants to send mail to User B. Before the message can make it into the network, they need a crypto signature to sign their mails with.
Even if they run their own NSMTP server, all the recipient servers will be verifying Spammer's crypto signature before accepting. Each server can in turn subscribe to lists of revoked signatures, so if Spammer abuses the privilege of sending and is flagged as a spammer, these different recipient servers are just not going to accept their mail.
Of course, we're still using IP addresses on the low level, so you can always reject connections from certain IP blocks if you want.
--
I should note that almost all of this could be implemented using existing infrastructure. The Git repository and and IMAP5 protocol could be implemented separately by clients and MDAs if they chose, but would not be required for the network component at all; you could do this with existing IMAP4 servers, and provide the p2p network as a way to interface with existing SMTP servers.
Comments
I'm not referring to POP or IMAP. I can keep my mail offline in any format I choose, anywhere I want. It's just text records. I can keep it in a .pst file, in a Maildir, in an mbox, behind an MUA or any mail retrieval protocol/service. My point was that using a repository like Git, you can simply store your mails (after you receive them, using any mechanism you choose) and then replicate them anywhere, and use any method you choose to interface with the repository later. Think of Git as your mbox or Maildir, and IMAP5 as the protocol+service to interface with it.
The reputation system is a relic of domain-hosted mail. We don't need to rely on it, it's just necessary for the current mail paradigm.
Crypto signatures from/to recipients could help this. You could register your personal signature with a notary, and the network could validate it before sending or receiving. You can then extend the cryptographically-secure identity into any other system you want to determine whether you want to accept the mail.
--
Example 1:
User A wants to send mail to User B. User A and User B both have crypto signatures distributed through notary services on the network. User A connects to a New-SMTP (NSMTP) service called "ZomboCom" and initiates sending a mail. The ZomboCom service checks the signature on the mail, and it's valid on the network. It also checks the recipient signature, and it's also valid on the network. It then accepts the mail. Then, ZomboCom can route the mail, or advertise it for delivery.
User B uses three different NSMTP services - "Flooz", "Webvan", and "eToys". User B has registered their signature with them all, and each validated the signature, and all of them agree to receive mail on behalf of User B.
An additional service can exist on the network which routes users to registered services - a Message Routing service. Flooz, Webvan and eToys can all register themselves with the Message Routing network as valid recipients for User B. When ZomboCom wants to deliver a message to User B, it can simply query which providers are listed as recipients for User B. It can verify they are real providers by cryptographically verifying the records against User B's public crypto key, which is in a different network service, the Public Key service.
So, ZomboCom connects to each of Flooz, Webvan, and eToys, and sends them a notification that there is a message waiting to be delivered for User B. Each one determines they do indeed receive mail for User B, and each then connects to ZomboCom and initiates receiving the mail. They each check User A's signature against a list of revoked signatures, and a separate list of "bad senders". If there is no bad flag, they receive the mail and store it.
Flooz, Webvan and eToys all store the mail in a Git repository for the user. The user can then retrieve their mail by merging each service's repository into their own. They can purge their repositories, edit history to remove old mail, whatever. Since every message is cryptographically signed/hashed, duplicates are easy to identify and ignore. If any one provider stops working, the other will have received the message already.
Example 2:
Spammer wants to send mail to User B. Before the message can make it into the network, they need a crypto signature to sign their mails with.
Even if they run their own NSMTP server, all the recipient servers will be verifying Spammer's crypto signature before accepting. Each server can in turn subscribe to lists of revoked signatures, so if Spammer abuses the privilege of sending and is flagged as a spammer, these different recipient servers are just not going to accept their mail.
Of course, we're still using IP addresses on the low level, so you can always reject connections from certain IP blocks if you want.
--
I should note that almost all of this could be implemented using existing infrastructure. The Git repository and and IMAP5 protocol could be implemented separately by clients and MDAs if they chose, but would not be required for the network component at all; you could do this with existing IMAP4 servers, and provide the p2p network as a way to interface with existing SMTP servers.