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…

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}

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…)

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}

# External program for received message content analysis:
#PARAM  contentfilter   $MAILBIN/smtp-contentfilter

 -1 negatives are condemned into rejection
  0 zero is ok! gladly accepted
  1 positives are sent into the freezer

 -1
 -1 250 2.7.1 Glad to see some spam, immediately destroyed :)
  0
  0 250 2.6.0 Message OK!
  1
  1 550 5.7.1 That is spam, rejected!

Text to be inserted here.

Text to be inserted here.