readme

< linux网络编程工具>>配套源码

		   [default: procmail -Y -a $h -d $u]
		3. Flags for the mailer [default: SPfhn9]

		Empty arguments cause the defaults to be taken.

		For example, this allows it to use the maildrop
		(http://www.flounder.net/~mrsam/maildrop/) mailer instead
		by specifying:

		FEATURE(`local_procmail', `/usr/local/bin/maildrop',
		 `maildrop -d $u')

		or scanmails using:

		FEATURE(`local_procmail', `/usr/local/bin/scanmails')

		WARNING: This feature sets LOCAL_MAILER_FLAGS unconditionally,
		i.e.,  without respecting any definitions in an OSTYPE setting.

bestmx_is_local	Accept mail as though locally addressed for any host that
		lists us as the best possible MX record.  This generates
		additional DNS traffic, but should be OK for low to
		medium traffic hosts.  The argument may be a set of
		domains, which will limit the feature to only apply to
		these domains -- this will reduce unnecessary DNS
		traffic.  THIS FEATURE IS FUNDAMENTALLY INCOMPATIBLE WITH
		WILDCARD MX RECORDS!!!  If you have a wildcard MX record
		that matches your domain, you cannot use this feature.

smrsh		Use the SendMail Restricted SHell (smrsh) provided
		with the distribution instead of /bin/sh for mailing
		to programs.  This improves the ability of the local
		system administrator to control what gets run via
		e-mail.  If an argument is provided it is used as the
		pathname to smrsh; otherwise, the path defined by
		confEBINDIR is used for the smrsh binary -- by default,
		/usr/libexec/smrsh is assumed.

promiscuous_relay
		By default, the sendmail configuration files do not permit
		mail relaying (that is, accepting mail from outside your
		local host (class {w}) and sending it to another host than
		your local host).  This option sets your site to allow
		mail relaying from any site to any site.  In almost all
		cases, it is better to control relaying more carefully
		with the access map, class {R}, or authentication.  Domains
		can be added to class {R} by the macros RELAY_DOMAIN or
		RELAY_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
		MASQUERADE_DOMAIN_FILE, see below).

relay_entire_domain
		By default, only hosts listed as RELAY in the access db
		will be allowed to relay.  This option also allows any
		host in your domain as defined by class {m}.

relay_hosts_only
		By default, names that are listed as RELAY in the access
		db and class {R} are domain names, not host names.
		For example, if you specify ``foo.com'', then mail to or
		from foo.com, abc.foo.com, or a.very.deep.domain.foo.com
		will all be accepted for relaying.  This feature changes
		the behaviour to lookup individual host names only.

relay_based_on_MX
		Turns on the ability to allow relaying based on the MX
		records of the host portion of an incoming recipient; that
		is, if an MX record for host foo.com points to your site,
		you will accept and relay mail addressed to foo.com.  See
		description below for more information before using this
		feature.  Also, see the KNOWNBUGS entry regarding bestmx
		map lookups.

		FEATURE(`relay_based_on_MX') does not necessarily allow
		routing of these messages which you expect to be allowed,
		if route address syntax (or %-hack syntax) is used.  If
		this is a problem, add entries to the access-table or use
		FEATURE(`loose_relay_check').

relay_mail_from
		Allows relaying if the mail sender is listed as RELAY in
		the access map.  If an optional argument `domain' is given,
		the domain portion of the mail sender is checked too.
		This should only be used if absolutely necessary as the
		sender address can be easily forged.  Use of this feature
		requires the "From:" tag be prepended to the key in the
		access map; see the discussion of tags and
		FEATURE(`relay_mail_from') in the section on ANTI-SPAM
		CONFIGURATION CONTROL.

relay_local_from
		Allows relaying if the domain portion of the mail sender
		is a local host.  This should only be used if absolutely
		necessary as it opens a window for spammers.  Specifically,
		they can send mail to your mail server that claims to be
		from your domain (either directly or via a routed address),
		and you will go ahead and relay it out to arbitrary hosts
		on the Internet.

accept_unqualified_senders
		Normally, MAIL FROM: commands in the SMTP session will be
		refused if the connection is a network connection and the
		sender address does not include a domain name.  If your
		setup sends local mail unqualified (i.e., MAIL FROM: <joe>),
		you will need to use this feature to accept unqualified
		sender addresses.  Setting the DaemonPortOptions modifier
		'u' overrides the default behavior, i.e., unqualified
		addresses are accepted even without this FEATURE.
		If this FEATURE is not used, the DaemonPortOptions modifier
		'f' can be used to enforce fully qualified addresses.

accept_unresolvable_domains
		Normally, MAIL FROM: commands in the SMTP session will be
		refused if the host part of the argument to MAIL FROM:
		cannot be located in the host name service (e.g., an A or
		MX record in DNS).  If you are inside a firewall that has
		only a limited view of the Internet host name space, this
		could cause problems.  In this case you probably want to
		use this feature to accept all domains on input, even if
		they are unresolvable.

access_db	Turns on the access database feature.  The access db gives
		you the ability to allow or refuse to accept mail from
		specified domains for administrative reasons.  By default,
		the access database specification is:

			hash /etc/mail/access

		The format of the database is described in the anti-spam
		configuration control section later in this document.

blacklist_recipients
		Turns on the ability to block incoming mail for certain
		recipient usernames, hostnames, or addresses.  For
		example, you can block incoming mail to user nobody,
		host foo.mydomain.com, or [e-mail].
		These specifications are put in the access db as
		described in the anti-spam configuration control section
		later in this document.

rbl		This feature is deprecated! Please use dnsbl instead.
		Turns on rejection of hosts found in the Realtime Blackhole
		List.  If an argument is provided it is used as the domain
		in which blocked hosts are listed; otherwise, the main
		RBL domain rbl.maps.vix.com is used.  For details, see
		http://maps.vix.com/rbl/.

dnsbl		Turns on rejection of hosts found in an DNS based rejection
		list.  If an argument is provided it is used as the domain
		in which blocked hosts are listed; otherwise it defaults to
		rbl.maps.vix.com.  An explanation for an DNS based rejection
		list can be found http://maps.vix.com/rbl/.  A second argument
		can be used to change the default error message of
		Mail from $&{client_addr} refused by blackhole site SERVER
		where SERVER is replaced by the first argument.  This feature
		can be included several times to query different DNS based
		rejection lists.

loose_relay_check
		Normally, if % addressing is used for a recipient, e.g.
		user%site@othersite, and othersite is in class {R}, the
		check_rcpt ruleset will strip @othersite and recheck
		user@site for relaying.  This feature changes that
		behavior.  It should not be needed for most installations.

no_default_msa	Don't generate the default MSA daemon, i.e.,
		DAEMON_OPTIONS(`Port=587,Name=MSA,M=E')
		To define a MSA daemon with other parameters, use this
		FEATURE and introduce new settings via DAEMON_OPTIONS().

+-------+
| HACKS |
+-------+

Some things just can't be called features.  To make this clear,
they go in the hack subdirectory and are referenced using the HACK
macro.  These will tend to be site-dependent.  The release
includes the Berkeley-dependent "cssubdomain" hack (that makes
sendmail accept local names in either Berkeley.EDU or CS.Berkeley.EDU;
this is intended as a short-term aid while moving hosts into
subdomains.


+--------------------+
| SITE CONFIGURATION |
+--------------------+

    *****************************************************
    * This section is really obsolete, and is preserved	*
    * only for back compatibility.  You should plan on	*
    * using mailertables for new installations.	  In	*
    * particular, it doesn't work for the newer forms	*
    * of UUCP mailers, such as uucp-uudom.		*
    *****************************************************

Complex sites will need more local configuration information, such as
lists of UUCP hosts they speak with directly.  This can get a bit more
tricky.  For an example of a "complex" site, see cf/ucbvax.mc.

The SITECONFIG macro allows you to indirectly reference site-dependent
configuration information stored in the siteconfig subdirectory.  For
example, the line

	SITECONFIG(`uucp.ucbvax', `ucbvax', `U')

reads the file uucp.ucbvax for local connection information.  The
second parameter is the local name (in this case just "ucbvax" since
it is locally connected, and hence a UUCP hostname).  The third
parameter is the name of both a macro to store the local name (in
this case, {U}) and the name of the class (e.g., {U}) in which to store
the host information read from the file.  Another SITECONFIG line reads

	SITECONFIG(`uucp.ucbarpa', `ucbarpa.Berkeley.EDU', `W')

This says that the file uucp.ucbarpa contains the list of UUCP sites
connected to ucbarpa.Berkeley.EDU.  Class {W} will be used to
store this list, and $W is defined to be ucbarpa.Berkeley.EDU, that
is, the name of the relay to which the hosts listed in uucp.ucbarpa
are connected.  [The machine ucbarpa is gone now, but this
out-of-date configuration file has been left around to demonstrate
how you might do this.]

Note that the case of SITECONFIG with a third parameter of ``U'' is
special; the second parameter is assumed to be the UUCP name of the
local site, rather than the name of a remote site, and the UUCP name
is entered into class {w} (the list of local hostnames) as $U.UUCP.

The siteconfig file (e.g., siteconfig/uucp.ucbvax.m4) contains nothing
more than a sequence of SITE macros describing connectivity.  For
example:

	SITE(`cnmat')
	SITE(`sgi olympus')

The second example demonstrates that you can use two names on the
same line; these are usually aliases for the same host (or are at
least in the same company).


+--------------------+
| USING UUCP MAILERS |
+--------------------+

It's hard to get UUCP mailers right because of the extremely ad hoc
nature of UUCP addressing.  These config files are really designed
for domain-based addressing, even for UUCP sites.

There are four UUCP mailers available.  The choice of which one to
use is partly a matter of local preferences and what is running at
the other end of your UUCP connection.  Unlike good protocols that
define what will go over the wire, UUCP uses the policy that you
should do what is right for the other end; if they change, you have
to change.  This makes it hard to do the right thing, and discourages
people from updating their software.  In general, if you can avoid
UUCP, please do.

The major choice is whether to go for a domainized scheme or a
non-domainized scheme.  This depends entirely on what the other
end will recognize.  If at all possible, you should encourage the
other end to go to a domain-based system -- non-domainized addresses
don't work entirely properly.

The four mailers are:

    uucp-old (obsolete name: "uucp")
	This is the oldest, the worst (but the closest to UUCP) way of
	sending messages accros UUCP connections.  It does bangify
	everything and prepends $U (your UUCP name) to the sender's
	address (which can already be a bang path itself).  It can
	only send to one address at a time, so it spends a lot of
	time copying duplicates of messages.  Avoid this if at all
	possible.

    uucp-new (obsolete name: "suucp")
	The same as above, except that it assumes that in one rmail
	command you can specify several recipients.  It still has a
	lot of other problems.

    uucp-dom
	This UUCP mailer keeps everything as domain addresses.
	Basically, it uses the SMTP mailer rewriting rules.  This mailer
	is only included if MAILER(`smtp') is also specified.

	Unfortunately, a lot of UUCP mailer transport agents require
	bangified addresses in the envelope, although you can use
	domain-based addresses in the message header.  (The envelope
	shows up as the From_ line on UNIX mail.)  So....

    uucp-uudom
	This is a cross between uucp-new (for the envelope addresses)
	and uucp-dom (for the header addresses).  It bangifies the
	envelope sender (From_ line in messages) without adding the
	local hostname, unless there is no host name on the address
	at all (e.g., "wolf") or the host component is a UUCP host name
	instead of a domain name ("somehost!wolf" instead of
	"some.dom.ain!wolf").  This is also included only if MAILER(`smtp')
	is also specified.

Examples:

On host grasp.insa-lyon.fr (UUCP host name "grasp"), the following
summarizes the sender rewriting for various mailers.

Mailer		sender		rewriting in the envelope
------		------		-------------------------
uucp-{old,new}	wolf		grasp!wolf
uucp-dom	wolf		[e-mail]
uucp-uudom	wolf		grasp.insa-lyon.fr!wolf

uucp-{old,new}	[e-mail]	grasp!fr.net!wolf