|
13.2 :include: Mailing ListsThe special notation :include: in the right-hand side of an alias causes sendmail to read its list of recipients from an external file. For that directive to be recognized as special, any address that begins with :include: must select the local delivery agent and, beginning with V8.7, must have the F=: delivery-agent flag set (F=: (colon)). This is automatic with most configuration files, but if your configuration file does not automatically recognize the :include: directive, you will need to add a new rule near the end of your parse rule set 0 (Section 19.5). For example: R :include: $* $@ $#local $: :include:$1 Beginning with V8.7 sendmail, any delivery agent for which the F=: flag (F=: (colon)) is set can also process :include: files. (Note that eliminating the F=: flag for all delivery agent definitions in your configuration file will disable this feature entirely.) The :include: directive is used in aliases(5) files like this: localname: :include:/path
The expression :include: is literal. It must appear exactly as shown, colons and all, with no space between the colons and the "include." As with any right-hand side of an alias, there can be space between the alias colon and the lead colon of the :include:. The /path is the full pathname of a file containing a list of recipients. It follows the :include: with intervening space allowed. The /path should be a full pathname. If it is a relative name (such as ../file), it is relative to the sendmail queue directory. For all but V8 sendmail, the /path must not be quoted. If it is quoted, the quotation marks are interpreted as part of the filename. For V8 sendmail, the /path can be quoted, and the quotation marks are automatically stripped. If the /path cannot be opened for reading for any reason, sendmail prints the following warning and ignores any recipients that might have been in the file: include: open path: reason Here, reason is "no such file or directory," "permission denied," or something similar. If /path exists and can be read, sendmail reads it one line at a time. Empty lines are ignored. Beginning with V8 sendmail, lines that begin with a # character are also ignored: addr
# a comment
Each line in the :include: file is treated as a list of one or more recipient addresses. Where there is more than one, each should be separated from the others by commas. addr1 addr2, addr3, addr4 The addresses can themselves be aliases that appear to the left in the aliases file. They can also be user addresses, program names, or filenames. A :include: file can also contain additional :include: lists: engineers Beginning with V8.7 sendmail, the TimeOut.fileopen option (Timeout) controls how long sendmail should wait for the open to complete. This is useful when files are remotely mounted, as with NFS. This timeout encompasses both this open and the security checks described next. Note that the NFS filesystem must be soft-mounted (or mounted with the intr option) for this to work. Beginning with V8, sendmail checks the file for security. If the controlling user is root, all components of the path leading to the file are also checked.[3] If the set-user-id bit of the file is set (telling sendmail to run as the owner of the file), sendmail checks to be sure that the file is writable only by the owner. If it is group- or world-writable, sendmail silently ignores that set-user-id bit. When checking components of the path, sendmail will print the following warning if it is running as root and if any component of the path is group- or world-writable:
WARNING: writable directory offending component This process is described in greater detail under the -d44 debugging switch (-d44.4), which can also be used to observe this process. After sendmail opens the /path for reading, but before it reads the file, it sets the controlling user to be the owner of the file (if one is not already set, and provided that file ownership cannot be given away with chown(1)). The controlling user provides the uid and gid identities of the sender when delivering mail from the queue (C line). The :include: file can neither deliver through programs nor append to files if any of the following situations are true:
13.2.1 Comments in :include: ListsIDA and V8 sendmail allow comments in :include: files. Comment lines begin with a # character. If the # doesn't begin the line, it is treated as the beginning of an address, thus allowing valid usernames that begin with a # (such as #1user) to appear first in a line by prefixing them with a space: # Management Note that because comments and empty lines are ignored by sendmail, they can be used to create attractive, well-documented mailing lists. Under older versions of sendmail, comments can be emulated through the use of RFC-style comments: ( comment ) By surrounding the comment in parentheses, you cause sendmail to view it (and the parentheses) as an RFC-style comment and, thus, to ignore it: ( Management ) frida george@wash.dc.gov ( Staff ) ben steve This form of comment works with both the old and new sendmail programs. 13.2.2 TradeoffsAs has been noted, the aliases file should be writable only by root for security reasons. Therefore, ordinary users, such as nonprivileged department heads, cannot use the aliases file to create and manage mailing lists. Fortunately, :include: files allow ordinary users (or groups of users) to maintain mailing lists. This offloads a great deal of work from the system administrator, who would otherwise have to manage these lists, and gives users a sense of participation in the system. In some circumstances, reading :include: lists can be slower than reading entries from an aliases database. At busy sites or sites with numerous mail messages addressed to mailing lists, this difference in speed can become significant. Note that the -bv command-line switch (-bv) can be used with sendmail to time and contrast the two different forms of lists. On the other hand, rebuilding the aliases(5) database can sometimes be very slow. In such instances the :include: file can be faster because it doesn't require a rebuild each time it changes. One possible common disadvantage to all types of mailing lists is that they are visible to the outside world. This means that anyone in the world can send mail to a local list that is intended for internal use. Many lists are intended for both internal and external use. One such list might be one for discussion of the O'Reilly Nutshell Handbooks, called, say, nuts@oreilly.com. Anyone inside oreilly.com and anyone in the outside world can send mail messages to this list, and those messages will be forwarded to everyone on the nuts mailing list. It is possible to protect your internal lists from use by outsiders, but doing so requires writing custom rules. For possible rules you might adapt to your site's needs, see http://www.sendmail.org/~ca/email/protected.html.  |
empty line is ignored
addr2|
|