Syntax Convention of the SMTP Rules

The previous example of the rewriting rules shows that you must follow several syntactical conventions. The conventions are:

Some keywords have special meaning to the rules interpreter. For example, RSCSHostName keyword means the RSCS 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 invalid 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 and becomes invalid.
```
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 AltRSCSDomain defined in the system configuration file, no rule that includes AltRSCSDomain in the before-address-pattern is considered during the header rewriting.
Alphanumeric identifiers that are not within apostrophes 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 RSCS 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, no two wildcards are allowed in a row, and the same wildcard cannot be used more than once, within the before-address-pattern of a given rule. The following rules have valid syntax:
```
A '@' B TCPHostName      => A '%' B '@' TCPHostName;
A '%' B '@' RSCSHostName => A B '@' TCPHostName;
```
The following rules have invalid syntax because the first rule has two 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 '@' RSCSHostName => A '@' TCPHostName;
```
A character string appearing within apostrophes 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 RSCS 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, apostrophes denote case-insensitive strings, 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. Once 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 file 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 terminated by an ENDIF keyword. As with IF statements in other languages, the ELSE clause is optional. There are only two conditions recognized by an IF statement:

IF predefined keyword = 'character string' THEN
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 is an example of the use of IF statements.

IF RSCSDomain = '' THEN
   A '@' AnyRSCSHostName => A '%' AnyRSCSHostName '@' TCPHostName;
ELSE
   A '@' RSCSHostName '.' RSCSDomain    => A '@' TCPHostName;
   A '@' RSCSHostName '.' AltRSCSDomain => A '@' TCPHostName;
   IF RSCSDomain CONTAINS '.' THEN
      A '@' AnyRSCSHostName                   =>
         A '@' AnyRSCSHostName '.' RSCSDomain;
      A '@' AnyRSCSHostName '.' RSCSDomain    =>
         A '@' AnyRSCSHostName '.' RSCSDomain;
      A '@' AnyRSCSHostName '.' AltRSCSDomain =>
         A '@' AnyRSCSHostName '.' RSCSDomain;
   ELSE
      A '@' AnyRSCSHostName                   =>
         A '%' AnyRSCSHostName '.' RSCSDomain '@' TCPHostName;
      A '@' AnyRSCSHostName '.' RSCSDomain    =>
         A '%' AnyRSCSHostName '.' RSCSDomain '@' TCPHostName;
      A '@' AnyRSCSHostName '.' AltRSCSDomain =>
         A '%' AnyRSCSHostName '.' RSCSDomain '@' TCPHostName;
   ENDIF
ENDIF