SMTP rules syntax conventions

Use the following syntax convention when writing SMTP rules:

Some keywords have special meaning to the rules interpreter. For example, NJEHostName keyword means the NJE host name of the present system, and TCPHostName keyword means the TCP host name of the present system. For more information about valid keywords see Predefined keywords within the SMTP rules. Some keywords, such as TCPHostName, have single values. Other keywords, such as AltTCPHostName and AnyDomainName, can have many possible values. To avoid ambiguity, any keyword that can have multiple values, and is used in the after-address-pattern of a given rule, must appear exactly once within the before-address-pattern of that rule. The following rule example shows a valid syntax:
```
         A '@' AltTCPHostName '.' AltTCPHostName =>
            A '%' TCPHostName '@' TCPHostName;
 
```
The following two rules have incorrect syntax because the first keyword AltTCPHostName must be rewritten to a keyword with specific values. The AltTCPHostName is attempting to be rewritten to the same AltTCPHostName but with unknown values, which is not valid.
```
         A '@' AltTCPHostName '.' AltTCPHostName =>
            A '%' AltTCPHostName '@' TCPHostName;

         A '@' TCPHostName => A '@' AltTCPHostName;
```
Any rule whose before-address-pattern includes a keyword that has a null value is ignored during the header rewriting. Thus, if there is no AltNJEDomain defined in the system configuration data set, no rule that includes AltNJEDomain in the before-address-pattern is considered during the header rewriting.
Alphanumeric identifiers that are not within single or double quotation marks, and that are not predefined keywords, are considered wildcards in the rule statement. Wildcards represent an arbitrary (non-null) sequence of characters. The identifier A, in the previous rule example, is a wildcard. Thus, if host were the NJE host name for the current site, and if tcphost were the TCP host name for the current site, the previous rule example recognizes abc@host and d@host as candidates for address rewriting, and rewrites them as abc@tcphost and d@tcphost respectively. To avoid ambiguity, within the before-address-pattern of a given rule, no two wildcards are allowed in a row, and the same wildcard cannot be used more than once. The following rules have valid syntax:
```
         A '@' B TCPHostName      => A '%' B '@' TCPHostName;
         A '%' B '@' NJEHostName => A B '@' TCPHostName;
```
The following rules have incorrect syntax because the first rule has 2 wildcards in a row A and B. The second rule has the same wildcard A repeated:
```
         A B '@' TCPHostName      => A A '%' B '@' TCPHostName;
         A '%' A '@' NJEHostName => A '@' TCPHostName;
```
A character string appearing within single or double quotation marks tells the rules interpreter where a particular string is to appear within a header address. In the previous rule example, the '@' string in the before-address-pattern tells the rules interpreter that an at-sign (@) must appear between the arbitrary character string and the NJE host name. The '@' string in the after-address-pattern tells the rules interpreter that the address must be rewritten so an at-sign appears between the arbitrary string and the TCP host name. As previously mentioned, single quotation marks denote strings that are not case-sensitive, and double quotation marks denote case-sensitive strings.
The character sequence "=>", with no spaces between the characters, separates the before-address-pattern from the after-address-pattern.
The order in which the rules are specified is important; the first rule encountered whose before-address-pattern matches the current address is the rule to dictate the address transformation. After a matching rule has been found for an address, no other rule is considered.

In addition to the rules themselves, there is the capability for some simple logic to decide at system configuration time which rules within the data set should become active. These conditions are specified in the form of an IF-THEN-ELSE statement, as shown in the following example:

   IF cond THEN
      statement list
   ELSE
      statement list
   ENDIF

A statement list can consist of any number of rules or nested IF statements, or both. Each IF statement, regardless of whether it is nested, must be ended by an ENDIF keyword. As with IF statements in other programming languages, the ELSE clause is optional.

There are only two conditions recognized by an IF statement:

IF predefined keyword = 'character string' THEN ... ENDIF
IF predefined keyword CONTAINS 'character string' THEN ... ENDIF

The conditional operators = and CONTAINS can be prefixed by the word NOT to invert the conditions.

The predefined keyword must be a keyword that resolves to a single value at system configuration time. The character string in the first condition can be null. A character string cannot span more than one line.

The following example shows the use of IF statements.

IF NJEDomain = '' THEN
   A '@' AnyNJEHostName => A '%' AnyNJEHostName '@' TCPHostName;
ELSE
   A '@' NJEHostName '.' NJEDomain    => A '@' TCPHostName;
   A '@' NJEHostName '.' AltNJEDomain => A '@' TCPHostName;
   IF NJEDomain CONTAINS '.' THEN
      A '@' AnyNJEHostName                   =>
         A '@' AnyNJEHostName '.' NJEDomain;
      A '@' AnyNJEHostName '.' NJEDomain    =>
         A '@' AnyNJEHostName '.' NJEDomain;
      A '@' AnyNJEHostName '.' AltNJEDomain =>
         A '@' AnyNJEHostName '.' NJEDomain;
   ELSE
      A '@' AnyNJEHostName                   =>
         A '%' AnyNJEHostName '.' NJEDomain '@' TCPHostName;
      A '@' AnyNJEHostName '.' NJEDomain    =>
         A '%' AnyNJEHostName '.' NJEDomain '@' TCPHostName;
      A '@' AnyNJEHostName '.' AltNJEDomain =>
         A '%' AnyNJEHostName '.' NJEDomain '@' TCPHostName;
   ENDIF
ENDIF