|
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: 27907 (0x6d03)
Types: TextFile
Names: »part.8«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z«
└─⟦bcd2bc73f⟧
└─⟦this⟧ »design/part.8«
Part 8: Delivery.
Once the <next_host>, <next_address> pairs are known for all
remote recipients of an address, and the transports are known,
it is time to deliver the message to the remote recipients.
The files and procedures defined in the following sections are
used in doing this delivery.
Section 8.1: The transport file.
The transport file describes the use of transport drivers and
assigns names to each transport entry that can be referenced from
routers, method files and directors. Its format follows the
standard described in Part 5.
The following list defines the current set of generic attributes
available for transport file entries:
bsmtp
type: boolean
Use a batched SMTP format, where the message is
enclosed in an envelope of SMTP commands. This is not
the same format commonly used on BITNET, as it does not
contain FORTRAN carriage control characters. This can
be used to send mail to remote hosts using SMTP formats
even when direct two-way connections are not feasible.
For example, this will work over UUCP and eliminates
difficulties with sending arbitrary addresses as argu-
ments to UUX.
crlf
type: boolean
If set, then each line of the header and message will
end in carriage-return/line-feed rather than a single
newline character. This is not typically useful, as
the SMTP transport, which requires this as a part of
the interactive protocol always does this anyway.
debug
type: boolean
If set, replaces the body of the message with debugging
information. This can be used, for example, as a sha-
dow transport to watch the flow of mail for a while for
debugging purposes. This essentially allows for debug-
ging without the ethical and space problems of saving
the personal correspondence of others.
dots
type: boolean
If set, then use the hidden dot protocol. All output
lines which begin with dot will have one more dot
prepended. All of the various SMTP modes imply this
behavior.
driver
type: string
The driver attribute names a specific set of low-level
functions which will do the work of delivering mail.
This attribute is always required.
error_transport
type: string
names another transport that the message should be sent
to, if the first transport returns failure.
from
type: boolean
If set, then supply a ``From<space>'' line before the
message when delivering with this transport. If this
is a remote transport (i.e., the local attribute is not
turned on) then this line will end with ``remote from
hostname'' where hostname is the UUCP name for the
local host. This is useful for delivery over UUCP and
for delivery to standard mailbox files, which require
this format.
hbsmtp
type: boolean
``Half-baked'' batched SMTP. This is batched SMTP mode
without an initial HELO command or an ending QUIT com-
mand. This can be used for creating files which will
be concatenated together at a later time to form one
batch of SMTP commands containing multiple messages.
local
type: boolean
If set, the form of the header and envelope information
will be setup for delivery to the local host. This
performs no changes to existing header fields, other
than insertion of commas into fields containing sender
and recipient addresses. This also affects the form of
any generated ``From<space>'' line and the form of
envelope addresses used in SMTP commands.
max_addrs
type: number
This states the maximum number of recipient addresses
that can be given in one call to the transport. If
this is turned off then there is no maximum number.
The default number is 1 and typically this is either
left as 1 or turned off.
max_chars
type: number
This states the maximum number of characters in reci-
pient addresses that can be given in one call to the
transport. If this is turned off then there is no max-
imum number. The default number is about one third of
the number characters that can be passed as arguments
to a program. When using SMTP transports this should
be turned off unless a remote host is known to be
unable to handle a large number of addresses. For
delivery over UUCP to a remote rmail program, this
should be around 200 or 250, to avoid buffer overruns
at the remote site. UUCP generally has small buffers
to hold argument information.
If smail is given an address whose length exceeds this
number, then the address will be passed with one call
to the transport. Thus, this limit is not strictly
enforced.
max_hosts
type: number
This states the maximum number of different hosts that
can be given in one call to the transport. If this is
turned off, using the form -max_hosts then there is no
maximum number. The default number is 1 and typically
this is not changed.
received
type: boolean
If set, then a Received: field is inserted for mail
being delivered with this transport. The form of this
field is taken from the received_field attribute in the
config file. This attribute is on be default.
return_path
type: boolean
If set, then a Return-Path: field is inserted for mail
being delivered with this transport. The form of this
field is taken from the return_path_field attribute in
the config file. This should only be used for tran-
sports which perform final delivery to local destina-
tions.
shadow
type: string
This names another transport that the message should be
sent to. This could be used to, for example, start a
program that looked up the sender in a database and
brought up a rendition of his face from a face server
in a window on your workstation. The shadow transport
is called only if the primary transport successfully
performs delivery.
strict
type: boolean
If this flag is set, then some effort is done to
transform mail which does not conform to RFC822 stan-
dards. This is potentially useful for sites which
gateway between the UUCP zone and the Internet. In
general, it is not a good idea to turn this on as it
changes the contents of headers fields. This should
only be done when it is known that some remote hosts
only understand mail which conforms to the RFC822 stan-
dard.
unix_from_hack
type: boolean
If set then any line in the body of the message which
begins with ``From '' will have the character `>'
inserted at the beginning. This is required for local
delivery to mailbox files that are in the standard form
expected by the System V mailx (1) and the BSD Mail (1)
programs.
uucp
type: boolean
If set then outgoing recipient addresses will be con-
verted into UUCP-style paths of the form
hosta!hostb!hostc!user. An exception is that any use
of `%' as an address operator is preserved. Thus, an
envelope address of user%hostb@hosta would be converted
to hosta!user%hostb. This only affects envelope
addresses and does NOT affect the message or the mes-
sage header.
Section 8.2: Skip this section.
All this just to avoid having to renumber section numbers!
Section 8.3: Sample transport file.
The following is a sample transport file that will be used
by examples in the following sections.
# @(#)/usr/lib/smail/transports 8.4 1/12/88 25:03:17
# perform local deliver by appending to user mailbox files
local:
# generic transport attributes:
driver=appendfile,
local, # local form for header and envelope
from, # supply a From_ envelope line
returnpath; # supply a Return-Path: field
# driver-specific attributes:
file=/usr/spool/mail/${lc:user}, # BSD/V7 mailbox directory
check_user, # user cannot contain `/' character
mode=0600, # only allow access by the recipient
unix_from_hack, # put > in front of From's in text
suffix="\n" # mailboxes require one extra newline
# deliver to local files
# Note: local-form addresses that specify files as recipients
# are delivered using this transport.
# treat these very much like user mailbox files
file:
# generic transport attributes:
driver=appendfile,
local, # local form for header and envelope
from, # supply a From_ envelope line
returnpath; # supply a Return-Path: field
# driver-specific attributes:
file=$user, # the address specifies the filename
suffix="\n", # mailboxes require one extra newline
check_path, # make sure user can write to file
expand_user, # expand $user before filename
mode=0664, # mode will not allow everyone to write
unix_from_hack, # put > in front of From's in text
suffix="\n" # mailboxes require one extra newline
# deliver to local shell commands
# Note: local-form addresses that specify shell commands
# as recipients are delivered using this transport.
pipe:
# generic transport attributes:
driver=pipe,
local, # local form for header and envelope
from, # supply a From_ envelope line
-log_output, # don't log the shell-command output
returnpath; # supply a Return-Path: field
# driver-specific attributes:
cmd="/bin/sh -c $user", # send address to the bourne shell
umask=022, # file creation for child process
parent_env, # put values from parent addr in env
unix_from_hack, # put > in front of From's in text
ignore_status, # ignore non-zero exitcodes
ignore_write_errors # ignore failed writes on pipes
# send to uux, queuing the message instead of starting
# uucico immediately
uux:
# generic transport attributes:
driver=pipe,
uucp, # uucp form for header and envelope
-max_addrs, # no limit of recipients passed
max_chars=200, # but limit of 200 chars per invokation
from; # supply a From_ envelope line
# driver-specific attributes:
cmd="/usr/bin/uux - -r -g$grade $host!rmail $(($addr)$)",
pipe_as_sender
# deliver over uux, but don't queue unless you cannot
# immediately connect
demand:
# generic transport attributes:
driver=pipe,
uucp, # uucp form for header and envelope
-max_addrs, # no limit of recipients passed
max_chars=200, # but limit of 200 chars per invokation
from; # supply a From_ envelope line
# driver-specific attributes:
cmd="/usr/bin/uux - -g$grade $host!rmail $(($addr)$)",
pipe_as_sender
# deliver mail by sending batched SMTP commands over UUCP.
uusmtp:
# generic transport attributes:
driver=pipe,
bsmtp, # send batched SMTP commands
-max_addrs, -max_chars; # no limit on passed recipient addrs
cmd="/usr/bin/uux - -g$grade $host!rsmtp",
pipe_as_sender
Section 8.4: Calling transports.
When <next_host>, <next_address> and the transport are known
for all recipient addresses of a message, then we can begin
to work on message delivery.
Section 8.4.1: Grouping into transport instances.
Given the list of all addresses tied to transports, we need
to group this list into lists tied to specific instances
a transport. Instances should be setup so that the number
of non-unique <host_host> values does not exceed `maxhosts'
as defined in the transport database, and the total number
of addresses does not exceed `maxaddr'. We will call the
list of instances formed <instance_list> where each instance
has an associated <instance_addresses> list grouped by
<next_host> into lists called <instance_host_addresses>.
Section 8.5: The transport drivers.
The following sections list the currently available transport
drivers.
Section 8.5.1: The pipe driver.
The pipe driver is the most general form of transport. Its
job is to send mail messages to another program, such as uux
or the bourne shell. The driver attributes for the pipe
driver are:
cmd
type: string
The program to be run and the arguments to be passed.
This is string expanded. To handle multiple addresses
being given to a transport, the use of $( and $) can be
used to bracket a section of the command string which
is to be repeated for each address given to the tran-
sport. It is a configuration error for string expan-
sion to fail.
defer_child_errors
type: boolean
Generally, only child failures from the signal SIGTERM
are reattempted at a later time. If this is set, then
retries are performed at a later time if the exit code
is non-zero, or if the write failed on the pipe. This
is useful for treating errors from UUCP as configura-
tion or as temporary filespace problems.
group
type: string
The name of the group to setgid(2) to within the child
process. Useful only if the mailer is running as root.
ignore_status
type: boolean
If set, the exit status of the child process is
ignored. If this is not set, an exit value other than
0 is noted and mail is sent to the postmaster stating
this.
ignore_write_errors
type: boolean
If set, write errors are ignored. This is useful for
running programs that may not actually read their stan-
dard input. If this is not set, a write error will
cause mail to be returned to the sender.
log_output
type: boolean
The stdout and stderr of a command are logged and
returned to the sender in case of problems. The
current implementation is not very good as it actually
returns the logs for all such transports in the event
that any transports fail. This attribute is on by
default.
parent_env
type: boolean
Stuff the environment with data taken from the parent
of the input address, rather than the input address
itself. This is useful for the transport specifically
named pipe which is used by smail for delivery to
shell-command addresses. Here the recipient address
stored into the environment will then be the address
that produced the shell-command address, rather than
the shell-command address itself.
pipe_as_sender
type: boolean
If set, the child process' uid is taken from the real
uid at the time the message was read by smail. This
does not affect the group id for the child. This over-
rides the uid obtained from the pipe_as_user attribute.
pipe_as_user
type: boolean
Obtain a uid and, if `group' attribute is not given, a
gid associated with the address (such as the user for a
.forward file). Then set these via setuid(2) and set-
gid(2) in the child process.
NOTE: This attribute is on by default.
umask
type: number
file creation mask for the child process.
user
type: string
The name of the user to setuid(2) to within the child
process. Useful only if the mailer is running as root.
Section 8.5.1.1: Generating the command line.
This section defines how the `cmd' attribute is used to
produce the command which is actually exec'd in the child
process by the pipe driver.
Given <instance_list>, let <transport> be the associated
transport for each element in turn, and let <cmd_line> be
the associated `cmd' entry for the <transport>. We shall
build up the command line <cmd> for the transport call as
follows:
1. If there is only one of <instance_addresses>, copy
<cmd_line> to <cmd> replacing any occurrences of
$host and $addr with <next_host> and <next_address>
respectively. Replace any occurrences of $( and $)
with <NULL>.
2. If there is only one list <instance_host_addresses> (i.e.,
only one <next_host> is associated with the entry in
<instance_list>) then copy <cmd_line> to <temp> replacing
any occurrence of $host with <next_host>. There
should be occurrences of $addr between $( and $) pairs.
Form a list <replace_list> with a member for each
<next_address> in <instance_host_addresses> such that
each member is the string between $( and $) pairs with
$addr replaced by <next_address>. Then copy <temp>
to <cmd> replacing the text between $( and $) with the
strings in <replace_list>
3. In the general case of several <next_host> values for
an entry in <instance_list>, $host and $addr should
only occur between $( and $) pairs. Copy <cmd_line>
to <cmd> replacing all text between $( and $) pairs with
that same text where <next_host> and <next_address> values
are substituted for $host and $addr respectively.
In summary, the substitutions specific to commands are:
$( begin a per address replacement list
$) end a per address replacement list
Other command-line substitutions are described in Section 5.2.
Examples:
If a transport with a cmd attribute of:
cmd = "/path/send -f $sender -h $host $(-u $user$)
were given a list of <next_address> values:
Jane.Doe
Milo.Bloom@BloomPicayune.COM
x!y!z
The generated command might be:
/path/send -f Steve.Dallas -h BordingHouse.ORG
-u Jane.Doe
-u Milo.Bloom@BloomPicayune.COM
-u x!y!z
Section 8.5.1.2: The child process environment.
The environment of the child process is entirely initialized
and loaded with variables which may be useful in shell scripts
or intelligent mail processing programs. Exactly one
environment variable is passed through from the environment
handed to the smail program, the TZ variable defining the
timezone. The following portion of the environment is
independent of the recipient addresses:
BASENAME the basename for the spool file
GRADE the grade character
MESSAGE_ID the message ID as assigned by smail
PATH ``/bin:/usr/bin''
PRIMARY_NAME the official name for the host
SENDER the sender address
SHELL ``/bin/sh''
SPOOL_FILE the complete name for the spool file
UUCP_NAME the name for the host on the uucp network
VISIBLE_NAME the name for the host used in addresses
The rest of the environment is loaded from the input address,
or from the parent of the input address:
ADDR The recipient address (or one of the recipient
addresses, if more than one is given to the
driver).
HOME The home directory (or one of home directories,
if more than one recipient address is given to
the driver). If no home directory is associ-
ated with an address, ``/'' is used.
append_as_user
type: boolean
Get the uid and, perhaps, the gid from the user id and
group id associated with the address. For example, the
user associated with a forward file might be used.
This attribute is on by default.
check_path
type: boolean
If set, then verify the permissions on a complete path
for a file or dir attribute. This requires that all
directories leading to a file must be searchable by the
appending user (see the user, group and append_as_user
attributes). Under System V, this requires a stat(2)
call for each directory in the path, and is thus some-
what expensive.
check_user
type: boolean
Reject an address if the $user would contain a `/'.
This prevents a $user expansion from accessing a dif-
ferent directory.
dir
type: string
Defines a directory in which to write unique files.
Files written to this directory always begin with the
letter `q', while temporary files used in the creation
process begin with ``temp.'' This string is expanded
similarly to the file attribute. It is a configuration
error for this string expansion to fail.
expand_user
type: boolean
If set the value for $user value is string expanded
before the value for the file or dir attribute is
expanded. This is useful if a local-form address may
require `~' or `$' expansions.
file
type: string
Defines a file to append messages to. This string is
expanded, and the variables $user and $host are set
from the recipient address. It is a configuration
error for this string expansion to fail.
group
type: string
become this group. Similar to the user attribute.
mode
type: number
When creating a file, creat(2) it with this access
mode. The default is 0666.
prefix
type: string
This prefix is inserted in the file before the message.
This string is expanded, with $user and $host being
available from the recipient address. It is a confi-
guration error for this string expansion to fail.
suffix
type: string
This suffix is appended to the file after the message.
This string is expanded, with $user and $host being
available from the recipient address. It is a confi-
guration error for this string expansion to fail.
user
type: string
This become this user (effectively at least) when open-
ing or creating the file. Access permissions are
checked relative to this user, and the user will own
the file if it did not previously exist.
To better understand the use of some of these attributes,
consider the transport file entry:
file: driver=appendfile, from, received, returnpath, local;
file=$user, suffix="\n", check_path,
expand_user, append_as_user, mode=0664
This transport will be called when a file-form address is
produced by a director. If the forwardfile director produced
the address, a user ID and group ID may be associated with it.
If the aliasfile director produced, there will not be a user ID
or group ID associated with it.
When given a next_addr of ~/Incoming, with an associated
home directory of /u/joe-user and an associated user of
joe-user, the following steps occur:
a. next_host is expanded to /u/joe-user/Incoming.
b. the `file' attribute is also expanded to /u/joe-user/Incoming.
c. The directories `/', `/u' and `/u/joe-user' are checked
for accessibility by the user `joe-user'. If any of these
is not searchable, then delivery fails.
d. The file /u/joe-user/Incoming is opened for append access.
If it did not exist, it is created and will be owned by
`joe-user' and will have mode 0664.
e. The message is written with a local-form From_ line.
f. An extra newline is appended to the file, after the
message.
NOTE: smail will follow the local conventions on locking
protocols for mailbox files, which may involve creating
a .lock file or using an file lock system call.
Next, lets examine:
local: driver=appendfile, local, from, received, returnpath;
file=/usr/spool/mail/$user, append_as_user, check_user,
mode=0600
In this example, the next_addr is not expanded before expanding
the file attribute. Also, just to make sure, the next_addr is
verified to not contain a `/'. Given an input address of
`jane-doe', associated with the user `jane-doe', the file
`/usr/spool/mail/jane-doe' will be appended to. If it did not
previously exist, it will be owned by `jane-doe' and will have
mode 0600.
As an example of using this driver for simle queuing, consider:
queue_to_remote:
driver=appendfile, received, strict, hbsmtp, crlf,
-max_addrs, -max_chars;
dir=/usr/spool/smtpq, prefix="DEST<$host>\r\n"
This driver will create files in the directory /usr/spool/smtpq,
one file per message. Each file will be given a unique basename
and will be begin with the destination hostname in the form of a
pseudo smtp command. The message itself will have an envelope of
SMTP commands. There are no limits on the number of addresses
passed to a single invocation of the driver.
For example, it might create a file of:
DEST<jupiter.berkeley.edu>
MAIL FROM:<@sun.com:tron@uts.amdahl.com>
RCPT TO:<"John Public"@jupiter.berkeley.edu>
RCPT TO:<@jupiter.berkeley.edu:rms@saturn.berkely.edu>
DATA
Received: by uts.amdahl.com (smail /\--/\ 3.1);
id <A38a878-382a87C@uts.amdahl.com>
From: tron@uts.amdahl.com (Ronald S. Karr)
To: "John Public"@jupiter.berkely.edu
Subject: 2001 a space odyssey
Cc: <@jupiter.berkeley.edu:rms@saturn.berkely.edu>
So why did 2001 go to Saturn via Jupiter, while the
movie only went to Jupiter?
tron |-<=>-|
.
This file can then be picked up later by a separate program to
actually deliver the message to jupiter.berkeley.edu. For
example, this can be used in environments where only rudimentary
file transfer is possible between systems.
Section 8.5.3: The smtp driver.
Simple support exists in smail for delivery using SMTP over
TCP/IP. It is intended that eventually a complete smail
backend will exist to handle SMTP in a more efficient manner,
though in the mean time a built-in SMTP transport driver is
available.
The smtp driver accepts can be used for delivery of any number
of addresses to one remote host, where the remote host can be
specified either in form of a hostname known by the networking
software or by an internet number in square brackets, such as
[192.2.12.89]. For example, the routing drivers gethostbyaddr
and gethostbyname are suitable for matching addresses to be
delivered using the smtp driver.
The smtp driver currently has no attributes, and always
connects to the port associated with the `smtp' service from
the /etc/services file (generally port 25).
The smtp driver attempts to connect immediately and delivery a
single message. If access to the remote host is currently not
possible, the driver will tell smail that delivery should be
attempted at a later time.
An example of the use of the smtp driver is the entry:
# deliver using SMTP over TCP/IP to the remote host
smtp: -max_chars, -max_addrs, driver=smtp
If your site is on the Internet and gateways from the UUCP
zone, it may be reasonable to set the `strict' attribute.
Otherwise, this is probably not a good idea.
If the `local' attribute is not set, then the envelope sender
address passed to the remote host will always contain the
primary name for the local host, while the recipient addresses
passed in the envelope will always be in RFC822 mailbox form
or route addr form. This is in keeping with the RFC821 SMTP
standards document.
\f