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.
This is the mail system
11–20 of 80 posts
Re: This is the mail system
#12I 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.
Re: This is the mail system
#13Yes, 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.
It is that bad. Email works and gets stuff done, yes, but at the expense of your time, server time, storage, network throughput. It is used for much more than it should, and is long past its expiration date. Sadly, we've all come to depend so much on email and how it works today that changing it would be like suddenly having to breathe underwater. It'll take a load of time to get used to whatever comes next.
Re: This is the mail system
#14Hi. 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 as soon as they see it.
Most people ignore the content of error messages as soon as they realize what they're reading. An awfully large percentage of people ignore it entirely.
I don't know what to do about people.
Re: This is the mail system
#15Every MTA used to have their own way of reporting bounces. These days, the big ones (at least by volume) seem to all obey RFC 3464[1], which defines a MIME type and required and optional fields for delivery reports. Of course, the old MTAs are still around and still delivering their bounces in a myriad of different formats. The bounce processor I work on at work has about a dozen different variants on "The message could not be delivered. There is a copy of the original message/headers below this line". Those plus the RFC 3464-style messages cover roughly 95% of what we see day to day. The other five percent are so unrecognizable that we can't process them automatically.
Re: This is the mail system
#16All 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 around mail handling, relays, spam filtering, etc, I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. RFC 3464-style messages get us part way there but it just doesn't approach something as "nice" as HTTP error codes (which themselves still aren't handled in a standard way by web browsers, they are handled on a case by case basis, if at all, by web developers).
I think this problem is only going to approach being solved when some of the more edge-case uses of email (such as attaching/sending files) are deprecated by more targeted, more efficient services. For example, lets say everyone started using Dropbox or YouSendIt to send files instead of attaching them in emails. And alongside that perhaps a separate protocol such as iCal or similar takes over the "meeting arrangement" space. Eventually the usefulness of email may be narrowed down into a small enough band of "send and forget" messaging that someone can actually, finally, come up with a better, more efficient and usable alternative.
Until that happens, or something else equally radical, email is something we're just stuck with, worts and all.
Re: This is the mail system
#17Please do no encourage admins to replace useful debugging output with useless HTML shiny. But, by all means, improve the text itself.
What you call debugging output frequently isn't really debugging output - it's frequently a bunch of convoluted text that says 1 of 2 things, in 90% of cases: a) target email doesn't exist; b) your email was too large, dummy The text can and should be improved and be void of HTML shiny - the mail client itself could parse the new, slimmer, standard error text and make it pleasing.
As somebody who administers an exchange server I see dozens of different types of failure messages and they are incredibly useful for troubleshooting. Lets please not dumb them down.
As somebody who spent 13 years doing tech support I can tell you that the vast majority of users don't read error messages no matter how shiny or well written they are.
Re: This is the mail system
#18Please 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 HTML. At least then a standard exists even though it will suck, most standards suck in many ways. But it's a total nightmare without any.
Re: This is the mail system
#19Yes, 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-…
> 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
That's a misuse of email on the receipient's side, not on the system's side. Email is about messages, not about tasks. Although there might be more comfortable (i.e., more automatic) ways, there's nothing wrong with maintaining a TODO list that is 100% separate from the INBOX.
For example, in my TODO list I describe shortly (and in my own words) what I consider to be important. Why should I waste my time scanning through the INBOX everytime I want to check what needs to be done?
In other words: It's me who decides what gets on my TODO list, nobody else! I'm in total control because I'm a free citizen living in a democracy, and as such it's my responsibility to organize my life. In particular, to decide what to do (to-do) in my life.
If you decide to give other people access to your TODO list (e.g. by defining your INBOX to be your TODO list), you're voluntarily giving up control of an important part of your life. Nobody forces you to do that. In fact, almost every organization guideline strongly advises against that kind of nonsense. (The most famous one being the "Inbox zero" series at http://www.43folders.com/izero)
Re: This is the mail system
#20Please do no encourage admins to replace useful debugging output with useless HTML shiny. But, by all means, improve the text itself.
You can use multipart/alternative emails to send HTML and Text in the same email.
This means the OP's solution can leave useful debugging in place while providing the user with the HTML shiny they've come to expect.