Because of automated bounces. The problem is that a) many mailservers would send their bounce messages to that address and b) there's no standard bounce message format, so there's no easy automatic way to distinguish bounces from non-bounces. There are solutions that do that, but they are basically a bag of heuristics, and usually everybody builds their own. So you either have to build/buy complicated software to filter responses, or your response address is flooded with bounces till its effectively unmanageable. The path of the least resistance is to put noreply@ there and have humans contact different address.
This isn't as big a factor as many would have you believe, though. I have a list of nearly 15,000 people via Aweber. How many autoresponders do I get when I send an email? 10 or 12. Now, if you are Facebook, that might be a consideration. But for startups, do the right thing and go the personal route.
I think it depends heavily on your industry. Out of our weekly distribution to 20,000+ opt-in subscribers, on average we get 400+ out-of-office replies.
There actually is a standard format for bounces. RFC 3462[1] defines Multipart/Report, a multipart MIME type for sending back delivery reports. Most big-name mail providers send bounces in this format these days, but there are still zillions of other MTAs out there that send in their own peculiar variation on text/plain. For example, last week while churning through a pile of bounces while writing a bounce processor I came across one that declared it was text/plain but then included quoted-printable HTML of a report page and some of the original message. No headers, of course.
No worries. I was mostly just pointing out that even though a standard exists it's just one of many formats for bounces, so they're still difficult to deal with.
I wonder if automated systems generally send to the sender email address, even when a reply-to is included. Interesting to know a/the reasoning though.
Automated systems are supposed to send to Sender, except when they're not... well, it depends on what you mean by "automated". In the "classical" sense, the only automated system was the software that implemented SMTP itself, such as sendmail. It generated bounces, it generated vacation replies, it was both the point of mail ingress and egress for mail's state in the system.
Now, there are automated systems that exist outside of SMTP. For example, mail user agents generate vacation replies. Things like gmail and Exchange/Outlook blur the line between mail server and mail user agent. SMTP generated bounces are rarely useful for humans, but things like vacation messages are intended for humans. If there is a reply-to, that's assumed to be more of a human (a human who will at least read the response, bounce or otherwise) than the chances that the Sender (on a message with a Reply-to) is going to be a human.
So, if you're talking about bounces, I'd expect them to go to Sender. For vacation messages, I expect them to go to Reply-to. And of course, YMMV, even MMMV, based on the email topology of any specific organization. What counts as a bounce? What counts as a auto-reply about the availability-state of the recipient? Or the availability-state of the person/role collecting the recipient's email? Is that significantly different from a bounce? Can an automated system determine that? Should it?
(sidenote: Personally, I hate vacation messages. People think it provides an explanation for not immediately replying (anyone who thinks email is reliably immediate is an idiot), but all it does is show you care more how you don't respond when you're not around than when you are.)
Some of them do, some of them don't. Email is a very old system, and for some things there's no standards, for some things implementations predate standards so one has to live with what is out there. Some of them just broken and since there's often no standard to point them to they just say "well, we know there's industry practice to do X, but we prefer to do Y".
This is the problem. I've helped build my company's bounce tracker. There is an RFC that explains how you are supposed to do things, but at least 50% of email servers don't follow it.
You may get your whole email back, or just the start. The message may tell you what went wrong, it may not. It may tell you what email address you tried to send to that failed, that may be missing (some mail servers actually redact it).
The worst one is when they successfully deliver their bounce to the Return-Path but then corrupt the To on the bounce to be the To on the original message and then copy their Message-ID into the original message, thus removing any chance of successfully processing anything. I never figured out the actual MTA that was doing this, but Lotus Domino was involved.
