Address parsing is done according to the rewriting rules, a simple pattern-matching and replacement system. sendmail scans the set of rewriting rules looking for a match on the left-hand side (LHS) of the rule. When a rule matches, the name is replaced by the right-hand side (RHS) of the rule.
There are several sets of rewriting rules. Some of the rewriting sets are used internally and must have specific semantics. Other rewriting sets do not have specifically assigned semantics and can be referenced by the mailer definitions or by other rewriting sets.
For example:
Sn |
sets the current rule set being collected to n. If you begin a rule set more than once, the new definition overwrites the old definition.
R is used to define a rule in the rule set. The syntax of the R line is:
Rlhs rhs comments |
The lhs is a pattern that is applied to the input. If it matches, the input is rewritten to the rhs. The comments are ignored.
Here is an example of how a rule definition might look:
# handle "from:<>" special caseR<> $@@ turn into magic token |
The fields must be separated by at least one tab character; you can use embedded spaces in the fields.
Programs and interfaces to mailers are defined on this line. The format is:
Mc name, c {c field=value}* |
where name is the name of the mailer (used in error messages) and the field=value pairs define attributes of the mailer. Table 3-7 shows the fields.
Table 3-7 Mailer Definition Fields
Field |
Description |
---|---|
A |
An argument vector to pass to this mailer |
D |
The working directory for the mailer |
E |
The end-of-line string for this mailer |
F |
Special flags for this mailer |
L |
The maximum line length in the message body |
M |
The maximum message length to this mailer |
P |
The path name of the mailer |
R |
A rewriting rule set for recipient names |
S |
The new version of sendmail (version 8) includes a new configuration option which defines the version of the sendmail.cf file. This will allow older configuration files to be used with Version 8 sendmail. You can set the version level to values between 0 and 5. You can also define the vendor. Either Berkeley or Sun are valid vendor options. If the V option is not defined in the configuration file the default setting is V1/Sun. If a version level is specified but no vendor is defined, then Berkeley is the used as the default vendor setting. Table 3-8 lists some of the valid options.
Table 3-8 Configuration File Version Values
Field |
Description |
---|---|
V0/Sun |
Do not use Solaris extensions for name service support. |
V1/Sun |
Use Solaris extensions of name service support. This is the default setting. |
V1 |
Use for older Berkeley configuration files. |
V5 |
Use for new Berkeley configuration files which set $w to be the short hostname. |
If Sun is defined as the vendor, then only V0 and V1 may be used to define the level.