|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T p
Length: 47182 (0xb84e)
Types: TextFile
Names: »part.9«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z«
└─⟦bcd2bc73f⟧
└─⟦this⟧ »design/part.9«
Part 9: Miscellaneous topics.
There are a many other subsystems in smail that require
some attention. These are discussed in following sections,
in case you didn't already guess. :-)
Section 9.1: Message spooling.
Input messages are spooled in smail to lower the probability of
losing mail due to software or system failure. Messages can
also be spooled simply to delay mail delivery and make
processing more efficient through batching. For example, if
the system is heavily loaded smail may decide to spool a message
instead of using CPU resources to attempt delivery.
Section 9.1.1: Format of spooled messages.
Spooled messages follow a simple format that is easy to produce
and easy to parse. It contains the following strings in
order:
1. The login name that the message was submitted on the local
host, or the name from the password entry corresponding
to the real uid for non-login sessions. This name may be
padded with spaces before the ending newline if it is
shorter than 8 characters.
2. The real user ID at the time smail was invoked to queue
the message. The number is stored as an ASCII string in
decimal.
3. Argument strings which can reproduce the state to use for
processing the message. This includes error processing
flags, -f and -F flags, and addresses which were supplied
as arguments to the smail program.
4. The message, as initially received by smail.
For example, a message from glotz!walldrug!root to tron and
prep.ai.mit.edu!root, submitted under real uid 10, might look
like:
uucp
10
-em
tron
prep.ai.mit.edu!root
From walldrug!root Sun Aug 23 00:56:03 1987 remote from glotz
Received: by glotz.uucp
Received: by walldrug
Date: Fri, 21 Aug 1987 18:58:04 PDT
Message-ID: <id29374@walldrug.wall.com>
From: root@walldrug.wall.com (The Church Police)
To: tron@glotz.uucp
Subject: what's all this then?
Cc: prep.ai.mit.edu!root@glotz.uucp
What's all this then, amen!
It is possible that newlines could occur in argument strings,
To guard against this causing problems, any occurrence of `\'
in the argument and sender strings is replaced by ``\\'' and
any occurrence of newline in one of those strings is replaced
by ``\n''.
Section 9.1.2: Format of spool file basenames.
The spool file name is a 14 character file name that contains:
length meaning
------ -------
6 seconds since 1969 GMT, in base 62
1 the charactere `-'
6 an inode number, in base 62
1 grade character (see section 9.5)
The base-62 numbers above use characters from the set of decimal
digits, uppercase letters and lowercase letters. These numbers
always begin with a decimal digit.
Example:
A spool file created on Sat, Jan 16 1988 at 15:57:56 on inode
37477 with a message grade, or priority, character of `C'
would be:
0cX2fs-000AjqC
Section 9.1.3: Spool directories and locking directories.
Files can be spooled in several directories: a primary spool
directory and any number of alternate spool directory. The
alternate spool directories are used if creation of a spool
file in the primary area failed. For example, the primary
directory may not be writable for some reason, or the file
system where it resides may be out of i-nodes or out of free
blocks. The alternate spool directories, if any exist, should
always be on different filesystems than the primary one.
Each of the spool directories has a locking directory under it
named ``lock''. When a spool file is being created or is being
processed, a file will exist in the locking directory with the
same basename in the spool file. This is to prevent two
processes from trying to process the same spool file, and to
prevent a spool processing daemon from trying to read a spool
file that is in the process of being created.
The sequence involved in creating a spool file is defined below:
1. Set the variable <tempfile> to <spooldir>/lock/msg.<pid>
where <pid> is the current process ID, in ASCII decimal.
2. Create the file <tempfile>. If this fails go to step 6.
3. Set the variable <spoolfile> to <spooldir>/<basename>,
where the inode is from that for <tempfile>.
4. Write out the sender, real uid, arguments, header and the
message. If this fails go to step 6.
5. When finished writing, rename the file <tempfile>
to <spoolfile>.
6. If we failed to write to a spool file, then remove
<tempfile> and then set <spoolfile> to <altspooldir>/<basename>
and set <tempfile> to <altspooldir>/lock/msg.<pid>, where
<altspooldir> is then next alternate directory in the list.
Then go to step 2. If no more alternate spool directories
exist then we failed to spool the message.
Section 9.1.4: Locking spool files.
For systems that have advisory (or mandatory) file locking, the
operating system's locking should be used. For systems that lack
such a feature, the following method can be used.
Consider the existing spoolfile:
<dir>/<basename>
where <dir> is a spooling directories and <basename> is the
basename of the file to be locked. To lock this spool file
we exclusively create the following lock file:
<dir>/lock/<basename>
and write our process id in ascii (base 10) followed by a newline.
At this point the file <dir>/<basename> has been locked.
If our exclusive create of the file <dir>/lock/<basename> failed,
then it is likely that another process has locked <dir>/<basename>.
We can verify that the process really does have the lock file
by the following algorithm:
1. stat the lock file and set:
<file_len> = file length
<cr_date> = creation date
2. if <file_len> != 0, the proceed to step 8
3. The lock file is empty because the locking process has
not yet written out its process id, or because the
process or system crashed before the write.
If `now' < Oct 28, 1986, then proceed to step 5.
If <cr_date> > `now' then proceed to step 6.
If <cr_date> < `now - 2 hours' proceed to step 7.
4. The empty lock file is too new to touch (the system could
be extremely loaded) and so we simply conclude that
some process has it locked and go on to do something else.
5. Since this version of smail did not exist on Oct 28, 1986,
the current time must be set wrong. At this point
we give up all hope of stale lock file detection,
consider the file locked and go on to do something else.
6. The empty lock file was created in the future so we don't
know if the empty lock file is stale or not. We first
bring the <cr_date> of the file back into reality by
doing a chmod (to the same permission). This forces
the <cr_date> to be set to `now'. Next we send the
following error message to the system log:
time warp on zero length lock file: 0571338010a72y
We consider the lock file active for now and go on to
do something else.
7. The empty lock file is likely to be stale. We will
remove the lock file but we will still consider it
locked, allowing some future process to operate
on <dir>/<filename>. We now go on to do something else.
8. The lock file contains the process id of the locking
process. We open the lock file and read it and set:
<lock_pid> = process id read from the lock file
If <lock_pid> == 0, then proceed to step 11.
If <lock_pid> is not a process, then proceed to step 10.
9. The process <lock_pid> is a valid and currently
running process, and thus the lock file is really
valid. At this point we go on to do something else.
10. The lock file is probably stale. We will remove the
lock file but we will still consider it locked, allowing
some future process to operate on <dir>/<filename>. We
now go on to do something else.
11. If <lock_pid> == 0, then the lock file is a
permanent lock file. (perhaps set by the system
administrator to freeze a mail message) At this
point we go on to do something else.
The above procedure allows for locking of spool files to work
even under many extreme conditions and yet will not freeze a mail
message for a long time. There are some conditions where this
locking system will fail:
* the system is so loaded, or the locking process is
suspended such that more than 2 hours pass between
the lock file creation and the write of the process
id.
* the system clock is changed by an administrator by a
large amount (say > 2 hours) at the wrong moment.
Note that Daylight Savings Time changes will not
cause this since the time stamps involved are based
on GMT.
Section 9.2: Logging.
Three types of log files are maintained: a panic log, a
transaction/debugging log and a per-message transaction/error/
debugging log.
There are a many cases where smail will decide that something
cannot be dealt with now. This could be an internal error, a
configuration file error, an i/o error, or an out of memory
error (the latter is almost certainly an internal error, except
on systems with small amounts of memory or small addressing
spaces). In such cases, an entry is made in the panic log
explaining what went wrong, the lock file is removed, and smail
quits. Perhaps at a later time, this case will be remedied
and processing the spool file will succeed.
The transaction/debugging log contains messages that may be
of interest to maintainers of the mail system. Some of the
items logged are: notification of reception of mail, including
sender and the host from whence mail was received, if applicable;
notification of successful or failed transmission of mail to
remote and local sources; and reasons for mail being sent
back to the sender or to the postmaster (syntax errors in
addresses, unknown hosts or users, etc).
The per-message transaction/error/debugging log is named
<dir>/msglog/<basename> where <dir> is the spooling directory
used. It is not removed until a the spool file is also removed.
It contains the same messages as the transaction/debugging log,
but may also contain more detailed accounts of syntax errors and
other problems relating solely to the message itself. When the
message is returned to the sender or sent to the postmaster,
the per-message log is sent as well as explanation.
Section 9.3: The config file.
In addition to information in the director, transport and
router files, and the various method files, there are a many
miscellaneous configuration parameters for smail that are
stored in an smail config file. This information includes file
and directory names, hostname information plus boolean and
string valued variables defining other miscellaneous
information.
The config file is able to overrite a number of compiled in
values. Attributes listed below are also found as UPPER CASE
#defile symbols in various source files. See Section 10.1
for details.
The format of this file is defined as:
<config_file> = (<comment> or <attribute>)*
<comment> = #[^\n]* or [\n]
<attribute> = <boolean_attribute> or <string_attribute>
<boolean_attribute> = {[+-]}<name> {<comment>}
<string_attribute> = <name> `=' <string-or-number> {<comment>}
<name> = [A-Za-z0-9_-]+
<string-or-number> = [!$%./0-9@A-Za-z_][!$%&+./0-9@A-Za-z_-]* or
`<' [^>]* `>' or "[^"]*"
The following paragraphs define the current set of configuration
attributes that can be set in the smail config file:
console
type: string
default value: /dev/console
The file name for the console device. This filename is
used as a last resort in attempting to write panic mes-
sages.
copying_file
type: string
default value: ``COPYING''
The pathname to the COPING file, which describes your
distribution rights and details the warranty informa-
tion from the authors of smail. If this does not begin
with `/', it will be referenced relative to the
smail_lib_dir directory.
date_field
type: string
default value: ``Date: $date''
This string will be expanded to form the Date: header
field. This will be used if such a field does not
already exist in the header.
delivery_mode
type: string
default value: ``foreground''
The default mode of delivery for new mail. This can be
one of the values ``foreground'' (immediate delivery in
the process that received the message), ``background''
(immediate delivery in a child process, where the pro-
cess that received the message exits immediately), or
``queued'' (do not attempt delivery until a later queue
run).
director_file
type: string
default value: ``directors''
Names the file containing the director configuration
information. If this does not begin with `/', it will
be referenced relative to the smail_lib_dir directory.
fnlock_interval
type: number
default value: 3
The sleep interval between retries while attempting to
lock mailbox files with a lockfile-based locking proto-
col.
fnlock_retries
type: number
default value: 0 if you have an atomic rename, 5 other-
wise
The number of times to attempt to lock mailbox files
using a file-based locking protocol.
grades
type: string
default value: special-delivery:9:air-mail:A:first-
class:C:bulk:a:junk:n
The priority, or grade, characters corresponding to
particular values for the Precedence: field in the
message header. The parts of the string are separated
by `:' with alternating precedence string and grade
character. Numbers are higher in priority than upper
case letters which are in turn higher than lower case
letters. Also lower numbers are higher in priority
than higher numbers, and the same goes for letters
lower in the alphabet Grades in the range [a-m] will
only have an error message and header returned to the
sender on errors, rather than including the message
body as well. Grades in the range [n-z] will not have
anything returned to the sender on errors.
The precedence names recognized by many BSD sendmail
configurations are: special-delivery, first-class and
junk. Others are useful mainly for getting mail out of
the local machine or for communication with other
machines running smail in a similar configuration. The
grade value for a message is available in string expan-
sions as the $grade variable.
hit_table_len
type: number
default value: 241 with a large address space, 13 oth-
erwise
The length of an internal address hit table. Addresses
are hashed into this table to prevent multiple
deliveries to the same address. Longer tables speed
address hashing at a small memory expense.
NOTE: this value may be ignored in the future.
hostnames
type: string
default value: computed at run time
A colon-separated list of names for the local host.
This list, together with visible_name , uucp_host and
more_hostnames should represent all possible names for
the local host. For a host that is in more than one
domain or that can gateway to more than one level of
domains, this should represent those names. For a host
in a registered domain in the UUCP zone, which is also
in the maps distributed over USENET, localhost.uucp
should also be in the list. The first value in host-
names is used internally as a special ``primary name''
for the local host.
If hostnames is set turned off (which is generally the
default) then the hostnames value will be computed by
pairing the localhosts's name, computed in a system-
dependent manner, with all values in the
visible_domains attribute list.
lock_by_name
type: boolean
default value: system-dependent
If this is on, then input spool file locking is always
based on lock files. Otherwise, an inode-based locking
mechanism may be used, such as flock(2) under BSD, or
lockf(3) under System V. Inode-based locking is more
efficient, if available. However, lock files can be
easily created by shell scripts which may be advanta-
geous under some circumstances.
lock_mode
type: number
default value: 0444
The creation mode for lock files.
log_mode
type: number
default value: 0664
The creation mode for the various mail system log
files.
logfile
type: string
default value: ``/usr/spool/smail/log/logfile''
The name of a file to which transaction and error mes-
sages are appended. If this file does not exist, it is
created with a mode from the log_mode attribute.
max_hop_count
type: number
default value: 20
If the hop count for a message equals or exceeds this
number, then attempts at remote delivery will result in
an error message being returned to the sender. This is
used to prevent infinite loops. The hop count for a
message can be set using the -h option when invoking
smail. Otherwise it is computed from the number of
Received: fields in the message header.
max_load_ave
type: number
default value: 0
For systems on which a load average can be computed,
this specifies the maximum load average at which mail
delivery will be performed, otherwise this value is
ignored. If the load average exceeds this number,
incoming mail will be saved in the input spool direc-
tory, though no delivery will be performed. If this
value is 0 the load average will not be computed and
delivery will always be performed. Normally the load
average refers to a 5 minute load average. (This is
not currently implemented)
max_message_size
type: number
default value: 100k
Messages longer than this will be truncated by smail
when when written to its input queue. (This is not
currently implemented and there is no limit on the size
of messages).
message_buf_size
type: number
default value: 100k with a large address space, BUFSIZ
otherwise
The size of an internal buffer for reading and writing
messages. For systems with a reasonable VM space, this
can be equal to the maximum size for messages. Speci-
fying the value of in which case reading messages and
then delivering them to one or more destinations
requires very few read calls, as the entire message is
always kept in memory. BUFSIZ, here, refers to the
defined symbol in /usr/include/stdio.h.
message_id_field
type: string
default value: ``Message-Id:
<$message_id@$primary_name>''
This string will be expanded to form the Message-Id:
header field. This will be used if such a field does
not already exist in the header.
message_log_mode
type: number
default value: 0664
Each message has associated with it a unique file con-
taining a transaction log for that message. This
number specifies the creation mode for this log file.
method_dir
type: string
default value: ``methods''
If a method attribute for a router does not specify a
pathname beginning with `/', then this directory is
prepended to the path to form the complete path for the
method file. See the description of the router file
for more information on method files. If this does not
begin with `/', it will be referenced relative to the
smail_lib_dir directory.
more_hostnames
type: string
default value: off
A colon-separated list of hostnames. This list is in
addition to any names which may have been computed from
the visible_domains attribute in forming the value of
hostnames. Thus, it is useful for specifying names
which are not formed from the computed name for the
host.
nobody
type: string
default value: site-dependent: often ``nobody''
This names a default user that defines permissions when
no other user is specified. Also, this user is used in
some conditions when it is not certain whether a set of
actions can be trusted, if performed under other,
potentially more powerful users. This should reference
a login id which has few or no capabilities for doing
harm or accessing protected files.
paniclog
type: string
default value: ``/usr/spool/smail/log/paniclog''
The name of a file to which panic and very important
error messages are appended. If this file does not
exist, it is created with a mode from the log_mode
attribute. Entries written to this log file represent
problems that require human intervention, such as con-
figuration errors or directory permission errors
preventing mail spooling or delivery.
Configuration errors generally cause mail to be moved
into a special defer/ directory under the input spool
directory, thus preventing attempts at redelivery until
the configuration error has been corrected.
Thus, both the panic log and the defer/ directory
should be checked periodically under normal use, and
frequently after configuration changes. When any prob-
lems have been resolved, deferred messages can be
requeued for delivery by using mv(1) to move the spool
files back to the spool directory.
queue_only
type: boolean
default value: off
If this is set then smail will not immediately attempt
delivery for incoming mail. The smail program will
then only attempt delivery when explicitly processing
the input queue, such as when invoked with the -q flag.
received_field
type: string
This string will be expanded to form the Received:
header field. This field will be inserted into the
header if the received attribute is not explicitly
turned off for a transport. The default value for
received_field is:
Received: by $primary_name ($version_string)
id <$message_id@$primary_name>; $date
require_configs
type: boolean
default value: off
If this is not set, then configuration files are not
required to exist. This applies to the primary and
secondary config files and the director, router and
transport files. If one of these files does not exist
then it is ignored and internally compiled
configuration is used instead. If this attribute is
set, then any configuration file, which does not have
a NULL filename (for example, using -router_file to
set the name of the router file to NULL) and which
does not exist, will generate a panic message from the
mailer.
return_path_field
type: string
default value: ``Return-Path: <$sender>''
This string will be expanded to form the Return-Path:
header field. This field will be inserted into the
header if the return_path attribute is turned on for a
transport.
router_file
type: string
default value: ``routers''
Names the file containing the router configuration
information. If this does not begin with `/', it will
be referenced relative to the smail_lib_dir directory.
second_config_file
type: string
default value: none
This names a secondary configuration file which can
define attribute values which override internal
defaults and values in the primary configuration file.
This is primarily useful in networks containing
machines that share filesystems. By having a shared
primary configuration file most systems on a network
need not be concerned with maintaining the smail pro-
gram, while other systems may want or need to use a
different configuration, while sharing the same binary.
In particular, the smart_user, smart_path and
smart_transport attributes are common attributes to be
set in the secondary configuration file.
smail
type: string
default value: ``/usr/lib/sendmail''
Name a valid path to a smail binary that can be used to
re-exec smail when a major configuration change has
been detected, or to exec smail when delivering error
messages. If this does not begin with `/', it will be
referenced relative to the smail_lib_dir directory.
smail_lib_dir
type: string
default value: ``/usr/lib/smail''
This defines the path to the smail configuration file
directory. The router, director and transport files,
as well as alias and path files and method files may be
referenced relative to this directory.
smart_path
type: string
default value: none
This defines the default value for the path attribute
used by the smarthost router driver. This gives the
path to a machine which supposedly contains a more com-
plete routing database than is available on the local
host. See a later section describing the smarthost
driver for more information on the use of this attri-
bute.
smart_transport
type: string
default value: none
This defines the default value for the transport gen-
eric attribute used by the smarthost router driver.
See a later section describing the smarthost driver for
more information on the use of this attribute.
smart_user
type: string
default value: none
This defines the default value for the smart_user
attribute used by the smartuser director driver.
spool_dirs
type: string
default value: ``/usr/spool/smail''
This defines one or more directories into which incom-
ing mail can be spooled. Directories are separated by
single colon characters. When writing a message to the
first spool directory fails, (say due to permission
problems, filesystem full errors, etc.) successive
spool directories are tried until the incoming message
can be successfully written or until no more alterna-
tive directories exist. Each spool directory is
expected to have writable subdirectories of: lock (for
temporary lock files), msglog (for temporary per-
message transaction logs and audit trails) and defer
(to hold messages which failed due to configuration
errors or other problems which require human interven-
tion).
spool_grade
type: character
default value: ``C''
This character names the default grade for messages.
This can be overridden by a Precedence: field in the
message header. The grade is used in sorting messages
in the input spool directory and is also available in
string expansions as the $grade variable. See the
grades attribute for more information.
spool_mode
type: number
default value: 0440
This defines the file creation mode for spool files.
transport_file
type: string
default value: ``transports''
names the file containing the transport configuration
information. If this does not begin with `/', it will
be referenced relative to the smail_lib_dir directory.
trusted
type: string
default value: ``root:uucp:daemon''
This names a list of users (separated by colons) who
are trusted to specify a sender for a message. Users
who are not in this list cannot specify a Sender:
header field without it being removed. If such users
specify a From: header field, then a Sender: field will
be created that specifies the real user that submitted
this mail. Generally, this should be set to that names
of all users under which remote mail is received and
sent to smail. If this list is turned off, using the
form -trusted, then all users are trusted.
NOTE: The real user ID is used in verifying trusted
users. However, under many operating systems, the
/usr/lib/uucp/uucico program runs under the real uid of
the user that ran /usr/lib/uucp/uucico. Often any user
can run the uucico program. The smail program cannot
differentiate this case from any other case and will
thus do the ``wrong thing'' here. If this problem
exists on your machine, then the trusted attribute may
need to be turned off. This problem is particularly
difficult to resolve on System V machines where non-
superuser programs are unable to change their real uid.
uucp_name
type: string
default value: computed at run time
This specifies a name for the local host. This name is
available in string expansions as the $uucp_name vari-
able. It is also used in the ``remote from hostname''
suffix to ``From<space>'' lines for mail being
delivered to remote machines, when the from attribute
is turned on for a transport.
visible_domains
type: string
default value: uucp
visible_name
type: string
default value: computed at run time
The full domain name used in outgoing mail addresses
within header fields. If visible_name is turned off,
then it will be set to the first name from the host-
names attribute. If the hostnames attribute is not
specified then that attribute will be filled in with
hostnames of the form hostname.visible_domain, where
hostname is derived in a system-dependent manner and
where visible_domain, here, is one name from the
visible_domains list attribute. Each entry in the
visible_domains list is used, in order, to created the
hostnames value.
For sites in the UUCP zone visible_domains will often
merely be the string ``uucp''. Finally, the variable
$visible_name is available in string expansions.
Section 9.4: The startup file.
NOTE: Startup files are not currently supported, and may
never be needed.
Section 9.5: Mail precedence.
Mail can be given a precedence by including a header field of:
Precedence: name
Where name is some <local_part> string that can be associated
with a queue priority. These precedence names are converted
internal to a single character from the set of digits, upper
case and lower case letters, with low to high precedence being
in that order, with low digits and letters having higher
precedence, that is compatible with 4.3BSD and HoneyDanBer
UUCP grading. These grade characters are used in the
generation of the spool file names, see Section 9.1.2 for more
details on this.
The mapping from precedence name to grade character is
configurable, though examples might be:
special-delivery 9
air-mail A
first-class C
bulk a
junk n
These grade values are taken into account when sorting the
spool directory messages to decide what to process next, and
they may also be used by transports in sending priorities to
the transport mechanism. In addition, a message with a grade
character that is a lower-case letter from the set [a-m] and
that fails in some way will cause only the message header and
a message describing the failure to be sent back to the
sender, rather than returning the entire message. If the
character is from the set [n-z], then mail is never returned
back to the sender on errors.
Note: I have not seen any standards documents that make use
of this Precedence field. The idea for it comes from,
and is syntactically compatible with, Eric Allman's
Sendmail program.
Section 9.6: Arguments to smail.
The arguments which are expected by the smail program depend
upon how the program is invoked. As well, different
invocation names can cause a differing set of defaults to be
used for some things.
Section 9.6.1: Invocation as sendmail.
In the normal mode of operation is to understand a set of
arguments similar to those accepted by the BSD sendmail
program from Eric Allman. However, all names other than
``smail'' ``sendmail'' and ``send-mail'' are reserved for other
uses. The current set of recognized arguments is:
-bc Display the file COPYING, distributed with the source,
which details your rights and restrictions for distri-
buting this software.
-bd Listen for connection requests on a socket bound in the
internet domain. When a connection occurs, conduct an
SMTP (Simple Mail Transfer Protocol) conversation with
the peer process. Listening will only occur if BSD
style internet networking functionality is available.
-bm Deliver mail to the recipient addresses. This is the
default mode of operation if invoked as sendmail,
smail, rmail or send-mail.
-bp List information about the messages currently in
smail's input spool directories. This is the default
mode of operation if invoked as mailq. With the -v or
-d flag, a per-message transaction log is displayed for
each message which shows what has happened to the
message so far.
-bP Take the addresses given on the command line as config
file variables and write the values for each variable
on the standard output. References to variables such
as hostnames or uucp_name which may be computed at run
time, will yield the values that smail would compute
normally. For example, on my workstation, the command:
smail -bP hostnames max_message_size
produces the output:
futatsu.uts.amdahl.com
102400
With the -v or -d flag the variable names are displayed
as well, so that the command:
smail -bP max_message_size
produces the output:
max_message_size=1024000
In addition to other config file variables, the name
primary_name will output the primary (or canonical)
name for the local host which will be used by smail,
and config_file will output the name of the primary
configuration file. Also the name help will produce a
verbose listing of all variables associated with their
type, one variable per line, and the name all will
produce a verbose listing of all variables along with
their values. It is equivalent to smail -bP -v
followed by a list of the names of all configuration
variables.
-bR Enter the hostile mail domain of giant mail messages,
and RFC standard scrolls. Attempt to make it down to
protocol level 26 and back.
-bS Read SMTP commands on standard input, but do not pro-
duce SMTP replies on standard output. All failures are
reported by return mail, rather than through reply
codes. This is suitable for setting up a batched form
of SMTP between machines over a remote execution ser-
vice like UUCP. This is the default mode of operation
if invoked as rsmtp.
-bs Read SMTP commands on standard input and produce SMTP
replies on standard output. The currently implemented
SMTP commands are HELO, MAIL FROM, RCPT TO, DATA, RSET,
NOOP, VRFY, EXPN and QUIT. This is the default mode of
operation if invoked as smtpd. For compatibility with
some implementations of inetd(8N), if smtpd is started
with no standard output, standard input will be
dup(2)'d to standard output.
-bt Enter address test mode. Read addresses on standard
input and produce the parse results and host
routing/resolving information on standard output. This
is primarily useful for debugging smail or debugging
new smail routers.
-bv Verify a list of addresses by producing the list of
addresses produced by aliasing and forwarding expan-
sions and by host routing or resolving. Addresses
which cannot be resolved are also displayed, along with
the reasons why.
-C filename
Sets the name of the config file to use in reading glo-
bal attribute values. If specified, then smail sets
the effective uid and gid back to the real uid and gid,
to avoid problems when installations allow smail to be
set uid to the superuser. If the filename is - then no
primary config file is read. This should only be used
for debugging purposes.
-d[number] or -v[number]
turn on debugging. If a number is given, set the
debugging level to that value, otherwise the debugging
level is set to 1. No white space is allowed before
the optional number.
-em or -oem
Mail errors back to the sender (default).
-ee or -oee
These forms refer to a berkenet error processing style
which is not supported. If used, errors will be mailed
back to the sender.
-ep or -oep
Write errors to the standard error output.
-eq or -oeq
Do not send notification of errors to the sender.
-ew or -oew
Write errors to the senders terminal using the write(1)
command, if he is logged in. Otherwise, mail errors
back to the sender. (This is currently not supported
and is treated in the same manner as -oem)
-F fullname
Explicitly set the full name of the sender for incoming
mail, used only if the operation mode is reception of a
single mail message on standard input.
-f sender or -r sender
Explicitly set the sender address for incoming mail,
used only if the operation mode is reception of a sin-
gle mail message on standard input.
-h number
Sets the hopcount for a single message. If this is not
specified, the hop count is computed from the number of
Received: fields in the message header. The hopcount
is used for a primative form of infinite loop detec-
tion: a sufficiently large hop count will cause mail to
be rejected.
-I or -oI
Use the hidden dot algorithm in reading the message.
Lines with one or more dots at the beginning have the
leading dot removed, while a line containing only a
single dot ends the input message. This is always set
for messages received using SMTP.
-i or -oi
Do not allow a single `.' to end an incoming message.
Otherwise, a dot on a line by itself will end a mes-
sage. This is the default if smail is invoked as
rmail.
-m or -om
Allow retention of the sender as a recipient for alias
and mailing list expansions that include the sender.
If this is Not set, the sender will not receive a copy
of the message only as a result of being in an alias or
mailing list.
-N Disable deliver of this message. All other processing
is performed, and transports are expected to go through
most of the steps involved in delivery. This is useful
for debugging smail when you do not actually wish to
have messages delivered.
-n Do not perform alias processing. This only prevents
expansion of entries in alias files. Mailing list
files and forward files may still be expanded.
-odb Deliver mail in background, if mail delivery is to be
performed. Background delivery is not currently sup-
ported in the SMTP modes; foreground delivery is used
instead.
-odf Deliver mail in foreground, if mail delivery is to be
performed.
-oD director-file
Sets the pathname of the director file. This overrides
the default name of the director file as well as any
name set in a config file. If specified, then smail
sets the effective uid and gid back to the real uid and
gid, to avoid problems when installations allow smail
to be set uid to the superuser. If the filename is -
then no director file is read. This should only be
used for debugging purposes.
-oL directory-name
Sets the pathname of the smail library directory. This
overrides the default value of smail_lib_dir compiled
into the smail binary, as well as any name set in a
config file. This string may be used to locate
configuration files, such as the director, router and
transport files, alias and path files, and mailing list
directories.
-oR router-file
Sets the pathname of the router file. This overrides
the default name of the router file as well as any name
set in a config file. If specified, then smail sets
the effective uid and gid back to the real uid and gid,
to avoid problems when installations allow smail to be
set uid to the superuser. If the filename is - then no
router file is read. This should only be used for
debugging purposes.
-oT transport-file
Sets the pathname of the transport file. This
overrides the default name of the transport file as
well as any name set in a config file. If specified,
then smail sets the effective uid and gid back to the
real uid and gid, to avoid problems when installations
allow smail to be set uid to the superuser. If the
filename is - then no router file is read. This should
only be used for debugging purposes.
-Q or -odq
Spool incoming messages but do not actually perform
delivery until a later queue. This mode of operation
is somewhat more efficient in terms of CPU usage,
though it does slow down the flow of mail.
-q[interval]
Cause smail to process its input spool directory. If
an interval is given, smail will repeatedly check its
input spool directory, sleeping for the given interval
between checks. The interval is in seconds, though it
can be defined as a sequence of numbers with suffixes
of `s' for seconds, `m' for minutes, `h' for hours, `d'
for days, `w' for weeks and `y' for years. For exam-
ple, -q2h30m specifies an interval of two hours and 30
minutes. This flag is useful in conjunction with the
-bd mode of operation and will cause the daemon process
to wake up on these intervals and perform queue pro-
cessing. Performing a single queue run is the default
mode of operation if smail is invoked as runq.
-t Extract addresses from the To:, Cc: and Bcc: fields of
the message header, if the operation mode is reception
of a single mail message on standard input. This is
useful for user agents that do not wish to compute the
recipient addresses themselves. In this mode, any
addresses given on the command line are addresses that
explicitly will NOT receive mail, even as a result of
aliasing or forwarding expansions.
-V or -bV
Print the smail version on the standard output.
In the normal mode of operation (sending mail without the -t
option set), recipient addresses are taken from the remainder
of the arguments.
Section 9.6.2: Miscellaneous invocation names.
Some invocation names affect the default operation mode for
smail. Additionally one invocation name (rmail) limits the
set of allowed argument.
If invoked as `mailq', the default mode of operation is to
print the input queue (is if invoked as smail -bp).
If invoked as `runq', the default mode of operation is to
process the input queue once and do nothing else.
If invoked as `rmail', the arguments -d, -v, -V, -N, -C, and
-q are ignored. The invocation name `rsmtp' is similar to
`rmail', except that the mode of operation will be batched
SMTP.
If invoked as `smtpd', then the default mode of operation is to
process interactive SMTP commands. This invocation name is useful
when using smail to process incoming requests received by the
4.3BSD or sun /etc/inetd programs. For compatibility with the sun
inetd program, stdin is dup(2)'d to stdout if no valid file
descriptor exists on stdout.
If the program is invoked as ``uupath'' then display on the
standard output the route to hosts given as arguments, from
the pathalias database. See the part titled ``Utilities'' for
information on the accepted arguments.
If invoked as ``pathto'', addresses given as arguments are
converted to routed !-routes to their destinations and
displayed on standard output. See the part titled
``Utilities'' for information on the accepted arguments.
If invoked as ``optto'', operate as in pathto but optimize
paths given by the user, instead of doing simple routing on
the first target host. See the part titled ``Utilities'' for
information on the accepted arguments.
If invoked as ``rogue'' or ``hack'' print a tombstone.
Other invocation names are reserved for future abuse.
\f