Skip to main content

Undesirable Failed Delivery messages due to Box Trapper auto-resonses

Comments

11 comments

  • cPanelMichael
    Hello :) Redelivery attempts for messages in the mail queue occur based on the retry rules in the Exim configuration file: ###################################################################### # RETRY CONFIGURATION # ###################################################################### # This single retry rule applies to all domains and all errors. It specifies # retries every 15 minutes for 2 hours, then increasing retry intervals, # starting at 1 hour and increasing each time by a factor of 1.5, up to 16 # hours, then retries every 8 hours until 4 days have passed since the first # failed delivery. # Domain Error Retries # ------ ----- ------- begin retry * quota * * F,2h,15m; G,16h,1h,1.5; F,4d,8h
    You could modify these rules if you prefer. However, you may also want to consider disabling BoxTrapper if you find it's causing more harm than good on a particular account. Thank you.
    0
  • RayBornert
    Thank you for the reply. Disabling Box Trapper would be like shooting the dog; that's just not an option. I think the blame lies with the core nature of our present email system. Box trapper is essentially an auto-responder acting on behalf of the email recipient. So this issue arises from the actions of "any" auto-responder combined with a bogus sender email address. My email system (i.e. exim) sees the auto-response as just any other email that "I" chose to send. And it is processing bounces accordingly. Am I correct in assuming that while your solution would reduce the number of bounces, there would indeed still be one final bounce that I would receive? If this is the case then the problem is essentially unchanged. Bottom line: A spammer still caused my brain to read something that I DO NOT want to read even if it is just a bounce. I want an email system that prevents unwanted email from getting to my brain.
    0
  • cPanelMichael
    Right, you could reduce the retry attempts but that won't stop the messages from bouncing if it's not a valid address. You could open a feature request if you have a specific idea on how you prefer it's handled: Submit A Feature Request Thank you.
    0
  • RayBornert
    Any feature request would require a fix to our existing world-wide email mechanics. This issue is systemic. It has existed for over 20 years. It would not be fair to place the blame at the feet of those who wrote the original SMTP RFC's because they cannot have possibly grasped the scope of world wide email communications 2 decades beyond. They sought to model our real-world paper mail systems and for the most part they did except for 2 characteristics that now, in hindsight, we daily feel the effects of the original design. They failed to model 2 things: 1) postage stamps 2) envelope entropy And in so doing they ignorantly created a world where spammers can thrive like bacteria. Also too, the original design carries a default mindset that all email is desirable and servers should do their very best to carry the email from point A to point B and tell the sender when a failure occurs. This is normal for any kind of software. So the only way to fix this issue in the near term is to modify Box Trapper to "NEVER" send any auto-response if the source email is bogus so that my brain does NOT have to see spam bounces to bad addresses. Does this make sense?
    0
  • RayBornert
    Is there an EXIM config setting that requires a valid source email address before processing the message? This filtering step needs to occur "BEFORE" the auto-responders (like Box Trapper) send their standard replies. I need EXIM to blackhole all incoming email with an invalid sender email address. I do not want to see it or know about it.
    0
  • RayBornert
    Guys, I'd like to take responsibility for this issue. I was desperately reviewing config. settings for various email related things looking for anything I missed that might be the root cause. As it turns out, it seems that Spam-assassin was not selected to auto-delete incoming spam. So essentially what was happening is that SA was tagging the email with "yep it's spam" but then passing it along and Box-Trapper was then auto-responding, etc. etc. I immediately changed the auto-delete setting and that appears to have solved everything. I've done public developer support for various products for over 10 years and I know what it's like when a user starts a post where I proceed to offer help; and then when they learn that the problem was on their end they never seem to be interested in posting that to the thread. So the moral of this story is: CHECK SPAM-ASSASSIN AND BE TRIPLE SURE THAT AUTO-DELETE IS ENABLED. Thx for the thread.
    0
  • cPanelMichael
    I am happy to see you were able to determine the cause of the problem. Thank you for updating this thread with the outcome.
    0
  • Ryan Walda
    I was having this problem as well. My issue is it sends 1 email for each bogus spam address.. A better solution would be 1 email a day or week have a setting were you can do that that lists all the bogus emails that way I don't wake up in the morning with 15 mail emails each one listing the single spam address that has not responded to box trapper.. I did update SpamAssassin to auto delete but I had it set to filter all spam emails into spam folder but it seemed all went straight to my inbox. I just updated it to auto delete messages but having Boxtrapper send a summary instead of an email for each one would be a better setup. Thanks
    0
  • Ryan Walda
    I submitted a feature request too.
    0
  • cPanelMichael
    [quote="Ryan Walda, post: 1777281">I submitted a feature request too.
    Feel free to post the URL to the feature request to this thread. Thank you.
    0

Please sign in to leave a comment.