/
README
1857 lines (1558 loc) · 73 KB
/
README
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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
NEW SENDMAIL CONFIGURATION FILES
Eric Allman <eric@CS.Berkeley.EDU>
@(#)README 8.124 (Berkeley) 9/23/97
This document describes the sendmail configuration files being used
at Berkeley. These use features in the new (R8) sendmail; they will
not work on other versions.
These configuration files are probably not as general as previous
versions, and don't handle as many of the weird cases automagically.
I was able to simplify them for two reasons. First, the network
has become more consistent -- for example, at this point, everyone
on the internet is supposed to be running a name server, so hacks to
handle NIC-registered hosts can go away. Second, I assumed that a
subdomain would be running SMTP internally -- UUCP is presumed to be
a long-haul protocol. I realize that this is not universal, but it
does describe the vast majority of sites with which I am familiar,
including those outside the US.
Of course, the downside of this is that if you do live in a weird
world, things are going to get weirder for you. I'm sorry about that,
but at the time we at Berkeley had a problem, and it seemed like the
right thing to do.
This package requires a post-V7 version of m4; if you are running the
4.2bsd, SysV.2, or 7th Edition version, I suggest finding a friend with
a newer version. You can m4-expand on their system, then run locally.
SunOS's /usr/5bin/m4 or BSD-Net/2's m4 both work. GNU m4 version 1.1
or later also works. Unfortunately, I'm told that the M4 on BSDI 1.0
doesn't work -- you'll have to use a Net/2 or GNU version. GNU m4 is
available from ftp://prep.ai.mit.edu/pub/gnu/m4-1.4.tar.gz (check for
the latest version). EXCEPTIONS: DEC's m4 on Digital UNIX 4.x is broken
(3.x is fine). Use GNU m4 on this platform.
IF YOU DON'T HAVE A BERKELEY MAKE, don't despair! Just run
"m4 ../m4/cf.m4 foo.mc > foo.cf" -- that should be all you need.
There is also a fairly crude (but functional) Makefile.dist that works
on the old version of make.
To get started, you may want to look at tcpproto.mc (for TCP-only
sites), uucpproto.mc (for UUCP-only sites), and clientproto.mc (for
clusters of clients using a single mail host). Others are versions
that we use at Berkeley, although not all are in current use. For
example, ucbarpa has gone away, but I've left ucbarpa.mc in because
it demonstrates some interesting techniques.
I'm not pretending that this README describes everything that these
configuration files can do; clever people can probably tweak them
to great effect. But it should get you started.
*******************************************************************
*** BE SURE YOU CUSTOMIZE THESE FILES! They have some ***
*** Berkeley-specific assumptions built in, such as the name ***
*** of our UUCP-relay. You'll want to create your own domain ***
*** description, and use that in place of domain/Berkeley.m4. ***
*******************************************************************
+--------------------------+
| INTRODUCTION AND EXAMPLE |
+--------------------------+
Configuration files are contained in the subdirectory "cf", with a
suffix ".mc". They must be run through "m4" to produce a ".cf" file.
You must pre-load "cf.m4":
m4 ${CFDIR}/m4/cf.m4 config.mc > config.cf
where ${CFDIR} is the root of the cf directory and config.mc is the
name of your configuration file. If you are running a version of M4
that understands the __file__ builtin (versions of GNU m4 >= 0.75 do
this, but the versions distributed with 4.4BSD and derivatives do not)
or the -I flag (ditto), then ${CFDIR} can be in an arbitrary directory.
For "traditional" versions, ${CFDIR} ***MUST*** be "..", or you MUST
use -D_CF_DIR_=/path/to/cf/dir/ -- note the trailing slash! For example:
m4 -D_CF_DIR_=${CFDIR}/ ${CFDIR}/m4/cf.m4 config.mc > config.cf
Let's examine a typical .mc file:
divert(-1)
#
# Copyright (c) 1983 Eric P. Allman
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in
# the documentation and/or other materials provided with the
# distribution.
# 3. All advertising materials mentioning features or use of this
# software # must display the following acknowledgement:
# This product includes software developed by the University of
# California, Berkeley and its contributors.
# 4. Neither the name of the University nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS''
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
# THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
# OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
# OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
# EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#
# This is a Berkeley-specific configuration file for HP-UX 9.x.
# It applies only to the Computer Science Division at Berkeley,
# and should not be used elsewhere. It is provided on the sendmail
# distribution as a sample only. To create your own configuration
# file, create an appropriate domain file in ../domain, change the
# `DOMAIN' macro below to reference that file, and copy the result
# to a name of your own choosing.
#
divert(0)
The divert(-1) will delete the crud in the resulting output file.
The copyright notice can be replaced by whatever your lawyers require;
our lawyers require the one that I've included in my files. A copyleft
is a copyright by another name. The divert(0) restores regular output.
VERSIONID(`<SCCS or RCS version id>')
VERSIONID is a macro that stuffs the version information into the
resulting file. We use SCCS; you could use RCS, something else, or
omit it completely. This is not the same as the version id included
in SMTP greeting messages -- this is defined in m4/version.m4.
OSTYPE(hpux9)dnl
You must specify an OSTYPE to properly configure things such as the
pathname of the help and status files, the flags needed for the local
mailer, and other important things. If you omit it, you will get an
error when you try to build the configuration. Look at the ostype
directory for the list of known operating system types.
DOMAIN(CS.Berkeley.EDU)dnl
This example is specific to the Computer Science Division at Berkeley.
You can use "DOMAIN(generic)" to get a sufficiently bland definition
that may well work for you, or you can create a customized domain
definition appropriate for your environment.
MAILER(local)
MAILER(smtp)
These describe the mailers used at the default CS site site. The
local mailer is always included automatically. Beware: MAILER
declarations should always be at the end of the configuration file,
and MAILER(smtp) should always precede MAILER(uucp). The general
rules are that the order should be:
VERSIONID
OSTYPE
DOMAIN
FEATURE
local macro definitions
MAILER
LOCAL_RULESET_*
+----------------------------+
| A BRIEF INTRODUCTION TO M4 |
+----------------------------+
Sendmail uses the M4 macro processor to ``compile'' the configuration
files. The most important thing to know is that M4 is stream-based,
that is, it doesn't understand about lines. For this reason, in some
places you may see the word ``dnl'', which standards for ``delete
through newline''; essentially, it deletes all characters starting
at the ``dnl'' up to and including the next newline character. In
most cases sendmail uses this only to avoid lots of unnecessary
blank lines in the output.
Other important directives are define(A, B) which defines the macro
``A'' to have value ``B''. Macros are expanded as they are read, so
one normally quotes both values to prevent expansion. For example,
define(`SMART_HOST', `smart.foo.com')
One word of warning: M4 macros are expanded even in lines that appear
to be comments. For example, if you have
# See FEATURE(foo) above
it will not do what you expect, because the FEATURE(foo) will be
expanded. This also applies to
# And then define the $X macro to be the return address
because ``define'' is an M4 keyword. If you want to use them, surround
them with directed quotes, `like this'.
+--------+
| OSTYPE |
+--------+
You MUST define an operating system environment, or the configuration
file build will puke. There are several environments available; look
at the "ostype" directory for the current list. This macro changes
things like the location of the alias file and queue directory. Some
of these files are identical to one another.
It is IMPERATIVE that the OSTYPE occur before any MAILER definitions.
In general, the OSTYPE macro should go immediately after any version
information, and MAILER definitions should always go last.
Operating system definitions are usually easy to write. They may define
the following variables (everything defaults, so an ostype file may be
empty). Unfortunately, the list of configuration-supported systems is
not as broad as the list of source-supported systems, since many of
the source contributors do not include corresponding ostype files.
ALIAS_FILE [/etc/aliases] The location of the text version
of the alias file(s). It can be a comma-separated
list of names (but be sure you quote values with
commas in them -- for example, use
define(`ALIAS_FILE', `a,b')
to get "a" and "b" both listed as alias files;
otherwise the define() primitive only sees "a").
HELP_FILE [/usr/lib/sendmail.hf] The name of the file
containing information printed in response to
the SMTP HELP command.
QUEUE_DIR [/var/spool/mqueue] The directory containing
queue files.
STATUS_FILE [/etc/sendmail.st] The file containing status
information.
LOCAL_MAILER_PATH [/bin/mail] The program used to deliver local mail.
LOCAL_MAILER_FLAGS [rmn] The flags used by the local mailer. The
flags lsDFM are always included.
LOCAL_MAILER_ARGS [mail -d $u] The arguments passed to deliver local
mail.
LOCAL_MAILER_MAX [undefined] If defined, the maximum size of local
mail that you are willing to accept.
LOCAL_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
that ARRIVE from an address that resolves to the
local mailer and which are converted to MIME will be
labelled with this character set.
LOCAL_SHELL_PATH [/bin/sh] The shell used to deliver piped email.
LOCAL_SHELL_FLAGS [eu] The flags used by the shell mailer. The
flags lsDFM are always included.
LOCAL_SHELL_ARGS [sh -c $u] The arguments passed to deliver "prog"
mail.
LOCAL_SHELL_DIR [$z:/] The directory search path in which the
shell should run.
USENET_MAILER_PATH [/usr/lib/news/inews] The name of the program
used to submit news.
USENET_MAILER_FLAGS [rlsDFMmn] The mailer flags for the usenet mailer.
USENET_MAILER_ARGS [-m -h -n] The command line arguments for the
usenet mailer.
USENET_MAILER_MAX [100000] The maximum size of messages that will
be accepted by the usenet mailer.
SMTP_MAILER_FLAGS [undefined] Flags added to SMTP mailer. Default
flags are `mDFMUX' for all SMTP-based mailers; the
"esmtp" mailer adds `a' and "smtp8" adds `8'.
SMTP_MAILER_MAX [undefined] The maximum size of messages that will
be transported using the smtp, smtp8, or esmtp
mailers.
SMTP_MAILER_ARGS [IPC $h] The arguments passed to the smtp mailer.
About the only reason you would want to change this
would be to change the default port.
ESMTP_MAILER_ARGS [IPC $h] The arguments passed to the esmtp mailer.
SMTP8_MAILER_ARGS [IPC $h] The arguments passed to the smtp8 mailer.
RELAY_MAILER_ARGS [IPC $h] The arguments passed to the relay mailer.
SMTP_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
that ARRIVE from an address that resolves to one of
the SMTP mailers and which are converted to MIME will
be labelled with this character set.
UUCP_MAILER_PATH [/usr/bin/uux] The program used to send UUCP mail.
UUCP_MAILER_FLAGS [undefined] Flags added to UUCP mailer. Default
flags are `DFMhuU' (and `m' for uucp-new mailer,
minus `U' for uucp-dom mailer).
UUCP_MAILER_ARGS [uux - -r -z -a$g -gC $h!rmail ($u)] The arguments
passed to the UUCP mailer.
UUCP_MAILER_MAX [100000] The maximum size message accepted for
transmission by the UUCP mailers.
UUCP_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
that ARRIVE from an address that resolves to one of
the UUCP mailers and which are converted to MIME will
be labelled with this character set.
FAX_MAILER_PATH [/usr/local/lib/fax/mailfax] The program used to
submit FAX messages.
FAX_MAILER_ARGS [mailfax $u $h $f] The arguments passed to the FAX
mailer.
FAX_MAILER_MAX [100000] The maximum size message accepted for
transmission by FAX.
POP_MAILER_PATH [/usr/lib/mh/spop] The pathname of the POP mailer.
POP_MAILER_FLAGS [Penu] Flags added to POP mailer. Flags "lsDFM"
are always added.
POP_MAILER_ARGS [pop $u] The arguments passed to the POP mailer.
PROCMAIL_MAILER_PATH [/usr/local/bin/procmail] The path to the procmail
program. This is also used by FEATURE(local_procmail).
PROCMAIL_MAILER_FLAGS [SPhnu9] Flags added to Procmail mailer. Flags
``DFM'' are always set. This is NOT used by
FEATURE(local_procmail); tweak LOCAL_MAILER_FLAGS
instead.
PROCMAIL_MAILER_ARGS [procmail -Y -m $h $f $u] The arguments passed to
the Procmail mailer. This is NOT used by
FEATURE(local_procmail); tweak LOCAL_MAILER_ARGS
instead.
PROCMAIL_MAILER_MAX [undefined] If set, the maximum size message that
will be accepted by the procmail mailer.
MAIL11_MAILER_PATH [/usr/etc/mail11] The path to the mail11 mailer.
MAIL11_MAILER_FLAGS [nsFx] Flags for the mail11 mailer.
MAIL11_MAILER_ARGS [mail11 $g $x $h $u] Arguments passed to the mail11
mailer.
PH_MAILER_PATH [/usr/local/etc/phquery] The path to the phquery
program.
PH_MAILER_FLAGS [ehmu] Flags for the phquery mailer.
PH_MAILER_ARGS [phquery -- $u] -- arguments to the phquery mailer.
CYRUS_MAILER_FLAGS [A5@] The flags used by the cyrus mailer. The
flags lsDFMnP are always included.
CYRUS_MAILER_PATH [/usr/cyrus/bin/deliver] The progam used to deliver
cyrus mail.
CYRUS_MAILER_ARGS [deliver -e -m $h -- $u] The arguments passed
to deliver cyrus mail.
CYRUS_MAILER_MAX [undefined] If set, the maximum size message that
will be accepted by the cyrus mailer.
CYRUS_MAILER_USER [cyrus:mail] The user and group to become when
running the cyrus mailer.
CYRUS_BB_MAILER_FLAGS [undefined] The flags used by the cyrusbb
mailer. The flags lsDFMnP are always included.
CYRUS_BB_MAILER_ARGS [deliver -e -m $u] The arguments passed
to deliver cyrusbb mail.
+---------+
| DOMAINS |
+---------+
You will probably want to collect domain-dependent defines into one
file, referenced by the DOMAIN macro. For example, our Berkeley
domain file includes definitions for several internal distinguished
hosts:
UUCP_RELAY The host that will accept UUCP-addressed email.
If not defined, all UUCP sites must be directly
connected.
BITNET_RELAY The host that will accept BITNET-addressed email.
If not defined, the .BITNET pseudo-domain won't work.
DECNET_RELAY The host that will accept DECNET-addressed email.
If not defined, the .DECNET pseudo-domain and addresses
of the form node::user will not work.
FAX_RELAY The host that will accept mail to the .FAX pseudo-domain.
The "fax" mailer overrides this value.
LOCAL_RELAY DEPRECATED. The site that will handle unqualified
names -- that is, names with out an @domain extension.
If not set, they are assumed to belong on this machine.
This allows you to have a central site to store a
company- or department-wide alias database. This
only works at small sites, and only with some user
agents.
LUSER_RELAY The site that will handle lusers -- that is, apparently
local names that aren't local accounts or aliases.
Any of these can be either ``mailer:hostname'' (in which case the
mailer is the internal mailer name, such as ``uucp-new'' and the hostname
is the name of the host as appropriate for that mailer) or just a
``hostname'', in which case a default mailer type (usually ``relay'',
a variant on SMTP) is used. WARNING: if you have a wildcard MX
record matching your domain, you probably want to define these to
have a trailing dot so that you won't get the mail diverted back
to yourself.
The domain file can also be used to define a domain name, if needed
(using "DD<domain>") and set certain site-wide features. If all hosts
at your site masquerade behind one email name, you could also use
MASQUERADE_AS here.
You do not have to define a domain -- in particular, if you are a
single machine sitting off somewhere, it is probably more work than
it's worth. This is just a mechanism for combining "domain dependent
knowledge" into one place.
+---------+
| MAILERS |
+---------+
There are fewer mailers supported in this version than the previous
version, owing mostly to a simpler world. As a general rule, put the
MAILER definitions last in your .mc file, and always put MAILER(smtp)
before MAILER(uucp) -- several features and definitions will modify
the definition of mailers, and the smtp mailer modifies the UUCP
mailer.
local The local and prog mailers. You will almost always
need these; the only exception is if you relay ALL
your mail to another site. This mailer is included
automatically.
smtp The Simple Mail Transport Protocol mailer. This does
not hide hosts behind a gateway or another other
such hack; it assumes a world where everyone is
running the name server. This file actually defines
four mailers: "smtp" for regular (old-style) SMTP to
other servers, "esmtp" for extended SMTP to other
servers, "smtp8" to do SMTP to other servers without
converting 8-bit data to MIME (essentially, this is
your statement that you know the other end is 8-bit
clean even if it doesn't say so), and "relay" for
transmission to our RELAY_HOST, LUSER_RELAY, or
MAILER_HUB.
uucp The Unix-to-Unix Copy Program mailer. Actually, this
defines two mailers, "uucp-old" (a.k.a. "uucp") and
"uucp-new" (a.k.a. "suucp"). The latter is for when you
know that the UUCP mailer at the other end can handle
multiple recipients in one transfer. If the smtp mailer
is also included in your configuration, two other mailers
("uucp-dom" and "uucp-uudom") are also defined [warning:
you MUST specify MAILER(smtp) before MAILER(uucp)]. When you
include the uucp mailer, sendmail looks for all names in
the $=U class and sends them to the uucp-old mailer; all
names in the $=Y class are sent to uucp-new; and all
names in the $=Z class are sent to uucp-uudom. Note that
this is a function of what version of rmail runs on
the receiving end, and hence may be out of your control.
See the section below describing UUCP mailers in more
detail.
usenet Usenet (network news) delivery. If this is specified,
an extra rule is added to ruleset 0 that forwards all
local email for users named ``group.usenet'' to the
``inews'' program. Note that this works for all groups,
and may be considered a security problem.
fax Facsimile transmission. This is experimental and based
on Sam Leffler's HylaFAX software. For more information,
see http://www.vix.com/hylafax/.
pop Post Office Protocol.
procmail An interface to procmail (does not come with sendmail).
This is designed to be used in mailertables. For example,
a common question is "how do I forward all mail for a given
domain to a single person?". If you have this mailer
defined, you could set up a mailertable reading:
host.com procmail:/etc/procmailrcs/host.com
with the file /etc/procmailrcs/host.com reading:
:0 # forward mail for host.com
! -oi -f $1 person@other.host
This would arrange for (anything)@host.com to be sent
to person@other.host. Within the procmail script, $1 is
the name of the sender and $2 is the name of the recipient.
If you use this with FEATURE(local_procmail), the FEATURE
should be listed first.
mail11 The DECnet mail11 mailer, useful only if you have the mail11
program from gatekeeper.dec.com:/pub/DEC/gwtools (and
DECnet, of course). This is for Phase IV DECnet support;
if you have Phase V at your site you may have additional
problems.
phquery The phquery program. This is somewhat counterintuitively
referenced as the "ph" mailer internally. It can be used
to do CCSO name server lookups. The phquery program, which
this mailer uses, is distributed with the ph client.
cyrus The cyrus and cyrusbb mailers. The cyrus mailer delivers to
a local cyrus user. this mailer can make use of the
"user+detail@local.host" syntax; it will deliver the mail to
the user's "detail" mailbox if the mailbox's ACL permits.
The cyrusbb mailer delivers to a system-wide cyrus mailbox
if the mailbox's ACL permits.
The local mailer accepts addresses of the form "user+detail", where
the "+detail" is not used for mailbox matching but is available
to certain local mail programs (in particular, see FEATURE(local_procmail)).
For example, "eric", "eric+sendmail", and "eric+sww" all indicate
the same user, but additional arguments <null>, "sendmail", and "sww"
may be provided for use in sorting mail.
+----------+
| FEATURES |
+----------+
Special features can be requested using the "FEATURE" macro. For
example, the .mc line:
FEATURE(use_cw_file)
tells sendmail that you want to have it read an /etc/sendmail.cw
file to get values for class $=w. The FEATURE may contain a single
optional parameter -- for example:
FEATURE(mailertable, dbm /usr/lib/mailertable)
Available features are:
use_cw_file Read the file /etc/sendmail.cw file to get alternate
names for this host. This might be used if you were
on a host that MXed for a dynamic set of other
hosts. If the set is static, just including the line
"Cw<name1> <name2> ..." is probably superior.
The actual filename can be overridden by redefining
confCW_FILE.
use_ct_file Read the file /etc/sendmail.ct file to get the names
of users that will be ``trusted'', that is, able to
set their envelope from address using -f without
generating a warning message.
The actual filename can be overridden by redefining
confCT_FILE.
redirect Reject all mail addressed to "address.REDIRECT" with
a ``551 User not local; please try <address>'' message.
If this is set, you can alias people who have left
to their new address with ".REDIRECT" appended.
nouucp Don't do anything special with UUCP addresses at all.
nocanonify Don't pass addresses to $[ ... $] for canonification.
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.
stickyhost If set, email sent to "user@local.host" 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 "user@local.host", 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. The argument of the
FEATURE may be the key definition. If none is specified,
the definition used is:
hash -o /etc/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".
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.
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 -o /etc/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 -o /etc/bitdomain.db
Keys are the bitnet hostname; values are the corresponding
internet hostname.
uucpdomain Similar feature for UUCP hosts. The default map definition
is:
hash -o /etc/uudomain.db
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 $=w are masqueraded. If this
feature is given, only the hosts listed in $=M 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 certain addresses originating in the
local domain or a domain listed in $=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. The addresses must be in the list of names given
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
defintion; the default map definition is:
hash -o /etc/genericstable
The key for this table is either the full address or the
unqualified username (the former is tried first); the
value is the new user address. If the new user address does
not include a domain, $j is used. 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.
virtusertable A domain-specific form of aliasing, allowing multiple
virtual domains to be hosted on one machine. For example,
if the virtuser table contained:
info@foo.com foo-info
info@bar.com bar-info
@baz.org jane@elsewhere.net
then mail addressed to info@foo.com will be sent to the
address foo-info, mail addressed to info@bar.com will be
delivered to bar-info, and mail addressed to anyone at
baz.org will be sent to jane@elsewhere.net. The username
from the original address is passed as %1 allowing:
@foo.org %1@elsewhere.com
meaning someone@foo.org will be sent to someone@elsewhere.com.
All the host names on the left hand side (foo.com, bar.com,
and baz.org) must be in $=w. The default map definition is:
hash -o /etc/virtusertable
A new definition can be specified as the second argument of
the FEATURE macro, such as
FEATURE(virtusertable, dbm -o /etc/mail/virtusers)
nodns We aren't running DNS at our site (for example,
we 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 stripped down
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 "nocanonify" (this causes addresses to
be sent unqualified via the SMTP connection; normally
they are qualifed with the masquerade name, which
defaults to the name of the hub machine). No mailers
should be defined. No aliasing or forwarding is done.
local_procmail Use procmail as the local mailer. This mailer can
make use of the "user+indicator@local.host" syntax;
normally the +indicator is just tossed, but by default
it is passed as the -a argument to procmail. The
argument to this feature is the pathname of procmail,
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.
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. 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, /usr/local/etc/smrsh is
assumed.
+-------+
| 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 we move 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.
If your host is known by several different names, you need to augment
the $=w class. This is a list of names by which you are known, and
anything sent to an address using a host name in this list will be
treated as local mail. You can do this in two ways: either create
the file /etc/sendmail.cw containing a list of your aliases (one per
line), and use ``FEATURE(use_cw_file)'' in the .mc file, or add the
line:
Cw alias.host.name
at the end of that file. See the ``vangogh.mc'' file for an example.
Be sure you use the fully-qualified name of the host, rather than a
short name.
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. The $=W class 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 I've left
this out-of-date configuration file 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 $=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:
We are 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 wolf@grasp.insa-lyon.fr
uucp-uudom wolf grasp.insa-lyon.fr!wolf
uucp-{old,new} wolf@fr.net grasp!fr.net!wolf
uucp-dom wolf@fr.net wolf@fr.net
uucp-uudom wolf@fr.net fr.net!wolf
uucp-{old,new} somehost!wolf grasp!somehost!wolf
uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr
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 addreses 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 "user@decvax.dec.com" and "user@research.att.com"
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, and can be used to
declare local database maps or whatever. For example:
LOCAL_CONFIG
Khostmap hash /etc/hostmap.db
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 I 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 $=w, the list
of local domain names). You can augment this list using
MASQUERADE_DOMAIN(otherhost.domain)
The effect of this is that although mail to user@otherhost.domain
will not be delivered locally, any mail including any user@otherhost.domain
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.
Normally only header addresses are masqueraded. If you want to
masquerade the envelope as well, use
FEATURE(masquerade_envelope)