Why SMTP still matters today(resend.com)
resend.com
Why SMTP still matters today
https://resend.com/blog/why-smtp-still-matters-today
38 comments
Yes - an actual article on SMTP in 2023 would be interesting. This isn't even an article that pushes a product - it's just an ad with a couple of paragraphs for background.
Who cares if the title is enough to trigger a discussion on the subject, facilitate sharing of opinions and bring some useful insights to some participants at least (which is often the case for the news in the HN top)? As for me I rarely even go by the title links to see the actual articles :-)
That's not true about the nothing of value, It helps keep my flagging finger strong and nimble through lots of use....
>We want email to feel like the web, modern and cutting edge.
Chill down my spine.
Chill down my spine.
Followed by:
> This is why we support modern technologies like React for email building and Serverless for sending.
They are referring to the generation and sending of emails not suggesting some radical change. Serverless for email and DSLs (like React) for email temples are not new concepts either.
> This is why we support modern technologies like React for email building and Serverless for sending.
They are referring to the generation and sending of emails not suggesting some radical change. Serverless for email and DSLs (like React) for email temples are not new concepts either.
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.
Aversion to standards is why the internet has become this closed hellscape.
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.
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.
* 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.
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"
* And it's "the arpanet"
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.
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.
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.
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.
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.
WebDAV?
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
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
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?
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?
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.
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.
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.
> 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.
Sure, but when it did arrive and largely replaced POP3 it could as well replace SMTP for the client.
While email is an application that is, for example, tightly tied to DNS (check the SOA record), SMTP is a protocol that has got a lot of improvements, addenda, enhacements and the likes.
But, IMHO, it is far from being comparable in features and security with other (modern) communication protocols like XMPP.
SMTP and XMPP do not exactly accomplish the same goal, nor have the same intentions. Sure, they both overlap in areas, but they're both interfaces (protocols) for implementation of tools. Tools that are suited for certain jobs.
Modern XMPP solved problem of loosing messages silently when a TCP connection is broken only with one of later added XEPs extensions while ancient SMTP did it from the beginning (a messages will be retried unless there was a response to dot command). Probably SMTP authors better understood how TCP works. Modern is not automatically implies that lessons of the past was learned.
I think the real question is if you ever see SMTP ever getting replaced by a newer protocol
If JMAP catches on for client-to-server, maybe that could inspire a replacement server-to-server mail protocol.
https://www.ietf.org/blog/jmap/
https://www.ietf.org/blog/jmap/
smap?
I don't think so, at this point SMTP is more than just a protocol for sending - it's how you integrate multiple email services into one single interface.
SMTP is as much a protocol for sending as it is for receiving. IMAP isn't a "receive emails" protocol, as much as it is a "manage mails on a server" protocol.
I'm not sure if people working with these protocols have built applications implementing their specifications before, but they should. It affords you a much better picture of why these protocols are designed as they are, good and bad.
I'm not sure if people working with these protocols have built applications implementing their specifications before, but they should. It affords you a much better picture of why these protocols are designed as they are, good and bad.
It could, I don't think there is really that many big players. If those agree to something and then start moving towards it others might follow.
I'd guess it will evolve and/or accrete bolt-ons to meet new use cases (e.g. MIME), much like HTTP and any number of protocols have.
in part, this is a chicken-and-egg question. To effect this kind of change, there needs to be a reference implementation of sufficiently high quality to get and keep people's interest, and there needs to be sufficient force of will to complete this to get people using it.
Funny i just created an expect tcl script to do SMTP sends. I’ll add these folks to my relay list!
I discovered how much i like expect/tcl. There’s no need to use a library. A simple 100 line script does what i need.
I discovered how much i like expect/tcl. There’s no need to use a library. A simple 100 line script does what i need.
Why do we even use SMTP and IMAP when we could be using XMPP instead?
I know there are some caveats preventing XMPP from becoming the one protocol to rule all the chats, but why not use it for email exchange?
I know there are some caveats preventing XMPP from becoming the one protocol to rule all the chats, but why not use it for email exchange?
Thank you for this ad. Other than that, the article adds nothing of value.