3 ms·

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

> 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)
- jimbobimbo 13y ago
  I think I follow your point about SMTP being secure only node-to-node, but doesn't S/MIME (PGP, etc.) solve the problem of security?
  - laumars 13y ago
    Totally, but that's not standardised across the clients either (plus there's a few different competing solutions for e-mail encryption). This is why I want to redesign the entire stack - to ensure that such solutions are standard across the ecosystem and available by default.

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)

jimbobimbo 13y ago
I think I follow your point about SMTP being secure only node-to-node, but doesn't S/MIME (PGP, etc.) solve the problem of security?
- laumars 13y ago
  Totally, but that's not standardised across the clients either (plus there's a few different competing solutions for e-mail encryption). This is why I want to redesign the entire stack - to ensure that such solutions are standard across the ecosystem and available by default.