Mail Flow Policies Connection Behavior ($CONTINUE)

Unanswered Question
Aug 15th, 2007

When to use "Continue" Connection behavior in mail flow policies?
What's the difference between "Continue" and "Accept"?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
kluu_ironport Thu, 08/16/2007 - 19:39

When to use "Continue" Connection behavior in mail flow policies?
What's the difference between "Continue" and "Accept"?

The short answer is when a connection behavior is sent to "continue", that connection is sent back to the HAT Overview to continue down the list until it matches another Sendergroup or matches the Default ALL.

You generally don't need to use the "Continue" connection behavior because it doesn't have any effect on the behavior of the message. It is in a sense a placeholder. If a connection matched a Sendergroup that had a Mail Flow Policy set to Continue, then that's exactly what would happen to the message, it would continue going down the list of Sendergroups. If it didn't match anything, it would default to the ALL sendergroup.

The difference between "Continue" and "Accept" is that Accept is finite and the "buck stops there". The message is accepted and the mail flow policies are applied. For "continue", you keep going down the list of sendergroups until there's a match or it goes to the ALL sendergroup, which will probably be set to ACCEPTED anyway.

Here is an example.

Let's say you have this for your HAT Overview/Mail Flow Policies:

Order 	Sendergroup		Mail Flow Policy
====== ============= =================

4 SUSPECTLIST (-3 to 0) THROTTLED (continue)

Let's say for example, the connecting server has a SBRS score of -2.5. It would match the Suspectlist SG and the mail flow policy would be Throttled(continue). Since the connection behavior is set to "continue", the connection is basically sent back to the HAT Overview to find another match. In the HAT Overview, it starts where it was last and continues down the list. If there is not match in the SG, then it will match the default ALL and be applied the ACCEPTED mail flow policy.

When would you use the "continue" connection behavior?

I would not see too many occasions when it would be benefical to use the "continue" connection behavior.


None that come to mind. If anyone knows of one, feel free to add it.


1. It doesn't display in the mail_logs that you had matched the "continue" connection behavior.

2. Tracking down the connection behavior is more work.

3. As far as mail flow limits, it doesn't really do anything.
kluu_ironport Thu, 08/16/2007 - 19:49

Also, some folks may wonder what's the difference between REJECT and TCPREFUSE in the connection behavior of the mail flow policies. This was taken from the Support Portal knowledge base
(, then click on Support Portal on the left side.

What is the difference between REJECT and TCPREFUSE?

You can configure your Email Security Appliance (ESA) to restrict connections by adding any of the following items to Sender Groups which use Mail Flow Policies:

  • IP range
  • specific host or domain name
  • SenderBase Reputation Service (SBRS) "organization" classification
  • SBRS score range
  • DNS List query response

Each Mail Flow Policy has an access rule, such as ACCEPT, REJECT, RELAY, CONTINUE, and TCPREFUSE.

A host that attempts to establish a connection to your ESA and matches a Sender Group using a TCPREFUSE access rule is not allowed to connect to your ESA. From the standpoint of the sending server, it will appear as if your server is unavailable. Most MTA's will retry frequently in this case.

A host that attempts to establish a connection to your ESA and encounters a REJECT will receive a 554 SMTP error (hard bounce).

For most implementations REJECT is a better policy as the sending ESA knows instantly that your domain will not accept messages from them. This not only reduces overall load on your appliance, but the sender recives a Non Deliverable Report (NDR) immediately instead of waiting for the retries to expire, which can take as long as five days for some senders. If the sender was erroneously blocked, this can be useful.

AsyncOS User Guide: Access Rules and Parameters


This Discussion