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

61–70 of 80 posts

Re: This is the mail system

#61

Post by fleitz »

ori_b wrote: post #36
spoondan wrote: post #29

Earlier quoted context omitted.

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.

There's no standard format for email either, but that doesn't stop it from working. Email is worse than HTML in terms of what is expected to work. You're lucky if an email is all in one character set, and even luckier if that character set is the one it says it is.

If you've written many systems that deal with email you know that you could be processing almost anything.

Sure, there might not be a 'standard' format for email, but you can return a multipart message that perserves the ugly text messages and includes an HTML message for the rest of us.

Note, that by standard I mean most emails violate any particular email RFC in some egregious way, similar to the way most HTML pages are invalid, for example the page for this comment has no less than 20 errors.

Re: This is the mail system

#62

Post by dfox »

ori_b wrote: post #36
spoondan wrote: post #29

Earlier quoted context omitted.

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.

There is no standard format for the plain text part of bounce that your MUA shows to you as it's just that: plaintext part to show when MUA knows nothing better to do. RFC 3464 specifies format of additional MIME parts of message that specify what happened in machine readable format. It's interesting to note that it's exactly same mechanism as is used for sender-requested notifications for delivered email in which case these messages are processed by MUAs just fine.

Re: This is the mail system

#63

Post by wazoox »

This could be a good idea to improve bounce management from the client, if only for the reason that 80-90% of the world population simply don't understand english at all -- all bounces AFAIK are always in english, for a start.

Re: This is the mail system

#64

Post by Sujan »

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…

It's not the support team talking to you. It's not the Yahoo mail server talking to you. It's not your mail server talking to you. It is your mail program telling you, that something went wrong with this mail. Because the only thing you did, was use your mail program to send an email to the other person. Everything else should matter - in the best case you donÄt even know about it.

Re: This is the mail system

#65

Post by Sujan »

orthecreedence wrote: post #34

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 challeng…

He isn't critizizing the mail technology. He is critizizing how we choose to present the most barebones stuff to the user, where some layer on top in the client would be much better.

So you're basically totally in agreement to what he writes.

Re: This is the mail system

#66

Post by Tichy »

My main problem is that spammers hacked the "sender unknown" error message long ago and use it to spam me (they send mails pretending to be me, so the error message gets delivered to me). So I had to filter them all away.

I wish Thunderbird's spam filter would check if I actually sent the message the error message refers to.

Re: This is the mail system

#67

Post by zokier »

Niten wrote: post #57
orthecreedence wrote: post #34

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 challeng…

Exactly. It would be no small matter to come up with an alternative system that has the simplicity, flexibility (including flexibility of archival), and most of all the freedom of email – and have it work anywhere near as well in practice as email does already. (Google Wave showed promise... but it also introduced a ton of new complexity, and given the pattern of messages "living" on the sender's server, it wasn't cl…

Federated XMPP seems rather nice alternative if it were extended to support asynchronous communications (eg servers would store messages when clients are offline). Yes, it is XML based and XML is not fashionable these days. But still I think it has potential if it were developed further.

btw Facebook messaging is partly based on XMPP so it's not completely proprietary.

Re: This is the mail system

#68

Post by pbhjpbhj »

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…

The MUA would do the work up front, query the TXT field for the rpf and tell yiu up front "I can't do that, $user wont accept attachments over 15MB". Then as the OP suggested the MUA can offer to zip, upload and link, or whatever.

Re: This is the mail system

#69

Post by pbhjpbhj »

davidcann wrote: post #39
pbhjpbhj wrote: post #24

Earlier quoted context omitted.

> 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.

Well the chances are slim because they cant read that much at a time.

Probably a computer at the CIA is reading it though.

Re: This is the mail system

#70

Post by qznc »

quanticle wrote: post #50
gauravk92 wrote: post #18

Earlier quoted context omitted.

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 Pragmati…

We could settle with markdown?

Does any mail client handle the mime-type text/markdown or text/x-markdown [0] or text/x-web-markdown [1] or something?

[0] http://www.mail-archive.com/markdown-discuss@six.pairlist.ne...

[1] http://codecraft.io/2011/07/18/ubuntu-markdown-files-mime-ty...

Post reply on HN