readme

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

uucp-dom	[e-mail]	[e-mail]
uucp-uudom	[e-mail]	fr.net!wolf

uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
uucp-dom	somehost!wolf	somehost![e-mail]
uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf

If you are using one of the domainized UUCP mailers, you really want
to convert all UUCP addresses to domain format -- otherwise, it will
do it for you (and probably not the way you expected).  For example,
if you have the address foo!bar!baz (and you are not sending to foo),
the heuristics will add the @uucp.relay.name or @local.host.name to
this address.  However, if you map foo to foo.host.name first, it
will not add the local hostname.  You can do this using the uucpdomain
feature.


+-------------------+
| TWEAKING RULESETS |
+-------------------+

For more complex configurations, you can define special rules.
The macro LOCAL_RULE_3 introduces rules that are used in canonicalizing
the names.  Any modifications made here are reflected in the header.

A common use is to convert old UUCP addresses to SMTP addresses using
the UUCPSMTP macro.  For example:

	LOCAL_RULE_3
	UUCPSMTP(`decvax',	`decvax.dec.com')
	UUCPSMTP(`research',	`research.att.com')

will cause addresses of the form "decvax!user" and "research!user"
to be converted to "[e-mail]" and "[e-mail]"
respectively.

This could also be used to look up hosts in a database map:

	LOCAL_RULE_3
	R$* < @ $+ > $*		$: $1 < @ $(hostmap $2 $) > $3

This map would be defined in the LOCAL_CONFIG portion, as shown below.

Similarly, LOCAL_RULE_0 can be used to introduce new parsing rules.
For example, new rules are needed to parse hostnames that you accept
via MX records.  For example, you might have:

	LOCAL_RULE_0
	R$+ <@ host.dom.ain.>	$#uucp $@ cnmat $: $1 < @ host.dom.ain.>

You would use this if you had installed an MX record for cnmat.Berkeley.EDU
pointing at this host; this rule catches the message and forwards it on
using UUCP.

You can also tweak rulesets 1 and 2 using LOCAL_RULE_1 and LOCAL_RULE_2.
These rulesets are normally empty.

A similar macro is LOCAL_CONFIG.  This introduces lines added after the
boilerplate option setting but before rulesets.  Do not declare rulesets in
the LOCAL_CONFIG section.  It can be used to declare local database maps or
whatever.  For example:

	LOCAL_CONFIG
	Khostmap hash /etc/mail/hostmap
	Kyplocal nis -m hosts.byname


+---------------------------+
| MASQUERADING AND RELAYING |
+---------------------------+

You can have your host masquerade as another using

	MASQUERADE_AS(`host.domain')

This causes mail being sent to be labeled as coming from the
indicated host.domain, rather than $j.  One normally masquerades as
one of one's own subdomains (for example, it's unlikely that
Berkeley would choose to masquerade as an MIT site).  This
behaviour is modified by a plethora of FEATUREs; in particular, see
masquerade_envelope, allmasquerade, limited_masquerade, and
masquerade_entire_domain.

The masquerade name is not normally canonified, so it is important
that it be your One True Name, that is, fully qualified and not a
CNAME.  However, if you use a CNAME, the receiving side may canonify
it for you, so don't think you can cheat CNAME mapping this way.

Normally the only addresses that are masqueraded are those that come
from this host (that is, are either unqualified or in class {w}, the list
of local domain names).  You can augment this list, which is realized
by class {M} using

	MASQUERADE_DOMAIN(`otherhost.domain')

The effect of this is that although mail to [e-mail]
will not be delivered locally, any mail including any [e-mail]
will, when relayed, be rewritten to have the MASQUERADE_AS address.
This can be a space-separated list of names.

If these names are in a file, you can use

	MASQUERADE_DOMAIN_FILE(`filename')

to read the list of names from the indicated file (i.e., to add
elements to class {M}).

To exempt hosts or subdomains from being masqueraded, you can use

	MASQUERADE_EXCEPTION(`host.domain')

This can come handy if you want to masquerade a whole domain
except for one (or a few) host(s).

Normally only header addresses are masqueraded.  If you want to
masquerade the envelope as well, use

	FEATURE(`masquerade_envelope')

There are always users that need to be "exposed" -- that is, their
internal site name should be displayed instead of the masquerade name.
Root is an example (which has been "exposed" by default prior to 8.10).
You can add users to this list using

	EXPOSED_USER(`usernames')

This adds users to class {E}; you could also use something like

	FE/etc/mail/exposed-users

You can also arrange to relay all unqualified names (that is, names
without @host) to a relay host.  For example, if you have a central
email server, you might relay to that host so that users don't have
to have .forward files or aliases.  You can do this using

	define(`LOCAL_RELAY', `mailer:hostname')

The ``mailer:'' can be omitted, in which case the mailer defaults to
"relay".  There are some user names that you don't want relayed, perhaps
because of local aliases.  A common example is root, which may be
locally aliased.  You can add entries to this list using

	LOCAL_USER(`usernames')

This adds users to class {L}; you could also use something like

	FL/etc/mail/local-users

If you want all incoming mail sent to a centralized hub, as for a
shared /var/spool/mail scheme, use

	define(`MAIL_HUB', `mailer:hostname')

Again, ``mailer:'' defaults to "relay".  If you define both LOCAL_RELAY
and MAIL_HUB _AND_ you have FEATURE(`stickyhost'), unqualified names will
be sent to the LOCAL_RELAY and other local names will be sent to MAIL_HUB.
Note: there is a (long standing) bug which keeps this combination from
working for addresses of the form user+detail.
Names in class {L} will be delivered locally, so you MUST have aliases or
.forward files for them.

For example, if you are on machine mastodon.CS.Berkeley.EDU and you have
FEATURE(`stickyhost'), the following combinations of settings will have the
indicated effects:

email sent to....	eric			  [e-mail]

LOCAL_RELAY set to	mail.CS.Berkeley.EDU	  (delivered locally)
mail.CS.Berkeley.EDU	  (no local aliasing)	    (aliasing done)

MAIL_HUB set to		mammoth.CS.Berkeley.EDU	  mammoth.CS.Berkeley.EDU
mammoth.CS.Berkeley.EDU	  (aliasing done)	    (aliasing done)

Both LOCAL_RELAY and	mail.CS.Berkeley.EDU	  mammoth.CS.Berkeley.EDU
MAIL_HUB set as above	  (no local aliasing)	    (aliasing done)

If you do not have FEATURE(`stickyhost') set, then LOCAL_RELAY and
MAIL_HUB act identically, with MAIL_HUB taking precedence.

If you want all outgoing mail to go to a central relay site, define
SMART_HOST as well.  Briefly:

	LOCAL_RELAY applies to unqualified names (e.g., "eric").
	MAIL_HUB applies to names qualified with the name of the
		local host (e.g., "[e-mail]").
	SMART_HOST applies to names qualified with other hosts or
		bracketed addresses (e.g., "[e-mail]"
		or "eric@[127.0.0.1]").

However, beware that other relays (e.g., UUCP_RELAY, BITNET_RELAY,
DECNET_RELAY, and FAX_RELAY) take precedence over SMART_HOST, so if you
really want absolutely everything to go to a single central site you will
need to unset all the other relays -- or better yet, find or build a
minimal config file that does this.

For duplicate suppression to work properly, the host name is best
specified with a terminal dot:

	define(`MAIL_HUB', `host.domain.')
	      note the trailing dot ---^


+--------------+
| LDAP ROUTING |
+--------------+

FEATURE(`ldap_routing') can be used to implement the IETF Internet Draft
LDAP Schema for Intranet Mail Routing
(draft-lachman-laser-ldap-mail-routing-01).  This feature enables
LDAP-based rerouting of a particular address to either a different host
or a different address.  The LDAP lookup is first attempted on the full
address (e.g., [e-mail]) and then on the domain portion
(e.g., @example.com).  Be sure to setup your domain for LDAP routing using
LDAPROUTE_DOMAIN(), e.g.:

	LDAPROUTE_DOMAIN(`example.com')

By default, the feature will use the schemas as specified in the draft
and will not reject addresses not found by the LDAP lookup.  However,
this behavior can be changed by giving additional arguments to the FEATURE()
command:

	FEATURE(`ldap_routing', <mailHost>, <mailRoutingAddress>, <bounce>)

where <mailHost> is a map definition describing how to lookup an alternative
mail host for a particular address; <mailRoutingAddress> is a map definition
describing how to lookup an alternative address for a particular address; and
the <bounce> argument, if present and not the word "passthru", dictates
that mail should be bounced if neither a mailHost nor mailRoutingAddress
is found.

The default <mailHost> map definition is:

	ldap -1 -v mailHost -k (&(objectClass=inetLocalMailRecipient)
				 (mailLocalAddress=%0))

The default <mailRoutingAddress> map definition is:

	ldap -1 -v mailRoutingAddress -k (&(objectClass=inetLocalMailRecipient)
					   (mailLocalAddress=%0))

Note that neither includes the LDAP server hostname (-h server) or base DN
(-b o=org,c=COUNTRY), both necessary for LDAP queries.  It is presumed that
your .mc file contains a setting for the confLDAP_DEFAULT_SPEC option with
these settings.  If this is not the case, the map definitions should be
changed as described above.

The following possibilities exist as a result of an LDAP lookup on an
address:

	mailHost is	mailRoutingAddress is	Results in
	-----------	---------------------	----------
	set to a	set			mail delivered to
	"local" host				mailRoutingAddress

	set to a	not set			delivered to
	"local" host				original address

	set to a	set			mailRoutingAddress
	remote host				relayed to mailHost

	set to a	not set			original address
	remote host				relayed to mailHost

	not set		set			mail delivered to
						mailRoutingAddress

	not set		not set			delivered to
						original address *OR*
						bounced as unknown user

The term "local" host above means the host specified is in class {w}.
Note that the last case depends on whether the third argument is given
to the FEATURE() command.  The default is to deliver the message to the
original address.

The LDAP entries should be set up with an objectClass of
inetLocalMailRecipient and the address be listed in a mailLocalAddress
attribute.  If present, there must be only one mailHost attribute and it
must contain a fully qualified host name as its value.  Similarly, if
present, there must be only one mailRoutingAddress attribute and it must
contain an RFC 822 compliant address.  Some example LDAP records (in ldif
format):

	dn: uid=tom, o=example.com, c=US
	objectClass: inetLocalMailRecipient
	mailLocalAddress: [e-mail]
	mailRoutingAddress: [e-mail]

This would deliver mail for [e-mail] to [e-mail].

	dn: uid=dick, o=example.com, c=US
	objectClass: inetLocalMailRecipient
	mailLocalAddress: [e-mail]
	mailHost: eng.example.com

This would relay mail for [e-mail] to the same address but redirect
the mail to MX records listed for the host eng.example.com.

	dn: uid=harry, o=example.com, c=US
	objectClass: inetLocalMailRecipient
	mailLocalAddress: [e-mail]
	mailHost: mktmail.example.com
	mailRoutingAddress: [e-mail]

This would relay mail for [e-mail] t