Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This is the mail system

dewith.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: This is the mail system

#41

Post by aethr »

kijin wrote: post #31
pnathan wrote: post #12

I generally prefer email to any other form of electronic communication. It's sortable, archivable, easily formed into lists, decentralized, encryptable, supports attaching images, well-known, implemented in a number of protocols... While you could implement a shiny-for-the-laypeople status code parser, email as a system works unbelievably well.

> archivable, ... decentralized, encryptable This. I shudder every time someone mentions replacing e-mail attachments with Dropbox/iCloud/etc., which somebody already did in this thread. With e-mail, I am beholden to nobody; and if I pay some company to handle my e-mail, it's only because I voluntarily chose to do so. I could drop that company at any time, fire up my own mail server, and have a 5TB mailbox with 10, 2…

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.

Re: This is the mail system

#42

Post by Retric »

pfraze wrote: post #28
jrockway wrote: post #23

Earlier quoted context omitted.

"I'm afraid I wasn't able to deliver your message to the following addresses: ..." Seems reasonable to me.

Yeah, but UIs aren't there for reading; they're for using. If I get an undeliverable because the recipient was bad, then the UI just needs to indicate, "Bad Recipient." People are doing energy management all the time, and that's not a bad thing. They see something that looks technical at a glance (it's got numbers and slashes and run-on sentences) and that's it. They know they're not technical, and they don't aspire…

I know plenty of non technical people and they all understand the concept of bounced emails. Error 238B is terrible but "can't deliver email to ben.cornwalll@test.com" and 90% of people can understand they miss spelled the guys email address. It's only after that they their eyes gloss over and their mind shuts down.

Re: This is the mail system

#43

Post by hub_ »

kijin wrote: post #32
hub_ wrote: post #26

I suggest returning the error in a .doc file so that people can read. At least some. And yes I get you idea, this is actually a RFC http://tools.ietf.org/html/rfc6522 And the MUA (Mail Program) should just deal with it properly. But then you have all these Bloatus Notes, M-SExchange and other broken system in the wild...

.doc file? Why use a proprietary binary format when a suitably standardized plain text format would work just fine? I don't even open .doc files from unknown senders.

You obviously missed the sarcasm.

Re: This is the mail system

#44

Post by pyre »

aethr wrote: post #38
pbhjpbhj wrote: post #30

Earlier quoted context omitted.

> One mail server may allow attachments up to 10MB, another 20MB [...] not allow attachments with a .exe extension, [...] important for this flexibility to be available. [...] I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. // Well couldn't we use something akin to SPF - ie a TXT field in the domain's DNS record with a shorthand for the acceptable receiving protocol in operatio…

From a technical standpoint something like that could work to a limited extent (enough to be helpful in some situations, when both parties are using modern, up to date MTAs / mail clients). It still doesn't fix the error message from a bounce, it's more like a hint to the email author to say "this email might not be accepted for the following reasons: x, y and z". Ultimately though, the inertia to implement such a th…

  > Except the need for IPv6 is verging on dire
But we just got all of Iran's blocks back because they are removing themselves from the Internet, right?

Re: This is the mail system

#46

Post by spullara »

gnu8 wrote: post #37

You want to strip out all of the useful information needed for debugging mail problems, and replace it with web 2.0 bullshit ajax and lickable icons that won't render in most mail clients? Sorry you couldn't send your attachment but go back to your blog and leave us alone.

They are suggesting that the client generate those UIs based on the message in the email, not that the message have that UI in it.

Re: This is the mail system

#47

Post by kijin »

aethr wrote: post #41
kijin wrote: post #31

Earlier quoted context omitted.

> archivable, ... decentralized, encryptable This. I shudder every time someone mentions replacing e-mail attachments with Dropbox/iCloud/etc., which somebody already did in this thread. With e-mail, I am beholden to nobody; and if I pay some company to handle my e-mail, it's only because I voluntarily chose to do so. I could drop that company at any time, fire up my own mail server, and have a 5TB mailbox with 10, 2…

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…

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.

Re: This is the mail system

#48

Post by kijin »

hub_ wrote: post #43
kijin wrote: post #32

Earlier quoted context omitted.

.doc file? Why use a proprietary binary format when a suitably standardized plain text format would work just fine? I don't even open .doc files from unknown senders.

You obviously missed the sarcasm.

Sorry, sarcasm doesn't always come across clearly on the Internet.

Re: This is the mail system

#49

Post by tedunangst »

TazeTSchnitzel wrote: post #11
sneak wrote: post #7

Please do no encourage admins to replace useful debugging output with useless HTML shiny. But, by all means, improve the text itself.

You can have both. Easy-to-read message at the top, debug output underneath. Simple.

That's exactly what we have today. Bounce message on top, details of conversation underneath.

Re: This is the mail system

#50

Post by quanticle »

gauravk92 wrote: post #18
sneak wrote: post #7

Please do no encourage admins to replace useful debugging output with useless HTML shiny. But, by all means, improve the text itself.

HTML definitely sucks to parse but it's definitely better then plain text. At least it's a standardized format, as well that it allows for a much better interpretation in terms of visuals without convoluting the DOM for a parser. Sort of the best of both worlds, again I know using any HTML lib sucks to a degree, even with xpath, but wouldn't it still be a step forward. Let's standardize all email error messages to HT…

No, no, no, a thousand times, no. HTML is not easier to parse than plain text. Plain text is easily transferred, stored, parsed (with grep, or whatever you use for regular expressions), and, as a bonus, is easy for humans to look at. HTML helps with exactly none of those things. There's a reason that Erik S. Raymond emphasizes the power of plain text in The Art of Unix Programming. There's a reason that The Pragmatic Programmer has a chapter devoted to it. That's because plain text (more specifically plain ASCII text) is the closest thing we have to a universally understood format in computing. For something like e-mail, plain text is by far preferable to HTML, XML, JSON or some other structured format. You can't know that your target will have a parser for a structured format. The only thing you can assume is that your target is capable of reading and transferring plain text.
Post reply on HN