readme

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

			that is allowed to relay.
		`nospecial': don't do anything special with "!".
		Warnings: 1. See the NOTICE in the ANTI-SPAM section.
		2. don't remove "!" from OperatorChars if `reject' is
		given as parameter.

nocanonify	Don't pass addresses to $[ ... $] for canonification
		by default.  It can be changed by setting the
		DaemonPortOptions modifiers (M=).  That is,
		FEATURE(`nocanonify') will be overridden by setting the
		'c' flag.  Conversely, if FEATURE(`nocanonify') is not used,
		it can be emulated by setting the 'C' flag
		(DaemonPortOptions=Modifiers=C).  This would generally only
		be used by sites that only act as mail gateways or which have
		user agents that do full canonification themselves.  You may
		also want to use
		"define(`confBIND_OPTS', `-DNSRCH -DEFNAMES')" to turn off
		the usual resolver options that do a similar thing.

		An exception list for FEATURE(`nocanonify') can be
		specified with CANONIFY_DOMAIN or CANONIFY_DOMAIN_FILE,
		i.e., a list of domains which are nevertheless passed to
		$[ ... $] for canonification.  This is useful to turn on
		canonification for local domains, e.g., use
		CANONIFY_DOMAIN(`my.domain my') to canonify addresses
		which end in "my.domain" or "my".
		Another way to require canonification in the local
		domain is CANONIFY_DOMAIN(`$=m').

		A trailing dot is added to addresses with more than
		one component in it such that other features which
		expect a trailing dot (e.g., virtusertable) will
		still work.

		If `canonify_hosts' is specified as parameter, i.e.,
		FEATURE(`nocanonify', `canonify_hosts'), then
		addresses which have only a hostname, e.g.,
		<user@host>, will be canonified (and hopefully fully
		qualified), too.

stickyhost	If set, email sent to "[e-mail]" are marked
		as "sticky" -- that is, the local addresses aren't
		matched against UDB and don't go through ruleset 5.
		This is used if you want a set up where "user" is
		not necessarily the same as "[e-mail]", e.g.,
		to make a distinct domain-wide namespace.  Prior to
		8.7 this was the default, and notsticky was used to
		turn this off.

mailertable	Include a "mailer table" which can be used to override
		routing for particular domains (which are not in class {w},
		i.e.  local host names).  The argument of the FEATURE may be
		the key definition.  If none is specified, the definition
		used is:

			hash /etc/mail/mailertable

		Keys in this database are fully qualified domain names
		or partial domains preceded by a dot -- for example,
		"vangogh.CS.Berkeley.EDU" or ".CS.Berkeley.EDU".  As a
		special case of the latter, "." matches any domain not
		covered by other keys.  Values must be of the form:
			mailer:domain
		where "mailer" is the internal mailer name, and "domain"
		is where to send the message.  These maps are not
		reflected into the message header.  As a special case,
		the forms:
			local:user
		will forward to the indicated user using the local mailer,
			local:
		will forward to the original user in the e-mail address
		using the local mailer, and
			error:code message
			error:D.S.N:code message
		will give an error message with the indicated SMTP reply
		code and message, where D.S.N is an RFC 1893 compliant
		error code.

domaintable	Include a "domain table" which can be used to provide
		domain name mapping.  Use of this should really be
		limited to your own domains.  It may be useful if you
		change names (e.g., your company changes names from
		oldname.com to newname.com).  The argument of the
		FEATURE may be the key definition.  If none is specified,
		the definition used is:

			hash /etc/mail/domaintable

		The key in this table is the domain name; the value is
		the new (fully qualified) domain.  Anything in the
		domaintable is reflected into headers; that is, this
		is done in ruleset 3.

bitdomain	Look up bitnet hosts in a table to try to turn them into
		internet addresses.  The table can be built using the
		bitdomain program contributed by John Gardiner Myers.
		The argument of the FEATURE may be the key definition; if
		none is specified, the definition used is:

			hash /etc/mail/bitdomain

		Keys are the bitnet hostname; values are the corresponding
		internet hostname.

uucpdomain	Similar feature for UUCP hosts.  The default map definition
		is:

			hash /etc/mail/uudomain

		At the moment there is no automagic tool to build this
		database.

always_add_domain
		Include the local host domain even on locally delivered
		mail.  Normally it is not added on unqualified names.
		However, if you use a shared message store but do not use
		the same user name space everywhere, you may need the host
		name on local names.

allmasquerade	If masquerading is enabled (using MASQUERADE_AS), this
		feature will cause recipient addresses to also masquerade
		as being from the masquerade host.  Normally they get
		the local hostname.  Although this may be right for
		ordinary users, it can break local aliases.  For example,
		if you send to "localalias", the originating sendmail will
		find that alias and send to all members, but send the
		message with "To: localalias@masqueradehost".  Since that
		alias likely does not exist, replies will fail.  Use this
		feature ONLY if you can guarantee that the ENTIRE
		namespace on your masquerade host supersets all the
		local entries.

limited_masquerade
		Normally, any hosts listed in class {w} are masqueraded.  If
		this feature is given, only the hosts listed in class {M} (see
		below:  MASQUERADE_DOMAIN) are masqueraded.  This is useful
		if you have several domains with disjoint namespaces hosted
		on the same machine.

masquerade_entire_domain
		If masquerading is enabled (using MASQUERADE_AS) and
		MASQUERADE_DOMAIN (see below) is set, this feature will
		cause addresses to be rewritten such that the masquerading
		domains are actually entire domains to be hidden.  All
		hosts within the masquerading domains will be rewritten
		to the masquerade name (used in MASQUERADE_AS).  For example,
		if you have:

			MASQUERADE_AS(`masq.com')
			MASQUERADE_DOMAIN(`foo.org')
			MASQUERADE_DOMAIN(`bar.com')

		then *foo.org and *bar.com are converted to masq.com.  Without
		this feature, only foo.org and bar.com are masqueraded.

		    NOTE: only domains within your jurisdiction and
		    current hierarchy should be masqueraded using this.

genericstable	This feature will cause unqualified addresses (i.e., without
		a domain) and addresses with a domain listed in class {G}
		to be looked up in a map and turned into another ("generic")
		form, which can change both the domain name and the user name.
		This is similar to the userdb functionality.  The same types of
		addresses as for masquerading are looked up, i.e., only header
		sender addresses unless the allmasquerade and/or
		masquerade_envelope features are given.  Qualified addresses
		must have the domain part in class {G}; entries can
		be added to this class by the macros GENERICS_DOMAIN or
		GENERICS_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
		MASQUERADE_DOMAIN_FILE, see below).

		The argument of FEATURE(`genericstable') may be the map
		definition; the default map definition is:

			hash /etc/mail/genericstable

		The key for this table is either the full address, the domain
		(with a leading @; the localpart is passed as first argument)
		or the unqualified username (tried in the order mentioned);
		the value is the new user address.  If the new user address
		does not include a domain, it will be qualified in the standard
		manner, i.e., using $j or the masquerade name.  Note that the
		address being looked up must be fully qualified.  For local
		mail, it is necessary to use FEATURE(`always_add_domain')
		for the addresses to be qualified.
		The "+detail" of an address is passed as %1, so entries like

			old+*@foo.org	[e-mail]
			gen+*@foo.org	[e-mail]

		and other forms are possible.

generics_entire_domain
		If the genericstable is enabled and GENERICS_DOMAIN or
		GENERICS_DOMAIN_FILE is used, this feature will cause
		addresses to be searched in the map if their domain
		parts are subdomains of elements in class {G}.

virtusertable	A domain-specific form of aliasing, allowing multiple
		virtual domains to be hosted on one machine.  For example,
		if the virtuser table contained:

			[e-mail]	foo-info
			[e-mail]	bar-info
			[e-mail]	error:nouser No such user here
			[e-mail]	error:D.S.N:unavailable Address invalid
			@baz.org	[e-mail]

		then mail addressed to [e-mail] will be sent to the
		address foo-info, mail addressed to [e-mail] will be
		delivered to bar-info, and mail addressed to anyone at baz.org
		will be sent to [e-mail], mail to [e-mail] will
		be rejected with the specified error message, and mail to
		[e-mail] will also have a RFC 1893 compliant error code
		D.S.N.

		The username from the original address is passed
		as %1 allowing:

			@foo.org	[e-mail]

		meaning [e-mail] will be sent to [e-mail].
		Additionally, if the local part consists of "user+detail"
		then "detail" is passed as %2 when a match against user+*
		is attempted, so entries like

			old+*@foo.org	[e-mail]
			gen+*@foo.org	[e-mail]
			+*@foo.org	[e-mail]

		and other forms are possible.  Note: to preserve "+detail"
		for a default case (@domain) +*@domain must be used as
		exemplified above.

		All the host names on the left hand side (foo.com, bar.com,
		and baz.org) must be in class {w} or class {VirtHost}, the
		latter can be defined by the macros VIRTUSER_DOMAIN or
		VIRTUSER_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
		MASQUERADE_DOMAIN_FILE, see below).  If VIRTUSER_DOMAIN or
		VIRTUSER_DOMAIN_FILE is used, then the entries of class
		{VirtHost} are added to class {R}, i.e., relaying is allowed
		to (and from) those domains.  The default map definition is:

			hash /etc/mail/virtusertable

		A new definition can be specified as the second argument of
		the FEATURE macro, such as

			FEATURE(`virtusertable', `dbm /etc/mail/virtusers')

virtuser_entire_domain
		If the virtusertable is enabled and VIRTUSER_DOMAIN or
		VIRTUSER_DOMAIN_FILE is used, this feature will cause
		addresses to be searched in the map if their domain
		parts are subdomains of elements in class {VirtHost}.

ldap_routing	Implement LDAP-based e-mail recipient routing according to
		the Internet Draft draft-lachman-laser-ldap-mail-routing-01.
		This provides a method to re-route addresses with a
		domain portion in class {LDAPRoute} to either a
		different mail host or a different address.  Hosts can
		be added to this class using LDAPROUTE_DOMAIN and
		LDAPROUTE_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
		MASQUERADE_DOMAIN_FILE, see below).

		See the LDAP ROUTING section below for more information.

nodns		If you aren't running DNS at your site (for example,
		you are UUCP-only connected).  It's hard to consider
		this a "feature", but hey, it had to go somewhere.
		Actually, as of 8.7 this is a no-op -- remove "dns" from
		the hosts service switch entry instead.

nullclient	This is a special case -- it creates a configuration file
		containing nothing but support for forwarding all mail to a
		central hub via a local SMTP-based network.  The argument
		is the name of that hub.

		The only other feature that should be used in conjunction
		with this one is FEATURE(`nocanonify').  No mailers
		should be defined.  No aliasing or forwarding is done.

local_lmtp	Use an LMTP capable local mailer.  The argument to this
		feature is the pathname of an LMTP capable mailer.  By
		default, mail.local is used.  This is expected to be the
		mail.local which came with the 8.9 distribution which is
		LMTP capable.  The path to mail.local is set by the
		confEBINDIR m4 variable -- making the default
		LOCAL_MAILER_PATH /usr/libexec/mail.local.
		WARNING: This feature sets LOCAL_MAILER_FLAGS unconditionally,
		i.e., without respecting any definitions in an OSTYPE setting.

local_procmail	Use procmail or another delivery agent as the local mailer.
		The argument to this feature is the pathname of the
		delivery agent, which defaults to PROCMAIL_MAILER_PATH.
		Note that this does NOT use PROCMAIL_MAILER_FLAGS or
		PROCMAIL_MAILER_ARGS for the local mailer; tweak
		LOCAL_MAILER_FLAGS and LOCAL_MAILER_ARGS instead, or
		specify the appropriate parameters.  When procmail is used,
		the local mailer can make use of the
		"[e-mail]" syntax; normally the +indicator
		is just tossed, but by default it is passed as the -a
		argument to procmail.

		This feature can take up to three arguments:

		1. Path to the mailer program
		   [default: /usr/local/bin/procmail]
		2. Argument vector including name of the program