3 ms·
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 fa
by spoondan 15y ago
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. His mockup is quite clearly of an email client showing users relevant recovery options based on an underlying error message the client has parsed.
In other words, he's proposing that email clients treat MTA error messages precisely as they already handle raw headers. Full headers contain useful debugging information, but you aren't normally debugging.
- ori_b 15y agoNo, 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.
- fleitz 15y agoThere'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.
- dfox 15y agoThere 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.