It's not because of automated bounces. It's not because of spam issues. It's not even because of laziness.
The startups that do this probably do it it because they get a ton of spam back.
I've lead a couple of projects now that have a few thousand users each. Nothing huge, all consumer-focused. I always make my notification emails be from jeff@{project}.com to give it that "human touch".
And I get the most ridiculous replies ever.
Not only do I get bounces (not a big deal) and vacation auto-responders (also not a big deal), but I also get messages from people that know they're getting someone's real email address.
People that want to talk. People that add you to their Google Talk or their "Fwd: FWD: FWD:" emails. People with insecure Hotmail passwords who start spamming you when their account gets hacked.
Obviously, some of the emails are very helpful - bug reports, feature requests, unsubscribes, etc... But some (I'm going to say most) are essentially just spam in the other direction.
I've moved my notification emails to be from "amy@{project}.com", a Mailgun inbox, and process it accordingly (e.g.: bounces get and unsub'd). It has a human name, but a mechanical backend. I strongly suggest it.
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.
My employer is not a startup (financial bank) but we use a technical "noreply" account for sending automated mail to our users (no external services, they're sent through our mailserver). We use a noreply because the same account is used for different kind of notifications (to clients, to financial advisors, to internal users, to external parties etc..) and we have different inbound mail accounts for assisting them (and actually the main channels for communicating with are web trouble ticketing and toll free number, mail is not the suggested one).
Having said that, I must admit that the whole system is quite basic and not integrated as you'd expect for serious problem tracking (ideally we should use something that can keep track a problem through different channels, integrating web, mail and phone ticketing).
N.B. one problem is that unfortunately there are tons of people who cant read and dont understand that if you write from a "noreply@domain" account and write in the mail "THIS IS A SERVICE ACCOUNT PLEASE DO NOT REPLY TO THIS MAIL", you're actually supposed not to do it
This might be your point (didn't quite get your point) but that's exactly why you should fix this. You actually have separate inbound and outbound channels. It's rediciously simple to change those outbound channels' email addresses so that a direct reply will be sent to the corresponding inbound channel.
It doesn't matter if the system is basic and uses a smtp server or if it uses a hot new email routing service. It's about setting the correct from address in your systems code.
The automated outbound mails are mail like "you have a new trouble ticket, please login to your personal area" (maybe because they forgot to send us some documents)
They dont have to reply to the mail, they have to login and reply via the troubleticketing system, eventually uploading attachments.
if you set the from address as you suggest, but you dont have a fully integrated (mail/web etc..) ticketing system, you end up with a mess (part on the web part on the mail account).
Counter-example: When email notifications contain private information, such as an alert of an engagement or communication between two users, there's no benefit from a reply-able email in this case. In fact, reply-for-feedback is bad since it will include private information quoted within.
Though in general, I agree that noreply is needlessly overused.
If privacy in replies and forwards is such a huge concern, shouldn't someone write an RFC for a header that indicates "Don't include original in replies and forwards"? Even if only a few companies (Google, Microsoft, Yahoo, Apple, Mozilla) implemented it initially, that would protect a lot of people.
This does not help, as while the private information sent to the user is missing, the private information sent from the user will still be there: they will simply now send complaints to the people who provide their email client that it didn't work.
You have to remember that websites are used by "normal people": the same people who get punished by websites with ludicrous URLs or broken images and fall for schemes asking them for their money or password.
I recently took over a website that uses OSQA (an open-source stack overflow implementation). When users get answers or comments, they get an email from "JailbreakQA" <admin@jailbreakqa.com>.
These emails now go to me, and the people who respond to the emails invariably are trying to talk to the other user, not to me. In this case the conversations were already public, so it isn't a big deal, but the exact same thing would happen if a user got a comment from a friend on Facebook.
To be clear: these emails clearly state they are a notification, that they came from the website you are using, that to view the content you need to return to the website (providing a URL), and then separating the content from the other user in the body.
People still just reply. Now, maybe you think that should work: that the emails should go back to the website and to the conversation thread, but the reality is that bridging email will make that a horrible experience, as the way people speak in email, the formatting available, and the crazy intermix of MIME and the original content, causes chaos: imagine trying to safely and automatically convert an email back into a Facebook Wall reply ;P.
The reality is: these are notifications, not messages. Replying to them is nonsensical, and if we were going to extend the email protocol at all, it should be to make "this is not really an email" an explicit first class feature.
(As an aside: the count recovery emails sent by Cydia, my primary work, can be replied to. Almost all of the email I get in reply is an elaborate and sometimes quite time consuming version of "thanks, that worked!"... I am simply floored that people thank the automated system, but hey: at least they seen happy. ;P)
You're talking about the same kind of "normal people" who will reply to noreply@ anyway and complain that the company doesn't respond. In that case, how does it help anyone if you keep using a noreply@ address, whether for privacy or for any other reason? If "people still just reply", maybe the right thing to do is to make those replies actually work, instead of trying to restrain normal people's normal behavior.
It doesn't make any intuitive sense that other people's replies to what you wrote are delivered to you by e-mail but you can't use e-mail to reply to them in turn. That's only half of a proper communication system. Give people a proper communication system, or give them none. If you only give them half, it is only natural that they will expect the other half to work. "Normal people" simply don't care whether SMTP is different from HTTP.
You say it'll be very difficult to make e-mail replies go back to the conversation thread on the web site, but Google Groups and Posterous group blogs have been doing that for years. Google even detects quotes in replies and hides them automatically; you could do the same in your forum software if you want. Support ticket systems of every web/vps/server host I've used also work with both e-mail and web. There are some kinks here and there, but integrating e-mail into a web conversation is a solved problem for the most part. There's no reason for e-mail notifications nowadays to be not reply-able, unless it's a one-off thing that clearly does not create any expectation of reply-ability.
Agreed. From a similar comment on HN a few months ago we changed our email address to concierge@ (we're a restaurant reservations startup). Very few people reply (automated emails still look automated), so it is very easy to manage.
One I've noticed people using recently and that I use is "Firstname from Company" as the name. Seems to work well, since it's both personable and clear what you are emailing about.
On a related note (email addresses), how about we standardize email address regex/verifications to accept "Foo Bar" <foobar@yahoo.com> formats? I'm tired of grabbing an address, hitting 'copy', then not being able to paste it anywhere without having to essentially retype just the stuff between < >. Apple Mail is bad about the 'copy', but I've noticed it with some other apps, and nothing lets me paste in the full version. :/
One annoying thing is that some programs want you to separate different email addresses with semicolons and some with commas. It's another hassle to translate between those two conventions.
I also wish that startups would use a bit more "personable" email address. Emails from donotreply@what.ever or invalid@examp.le just look odd. Instead, the reply-to email should alias to your help email address, to simplify sending requests for help, or just sending comments and feedback.
I don't know if it's a general EU directive, but this is becoming a legal requirement in some European countries (identifiable sender name, must be possible to reply to email).
I've always found it weird that email - a two-way system supposed to be analogous to letters - has so many occurrences of noreply@example.com. I wonder what percentage of emails end up in these unmonitored mailboxes.
I think it comes from the parallels to physical bulk mailing. I usually get sales flyers, various "junk" mail and the not-as-often "we've moved funds from one account to another because a check didn't clear" from my bank. I equate most of these to something that would come from a no-reply email. Also, I do believe it's possible to have a send only mailbox that won't even accept incoming mail. It would drop the mail on the floor without you knowing.
This is a great post, redmine ticket has been submitted, its something we're guilty of. I completely agree that a name is important, and to reiterate what others are saying here I also agree that email addresses you cant reply to are useless.
Thanks for sharing, the internet is a better place for it :P
In some cases it may be intentional. I am unlikely to open an email from startup X if months ago I reached a negative judgement about startup X.
On the other hand, if the From field only says "John" or "notification", I may open the email even if just for a second.
Also, note the branding value of having your company name in the from field. I receive emails from some sites that I no longer visit. Yet, just seeing their name day in and day out in my email makes me remember their name/brand.
If I was one of those John Schmidts, I would mention the conference. I think this is just a question of providing context in a world of email inundation.
Also bad is when the emailing service that you use creates new and random "From" addresses for every single email. That means if I want to see images from you in Gmail or Outlook, I have to do it for _every_ single email I get from you. I'm looking at you, Twitter, with your n-grqlbhat=tznvy.pbz-302c1@postmaster.twitter.com "from" addresses and anyone using whatever service results in "EAT Club [support=myeatclub.com@mail13.us2.mcsv.net]".
That is done to track bounces. If an automated email is sent to an address, but that address is setup to forward once or twice and bounces somewhere along that path, by the time the bounce gets back to the original (automated) sender, it may otherwise be impossible to figure out what the original address was. With unique addresses like that, bounces can be tracked.
Doesn't a bounce usually include the Message-ID of the original message, along with a lot of other cruft? I can understand small teams doing this as a quick fix, but companies like Twitter should have no trouble keeping a large dict of Message-ID => account ID.
'Usually' but definitely not always. Account ID is also usually at the application level, while Message-ID originates lower, at the mailserver level. When the app posts something off to the mailserver, how is it supposed to get the Message-ID back?
At least with the cruft, bounces are just handed back to the app to deal with.
The important point this post makes is the issue of an ambiguous subject line. I had never thought of it before, but not putting a company name in the subject makes the email look much less credible and increases the chance of me flagging it as spam.
In the examples of subject lines including a company name, I would only recommend:
Company Name: Check out this new feature
Enables people to easily find something by sorting alphabetically in case they cannot remember the company name in full. I do the same thing with downloadable files.
My Downloads folder is full of things like Summer-menu.pdf or menu.pdf when I'd rather have Celcius_Summer_menu.pdf.
