This is the mail system • Hacker News Board

Re: This is the mail system

#71

Post by zerostar07 » Thu, Apr 12, 2012, 11:53 AM UTC

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.

Those would be SMTP codes. I don't see why it's hard not to understand that "your message was not delivered to this user". The traceback should probably be sent to the postmaster rather than back to the user, but that's an anachronism of the mail servers, which were built back in a time when all email users were technical.

Re: This is the mail system

#72

Post by stasm » Thu, Apr 12, 2012, 11:59 AM UTC

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 looks OK, but it's not for a single reason: who is "I" in this sentence? This is enough to confuse most of the users.

Re: This is the mail system

#73

Post by scott_w » Thu, Apr 12, 2012, 12:11 PM UTC

dholowiski wrote: post #17

fredoliveira wrote: post #10

Earlier quoted context omitted.

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.

The problem isn't the failure messages per se, it's the failure messages regarding user error.

If the user has made a mistake somewhere, the client should try to understand the error message and, if it's user error (email address doesn't exist, attachment too big), it should suggest solutions to the problem in a language the user can understand.

If the system itself has an issue, the client should provide enough information to tell the user either: a) How they can resolve it b) How they can contact whoever needs to resolve it

Re: This is the mail system

#74

Post by ajankovic » Thu, Apr 12, 2012, 1:37 PM UTC

kijin wrote: post #31

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, 2…

So please, folks, by all means fix what's currently wrong with e-mail.

I wonder if someone actually compiled a list of e-mail shortcomings? I tried to do a search but keyword space is filled with regular users searching for standard e-mail problems.

Re: This is the mail system

#75

Post by 4ydx » Thu, Apr 12, 2012, 2:45 PM UTC

It is a perfectly reasonable error message that mail clients should try to beautify. The message itself is absolutely necessary, but should perhaps be cleaned up by the client. All of the calls to write a new "protocol" by the posters on that blog make me wonder if they even understand what the word means.

Re: This is the mail system

#76

Post by 4ydx » Thu, Apr 12, 2012, 2:45 PM UTC

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…

Agreed.

Re: This is the mail system

#77

Post by jrockway » Thu, Apr 12, 2012, 3:54 PM UTC

autarch wrote: post #59

jrockway wrote: post #25

Earlier quoted context omitted.

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

And an HTTP server can return a custom body for most errors, so the server can provide even more info if it wants.

SMTP MTAs can also "provide more info if it wants", but that's what the article considers a problem. What the author of the article wants is a way to dumb down error messages (or, less cynically, automatically correct errors), which is not easy with free-form responses. Imagine a web page that returns a page that says "404 Not found" with a 200 status code. Brokenness ensues.

Re: This is the mail system

#78

Post by rlpb » Thu, Apr 12, 2012, 5:33 PM UTC

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…

> "Hi, this is the Yahoo! email support team...

At this point a large number of users will reply to the email expecting to reach the Yahoo! email support team, who of course can help with every individual bounced email. They will be disappointed when this doesn't work out.

Re: This is the mail system

#79

Post by rlpb » Thu, Apr 12, 2012, 5:35 PM UTC

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…

There is one email "client" that does display a pretty failure message. It's Exchange. Email administrators hate it because when a user forwards the failure message so that a problem might be fixed, the message turns out to be useless.

Re: This is the mail system

#80

Post by jlawer » Thu, Apr 12, 2012, 7:35 PM UTC

Client side parsing won't be as reliable as you expect.

SMTP bounce codes are notorious for changing on a per domain basis whenever someone feels like it.

I work with StrongMail supporting their Email Marketing Platform and their solution is to have a central database that is updated regularly for all major ISPs to basically be able to have a conversion process between the SMTP bounce codes and the 30 classifications for mail failures StrongMail groups failures by (such as User not existing, blocked due to spam complaint, service temporarily offline, etc). This conversion process has to be updated regularly to keep up with changes.

Server side generation of multi-part NDR reports including HTML email could be a solution, i am not sure if it violates the rfc to send NDRs in multi-part, it could perhaps need an amendment.

But if you want to show this then your in luck since all the major SMTP servers besides exchange are open source, go produce a patch set for postfix, sendmail and qmail.