1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
SIMPLE.DOMAIN,v 1.1 1994/10/18 08:41:19 nm4 Exp
To: marc@r-node.gts.org (Marc Fournier)
Subject: Re: domain registering
Reply-To: tron@veritas.com
Organization: VERITAS Software, Corp.
Marc Fournier <marc@r-node.gts.org> writes:
> I'm probably getting into something deeper then I should, but
>how do I configure smail3.1 so that I'm a domain? Is there
>documentation on such available with the distribution? Is it
>hard to do? I'm basically going to set up a sub-domain for
>my downstream sites to 'attach' onto.
First, you will need to configure the hostnames recognized and
generated by your machine. set the visible_domain variable in
/usr/lib/smail/config to the set of domain suffixes to use for your
host. The first entry in the list is the canonical domain name,
additional names are recognized domain names, but are never used by
smail in generating addresses. For example:
visible_domain=gts.org:uucp
If this config file variable is used on host r-node, then the official
name for the host is considered:
r-node.gts.org
But the name:
r-node.uucp
will also be recognized.
You may also want to declare that your host recognizes gts.org as one
of its own names. You can do this by adding:
more_hostnames=gts.org
You can make gts.org the name that is generated when forming addresses
for the local users by adding:
visible_name=gts.org
This is a simple way of hiding your network topology from outside users.
Second, configure a paths file (which can be merged into the default
paths file, or configured through the routers file as a separate paths
file), containing entries such as:
.gts.org %s
.sub.gts.org gateway-sub-host!%s
foo.gts.org foo!%s
this paths file declares (in the first line), that your host is
authoritative for the gts.org domain, preventing use of the smarthost
router. It also causes mail to gts.org to be delivered locally on
your host.
The second line declares a subdomain, sub.gts.org, that is handled by
sending to gateway-sub-host.
The third line declares that host foo.gts.org can be reached by sending
to host foo.
This is the minimum that you must do to manage a simple domain using
paths files. If you are intending to use bind to manage your domain,
then you still may wish to add:
.gts.org %s
to a paths file (again, to disable smarthost routing).
If your local network is connected by a TCP/IP network and managed
using DNS tables, then you can just enable use of the bind router (by
copying samples/bind/routers to /usr/lib/smail/routers), and
configuring your network with DNS MX and A records. You may want to
configure a paths file prior to the bind router in the routers file, so
that you can override the DNS information (particular wildcarding), for
special cases, or to handle hosts within your domain that are not
connected to you TCP/IP network.
You may wish to configure a qualify file, so that references to hostnames
within your domain will be qualified with your domain name, in the
From:, To:, and Cc: lines of locally-generated messages. To do this,
create a file /usr/lib/smail/qualify containing lines such as:
foo gts.org
bar sub.gts.org
the first field in each line is a string that is matched against a
hostname in the From:, To:, or Cc: lines. The second field is a domain
suffix to append to that hostname. For example, given this file the
message:
From: marc@foo (Marc Fournier)
To: postmaster@bar
send on a machine containing the qualify file, would be transformed
into:
From: marc@foo.gts.org (Marc Fournier)
To: postmaster@bar.sub.gts.org
the qualify file does NOT support any kind of wildcarding.
--
tron |-<=>-| ARPAnet: veritas!tron@apple.com
tron@veritas.com UUCPnet: {apple,pyramid}!veritas!tron
|
