Messaging Gateway

Hi,

We are running SBG 8.0.3-11. Some of the emails are bouncing back to the users with the below error. It is not Sender/Recepient based. It is spontaneous. The same email will be received properly, if tried the next time.

"552 4.3.1 Session size exceeds fixed maximum session size"

Did anyone faced this problem in your infra?

Google says:

                This SMTP error can occur when sending too many emails in a single SMTP session.
               (It entirely depends on the SMTP server involved, whether there are limits, and the SMTP server settings.

Is the error associated with a particular sending IP address?

Try looking at your scanner's   Admin / config / <scanner> / SMTP / Advance / inbound and the property
             Maximum number of connections from a single IP address:

Hi phhowe,

Thanks for your reply. I had seen that, when I did a googling.

But there are not much connections which I had senn frmo that particular IP or domain. There was only one email which was sent in a particular interval, so not sure whether maximum number of connections will be helpful in this. Moreover we have the default value set here. Also the email size is just 5 MB compared to the configured limit of 12MB.

I am facing the same problem. Have SBG 8.0.3-11 configured for inbound mail relay.
The number of connections from a single IP address is set as default say 2000.
But the problem is not with acceptance from the sender. The issue that we are observing is that after being accepted by SBG the scanner is trying to relay the mail downstream but that does not happen.

Moreover the number of connections per unit time from the sender MTA of the domain is very negligible. There is no way the threshold could have been exceeded.

Further more, the mail is lost as it is not even retained in the delivery queues.

Can you please help?

Try turning  Mail Transfer Agent log level to at least Information  and when the error is happening    Sender -> public IP address, Inbound IP to 127.0.0.1 hand-off to scanner subsystem, or the local IP to next inbound hop.  That should help narrow it down.