552 4.3.1 Session size exceeds fixed maximum session size
Created: 09 Jun 2010 | 4 comments
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?
Discussion Filed Under:
Comments
Google says:
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:
552 4.3.1 Session size exceeds fixed maximum session size
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?
Hi phhowe, Thanks for your
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.
Try turning Mail Transfer
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.
Would you like to reply?
Login or Register to post your comment.