This metasymbol resolves hostname to canonical name. It is replaced by the canonical form of the host name supplied. $(map key $@arguments $:default $) This is the more general form of lookup. The output is the result of looking up key in the map named map passing arguments as arguments. The map can be any of the maps that sendmail supports such as the virtusertable that we describe a little later. If the lookup is unsuccessful, default will be output. If a default is not supplied and lookup fails, the input is unchanged and key is output. $>n This will cause the rest of this line to be parsed and then given to ruleset n to evaluate. The output of the called ruleset will be written as output to this rule. This is the mechanism that allows rules to call other rulesets. $#mailer This metasymbol causes ruleset evaluation to halt and specifies the mailer that should be used to transport this message in the next step of its delivery. This metasymbol should be called only from ruleset 0 or one of its subroutines. This is the final stage of address parsing and should be accompanied by the next two metasymbols. $@host This metasymbol specifies the host that this message will be forwarded to. If the destination host is the local host, it may be omitted. The host may be a colon-separated list of destination hosts that will be tried in sequence to deliver the message. $:user This metasymbol specifies the target user for the mail message. A rewrite rule that matches is normally tried repeatedly until it fails to match, then parsing moves on to the next rule. This behavior can be changed by preceding the righthand side with one of two special righthand side metaymbols described in the following list. The rewrite rules for a righthand side loop control metasymbols are: $@ This metasymbol causes the ruleset to return with the remainder of the righthand side as the value. No other rules in the ruleset are evaluated. $: This metasymbol causes this rule to terminate immediately, but the rest of the current ruleset is evaluated.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
The domain name component of the FQDN. We can incorporate these macro definitions in our rewrite rules. Our Virtual Brewery configuration uses the $m macro. The Lefthand Side In the lefthand side of a rewriting rule, you specify a pattern that will match an address you wish to transform. Most characters are matched literally, but there are a number of characters that have special meaning; these are described in the following list. The rewrite rules for the lefthand side are: $@ Match exactly zero tokens $* Match zero or more tokens $+ Match one or more tokens $- Match exactly one token $=x Match any phrase in class x $~x Match any word not in class x A token is a string of characters delimited by spaces. There is no way to include spaces in a token, nor is it necessary, as the expression patterns are flexible enough to work around this need. When a rule matches an address, the text matched by each of the patterns in the expression will be assigned to special variables that we’ll use in the righthand side. The only exception to this is the $@, which matches no tokens and therefore will never generate text to be used on the righthand side. The Righthand Side When the lefthand side of a rewrite rule matches an address, the original text is deleted and replaced by the righthand side of the rule. All tokens in the righthand side are copied literally, unless they begin with a dollar sign. Just as for the lefthand side, a number of metasymbols may be used on the righthand side. These are described in the following list. The rewrite rules for the righthand side are: $n This metasymbol is replaced with the n’th expression from the lefthand side. $[name$]
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Linux Network Administrators Guide Prev Chapter 18. Sendmail Next Interpreting and Writing Rewrite Rules Arguably the most powerful feature of sendmail is the rewrite rule. Rewrite rules are used by sendmail to determine how to process a received mail message. sendmail passes the addresses from the headers of a mail message through collections of rewrite rules called rulesets The rewrite rules transform a mail address from one form to another and you can think of them as being similar to a command in your editor that replaces all text matching a specified pattern with another. Each rule has a lefthand side and a righthand side, separated by at least one tab character. When sendmail is processing mail it scans through the rewriting rules looking for a match on the lefthand side. If an address matches the lefthand side of a rewrite rule, the address is replaced by the righthand side and processed again. sendmail.cf R and S Commands In the sendmail.cf file, the rulesets are defined using commands coded as Sn, where n specifies the ruleset that is considered the current one. The rules themselves appear in commands coded as R. As each R command is read, it is added to the current ruleset. If you’re dealing only with the sendmail.mc file, you won’t need to worry about S commands at all, as the macros will build those for you. You will need to manually code your R rules. A sendmail ruleset therefore looks like: Sn Rlhs rhs Rlhs2 rhs2 Some Useful Macro Definitions sendmail uses a number of standard macro definitions internally. The most useful of these in writing rulesets are: $j The fully qualified domain name of this host. $w The hostname component of the FQDN. $m
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
Linux Network Administrators Guide Prev Chapter 18. Sendmail Next Generating the sendmail.cf File When you have completed editing your m4 configuration file, you must process it to produce the /etc/mail/sendmail.cf file read by sendmail. This is straightforward, as illustrated by the following example: # cd /etc/mail # m4 /usr/share/sendmail.cf/m4/cf.m4 vstout.uucpsmtp.mc >sendmail.cf This command invokes the m4 macro processor, supplying it the name of two macro definition files to process. m4 processes the files in the order given. The first file is a standard sendmail macro template supplied with the sendmail source package, the second, of course, is the file containing our own macro definitions. The output of the command is directed to the /etc/mail/sendmail.cf file, which is our target file. You may now start sendmail with the new configuration. Prev Home Next The sendmail.cf and sendmail.mc Files Up Interpreting and Writing Rewrite Rules
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
This mailer allows you to send mail messages directly into Usenet style news networks. Any local message directed to an address of news.group.usenet will be fed into the news network for the news.group newsgroup. fax If you have the HylaFAX software installed, this mailer will allow you to direct email to it so that you may build an email-fax gateway. This feature is experimental at the time of writing and more information may be obtained from http://www.vix.com/hylafax/. There are others, such as the pop, procmail, mail11, phquery, and cyrus that are useful, but less common. If your curiosity is piqued, you can read about these in the sendmail book or the documentation supplied in the source package. Configure mail routing for local hosts The Virtual Brewery’s configuration is probably more complex than most sites require. Most sites today would use the SMTP transport only and do not have to deal with UUCP at all. In our configuration we’ve configured a smart host that is used to handle all outgoing mail. Since we are using the SMTP transport on our local network we must tell sendmail that it is not to send local mail via the smart host. The LOCAL_NET_CONFIG macro allows you to insert sendmail rules directly into the output sendmail.cf to modify the way that local mail is handled. We’ll talk more about rewrite rules later on, but for the moment you should accept that the rule we’ve supplied in our example specifies that any mail destined for hosts in the vbrew.com domain should be delivered directly to the target hosts using the SMTP mail transport. Prev Home Next Overview of Configuration Files Up Generating the sendmail.cf File
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
where name is substituted with the feature name. Some features take one optional parameter. If you wish to use something other than the default, you should use an entry that looks like: FEATURE(name, param) where param is the parameter to supply. Local macro definitions The standard sendmail macro configuration files provide lots of hooks and variables with which you can customize your configuration. These are called local macro definitions. Many of them are listed in the CF file in the sendmail source package. The local macro definitions are usually invoked by supplying the name of the macro with an argument representing the value you wish to assign to the variable the macro manages. Again, we’ll explore some of the more common local macro definitions in the examples we present later in the chapter. Defining mail transport protocols If you want sendmail to transport mail in any way other than by local delivery, you must tell it which transports to use. The MAILER macro makes this very easy. The current version of sendmail supports a variety of mail transport protocols; some of these are experimental, others are probably rarely used. In our network we need the SMTP transport to send and receive mail among the hosts on our local area network, and the UUCP transport to send and receive mail from our smart host. To achieve this, we simply include both the smtp and uucp mail transports. The local mail transport is included by default, but may be defined for clarity, if you wish. If you are including both the smtp and the uucp mailers in your configuration, you must always be sure to define the smtp mailer first. The more commonly used transports available to you using the MAILER macro are described in the following list: local This transport includes both the local delivery agent used to send mail into the mailbox of users on this machine and the prog mailer used to send messages to local programs. This transport is included by default. smtp This transport implements the Simple Mail Transport Protocol (SMTP), which is the most common means of transporting mail on the Internet. When you include this transport, four mailers are configured: smtp (basic SMTP), esmtp (Extended SMTP), smtp8 (8bit binary clean SMTP), and relay (specifically designed for gatewaying messages between hosts). uucp The uucp transport provides support for two mailers: uucp-old, which is the traditional UUCP, and uucp-new, which allows multiple recipients to be handled in one transfer. usenet
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
include: OSTYPE(`linux’) This is probably the most important definition. The OSTYPE macro causes a file of definitions to be included that are good defaults for your operating system. Most of the definitions in an OSTYPE macro file set the pathnames of various configuration files, mailer program paths and arguments, and the location of directories sendmail uses to store messages. The standard sendmail source code release includes such a file for Linux, which would be included by the previous example. Some Linux distributions, notably the Debian distribution, include their own definition file that is completely Linux-FHS compliant. When your distribution does this, you should probably use its definition instead of the Linux default one. The OSTYPE definition should be one of the first definitions to appear in your sendmail.mc file, as many other definitions depend upon it. DOMAIN The DOMAIN macro is useful when you wish to configure a large number of machines on the same network in a standard way. It you’re configuring a small number of hosts, it probably isn’t worth bothering with. You typically configure items, such as the name of mail relay hosts or hubs that all hosts on your network will use. The standard installation contains a directory of m4 macro templates used to drive the configuration process. This directory is usually named /usr/share/sendmail.cf or something similar. Here you will find a subdirectory called domain that contains domain-specific configuration templates. To make use of the DOMAIN macro, you must create your own macro file containing the standard definitions you require for your site, and write it into the domain subdirectory. You’d normally include only the macro definitions that were unique to your domain here, such as smart host definitions or relay hosts, but you are not limited to these. The sendmail source distribution comes with a number of sample domain macro files that you can use to model your own. If you saved your domain macro file as /usr/share/sendmail.cf/domain/vbrew.m4, you’d include definitions in your sendmail.mc using: DOMAIN(`vbrew’) FEATURE The FEATURE macro enables you to include predefined sendmail features in your configuration. These sendmail features make the supported configurations very simple to use. There are a large number, and throughout this chapter we’ll talk about only a few of the more useful and important ones. You can find full details of the features available in the CF file included in the source package. To use any of the features listed, you should include a line in your sendmail.mc that looks like: FEATURE(name)
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
# end If you compare and contrast the two configurations, you might be able to work out what each of the configuration parameters does. We’ll explain them all in detail. Typically Used sendmail.mc Parameters A few of the items in the sendmail.mc file are required all the time; others can be ignored if you can get away with defaults. The general sequence of the definitions in the sendmail.mc is as follows: 1. VERSIONID 2. OSTYPE 3. DOMAIN 4. FEATURE 5. Local macro definitions 6. MAILER 7. LOCAL_* rulesets We’ll talk about each of these in turn in the following sections and refer to our examples in Example 18-1 and Example 18-2, when appropriate, to explain them. Comments Lines in the sendmail.mc file that begin with the # character are not parsed by m4, and will by default be output directly into the sendmail.cf file. This is useful if you want to comment on what your configuration is doing in both the input and output files. To allow comments in your sendmail.mc that are not placed into the sendmail.cf, you can use the m4 divert and dnl tokens. divert(-1) will cause all output to cease. divert(0) will cause output to be restored to the default. Any output generated by lines between these will be discarded. In our example, we’ve used this mechanism to provide a comment that appears only in the sendmail.mc file. To achieve the same result for a single line, you can use the dnl token that means, literally, starting at the beginning of the next line, delete all characters up to and including the next newline. We’ve used this in our example, too. These are standard m4 features, and you can obtain more information on them from its manual page. VERSIONID and OSTYPE VERSIONID(`@(#)sendmail.mc 8.9 (Linux) 01/10/98′) The VERSIONID macro is optional, but is useful to record the version of the sendmail configuration in the sendmail.cf file. So you’ll often encounter it, and we recommend it. In any case, be sure to
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
divert(-1) # # Sample configuration file for vstout - smtp only # divert(0) VERSIONID(`@(#)sendmail.mc 8.7 (Linux) 3/5/96′) OSTYPE(`linux’) # # Include support for the local and smtp mail transport protocols. MAILER(`local’) MAILER(`smtp’) # FEATURE(rbl) FEATURE(access_db) # end A sendmail.mc file for vstout at the Virtual Brewery is shown in Example 18-2. vstout uses SMTP to talk to all hosts on the Brewery’s LAN, and you’ll see the commonality with the generic SMTP-only configuration just presented. In addition, the vstout configuration sends all mail for other destinations to moria, its Internet relay host, via UUCP. Example 18-2. Sample Configuration File vstout.uucpsmtp.m4 divert(-1) # # Sample configuration file for vstout # divert(0) VERSIONID(`@(#)sendmail.mc 8.7 (Linux) 3/5/96′) OSTYPE(`linux’) dnl # moria is our smart host, using the “uucp-new” transport. define(`SMART_HOST’, `uucp-new:moria’) dnl # Support the local, smtp and uucp mail transport protocols. MAILER(`local’) MAILER(`smtp’) MAILER(`uucp’) LOCAL_NET_CONFIG # This rule ensures that all local mail is delivered using the # smtp transport, everything else will go via the smart host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3 dnl # FEATURE(rbl) FEATURE(access_db)
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Linux Network Administrators Guide Prev Chapter 18. Sendmail Next The sendmail.cf and sendmail.mc Files The m4 macro processor program generates the sendmail.df file when it processes the macro configuration file provided by the local system administrator. Throughout the remainder of this chapter we will refer to this configuration file as the sendmail.mc file. The configuration process is basically a matter of creating a suitable sendmail.mc file that includes macros that describe your desired configuration. The macros are expressions that the m4 macro processor understands and expands into the complex sendmail.cf syntax. The macro expressions are made up of the macro name (the text in capital letters at the start), which can be likened to a function in a programming language, and some parameters (the text within brackets) that are used in the expansion. The parameters may be passed literally into the sendmail.cf output or may be used to govern the way the macro processing occurs. A sendmail.mc file for a minimal configuration (UUCP or SMTP with all nonlocal mail being relayed to a directly connected smart host) can be as short as 10 or 15 lines, excluding comments. Two Example sendmail.mc Files If you’re an administator of a number of different mail hosts, you might not want to name your configuration file sendmail.mc. Instead, it is common practice to name it after the host vstout.m4 in our case. The name doesn’t really matter as long as the output is called sendmail.cf. Providing a unique name for the configuration file for each host allows you to keep all configuration files in the same directory and is just an administrative convenience. Let’s look at two example macro configuration files so we know where we are heading. Most sendmail configurations today use SMTP only. It is very simple to configure sendmail for SMTP. Example 18-1 expects a DNS name server to be available to resolve hosts and will attempt to accept and deliver all mail for hosts using just SMTP. Example 18-1. Sample Configuration File vstout.smtp.m4
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services