How to Create and Organize Advanced Acceptance and Routing Rules

   The administrator can configure and implement message acceptance and routing rules and adjust them to best suit their security requirements. Incoming connections established via SMTP and the message flow can be easily managed using the advanced rules. They allow adding/modifying headers, changing addresses and other actions.
   The Acceptance and Routing rules will be applied from top to bottom (with reference to the view in Webadmin -> Security & Filtering -> Acceptance & Routing -> Advanced Settings tab), in the order they appear in the rules table. The rules are separated automatically on an event bases.

   The distribution process for a rule to a specific event is done automatically when you create the rule. The event is chosen based on the conditions you select for that rule.
   This means that if you choose for example "Recipient -> Email is local" as a condition, the rule will be automatically assigned to the "On Recipient" event. This is due to the fact that the recipient email will only be available to the Axigen server, after the "rcpt to:" command is received in the SMTP session. As such applying the rule on a previous event would not be possible.
   To better understand the events and the parameters that are available on each event, you can consult our related documentation pages:

https://www.axigen.com/docs/en/Message-Acceptance-Rules_241.html
https://www.axigen.com/docs/en/Language-Specifications-for-Policy-Configuration_242.html

NOTE: In case you have multiple conditions, involving parameters that are received at different events, the rule will be applied in the event where all the parameters are available. For example at the "On Recipient" event all the parameters obtained at the previous events are available to the Axigen server.

   The event on which the rule is applied can also be viewed in the rule creation window, to allow you to choose the correct conditions if you have a requirement that the rule be applied on a specific event and to permit a better understanding on how the rule you create will be applied, while you are editing the rule. The below screenshot shows the position of the information section in the rule creation window.



   When you have several rules that apply on an event, a good practice is to arrange the rules, in that event section, from the ones that target "global" conditions (all incoming connections/emails or most of these), to the more fine grained, specific, rules that match a certain ip/connection/user account etc.
   Thus you ensure that global policies rules (ex: rules that address an entire domain) apply first, modifying certain parameters and after that the more "specific" rules (ex: rules that apply for a single account in that domain) will override the necessary parameters.

   Arranging the rules in an event section can be accomplished using the arrow buttons, available in the "Priority" column, as shown in the below screenshot.



   Please note that the last rule that matches a certain session, will set the parameters it was designed to modify, overriding any previous settings for those parameters that other rules have set.

   For example, if rule_three in the above picture would state: "If the sender domain is example.com -> allow remote delivery only for authenticated users" and rule_four states: "If sender email is a@example.com -> allow remote delivery without authentication" a new email that would be sent by user a@example.com would match both rules. Rule_three would apply first setting the "remoteDelivery" parameter to "auth" and then rule_four would match the session and set the "remoteDelivery" parameter to "all". However if the recipient in the above example email would be b@example.com and rule_five states: "If recipient account is b@relay.com -> deny remote delivery", then this rule would also be matched in the "On Recipient" event and the "remoteDelivery" parameter would be set to "none".

NOTE: Each message is checked against all the rules corresponding to the events it passes through. For example an email that has a local recipient will be filtered with all the rules available in the "onConnect", "onEhlo", "onMailFrom", "onRcptTo", "onHeadersReceived", "onBodyChunk", "onDataReceived" and if the required issues are encountered through "onTemporaryDeliveryFailure" and/or "onDeliveryFailure". An email destined for an external domain would also be checked against the rules of the "onRelay" event.