Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources

When trying to telnet to the SMTP port of an Exchange 2007 Hub Transport server, it issues the following error:

452 4.3.1 Insufficient system resources

The Application Event Log has Event ID 15002 from MSExchangeTransport saying “The resource pressure is constant at High. Statistics… “ and goes on to tell you that inbound mail submission has stopped, and it’s due to disk space being low on the volume where the queue database is located.

What’s Back Pressure?

In Exchange Server 2007, the Transport service monitors system resources such as disk space and memory on Transport servers (the Hub Transport and the Edge Transport servers), and stops message submission if it’s running low on these resources. It continues to deliver existing messages in the queue. When resource utilization returns to normal, it resumes message submission. The feature is called Back Pressure.

In this case, Exchange required 4 Gigs of free disk space on the volume where the Queue database was located – I had about 3.95 Gigs. 🙂

Changes to Back Pressure settings in Exchange Server 2007 SP1

The Back Pressure settings in Exchange Server 2007 RTM stop inbound mailflow if free disk space is below 4 Gigs. This static threshold has been lowered in SP1 to a more realistic 500 MB.

The Resolution

Many configuration options for transport servers are saved in an XML file namedEdgeTransport.exe.config (it’s the same file name on both server roles— Edge Transport and Hub Transport) located in \Exchange Server\Bin\.

To get transport to resume submissions, you can use any of the following methods. All of the following require you to edit the EdgeTransport.exe.config file.

  1. Disable BackPressure: Although Microsoft doesn’t recommend it, it does provide a way to Disable Back Pressure
  2. Tweak BackPressure thresholds: Modify BackPressure parameters to more accurately define what’s high utilization for your deployment or server configurations, as explained in the above docs.
  3. Move the queue database to another volume: Another resolution, and the one I used in this case, was to move the queue database to another volume with ample of free space, using the following procedure:
    1. Add the following key in the <AppSettings> section in EdgeTransport.exe.config, as documented in “How to Change the Location of the Queue Database“:

      <add key=“QueueDatabasePath” value=”D:\Queue\QueueDB” />

    2. Save the file and restart the Microsoft Exchange Transport service from the Services console or by using the Restart-Service cmdlet (Restart-Service MSExchangeTransport).

Solved: 552 4.3.1 Message size exceeds fixed maximum message or 552 5.3.4 Message size exceeds fixed maximum message

When email is sent by my SMTP Relay (or Forward in POP3 downloader) module I see errors in the log saying “552 4.3.1 Message size exceeds fixed maximum message” or “552 5.3.4 Message size exceeds fixed maximum message”. This is typically when sending email to Microsoft Exchange. What can I do?

Those errors are being reported from the next server, the one Hexamail is trying to send the email onwards to. In the log just above it should say which server is being contacted. Typically this error message is generated by message limits set in Microsoft ISA server, Microsoft Exchange or Symantec Antivirus SMTP gateway.

Setting the maximum message size is of course different in almost every single version of Exchange. Follow the links below to find out how to do so in each version:

Exchange 2000

Exchange 2003

Exchange 2007 or here

Exchange 2010

A general discussion thread on Technet

Quarantine in Exchange Server IMF


Exchange 2003 IMF and Exchange 2007 Content Filter do have their own Quarantine functionality.  In Exchange 2003 you can Quarantine Emails into an archive directory.  You can then use one of the freely available Archive viewers to release emails. This is a little fiddly to do.


 Exchange 2007 provides the Quarantine by routing blocked emails to a central mailbox.


 In addition both versions support routing emails to the user Junk Email folder. In this manner users can review filtered spam on their own. In order to release the email more configuration is required

The disadvantages of quarantining spam inside Exchange or in user mailboxes are as follows:

– Once in the Exchange server the spam has already wasted processing resources. There may be many thousands of spam email!

– Once in the Exchange server the spam has already wasted storage resources

– If using a central quarantine, the admin has to manually review and release spam using limited tools to browse the quarantine and identify the spam vs non spam email

– If spam goes to user mailboxes then the administrator cannot easily mass-delete blocked spam for users

– If spam goes to user mailboxes then the administrator cannot easily add specific blocks and reject rules based on the  blocked spam to prevent similar spam even arriving in the quarantine in future.

–  If spam goes to user mailboxes then the users may inadvertently trigger malware or scripts or open attachments in the spam email and infect their machines. Any images shown in the spam may track their viewing

of the spam and notify the spammer that the email address is active.

So it seems its best to keep spam (as email) away from the user mailboxes, and quarantine it outside of Exchange.

Hexamail Guard allows you to  quarantine spam BEFORE it reaches Exchange. The advantages of this approach:

– Eliminate  processing and storage requirements on Exchange.

– The Administrator can review spam in large volumes, grouped by subject, block rule, country code, ip address etc.

– The Administrator can perform batch operations such as deleting all spam of a similar nature

– The Administrator can perform batch operations such as releasing all nonspam of a similar nature

– The Administrator can use blocked spam to setup new rules to automatically  reject or delete future spam before it is even quarantined

– The Administrator can whitelist nonspam senders so that in future they are never blocked.

– Users can review their spam using a web interface that is entirely safe, only the text of the email is rendered so no scripts or attachments can be triggered.

– Users can whitelist non spam senders for their specific account so that they will receive email from those senders unhindered in future.

– Users on restricted bandwidth (such as mobile devices) don’t have to waste time downloading spam email. They can review the headers and delete or accept email in a fully responsive web app.

Some of the features of the administrator spam quarantine are shown here