How can we improve WHMCS?

Share, discuss and vote for what you would like to see added to WHMCS

  1. Home
  2. Ideas
  3. Support
  4. Allow `Mail delivery failed: returning message to sender message` through the system that prevents an autoresponder from opening a ticket

Allow `Mail delivery failed: returning message to sender message` through the system that prevents an autoresponder from opening a ticket



9 Votes
Login to Vote
Hi,
Please allow Mail delivery failed: returning message to sender message through the system that prevents an autoresponder from opening a ticket.

since version 8.4 when we send an email via a ticket system to a client we have no way to know if there is a problem and that the customer did not get the email (because his mailbox is full or maybe we have a spelling error in his email address or any other error) - and this is a big problem.

in the past any such error would be identified by our mail server and a Mail delivery failed email was automatically sent to us and open a ticket with all the information and we were able to resend the email or correct the spelling etc.

Since version 8.4 any such email is blocked by the system that prevents an autoresponder from opening a ticket - and the only way to know that there is an Mail delivery failed error is to manually go over the Delivery Report in cpanel or the Support Ticket Mail Import Log - and this is a big problem.

The email is blocked since it contains the Auto-Submitted header with the value auto-replied or *. any such emails will not be imported into the WHMCS ticket system.
So please add a way for us to whitelist the Mail Delivery System email (usually something like [email protected]) So any such email will not be blocked and a ticket with all the relevant information will be opened like it use to be before version 8.4.

Regards,
Ram



2 Comments

Login to post a comment.

Official Response
WHMCS commented 13th May 22
Hi Ram,
Thanks for taking the time to submit this suggestion. In version 8.4 we implemented RFC-3834 compliance to support ticket email importing and auto-responders. To highlight a relevant part of the standard:

An automatic responder MUST NOT blindly send a response for every
message received. In practice there are always reasons to refuse to
respond to some kinds of received messages, e.g., for loop
prevention, to avoid responding to "spam" or viruses, to avoid being
used as a means to launder or amplify abusive messages, to avoid
inappropriately revealing personal information about the recipient
(e.g., to avoid an automatic indication that a recipient has not read
his mail recently), and to thwart denial-of-service attacks against
the responder. The criteria for deciding whether to respond will
differ from one responder to another, according to the responder's
purpose. In general, care should be taken to avoid sending useless
or redundant responses, and to avoid contributing to mail loops or
facilitating denial-of-service attacks.

...

- Automatic responses SHOULD NOT be issued in response to any
message which contains an Auto-Submitted header field (see below),
where that field has any value other than "no".

Source: https://datatracker.ietf.org/doc/html/rfc3834

The intention is to help prevent auto-responder loops and remove generic system messages from your support ticket queue. We'd be interested to hear details about the kind of problem this causes to your workflow, and ideas for meeting that specific desire whilst maintaining standards compliance.
ramf commented 13th May 22
Dear John.

I'm all for your intention to help prevent auto-responder loops and remove generic system messages from the support ticket queue. I really am.

As for your request to hear details about the kind of problem this causes my your workflow, and ideas for meeting that specific desire whilst maintaining standards compliance:

The problem is very simple (I think):
Sometimes, when sending an email to a customer via the support ticket system, the customer will not receive the email we sent because his mailbox is full or maybe because we misspell his email address we got from his while talking over the phone or even a misspelling originated from the customer himself that filled the "contact us" form with a wrong email address.

In any such a case an automatic email is being generated by the receiver mail server and we usually get it back as an email with the failure details.
This email is usually sent from a specific address like [email protected] or something like that.

The message is something like that:

From: Mail Delivery System <[email protected]>
Date: Fri, May 13, 2022 at 6:41 PM
Subject: Mail delivery failed: returning message to sender
To: <[email protected]>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

[email protected]
host gmail-smtp-in.l.google.com [173.194.76.26]
SMTP error from remote mail server after RCPT TO:<[email protected]>:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser v3-20020a05600c214300b00393eb39d060si5369091wml.15 - gsmtp

This is a very important email - and this is the only way for us to know that the email we sent was not delivered to the client (in the above example the email account that we tried to reach does not exist - probably a misspell in the address).

Until version 8.4 any such email was imported to our WHMCS without a problem and we could easily see that there is a problem.

So in order to maintain the goal of preventing auto-responder loops and remove generic system messages from our support ticket queue - I think you should add a whitelist that we can use to set the emails we do want to import to our support ticket queue regardless if they originated from an automatic responder or something like that.

Having the ability to add Mail Delivery System <[email protected]> to a whitelist and allowing such emails to be imported to our support ticket queue will keep the general goal of preventing **unwanted** automatic responders or generic system messages tickets while still allowing us to easily know that there is a problem with an email we sent without the need to manually go over the logs (in our mail server or in WHMCS) to search for such an error.

This is something that was working before version 8.4 and since it got removed (without any notice) we lost several business opportunities because an email we sent did not reach the desired destination without us knowing about it.

Hope it's clearer now.
If you need any more information - please let me know.
Regards,
Ram