3 ms·

The reason people choose Gmail or Office instead of smaller providers, is 1) They get less spam 2) Less likely get their mail market as spam. This centralizatio

by z3t4 7y ago

The reason people choose Gmail or Office instead of smaller providers, is 1) They get less spam 2) Less likely get their mail market as spam. This centralization is killing e-mail. But that's just e-mail. What protocols do people use to send messages ? Facebook messenger, Whatsapp, etc. More proprietary centralized solutions. We need a simple decentralized protocol, as simple as SMTP, bit it need to solve the spam issue, and it need not to be over-engineered (like XMPP). And no, it should not be built ontop of SMTP, SMTP has so many issues, like you can send mail pretending to be anyone. There are solutions like SPF, DKIM etc, but 1) they are built ontop of SMTP 2) They are not stopping spam. We need a new protocol that replaces SMTP, and have spam prevention, identify, etc built in.

dane-pgp 7y ago
Email could be free from spam if you configured your email client to only accept emails from people you manually added (and if SPF/DKIM was enforced). It's not clear how replacing SMTP with a different protocol would make the situation any better. The reason why centralised chat systems can limit spam is that one company gets to decide who can and can't send messages to whom. Recreating that in a decentralised architecture is precisely the problem that needs to be solved, and the solution could then be used by email providers. Now there are no technical reasons not to use SPF/DKIM, and recipients can enforce it more strictly, the problem seems to be determining which mail providers (i.e. which domains) can be trusted to stop their users from sending spam. Spammers have realised this too, of course, which is why a lot of spam comes from domains that are registered cheaply and quickly abandoned. One solution that might be worth exploring is requiring that domain registrants provide a bond to their registrar if they want to send mail from that domain (grandfathering in all existing domains). The bond could be refunded after, say, 12 months of sending enough emails that recipients don't mark as spam. The difficulty with this is creating a reporting mechanism that can't be gamed, either to unfairly cost a domain its bond, or to flood the system with fake positive reports to drown out the true negative ones. Fortunately, with DKIM, there is at least cryptographic proof that a given email was sent by a given domain.
- deleted 7y ago
  [deleted]
- z3t4 7y ago
  Messages should be sent from client to client. The server layer can be skipped. But the client could of course be a cloud based email solution. Messages would need double opt in, which would be baked into the protocol. Id's would be a random hash. Personal messages could be trust based eg. "Do i know this person" and corporates could use certificates. Once a user has opted in to receive messages from a id/hash the receiver would generate a challenge at the start of each session, either using a shared secret or public key crypto (also baked into the protocol). The protocol should have a standard for sending simple text. But then allow extension protocols, for example implementing voice/video. With capabilities eg. Client tells the other client what formats it accepts.

by z3t4 7y ago

dane-pgp 7y ago

Email could be free from spam if you configured your email client to only accept emails from people you manually added (and if SPF/DKIM was enforced). It's not clear how replacing SMTP with a different protocol would make the situation any better. The reason why centralised chat systems can limit spam is that one company gets to decide who can and can't send messages to whom. Recreating that in a decentralised architecture is precisely the problem that needs to be solved, and the solution could then be used by email providers. Now there are no technical reasons not to use SPF/DKIM, and recipients can enforce it more strictly, the problem seems to be determining which mail providers (i.e. which domains) can be trusted to stop their users from sending spam. Spammers have realised this too, of course, which is why a lot of spam comes from domains that are registered cheaply and quickly abandoned. One solution that might be worth exploring is requiring that domain registrants provide a bond to their registrar if they want to send mail from that domain (grandfathering in all existing domains). The bond could be refunded after, say, 12 months of sending enough emails that recipients don't mark as spam. The difficulty with this is creating a reporting mechanism that can't be gamed, either to unfairly cost a domain its bond, or to flood the system with fake positive reports to drown out the true negative ones. Fortunately, with DKIM, there is at least cryptographic proof that a given email was sent by a given domain.

deleted 7y ago
[deleted]
z3t4 7y ago
Messages should be sent from client to client. The server layer can be skipped. But the client could of course be a cloud based email solution. Messages would need double opt in, which would be baked into the protocol. Id's would be a random hash. Personal messages could be trust based eg. "Do i know this person" and corporates could use certificates. Once a user has opted in to receive messages from a id/hash the receiver would generate a challenge at the start of each session, either using a shared secret or public key crypto (also baked into the protocol). The protocol should have a standard for sending simple text. But then allow extension protocols, for example implementing voice/video. With capabilities eg. Client tells the other client what formats it accepts.