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

21–30 of 80 posts

Re: This is the mail system

#21

Post by kevinchen »

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…

For an overwhelming majority of nontechnical users, no, it is not a good error message. It is filled with confusing technical things that he/she shouldn't have to care about, like HTTP status codes and IP addresses. Even if these people chose to read the whole thing, they still would have no idea what is going on. So it's a terrible error message.

Re: This is the mail system

#22

Post by ssebro »

vog wrote: post #19
jsprinkles wrote: post #9

Earlier quoted context omitted.

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

I think that part of the idea is that reading a message, replying to a message & all other things that you do with mail can be considered as "tasks".

Re: This is the mail system

#23

Post by jrockway »

kevinchen wrote: post #21
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…

For an overwhelming majority of nontechnical users, no, it is not a good error message. It is filled with confusing technical things that he/she shouldn't have to care about, like HTTP status codes and IP addresses. Even if these people chose to read the whole thing, they still would have no idea what is going on. So it's a terrible error message.

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

Seems reasonable to me.

Re: This is the mail system

#24

Post by pbhjpbhj »

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 and the text of the email you sent are below [or attached]."

The response could also include info like that the domain is live.

Re: This is the mail system

#25

Post by jrockway »

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.

The underlying problem is that SMTP only has a few error codes, and so there is no way the MUA can understand (in a standard way) why the MTA rejected the message. HTTP ended up having richer errors, and so clients can provide nice messages if they feel like it. (IE does this for 404s and 500s, though it's not a nice message and it seems to upset most web developers.)

Re: This is the mail system

#26

Post by hub_ »

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

Re: This is the mail system

#27

Post by warpspeed »

jrockway wrote: post #23
kevinchen wrote: post #21

Earlier quoted context omitted.

For an overwhelming majority of nontechnical users, no, it is not a good error message. It is filled with confusing technical things that he/she shouldn't have to care about, like HTTP status codes and IP addresses. Even if these people chose to read the whole thing, they still would have no idea what is going on. So it's a terrible error message.

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

It would be reasonable to someone reading HN, since we probably are not scared off by technical jargon. Even if the instructions were spelled out completely, the plain-text formatting and numbers (IP addresses) immediately tell the average user that this is over their head and they ignore it. It's not user-friendly for real-world users.

Re: This is the mail system

#28

Post by pfraze »

jrockway wrote: post #23
kevinchen wrote: post #21

Earlier quoted context omitted.

For an overwhelming majority of nontechnical users, no, it is not a good error message. It is filled with confusing technical things that he/she shouldn't have to care about, like HTTP status codes and IP addresses. Even if these people chose to read the whole thing, they still would have no idea what is going on. So it's a terrible error message.

"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 to be technical, so they don't waste energy trying to comprehend the message.

Re: This is the mail system

#29

Post by spoondan »

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

Re: This is the mail system

#30

Post by pbhjpbhj »

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 operation, kind of an RPF.

So you'd have something like:

alicious.com TXT v=rpf1 deny-ext:exe,reg,dll max-size:15MB req-field:sender ip4:xxx.xxx.xxx.xxx/16 req-format:txtonly req-other:spf ...

would tell the MTA (or the forwarding relay) that this address will likely reject emails containing exe, .reg, .dll files; emails over 15MB; emails without a sender field; emails apparently originating from servers outside the given address range; emails not in text format; emails from domains without a SPF; ...

Whoops got carried away there.

What would be the problems with this sort of scheme?

[FWIW there's already a milter called RPF but that's not what I'm proposing here I'm talking instead about a policy to give to a sender to tell the sender what you intend to accept so that they can choose to match your requirements and avoid having the mail rejected. Obviously an MTA/MUA can choose to receive mail that doesn't adhere to the policy if they wish.]

Post reply on HN