Chapter 17. Smtpserver

Table of Contents
17.1. Smtpserver Runtime Parameters
17.2. Smtpserver Configuration
17.3. policy-builder.sh utility
17.4. Policy Filtering Language

The ZMailer distribution contains an smtpserver program for the BSD socket implementation of TCP/IP. It is an asynchronous implementation, in that while address syntax is checked in real time, semantics are not, nor are other (optional in the SMTP standard) functions that require router functionality.

The server will run an RFC-821 syntax scanner for addresses, plus possible policy analysis phase, and if things are ok, it says ``Yes yes, sure!'' to everything. The program may also be used in non-daemon mode to unpack BSMTP format messages on the standard input stream.

This program implements the server side of the SMTP protocol as described in RFC821, and knows about the common extensions to the protocol expected by sendmail and BSMTP clients. By default the program will kill the previous smtpserver daemon, if any, then detach and listen for SMTP connections. Incoming messages will be submitted for processing using the zmailer(3) interface to ZMailer. Some non-trivial address checking is doable in optional policy analysis functions within the smtpserver, or can be acomplished with synchronous (or asynchronous) running of router. This behaviour can be changed by a command line option (or HELO/EHLO style patterns) if you cannot afford to transfer data just to bounce it back.

All router assisted checking is done by executing the router(8) program in interactive mode, and executing well-known shell function with well-known parameters for each request.

The server implements also most of the ESMTP facilities invented up to date (Feb, 2000). The ones that are active are visible at greeting response to ``EHLO'' command, as can be seen in figure Figure 17-1.

Figure 17-1. Sample ``EHLO'' greeting with smtpserver

$ telnet 127.1 smtp
Connected to 127.1.
Escape character is '^]'.
220 localhost ZMailer ....
EHLO foo
250-localhost expected "EHLO localhost"
250-SIZE 1234567
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-ENHANCEDSTATUSCODES
250-EXPN
250-VRFY
250-DSN
250-X-RCPTLIMIT 10000
250-ETRN
250 HELP
...

17.1. Smtpserver Runtime Parameters

Usage:

smtpserver [-46aginvBV] [-p port] [-l logfile] [-s 'strict'] [-s [ftveRS]] [-L maxloadaver] [-M SMTPmaxsize] [-P postoffice] [-R router] [-C cfgfile]

Parameters:

-4

Explicitly use IPv4 type of socket even on machines that are capable to do IPv6 type of sockets.

-6

Explicitely (try to) use IPv6 type of socket even if the machine does not support it. By default the server will try to use IPv6, if it has been compiled in an environment where it is present, but will fall back to IPv4, if the runtime system does not have IPv6.

-8

This option is part of optional inbound translate processing; see ``-X'' option below.

-a

Turn on RFC931/RFC1413 identification protocol, and log the information acquired with it into the submitted file. Reliability, validity, worthwhileness, ... all such are suspect at this.

-B

Flags the email to arrive via BSMTP channel (via BITNET, for example).

-B cfgfile

Specifies nonstandard configuration file location; the default is $MAILSHARE/smtpserver.conf.

-d nnnn

This option sets numeric debug value. Any non-zero will work. This numeric argument is provision for possible bit-flag or level oriented debugging mode….)

-g

The ``gullible'' option will make the program believe any information it is told (such as origin of a connection) without checking.

-h

Check ``HELO'' parameter very closely (syntax), and if it is bad, complain with ``501''. Such behaviour is against interoperability minded ``Be lenient on what you accept'' policy, and apparently will break a lot of common clients….

-i

Runs the server interactively, which makes it usable for processing a batched SMTP stream (BSMTP) on stdin. With ``-v'' option this echoes incoming BSMTP to create more accurate faximile of BITNET BSMTP mailers.

-L maxloadaver

The maximum load-average the system is under when we still accept email.

Not all systems are supported for load-aver extraction; and as that information happens to be very poorly extractable without major magics, it is our considered opinnion that it is better to spend time to figure other methods for limiting incoming email induced load impact, than trying to see any load-average — anyway the ZMailer smtpserverused without interactive routing is very low load inpact system.

-l 'SYSLOG'

Specifies that incoming SMTP conversations are logged via syslog(3) to system syslogd(8) server by using facility LOG_MAIL and level LOG_DEBUG messages.

-l LOGFILE

Specifies a logfile and enables recording of incoming SMTP conversations to go there.

This can be used in parallel with -l 'SYSLOG' version!

-M SMTPmaxsize

Defines the absolute maximum size we accept from incoming email. (Default: infinite) (This is a local policy issue.)

-n

Indicates the program is being run from {\em inetd(8)}.

-P postofficedir

Specifies an alternate $POSTOFFICE/ directory.

-P port

Specifies the TCP port to listen on instead of the default SMTP port: 25.

-R routerpath

Specifies an alternate router(8) program to use for address verification.

-s 'strict'

This turns server protocol processing into extremely strict mode, any misplaced character is rejected. Not very practical in real file, but nice for protocol interoperability bakeout testing.

-s 'strict'

Specifies the style of address verification to be performed. There are four independent commands that can invoke some kind of address verification, and four independent flags to control whether this should be done.

They are:

f

Run ``MAIL FROM'' address through online router for analysis.

t

Run ``RCPT TO'' address through online router for analysis.

v

Enable ``VRFY'' command for this style selector (if configuration ``PARAM vrfycmd'' is in effect)

e

Enable ``EXPN'' command for this style selector (if configuration ``PARAM expncmd'' is in effect)

R

Require incoming addresses to be of fully-qualified domained form.

Don't use this if you want to allow non-domained addresses accepted into your server through SMTP.

S

Allow ``Sloppy'' behaviour from the sending smtp clients; namely allow ``MAIL FROM:foo@bar'', that is, an addresses without mandatory (RFC-821) angle braces.

The flags are concatenated to form the argument to the ``-s'' option. The default is ``ve''.

-S suffixstyle

This defines log suffix which can alter the default logfile name to one which splits incoming traffic into separate files.

Possible values are:

'remote'

Append remote hostname to the logfile name (after a dot) so that from host ``foo.bar.edu'' the logfile would be: ``smtpserver.foo.bar.edu''.

'local'

Append local end reversed hostname to the logfile name (after a dot) so that in multihomed hosts all different ``hosts'' have different logfiles. Such does, of course, assume that different IP addresses in the host reverse to different names.

-v

This is a ``verbose'' option to be used with ``-i'' option. This is especially for ``BSMTP'' processing.

-V

prints a version message and exits.

-X

This is ``Xlate'' option. For more info, see source file:

 

``It may be necessary in some cases (e.g. in Cyrillic-language countries) to translate charset on the messages coming from the clients with, e.g. old Eudora or other MUAs that do not correctly support koi8-r charset.  …''

 
--README.translation 

17.2. Smtpserver Configuration

If the $MAILSHARE/smtpserver.conf file exists it is read to configure two kinds of things. Specifically the following:

PARAM -entries

Allow server start-time parametrization of several things, including:

  • system parameters

  • help texts

  • acceptance/rejection database definitions

The style (-s) options

Behaviour is based on glob patterns matching the HELO/EHLO name given by a remote client. Lines beginning with a ``#'' or whitespace are ignored in the file, and all other lines must consist of two tokens: a shell-style (glob) pattern starting at the beginning of the line, whitespace, and a sequence of style flags. The first matching line is used.

As a special case, the flags section may start with a ``!'' character in which case the remainder of the line is a failure comment message to print at the client. This configuration capability is intended as a way to control misbehaving client software or mailers.

17.2.1. Smtpserver configuration; PARAM -entries

PARAM maxsize nn

Maximum size in the number of bytes of the entire spool message containing both the transport envelope, and the actual message. That is, if the max-size is too low, and there are a lot of addresses, the message may entirely become undeliverable..

This sets system default value, and overrides commandline ``-M'' option.

PARAM max-error-recipients nn

In case the message envelope is an error envelope (MAIL FROM:<>), the don't accept more than this many separate recipient addresses for it. The default value is 3, which should be enough for most cases. (Some SPAMs claim to be error messages, and then provide a huge number of recipient addresses… Of course as spam-spewers learn, they begin just sending single recipients per message — less efficient, but working still…)

PARAM MaxSameIpSource nn

(Effective only on daemon-mode server — not on ``-i'', nor ``-n'' modes.) Sometimes some systems set up multiple parallel connections to same host (qmail ones especially, not that ZMailer has entirely clean papers on this either — at least up to 2.99.X series), we won't accept more than this many connections from the same IP source address open in parallel.

The default value for this limit is 10.

The principal reason for this has been authors experience at nic.funet.fi, where some MS-Windows users have caused huge numbers of parallel connections to some services. So huge, that the system did in fact run out of swap due to that, and caused all manner of other nasty things to occur too… All this simply because some windows client had opened 800+ parallel sessions, and each server process consumed separate blocks of swap space… To avoid the system to succumb under such an accidental denial-of-service attack at the overall system, this parallel limit was created.

PARAM TcpRcvBufferSize nn

This sets setsockopt(SO_RCVBUF) value, in case the system default is not suitable for some reason.

PARAM TcpXmitBufferSize nn

This sets setsockopt(SO_SNDBUF) value, in case the system default is not suitable for some reason.

PARAM ListenQueueSize nn

This relates to newer systems where the listen(2) system call can define higher limits, than the traditional/original 5. This limit tells how many nascent TCP streams we can have in SYN_RCVD state before the socket stops answering to incoming SYN packets requesting opening of a connection. Such sockets have not opened sufficiently to reach a state where bi-directional communication has been established, thus they won't appear to accept(2) yet for the server to pick them up!

There are entirely deliberate denial-of-service attacks based on flooding to some server many SYNS on which it can't send replies back (because the target machines don't have network connectivity, for example), and thus filling the back-queue of nascent sockets.

This can also happen accidentally, as the connectivity in between the client host, and the server host may have a black hole into which the SYN-ACK packets disappear, and the client thus will not be able to get the TCP startup three-way handshake completed.

Most modern systems can have this value upped to thousands to improve systems resiliency against malicious attacks, and most likely to provide complete immunity against the accidental ``attack'' by the failing network routing.

Do consult your system specific information on how much memory each nascent (and matured) socket will require before you commence upping this very much. You might commit heaps of unswappable memory to useless waste.

PARAM help string

This one adds yet another string (no quotes are used) into those that are presented to the client when it asks for ``HELP'' in the SMTP session.

PARAM debugcmd

Enables ``DEBUG'' command in the server. This command turns on various trace functions which ruin the protocol from standards compliant client, but may help interactive debuggers.

PARAM expncmd

Enables ``EXPN'' command in the server.

PARAM vrfycmd

Enables ``VRFY'' command in the server.

PARAM PolicyDB dbtype dbpath

This defines the database type, and file path prefix to the binary database containing policy processing information. Actual binary database file names are formed by appending type specific suffixes to the path prefix. For example NDBM database appends ``.pag'' and ``.dir'', while BSD-Btree appends only ``.db''. (And the latter has only one file, while the first has two.)

More information below, and at newdb at Section 24.5

PARAM allowsourceroute

When present, this parameter will not convert input of form <@aa,@bb:cc@dd> into source-route-less form of <cc@dd> Instead it carries the original source-route into the system as is.

A possible smtpserver configuration file is shown in figure Figure 17-2.

Figure 17-2. Full-featured smtpserver.conf file example

#
# {\rm{}smtpserver.conf - autogenerated edition}
#
#PARAM maxsize              10000000    # {\rm{}Same as -M -option}
#PARAM max-error-recipients        3    # {\rm{}More than this is propably SPAM!}
#PARAM MaxSameIpSource            10    # {\rm{}Max simultaneous connections from}
#                                       # {\rm{}any IP source address}
#PARAM TcpRcvBufferSize        32000    # {\rm{}Should not need to set!}
#PARAM TcpXmitBufferSize       32000    # {\rm{}Should not need to set!}
#PARAM ListenQueueSize            10    # {\rm{}listen(2) parameter}

# {\rm{}Enables of some commands:}
PARAM debugcmd
PARAM expncmd
PARAM vrfycmd

PARAM help -------------------------------------------------------------
PARAM help  This mail-server is at Yoyodyne Propulsion Inc.
PARAM help  Our telephone number is: +1-234-567-8900, and
PARAM help  telefax number is: +1-234-567-8999
PARAM help  Our business-hours are Mon-Fri: 0800-1700 (Timezone: -0700)
PARAM help
PARAM help  Questions regarding our email service should be sent via
PARAM help  email to address  <postmaster@OURDOMAIN>
PARAM help  Reports about abuse are to be sent to: <abuse@OURDOMAIN>
PARAM help -------------------------------------------------------------

# {\rm{}Uncomment following for not to strip incoming addresses of format:}
# <@aa,@bb:cc@dd>  into non-source-routed base form: <cc@dd>
#PARAM  allowsourceroute

PARAM   accept-percent-kludge # "localpart" can contain '%' and '!'
#PARAM  reject-percent-kludge # "localpart" can't contain  --"--

# {\rm{}The policy database:  (NOTE: See  'makedb'  for its default suffixes!)}
PARAM  policydb   btree  /opt/mail/db/smtp-policy

#
# HELO/EHLO-pattern     style-flags
#               [max loadavg]

localhost           999 ftveR
some.host.domain    999 !NO EMAIL ACCEPTED FROM YOUR MACHINE

# {\rm{}If the host presents itself as:  HELO [1.2.3.4], be lenient to it..}
# {\rm{}The syntax below is due to these patterns being SH-GLOB patterns,}
# {\rm{}where brackets are special characters.}

[*]                 999 ve

# {\rm{}Per default demant strict syntactic adherence, including fully}
# {\rm{}qualified addresses for  MAIL FROM, and RCPT TO.  To be lenient}
# {\rm{}on that detail, remove the "R" from "veR" string below:}

*                   999 veR

17.3. policy-builder.sh utility

The policy database that {\em smtpserver} uses is built with {\tt policy-builder.sh} script, which bundles together a set of policy source files:
  DB/smtp-policy.src   The boilerplate
  DB/localnames        ('= _localnames')
  DB/smtp-policy.relay ('= _full_rights')
  DB/smtp-policy.mx    ('relaytargets +')
  DB/smtp-policy.spam  ('= _bulk_mail')

At the moment, {\tt smtp-policy.spam} source is retrieved with LYNX from
the URL:
\begin{alltt}\medskip\scriptsize\medskip
http://www.webeasy.com:8080/spam/spam_download_table
\medskip\end{alltt}\medskip
however it seems there are sites out there that are spam havens, and
that serve valid spam source/responce domains, which are not registered
at that database.

{\em If you want, you can modify your {\tt smtp-policy.src} boilerplate
file as well as your installed {\tt\small policy-builder.sh} script.}
{\bf In fact you SHOULD modify both to match your environment!}

Doing {\tt make install} will overwrite {\tt\small policy-builder.sh},
but not {\tt smtp-policy.src}.

Basically these various source files (if they exist) are used to
combine knowledge of valid users around us:

\begin{description}
\item[\tt localnames] \mbox{}

Who we are -- ok domains for receiving.

\item[\tt smtp-policy.relay] \mbox{}

Who can use us as outbound relay.

Use  {\em\verb/[/ip.number\verb/]//maskwidth}  here for
listing those senders (networks) we absolutely trust.
You may also use domains, or domain suffixes so that the IP-reversed
hostnames are accepted (but that is a it risky thing due to ease of
fakeing the reversed domain names):

\begin{alltt}\medskip\hrule\medskip
[11.22.33.00]/24
ip-reversed.host.name
.domain.suffix
\medskip\hrule\end{alltt}\medskip

Server sets its internal ``always_accept'' flag at the source IP tests
before it decides on what to tell to the contacting client.
The flag is not modified afterwards during the session.

Usage of domain names here is discouraged as there is no way to tell
that domain ``foo.bar'' here has different meaning than same domain
elsewere -- at ``{\tt smtp-policy.mx}'', for example.

\item[\tt smtp-policy.mx] \mbox{}

Who really are our MX clients.
Use this when you really know them, and don't want just to trust
that if recipient has MX to you, it would be ok\ldots

You can substitute this knowledge with a fuzzy feeling by using
``acceptifmx -'' attribute at the generic boilerplate.
List here domain names. 
\begin{alltt}\medskip\hrule\medskip
 mx-target.dom
 .mx-target.dom
\medskip\hrule\end{alltt}\medskip

You CAN also list here all POSTMASTER addresses you accept email routed to: 

\begin{alltt}\medskip\hrule\medskip
 postmaster@local.domain
 postmaster@client.domain
\medskip\hrule\end{alltt}\medskip

these are magic addresses that email is accepted to, even when everything
else is blocked. 

\item[\tt smtp-policy.spam] \mbox{}

Those users, and domains that are absolutely no-no for senders,
or recipients no matter what earlier analysis has shown.
(Except for those senders that we absolutely trust..)

\begin{alltt}\medskip\hrule\medskip
 user@domain
 user@
 domain
\medskip\hrule\end{alltt}\medskip

The ``{\tt policy-builder.sh}'' builds this file from external sources. 

\end{description}

17.4. Policy Filtering Language

Policy based filter database boilerplate for smtp-server.

File:  {\tt \$MAILVAR/db/smtp-policy.src}

This file is compiled into an actual database using the command:
\begin{alltt}\medskip\hrule\medskip
  \$MAILBIN/policy-builder.sh
\medskip\hrule
\end{alltt}\par


The basic syntax of non-comment lines in the policy source is:
\begin{alltt}\medskip\hrule\medskip
  key  [attribute value]* [= _tag]
\medskip\hrule
\end{alltt}\par

There are any number of attribute-value pairs associated with the key.

There can be only one key of any kind currently active, unless ``{\em makedb}''
is called with ``-A'' option (Append mode) in which case latter appearances
of some keys will yield catenation of of latter data into previous datasets.
(This may or may not be a good idea\ldots)

The key can be any of following forms:
\begin{description}
\item[\rm domain, or .domain.suffix] \mbox{} \\
a domain name optionally preceded by a dot (.)

\item[\rm``user@'', or ``user@domain''] \mbox{} \\
Usernames -- domainless (``user@'') or domainfull.

\item[\rm An IP address in {[}nn.nn.nn.nn{]}/prefix form] \mbox{} \\
Unspecified bits must be 0.
(Network IPv6 addresses containing IPv4-mapped addresses are translated
 into plain IPv4.)

\item[\rm A tag -- word begining with underscore] \mbox{} \\
An ``alias'' dataset entry for ``='' ``attribute'' uses.
\end{description}


{\em attribute} and {\em value} are tokens.
They are used by {\tt policytest()} to make decisions.

The attribute scanners operate in a manner, where the first
instance of interesting attribute is the one that is used.
Thus you can construct setups which set some attribute, and
then {\em ignore} all latter instances of that same attribute
which have been pulled in via ``{\em = _alias_tag}'' mechanism,
for example.

In following, ``understood'' value is one or both of literals: ``+'', ``-'',
if they are listed at the definition entry.
In case only one is understood, the other one can be considered as
placeholder which stops the scanner for that attribute.

Attribute names, and understood value tokens are:

\begin{description}
\item[\tt = _any_tag] \mbox{} \\
The analysis function will descend to look up ``_any_tag'' from
the database, and expand its content in this place.

\item[\tt rejectnet +] \mbox{} \\
Existence of this attribute pair sets persistent session flag:
``always-reject'', which causes all ``MAIL FROM'' and ``RCPT TO''
commands to fail until end of the session.

This is tested for at the connection start against connecting
IP address, and against IP-reversed domain name.
This is also tested against the ``HELO/EHLO'' supplied parameter
string.

Use of this should be limited only to addresses against which you
really have grudges.

\item[\tt freezenet +] \mbox{} \\
Existence of this attribute pair sets persistent session flag:
``always-freeze'', which will accept messages in, but all of them
are moved into ``freezer'' spool directory.

This is tested for at the same time as ``rejectnet''.

\item[\tt rejectsource +] \mbox{} \\
Existence of this attribute pair rejects ``MAIL FROM'' address,
and thus all subsequent ``RCPT TO'' and ``DATA'' transactions
until new ``MAIL FROM'' is supplied.

\item[\tt freezesource +] \mbox{} \\
Existence of this attribute pair causes subsequently following
``DATA'' phase message to be placed into ``freezer'' spool directory.

This is tested for only at ``MAIL FROM'', and subsequent ``MAIL FROM''
may supply another value.

\item[\tt relaycustomer +/-] \mbox{} \\
Existence of this attribute pair is tested for at ``MAIL FROM'',
and it affects subsequent ``RCPT TO'' address testing.

Pair ``relaycustomer -'' is a placeholder no-op, while
``relaycustomer +'' tells to the system that it should not
test the ``RCPT TO'' address very deeply.

{\em Usage of this attribute is not encouraged!
Anybody could get email relayed through just by claiming
a ``MAIL FROM'' domain which has this attribute.}

\item[\tt relaycustnet +] \mbox{} \\
Existence of this attribute pair is tested for at the  connection
start against connecting IP address, and against IP-reversed domain name.

If this pair exists, session sets persistent ``always-accept'' flag,
and will not do further policy analysing for the ``MAIL FROM'', nor
``RCPT TO'' addresses.  (Except looking for valid A/MX data from the
DNS for the sender/recipient domains.)

\item[\tt fulltrustnet +] \mbox{} \\
Because the DNS lookups still done with ``relaycustnet +'' setting on,
a massive feed for fanout servers might become slowed down/effectively
killed, unless we use ``fulltrustnet +'' specification for the feeder
host.  Then everything is taken in happily from that source address.

\item[\tt trustrecipients +] \mbox{} \\
This is a variant of ``relaycustnet,'' where  ``RCPT TO'' addresses are
not checked at all, but ``MAIL FROM'' addresses are looked up from
the DNS. (Unless some other test with the ``MAIL FROM'' domain name
has matched before that.)

\item[\tt trust-whoson +] \mbox{} \\
If the system has been compiled with support to ``{\em whoson}'' services,
see file ``{\em whoson-*.tar.gz}'' in the ``contrib/'' subdirectory.
This facilitates indirectly authenticated (via POP/IMAP) SMTP message
submission for dialup-type users.

\item[\tt relaytarget +] \mbox{} \\
With this attribute pair the current ``RCPT TO'' address is accepted in
without further trouble. (Theory being, that keys where this attribute
pair exist are fully qualified, and valid, thus no need for DNS analysis.)

See ``RCPT TO'' processing algorithm for further details.

\item[\tt relaytarget -] \mbox{} \\
This attribute pair causes instant rejection of the current ``RCPT TO''
address.

See ``RCPT TO'' processing algorithm for further details.

\item[\tt freeze +] \mbox{} \\
When ``RCPT TO'' address test meets this attribute pair, the entire
message will be placed into ``freezer'' directory.

\item[\tt acceptifmx +/-] \mbox{} \\
This attribute pair is used to give fuzzy feeling in anti-relay setups
so that we don't need to list {\bf all} those target domains that we
are allowing to use ourselves as relays.

This will basically check that ``RCPT TO'' address has our server
as one of its MX entries.

The value (``+'' or ``-'') determines how ``severe'' the nonexistence
of MX data is.  With ``+'' the server will yield ``400'' series temporary
error with implied invitation to try again, and with ``-'' the server will
yield ``500'' series permanent error.

\item[\tt acceptifdns +/-] \mbox{} \\
This attribute pair is complementary for the ``acceptifmx'' in sense
that it accept the recipient address in case the DNS system has any
A or MX information for it.

This attribute pair should not be used.

\item[\tt senderokwithdns +/-] \mbox{} \\
This attribute pair will do DNS analysis for ``MAIL FROM'' domain, and
accept it only if there exists A or MX data for the said domain.

The value (``+'' or ``-'') determines how ``severe'' the nonexistence
of DNS data is.  With ``+'' the server will yield ``400'' series temporary
error with implied invitation to try again, and with ``-'' the server will
yield ``500'' series permanent error.


\item[\tt sendernorelay +] \mbox{} \\
Tested at ``MAIL FROM'' address domain, and affects ``RCPT TO''
address domain analysis.
{\em At the moment this attribute does not make sense, don't use!}

\item[\tt test-dns-rbl +] \mbox{} \\
This attribute pair will use Paul Vixie's RBL
( HTTP://maps.vix.com/rbl/ )
system to block undesired connection sources.

\item[\tt rply-dns-rbl +] \mbox{} \\
\item[\tt test-rply-dns-rbl +] \mbox{} \\
This is a ``recipient selective'' version of the RBL.
The first one is to be placed into the default address case
(the ``[0.0.0.0]/0´´), and then the latter can be used in given
destination domain(s) to test for the result of the lookup.

This allows selective usage of 'RBL' blocking via this server.
For example if you have {\tt smtp-policy.mx} file listing special
cases (opposite of your default domain address ``.'' values)

\begin{alltt}\medskip\hrule\medskip
 fobar.com  test-rply-dns-rbl + relaytarget +
 barfo.dom  test-rply-dns-rbl + relaytarget +
\medskip\hrule\end{alltt}\medskip

The selectivity can be either by means of listing those where the test
happens, or those where it doesn't happen -- the latter means that
the default domain address (``.'') must have ``test-rply-dns-rbl +'' entry.

\item[\tt maxinsize nnn] \mbox{} \\
This attribute pair yields numeric limit for incoming message
size.  With this you can define source specific message size
limits so that if your intranetwork has a system with lower
inbound message size, than you do, you can report this limit
at the ``EHLO'' responses.

Partly this is placeholder for further code with for example
source/target domain specific runtime enforced size limits.

\item[\tt maxoutsize nnn] \mbox{} \\
Placeholder for further code

\item[\tt localdomain *] \mbox{} \\
Placeholder for further code

\item[\tt message "text string in quotes"] \mbox{} \\
Placeholder for further code
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\end{multicols}

17.4.1. Semantics

The {\tt policytest()} function is called by smtp-server to check the client 
host, the sender's and recipients' addresses.  {\tt policytest()} looks for 
the name and address of the client host as well as full and partial user address 
and domain part of sender and recipient addresses in this database.  The 
retrieved attributes are used to make decissions on accepting or rejecting 
the incoming mail.

If looking for ``foo.bar.edu'' and an exact match failed, the database looks
for keys in sequence:  ``.foo.bar.edu'', ``.bar.edu'', ``.edu'', and ``.''.

The order of entries in the input file is not important, as the file is
compiled into binary database for faster lookup.

When searching for an IP address the entry with the most common (leftside)
bits is returned.   So you can have a [0.0.0.0]/0 entry what specifies the 
default addributes for all unlisted IP addresses. (Both IPv4 and IPv6)

`=' is a special attribute.

The notation `= _tag' means ``See also at `_tag'". If {\tt server()} doesn't 
find the requested attribute of the object, it will replace object name 
with `_tag' and restart the search.

{\Large SCRIPT REMOVED; SEE FILE  smtp-policy.src}