4 ms·

Can you give some examples? I've never seen any mentioned.

by darau1 5y ago

pfranz 5y ago
Sending private information is the first thing I think of--from a bunch of aspects. Secure in transit has had a bunch of different, awkward implementations. My biggest concern is sending tax documents and it sitting in someone's archive folder (or sent folder) for years until their account is compromised. So I often have organizations that send email pointing to their proprietary webmail. The alternative is sneakernet, hard copies, or even faxing.
- darau1 5y ago
  Unless you physically hand your taxes in, isn't any solution technically vulnerable to being compromised? Also, wouldn't encryption fix this problem? I don't understand how it might be implemented in the real world, but if you encrypt with your private key, then their public key the message should be safe in transit, and at rest (unless they leave it decrypted on disk)
  - pfranz 5y ago
    > Unless you physically hand your taxes in, isn't any solution technically vulnerable to being compromised? If that's all there is to it, then why do people use other solutions? > Also, wouldn't encryption fix this problem? Kind of. The problem is the protocol and lack of consensus prevents this from being feasibly implemented. Personally, I think encryption in transit is a low probability threat for me. I would also like certain data to "expire" or go into "cold storage" after a period of time. Sending it in a side-channel, like Dropbox or Google Drive means I can delete it or revoke access after a period of time but this breaks email.
paxys 5y ago
End-to-end encryption, large attachments, managing group messages (aka "reply all" problem), changing message subject, quoted messages when replying, HTML/CSS formatting, sorting/labeling/folders, tracking protections, sending messages over websocket, heck even basic message threading. None of this works consistently across different clients.
- darau1 5y ago
  But those are problems with /the client/. Not the protocol.
  - paxys 5y ago
    They are all problems with the protocol, considering that the protocol doesn't define how to do any of this.
    - darau1 5y ago
      Then should we not amend the protocol to define these things? Why reinvent the wheel, when we could improve it?
      - paxys 5y ago
        Yes we should, but people have been trying for 20 years and it hasn't happened yet. The wheel has been successfully reinvented already. The biggest reason for it is that in practice email isn't as open and decentralized as people like to think. For most of its history all advancements were controlled by Microsoft, AOL and Yahoo, and today it is controlled by Microsoft and Google.
      - jjav 5y ago
        > Then should we not amend the protocol to define these things? Most of the OP list of things they don't like are about client UI presentation. Inherently unrelated to the protocol itself. I don't have any of those issues because I use a client that does the interaction and presentation exactly how I like it.
        darau1 5y ago
        What client is that?
        jameshart 5y ago
        I don’t understand how your client can solve for someone else sending you top-quoted replies, or word-html-engine compatible HTML designed to work in outlook. Or eighty other people hitting reply all on the email chain you’re on. The clients other people use can behave completely differently, because the protocol leaves so many decisions up to clients.
lmm 5y ago
Email has: no shared concept of a group/channel/... no shared history support no shared concept of a thread no consistency about how previous replies are referred to (e.g. different quoting styles) no real identity support ...
- chii 5y ago
  > no shared concept of a group/channel/... mailing lists > no shared history support Your own client or provider can store history. you also don't own someone else's history - a good feature imo. > no consistency about how previous replies are referred to (e.g. different quoting styles) A preference for individuals to decide. > no real identity support What's a "real" identity? my email address is my identity.
  - lmm 5y ago
    > mailing lists Not understood at the protocol level, not visible as such in the client. > Your own client or provider can store history. you also don't own someone else's history - a good feature imo. It's a nightmare in practice. Catching someone up on a conversation ends up being a mess of forwarding multiple overlapping but partially distinct emails and then constantly having to resend messages as different people get dropped in different replies. Exiting such a conversation is even harder. > A preference for individuals to decide. The cost is much bigger than the benefit. > What's a "real" identity? my email address is my identity. There's no authentication. You can't associate yourself with multiple organisations except by using multiple addresses, and then there's no way to reflect that those are somehow the same.

Can you give some examples? I've never seen any mentioned.

by darau1 5y ago

Can you give some examples? I've never seen any mentioned.

Sending private information is the first thing I think of--from a bunch of aspects. Secure in transit has had a bunch of different, awkward implementations. My biggest concern is sending tax documents and it sitting in someone's archive folder (or sent folder) for years until their account is compromised. So I often have organizations that send email pointing to their proprietary webmail. The alternative is sneakernet, hard copies, or even faxing.

darau1 5y ago
Unless you physically hand your taxes in, isn't any solution technically vulnerable to being compromised? Also, wouldn't encryption fix this problem? I don't understand how it might be implemented in the real world, but if you encrypt with your private key, then their public key the message should be safe in transit, and at rest (unless they leave it decrypted on disk)
- pfranz 5y ago
  > Unless you physically hand your taxes in, isn't any solution technically vulnerable to being compromised? If that's all there is to it, then why do people use other solutions? > Also, wouldn't encryption fix this problem? Kind of. The problem is the protocol and lack of consensus prevents this from being feasibly implemented. Personally, I think encryption in transit is a low probability threat for me. I would also like certain data to "expire" or go into "cold storage" after a period of time. Sending it in a side-channel, like Dropbox or Google Drive means I can delete it or revoke access after a period of time but this breaks email.

paxys 5y ago

End-to-end encryption, large attachments, managing group messages (aka "reply all" problem), changing message subject, quoted messages when replying, HTML/CSS formatting, sorting/labeling/folders, tracking protections, sending messages over websocket, heck even basic message threading. None of this works consistently across different clients.

darau1 5y ago
But those are problems with /the client/. Not the protocol.
- paxys 5y ago
  They are all problems with the protocol, considering that the protocol doesn't define how to do any of this.
  - darau1 5y ago
    Then should we not amend the protocol to define these things? Why reinvent the wheel, when we could improve it?
    - paxys 5y ago
      Yes we should, but people have been trying for 20 years and it hasn't happened yet. The wheel has been successfully reinvented already. The biggest reason for it is that in practice email isn't as open and decentralized as people like to think. For most of its history all advancements were controlled by Microsoft, AOL and Yahoo, and today it is controlled by Microsoft and Google.
    - jjav 5y ago
      > Then should we not amend the protocol to define these things? Most of the OP list of things they don't like are about client UI presentation. Inherently unrelated to the protocol itself. I don't have any of those issues because I use a client that does the interaction and presentation exactly how I like it.
      - darau1 5y ago
        What client is that?
      - jameshart 5y ago
        I don’t understand how your client can solve for someone else sending you top-quoted replies, or word-html-engine compatible HTML designed to work in outlook. Or eighty other people hitting reply all on the email chain you’re on. The clients other people use can behave completely differently, because the protocol leaves so many decisions up to clients.

lmm 5y ago

Email has: no shared concept of a group/channel/... no shared history support no shared concept of a thread no consistency about how previous replies are referred to (e.g. different quoting styles) no real identity support ...

chii 5y ago
> no shared concept of a group/channel/... mailing lists > no shared history support Your own client or provider can store history. you also don't own someone else's history - a good feature imo. > no consistency about how previous replies are referred to (e.g. different quoting styles) A preference for individuals to decide. > no real identity support What's a "real" identity? my email address is my identity.
- lmm 5y ago
  > mailing lists Not understood at the protocol level, not visible as such in the client. > Your own client or provider can store history. you also don't own someone else's history - a good feature imo. It's a nightmare in practice. Catching someone up on a conversation ends up being a mess of forwarding multiple overlapping but partially distinct emails and then constantly having to resend messages as different people get dropped in different replies. Exiting such a conversation is even harder. > A preference for individuals to decide. The cost is much bigger than the benefit. > What's a "real" identity? my email address is my identity. There's no authentication. You can't associate yourself with multiple organisations except by using multiple addresses, and then there's no way to reflect that those are somehow the same.