4 ms·

>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.

>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).
  - laumars 13y ago
    > 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. Yeah sorry, I explained my point abysmally there. What I meant was e-mails are only encrypted on a node-to-node basis but obviously a proportion of that transport isn't over SMTP. (My complaints are about the entire e-mail stack where as you're focusing on just SMTP, so there may have been a degree of us talking past each other). > 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). We're definitely talking past each here. I'm on about client side not server side. (I should have been more clear from the outset that my complaints are about the entire email stack rather than specifically against SMTP) > 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). None of that is really an issue though. 1) we already have mail servers that retry for hours 2) we already have instant push mechanisms for e-mails on phones 3) you're actually reducing the network overhead by eliminating the POP3/IMAP handshakes every n minutes in favor of an idle TCP/IP connection with periodic pings. > 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? Maybe the base64 conversion is happening at my end then. It's never caused an issue as such (we have the capacity to cope with base64), it was just one of many niggles with the mismatch of the whole ecosystem. But I'll happily concede that I was wrong about the binary point :) (I don't particularly want to announce to the world what software and versions we're running at work for reasons that I hope you appreciate)

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).
- laumars 13y ago
  > 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. Yeah sorry, I explained my point abysmally there. What I meant was e-mails are only encrypted on a node-to-node basis but obviously a proportion of that transport isn't over SMTP. (My complaints are about the entire e-mail stack where as you're focusing on just SMTP, so there may have been a degree of us talking past each other). > 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). We're definitely talking past each here. I'm on about client side not server side. (I should have been more clear from the outset that my complaints are about the entire email stack rather than specifically against SMTP) > 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). None of that is really an issue though. 1) we already have mail servers that retry for hours 2) we already have instant push mechanisms for e-mails on phones 3) you're actually reducing the network overhead by eliminating the POP3/IMAP handshakes every n minutes in favor of an idle TCP/IP connection with periodic pings. > 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? Maybe the base64 conversion is happening at my end then. It's never caused an issue as such (we have the capacity to cope with base64), it was just one of many niggles with the mismatch of the whole ecosystem. But I'll happily concede that I was wrong about the binary point :) (I don't particularly want to announce to the world what software and versions we're running at work for reasons that I hope you appreciate)