Back to Community Threads
2
Immediate bounce for over quota recipients
Idea shared by Chris - 2/22/2024 at 8:04 PM
Proposed
I noticed for example, when you send an email to gmail, and the recipient's inbox is full, the message will keep retrying according to the retry intervals and finally bounce once it reaches the last retry interval. This seems inefficient because it keeps retrying, taking up server resources, and the message is stuck in the spool for a bit. Google sees too many attempts from your IP. It just makes more sense to me to immediately bounce the message. 

6 Replies

Reply to Thread
0
Chris,

You're exactly right that it would be move efficient.

Only issue is that SmarterMail would need to read these error messages from various providers, which are subject to change.

Bur maybe just follow Google and Office365 verbiage / codes.
3
Gmail (and most other mail services) is returning a 4XX error when a mailbox is full. 4XX messages are temporary errors so a MTA is supposed to retry later when getting these, as opposed to 5XX messages that should be treated as permanent failure triggering no retries and immediate notification.

So here SM is doing the right thing. Retrying until the max retries are reached.

Gmail shouldn't count these as if you were hammering their servers as they ask the sender MTA to retry.

In between some retries, the target user might have cleaned his mailbox after receiving a notification from gmail that it is full and is rejecting messages, so the mail might finally get delivered a bit later.

You can not rely on the error description returned by the MTA alongside the error code. It can be of any form. Therefore only the return code matters.

However, this is a setting that might be of your interrest:


This should tell SM to notify the sender that his mail is still in queue after X attempts.
So he knows the mail he sent did not reached the destination but that there are still attempts at delivering it.

You might set it to something low enough, depending on how you configured the delivery attempts intervals.

With our setting set to 10 and our retry intervals, it should be something like after 3h

Kind regards
Sébastien Riccio System & Network Admin https://swisscenter.com
0
Our clients are businesses that send time sensitive emails. Although what you are saying theoretically makes sense, but rarely do people clear out their inboxes right away or at all. We have one of the largest, if not THE largest, Smartermail installations, so clearing out messages that don't necessarily need to sit in the spool is key. Maybe add this feature as a toggle you can turn on or off? To bounce 4xx return codes faster?
0
Bouncing 4xx is unlikely to happen as it is not standards compliant.

The closest thing they may do which could be useful is to add 'retry rules' so you could craft handling based upon the recipient MX and the error code. Similar functionality exists in Exim (open source):


If you are running a seriously large installation then offloading delivery to something like Exim or Postfix would be worth considering. In my experience it handles large spools much better than Smartermail plus you can do some clever things in your exim.conf that provides for infinitely more flexible mail handling.
1
Matt Petty Replied
2/23/2024 at 11:29 AM
Employee Post
"Our clients are businesses that send time sensitive emails." 

I would use less retry intervals then. You could do like 1, 2, 3, 4, 5, if you don't want to be sitting on the email for more than 15 minutes. This also has the effect of your user quickly getting the bounce rather than left wondering where the email is. If they are time sensitive it's probably safer to bounce than let it sit around, for any reason.
Matt Petty Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
I was referring to using Smartermail FREE as outbound SMTP servers. We currently have intervals set to 15,30,60,90. With delay notifications set at 2 and DNS bounce also set at 2. It works.

This was just me thinking out loud to see if anyone else has a lot of emails sitting in "waiting to deliver". If you all are more worried about complying with RFC standards then we can just leave it. 
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

Common Email Delivery ErrorsSmarterMail > Troubleshooting
Cannot Add Attachments Using the SmarterMail Web InterfaceSmarterMail > Troubleshooting
Resolving JSON IssuesSmarterMail > Troubleshooting
Use LDAP with OutlookSmarterMail > Desktop and Mobile Synchronization
Set up SmarterMail as an IIS Site in IIS 10SmarterMail > Server Configuration and Management