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

31–40 of 80 posts

Re: This is the mail system

#31

Post by kijin »

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, 20, 30 years of searchable history if I wanted to. I can also access it with a whole bunch of free and open-source software, from ESR's original fetchmail all the way to the latest alpha of Thunderbird.

Every other messaging system that I've heard about, on the other hand, is either held hostage to one company's proprietary platform or clearly not intended for people who need to look up conversations they had 10 years ago.

So please, folks, by all means fix what's currently wrong with e-mail. But please think twice before suggesting that everyone replace it wholesale with some proprietary cloud-based TODO app.

Re: This is the mail system

#32

Post by kijin »

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.

Re: This is the mail system

#33

Post by MatthewPhillips »

jsprinkles wrote: post #9
jhferris3 wrote: post #2

Yes, the email system could be better. But for something that was designed decades ago it works surprisingly well. Should somebody try to do some smart parsing of failure notifications to make them more readable? Sure, I don't see why not. But don't pitch the baby out with the bathwater here. The underlying system is not that bad.

Actually, the underlying system is absolutely putrid, a sentiment that pg agrees with based on his latest talk at PyCon. Mail is, unequivocally, the worst part of my daily existence and you are kidding yourself if you're calling it "not that bad". Using pg's words, mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it. We live in an era of technology that can do e-…

Email isn’t the problem, the problem is the client. Here’s just a few of the things we use email for today:

  Todo list
  Social networking notifications
  Text messaging
  Planning meetings
  Planning vacation
  Discussing issues with colleagues (mailing list)
  Bill notifications
  Newsletters / grey mail
  File sharing
We do all of those different things and shove them into a single client that was designed (with minor alterations) over 30 years ago. What were they using email for then? To send “holy shit, this is cool!” messages to other neckbeards.

We should be using a separate client for all of these uses. Email is nothing more than a messaging protocol. You could launch a group texting app and use email as the delivery protocol. Your user base would instantly be every person with an internet connection. It wouldn’t matter that person A has your app and person B doesn’t, you could make it transparent to the person that has the app and pitch to the person that doesn’t.

The biggest obstacle to this is that we all use regular old email clients today and increasing the already incredible noise would not be without backlash. I think you have to start out with apps that don’t require adding to your message count (a notification app that scrapes your inbox, for example).

Meanwhile startups are trying and failing to make every service its own silo that travels over port 80. This is what is most sickening about startup culture today, no one is creative about using the stuff that has been around forever and is used by everyone.

Re: This is the mail system

#34

Post by orthecreedence »

I completely disagree 100%. I think the mail system is exceptionally well-functioning. It's a massively-scalable, decentralized, asynchronous messaging system that supports large file attachments. At this, it excels. There's not one big evil company controlling all messages and unless you're sending massive amounts of emails every day, your messages almost always end up exactly where they're supposed to. I'd challenge anybody to do better.

The author's main gripe is Mailer Daemon messages. It's not email's fault that people write shitty clients that don't display a pretty failure message. If your car doesn't have anti-lock breaks, it's not the road's fault when you hit a patch of ice and slam into a tree.

Email is great not only because it works simply and beautifully, but because it's so extendable. People think it's broken. It's not. It's just simple...and it's this same simplicity that makes it easy to build on top of. Look at Gmail or Xobni. Both have incredible features that "email" doesn't have because they took the time to build extras on top that make it work nicely.

Email is NOT broken. There's nothing to fix. Whatever fixes you think it needs you can make yourself. The underlying platform works great. If you have a problem, write/patch a client.

Re: This is the mail system

#36

Post by ori_b »

spoondan wrote: post #29
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 missed a crucial part of the post: Machines can read [these error messages] just fine, though. Here's an idea: machines shouldn’t slap us in the face. They should help us along if they fail to do our bidding. He's not encouraging admins to replace useful debugging output. In fact, it's the opposite: he's encouraging email client designers to actually use the debugging output to let people know what went wrong. Hi…

No, they can't. There's no standard format for these error messages that I know of.

Maybe there should be, but that's a problem that has to be solved before the shiny UI can be placed over it.

Re: This is the mail system

#37

Post by gnu8 »

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.

Re: This is the mail system

#38

Post by aethr »

pbhjpbhj wrote: post #30
aethr wrote: post #16

All mail systems have different rules for what is "acceptable", what is perceived as "spam", etc. One mail server may allow attachments up to 10MB, another 20MB. Some mail server somewhere may allow attachments up to 50MB but will not allow attachments with a .exe extension, and due to the vast and wide uses of email it actually is important for this flexibility to be available. Given the amount of variablility aroun…

> 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 thing on existing MTAs is somewhere close to the difficulty of implementing IPv6. Except the need for IPv6 is verging on dire, and not many people seem to be rushing to fix that one. How will we convince people to act with any expediency over something that is, at most, an inconvenience?

Re: This is the mail system

#39

Post by davidcann »

pbhjpbhj wrote: post #24
dsr_ wrote: post #14

Hi. This is the qmail-send program at yahoo.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 72.1.169.10 does not like recipient. Remote host said: 550 : Recipient address rejected: undeliverable address: unknown user: "[list name]" Giving up on 72.1.169.10. That's a pretty good error message. Most people glaze over…

> Recipient address rejected: undeliverable address: unknown user // Hmm, it's okay. It's a person masquerading as a computer masquerading as a person. This doesn't really help IMO. Why can't it be "Hi, this is the Yahoo! email support team. You sent a message to someone but when we tried to pass it on the email address didn't work so we can't send the email for you. Here's some things to try ... technical details an…

That sounds like someone at Yahoo is reading my email.
Post reply on HN