converting.sun.configs

早期freebsd实现

   done differently under v8.  For example:

	DMmailhosts
	...
	R$*<@$%M.uucp>$*	$#ether $@$2 $:$1<@$2>$3

   takes a different map definition and two rules under version 8:

	Kmailhosts nis -f -m -a. mailhosts
	...
	R$*<@$+.uucp>$*		$: $1<@$(mailhosts $2 $).uucp>$3
	R$*<@$+..uucp>$*	$#ether $@$2 $:$1<@$2>$3

4) Sun has a special case of the "$%x" feature for host lookups - "%y" is
   automagically defined to do an NIS "hosts.byname" search with no other
   definition, as done in the below example:

	R$*<@$%y.LOCAL>$*	$#ether $@$2 $:$1<@$2>$3

   (Sun does this in more than one place.  But the above syntax is almost
    identical in each - mostly a case of changing names to protect the
    innocent.)

   In version 8, the predefined "host" map can be used to do essentially
   the same thing.  (However, whether or not it does an NIS lookup is
   a function of what gethostbyxxx() functions are linked in.)

   Recall the map definition I mentioned earlier in the DECLARATIONS
   section:

	Khostlookup host -f -m -a.

   Here's where we will use it.  It will take two rules:

	R$*<@$+.LOCAL>$*	$: $1<@$(hostlookup $2 $).LOCAL>$3
	R$*<@$+..LOCAL>$*	$#ether $@$2 $:$1<@$2>$3

   Note that this is almost verbatim the same change as was used in the
   previous "mailhosts" example.

5) Although Sun's default configs don't do this, because I mentioned
   canonicalization earlier, it deserves an example, as it's illustrative
   of the functional difference in the map definitions I discussed before.
   This stuff is also convered in the "Sendmail Installation and Operation
   Guide".

   Remember the built-in "host" map definition?  As you'll recall, unlike
   the "hostlookup" map we defined, "host" will actually CHANGE the
   hostname in addition to appending a dot.  "hostlookup" only appends a
   dot if the name is found and doesn't change it otherwise.  Anyway,
   here's the example:

	R$*<@$+>$*	$: $1<@$(host $2 $)>$3		canonicalize
	R$*<@$+.>$*	$1<@$2>$3			remove trailing dot

   Using the above, say you had input of:

	joe<@tilde>

	OR

	joe<@[128.247.160.56]>

	Assuming "tilde" or the IP address is found, it might be
        canonicalized as:

	joe<@tilde.csc.ti.com>

6) As another instance of the NIS lookup feature, with a slightly
   different twist, Sun implements reverse alias mapping in ruleset 22
   with the below:

	DZmail.byaddr
	...
	R$-<@$->		$:$>3${Z$1@$2$}			invert aliases

   To use this feature under v8, change the above rule a (remember to
   define the alias map as I showed earlier):

	R$-<@$->		$:$>3$(aliasrev $1@$2 $)	invert aliases


			   MAILER DEFINITIONS

1) Where "TCP" is defined in the "P=" and "A=" parameters of mailers, I
   changed it to "IPC".  Version 8 will accept "TCP", but "IPC" is
   preferred.

2) On all IPC mailers, I also defined "E=\r\n" and added an "L=1000" as
   in the below example:

	Mether,	P=[IPC], F=mDFMuCX, S=11, R=21, L=1000, E=\r\n, A=IPC $h

   The "E=\r\n" will save you headaches interoperating with such things as
   VMS TCP products.

   The "L=1000" is for RFC821 compatibility.  Not strictly necessary.

   I also removed the "s" (strip quotes) mailer flag Sun puts in for
   these mailers.  Stripping quotes violates protocols, which say
   clearly that you can't touch the local-part (left hand side of
   the @) until you are on the delivering host.

NOW.  If I haven't left anything out, you should be able to run through
your Sun sendmail.cf file and convert it to run under v8.

			      BUILD ISSUES

Some important notes on building v8 on SunOS:

Makefile

The default makefile in the version 8 source (src) directory assumes the
new Berkeley make.  Unless you want to go to the trouble of building it,
you can use your regular make, but you need to use a different makefile.
You can use "Makefile.dist" or "Makefile.SunOS" in the src directory.  I
made changes to get it to build so it is as compatible as possible with
the file/directory locations Sun uses.  Here are some relevant sections
out of my makefile:

	CC=gcc

	# use O=-O (usual) or O=-g (debugging)
	O=	-O

	# define the database mechanisms available for map & alias lookups:
	#	-DNDBM -- use new DBM
	#	-DNEWDB -- use new Berkeley DB
	#	-DNDBM -DNEWDB -DYPCOMPAT -- use both plus YP compatility
	#	-DNIS -- include client NIS support
	# The really old (V7) DBM library is no longer supported.
	# See READ_ME for a description of how these flags interact.
	#DBMDEF= -DNDBM -DNEWDB
	DBMDEF=	-DNDBM -DNIS

	# environment definitions (e.g., -D_AIX3)
	ENVDEF=

	# see also conf.h for additional compilation flags

	# library directories
	LIBDIRS=-L/usr/local/lib

	# libraries required on your system
	#LIBS=	-ldb -ldbm
	LIBS=	-ldbm -lresolv

	# location of sendmail binary (usually /usr/sbin or /usr/lib)
	BINDIR=	${DESTDIR}/usr/lib

	# location of sendmail.st file (usually /var/log or /usr/lib)
	STDIR=	${DESTDIR}/etc

	# location of sendmail.hf file (usually /usr/share/misc or /usr/lib)
	HFDIR=	${DESTDIR}/usr/lib

For the resolver library, you can use the one shipped with Sun if you
want.  But I'd recommend using another version of the resolver library
(such as the one with Bind 4.8.3 or 4.9).  Sun's resolver stuff (at
least with 4.1.x) is quite old - I believe it is of 4.3.1 vintage.  (Do
you get the impression I don't TRUST what Sun ships with their systems?)

If you want NIS host lookup while maintaining DNS capability, you might
take a look at resolv+, which has NIS capable gethostbyxxx() functions
in it.  My recommendation, however, is to avoid doing NIS host lookups
in sendmail altogether, and to use a "pure" version of the resolver
library.

There are probably no situations (at least I think so) where it makes
any sense to link in Sun's NIS gethostbyxxx() functions from libc.
You could, I guess do it (I haven't tried it) and wind up with a
sendmail equivalent to the non-mx version Sun ships.  You'd need to
insure that NAMED_BIND is not defined in the build.  (If you do
this and have the "-b" DNS passthru option set in NIS, remember that
while you have some DNS functionality you'll not have any MX support.
(This, IMO, is what makes this a non-optimal choice.)

		      INSTALLATION/TESTING ISSUES

The sendmail.hf file in the src directory should replace the one currently
in /usr/lib.  You also might choose to edit it a bit to "localize" what it
says.

The sendmail executable goes, of course, in /usr/lib in place of the current
one.  What I did was create a subdirectory in /usr/lib and put all of the
Sun sendmail stuff in there.  I named the v8 sendmail executable to be
sendmail.v8.mx and then symbolically linked it to sendmail.

One other thing.  If you use address test mode, keep in mind that
Version 8 is like IDA in that it does not automatically execute ruleset
3 first.  So say you're playing around with things testing addresses and
you're used to things like:

	0 [e-mail]

under v8 you need to say instead:

	3,0 [e-mail]

	      INTEROPERABILITY ISSUES YOU MIGHT ENCOUNTER

Be aware that sendmail v8 issues a multi-line SMTP welcome (220)
response upon a client connection.  Most systems in your network should
handle it OK, but there are some that choke on it, because whoever wrote
the clients assumed only a single line.  THIS IS NOT SENDMAIL's FAULT.
A multi-line 220 response is perfectly valid.  A likely place you'll
encounter this problem is with non-Un*x SMTP clients.  If you do run
into it, you should report it to the vendor.

A final note about version 8 - if you follow the above configuration
scenario, you'll notice it doesn't like to get envelope sender
addresses it doesn't know how to get back to.  Sun sendmail would take
anything, even though it might not be able to bounce the message back
should something happen downstream.  So if another sendmail on a host
that's not locally known is trying to pump mail through your v8 host,
the ENVELOPE sender it gives had better be fully qualified.  This is
a GREAT thing, because it helps clear up problems we've had with not
being able to get things back to the sender, resulting in an
overburdened postmaster.

I hope this helps those running Sun sendmail feel more at ease with moving
on to v8.  It's really worth going to.