![]() ![]() |
19.1 The S Configuration CommandThe S configuration command declares the start of a rule set. It is perhaps the simplest of all configuration commands and looks like this: Sident
The S, like all configuration commands, must begin the line. The ident identifies the rule set. There can be whitespace between the S and the ident. If the ident is missing, sendmail prints the following error message and skips that particular rule-set declaration: configfile: line num: invalid ruleset name: "" Prior to V8.7 sendmail the ident could only be numeric. Beginning with V8.7 sendmail the ident can be numeric or alphanumeric. We cover the old form first, then the new. 19.1.1 Rule-Set NumbersPrior to V8.7 sendmail, rule sets could be identified only by numbers. When a rule set is declared with an integer, that integer is taken to be the numeric identity of the rule set: S#
Here, # is an integer such as 23. If the # is greater than 100[1] (the maximum number of numbered rule sets allowed), or is negative, sendmail prints and logs the following error:
configfile: line number: bad ruleset # ( maximum max) and each rule following that bad rule-set declaration will produce the following error: configfile: line number: missing valid ruleset for "Rrule shown here" 19.1.2 Rule-Set NamesBeginning with V8.7 sendmail, rule sets can be declared with numbers (as in the previous section) or with more meaningful names. The form for a rule-set name declaration looks like this: Sname
The name can contain only ASCII alphanumeric characters and the underscore character. Any bad character causes that character and the characters following it to be silently ignored: My_rule Case is recognized; that is, Myrule and MYRULE are different names. You can use any name that begins with an uppercase letter. Names that begin with a lowercase letter or an underscore character are reserved for internal use by sendmail. There can be, at most, MAXRWSETS/2 named rule sets (MAX...). Each rule set that is declared beyond that amount causes sendmail to print the following error and ignore that rule-set declaration:
name: too many named rulesets ( # max)
When you declare a rule-set name, sendmail associates a number with it. That number is selected by counting down from MAXRWSETS. That is, the first name is given the number MAXRWSETS-1, the second is given the number MAXRWSETS-2, and so on. Named rule sets can be used anywhere that numbered rule sets can be used. 19.1.3 Associate Number with NameWhen associating a named rule set with a number of importance, you can create that association when the name is declared. The form of such a combined declaration looks like this: Sname=num
Here, the rule set named name is declared. Instead of allowing sendmail to associate a number with it, you create the association yourself by following the name with an = character and then an integer num. Arbitrary whitespace can surround the = character. If the integer is missing or nonnumeric, sendmail prints the following error and skips that rule-set declaration: configfile: line num: bad ruleset definition "bad" (number required after `=') Different names should not share the same number: Sfoo=1 Sfee=1 If they do, the second declaration will produce the following warning: WARNING: Ruleset fee=1 has multiple definitions The same name cannot be given a different number. Consider the following example: SMyrule=1 SMyrule=2 This causes sendmail to print the following error and skip the second declaration: configfile: line num: Myrule: ruleset changed value (old 1, new 2)
Named rule sets have numbers associated with them when they first appear. If you use a named rule set in an S= equate for a delivery agent and then later attempt to assign it a value, you will get an error such as the previous example: Mprog, P=sh, ...., S=Myrule, ... ... SMyrule=2 The solution is either to move the rule-set declaration (and its rules) so that they reside above the delivery agent declaration or to declare a numeric association in the delivery agent declaration instead of in the rule-set declaration: Mprog, P=sh, ...., S=Myrule=2, ... ... SMyrule You could also place just the S line above the delivery agent declaration and the rules, without the =2, below it: SMyrule=2 Mprog, P=sh, ...., S=Myrule, ... ... SMyrule In general, we recommend that you assign numbers to named rule sets only if there is a genuine need. 19.1.4 Macros in Rule-Set NamesMacros can be used in any or all of a part of a rule-set declaration. They can be used to declare a name: D{NAME}myname S${NAME} or to declare a number: D{NUMBER}12 S${NUMBER} or both a name and a number: D{NAME}myname D{NUMBER}12 S${NAME}=${NUMBER} or even the whole thing: D{SET}myset=12 S${SET} You can use single- and multicharacter sendmail macros in any combination. Macros can be used in any rule-set declaration, including subroutine calls inside rules: R $* < $=w > $* $@ $>${NAME} $2 But they cannot be used in the S= or the R= of delivery agents: Mprog, P=sh, ..., S=$X, R=$X, ... Macros can be used in the command line to modify a configuration file when sendmail is run. Consider the desire to call one rule set when running as a daemon and another when processing the queue. You might declare such rules like this: R $* $: $&A R daemon $@ $>Daemon_ruleset R queue $@ $>Queue_ruleset R $* $@ $>UndefinedA_ruleset The two different runs might look like this: # /usr/sbin/sendmail -MAdaemon -bd # /usr/sbin/sendmail -MAqueue -q30m The first defines the $A sendmail macro to have the value daemon and results in this subroutine call: R daemon $@ $>Daemon_ruleset The second defines the $A sendmail macro to have the value queue and results in this different subroutine call: R queue $@ $>Queue_ruleset Note that any different or missing command-line setting for $A will result in the fallback subroutine call: R $* $@ $>UndefinedA_ruleset Also note that you can also define multicharacter macros from the command line. But to protect such multicharacter names from being interpreted by the shell, you should quote them: # /usr/sbin/sendmail -M"{RunMode}"daemon -bd # /usr/sbin/sendmail -M"{RunMode}"queue -q30m Also note that defining macros from the command line can result in sendmail giving up special privileges. 19.1.5 Rule Sets and Lists of RulesAll rules (R lines) that follow a rule-set declaration are added to and become part of that rule set: S0 R... Rule sets need not be declared in any particular order. Any order that clarifies the intention of the configuration file as a whole is acceptable. If a rule set appears more than once in a configuration file, V8 sendmail will print a warning: WARNING: Ruleset name redefined and append the new rules to the old: S0 R... Note that the warning is given in all cases prior to V8.8, but beginning with V8.8, it is issued only in -bt rule-testing mode (Section 8.1) or if the -d37.1 debugging switch (-d37.1) is set. Other configuration commands can be interspersed among rule definitions without affecting the rule set to which the rules are added: S0 R... Prior to V8.10, any rules that appeared before the first S command were added to rule set 0 by default. With V8.10 and above, sendmail rejects any rules that are not preceded with a valid rule set definition. 19.1.6 Odds and EndsArbitrary text that follows a rule-set declaration is ignored unless it appears to be part of the declaration: S11 100 more rule sets Although the first and last of these examples work, we recommend that you use the # commenting mechanism instead (available with version 3 and higher configuration files): S11 #100 more rule sets A rule-set declaration that has no rules associated with it acts like a do-nothing subroutine (one that returns its workspace unaltered): Stest1 19.1.7 Rule Sets and m4When building a configuration file using the m4 technique (Section 4.1), sendmail reserves certain rule-set numbers and names for its own use. Using the m4 technique, you can add rules to those rule sets, but you cannot replace those rule sets with your own. A few m4 keywords are available to make adding rules easier. They affect rule sets 0 through 3 (now called parse through canonify) directly, and other rule sets indirectly (see Table 4-2 in Section 4.3.3). The configuration file created with the m4 technique uses quite a few rule sets beyond the base group. To avoid name collisions, we recommend you begin all your own named rules with a leading capital letter. |
![]() ![]() |