3 ms·

I was one who suggested Dropbox as a replacement for attachments (although it was really just an example, I don't even use Dropbox personally), and the point I

by aethr 15y ago

I was one who suggested Dropbox as a replacement for attachments (although it was really just an example, I don't even use Dropbox personally), and the point I was trying to make is that you can either have flexibility, or you can have standardization. The OP is suggesting we somehow standardize email error messages, but this doesn't seem possible while email remains a free-form, very simple protocol, which gets used for an infinite number of different purposes by different people. "Fix what's currently wrong with email" is so overly vague as to be basically meaningless. Different people have completely different ideas about what is "wrong" with email, and it is such an entrenched technology that you will almost certainly never be able to make structural changes to it unless the problem set it addresses is radically diminished.

kijin 15y ago
I don't see any reason why something like SMTP error messages can't be standardized if several major e-mail software vendors and related groups get together and agree to implement, over a period of 5-10 years, an extension to SMTP. Sure, it might not be as clean as rewriting the protocol from scratch, but it would work for all practical purposes. A lot of features of HTTP that we take for granted, like cookies and anti-clickjacking headers, were added through a similar process. The problem is political and economic, not technical. I also don't see anything wrong with having a free-form, vendor-neutral, decentralized messaging protocol that can be used for a million different purposes. As long as the underlying protocol itself is reliable (e.g. it has proper error handling) and extensible (e.g. you can add custom headers and MIME types that other software won't mess with), innovators are free to implement whatever functionality they want on top of that protocol. Heck, Richard Stallman uses e-mail to browse the web! If you restrict the protocol to what you think should be its only purpose, you're unnecessarily limiting what other people can do with it. That would be like restricting HTTP to hypertext documents only, no AJAX, no API calls, no streaming. IMO, e-mail doesn't need to become a TODO list or notification system. When I say "fix it", I mean we should clean up old cruft from the protocol (e.g. make it 8-bit clean) and make it extensible so that it is not too difficult for interested parties to implement a TODO list, notification system, etc. on top of it if they want to. People will obviously disagree about how exactly that should be done, but people disagree about everything anyway.

by aethr 15y ago

kijin 15y ago

I don't see any reason why something like SMTP error messages can't be standardized if several major e-mail software vendors and related groups get together and agree to implement, over a period of 5-10 years, an extension to SMTP. Sure, it might not be as clean as rewriting the protocol from scratch, but it would work for all practical purposes. A lot of features of HTTP that we take for granted, like cookies and anti-clickjacking headers, were added through a similar process. The problem is political and economic, not technical. I also don't see anything wrong with having a free-form, vendor-neutral, decentralized messaging protocol that can be used for a million different purposes. As long as the underlying protocol itself is reliable (e.g. it has proper error handling) and extensible (e.g. you can add custom headers and MIME types that other software won't mess with), innovators are free to implement whatever functionality they want on top of that protocol. Heck, Richard Stallman uses e-mail to browse the web! If you restrict the protocol to what you think should be its only purpose, you're unnecessarily limiting what other people can do with it. That would be like restricting HTTP to hypertext documents only, no AJAX, no API calls, no streaming. IMO, e-mail doesn't need to become a TODO list or notification system. When I say "fix it", I mean we should clean up old cruft from the protocol (e.g. make it 8-bit clean) and make it extensible so that it is not too difficult for interested parties to implement a TODO list, notification system, etc. on top of it if they want to. People will obviously disagree about how exactly that should be done, but people disagree about everything anyway.