home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  


sendmailSearch this book
Previous: 11.6 Handling user@thishost Chapter 11
Rule Sets 1 and S=
Next: 11.8 Things to Try

11.7 Rule Set 1

When we began this chapter, we explained that the sender's address was processed by a series of three rule sets: rule set 3, rule set 1, and the custom rule set specified by the S= delivery agent equate. We've described rule set 3 and S= , but we haven't yet described rule set 1. If we send all mail to a central hub , we don't really need a rule set 1. That's because there is nothing that we need to do to all sender addresses. In fact, most configuration files, even at large sites, have no need for a rule set 1. [4]

[4] Eric says, "Given it to do over, rule sets 1 and 2 wouldn't exist."

Still, it is wise to add a dummy rule set 1 (one that does nothing) to the client.cf file. For one thing, this makes it clear that you haven't simply omitted rule set 1 by oversight. It also allows us to illustrate some points about rule sets in general.

R$-             $@ $1@${HUB}            user -> user@hub
R$-@$w          $@ $1@${HUB}            user@local -> user@hub

S1 # Generic sender rewrite (unused)                                 

<- new

We place rule set 1 last in the client.cf file, as we will continue to do with any other unused rules. This declaration of rule set 1 illustrates three points about rule sets in general:

  • Rule sets do not have to be in any particular order in the configuration file. The sendmail program reads the entire file and sorts the rule sets internally.

  • A rule set containing no rules is a "do-nothing" rule set. The workspace passed to it is returned unchanged.

  • Rule sets that are declared but unused should be commented to indicate this fact.

The positioning of rule sets in the configuration file is largely a matter of individual taste. Some administrators like to keep custom rule sets (such as Hubset ) next to the delivery agent definition rather than with the general rules. We don't favor any particular approach over another. The overriding concern in any configuration file - which can be complex - should be for clarity and organization.