[iffycan]

Author here.

I'm writing from the perspective of a customer. As a customer, I don't care how your email queues work. I do care that you sent me an email and forbid me from replying to it. It chafes. And you want my money?

From the perspective of a company, I can sympathize. I've been directed to create noreply-sending mailers in the course of my job. In every case, it would have been better sent from support@, but because of understandable but dumb reasons (bureaucratic laziness; not-my-problem-itis), it's way easier just to turn on the mailing hose and forget replies. So that's what we did.

I've also worked on handling bounces of both email replies and (cringe) faxes. Yes, handling bounces can be annoying, but to create a good customer experience I think it's worth the cost.

[snarf21]

I hope I don't seem critical because that is not my intent. It seems like this is about misusing no-reply@ not that no-reply@ is inherently bad. Github completing a merge of a branch onto master seems like a fine use case for no-reply@. Using no-reply@ to tell someone they are overdue on their bill is not. Or are you saying there is literally never a reason for a no-reply@ address?

Additionally, if a service is over sending, there are lots of unsubscribe laws and rules to address that to your own personal preference.

[iffycan]

I won't say never. I think your distinction (GitHub merge vs bill overdue) might strike the right balance, but I'm having trouble sorting out what the principle is that distinguishes those two.

As I've never even paid attention to the sending address of GitHub merge notifications, perhaps the principle is: "If someone notices that your email came from noreply@ then you shouldn't use noreply@"

(And, no, you don't seem critical -- more like thoughtful)

[bitJericho]

I agree, but I think it's best to just have an email address right at the top of the email for a customer to reply to, or use the reply-to headers.