SURVIVOR: gateway.cf
About gateway.cf
syntax
  • Whitespace is generally ignored, unless otherwise noted.
  • boldface denotes keywords.
  • [brackets] denote optional keywords.
  • Separators (|) denote mutually exclusive keywords.
  • Comments begin with a # symbol, and may appear anywhere. Comments must be terminated with newlines. 
     <argname> : [a-zA-Z0-9\._-]+
     <argvalue> : [^ \n\t][^\n]*
     <name> : [a-zA-Z0-9\.+%@_-]+
     <number> : [0-9]+
     <path> : [^\n]*
     <regex> : [^ \n\t]*

gateway.cf controls the behavior of the Mail Gateway. The file is optional, if it does not exist message relaying will be disabled. There are no two-way message handling configuration options, and that service is always enabled.

Debug Level
syntax 
     debug level <number>

About Debug Level

The Debug Level keyword enables debugging output, which is sent to the mail.debug syslog facility. It is functionally equivalent to the -d flag in the command line interface and scheduler, except that debugging cannot be enabled until the configuration file is parsed. For this reason, debugging is automatically set to DEBUG_CONFIG when the configuration file fails to parse.

Dependencies

  • None.

Debug Level Keywords

debug level Set debugging to the specified level, if debugging was enabled at compile time. See include/debug.H for the level definitions, only the numeric values may be specified. DEBUG_PARSER will likely be the most useful level.

Examples

  1. Enable debugging of message parsing: 
         debug level 8192
Relay Domains
syntax 
     relay domain {
         <regex>
	 [...]
     }

     relay all domains

     relay localhost

About Relay Domains

Relay Domains specify which messages sg will accept for relay and to which addresses. If no domains are specified, message relaying is disabled. Domains are relevant to the destination (To or Cc) addresses in a message received by the gateway. For example, if the gateway receives a message with the headers 
  To: jsmith@monitor.site.edu
  Cc: tsmith@foo.org
  From: lsmith@bar.com
The domains monitor.site.edu and foo.org would be evaluated against the specified Relay Domains. If the domains matched, the message would be accepted for relay for the matching address.

The gateway cannot relay messages to addresses specified by Bcc. Only the Subject header and the message body are maintained during relay, all other header fields are modified or dropped.

Dependencies

  • None.

Relay Domain Keywords

relay domain Specify one or more regular expressions describing which destination domains are to be accepted for relay.
relay all domains Specify that all destination domains are to be accepted for relay.
relay localhost Specify that destination domains equivalent to the name of the host the gateway is installed on are to be accepted for relay. Currently, this is defined as destination domains equivalent to the fully qualified domain name of the gateway host, the string localhost, or where the destination domain is an alias for the FQDN of the gateway host.

To determine what the host FQDN is, use sc -o test=fqdn dtest.

Examples

  1. Relay messages destined for pager.site.org: 
         relay domain {
       ^pager\.site\.org$
     }

Relay Targets
syntax 
     relay user <name> {
         calllist <name>
         instance <name>
     }

     relay user <name> {
         person <name>
         via <name>
         instance <name>
     }

About Relay Targets

After an address matches a Relay Domain and is accepted for relay, Relay Targets determine to which Person or CallList the message will be relayed to. The Relay Target is determined by the user component of the address. For example, if the gateway receives a message with the headers 
  To: jsmith@monitor.site.edu
  Cc: person.sample.tsmith.mail@foo.org
  From: lsmith@bar.com
The Relay Targets would be based on jsmith and person.sample.tsmith.mail, assuming the domains were defined as Relay Domains.

Relay Targets come in two forms. Mapped targets are defined in this configuration file, as explained below. Implied targets are obtained from the destination address in the message being processed, and come in two forms:

  • calllist.instance.name@domain
    where instance is an instance as defined in instance.cf, and name is the name of a CallList.
  • person.instance.name.module@domain
    where instance is an instance as defined in instance.cf, name is the name of a Person, and via is the name of an Alert module defined within the instance to use for relaying. Note that only the transmit module specified will be used, the format module will be ignored.

Dependencies

  • The Instance specified by the instance keyword must be defined in instance.cf.
  • The CallList specified by the calllist keyword must be defined in calllist.cf.
  • The Person specified by the person keyword must be defined in calllist.cf.
  • The Alert specified by the via keyword must be defined in calllist.cf.

Relay Target Keywords

relay user <name> Define a new Relay Target. name is the user component of the address being processed for relay. If a message accepted for relay contains a destination address that matches name, the contents of the Relay Target will be used to determine where the message is relayed to.
calllist <name> Relay messages for the Relay Target to the CallList name.
instance <name> Use the Instance name to determine the definition of the specified Person or CallList.
person <name> Relay messages for the Relay Target to the Person name.
via <name> When relaying messages to a Person, use the Alert module name. Note that only the transmit module specified will be used, the format module will be ignored.

Examples

  1. To map messages destined for jsmith to the Person jsmith in the instance sample and to send messages to that Person with the mail Alert module: 
         relay user jsmith {
       instance sample
       person   jsmith
       via      mail
     }
$Date: 2006/11/19 16:52:30 $
$Revision: 0.3 $
 keywords
calllist
debuglevel
instance
person
relay all domains
relay domain
relay localhost
relay user
via