8 ms·

People keep banging on about "plain text, plain text" what is wrong with plain text? And what is wrong with SMTP? Also email attachments can be binary encoded,

People keep banging on about "plain text, plain text" what is wrong with plain text? And what is wrong with SMTP? Also email attachments can be binary encoded, base64 is just one option. People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case. And "there are multiple different implementations" is a pretty poor justification, as a SMTP replacement would likely have the same issue (or worse).

laumars 13y ago
> People keep banging on about "plain text, plain text" what is wrong with plain text? Well it's not exactly secure, for one thing. > Also email attachments can be binary encoded, base64 is just one option. base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP. > People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case. Actually I have given a long list of reasons every time I've complained about SMTP[1][2] [1] https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5510910 [2] https://news.ycombinator.com/item?id=5297472 https://news.ycombinator.com/item?id=5297472
- UnoriginalGuy 13y ago
  >Well it's not exactly secure, for one thing. No more or less secure than HTTP/HTTPS. In fact exactly as secure as... >base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP. http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc2045 http://tools.ietf.org/html/rfc2045 http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding >Actually I have given a long list of reasons every time I've complained about SMTP >https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5297472 https://news.ycombinator.com/item?id=5297472 Your list is full of misinformation. - Base64 thing is nonsense. As already stated SMTP supports binary and has for a long time. - SMTPS is fairly well supported. In fact I currently connect to nothing which lacks it, and my email client auto-selects it when setting up new connections. Most of the hosts as far as I know support SMTPS out-of-the-box. - SMTP reply codes are standardised (http://www.ietf.org/rfc/rfc1893.txt http://www.ietf.org/rfc/rfc1893.txt) - HTML is standardised. - SMTP is not designed to be real-time. That is what IM is designed to provide.
  - laumars 13y ago
    > No more or less secure than HTTP/HTTPS. In fact exactly as secure as... HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So SMTPS is less secure than HTTPS. > http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc3030 It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Most of the SMTP servers I've dealt with have archived and transmitted binary content over base64. > Your list is full of misinformation. Please don't be rude. And to address your bullet points: - already addressed the binary / base64 remark - already addressed the SMTPS remark - yes, but those response codes are rarely transmitted back up the stack (and when they are, with a horribly garbled error). I'm talking about rebuilding the entire stack - from client to server - so that users get meaningful responses. - of course HTTP is standardised. I never said it wasn't. So please don't turn this into a dumb trolling match where you make shit up to win an argument. - I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Simply citing IM's as an argument misses the point. IM's are for conversations. Emails are for memos. There's no reason why memo's shouldn't be sent real time. In fact, Android's Gmail notifications are real time. Exchange pushes mail to Outlook clients in real time. There's no reason why real-time shouldn't be the standard for all e-mails. (note: we're not talking about real time character update. Just a standard system for pushing messages instead of the client periodically polling for updates).
    - UnoriginalGuy 13y ago
      > HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So in this instance SMTPS is less secure than HTTPS. Sorry, not following you. HTTPS and SMTPS are both end to end encryption schemes. In fact they both use SSL in a similar way to secure traffic. > It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it. Which mail server and version in particular are you having issues with? In general almost all of the "big names" in mail servers support more than just base64 as standard. > yes, but those response codes are rarely transmitted back up the stack I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT). > I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).
dsr_ 13y ago
Multiple implementations are a strength. In fact, you won't see a good replacement for SMTP without multiple independent implementations. (What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers. Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.)
- laumars 13y ago
  I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well. I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on. The problem isn't so much that we have multiple implementations (I agree that can potentially be a strength). The problem is that there's very little that's consistent across the platforms.
  - npsimons 13y ago
    I'd like to see the HTML that is supported in e-mails standardised Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
    - laumars 13y ago
      While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads. </sarcasm> We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already). At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)
freehunter 13y ago
>what is wrong with plain text? Plain text means anyone can read your message while it's going over the wire. That person sitting next to you in the coffee shop? He's running a packet sniffer and is reading everything you send, because it's plain text. -- edit: In information security, plaintext means unencrypted. That's true for SMTP, and that's what I'm referring to. Am I wrong?
- UnoriginalGuy 13y ago
  > Plain text means anyone can read your message while it's going over the wire. Plain text is a style of encoding information (e.g. binary, XML, JSON, plain text, etc). Encryption determines if someone can intercept your message. Something can be both plain text and secure, like HTTPS for one example.
  - Osmium 13y ago
    It's my understanding that people often use "plaintext" in contrast to "ciphertext", so it's not unreasonable for someone to read "plaintext" and think "unencrypted".
    - npsimons 13y ago
      Except in a discussion such as this one, where we're explicitly talking about Google locking out competitors by replacing plain (ASCII) text protocols with proprietary binary ones.
      - laumars 13y ago
        To be fair, this discussion is a huge tangent about e-mail protocols. So both definitions of plain text could be contextually valid.
    - daeken 13y ago
      I've been trying to force myself to use "cleartext" instead of "plaintext" to alleviate this ambiguity. It's remarkably hard to do after so long, though.
jfb 13y ago
I'm interested in djb's IM2000 [1] proposal. Change the underlying model from a postal service one; adapt the infrastructure to the use cases. "Plain text" is not the problem with SMTP. [1] http://cr.yp.to/im2000.html http://cr.yp.to/im2000.html

laumars 13y ago

> People keep banging on about "plain text, plain text" what is wrong with plain text? Well it's not exactly secure, for one thing. > Also email attachments can be binary encoded, base64 is just one option. base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP. > People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case. Actually I have given a long list of reasons every time I've complained about SMTP[1][2] [1] https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5510910 [2] https://news.ycombinator.com/item?id=5297472 https://news.ycombinator.com/item?id=5297472

UnoriginalGuy 13y ago
>Well it's not exactly secure, for one thing. No more or less secure than HTTP/HTTPS. In fact exactly as secure as... >base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP. http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc2045 http://tools.ietf.org/html/rfc2045 http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding >Actually I have given a long list of reasons every time I've complained about SMTP >https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5297472 https://news.ycombinator.com/item?id=5297472 Your list is full of misinformation. - Base64 thing is nonsense. As already stated SMTP supports binary and has for a long time. - SMTPS is fairly well supported. In fact I currently connect to nothing which lacks it, and my email client auto-selects it when setting up new connections. Most of the hosts as far as I know support SMTPS out-of-the-box. - SMTP reply codes are standardised (http://www.ietf.org/rfc/rfc1893.txt http://www.ietf.org/rfc/rfc1893.txt) - HTML is standardised. - SMTP is not designed to be real-time. That is what IM is designed to provide.
- laumars 13y ago
  > No more or less secure than HTTP/HTTPS. In fact exactly as secure as... HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So SMTPS is less secure than HTTPS. > http://tools.ietf.org/html/rfc3030 http://tools.ietf.org/html/rfc3030 It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Most of the SMTP servers I've dealt with have archived and transmitted binary content over base64. > Your list is full of misinformation. Please don't be rude. And to address your bullet points: - already addressed the binary / base64 remark - already addressed the SMTPS remark - yes, but those response codes are rarely transmitted back up the stack (and when they are, with a horribly garbled error). I'm talking about rebuilding the entire stack - from client to server - so that users get meaningful responses. - of course HTTP is standardised. I never said it wasn't. So please don't turn this into a dumb trolling match where you make shit up to win an argument. - I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Simply citing IM's as an argument misses the point. IM's are for conversations. Emails are for memos. There's no reason why memo's shouldn't be sent real time. In fact, Android's Gmail notifications are real time. Exchange pushes mail to Outlook clients in real time. There's no reason why real-time shouldn't be the standard for all e-mails. (note: we're not talking about real time character update. Just a standard system for pushing messages instead of the client periodically polling for updates).
  - UnoriginalGuy 13y ago
    > HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So in this instance SMTPS is less secure than HTTPS. Sorry, not following you. HTTPS and SMTPS are both end to end encryption schemes. In fact they both use SSL in a similar way to secure traffic. > It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it. Which mail server and version in particular are you having issues with? In general almost all of the "big names" in mail servers support more than just base64 as standard. > yes, but those response codes are rarely transmitted back up the stack I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT). > I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).

dsr_ 13y ago

Multiple implementations are a strength. In fact, you won't see a good replacement for SMTP without multiple independent implementations. (What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers. Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.)

laumars 13y ago
I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well. I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on. The problem isn't so much that we have multiple implementations (I agree that can potentially be a strength). The problem is that there's very little that's consistent across the platforms.
- npsimons 13y ago
  I'd like to see the HTML that is supported in e-mails standardised Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
  - laumars 13y ago
    While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads. </sarcasm> We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already). At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)

freehunter 13y ago

>what is wrong with plain text? Plain text means anyone can read your message while it's going over the wire. That person sitting next to you in the coffee shop? He's running a packet sniffer and is reading everything you send, because it's plain text. -- edit: In information security, plaintext means unencrypted. That's true for SMTP, and that's what I'm referring to. Am I wrong?

UnoriginalGuy 13y ago
> Plain text means anyone can read your message while it's going over the wire. Plain text is a style of encoding information (e.g. binary, XML, JSON, plain text, etc). Encryption determines if someone can intercept your message. Something can be both plain text and secure, like HTTPS for one example.
- Osmium 13y ago
  It's my understanding that people often use "plaintext" in contrast to "ciphertext", so it's not unreasonable for someone to read "plaintext" and think "unencrypted".
  - npsimons 13y ago
    Except in a discussion such as this one, where we're explicitly talking about Google locking out competitors by replacing plain (ASCII) text protocols with proprietary binary ones.
    - laumars 13y ago
      To be fair, this discussion is a huge tangent about e-mail protocols. So both definitions of plain text could be contextually valid.
  - daeken 13y ago
    I've been trying to force myself to use "cleartext" instead of "plaintext" to alleviate this ambiguity. It's remarkably hard to do after so long, though.

jfb 13y ago

I'm interested in djb's IM2000 [1] proposal. Change the underlying model from a postal service one; adapt the infrastructure to the use cases. "Plain text" is not the problem with SMTP. [1] http://cr.yp.to/im2000.html http://cr.yp.to/im2000.html