Predelivery Logic Administrator Manual

This manual describes the Predelivery Logic as part of Retarus Email Security. Retarus Email Security is the mandatory base for using the Predelivery Logic.

With the help of the Predelivery Logic, customer-specific requirements concerning the processing of
incoming or outgoing emails can be flexibly implemented.

The manual describes the general functionality, possibilities and limitations of the Predelivery Logic
and how to administrate it.

Prerequisites

In order to be able to use the Predelivery Logic (Inbound and Outbound), the service has to be booked
by the customer as part of the Retarus Secure Email Platform and activated by Retarus.

General processing logic and limitations

Inside the “Predelivery Logic” as part of the Retarus Email Security portfolio, individual, customer- specific rules can be created, consisting of "conditions" and associated "actions". For example, routing or rewriting can be based on certain header information such as sender, recipient or subject of an email. Predelivery Logic works for Inbound and Outbound emails. Some conditions and actions are only available for In- or Outbound.

Definition of terms and general processing logic:

• Ruleset describes the complete set of rules inside the Predelivery Logic for one customer.
  Up to 100 rules may be created.

• Rule describes a combination of conditions and actions.

  • Every rule may include max. 100 conditions and exactly one action to be performed
    with an email.

  • Rules are processed in a defined order which can be adapted by using “priority”
    numbers.

  • Only one rule is executed for an email (if any) – the first one where ALL conditions
    match. Afterwards, the particular email is not processed any more by the Predelivery
    Logic. Any other rules with lower priority are skipped. This is done in order to avoid
    roundtrips and unwanted side effects.

  • If a rule contains one or more invalid conditions or actions, it is not processed at all.
    (Normally, invalid entries should not occur as all entries are validated.)

• Conditions inside a rule are AND-connected. This means that only if ALL conditions of a rule
  match, the defined action is executed. If you would like to have an OR-connection, you may
  use two separate rules containing the same action, but different conditions. If you don’t define
  any conditions for a rule, it will not be taken into consideration (even if you activated the rule
  explicitly).

• Action is executed when all related conditions of the rule match. Only one action per rule
  may be created.