Something i'm realizing more and more... What the hell do I really need remotely hosted mail for?
We all know mail is insecure. Unless you look really really hard, you aren't sure if the mail you received was spoofed or modified, a child can spoof mail and any MitM can modify it. So in general you can't trust your mail anyway, even if it's received by a reputable company. Sending mail is almost just as subjective... a random ISP's mail smarthost is just as good for getting your mail delivered as a hosted mail provider.
All I really need is a way to get my mails, once. Once you have the mail, you can back it up to an infinite number of places (Git repository, anyone?) if in the future you need to search it.
So really, the only thing I need is 1) to receive mail, 2) to filter the spam, and 3) to keep a backup of my mail somewhere.
Considering this, why do we even need domain-specific mail? Like, myusername at Gmail dotcom, for example. I don't need it sent to GMail... I need it sent to me. I don't care what server receives it. I don't even need to store my mail there once i've read it - I can keep it offline, and back it up to remote repositories to search. With a format + protocol like Git, this would be fast, efficient, reliable, secure, and compatible.
So really, if we just had a distributed decentralized peer-to-peer mail network, a unique address system, and a retrofitted mail storage protocol (IMAP5?), we could send mail anywhere, receive it anywhere, store it anywhere, and spam could be filtered by whatever product or company was hosting your Git backup. With the new address system we could even build in personal crypto keys and teach people how to send real, honest-to-god, secure mails, potentially even anonymously.
Now somebody tell me how someone already thought of this and how it won't work :-)
Fighting spam (solely) by analyzing its contents turns out to not really work that well. You also need to be very picky about which SMTP servers you will accept mail from.
In practice, this means that if you do not route your outbound mail through a reputable hosted mail provider, it is significantly likely that messages will not make it through to their recipients. Even if you do SPF/DKIM/etc correctly. SMTP servers are not interchangeable. They have reputations, and the IP address blocks they reside in have reputations.
That doesn't always mean Fastmail/GMail/Live, etc. Businesses do run their own Exchange servers successfully. They do so from high-quality IP address space which is closely guarded, not handed out to any idiot with a cable modem (most recipients blacklist all residential IP address space) or $5 (cheap hosting providers are similarly suspect).
I can keep it offline
You are referring to POP, which predates IMAP - the server just gives you the new emails since last checkin, and then they are gone (from the server's perspective). If you use multiple computers, or a computer and a smartphone, this really sucks. Most people are not going to hack together Git and rsync; they want the same view of their email on whatever device. So we get IMAP.
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.
Urbit seems to try to provide a centralized, personalized model for application services. I don't think centralizing is the way to go, mainly because my entire digital life is dependent on de-centralizing all my services. They try to make it out to be like some kind of container you can put anywhere, but that's like saying we should all use one kind of bag for everything we ever need to carry in our daily lives. There's good reasons I have 10 different kinds of bags at home.
Comments
Something i'm realizing more and more... What the hell do I really need remotely hosted mail for?
We all know mail is insecure. Unless you look really really hard, you aren't sure if the mail you received was spoofed or modified, a child can spoof mail and any MitM can modify it. So in general you can't trust your mail anyway, even if it's received by a reputable company. Sending mail is almost just as subjective... a random ISP's mail smarthost is just as good for getting your mail delivered as a hosted mail provider.
All I really need is a way to get my mails, once. Once you have the mail, you can back it up to an infinite number of places (Git repository, anyone?) if in the future you need to search it.
So really, the only thing I need is 1) to receive mail, 2) to filter the spam, and 3) to keep a backup of my mail somewhere.
Considering this, why do we even need domain-specific mail? Like, myusername at Gmail dotcom, for example. I don't need it sent to GMail... I need it sent to me. I don't care what server receives it. I don't even need to store my mail there once i've read it - I can keep it offline, and back it up to remote repositories to search. With a format + protocol like Git, this would be fast, efficient, reliable, secure, and compatible.
So really, if we just had a distributed decentralized peer-to-peer mail network, a unique address system, and a retrofitted mail storage protocol (IMAP5?), we could send mail anywhere, receive it anywhere, store it anywhere, and spam could be filtered by whatever product or company was hosting your Git backup. With the new address system we could even build in personal crypto keys and teach people how to send real, honest-to-god, secure mails, potentially even anonymously.
Now somebody tell me how someone already thought of this and how it won't work :-)
Fighting spam (solely) by analyzing its contents turns out to not really work that well. You also need to be very picky about which SMTP servers you will accept mail from.
In practice, this means that if you do not route your outbound mail through a reputable hosted mail provider, it is significantly likely that messages will not make it through to their recipients. Even if you do SPF/DKIM/etc correctly. SMTP servers are not interchangeable. They have reputations, and the IP address blocks they reside in have reputations.
That doesn't always mean Fastmail/GMail/Live, etc. Businesses do run their own Exchange servers successfully. They do so from high-quality IP address space which is closely guarded, not handed out to any idiot with a cable modem (most recipients blacklist all residential IP address space) or $5 (cheap hosting providers are similarly suspect).
You are referring to POP, which predates IMAP - the server just gives you the new emails since last checkin, and then they are gone (from the server's perspective). If you use multiple computers, or a computer and a smartphone, this really sucks. Most people are not going to hack together Git and rsync; they want the same view of their email on whatever device. So we get IMAP.
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.
Blockchain mail, anyone?
- Available anywhere
- Guaranteed notarized sending, guaranteed total ordering of messages
- Privacy and security built into the protocol.
The incentives aren't there -- what would miners get in this scenario? Also doing it in a way that retains perfect forward secrecy will be tricky.
Could be a startup idea.
Exists already as bitmessage
Funny. You just described a perfect fit for Urbit.
Urbit seems to try to provide a centralized, personalized model for application services. I don't think centralizing is the way to go, mainly because my entire digital life is dependent on de-centralizing all my services. They try to make it out to be like some kind of container you can put anywhere, but that's like saying we should all use one kind of bag for everything we ever need to carry in our daily lives. There's good reasons I have 10 different kinds of bags at home.
Open to flood poisoning.