Is there a way to prevent bounce responses being sent to app emails, or ignore bounce messages entirely, or redirect to a monitored mailbox?
-
I'm looking to accomplish a couple of things here..
- Reduce overhead on the mail server
- Possibly redirect bounce messages to app email addresses to something like
postmaster@<domain.tld>
Example situation #1: Application with too many spam bot registrations which generate many bounce email notifications.
In example #1, I see many things like the following in the mail logs where it seems to be attempting to send a bounce back to the app email address which of course isn't monitored nor even a real mailbox to receive mail at:
Sent bounce to <> for mail sent to www.app@<domain.tld>. Some recipients failed: <www.app@<domain.tld>. It's distracting to see so many of these in the logs when trying to review them for various reasons. I'm also worried this is producing unnecessary overhead on the mail server when there's a lot of them at once (rather than spread out by some time). To be fair, I have not noticed any performance impact, but would like to make sure to avoid one if possible.
Example situation #2: Application sending order confirmation emails to customers, but customer email provider blocks because of whatever spam policy they may have at the moment (this isn't too frequent but has occurred recently which I finally managed to get Microsoft to unblock for now for their domains).
In example #2, we never really know if an order email failed to go out unless I'm looking at the logs, and a customer would like to understand if an email failed to send from their website. How in that case could I get bounce-backs to go to another email address so that a user can see this happening? Right now since the emails go to an app email address which isn't even a real mailbox, nobody sees it unless it's brought to my attention from my own customer who may be receiving complaints from their customers. Being able to have the customer aware of those types of issues before they happen will be helpful to them.
Am I way overthinking all of this?
PS - Yes, I know one solution for example #1 would be just to cut the issue at the source by implementing better spam protection from bots in various applications, but that's always a moving target. I recently think I've fixed this for now on one of the apps that has this problem, but that's what got me thinking about some other possible scenarios and how they could be improved / addressed differently.
-
I just realized after posting this that I guess the solution for example #2 is to just change the from email address in the app, though that may not always be possible in every app (I think it should be in the ones I use though), and would perhaps expose a user's private mailbox that they don't want exposed to every customer notification being sent out. I suppose in that last part though it can be worked around with a dedicated alias or something like that which forwards to the user's private mailbox.
--
Dustin Dauncey
www.d19.ca -
I just realized after posting this that I guess the solution for example #2 is to just change the from email address in the app, though that may not always be possible in every app (I think it should be in the ones I use though), and would perhaps expose a user's private mailbox that they don't want exposed to every customer notification being sent out. I suppose in that last part though it can be worked around with a dedicated alias or something like that which forwards to the user's private mailbox.
-
@d19dotca I think if you have a catch all, the bounces will go to the catch all if the app mailbox does not exist. For important apps like newsletter, i tend to create a concretw mailbox and assign it to the app.
