5 ms·

I don't even understand why do email clients have to use a dedicated protocol (let alone SMTP) for email sending. If I were developing an email client and didn'

I don't even understand why do email clients have to use a dedicated protocol (let alone SMTP) for email sending. If I were developing an email client and didn't care about established conventions, I would just make it put outgoing email to a dedicated folder via IMAP and let the server pick it there and go on sending it to recipients servers over SMTP.

stbenjam 3y ago
Aversion to standards is why the internet has become this closed hellscape.
- qwerty456127 3y ago
  We also had a dedicated protocol for file transfer, you know, FTP, and now it appears nobody needs it anymore as HTTPS is enough for everything.
  - PedroBatista 3y ago
    Careful with the generalizations, the ability to drag&drop a bunch of files to the browser and upload them to some server in a reliable way across all major browsers is very recent. Also, try to create a web app that mimics a FTP server. ( a real production one ) you’ll see how much FTP does and you didn’t know.
    - qwerty456127 3y ago
      I personally wish FTP would have stayed or replaced by a better yet direct successor dedicated for its function. Because I don't like all these "cloud drives" implemented as browser+native apps instead of an open protocol everyone could implement.
      - yetanotherloss 3y ago
        SFTP exists but never really took off for anonymous usage modes as people were already being conditioned to use browsers and cramming everything into HTTP.
      - dale_glass 3y ago
        WebDAV?
  - layer8 3y ago
    HTTPS is no replacement for FTP’s “cloud drive” functionality, that is, interoperability with the local file system. WebDAV could theoretically be, but clients and servers never reached the usability of FTP. The best FTP successor is still SFTP.
  - gumby 3y ago
    BTW the first mail transport on the arpanet* was...FTP! Yes, FTP used to have specific mail transfer commands different from regular file transport. * And it's "the arpanet"
  - dale_glass 3y ago
    FTP is an absolutely horrible protocol. It's better off dead. * It's a pain in the butt with NAT, which is something that unfortunately has to be accounted for in the internet these days. * NAT traversal requires deep packet inspection and is a bloody pain, because since IP addresses and ports are written in text it means that packet sizes may change, requiring the rewrite of every single packet afterwards at a serious performance cost. * No SSL for you on the data channel due to this either. * The binary/ASCII mode is awful * Data transfer lacks good status indications. Is the data socket close an end of file, or a problem to be reported? * Directory listing is not standard and has a dozen possible formats * The entire protocol is made for interactive commandline use, which is really an annoyance in modern times. * Anonymous access requires a fake, non-standard login. Which sometimes requires reading the MOTD, but see above. Fortunately we do have a replacement: WebDAV. Layers on nicely on top of HTTP and backwards compatible with it, goes trivially through firewalls, can be encrypted, directly listings are standard, and highly amenable to automation and GUIs. It's also well supported and you can mount WebDAV servers as a share easily.
wongarsu 3y ago
Part of the reason is that SMTP predates IMAP by a decade. And even in the early 2000s many email providers didn't offer IMAP. Their view of an email service was much simpler: there's a queue of incoming emails you can fetch with POP, and a queue of outgoing emails you can append to via IMAP. Having folders and most of the state of the email client synced to the server via IMAP is a radically different philosophy that only became useful when you logged in from multiple devices
- qwerty456127 3y ago
  I liked this approach. For myself I would still prefer it over everything else. However, once everyone rolled out IMAP and deprecated (explicitly or implicitly) POP, why didn't they also deprecate SMTP (for clients) in favour of clients just putting outgoing mail to an Outbox folder over IMAP?
  - layer8 3y ago
    The clients doing SMTP themselves allows them to communicate sending failures to the user. How would you do that for an email just sitting in an IMAP folder? You’d need to define and integrate some “sending” protocol into IMAP. Furthermore, there are many use cases where clients only send, like notification emails or sending reports. Those use cases would become more complicated if the clients were forced to use IMAP. For one, you wouldn’t want to give all of them access to all email in other folders — or even to emails in the outbox sent by other clients.
    - qwerty456127 3y ago
      Makes sense, thanks. > The clients doing SMTP themselves allows them to communicate sending failures to the user. How would you do that for an email just sitting in an IMAP folder? I would introduce a folder for logs. Also make the server move messages it succesfully sent from Outbox to Sent folder. By the way, I wish the whole email system would have been extended to make it possible to attach (not in the way we attach files, not integrated in the message, only visible to the owner/admin of the mail box where the message is stored, not communicated to other servers/clients) comments to email messages so I would be able to attach my thoughts&tags to a message I received and the server could attach diagnostic data about delivery details.

stbenjam 3y ago

Aversion to standards is why the internet has become this closed hellscape.

qwerty456127 3y ago
We also had a dedicated protocol for file transfer, you know, FTP, and now it appears nobody needs it anymore as HTTPS is enough for everything.
- PedroBatista 3y ago
  Careful with the generalizations, the ability to drag&drop a bunch of files to the browser and upload them to some server in a reliable way across all major browsers is very recent. Also, try to create a web app that mimics a FTP server. ( a real production one ) you’ll see how much FTP does and you didn’t know.
  - qwerty456127 3y ago
    I personally wish FTP would have stayed or replaced by a better yet direct successor dedicated for its function. Because I don't like all these "cloud drives" implemented as browser+native apps instead of an open protocol everyone could implement.
    - yetanotherloss 3y ago
      SFTP exists but never really took off for anonymous usage modes as people were already being conditioned to use browsers and cramming everything into HTTP.
    - dale_glass 3y ago
      WebDAV?
- layer8 3y ago
  HTTPS is no replacement for FTP’s “cloud drive” functionality, that is, interoperability with the local file system. WebDAV could theoretically be, but clients and servers never reached the usability of FTP. The best FTP successor is still SFTP.
- gumby 3y ago
  BTW the first mail transport on the arpanet* was...FTP! Yes, FTP used to have specific mail transfer commands different from regular file transport. * And it's "the arpanet"
- dale_glass 3y ago
  FTP is an absolutely horrible protocol. It's better off dead. * It's a pain in the butt with NAT, which is something that unfortunately has to be accounted for in the internet these days. * NAT traversal requires deep packet inspection and is a bloody pain, because since IP addresses and ports are written in text it means that packet sizes may change, requiring the rewrite of every single packet afterwards at a serious performance cost. * No SSL for you on the data channel due to this either. * The binary/ASCII mode is awful * Data transfer lacks good status indications. Is the data socket close an end of file, or a problem to be reported? * Directory listing is not standard and has a dozen possible formats * The entire protocol is made for interactive commandline use, which is really an annoyance in modern times. * Anonymous access requires a fake, non-standard login. Which sometimes requires reading the MOTD, but see above. Fortunately we do have a replacement: WebDAV. Layers on nicely on top of HTTP and backwards compatible with it, goes trivially through firewalls, can be encrypted, directly listings are standard, and highly amenable to automation and GUIs. It's also well supported and you can mount WebDAV servers as a share easily.

wongarsu 3y ago

Part of the reason is that SMTP predates IMAP by a decade. And even in the early 2000s many email providers didn't offer IMAP. Their view of an email service was much simpler: there's a queue of incoming emails you can fetch with POP, and a queue of outgoing emails you can append to via IMAP. Having folders and most of the state of the email client synced to the server via IMAP is a radically different philosophy that only became useful when you logged in from multiple devices

qwerty456127 3y ago
I liked this approach. For myself I would still prefer it over everything else. However, once everyone rolled out IMAP and deprecated (explicitly or implicitly) POP, why didn't they also deprecate SMTP (for clients) in favour of clients just putting outgoing mail to an Outbox folder over IMAP?
- layer8 3y ago
  The clients doing SMTP themselves allows them to communicate sending failures to the user. How would you do that for an email just sitting in an IMAP folder? You’d need to define and integrate some “sending” protocol into IMAP. Furthermore, there are many use cases where clients only send, like notification emails or sending reports. Those use cases would become more complicated if the clients were forced to use IMAP. For one, you wouldn’t want to give all of them access to all email in other folders — or even to emails in the outbox sent by other clients.
  - qwerty456127 3y ago
    Makes sense, thanks. > The clients doing SMTP themselves allows them to communicate sending failures to the user. How would you do that for an email just sitting in an IMAP folder? I would introduce a folder for logs. Also make the server move messages it succesfully sent from Outbox to Sent folder. By the way, I wish the whole email system would have been extended to make it possible to attach (not in the way we attach files, not integrated in the message, only visible to the owner/admin of the mail box where the message is stored, not communicated to other servers/clients) comments to email messages so I would be able to attach my thoughts&tags to a message I received and the server could attach diagnostic data about delivery details.