converting.sun.configs

早期freebsd实现

		     Converting Standard Sun Config
		      Files to Sendmail Version 8

			      Rick McCarty
			 Texas Instruments Inc.
		     Latest Update: 08/25/93 - RJMc

This document details the changes necessary to continue using your
current SunOS sendmail.cf with sendmail version 8.  In the longer term,
it is recommended that one move to using an m4 based configuration such
as those shipped with sendmail, but if you're like me and have made
enough modifications to your .cf file that you'd rather put that task
off until later, here's the sum total of my experience to get you to
version 8 with minimal pain.  I'll cover .cf as well as build issues.

Some background - as many are surely aware, Sun has some "special"
features in the sendmail they ship ($%x, %y LHS lookup, NIS alias DB
search, etc.).  (Some of those features can be had in alternative forms
in IDA sendmail, but v8 has picked up some IDA capabilities as well as
new ones, making it IMHO a most desirable version to go to.)  What I
will explain below includes v8 functional "equivalences" to these Sun
sendmail features.

So with that out of the way, let's begin.

First, some assumptions:

	1) I'm going to assume you've got sendmail version 8.6 or
	   later in hand - if not, grab it from ftp.cs.berkeley.edu
	   in the ucb/sendmail directory.  There are bugs in earlier
	   versions which affect some of the needed functionality.

	2) Second, I'm going to detail this based upon the
	   "sendmail.main.cf" configuration.  (BTW, if you attempt
	   to move to using an m4 generated config in the future,
	   MAIL_HUB is the feature which should provide similar
	   functionality).

	   In general, the changes will be similar for a subsidiary
	   file, but since we (my TI group) funnel all non-local mail
	   through our mailhost, we're not as interested in getting v8
	   to run on such systems and I haven't tried it.

	3) You're using DNS and sendmail.mx.  If you're not, you ought
	   to be, even if you're also running it along with NIS (which
	   we do - except for gethostbyxxx() lookups, which I'll be
	   talking about later).  I would imagine you could get things
	   running OK without DNS support, but I haven't tried it myself.

	4) You're not mounting /var/spool/mail from other systems.
	   I haven't found a v8 feature to guarantee this will work
	   correctly.  Anyway, in the past, we've tried doing that
	   here and found it to be a rather "ugly" feature, though
	   Sun ostensibly supports it ("R" option).  Perhaps v8
	   will one day have a similar feature, but for now, bottom
	   line, I would recommend against it.

	5) You're not on Solaris or using NIS+.  I'm on 4.1.3.  I've
	   looked at Solaris briefly and have noted that things are
	   pretty much similar there except that they've moved some
	   things into the /etc/mail directory.  I'd guess the
	   executables aren't functionally all that different from
	   what they had before - the configs are roughly the same.
	   So I'd bet most of what I say in here will apply to
	   Solaris.

OK, let's configure our sendmail.cf!  I'll just go from the top down...

			  VARIOUS DECLARATIONS

1) For v8, you need to define your .cf as AT LEAST a version level 4
   configuration.  Add the following line:

	V4

   There are some issues regarding certain predefined macros - $w, $j, and
   $m.  With a V4 configuration:

	$w is defined to be the hostname, which will usually be fully
	qualified (i.e. "firefly.add.itg.ti.com").

	$j should have the same value as $w.

	$m will be predefined as the domain portion of $w
	(ex. "add.itg.ti.com").

   One note about this - if your configuration relies on the "w" macro to
   be the "simple" hostname (as mine does)...

   If the configuration version is 5 or larger:

	$w is supposed to be the "simple" name (ex. "firefly")

	$j should be the fully qualified name (i.e. "firefly.add.itg.ti.com")

	$m will be predefined as the domain portion of $j
	(ex. "add.itg.ti.com").

   I have not experimented with the various combinations, so I cannot
   guarantee you that the above definitions will always come out as
   expected.  Bottom line:  if your sendmail.cf depends on $w being the
   simple hostname, test it carefully or define the name explicitly,
   for example:

	Dwfirefly

2) To replace the Sun's "%y" feature, we must use a hostname mapping
   feature in v8.  If you want to do similar lookups with v8, you need
   to define the following map (we'll go over the rules that use this
   map later):

	Khostlookup host -f -m -a.

   This will define a "lookup only" map that is otherwise the same as
   sendmail version 8's built-in "host" map (see the "Sendmail
   Installation and Operation Guide" for details on this map.).

   An important note:  Whether or not these lookups will be done via
   NIS is a function of what gethostbyxxx() functions you link into
   your sendmail.  DO NOT redefine your host mapping to use NIS
   explicitly within sendmail - there can be unexpected behaviour if
   you do so (if you do any canonicalization in your .cf, you can get
   incorrect results, for one thing).

   For example, DO NOT TRY:

	Khost nis -f -a. hosts.byname

3) If you're doing reverse alias mapping as done in ruleset 22, instead of:

	DZmail.byaddr

   you'll need to declare the following:

	Kaliasrev nis -f -N mail.byaddr

4) If you are doing any other NIS map lookups, you'll need to define the
   map as done in the below example.  I have a "mailhosts" map, which I
   use to distinguish between local and non-local hosts.  Look at the
   sendmail doc for details on this stuff.

	Kmailhosts nis -f -m -a. mailhosts 

5) You might wish to add the following line to support Errors-To: headers.
   I don't.

	Ol

6) Comment out/remove the following line:

	OR

   The R option means something different under v8 - check the documentation
   if you're interested in using it.

7) If you're running NIS and have a separate alias map, BELOW the
   following line where the alias file is declared:

	OA/etc/aliases

   ADD the following:

	OAnis:mail.aliases

   This will set things up so v8 will look at the local alias DB first,
   then the NIS map, just as Sun sendmail does.

8) Though you don't have to, I'd suggest changing:

	OT3d

   to use v8's warning feature, which allows a warning message to be
   sent if a message cannot be delivered within a specified period.
   I use:

	OT5d/4h

   which says - bounce after 5 days, warn after 4 hours.

9) I set the following option to be explicit about how I want DNS
    handled:

	OI +DNSRCH +DEFNAMES

10) The following line:

	T root daemon uucp

    may be deleted, though it will be ignored if you leave it around.

11) It would probably be good to change the version macro value (which
    shows up in "Received:" headers) so no one debugging mail problems
    gets the wrong idea about what config you're running under.  Look
    for something like:

	DVSMI-4.1

    Mine, for example is:

	DVADD-HUB-2.1

				RULESETS

1)  In ruleset 3, BELOW this rule:

	# basic textual canonicalization
	R$*<$+>$*		$2			basic RFC822 parsing


I add the following rule to remove a trailing dot in the domain spec so
it won't interfere with v8 mapping features, etc.  (Having a trailing dot is
not RFC-compliant anyway.):

	R$+.			$1

2) Because ruleset 5 is special in v8, I rename it to S95 and also change
   all RHS expressions containing ">5" to use ">95" instead.  In v8,
   5 is executed against addresses which resolve to the local mailer and
   are not an alias.  If you don't change S5 to something else, you might
   get a surprise!

3) If you're doing any lookups via the generalized NIS "$%x/$!x"
   mechanisms (such as with the mailhost map I referred to earlier) it's