Let’s kill no-reply(medium.com)
medium.com
Let’s kill no-reply
https://medium.com/@iffy/lets-kill-no-reply-d451c80ba8be
108 comments
This is odd, what do you gain from this? Chances are this will not get seen on the sender's end, and if it does they won't care, statistically speaking. Many noreply addresses are transactional emails (ie, emails you trigger by doing an action), so it seems maintaining a whitelist would be a chore.
> many noreply addresses are transactional emails
That is correct; for transactional e-mails I use a throwaway e-mail alias system (operated via a web front end). Messages targetting these e-mail aliases bypass all these rules.
That is correct; for transactional e-mails I use a throwaway e-mail alias system (operated via a web front end). Messages targetting these e-mail aliases bypass all these rules.
Ok, but my core question still stands: why? I'm with you in thinking that noreply addresses should go away, but I don't see how this could be an effective measure to stopping them. A company isn't going to care about this, statistically speaking. Everything you're describing sounds tedious for no gain.
Not having to search sites on how to contact them.
Having managed email queues, the no reply email is essential, because everyone and their uncle uses auto replies. That said, I'm all for including a real email address somewhere so a user can reply.
You can configure your email sending with a reply-to email (example [email protected]) and not have auto replies or bounces go to that reply-to address.
The auto replies will go to the envelope sender email. I prefer to set that to something like [email protected] rather than [email protected] because noreply just looks so unfriendly.
Replies from real people will go to the reply-to email ([email protected]) and bounces/auto-replies will go to the sender address ([email protected]). You can then write a script that automatically clears the auto-replies and handles the bounces from the [email protected] inbox.
This will allow you to still handle real customer inquiries that come into the reply-to email without being bombarded with bounces and auto-replies.
The auto replies will go to the envelope sender email. I prefer to set that to something like [email protected] rather than [email protected] because noreply just looks so unfriendly.
Replies from real people will go to the reply-to email ([email protected]) and bounces/auto-replies will go to the sender address ([email protected]). You can then write a script that automatically clears the auto-replies and handles the bounces from the [email protected] inbox.
This will allow you to still handle real customer inquiries that come into the reply-to email without being bombarded with bounces and auto-replies.
why wouldn't auto-replies go to the reply-to address?
You control this using the Return-Path option in your email headers.
There are common clues an email is an auto-response, too — from timestamp to headers: https://github.com/jpmckinney/multi_mail/wiki/Detecting-auto...
Ah, the old "Be liberal in what you send out, be conservative in what you receive" approach.
If you want to waste money on resolving 6 month out of date vacation replies than be my guest.
I'd rather have the mail admin spend a moment or two putting in a rule that ignores autoreplies
e.g. in another response someone linked https://github.com/jpmckinney/multi_mail/wiki/Detecting-auto...
e.g. in another response someone linked https://github.com/jpmckinney/multi_mail/wiki/Detecting-auto...
It's been resolved for many years.
[deleted]
Auto relies could easily be weeded out with some simple code.
One mistake per day is enough for the knives to come out. On a big mailing list, think about how many 9's of accuracy you have to have to keep one incident from happening per day. Per week. Per month.
If you asked people, one per month would be a 'working' system, if you catch them on a good day. 'Never' is a very long time.
If you asked people, one per month would be a 'working' system, if you catch them on a good day. 'Never' is a very long time.
I've never seen it. I'm sure that works "in theory"
A quick Google for "outlook autoreply headers" gave me https://www.jitbit.com/maxblog/18-detecting-outlook-autorepl... -- a more comprehensive list of headers is available at https://github.com/jpmckinney/multi_mail/wiki/Detecting-auto...
Will some things filter through this list? Undoubtedly, but I would be surprised if it's a significant percentage. Extremely high-volume lists probably need some more specific care, to be sure.
Will some things filter through this list? Undoubtedly, but I would be surprised if it's a significant percentage. Extremely high-volume lists probably need some more specific care, to be sure.
Couldn't you filter most of them out by the timestamp? If you get a reply that was sent faster than a human could have responded, ignore it.
The auto-reply is probably sent by a desktop email client, which are often offline and/or configured to only check for new email every few minutes. So you'd fail to mark a lot of auto-replies.
Exchange configures it on the server because generally people have their computers turned off when on holidays.
We decided against 'no-reply' emails when we started our business 6 years ago and it's been a great way to get our customers to engage with us.
Every email we send out has a blurb like this:
"Please let us know if you have any questions. You may reply to this email or reach us at support@..."
Yes, we get some bounces and vacation/out of office auto-replies but the benefits far outweigh having to delete a few auto-replies that got through the filters.
Every email we send out has a blurb like this:
"Please let us know if you have any questions. You may reply to this email or reach us at support@..."
Yes, we get some bounces and vacation/out of office auto-replies but the benefits far outweigh having to delete a few auto-replies that got through the filters.
Yes, we get some bounces and vacation/out of office auto-replies but the benefits far outweigh having to delete a few auto-replies that got through the filters.
This has been our experience as well, though maybe it's different for purely B2B communications. We're mostly B2C, and we've never found out-of-office replies to be a significant problem.
This has been our experience as well, though maybe it's different for purely B2B communications. We're mostly B2C, and we've never found out-of-office replies to be a significant problem.
It's actually very easy, just feed the responses to your customer support service. Since it's an email you know, it will be associated to the customer account.
Not only it's good for the customers, it's good for you because you definitely want customers to contact you when they have a problem (or when they believe you're sending too many emails). You want them to contact you to give you a chance to make them happy customer who stay with you, not grumpy customer who quit your service before even giving you an opportunity to fix their problem.
Not only it's good for the customers, it's good for you because you definitely want customers to contact you when they have a problem (or when they believe you're sending too many emails). You want them to contact you to give you a chance to make them happy customer who stay with you, not grumpy customer who quit your service before even giving you an opportunity to fix their problem.
For both customers and 'potential customers' you'd need classification staff to categorize the mail. Their jobs might be made easier by machine learning providing them a guess to confirm, but it is important to have a human involved as actually intelligent verification (and additional training in some cases).
Obviously non-customers would be fed over to either sales directly or a Sales Engineer.
Obviously non-customers would be fed over to either sales directly or a Sales Engineer.
I've worked email queues. The customer's account will be full of auto-responders and it'll be impossible to find the real communications.
That's highly disingenuous. Unless you've been spamming your users, it's typical that less than 1% of emails are automated responses. These can be deleted/skipped very quickly.
In my company's case, it's more like 0.1%, but perhaps some are higher.
In my company's case, it's more like 0.1%, but perhaps some are higher.
Not to mention how easy it is to filter auto-replies. If you receive an office with the strong "out of the office" or "vacation" within ten seconds of sending the email, you can be reasonably sure that it's an automated reply.
It's not always this though - I worked support in the past and have seen the annoyingness that two auto-reply systems from different ticketing systems can become. Customer emails us and they get our auto response, which triggers an auto response from their system, which triggers the pre-First Time Response response from ours, which triggers a new ticket from them since the pre-First Time Response response doesn't pull the ticket number from their system's subject line, which in turn triggers another response from this, all the while we're getting spammed with update emails and the case log is bogged down with non-sense. This repeats several times until one side intervenes to ensure their system's automated rules don't catch the support emails for this case.
I understand why we have the no-reply and auto-reply emails, and it makes a lot of sense in many ways, but there's also a very large blind spot where two systems don't realize they're talking to each other and not to humans; the system does exactly what it should be, it's just not what we want it to be doing.
I understand why we have the no-reply and auto-reply emails, and it makes a lot of sense in many ways, but there's also a very large blind spot where two systems don't realize they're talking to each other and not to humans; the system does exactly what it should be, it's just not what we want it to be doing.
The easiest solution to this is to respond with automated emails, but instead only when a human decides it's appropriate.
We send from "auto@", but have a reply-to of "support@" or something more specific depending on the exact case. This does seem to help a little bit with slightly reducing non-human emails.
We send from "auto@", but have a reply-to of "support@" or something more specific depending on the exact case. This does seem to help a little bit with slightly reducing non-human emails.
This is a good point. I wonder if the difference between 'from' and 'reply to' mentioned elsewhere covers this.
Except in western Europe towards the end of July. It's closer to 85%. Brutal.
If all of your customers are on vacation, why are you still emailing them?
How do you know your customers are on vacation prior to the first auto response?
If they are in Europe, it’s useless trying to do anything the last week of July through August. France, for example, pretty much shuts down. I have heard of VC negotiations just stopping practically midsentence August 1 and magically resuming September 1. Apparently France doesn’t understand that it is possible for people to take vacations in any month other than August. They seem to thrive on tourist destinations being absurdly crowded while in June, many destinations are nearly ghost towns. (I live in Provence and have a tiny hotel there so I see it up close and personal every year.)
I had forgotten (socially, legally) "mandated" vacation.
I think the more concerning facet will be proving that the response actually came from the user.
Which is ultimately why many systems encourage you to go through already established and protected schemes for doing things.
Which is ultimately why many systems encourage you to go through already established and protected schemes for doing things.
When you have tens of thousands of customers that's a lot of emails.
I think that's the point of the article too. If you are not prepared to handle 1% auto-responder rate which you can weed out which some code; you are sending too many emails.
I do, and it isn't a problem. If you have the people needed to handle thousands of emails from customers a day, those same people can very easily filter a couple of hundred automated emails.
What actually is more of a problem is spam and unsolicited non-customer email. But still, it takes half a second to close them.
What actually is more of a problem is spam and unsolicited non-customer email. But still, it takes half a second to close them.
Perhaps startups should send email from [email protected] to encourage customer feedback and iterate faster? As pg wrote in Do Things that Don't Scale, "The feedback you get from engaging directly with your earliest users will be the best you ever get... That's one advantage of being small: you can provide a level of service no big company can."
For a smaller startup (< 10 people), I'd recommend going with a person's email. Bonus points if you use your own.
We do that and get the occasional reply, but when we do, people are usually happy to get a quick, personal response.
Once you're larger, using more purpose-suited emails that route correctly is better (e.g. [email protected] or [email protected] routed to the correct customer service teams).
We do that and get the occasional reply, but when we do, people are usually happy to get a quick, personal response.
Once you're larger, using more purpose-suited emails that route correctly is better (e.g. [email protected] or [email protected] routed to the correct customer service teams).
Possibly a personal quirk of mine, but I've never really liked that for automated emails. Getting an automated sign-up email from name@company just feels disingenuous to me.
Similar with the hi@company suggested below - I've seen hello@company used a lot (PR companies seem to love it) and always found it weird to not know who (person or role) I am addressing.
Similar with the hi@company suggested below - I've seen hello@company used a lot (PR companies seem to love it) and always found it weird to not know who (person or role) I am addressing.
I always tack on a "this email is automated, but responses will be read by a human". You can also set the reply to header for a person/role, so you could use [email protected].
I've seen this done a few places. They all used simply "[email protected]" for their reply-tos.
Companies often use noreply@… as sender and add a real address as Reply-To so their staff does not have to deal with bounce messages.
Yes, we do this; it seems to be both the correct solution, and one which works effectively in practice -- use email properly.
Auto responders generally send their messages to the mail Sender. That seems correct to me. We send automated mail from robot@, with a Reply-to of support@ -- because that's logically what's happening.
All of bounces just end up back at the robot, and IMO that's where they belong (and potentially can even be dealt with automatically). The vast majority of out-of-office do that too. And humans end up emailing support.
The name 'robot' was chosen to gently imply to the user a few things.
Auto responders generally send their messages to the mail Sender. That seems correct to me. We send automated mail from robot@, with a Reply-to of support@ -- because that's logically what's happening.
All of bounces just end up back at the robot, and IMO that's where they belong (and potentially can even be dealt with automatically). The vast majority of out-of-office do that too. And humans end up emailing support.
The name 'robot' was chosen to gently imply to the user a few things.
Hackish workarounds will be the death of us.
Hackish? This is a great design: http://www.gnu.org/software/emacs/manual/html_node/emacs/Mai...
As near ad I can tell, the whole damned Internet is pretty much hackish workarounds. It's not amazing when something breaks, it's amazing that it works at all. From HTML being used for more than markup, to NAT routing, to a complete disregard for standards...
It's kinda impressive, actually.
It's kinda impressive, actually.
Companies should definitely have an easily-discovered means of contacting them if you have a concern about an email you received.
But actually allowing replies to the email itself is just asking to get a lot of low-quality spammy replies that now you have to pay someone to wade through.
But actually allowing replies to the email itself is just asking to get a lot of low-quality spammy replies that now you have to pay someone to wade through.
And a crazy amount of "I'm on vacation" auto replies.
We could have a mail field indicating if vacation replies are wanted.
X-WantVacationReplies: noOr headers in the auto-reply mail which tag it as being auto-reply.
These exist!
https://stackoverflow.com/a/10839343/1250772
This answer points at RFC containing recommendations for auto-reply e-mails, and specifies a header to use.
Any new proposal will fall victim to the same opt-in problem to an even greater degree; if developers of auto-responders can't be bothered to follow this RFC, they will also ignore even newer recommendations.
These exist!
https://stackoverflow.com/a/10839343/1250772
This answer points at RFC containing recommendations for auto-reply e-mails, and specifies a header to use.
Any new proposal will fall victim to the same opt-in problem to an even greater degree; if developers of auto-responders can't be bothered to follow this RFC, they will also ignore even newer recommendations.
or.. you know, a reply-to header where real emails can be sent to...
But if I'm on vacation, I don't want to read your email right now. I'm just letting you know that your email might not get a reply, especially not any time soon.
Yeah, it seems like it's providing meta-information about the status of the email address owner rather than actually conveying information from the owner of the email address. Perhaps there should be a separate channel for such meta information.
And bounces, and out of office autoresponders, and so on
We do it anyway. It's easy enough to filter those types of emails. I think it's a huge plus for customer service to be able to say "Have a problem or question? Just reply..."
Sure. And I think that's a better approach, on balance.
Having worked in email queues, filters are nowhere near good enough. Nothing is more infuriating than wasting hours on bounces.
If you have a good quality customer support/CRM tool it should take care of the most obvious, connect to the corresponding customer, and be easy to manage.
> But actually allowing replies to the email itself is just asking to get a lot of low-quality spammy replies that now you have to pay someone to wade through.
If I give them my personal email address (risking low-quality spammy email) then they should at least give me a real corporate address when they send me an email, accepting the risk of a low-quality spammy reply. That's power symmetry.
If I give them my personal email address (risking low-quality spammy email) then they should at least give me a real corporate address when they send me an email, accepting the risk of a low-quality spammy reply. That's power symmetry.
I've seen noreply@ useful/necessary in cases where the original message contained sensitive information that you wouldn't want forwarded to support staff if someone chose to reply.
I can't help but seeing a multi-fail here.
First, it's ok for the company to send confidential info via email? I don't think so. Email is not a secure transport mechanism.
Second, email accounts are often the target of phishing and cyber attacks, so that's the last place you should enable the customer to store sensitive information.
Third, how does "noreply@" actually prevent the customer from sending a reply, disclosing the confidential information at every hop along the way to being bounced by your server? It doesn't. Or to "support" personnel; well maybe if you exclude your admins from the "support" classification but they're likely collecting those emails in an unnamed inbox or logging them somewhere? And what if the customer's (possibly third-party) admins are collecting bounces as they proactively monitor SMTP reputation for the domain and IP address?
Please, just erase the idea that it's ok to send confidential information via email from your head. Send a link to a password-protected page. If you want to be extra vigilant, require temp password via SMS to reset that password. And if you want to be hyper-vigilant, use TOTP as a 2FA mechanism for password reset. And if it really requires secrecy, send it via courier followed by an assassin to kill the courier. (Joking, not an incitement to criminal activity)
First, it's ok for the company to send confidential info via email? I don't think so. Email is not a secure transport mechanism.
Second, email accounts are often the target of phishing and cyber attacks, so that's the last place you should enable the customer to store sensitive information.
Third, how does "noreply@" actually prevent the customer from sending a reply, disclosing the confidential information at every hop along the way to being bounced by your server? It doesn't. Or to "support" personnel; well maybe if you exclude your admins from the "support" classification but they're likely collecting those emails in an unnamed inbox or logging them somewhere? And what if the customer's (possibly third-party) admins are collecting bounces as they proactively monitor SMTP reputation for the domain and IP address?
Please, just erase the idea that it's ok to send confidential information via email from your head. Send a link to a password-protected page. If you want to be extra vigilant, require temp password via SMS to reset that password. And if you want to be hyper-vigilant, use TOTP as a 2FA mechanism for password reset. And if it really requires secrecy, send it via courier followed by an assassin to kill the courier. (Joking, not an incitement to criminal activity)
There are some products that will help you strip that information out automatically, e.g. https://cloud.google.com/dlp/ Demo: https://www.youtube.com/watch?v=GXTCIDbLdfw
Others probably exist, but that is the one I know about.
Others probably exist, but that is the one I know about.
Stripping is prone to human errors. Noreply as a blanket is probably less so.
That service is not done by humans :-)
Humans build their flaws into their machines.
Well... Who identifies whar to strip? Who ensures that an email that is sent by an engineer in a department will definitely go through the sanitization?
Like another poster said, people can build their flaws into machines.
Like another poster said, people can build their flaws into machines.
That's sounds pretty easy to solve redacting the sensitive content when it hits your mail server before going to support staff. If you're sending out HTML email you can also make easy and extensible by having a custom class for redactable contents.
Realistically customers are going to fwd those emails anyway so this approach is more robust.
It seems like most information in these emails would be available to support staff typically though. It sounds like a niche case.
Realistically customers are going to fwd those emails anyway so this approach is more robust.
It seems like most information in these emails would be available to support staff typically though. It sounds like a niche case.
> That's sounds pretty easy to solve
Everything does if you just glance at someone's comment online and dash one off.
How do you recognize which is the sensitive content and which isn't? How do you handle the case where you send out HTML emails, but the response strips all of the HTML and sends plain text back?
Everything does if you just glance at someone's comment online and dash one off.
How do you recognize which is the sensitive content and which isn't? How do you handle the case where you send out HTML emails, but the response strips all of the HTML and sends plain text back?
This certainly also has to do with the value of the customer. If you are an insurance company the value of the customer may be measured in thousands of $$$. If you are a lean e-commerce middleman the value you extract from ordinary end-customer might be some cents. Engaging with the customer in email conversation may cost tens of dollars.
While customers may love email, some (many?) customer service people actually don't. The trouble I have heard couple of times is that with email you usually never manage to solve the issue in one pass. Customer fires off email with insufficient details. Your service center checks the case, asks for more details. Customer does not respond immediately. When the reply comes, the person who originally handled the cases is not at work or has forgotten the details. You can call up the customer - if the customer has provided you the number, but that has it's own challenges. Customer can't talk right now, you need to call back at certain time etc.
In some cases it simply does not work out financially to provide personalized customer service. Too many customers are so cheap that they prefer to deal with your competitor who automates things.
While customers may love email, some (many?) customer service people actually don't. The trouble I have heard couple of times is that with email you usually never manage to solve the issue in one pass. Customer fires off email with insufficient details. Your service center checks the case, asks for more details. Customer does not respond immediately. When the reply comes, the person who originally handled the cases is not at work or has forgotten the details. You can call up the customer - if the customer has provided you the number, but that has it's own challenges. Customer can't talk right now, you need to call back at certain time etc.
In some cases it simply does not work out financially to provide personalized customer service. Too many customers are so cheap that they prefer to deal with your competitor who automates things.
This seems like a problem that could be solved by micropayments for sending and receiving emails.
I've seen proposals[1] for a solution where the sender of an email pays a small fee to the recipient of the email. If you are sending as much email as you are receiving you wouldn't have to worry about using up your email. If you are sending a mass email, you will end up paying for it.
In the case of no-replies, it would discourage the sender from sending an email that doesn't need to be replied to.
I've seen proposals[1] for a solution where the sender of an email pays a small fee to the recipient of the email. If you are sending as much email as you are receiving you wouldn't have to worry about using up your email. If you are sending a mass email, you will end up paying for it.
In the case of no-replies, it would discourage the sender from sending an email that doesn't need to be replied to.
I've personally setup noreply accounts for some selfhosted services.
These emails are truly noreply, there is no inbox, any incoming mail is blackholed. There is no sense in receiving it, it's automated and the software does not react to incoming mails. There is no reason to reply, there is no sense in replying, there is no way to reply, why demand the ability to reply?
Why would I have me reading the garbage that piles up there? If you have a problem, contact postmaster/webmaster/root/etc.
If I send you mail from a real human account, you can reply there. Simple as that.
It seems a bit like someone demanding that the radio should respond to their choice of music. Sure, if you want that, get a music app (aka a meat-email) and stop listening to the radio (aka the machine-email)
These emails are truly noreply, there is no inbox, any incoming mail is blackholed. There is no sense in receiving it, it's automated and the software does not react to incoming mails. There is no reason to reply, there is no sense in replying, there is no way to reply, why demand the ability to reply?
Why would I have me reading the garbage that piles up there? If you have a problem, contact postmaster/webmaster/root/etc.
If I send you mail from a real human account, you can reply there. Simple as that.
It seems a bit like someone demanding that the radio should respond to their choice of music. Sure, if you want that, get a music app (aka a meat-email) and stop listening to the radio (aka the machine-email)
Why not send the email "From" postmaster/webmaster etc in the first place, or at least set the Reply-To header to that?
Because there is no reason for it. If you have a problem there is a contact email in every mail included.
I do not feel like I should be sending mail from postmaster and the reply-to header does not feel any more appropriate.
These emails are 100 percent automatic and do not require you to reply. Ever.
I do not feel like I should be sending mail from postmaster and the reply-to header does not feel any more appropriate.
These emails are 100 percent automatic and do not require you to reply. Ever.
> If you have a problem, contact postmaster/webmaster/root/etc.
This is a very outdated 1990s mentality.
Most modern web users would have no idea that such a thing exists (or should exist), and they're probably the same users who also have no idea that WHOIS exists and know how to find contact details for a domain owner using it.
It's also a little user-hostile to assume that nobody is ever going to question something they receive from an automated system. In that case, why make the user journey unnecessarily difficult by forcing them to find an alternative route to contact you?
This is a very outdated 1990s mentality.
Most modern web users would have no idea that such a thing exists (or should exist), and they're probably the same users who also have no idea that WHOIS exists and know how to find contact details for a domain owner using it.
It's also a little user-hostile to assume that nobody is ever going to question something they receive from an automated system. In that case, why make the user journey unnecessarily difficult by forcing them to find an alternative route to contact you?
There is no reason to reply. The emails state as such. A contact email is included. I literally do not care about anyone who thinks they can reply to these emails and I'm not concerned about user hostility.
My users aren't the kind of users that will respond to such emails.
Again, I don't see a reason to why I need to reply to emails which are explicitly only ever sent if the user chooses to at which point they have been warned about noreply and the emails themselves reinclude such warnings with the proper contact email, especially since this group of users are knowledgeable enough to not reply in the first place.
My users aren't the kind of users that will respond to such emails.
Again, I don't see a reason to why I need to reply to emails which are explicitly only ever sent if the user chooses to at which point they have been warned about noreply and the emails themselves reinclude such warnings with the proper contact email, especially since this group of users are knowledgeable enough to not reply in the first place.
It would seem like over a long enough time horizon a significant fraction of the email you send is going to go to dead email addresses.
Wouldn't it make sense once in a while to turn on receipt to see how bad your bounce rate is instead of ignoring it?
Wouldn't it make sense once in a while to turn on receipt to see how bad your bounce rate is instead of ignoring it?
Not really. There is no reason for anyone to reply. As far as I'm aware from logs I only get about 10 Mails per month in these addresses.
And I'm truly not interested in what someone has to say to an email that says "noreply"
And I'm truly not interested in what someone has to say to an email that says "noreply"
It's done to prevent a loop where an automated response causes an automated response.
Not sure this is entirely true. RFC 3848 (http://www.rfc-base.org/txt/rfc-3834.txt) covers the implementation detail, and a lot of consideration was given to the prevention of email loops.
Section 4 states that auto-responders should send the response to the email address given by the Return-Path header (usually set to a VERP address for identification of bounces) or if absent then fall back to the email address given in the From header.
Section 4 states that auto-responders should send the response to the email address given by the Return-Path header (usually set to a VERP address for identification of bounces) or if absent then fall back to the email address given in the From header.
I agree wholeheartedly. This practice is up there with "No Caller ID" calls.
If a customer really wants to contact you they'll find a way. Life always finds a way.
Sometimes getting communication from a customer who only kind of wants to contact you is well worth the effort.
Why would you want to talk only to customers who "really want" to talk to you? Instead of all your customers, who are a superset of that group and don't always have the same needs?
What about all the emails that get sent to people who aren't customers yet and just have a simple question that isn't covered by the FAQ?
They'll see noreply@, and not bother to dig up a support email address and forget about your company's offerings.
However, seeing a welcoming replieswelcome@ email, they can ask their simple question while they're thinking of it, which then becomes a warm lead, and possibly even convert into a paying customer.
They'll see noreply@, and not bother to dig up a support email address and forget about your company's offerings.
However, seeing a welcoming replieswelcome@ email, they can ask their simple question while they're thinking of it, which then becomes a warm lead, and possibly even convert into a paying customer.
Send as noreply@ with reply-to header pointing to a valid address.
TLDR, an article by someone who doesn't know how email works nor how companies use email queues.
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.
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.
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.
Additionally, if a service is over sending, there are lots of unsubscribe laws and rules to address that to your own personal preference.
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)
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)
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.
If slack can disrupt chat, then maybe another company can disrupt no-reply.
I feel like this predicament resembles the story in the children's book: Half Magic (http://a.co/e8JrhbU).
I feel like this predicament resembles the story in the children's book: Half Magic (http://a.co/e8JrhbU).
"Don’t make me hunt for a way to ask it."
And this post makes me hunt google to find what "kthxbye" means...
And this post makes me hunt google to find what "kthxbye" means...
Unfortunately, this has to be immediately followed by a whitelist: